反對盲目的UI自動化測試

01-24

首先，建議大家看看這篇文章，寫的很不錯：自動化測試: 真的是銀彈？這裡就說一下結論：自動化測試不是銀彈，自動化測試（包括UI自動化測試）是為了減少重複工作，增加測試的覆蓋率，而不是為了替代手工測試，更不是為了減少測試人員（當然，有可能導致減少部分手工測試人員）…… 這裡就不展開討論這個了，我們來說UI自動化測試。

在上一篇文章非UI自動化測試和UI自動化測試 - UI自動化測試 - 知乎專欄裡邊已經說了UI自動化測試的特點和一些優缺點，下面我們針對這幾點來討論一下：

產品是否適合UI自動化測試，是否有其它替代方式

前邊文章也說過了，能不用UI自動化測試就不用，能不用UI自動化測試就不用，能不用UI自動化測試就不用，這也是因為在所有種類的自動化測試中，UI自動化測試是最不穩定，測試用例最難寫的穩定，維護成本最高的方式。所以，我們首先要考慮，是否有替代方案。

雖然UI自動化是比較高成本的方式，但是很多時候也是功能測試的唯一選擇（當然，可以通過軟體設計來減少這種依賴，我們後邊的文章會講到）。這個時候我們在決定採用UI自動化方案之前，需要考慮一下幾點：

選擇UI自動化工具：

看對產品的支持程度。比如產品是用WPF寫的，那公司買的工具是否可以識別，是否有其它商業工具可以支持，價格是不是公司有預算去購買等等。

自動化工具的開發語言是否需要學習成本，自動化工具的第三方類庫是否豐富，建議選擇採用通用語言的自動化工具，比如用python或者c#作為腳本語言的工具。

在定義UI節點的時候，自動化工具是否提供方便的方式來生成UI的映射。而且這種映射是否比較容易維護

是否可以方便的調試測試程序，比如是否支持斷點和變數值查看

產品裡邊自定義UI，或者叫自繪製的UI控制項的比例，是否是關鍵節點控制項（當然了，如果自繪製UI控制項支持的Accessibility的介面，那就沒有問題）。比如，產品的最主要功能是繪圖，一般繪圖區肯定都是自定義控制項，而UI自動化工具基本上對繪圖區都是無能為力的，那是否有其它方式可以來測試？比如把繪圖相關的模塊單獨拿出來，通過API的方式來操作測試？

反對錄製回放腳本

看到有些team把支持錄製回放腳本作為評估自動化測試工具的一個必備條件，而且有些就是用錄製回放來創建測試用例。些很小的項目，測試用例只有幾十上百個倒是問題不大，但是當測試用例個數上百上千的時候，維護測試用例基本上就變成一個繁重的任務。比如一個UI節點細微的變化，可能導致自動化工具沒有識別UI控制項，那麼所有用到這個控制項的測試用例都需要更新，查找替換並且保證沒有替換錯就是一個很大的工作量，更別說一般錄製的腳本人工都不容易理解。

UI自動化測試不只是腳本，也需要設計

軟體測試腳本的開發也是軟體開發，腳本必須符合規範，必須經過設計編碼測試維護的全過程。

測試腳本的設計：根據面向對象設計的原則，我們需要對變化頻繁的地方進行必要的封裝。在這裡變化相對最頻繁的就是UI本身，而相對穩定的是業務邏輯。所以我們可以針對UI進行封裝，然後再封裝一層業務邏輯層，所有的測試用例都通過業務邏輯介面進行操作。比如我們要測試一個登錄窗口，那麼UI層就包含用戶名，密碼，登錄按鈕的UI定義，邏輯層包含介面類似login介面，測試用例裡邊就調用login介面登錄並進行必要的驗證。

測試腳本的編碼：既然是軟體工程，那麼腳本也必須遵循代碼規範，比如python的腳本需要遵循python的代碼規範。

測試腳本的測試：腳本是用於測試程序的，那麼自身的質量也是至關重要。建議有條件的team進行code review，當然這個很難做到…… 另外就是至少要人工觀察腳本的操作，來確定它做了正確的事情。而且需要在不同的系統和機器上測試通過。

測試腳本的維護：UI相對來說比較容易變化，這就導致測試用例的fail，那麼我們需要去調試並確認是腳本問題，確認之後如果設計良好，大部分情況下只需要更新UI層就可以了。另外我們需要考慮是否UI變化過於頻繁，現在自動化開始是不是正確？

UI自動化測試開始的時機

從前邊測試腳本的維護可以看出，維護工作量的大小，跟UI變動是否頻繁直接相關。我們需要做的事情，就是確定什麼時候UI已經穩定了，我們再開始UI自動化，否則還是考慮先人工測試覆蓋。當然了，我們也沒必要等整個程序的UI穩定，比如一個獨立的功能UI穩定了之後，我們就可以先對那個功能進行自動化，然後等待其它功能的UI穩定。

而且一旦UI自動化開始，後邊的維護工作也相應要開始

所以我建議開發過程中，有一個milestone叫UI freeze，這個階段後就可以著手開始UI的自動化測試了。當然，非UI的自動化，比如Unit Test，Integration test和API test應該很早就開始了

另外一種情況，是針對上一個版本release的功能的回歸測試，這個是最適合UI自動化的方面。一般來說，這種情況UI變動基本上沒有，而且功能比較穩定，測試寫好之後，可以有效減輕手工測試的壓力，而且可以更專註於新功能的驗證。

需要考慮UI自動化的投入產出比

我們先說投入：與軟體的投入產出一樣，一個設計良好的UI自動化框架，最大的投入應該是創建框架和實現測試自動化腳本，而盡量減少維護的工作量。一個壞的自動化框架，前期可能投入較少，後續的維護和更改的成本可能幾倍與前期，甚至到最後只能丟棄掉。

說到產出，自動化測試跑的次數越多，平台覆蓋越廣，產出就越多，減少手工測試的工作量也越多。一旦自動化測試寫好，那就應該讓他們持續的跑起來，比如根據情況設置每周，每日，甚至是每次提交自動部署到所有平台運行並報告結果。這個配合Jenkins來實現會比較方便。