[淺談 ui 自動化專案的個人套路]

這幾天作者接手了一個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點，歡迎小夥伴們補充和討論哦～
最後，轉載請註明出處。歡迎分享～

轉載至：https://mp.weixin.qq.com/s?__biz=MzA3NTc4Njk1NQ==&mid=2247484080&idx=1&sn=02eccd46c83cfd5d754648049f2b88fa&chksm=9f6a7d14a81df402dc107e3cdfe873f74ceb69351205b6518f27f2b2ed2adf01878081c8b1a7&token=1187973523&lang=zh_CN#rd