什麽是自動化測試？
不管你是剛入行的小白，還是已經在做軟件測試的工作，相信你一定聽說過或者接觸過自動化測試。那麽，自動化測試到底是什麽意思呢？
顧名思義，自動化測試是，把人對軟件的測試行為轉化為由機器執行測試行為的一種實踐，對於最常見的 GUI 自動化測試來講，就是由自動化測試工具模擬之前需要人工在軟件界面上的各種操作，並且自動驗證其結果是否符合預期。
你是不是有點小激動？這似乎開啟了用機器代替重復手工勞動的自動化時代，你可以從簡單重復勞動中解放出來了。但現實呢？
自動化測試的本質是先寫一段代碼，然後去測試另一段代碼，所以實現自動化測試用例本身屬於開發工作，需要投入大量的時間和精力，並且已經開發完成的用例還必須隨著被測對象的改變而不斷更新，你還需要為此付出維護測試用例的成本。
當你發現自動化測試用例的維護成本高於其節省的測試成本時，自動化測試就失去了價值與意義，你也就需要在是否使用自動化測試上權衡取舍了。
為什麽需要自動化測試？
為了讓你更好地理解自動化測試的價值，即為什麽需要自動化測試，我先來跟你聊聊自動化測試通常有哪些優勢：

1.自動化測試可以替代大量的手工機械重復性操作，測試工程師可以把更多的時間花在更全面的用例設計和新功能的測試上；

2.自動化測試可以大幅提升回歸測試的效率，非常適合敏捷開發過程；

3.自動化測試可以更好地利用無人值守時間，去更頻繁地執行測試，特別適合現在非工作時間執行測試，工作時間分析失敗用例的工作模式；

4.自動化測試可以高效實現某些手工測試無法完成或者代價巨大的測試類型，比如關鍵業務 7×24 小時持續運行的系統穩定性測試和高並發場景的壓力測試等；

5.自動化測試還可以保證每次測試執行的操作以及驗證的一致性和可重復性，避免人為的遺漏或疏忽。

而為了避免對自動化測試的過度依賴，你還需要了解自動化測試有哪些劣勢，這將幫你繞過實際工作中的“坑”。

1.自動化測試並不能取代手工測試，它只能替代手工測試中執行頻率高、機械化的重復步驟。你千萬不要奢望所有的測試都自動化，否則一定會得不償失。

2.自動測試遠比手動測試脆弱，無法應對被測系統的變化，業界一直有句玩笑話“開發手一抖，自動化測試忙一宿”，這也從側面反映了自動化測試用例的維護成本一直居高不下的事實。
其根本原因在於自動化測試本身不具有任何“智能”，只是按部就班地執行事先定義好的測試步驟並驗證測試結果。對於執行過程中出現的明顯錯誤和意外事件，自動化測試沒有任何處理能力。

3.自動化測試用例的開發工作量遠大於單次的手工測試，所以只有當開發完成的測試用例的有效執行次數大於等於 5 次時，才能收回自動化測試的成本。

4.手工測試發現的缺陷數量通常比自動化測試要更多，並且自動化測試僅僅能發現回歸測試範圍的缺陷。

5.測試的效率很大程度上依賴自動化測試用例的設計以及實現質量，不穩定的自動化測試用例實現比沒有自動化更糟糕。

6.實行自動化測試的初期，用例開發效率通常都很低，大量初期開發的用例通常會在整個自動化測試體系成熟，和測試工程師全面掌握測試工具後，需要重構。

7.業務測試專家和自動化測試專家通常是兩批人，前者懂業務不懂自動化技術，後者懂自動化技術但不懂業務，只有二者緊密合作，才能高效開展自動化測試。

8.自動化測試開發人員必須具備一定的編程能力，這對傳統的手工測試工程師會是一個挑戰。

