非UI自動化測試和UI自動化測試

先抄一段話，來說什麼是自動化測試：Test automation

In software testing, test automation is the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes.

本篇文章也不打算總結有多少種測試，他們怎麼分類，我們只講自動化測試…… 上邊一段話也講了什麼是自動化測試，簡單來講就是一個操作軟體的軟體，然後可以對操作的結果進行驗證。這裡的定義是跟被測軟體分離，這個我不是很同意這句話，有些自動化測試是進程內的，需要inject代碼來運行測試代碼，甚至有些直接類似病毒附加二進位代碼並且運行在被測程序的進程內（確實見過一個軟體是這麼做的，直接改二進位代碼然後在進程內運行一個socket server來執行測試）。

既然是一種軟體，那我們就簡單按照有沒有UI，分為非UI和UI的自動化測試程序：

• 常見的非UI自動化
• 大部分的Unit Test
• API test
• Integration Test
• ...
• 常見的UI自動化
• 帶UI的Unit Test，比如mock掉底層代碼，僅僅測試UI邏輯
• 帶UI的API Test，比如我以前工作過的一個Team是做UI的component的，大部分的API都是跟UI相關的
• 功能測試。大部分的UI自動化測試是功能測試。或者說是Regression Test（應該是翻譯成回歸測試吧）
• ....

我們來看看這兩種測試各自的優點：

• 非UI
• 簡單。測試代碼相對容易寫，容易調試
• 運行穩定。除非代碼邏輯變化，一般不需要改測試代碼。而且不容易受到外在因素影響
• 好維護。運行穩定，就不需要經常去更新測試代碼
• 運行速度快。一般執行速度比UI的測試要快很多
• 容易模擬出錯情況。構造錯誤情況比UI操作容易的多
• UI
• 覆蓋範圍廣。簡單說，就是不挑食，只要是有UI的程序，只要是支持Accessibility的程序都可以做。
• 不需要被測程序源代碼。比如前邊一篇文章的計算器
• 最大程度模擬用戶操作 （有些操作比如用InvokePattern，還是跟用戶點擊滑鼠不太一樣，但是我們可以通過模擬滑鼠事件來達到完全一樣的效果）。這個就淺顯易懂了，畢竟用戶是用滑鼠鍵盤操作的，不是寫代碼來用的……

那一般我們怎麼去選擇用非UI還是UI呢？重要的話說三遍：

能不用UI自動化測試就不用，能不用UI自動化測試就不用，能不用UI自動化測試就不用

這樣好像有點自黑，我就是做UI自動化測試和工具的……，那為什麼還要黑它呢，主要是UI自動化測試有以下顯著缺點：

• 大部分寫UI自動化測試的人員沒有豐富的代碼經驗，甚至有些UI的自動化測試是通過錄製回放腳本來完成的。自動化測試代碼也是軟體代碼，應該遵循軟體開發從設計開始的所有流程（不僅僅是UI自動化測試代碼），這裡還是贊同微軟的SDET的說法
• 在整個軟體開發過程中，越是底層的代碼變動的頻率越低。比如底層類的實現和用戶界面相比，顯然UI變化最頻繁，並且最晚穩定下來
• 為了滿足設計的要求，很多程序的UI大量使用了自定義控制項，但是又沒有遵循微軟的Accessibility標準（甚至根本不知道有這個東西）。導致沒有任何的自動化測試工具可以操作和獲取信息進行測試驗證……
• UI在Windows各個版本中，顯示並不完全一樣（從UI自動化測試工具的角度看）

但是，什麼東西都是有兩面的，雖然有很多的顯著缺點，但是也有很多上邊列的優點，怎麼取捨，怎麼樣發揮UI自動化測試的優勢，我們後邊有幾篇文章會分別做一些介紹：

反對盲目的UI自動化測試

UI自動化測試開始的時機

反對錄製回放腳本

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

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

自動化測試應該從軟體設計開始

軟體設計需要考慮可測試性(testability)

程序設計需要考慮UI框架

程序設計需要考慮非UI自動化測試

團隊需要重視Automation Bug

自動化測試腳本也有維護周期

同步和Sleep的選擇

什麼是一個好的UI自動化測試用例

盡量不用Sleep

單個驗證點和功能封裝

除了Pass和Fail，也需要有Error

UI自動化測試並不是只能用UI狀態來做驗證

自定義控制項支持Windows automation api

談談UI自動化在localization測試中的問題

推薦閱讀：