淺 談 自 動 化編程
自動化測試的優點:瀏覽器
自動化測試能夠替代大量的手工機械重複性操做,測試工程師能夠把更多的時間花在更全面的用例設計和新功能的測試上;併發
自動化測試能夠大幅提高迴歸測試的效率,很是適合敏捷開發過程;高併發
自動化測試能夠更好地利用無人值守時間,去更頻繁地執行測試,特別適合如今非工做時間執行測試工做時間分析失敗用例的工做模式;工具
自動化測試能夠高效實現某些手工測試沒法完成或者代價巨大的測試類型,好比關鍵業務7×24小時持續運行的系統穩定性測試和高併發場景的壓力測試等;性能
自動化測試還能夠保證每次測試執行的操做以及驗證的一致性和可重複性,避免人爲的遺漏或疏忽學習
自動化測試的劣勢:測試
自動化測試並不能取代手工測試,它只能替代手工測試中執行頻率高、機械化的重複步驟。你千萬不要奢望全部的測試都自動化,不然必定會得不償失。spa
自動測試遠比手動測試脆弱,沒法應對被測系統的變化,業界一直有句玩笑話「開發手一抖,自動化測試忙一宿」,這也從側面反映了自動化測試用例的維護成本一直居高不下的事實。其根本緣由在於自動化測試自己不具備任何「智能」,只是循序漸進地執行事先定義好的測試步驟並驗證測試結果。對於執行過程當中出現的明顯錯誤和意外事件,自動化測試沒有任何處理能力。設計
自動化測試用例的開發工做量遠大於單次的手工測試,因此只有當開發完成的測試用例的有效執行次數大於等於5次時,才能收回自動化測試的成本。
手工測試發現的缺陷數量一般比自動化測試要更多,而且自動化測試僅僅能發現迴歸測試範圍的缺陷。
測試的效率很大程度上依賴自動化測試用例的設計以及實現質量,不穩定的自動化測試用例實現比沒有自動化更糟糕。
實行自動化測試的初期,用例開發效率一般都很低,大量初期開發的用例一般會在整個自動化測試體系成熟,和測試工程師全面掌握測試工具後,須要重構。
業務測試專家和自動化測試專家一般是兩批人,前者懂業務不懂自動化技術,後者懂自動化技術但不懂業務,只有兩者緊密合做,才能高效開展自動化測試。
自動化測試開發人員必須具有必定的編程能力,這對傳統的手工測試工程師會是一個挑戰。
適合作自動化的項目:
第一,需求穩定,不會頻繁變動
自動化測試最怕的就是需求不穩定,太高的需求變動頻率會致使自動化測試用例的維護成本直線上升.剛剛開發完成並調試經過的用例可能由於界面變化,或者是業務流程變化,不得不從新開發調試。因此自動化測試更適用於需求相對穩定的軟件項目.
第二,研發和維護週期長,須要頻繁執行迴歸測試。
軟件產品的生命週期通常都比較長,一般會有多個版本陸續發佈,每次版本發佈都會有大量的迴歸測試需求若是短時間的一次性項目,就算從技術上講自動化測試的可行性很高,但從投入產出比(ROI)的角度看並不建議實施自動化,由於千辛萬苦開發完成的自動化用例可能執行一兩次,項目就結束了。
第三,須要在多種平臺上重複運行相同測試的場景。
這樣的場景其實有不少,好比:對於GUI測試,一樣的測試用例須要在多種不一樣的瀏覽器上執行;對於移動端應用測試,一樣的測試用例須要在多個不一樣的Android或者iOS版本上執行,或者是一樣的測試須要在大量不一樣的移動終端上執行.
第四,某些測試項目經過手工測試沒法實現,或者手工成本過高。
對於全部的性能和壓力測試,很難經過手工方式實現。好比,某一個項目要求進行一萬併發用戶的基準性能測試(Benchmark test),難道你真的要找一萬個用戶按照你的口令來操做被測軟件嗎?又好比,對於7×24小時的穩定性測試,難道你也要找一批用戶沒日沒夜地操做被測軟件嗎?這個時候,你就必須藉助自動化測試技術了,用機器來模擬大量用戶反覆操做被測軟件的場景。固然對於此類測試是不可能經過GUI操做來模擬大量用戶行爲的,你必須基於協議的自動化測試技術.
第五,被測軟件的開發較爲規範,可以保證系統的可測試性。
從技術上講,若是要實現穩定的自動化測試,被測軟件的開發過程就必須規範。好比,GUI上的控件命名若是沒有任何規則可尋,就會形成GUI自動化的控件識別與定位不穩定,從而影響自動化測試的效率.
第六,測試人員已經具有必定的編程能力。
若是測試團隊的成員沒有任何開發編程的基礎,那你想要推行自動化測試就會有比較大的阻力。這個阻力會來自於兩個方面:前期的學習成本一般會比較大,很難在短時間內對實際項目產生實質性的幫助,此時若是管理層對自動化測試沒有正確的預期,極可能會叫停自動化測試;測試工程師一般會很是熱衷於學習使用自動化測試技術,以致於他們的工做重點會發生錯誤的偏移,把大量的精力放在自動化測試技術的學習與實踐上,而忽略了測試用例的設計,這將直接下降軟件總體的質量。