我發(fā)現(xiàn)了，大家極度關心自動化測試，尤其是UI自動化測試，雖然現(xiàn)在作為專項測試，離開這些越來越遠了，但總能遙想以前，我總能想起自己做nokia的WindowsLive的ui自動化，做web的自動化測試，后面加入騰訊，寫過pc的自動化，作為早期的終端測試，做android的自動化，然后mac的，然后ios。 先不說有多少成功經(jīng)驗，但是確實有一些感悟，現(xiàn)在分享給大家，希望能幫助大家思考，少走彎路。
*UI自動化測試的真實價值
測試生命中三大幻覺:
今天能發(fā)布
明天能發(fā)布
UI自動化實現(xiàn)了，測試就可以不用測了
正正是第三點賦予了ui自動化測試錯誤的價值。讓UI自動化測試驗證UI, 利用圖片比較去做自動驗證，甚至利用截圖定位按鈕。真是找死的節(jié)奏呀。 現(xiàn)在我?guī)Т蠹艺J識下它的真正價值。
1. 驗證邏輯而非UI
UI的驗證會引入大量的不穩(wěn)定因素。換句話說，像當年的測試大牛段念說的，你跑過了UI自動化，你就相信沒問題了嗎？不會相信，原因是啥？因為聰明的你會發(fā)現(xiàn)，你驗證的東西越多，例如界面的每個按鈕，顏色，排布，互聯(lián)網(wǎng)應用變化最大的就是UI, 你的用例就越不穩(wěn)定，所以你最終肯定不會驗證全部UI。那結(jié)果就是"然并卵"了, 你根本不會相信這個用例真的通過了。因此給大家定個UI自動化能做的，驗證邏輯（另外一種說法，說這種叫功能自動化）。什么叫驗證邏輯？例如驗證qq是否登錄成功，驗證到了好友列表，就是登錄成功，甚至有登錄成功的日志都可以，怎么穩(wěn)定怎么行。
2.代替大量的UI重復操作
簡單來說就是UI自動化你要投入5元，只是執(zhí)行4次，每次賺5毛的話，那你還虧3元的問題。什么時候會大量呢？像手Q, 編譯百個市場的包，每個包要驗證核心功能?；蛘呦裥阅躸i自動化監(jiān)控，同一個用例為了多次采樣，也會執(zhí)行多次。還有每日構(gòu)建，集成，都可以。關鍵點就是用次數(shù)來增加價值，UI自動化能幫你確保不出死人的問題，如登錄不了，登錄了又卡死，或者是監(jiān)控UI之外的其他，如性能。這些都有機會讓其價值高于成本的。
*最大難點，維護
無間道: 出來混，遲早要還的。 這句話，最好用來說明，為什么自動化測試構(gòu)造得越快越隨便，未來的維護成本也就越大。更甚者，腳本依賴錄制得來的，也是找死的節(jié)奏。 無數(shù)的故事告訴我，很多UI自動化都是死在一開始就寫或者錄一堆腳本，結(jié)果每天都要花大量時間排查錯誤，錯誤有腳本錯誤，有功能的變更，有bug，甚至問題是隨機出現(xiàn)的，但是無論你的問題或者是功能的問題，反正你排查錯誤的時間是花進去了，哪怕你不用改腳本。所以這里看來，
要解決維護的難點，終極招數(shù)就是不要碰UI自動化。其實很多大牛都是說不要做ui自動化的，或者這個事情不是最高優(yōu)先級，但是現(xiàn)實是，大家都做了，優(yōu)先級還不低。所以我當然不說不做了，要做就只能要狠狠地干一場，要成功，不要失敗。下面給大家有兩點建議，一是策略，二是技術。
策略上，維護成本的控制，腳本要慢慢上，先做核心的BVT，人均維護的腳本1~2個，定目標，如穩(wěn)定運營1個月，后面增加的腳本要在測試環(huán)境穩(wěn)定跑上一周，才能切換到正式環(huán)境。 組織培訓，知識分享，分享寫自動化遇到的坑，沉淀最佳的實踐，讓大家知道寫UI自動化也是在自我提升，而不是簡單的工作任務。
技術上，降低維護成本的方法，
1.腳本里不要有坐標，圖像識別這些，想都別想，想都別想，想都別想！這些都是不穩(wěn)定的因素。
2.腳本里不要有sleep。sleep就是UI自動化的穩(wěn)定性的克星，絕對不能有。一方面，如果幫助建立或者直接使用UI自動化測試等待界面穩(wěn)定的阻塞方法，例如waitForIdle，等待控件出現(xiàn)和消失的方法，如waitForInvisiable之類的。另外一種，就是封裝一個timeout的類，里面包含重試和sleep的策略，讓腳本直接使用。反正，不要看到sleep。
3.要用腳本要基于面向?qū)ο?/b>。腳本不需要編譯，調(diào)試方便，學習門檻低，像python，能使用的庫也豐富。所以自動化測試最佳的使用Python，再配合pydev，用起來還是很舒服的。而說到面向?qū)ο?，它有個作用，就是通過隔離變化來提升代碼的可維護性。說多了，可能你都不明白， 我舉個例子來說說, 用了面向?qū)ο蟮腢I自動化腳本的樣子(python的哈）。
qqApp = Application("QQ")
loginPanel = qqApp.launch()
buddylistPanel = loginPanel.login("27373636","ffssdd")
aioPanel = buddylistPanel.findAndOpenAIO("28282828")
aioPanel.sendMsg("hi")
好，這個偽腳本，有什么特點呢？對，沒有見到控件。控件要封裝到界面類里面。具體一下說，自動化腳本的隔離變化基本上可以分四個層次，
a. 用例邏輯，通常有個用于繼承的TestCaseBase， 用來封裝用例的邏輯，類似teardown, setup，run之類。
b. 業(yè)務邏輯，通常就是繼承TestCaseBase，用例實現(xiàn)的本身。封裝業(yè)務邏輯的變化。c. 界面邏輯，通常就是界面類，例如上面的LoginPanel。隔離了控件與業(yè)務邏輯，讓控件位置，ID的變化，可以控制在界面類中。
d. 控件驅(qū)動，通常就是基本的獲取控件樹，檢索控件。封裝控件獲取方式。
3.控件定位要用類似XPath的方式。這種方式的好處就是方便閱讀，把復雜的位置描述封裝到一條短短的字符串里面了。（有寫朋友誤會了，是XPATH, 是類似XPATH的東西，但是要把他比較復雜的部分去掉，只支持屬性，節(jié)點的簡單定位就行。不然跟正則表達式一樣，又是一對學習成本了）
4.通過分Step的腳本化繁為簡。UI自動化腳本都有個特色。長～！一個腳本通常我們希望驗證好幾點，登錄，打開聊天窗口就不容易了，因此除了驗證發(fā)消息，我們還希望可以發(fā)圖，發(fā)表情，那么這個時候，最好可以把用例分割成幾個Step。出了問題，就集中排查某個Step的日志就OK了。補充一下， 大家肯定想個一個問題，每個用例都要獨立的，要互不影響，重新登錄，為了穩(wěn)定，多補點時間我不在意，但是現(xiàn)實你有發(fā)現(xiàn)這些時間會增加用例出錯之后的修復，驗證的時間成本。所以“分Step”無疑意思是給大家一個合并用例來提升用例執(zhí)行速度，但是又不影響用例與用例之間的獨立性。
5.不要再給UI操作/驗證本身壓力了。例如輸入文本這些操作，也沒有必要用鍵盤事件來觸發(fā)，如果你是注入方式的，獲取到控件對象，直接setText吧，這樣會穩(wěn)定很多。還有端到端的UI自動化，如QQ發(fā)消息到另外一端的QQ的測試，我們就可以利用網(wǎng)絡協(xié)議，發(fā)送消息，另外一端用UI驗證接收消息。
6.定時重啟手機和，出錯的用例再跑一次，可能會幫助回避一些問題，可以做。但是不能以此來麻木自己對錯誤的敏感的感覺。
7. 穩(wěn)定你的環(huán)境，這些環(huán)境包括網(wǎng)絡，系統(tǒng)，賬號資源，電腦/手機。
a. 網(wǎng)絡, 假如我們的UI自動化是驗證功能邏輯的，那網(wǎng)絡就一定要被牢牢地控制，獨立的路由器，并且監(jiān)控著網(wǎng)絡情況，如果存在嚴重的丟包和斷連，這信息一定要及時同步出來，甚至可以自動控制你的用例，在網(wǎng)絡差時暫停，網(wǎng)絡回復后再跑。
b. 系統(tǒng), 系統(tǒng)經(jīng)常有各種更新的彈窗，特別是IOS。利用網(wǎng)絡，屏蔽這些無用的推送把。android則是找個穩(wěn)定的ROM。
c. 賬號資源，有很多軟件賬號資源都是不能重用的，或者重用了之后，用例之間會相互影響。這里需要有賬號資源池的概念，類似SVN, 通過CGI, 來取了資源，可以加鎖，還回去，再解鎖。
d. 手機與電腦，肯定不能長時間運行，不然他們也會發(fā)脾氣。所以定期重啟手機和電腦，似乎是必不可少的一步。
*UI自動化測試的未來
有很多人問, UI自動化應不應該投入，有沒有前途。這個問題沒有絕對的，要看項目的類型，像做Android手機的，因為項目相對來說比較穩(wěn)定，CTS本身就有一定的用例量，幾千個UI自動化測試，都能維護過來，而且通過率極高。做前端應用的，像我們PC QQ，開發(fā)在控件唯一標識的問題上，給予了不少支持，因此用例的量和穩(wěn)定性也是非常高。說虛一點的，如果這個事情至上而下都是支持的，想做的，投入的方向沒有錯，價值認識正確，肯定是有積極的產(chǎn)出的。另外，UI自動化是測試生來無法回避的一種能力，可以不依賴他，但是你需要他。
下面我們來開開腦洞，大家有木有想過用例可以生成，生成用例自動化：
最簡單的用例生成就是基于數(shù)據(jù)驅(qū)動的自動化測試，生成基于不同的數(shù)據(jù)輸入的用例。當然，用例的邏輯肯定要是一致的，就如QQ的狀態(tài)變更能力，用例用選擇輸入不同的狀態(tài)變更，如離線，繁忙，在線等等，最后檢查狀態(tài)欄的情況。如果輸入之間有排列組合的關系，則可以利用pairwise來減少用例的個數(shù)，但是保持一定的覆蓋率。
另外一種用例生成，則是用例邏輯的自動生成，想想，只要定義好每個Action在不同狀態(tài)下切換到的新狀態(tài)，狀態(tài)機算法就幫助我們生成一系列的用例。這個技術叫MBT, Model Base Testing?，F(xiàn)在各種語言都有Model Base Testing的庫，跟UI自動化結(jié)合起來就可以了。python的就例如pyModel。但是為什么這么好的東西一直沒有做起來呢? 1. 入門稍微困難了一點，需要理解一下狀態(tài)機本身的算法。這個對測試本身的素質(zhì)要求更高 2. 如果說UI自動化測試的維護大部分在于排錯，那么基于MBT的自動化，則排錯更加困難了。原因是什么呢？因為腳本邏輯是生成的，所以對于依賴固定邏輯的Assert會變得非常復雜，但是也不是不可行。況且，退一步說，驗證CRASH這種簡單的Assert是沒有問題的。只要能把排查錯誤的能力在普通UI自動化測試下做到極致，排查時間能夠控制在幾分鐘之內(nèi)，那么結(jié)合MBT當然也就不是夢想了。另外，最能證實可行性的證據(jù)，應該就是“即時戰(zhàn)略”游戲里面的電腦，他們就是狀態(tài)機編程的結(jié)果，比一個應用復雜得多，都尚且能無差無錯的完成。
再開個腦洞，前面說的UI自動化都是長長的用例，所以才有了分Step。但是這些UI自動化測試的用例有沒有可能變短，例如我們測試QQ聊天，我們不需要在界面上登陸，我們直接打開就是聊天窗口，甚至里面各種類型的消息都準備好了。要做到這不需要什么，只需要一點，“解耦”，聊天窗口跟別的類的關聯(lián)是清晰的，簡單的。如果能，例如在android，用接口測試操作，獲取QQ聊天窗口必須的SKEY等等資源，然后繞過登陸，搜索好友這些步驟，直接起來QQ聊天界面， 簡單，快捷，穩(wěn)定?？上Ы怦畈皇情_發(fā)天然做到的，需要逼， 國外用來逼的方式就是UnitTest，國內(nèi)呢？
總結(jié)
UI自動化是一種能力，常常無法回避。
UI自動化會給人幻覺，要看清現(xiàn)實與價值。
UI自動化最適合一句話，喜歡是放肆，愛是克制。而克制是UI自動化能發(fā)揮作用的關鍵。
