這幾天作者接手了一個ui自動化項目，原來的負責人離職了。
我就臨危受命交接了過來。本來應該交接給另一個女孩，結果她看了倆眼後果斷拒絕接手。
我爲了不讓ui自動化這個端直接廢掉，就乾脆一咬牙，答應接手。等到我們實際用了半小時交接後，我做了個決定。我決定等負責人離開了，我就刪除他的項目代碼，格式化電腦，然後關機。。。
這之後。我用了大概7天時間，重做了整個這個移動端的ui自動化 包括我們app的全量用例。代碼行直逼1w+。。。
以下是我這7天工作內容：
第一天：找一個合適的服務器，要性能極好，抗燥，長時間不關機。乾淨的環境(沒找到，手動清理了一頓)。找一個可以長期運行腳本的手機，並且不太卡。然後作出設計，我要弄個好交接，好維護，好理解，好操作的ui自動化測試平臺。
第二天：搭建appium+pythoon環境，研究在windows（第一天只找到一臺符合條件的windows）上如何能自動每次中斷/重lanuch appium的命令。並使得appium腳本可以成功運行在真機上，然後在配置django+python的環境。跑起一個django服務，能成功打開第一個空白頁面爲止。
第三天：搭建這個django 平臺，一個大頁面就好。要有菜單欄，工具欄，用例列表，監控設置，用例運行測試報告 等等。主要技術：django+python+appium+reuqest+sql/rom+unittest+linuxshell+htmltestrunner+html/css+js/jquery+bootstrap3+… 菜單欄開發：進入後臺，用例的增刪改查和關聯實際腳本.py ，執行全部用例+全部用例結果統計 ，執行核心用例+核心用例結果統計。
第四天：搭建好平臺後，測試啓動第一個腳本，運行成功。測試監控輪詢子線程執行成功。開發小工具（正所謂磨刀不誤砍柴工）：如重啓adb服務，殺死appium，一鍵登陸某身份賬號 等。這些小工具在我之後寫具體用例腳本的時候會很常用。（比如：執行的時候手機鍵盤會被appium屏蔽，我要是手動要登陸某個賬號查看/調試一些特定數據的時候，還需要每次去設置裏面修改輸入法，用這個點一下就自動登陸那幾個賬號了（因app的用戶身份不同，所以準備了三個賬號））
第五天：開始寫第一個模塊的用例，很多，很繁瑣。也思考了很多。所以大筆時間用來寫一些絕對可靠的 公用函數了。如：屏幕上滑/下滑 正好一個頁面，
確保某身份制定賬號的確保登陸函數，退出函數，無限返回到首頁的函數，快速清空輸入框函數，快速adb輸入文字函數，自動定位函數(針對id/class不唯一，只能通過text定位的元素)，自動斷言元素應該存在或不應該存在函數，最符合本app和該手機風格性能的智能等待，等等等等呢。
這些函數可以確保我少寫代碼的同時，還能確保用例的穩定性。
第六天：寫用例，優化公共函數
第七天：寫用例。
在這個過程中，我說我思考了很多事情，關於ui自動化的。到底都要注意一些什麼呢？或者說相對於我第一次會寫ui自動化腳本的時候，我現在會多思考哪些事呢？畢竟自己也是平時給人培訓過自動化的講師。不可能出手跟新人一樣，那就太沒排面了。
到底要不要採取page-object模式：這個設計模式，是主要用來後續維護方便的，但是如果功力不夠，爲了使用而使用，那麼就會造成，我在用例邏輯腳本中完全看不懂這些代碼是幹什麼的，我還需要打開元素維護的腳本，一個一個去搜，這中間把你的思緒撕扯到零碎，理論上來說，元素定位發生變更後，我們只需要去維護元素定位模塊。邏輯發生變更後，我們只需要維護邏輯腳本。看起來省了很多時間。但是實際情況更多是同時變更，我們要同時去修改元素定位，和元素操作邏輯順序等。這樣你就需要維護倆個模塊的腳本，你的思維很難去整合在一起，非常費心。
數據分離/驅動：千萬不要爲了數據分離就去分離數據。本來你的數據都是很死的，比如用戶名，你整個腳本中也就使用幾次，那麼你的這個用戶名，你還要單獨去弄個csv/excel/sql去存放麼？然後每次用的時候從這裏調取？這樣無疑增加了執行時間，也增大了腳本出錯的概率。最主要的是，以後交接或者自己維護的時候，看到腳本這裏，心想這裏寫的是什麼東西，具體是哪個賬號呢？還要趕緊去打開excel表查了半天，哦，原來這裏斷言的字符串是這個啊。。。。我的結論就是，需要大量數據驗證的/重複使用多次的用例具體字符串，纔可以去做數據分離。還有不要驗證太多的寫死的數據，要學會動態獲取並驗證。比如：我登陸這個用戶叫王大錘，然後我把王大錘寫在csv文件裏。然後我要去測試在另一個頁面斷言，這個用戶名能不能顯示正確。每次都去調用這個文件。如果有一天這個賬號換了呢？你還要改這個王大錘三個字。所以更好的辦法是動態獲取和驗證，就是我在登陸的時候獲取這個賬號的用戶名，然後存在緩存（unittest可以用類名.變量名來記錄數據），然後之後用例去緩存取這個用戶名做斷言。不要小看這一個字符串。當你的用例幾十幾百處這種斷言的時候，不動態獲取數據那後續維護你會想死的。最怕過些日子你自己都不知道這個字符串是啥意思了（比如在csv文件看到一行：ABcdqwije12 ,你也不知道這是啥，但現在賬號換了，我要把新賬號的數據更新到這csv裏。但是這行是什麼來着？暱稱？id？完全不記得。。。還是去研究代碼腳本推斷出來吧。）跟前面第1條說的類似，大道至簡，凡事都有雙面性，找到一條最適合的適用場景來使用纔是王道。不要一味的爲了炫技加入太多的各種設計 思路 框架。
3.用例的分段：可能大家都會苦惱這個，流程就是這一大堆步驟，我放在一個用例也可以，分成10個小用例也行。那到底怎麼分纔是最好的呢？
我在這裏給出建議：按照你手工寫用例的基本思想，每條用例只注重一個測試點，不然包含的功能太多，用例失敗你都不知道後續測試點是否成功。每條小用例千萬別包含太多代碼，不然一個錯，後面都不執行了。而且分的多，你領導看着也好，知道你寫了好幾百條用例的辛苦。
4.用例的斷言：unittest框架中，若是你用例如test_001斷言失敗了，那麼這條方法裏後面的語句可就都不執行了。後面大多數人會寫成返回頁面/還原數據 等操作，來給下一條用例創造環境。但是如果這條斷言失敗，那麼後面不執行，下一條用例沒有一個正確的環境，所以也會失敗，這就是誤報失敗了。到時候你看着密密麻麻的爆紅結果，腦子也疼吧，雖然可能僅僅是第一條報錯/失敗 的用例的問題，後面用例其實都是好的。。。所以這種還原操作，儘量放在下一條用例中，以便杜絕前一條失敗帶來的風險，當然不是絕對。
5.unittest框架中的setup 一定要用好。也就是說，根據高內聚，低耦合 原則。用例和用例之間一定不要有太多的 聯繫。我喜歡根據不同模塊 分成大用例，大用例內 不同小功能 分成小用例，小用例直接可以有關聯。也可以沒有。大用例之間 必須毫無關聯。確保我執行順序混亂都可互不影響。所以在大用例執行之前，最好乾掉appium，然後重新啓動appium服務。
6.斷言：這是一個非常頭疼的事。斷言詳細了。你後續維護會累死，斷言太簡單了。那腳本失去了價值。所以斷言我覺得一定要是非常非常智能的。各種ai測試，大數據測試，智能匹配 模糊匹配 ，圖片相似度 等算法，都可以在斷言上放光發熱。我這邊運用了許多黑科技，包括自動維護，智能斷言等，當然名字也不貼切。您要是有興趣，歡迎找我討論或關注我博客，可以點擊下方菜單：聯繫作者。
7.代碼註釋：我別的不說了。我所有用例代碼，每一行，全都後面寫着中文註釋，點了什麼，斷言什麼。必須全部寫清楚。不然你怎麼之後交接給別人，怎麼應對頻繁的ui變化維護腳本。這個習慣可是個好習慣。不要以爲這個註釋太簡單，沒什麼用。定位某個元素並點擊的代碼多簡單，誰會看不懂呢？當然單個拿出來都能看懂，但是具體點了什麼 ，誰知道？一大堆放在一起，這是啥？寫了漢字註釋後，針對後續複雜的變更和邏輯，你大腦也可以快速思考並作出調整。而不至於增加無謂的理解成本。
8.項目結構：任何新建一個包/層級，都是要經過深思熟慮的，千萬不要圖爽隨便去弄，看着層級很多就牛逼麼？東一個配置文件，西一個腳本的，南一個封裝，北一個包的。 仔細一看，到處都發現其實不分這麼多包 和層級，可以更好的理解和維護。那這種複雜到沒法看的項目結構叫什麼？我們稱之爲：屎山～ 沒人敢隨便改什麼，誰知道會出什麼問題？
9.支撐服務：你一個自動化ui項目，目的就是爲了節省時間，如果支撐服務過多，那麼風險就會增大，穩定性就會降低。也就更加需要我們花費時間在大量的支撐服務上。（比如就一個輪詢腳本，每小時執行一次，你至於要本地搭建一套jeknins節點，然後去主jenkins站上次次下載文件，然後鏈接，然後設置項目等一大堆操作，最終只爲了在上面可以定時發送命令過來執行腳本。）我不建議這種做法，任何做法都需要有理由，有利也有弊，都是需要進行討論和分析的，而不是單純的摻雜越多就越好。
10.一個優秀的自動化項目，一定要是好交接給其他人，可以容易的讓多人協作開發的。所以，你要有良好的易學性，易理解性，易分析型，易測試性，可移植性等等等等，具體的可以參考iso9126質量體系，我的文章中也有專門講解過這個。不能只會讀，自己開發的時候也要用上才行啊。
好了，暫時就想到這10點，歡迎小夥伴們補充和討論哦～
最後，轉載請註明出處。歡迎分享～
vx公衆號：【測試開發乾貨】帶給你不一樣的技術體驗～