小心！做 UI 彩38源碼自動化一定要跨過這些坑
填掉這三類坑，基本上就獲得了一套低成本高產出、少量維護、穩定可靠的UI自動化用例集。
三、 設計類問題分析與解決
“才剛寫完用例，怎麽開發大哥又改了UI了？”
“測試框架自己有bug，我改用例也沒用啊……”
這類問題，我們需要從根上治。UI自動化開發，也應該是嚴謹的開發工作，它也需要設計模式，也是磨刀不誤砍柴工。這裏的設計，主要包括選工具、框架分層等。很多前輩都分析過UI自動化各類工具的優缺點，對工具選用筆者不再贅述。主要依托uiautomator來介紹下筆者認為比較巧妙的用例框架設計。
1 優化測試代碼框架
圖二uiautomator和espresso邏輯樣例
問題在哪裏？這些sample過於簡單，都只教了我們UI自動化三元素：怎麽查找元素、怎麽操作元素、怎麽校驗結果。如果我們按照大多數分享帖或GitHub sample來寫作自己的case。最後這種沒有任何設計模式的框架，肯定會面臨重構。拿上面的espresso來說：
假如action_save這個id開發改了，而你的用例集中，有30個步驟用例到了這個id，一個個去改，是不是要瘋？
不厭其煩的重復寫onView(withXX(xxx)).perform(click())這一長串，你不煩？
圖三 框架設計建議
按照圖三進行分層設計後，得到如圖四的測試代碼包。
測試同行面前一提起自動化，大家就會自然而然的問：“恩，你們是用的什麽框架？appium？還是robotium？”
其實在筆者看來，UI自動化是一個ROI較低的測試項（ROI即return on investment，中文意思是投資回報率）。但UI自動化相比接口自動化、白盒測試等，它更貼近手工業務測試行為。對於剛起步測試左移、效率提升的團隊來說，是最迅速的切入點，也是廣大黑盒tester，提升自身技術能力的起跑線。
筆者接觸UI自動化一年多，兼顧業務測試的同時斷斷續續地投入，曾經無數次的想放棄：
“才剛寫完用例，怎麽開發大哥又改了UI了？”
“維護這些破用例的時間，都夠我手工測三遍了，真的有意義麽？”
“測試框架自己有bug，我改用例也沒用啊……”
“我調試的時候這個用例還是通的，放到daily裏面跑就不通，到底怎麽回事嘛！”
“adb怎麽這麽不穩定啊，老是斷！！！”
“怎麽跑著跑著就crash了，到底是被測應用有問題，還是測試代碼有問題啊？”
“明明界面上有這個元素，怎麽就是查不到呢？”
“這破手機，能不能別老是系統彈框……”
“這手機真是渣，adb screencap截個圖，居然要三分鐘才返回！”
“這些控件都沒有id，沒有text，層級還三天兩頭改，要我怎麽查……”
“查了這麽多論壇，怎麽就沒有人遇到過類似的問題呢？”
……
這些問題讓筆者一度懷疑，UI自動化這個TOPIC，是不是根本沒用，只是tester為了漲薪，或者為了擺脫重復無聊的手工業務測試，而YY出來自我欺騙的。
二、 問題分類及目標明確
筆者將以上所有的問題簡單分成三類：設計類，環境類，細節類。一個好的設計模式，能夠避免一部分問題；一套好的環境，可以讓我們從乏味的維護工作中解脫；精益求精的細節，讓測試用例更加可靠穩定。
小心！做 UI 彩38源碼自動化一定要跨過這些坑