🍅?點擊文末小卡片，免費獲取軟件測試全套資料，資料在手，漲薪更快????

什么是自動化測試?

自動化測試是指利用軟件測試工具自動實現全部或部分測試，它是軟件測試的一個重要組成 部分，能完成許多手工測試無法實現或難以實現的測試。能夠正確、合理地實施自動測試，可以 快速、全面地對軟件進行測試，從而提高軟件質量，節省經費，縮短軟件發布周期。

自動化測試一般分為UI 自動化測試和接口自動化測試。

UI自動化測試是指基于界面元素的自動化測試。需要先定位界面元素的路徑，然后通過腳本 實現自動化。這種方法因為界面需求的變更頻繁，腳本更新頻繁，不利于后期的維護工作，造成 自動化工作的成本巨大，已經慢慢被各大公司所淘汰。

隨即演變出的就是接口自動化了。接口自動化是指模擬程序接口層面的自動化，由于接口不 易變更維護成本小，所以它深受各大公司喜愛。接口自動化也是本書的重點。它包含兩個部分， 功能性的接口自動化測試和并發接口自動化測試。

自動化測試與手工測試的區別

自動化測試和手工測試并沒有高低貴賤之分，雖然劃分在不同的階層，但只是出于對測試人 員個人的價值評判而已。以下詳細解析這兩者的區別。

1．測試目的不同

雖然都是測試，但這2種測試的目的卻是截然相反的。

• 手工測試的目的在于通過“破壞”發現系統有bug。
• 自動化測試的目的在于“驗證”系統沒有bug。

當測試系統處于前期不穩定的時候，做自動化測試將毫無意義，因為程序運行到一半就會因 為某個bug而停止的，而當這個bug未被修復之前所有的自動化測試都會卡在這里無法往下執行。 而當測試系統處于穩定的時候，通過手工測試重復著一樣的操作也會變得煩瑣和枯燥，所以這兩 者在不同的測試階段都有著不可替代的作用。

2．覆蓋范圍不同

除了目的的不同，覆蓋范圍也是不同的。

• 手工測試可以盡可能地覆蓋測試系統的各個角落。
• 自動化測試只能覆蓋測試系統的主要功能。

試想把所有的測試用例都弄成自動化是一件多么美好的事情，但代價實在太大了，投入的時 間和產出完全不成正比，不夸張地說如果要做到完全自動化測試，所需要的代碼量會遠遠超過開 發編寫程序的代碼量。所以自動化測試只能挑一些重要和穩定的功能來做，而更多的一些細節的 測試還需要手工測試來完成。

3．智能判斷不同

自動化和手工測試還有一個最大的區別是智能判斷方面。 計算機程序對于人而言是絕對的服從和誠實的。

舉個例子，用計算機程序去計算1＋1，結果必然等于2（除非你的程序本身寫的有bug， 這不是計算機程序的問題），而如果問一個人1＋1等于幾，可能會有一個答案“1＋1等于我 們”，那這個結果是對還是錯呢？如果交給程序判斷必然是錯的。因此智能判斷是自動化測試的 瓶頸，一個操作出現多種結果可能都是對的，但又可能都是錯的。

再舉個電商的例子，比如有個特價產品只有一份，需要秒殺，有可能搶到，也有可能搶不到。 對于能搶到來說，只有“他”1個人搶到是對的，如果多個人都能搶到那就是錯的。對于不能搶 到來說，已經有1個人搶到就是對的，如果沒有一個人搶到的話就是錯的，這個時候自動化測試 程序該如何判斷結果的對錯呢？這樣的情況比比皆是，雖然有辦法通過程序去預置各種條件讓結 果唯一化，但需要花大量的時間和精力去優化自動化測試代碼，并且還需要分多個自動化測試程 序完成，這個時候還不如人工介入測試進行判斷來得方便。

這樣看來其實自動化測試能做的還是非常有限的，而更多的時候還是需要手工測試，利用工具也好，邏輯判斷也好，又或者讓開發修改程序來配合測試也好，總之能達到測試的最終目的就好，從這個意義上來說手工測試也并非沒有技術含量，而自動化測試也沒有那么無所不能。

自動化測試的困境

自動化測試具有很大的優勢，一勞永逸地用程序代替人力，人力干活8小時，而程序可以24小時不停止地干活。但是自動化測試還有一個很大的困境，即由于自動化測試很難持續維護，導致在大多數公司無法普及這種測試方式。

IT行業的競爭日益激烈，產品要保持自身的競爭力就需要不斷高速迭代新版本、新功能。這就意味了原來寫的自動化測試程序變得不可用了（其中的部分程序），而留給測試人員的時間又往往是很少的，于是只能手工測試保證按時上線，等上完線之后可能過幾天又有新的功能要測試。留給測試的時間不夠完成自動化測試程序的維護更新，周而復始，久而久之，原來的自動化測試程序已經和當前版本相去甚遠了，最后自動化測試就不了了之了。我想這就是人們常說的“愿望是美好的，但現實總是殘酷的”。

既然知道是困境，必然就是很難解決的，那有沒有折中的辦法來減少一定的維護成本，又可以達到一定的自動化測試的目的呢？回答這個問題之前先要看透自動化測試的核心本質，就是元素識別＋元素操作＋驗證結果，大多數自動化測試工具都會提供元素識別和元素操作（鼠標點擊、鍵盤輸入、屏幕 touch等），只有在驗證結果的時候需要寫代碼提取實際結果，然后和預期結果進行比較，最后得出測試通過或者不通過的結論。

其實對于寫代碼的部分來說都是通用的，不同的地方在于獲取實際結果的方式變更或者預期結果的變更，工作量并不多。真正煩瑣之處在于元素的識別，每個元素其實都由唯一標識來識別，這樣才能保證不會操作錯元素，好處在于如果元素不變，那唯一的標識也永遠不會識別錯，這是自動化測試可以實施的基礎。但有利自然有弊，一旦元素變了，原來的標識就不可用了，那自動化測試就無法實施了。說到這里如果可以繞過元素識別這一步，將元素操作以接口的形式通過腳本完成，就可以拋棄重量級的自動化測試工具，而通過測試腳本直接實現接口自動化測試。

最后感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

這些資料，對于做【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！凡事要趁早，特別是技術行業，一定要提升技術功底。