本文首發(fā)于公眾號「測試漫談」，回復(fù)“軟件測試教程”獲?。蝴溩訉W院、黑馬、小強軟件測試全套學習教程！

當我們找工作的時候查看招聘信息發(fā)現(xiàn)都需要有自動化測試經(jīng)驗，由此看來測試人員不會一點自動化測試技術(shù)都不好意思說自己是做軟件測試的。大部分測試人員也都是從使用自動化測試工具、錄制回放、測試腳本、開發(fā)小工具入門自動化測試的，然后在慢慢的接觸 UI 自動化、接口自動化、持續(xù)集成，最后搭建自動化測試框架系統(tǒng)。

大部分測試初學者入門自動化測試接觸最多的也許就是 UI 自動化了，也都使用過移動端的 Uiautomator、Appium? UI自動化框架、PC 互聯(lián)網(wǎng)界面相關(guān)的 Selenium、Robot Framework? UI自動化框架，潛意識里認為 UI 自動化測試很簡單。但是使用一段時間之后喜憂參半，特別是在工作中真正使用時就立馬水土不服了，開發(fā)和維護腳本的時間遠遠大于手工測試的時間，得不償失，最后由回歸到了手工測試。

如果要想 UI 自動化在實際的工作中得以使用，必須要解決以下痛點，否則 UI 自動化的測試還有很遠的路要走。

1、需求不穩(wěn)定，頻繁變更的項目

UI 自動化測試最大的挑戰(zhàn)就是需求的變化，界面如果經(jīng)常變動，腳本就需要重新編寫，界面需求頻繁的變更導致編寫腳本的速度趕不上需求的變化，那 UI 自動化就是名存實亡，因此 UI 自動化測試特別適合需求穩(wěn)定、不會頻繁變更的項目。敏捷開發(fā)的項目需求不穩(wěn)定，需求的變更經(jīng)常會導致界面的變更，同時敏捷開發(fā)的項目周期短，因此敏捷開發(fā)的項目就不適合做 UI 自動化。

2、開發(fā)維護周期短的項目

對于一次性開發(fā)的、周期短的項目，考慮到 UI 自動化的投入產(chǎn)出比，不宜進行 UI 自動化測試。UI 自動化的收益主要是在多輪測試的時候才能體現(xiàn)出來，試想一個維護周期短的項目測試的輪次比較少，如界面測試就測試 1 到 2 輪即可，這樣完全可以使用手工測試就行了。同時自動化腳本的開發(fā)和調(diào)試本身就需要一定的時間，如果項目的周期短，沒有足夠的時間支撐腳本的開發(fā)，那也無需自動化測試了。

3、被測系統(tǒng)開發(fā)不規(guī)范，可測試性需求不明確

UI 自動化測試其實就是模擬手工點擊，不像人眼可以直接找到需要點擊的控件，程序就不一樣了，需要我們事先要找到要點擊的控件，然后讓程序去點擊完成模擬手工的操作。這就需要在項目開發(fā)前針對自動化測試定義一些列的規(guī)范，開發(fā)工程師在開發(fā)的時候遵循規(guī)范開發(fā)，UI 自動化才可以進行下去。例如針對按鈕控件沒有定義唯一的 id 或者文本描述等，在自動化腳本編寫的時候就無法找到該控件。如果開發(fā)在不同的版本之前經(jīng)常隨便變更控件的定義，那之前能執(zhí)行的腳本在之后就無法正確的運行，需要實時維護，帶來很高的人力成本而變得效率低下。同樣的還有接口自動化測試過程中的接口參數(shù)等。

那什么樣的項目適合進行 UI 自動化測試呢？如下列舉的可以進行參考：需求穩(wěn)定不頻繁變更；需要頻繁的回歸驗證；UI 界面穩(wěn)定、界面控件定義規(guī)范可測試性強；開發(fā)維護周期長的項目；項目進度壓力小；大型公司大平臺；測試部門中大部分測試人員具備腳本開發(fā)能力。

當前，UI 測試是耗費測試團隊人力最多的測試環(huán)節(jié)，大部分的測試人員日常的工作就是 UI 測試。因此 UI 自動化非常適合解決簡單、機械、重復(fù)的任務(wù)，增加測試的覆蓋率。

UI 自動化測試不僅僅編寫測試腳本，也需要設(shè)計，不僅需要考慮成百上千條用例的執(zhí)行效率，還需要考慮維護成本，執(zhí)行結(jié)果的正確性。我們需要明白，UI 自動化測試不能替代手工測試，也很難減少測試人員，不能盲目的推崇和追求 UI 自動化測試。

PS：如果文章對你有價值，歡迎點個喜歡，謝謝 。