什麽樣的項目適合自動化測試？
看到這裏，你心裏可能在暗自嘀咕，“有沒有搞錯啊，自動化測試的劣勢居然比優勢還多”。那為什麽還有那麽多的企業級項目在實行自動化測試呢？那麽，我接下來要講的內容就是，到底什麽樣的項目適合自動化測試？
第一，需求穩定，不會頻繁變更。
自動化測試最怕的就是需求不穩定，過高的需求變更頻率會導致自動化測試用例的維護成本直線上升。剛剛開發完成並調試通過的用例可能因為界面變化，或者是業務流程變化，不得不重新開發調試。所以自動化測試更適用於需求相對穩定的軟件項目。
第二，研發和維護周期長，需要頻繁執行回歸測試。
1. 在我看來，軟件產品比軟件項目更適合做自動化測試。
首先，軟件產品的生命周期一般都比較長，通常會有多個版本陸續發布，每次版本發布都會有大量的回歸測試需求。
同時，軟件產品預留給自動化測試開發的時間也比較充裕，可以和產品一起叠代。
其次，自動化測試用例的執行比高於 1:5，即開發完成的用例至少可以被有效執行 5 次以上時，自動化測試的優勢才可以被更好地體現。
2. 對於軟件項目的自動化測試，就要看項目的具體情況了。
如果短期的一次性項目，就算從技術上講自動化測試的可行性很高，但從投入產出比（ROI）的角度看並不建議實施自動化，因為千辛萬苦開發完成的自動化用例可能執行一兩次，項目就結束了。我還遇到過更誇張的情況，自動化測試用例還沒開發完，項目都已經要上線了。
所以，對於這種短期的一次性項目，我覺得你應該選擇手工探索式測試，以發現缺陷為第一要務。而對於一些中長期項目，我的建議是：對比較穩定的軟件功能進行自動化測試，對變動較大或者需求暫時不明確的功能進行手工測試，最終目標是用 20% 的精力去覆蓋 80% 的回歸測試。
第三，需要在多種平臺上重復運行相同測試的場景。
這樣的場景其實有很多，比如：

對於 GUI 測試，同樣的測試用例需要在多種不同的瀏覽器上執行；
對於移動端應用測試，同樣的測試用例需要在多個不同的 Android 或者 iOS 版本上執行，或者是同樣的測試需要在大量不同的移動終端上執行；
對於一些企業級軟件，如果對於不同的客戶有不同的定制版本，各個定制版本的主體功能絕大多數是一致的，可能只有個別功能有輕微差別，測試也是需要覆蓋每個定制版本的所有測試；
……

這些都是自動化測試的最佳應用場景，因為單個測試用例都需要被反復執行多次，能夠使自動化測試的投資回報率最大化。
第四，某些測試項目通過手工測試無法實現，或者手工成本太高。
對於所有的性能和壓力測試，很難通過手工方式實現。
比如，某一個項目要求進行一萬並發用戶的基準性能測試（Benchmark test），難道你真的要找一萬個用戶按照你的口令來操作被測軟件嗎？又比如，對於 7×24 小時的穩定性測試，難道你也要找一批用戶沒日沒夜地操作被測軟件嗎？
這個時候，你就必須借助自動化測試技術了，用機器來模擬大量用戶反復操作被測軟件的場景。當然對於此類測試是不可能通過 GUI 操作來模擬大量用戶行為的，你必須基於協議的自動化測試技術，這個我會在後續的性能測試章節詳細敘述。
第五，被測軟件的開發較為規範，能夠保證系統的可測試性。
從技術上講，如果要實現穩定的自動化測試，被測軟件的開發過程就必須規範。比如，GUI 上的控件命名如果沒有任何規則可尋，就會造成 GUI 自動化的控件識別與定位不穩定，從而影響自動化測試的效率。
另外，某些用例的自動化必須要求開發人員在產品中預留可測試性接口，否則後續的自動化會很難開展。
比如，有些用戶登錄操作，需要圖片驗證碼，如果開發人員沒有提供繞開圖片驗證碼的路徑，那麽自動化測試就必須借助光學字符識別（OCR）技術來對圖片驗證碼進行模式識別，而它的設計初衷是為了防止機器人操作，可想而知 OCR 的識別率會很低，就會直接影響用例的穩定性。
第六，測試人員已經具備一定的編程能力。
如果測試團隊的成員沒有任何開發編程的基礎，那你想要推行自動化測試就會有比較大的阻力。這個阻力會來自於兩個方面：

前期的學習成本通常會比較大，很難在短期內對實際項目產生實質性的幫助，此時如果管理層對自動化測試沒有正確的預期，很可能會叫停自動化測試；
測試工程師通常會非常熱衷於學習使用自動化測試技術，以至於他們的工作重點會發生錯誤的偏移，把大量的精力放在自動化測試技術的學習與實踐上，而忽略了測試用例的設計，這將直接降低軟件整體的質量。

總結
自動化測試是，把人工對軟件的測試轉化為由機器執行測試行為的一種實踐，可以把測試工程師從機械重復的測試工作中解脫出來，將更多的精力放在新功能的測試和更全面的測試用例設計上。
然而自動化測試試一把“雙刃劍”，雖然它可以從一定程度上解放測試工程師的勞動力，完成一些人工無法實現的測試，但並不適用於所有的測試場景，如果維護自動化測試的代價高過了節省的測試成本，那麽在這樣的項目中推進自動化測試就會得不償失。

自動化測試----打卡第四天