我發現了，大家極度關心自動化測試，尤其是UI自動化測試，雖然現在作為專項測試，離開這些越來越遠了，但總能遙想以前，我總能想起自己做nokia的WindowsLive的ui自動化，做web的自動化測試，后面加入騰訊，寫過pc的自動化，作為早期的終端測試，做android的自動化，然后mac的，然后ios。 先不說有多少成功經驗，但是確實有一些感悟，現在分享給大家，希望能幫助大家思考，少走彎路。

*UI自動化測試的真實價值

 

測試生命中三大幻覺:

今天能發布

明天能發布

UI自動化實現了，測試就可以不用測了

正正是第三點賦予了ui自動化測試錯誤的價值。讓UI自動化測試驗證UI, 利用圖片比較去做自動驗證，甚至利用截圖定位按鈕。真是找死的節奏呀。 現在我帶大家認識下它的真正價值。

1. 驗證邏輯而非UI

UI的驗證會引入大量的不穩定因素。換句話說，像當年的測試大牛段念說的，你跑過了UI自動化，你就相信沒問題了嗎？不會相信，原因是啥？因為聰明的你會發現，你驗證的東西越多，例如界面的每個按鈕，顏色，排布，互聯網應用變化最大的就是UI, 你的用例就越不穩定，所以你最終肯定不會驗證全部UI。那結果就是"然并卵"了, 你根本不會相信這個用例真的通過了。因此給大家定個UI自動化能做的，驗證邏輯（另外一種說法，說這種叫功能自動化）。什么叫驗證邏輯？例如驗證qq是否登錄成功，驗證到了好友列表，就是登錄成功，甚至有登錄成功的日志都可以，怎么穩定怎么行。

2.代替大量的UI重復操作

簡單來說就是UI自動化你要投入5元，只是執行4次，每次賺5毛的話，那你還虧3元的問題。什么時候會大量呢？像手Q, 編譯百個市場的包，每個包要驗證核心功能?；蛘呦?a href='http://www.anti-gravitydesign.com/ceshi/ceshijishu/xncs/' target='_blank'>性能ui自動化監控，同一個用例為了多次采樣，也會執行多次。還有每日構建，集成，都可以。關鍵點就是用次數來增加價值，UI自動化能幫你確保不出死人的問題，如登錄不了，登錄了又卡死，或者是監控UI之外的其他，如性能。這些都有機會讓其價值高于成本的。

*最大難點，維護

 

無間道: 出來混，遲早要還的。 這句話，最好用來說明，為什么自動化測試構造得越快越隨便，未來的維護成本也就越大。更甚者，腳本依賴錄制得來的，也是找死的節奏。 無數的故事告訴我，很多UI自動化都是死在一開始就寫或者錄一堆腳本，結果每天都要花大量時間排查錯誤，錯誤有腳本錯誤，有功能的變更，有bug，甚至問題是隨機出現的，但是無論你的問題或者是功能的問題，反正你排查錯誤的時間是花進去了，哪怕你不用改腳本。所以這里看來，

要解決維護的難點，終極招數就是不要碰UI自動化。其實很多大牛都是說不要做ui自動化的，或者這個事情不是最高優先級，但是現實是，大家都做了，優先級還不低。所以我當然不說不做了，要做就只能要狠狠地干一場，要成功，不要失敗。下面給大家有兩點建議，一是策略，二是技術。

策略上，維護成本的控制，腳本要慢慢上，先做核心的BVT，人均維護的腳本1~2個，定目標，如穩定運營1個月，后面增加的腳本要在測試環境穩定跑上一周，才能切換到正式環境。 組織培訓，知識分享，分享寫自動化遇到的坑，沉淀最佳的實踐，讓大家知道寫UI自動化也是在自我提升，而不是簡單的工作任務。

技術上，降低維護成本的方法，

1.腳本里不要有坐標，圖像識別這些，想都別想，想都別想，想都別想！這些都是不穩定的因素。

2.腳本里不要有sleep。sleep就是UI自動化的穩定性的克星，絕對不能有。一方面，如果幫助建立或者直接使用UI自動化測試等待界面穩定的阻塞方法，例如waitForIdle，等待控件出現和消失的方法，如waitForInvisiable之類的。另外一種，就是封裝一個timeout的類，里面包含重試和sleep的策略，讓腳本直接使用。反正，不要看到sleep。

原文轉自：http://www.jianshu.com/p/84f2a5d86334