在我有限的軟體測試經歷裡，一段專職的自動化測試經驗總結

摘要：在我有限的軟體測試經歷裡，曾有一段專職的自動化測試經歷。 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

那時第一次上手自動化測試，團隊裡用的是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，而要看當前的專案適不適合做自動化，有沒有足夠資源的投入和外部團隊的配合。

自動化不是萬能的

不要貪多求全，妄想所有的測試場景都能透過自動化實現，尤其是更新迭代快的專案。能把穩定的功能實現，並且做好迴歸 ，已經足夠了。

自動化的場景

一種是基本場景，另一種可以是前端無法實現的場景。

而對於介面中無窮無盡的欄位進行嚴苛的異常校驗，來保證足夠程式足夠健壯，有時候反而沒有那麼必要。

因為開發週期短的公司一週好幾個版本，開發根本就沒時間對一些不太重要的欄位做異常處理，當然重要欄位的型別、長度、非空校驗等還是要做。

對自動化的認知

有些同行認為，自動化就是為了發現缺陷的，但是自動化發現的缺陷根本比不上功能測試，發現不了缺陷的自動化就沒有意義嗎？

事實並非如此，尤其是一些迴歸測試的自動化，一方面是為了提高效率，一方面是為了增強上線前團隊的信心。

團隊人才的培養

遇到了一些公司，好不容易做起了自動化，做得也不錯，等到負責人離職之後，就沒人維護了，然後再招一些自動化測試人員另起爐灶，反反覆覆，歸根結底是沒有人做技術備份。

最後：

可以我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！，其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！