狠狠地聊一下UI自動化測試(2)

3.要用腳本要基于面向對象。腳本不需要編譯，調試方便，學習門檻低，像python，能使用的庫也豐富。所以自動化測試最佳的使用Python，再配合pydev，用起來還是很舒服的。而說到面向對象，它有個作用，就是通過隔離變化來提升代碼的可維護性。說多了，可能你都不明白， 我舉個例子來說說, 用了面向對象的UI自動化腳本的樣子(python的哈）。

qqApp = Application("QQ")

loginPanel = qqApp.launch()

buddylistPanel = loginPanel.login("27373636","ffssdd")

aioPanel = buddylistPanel.findAndOpenAIO("28282828")

aioPanel.sendMsg("hi")

好，這個偽腳本，有什么特點呢？對，沒有見到控件?？丶庋b到界面類里面。具體一下說，自動化腳本的隔離變化基本上可以分四個層次，

a. 用例邏輯，通常有個用于繼承的TestCaseBase， 用來封裝用例的邏輯，類似teardown, setup，run之類。

b. 業務邏輯，通常就是繼承TestCaseBase，用例實現的本身。封裝業務邏輯的變化。c. 界面邏輯，通常就是界面類，例如上面的LoginPanel。隔離了控件與業務邏輯，讓控件位置，ID的變化，可以控制在界面類中。

d. 控件驅動，通常就是基本的獲取控件樹，檢索控件。封裝控件獲取方式。

3.控件定位要用類似XPath的方式。這種方式的好處就是方便閱讀，把復雜的位置描述封裝到一條短短的字符串里面了。（有寫朋友誤會了，是XPATH, 是類似XPATH的東西，但是要把他比較復雜的部分去掉，只支持屬性，節點的簡單定位就行。不然跟正則表達式一樣，又是一對學習成本了）

4.通過分Step的腳本化繁為簡。UI自動化腳本都有個特色。長～！一個腳本通常我們希望驗證好幾點，登錄，打開聊天窗口就不容易了，因此除了驗證發消息，我們還希望可以發圖，發表情，那么這個時候，最好可以把用例分割成幾個Step。出了問題，就集中排查某個Step的日志就OK了。補充一下， 大家肯定想個一個問題，每個用例都要獨立的，要互不影響，重新登錄，為了穩定，多補點時間我不在意，但是現實你有發現這些時間會增加用例出錯之后的修復，驗證的時間成本。所以“分Step”無疑意思是給大家一個合并用例來提升用例執行速度，但是又不影響用例與用例之間的獨立性。

5.不要再給UI操作/驗證本身壓力了。例如輸入文本這些操作，也沒有必要用鍵盤事件來觸發，如果你是注入方式的，獲取到控件對象，直接setText吧，這樣會穩定很多。還有端到端的UI自動化，如QQ發消息到另外一端的QQ的測試，我們就可以利用網絡協議，發送消息，另外一端用UI驗證接收消息。

6.定時重啟手機和，出錯的用例再跑一次，可能會幫助回避一些問題，可以做。但是不能以此來麻木自己對錯誤的敏感的感覺。

7. 穩定你的環境，這些環境包括網絡，系統，賬號資源，電腦/手機。

a. 網絡,假如我們的UI自動化是驗證功能邏輯的，那網絡就一定要被牢牢地控制，獨立的路由器，并且監控著網絡情況，如果存在嚴重的丟包和斷連，這信息一定要及時同步出來，甚至可以自動控制你的用例，在網絡差時暫停，網絡回復后再跑。

b. 系統,系統經常有各種更新的彈窗，特別是IOS。利用網絡，屏蔽這些無用的推送把。android則是找個穩定的ROM。

c. 賬號資源，有很多軟件賬號資源都是不能重用的，或者重用了之后，用例之間會相互影響。這里需要有賬號資源池的概念，類似SVN, 通過CGI, 來取了資源，可以加鎖，還回去，再解鎖。

d. 手機與電腦，肯定不能長時間運行，不然他們也會發脾氣。所以定期重啟手機和電腦，似乎是必不可少的一步。

*UI自動化測試的未來

有很多人問, UI自動化應不應該投入，有沒有前途。這個問題沒有絕對的，要看項目的類型，像做Android手機的，因為項目相對來說比較穩定，CTS本身就有一定的用例量，幾千個UI自動化測試，都能維護過來，而且通過率極高。做前端應用的，像我們PC QQ，開發在控件唯一標識的問題上，給予了不少支持，因此用例的量和穩定性也是非常高。說虛一點的，如果這個事情至上而下都是支持的，想做的，投入的方向沒有錯，價值認識正確，肯定是有積極的產出的。另外，UI自動化是測試生來無法回避的一種能力，可以不依賴他，但是你需要他。

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