不管你是剛入行的小白，還是已經在做軟件測試的工作，相信你一定聽說過或者接觸過自動化測試。那麼，自動化測試到底是什麼意思呢？

顧名思義，自動化測試是，把人對軟件的測試行為轉化為由機器執行測試行為的一種實踐，對于最常見的 GUI 自動化測試來講，就是由自動化測試工具模拟之前需要人工在軟件界面上的各種操作，并且自動驗證其結果是否符合預期。

你是不是有點小激動？這似乎開啟了用機器代替重複手工勞動的自動化時代，你可以從簡單重複勞動中解放出來了。但現實呢？

自動化測試的本質是先寫一段代碼，然後去測試另一段代碼，所以實現自動化測試用例本身屬于開發工作，需要投入大量的時間和精力，并且已經開發完成的用例還必須随着被測對象的改變而不斷更新，你還需要為此付出維護測試用例的成本。

當你發現自動化測試用例的維護成本高于其節省的測試成本時，自動化測試就失去了價值與意義，你也就需要在是否使用自動化測試上權衡取舍了。

為了讓你更好地理解自動化測試的價值，即為什麼需要自動化測試，我先來跟你聊聊自動化測試通常有哪些優勢：

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

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

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

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

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

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

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

自動測試遠比手動測試脆弱，無法應對被測系統的變化，業界一直有句玩笑話“開發手一抖，自動化測試忙一宿”，這也從側面反映了自動化測試用例的維護成本一直居高不下的事實。

其根本原因在于自動化測試本身不具有任何“智能”，隻是按部就班地執行事先定義好的測試步驟并驗證測試結果。對于執行過程中出現的明顯錯誤和意外事件，自動化測試沒有任何處理能力。

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

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

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

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

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

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

什麼樣的項目适合自動化測試？

看到這裡，你心裡可能在暗自嘀咕，“有沒有搞錯啊，自動化測試的劣勢居然比優勢還多”。那為什麼還有那麼多的企業級項目在實行自動化測試呢？那麼，我接下來要講的内容就是，到底什麼樣的項目适合自動化測試？

第一，需求穩定，不會頻繁變更。

自動化測試最怕的就是需求不穩定，過高的需求變更頻率會導緻自動化測試用例的維護成本直線上升。剛剛開發完成并調試通過的用例可能因為界面變化，或者是業務流程變化，不得不重新開發調試。所以自動化測試更适用于需求相對穩定的軟件項目。

第二，研發和維護周期長，需要頻繁執行回歸測試。

1. 在我看來，軟件産品比軟件項目更适合做自動化測試。

首先，軟件産品的生命周期一般都比較長，通常會有多個版本陸續發布，每次版本發布都會有大量的回歸測試需求。

同時，軟件産品預留給自動化測試開發的時間也比較充裕，可以和産品一起疊代。

其次，自動化測試用例的執行比高于 1:5，即開發完成的用例至少可以被有效執行 5 次以上時，自動化測試的優勢才可以被更好地體現。

2. 對于軟件項目的自動化測試，就要看項目的具體情況了。

如果短期的一次性項目，就算從技術上講自動化測試的可行性很高，但從投入産出比（ROI）的角度看并不建議實施自動化，因為千辛萬苦開發完成的自動化用例可能執行一兩次，項目就結束了。我還遇到過更誇張的情況，自動化測試用例還沒開發完，項目都已經要上線了。

所以，對于這種短期的一次性項目，我覺得你應該選擇手工探索式測試，以發現缺陷為第一要務。而對于一些中長期項目，我的建議是：對比較穩定的軟件功能進行自動化測試，對變動較大或者需求暫時不明确的功能進行手工測試，最終目标是用 20% 的精力去覆蓋 80% 的回歸測試。

第三，需要在多種平台上重複運行相同測試的場景。

這樣的場景其實有很多，比如：

對于 GUI 測試，同樣的測試用例需要在多種不同的浏覽器上執行；

對于移動端應用測試，同樣的測試用例需要在多個不同的 Android 或者 iOS 版本上執行，或者是同樣的測試需要在大量不同的移動終端上執行；

對于一些企業級軟件，如果對于不同的客戶有不同的定制版本，各個定制版本的主體功能絕大多數是一緻的，可能隻有個别功能有輕微差别，測試也是需要覆蓋每個定制版本的所有測試；

……

這些都是自動化測試的最佳應用場景，因為單個測試用例都需要被反複執行多次，能夠使自動化測試的投資回報率最大化。

第四，某些測試項目通過手工測試無法實現，或者手工成本太高。

對于所有的性能和壓力測試，很難通過手工方式實現。

比如，某一個項目要求進行一萬并發用戶的基準性能測試（Benchmark test），難道你真的要找一萬個用戶按照你的口令來操作被測軟件嗎？又比如，對于 7×24 小時的穩定性測試，難道你也要找一批用戶沒日沒夜地操作被測軟件嗎？

這個時候，你就必須借助自動化測試技術了，用機器來模拟大量用戶反複操作被測軟件的場景。當然對于此類測試是不可能通過 GUI 操作來模拟大量用戶行為的，你必須基于協議的自動化測試技術，這個我會在後續的性能測試章節詳細叙述。

第五，被測軟件的開發較為規範，能夠保證系統的可測試性。

從技術上講，如果要實現穩定的自動化測試，被測軟件的開發過程就必須規範。比如，GUI 上的控件命名如果沒有任何規則可尋，就會造成 GUI 自動化的控件識别與定位不穩定，從而影響自動化測試的效率。

另外，某些用例的自動化必須要求開發人員在産品中預留可測試性接口，否則後續的自動化會很難開展。

比如，有些用戶登錄操作，需要圖片驗證碼，如果開發人員沒有提供繞開圖片驗證碼的路徑，那麼自動化測試就必須借助光學字符識别（OCR）技術來對圖片驗證碼進行模式識别，而它的設計初衷是為了防止機器人操作，可想而知 OCR 的識别率會很低，就會直接影響用例的穩定性。

第六，測試人員已經具備一定的編程能力。

如果測試團隊的成員沒有任何開發編程的基礎，那你想要推行自動化測試就會有比較大的阻力。這個阻力會來自于兩個方面：

前期的學習成本通常會比較大，很難在短期内對實際項目産生實質性的幫助，此時如果管理層對自動化測試沒有正确的預期，很可能會叫停自動化測試；

測試工程師通常會非常熱衷于學習使用自動化測試技術，以至于他們的工作重點會發生錯誤的偏移，把大量的精力放在自動化測試技術的學習與實踐上，而忽略了測試用例的設計，這将直接降低軟件整體的質量。

自動化測試是，把人工對軟件的測試轉化為由機器執行測試行為的一種實踐，可以把測試工程師從機械重複的測試工作中解脫出來，将更多的精力放在新功能的測試和更全面的測試用例設計上。

然而自動化測試試一把“雙刃劍”，雖然它可以從一定程度上解放測試工程師的勞動力，完成一些人工無法實現的測試，但并不适用于所有的測試場景，如果維護自動化測試的代價高過了節省的測試成本，那麼在這樣的項目中推進自動化測試就會得不償失。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!