摘要：在我有限的軟體測驗經歷里，曾有一段專職的自動化測驗經歷，
接觸自動化
那時第一次上手自動化測驗，團隊里用的是Python，介面自動化測驗的框架是requests+Excel+Jenkins，APP自動化測驗的框架是Appium，
整個公司當時有一款已有的APP，因此在試用期內，我的任務是完成對已有APP的自動化腳本撰寫和除錯，
記得當時剛開始去，很沒有經驗，在跟功能測驗同學了解了業務之后，只顧埋著頭部署環境，突然有一天，測驗主管問我，是否要輸出一份自動化測驗用例，我恍然大悟，于是把功能測驗的用例拿來參考了一下，對用例做了一次篩選，輸出了一份自動化測驗用例（現在回過頭看，當時的做法真的很草率，既沒有一個自動化測驗計劃，也沒有對自動化用例做評審，只知道功能測驗同學的痛點就是迭代太快，回歸來不及做），
用例輸出后，大概花了一個月的時間，完成了環境部署和基本用例腳本的撰寫，那時候大概實作了四五十個場景，并且完成了自動發送測驗報告，剩下的兩個月，我就一步一步的將場景擴充為二百多個，
其間也遇到了一些問題，比如登錄圖形驗證碼的獲取，不過使用OCR圖形識別很快就得到了解決，同事也有使用云打碼一類的平臺，
最大的一個問題是，當APP版本更新迭代后，固定頁面所有的id、class等屬性都會變化，因為這些都是寫死在代碼里的，如果要更改意味著每個page都要更改，作業量非常之大，而且獲取這些屬性還需要借助一些工具，如UI AuTomatorviewer 、Appium自帶的Inspector，
在忙碌了一段時間后，先找到一個安卓開發，跟他排查了一下，他也找不到問題所在，后面又找了另一個開發，他排查之后發現是安卓混淆打包的問題，他給我出了一個不做混淆打包的APP，這才解決了這一問題，
另外一個比較大的問題是，APP自動化測驗的運行時間非常久，我們兩三百條用例，如果加上失敗重試，大概要跑四五個小時，而且還會出現中間腳本出錯運行停止的問題，
記得一個印象比較深的事情是，我們第二天要發版了，頭一天下班前我開始跑腳本，等到晚上我一直沒有收到測驗報告的郵件，于是晚上十點多趕回公司，發現自動化腳本已經停止了，
對于時間久的問題，后面我嘗試引入UI AuTomator2（以下簡稱u2）框架來代替Appium，毋庸置疑，u2在執行速度上有很大優勢，
我曾經對比過這兩個框架，同一個場景，Appium需要耗時60多秒的，u2只需要20多秒，足足節省了三分之二的時間，
但隨之而來新的問題是，u2不太穩定，Appium中查找元素有用到顯式等待、隱式等待和強制等待，而u2中看似不需要這些，實際上多跑幾遍場景就會發現u2執行太快會找不到元素，因此還得手動加上強制等待，這樣一來時間并沒有節省多少，
這個問題當時沒有得到解決，反而是在我離職后的一段時間里，通過學習pytest-xdist的檔案，發現pytest-xdist可以基于ssh和socket來實作分布式執行，
舉個例子，假如有200條場景，同時啟動2個執行機，那么就會往執行機-1上推送100個場景，往執行機-2上推送另外100個場景，最終兩個執行機的測驗報告會集成為一個報告，這樣的解決方案如果當時能應用到實踐中，那么APP自動化測驗時間過長的問題會得到完美解決，唯一需要注意的是，每個場景要獨立，不能相互依賴，
話說回來，APP自動化測驗做下來好像沒有產生多少收益，因為只有我一個人開發和維護，所以到了維護階段就顯得耗時耗力，特別是本來一個固定的頁面改了或者中間插入了一套新的邏輯，就意味著相當多的頁面需要調整，
第二次接觸專案
差不多這樣做了幾個月后，公司開始立新的專案，新的專案一開始就下決心要做介面測驗，因此我又介入到這個專案中，參加立項會議、參加技術評審，了解了要做哪些，并且介面檔案怎么管理，介面怎么定義等等之后，就開始了新專案的介面測驗，
那個階段，使用requests讀取Excel的方式在介面不多的時候還挺方便，因為代碼框架比較固定，只需要Excel里修改引數，
但隨著介面越來越多，也意味著介面之間的依賴越來越多，Excel管理簡直就是災難，在Excel里要理清不同介面的依賴關系，是非常頭痛的一件事，
后來我使用Postman做了一些快速測驗，等待時間充裕的時候，再慢慢把整個主流程的介面測驗加上，在介面測驗階段，前前后后發現了一些問題，但很大的不足是沒有解決Excel存盤資料的問題和沒有做資料正確性的校驗，
而且我們還是和支付相關的業務，這使得介面測驗結果只能保證服務是正常的，回傳碼是正常的，但是資料是否正確無從得知，
直到后來，自動化團隊換了一批人，新來的同事開始推行Java堆疊，使用Springboot+httpclient+Maven來作為介面自動化框架，基本舍棄了之前的Python自動化腳本，
那幾個月好幾位同事投入到同一個專案的介面自動化腳本的撰寫中，對比之前我一個人負責兩個專案的自動化，情況的確好了很多，
這個自動化也是基于場景的，有做正常和例外輸入的校驗，以及最后的入庫檢查，腳本量非常大，所有例外場景的請求資料和期望結果都是入庫的，后續請求的時候，先從資料庫拿到請求資料發送請求，得到回應結果再和資料庫的期望結果做比較，正常場景需要手動寫邏輯，回應結果里重要欄位的值和資料庫里的值做比較，
那個時候，考慮了很多前端無法測到的復雜的場景，并發、冪等之類的，因此發現的缺陷更有意義一點，但是維護成本依然比較高，
自動化是什么？
最近的一兩年，我有時會想到自動化測驗是什么？自動化測驗本來是為提高測驗效率而生，有時候使用不得當，卻成為測驗活動中的累贅，
但不可否認的是，自動化測驗仍然是行之有效的，區別只是使用的動機和使用的方式，在我看來，做好自動化測驗需要規避以下幾點：
不要為了自動化為自動化
自動化測驗不能基于KPI，而要看當前的專案適不適合做自動化，有沒有足夠資源的投入和外部團隊的配合，
自動化不是萬能的
不要貪多求全，妄想所有的測驗場景都能通過自動化實作，尤其是更新迭代快的專案，能把穩定的功能實作，并且做好回歸 ，已經足夠了，
自動化的場景
一種是基本場景，另一種可以是前端無法實作的場景，
而對于介面中無窮無盡的欄位進行嚴苛的例外校驗，來保證足夠程式足夠健壯，有時候反而沒有那么必要，
因為開發周期短的公司一周好幾個版本，開發根本就沒時間對一些不太重要的欄位做例外處理，當然重要欄位的型別、長度、非空校驗等還是要做，
對自動化的認知
有些同行認為，自動化就是為了發現缺陷的，但是自動化發現的缺陷根本比不上功能測驗，發現不了缺陷的自動化就沒有意義嗎？
事實并非如此，尤其是一些回歸測驗的自動化，一方面是為了提高效率，一方面是為了增強上線前團隊的信心，
團隊人才的培養
遇到了一些公司，好不容易做起了自動化，做得也不錯，等到負責人離職之后，就沒人維護了，然后再招一些自動化測驗人員另起爐灶，反反復復，歸根結底是沒有人做技術備份，
最后：這里有我建立的一個專門交流軟體測驗方面問題的學習群，里面也有很多大公司的技術大牛，很多時候，技術大牛的幾句話就會讓我們醍醐灌頂，少浪費時間，如果想要多跟有經驗的人學習，就找我加入我的軟體測驗交流群，以后有作業的內推機會都相互推薦一下，畢竟我們是關系社會，
軟體測驗技術交流群社：786229024 等待你的加入... 大家可以一起探討交流，共同學習軟體測驗技術、面試等軟體測驗方方面面，還會有免費直播課，識訓更多測驗技巧，我們一起進階Python自動化測驗/測驗開發，走向高薪之路，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/552526.html
標籤：其他
上一篇：原來如此！如何去開發一款直播軟體app平臺？直播原始碼技術直播互動篇
下一篇：返回列表