在我有限的軟件測試經歷里，曾有一段專職的自動化測試經歷。

接觸自動化

那時第一次上手自動化測試，團隊里用的是Python，接口自動化測試的框架是requests+Excel+Jenkins，APP自動化測試的框架是Appium。

整個公司當時有一款已有的APP，因此在試用期內，我的任務是完成對已有APP的自動化腳本編寫和調試。

記得當時剛開始去，很沒有經驗，在跟功能測試同學了解了業(yè)務之后，只顧埋著頭部署環(huán)境，突然有一天，測試主管問我，是否要輸出一份自動化測試用例。我恍然大悟，于是把功能測試的用例拿來參考了一下，對用例做了一次篩選，輸出了一份自動化測試用例(現(xiàn)在回過頭看，當時的做法真的很草率，既沒有一個自動化測試計劃，也沒有對自動化用例做評審，只知道功能測試同學的痛點就是迭代太快，回歸來不及做)。

用例輸出后，大概花了一個月的時間，完成了環(huán)境部署和基本用例腳本的編寫，那時候大概實現(xiàn)了四五十個場景，并且完成了自動發(fā)送測試報告。剩下的兩個月，我就一步一步的將場景擴充為二百多個。

其間也遇到了一些問題，比如登錄圖形驗證碼的獲取，不過使用OCR圖形識別很快就得到了解決，同事也有使用云打碼一類的平臺。

最大的一個問題是，當APP版本更新迭代后，固定頁面所有的id、class等屬性都會變化，因為這些都是寫死在代碼里的，如果要更改意味著每個page都要更改，工作量非常之大，而且獲取這些屬性還需要借助一些工具，如UI AuTomatorviewer 、Appium自帶的Inspector。

在忙碌了一段時間后，先找到一個安卓開發(fā)，跟他排查了一下，他也找不到問題所在，后面又找了另一個開發(fā)，他排查之后發(fā)現(xiàn)是安卓混淆打包的問題，他給我出了一個不做混淆打包的APP，這才解決了這一問題。

另外一個比較大的問題是，APP自動化測試的運行時間非常久，我們兩三百條用例，如果加上失敗重試，大概要跑四五個小時，而且還會出現(xiàn)中間腳本出錯運行停止的問題。

記得一個印象比較深的事情是，我們第二天要發(fā)版了，頭一天下班前我開始跑腳本，等到晚上我一直沒有收到測試報告的郵件，于是晚上十點多趕回公司，發(fā)現(xiàn)自動化腳本已經停止了。

對于時間久的問題，后面我嘗試引入UI AuTomator2(以下簡稱u2)框架來代替Appium，毋庸置疑，u2在執(zhí)行速度上有很大優(yōu)勢。

我曾經對比過這兩個框架，同一個場景，Appium需要耗時60多秒的，u2只需要20多秒，足足節(jié)省了三分之二的時間。

但隨之而來新的問題是，u2不太穩(wěn)定，Appium中查找元素有用到顯式等待、隱式等待和強制等待，而u2中看似不需要這些，實際上多跑幾遍場景就會發(fā)現(xiàn)u2執(zhí)行太快會找不到元素，因此還得手動加上強制等待。這樣一來時間并沒有節(jié)省多少。

這個問題當時沒有得到解決，反而是在我離職后的一段時間里，通過學習pytest-xdist的文檔，發(fā)現(xiàn)pytest-xdist可以基于ssh和socket來實現(xiàn)分布式執(zhí)行。

舉個例子，假如有200條場景，同時啟動2個執(zhí)行機，那么就會往執(zhí)行機-1上推送100個場景，往執(zhí)行機-2上推送另外100個場景，最終兩個執(zhí)行機的測試報告會集成為一個報告。這樣的解決方案如果當時能應用到實踐中，那么APP自動化測試時間過長的問題會得到完美解決，唯一需要注意的是，每個場景要獨立，不能相互依賴。

話說回來，APP自動化測試做下來好像沒有產生多少收益，因為只有我一個人開發(fā)和維護，所以到了維護階段就顯得耗時耗力，特別是本來一個固定的頁面改了或者中間插入了一套新的邏輯，就意味著相當多的頁面需要調整。

第二次接觸項目

差不多這樣做了幾個月后，公司開始立新的項目，新的項目一開始就下決心要做接口測試，因此我又介入到這個項目中，參加立項會議、參加技術評審，了解了要做哪些，并且接口文檔怎么管理，接口怎么定義等等之后，就開始了新項目的接口測試。

那個階段，使用requests讀取Excel的方式在接口不多的時候還挺方便，因為代碼框架比較固定，只需要Excel里修改參數(shù)。

但隨著接口越來越多，也意味著接口之間的依賴越來越多，Excel管理簡直就是災難，在Excel里要理清不同接口的依賴關系，是非常頭痛的一件事。

后來我使用Postman做了一些快速測試，等待時間充裕的時候，再慢慢把整個主流程的接口測試加上。在接口測試階段，前前后后發(fā)現(xiàn)了一些問題，但很大的不足是沒有解決Excel存儲數(shù)據(jù)的問題和沒有做數(shù)據(jù)正確性的校驗。

而且我們還是和支付相關的業(yè)務，這使得接口測試結果只能保證服務是正常的，返回碼是正常的，但是數(shù)據(jù)是否正確無從得知。

直到后來，自動化團隊換了一批人，新來的同事開始推行Java棧，使用Springboot+httpclient+Maven來作為接口自動化框架，基本舍棄了之前的Python自動化腳本。

那幾個月好幾位同事投入到同一個項目的接口自動化腳本的編寫中，對比之前我一個人負責兩個項目的自動化，情況的確好了很多。

這個自動化也是基于場景的，有做正常和異常輸入的校驗，以及最后的入庫檢查，腳本量非常大，所有異常場景的請求數(shù)據(jù)和期望結果都是入庫的，后續(xù)請求的時候，先從數(shù)據(jù)庫拿到請求數(shù)據(jù)發(fā)送請求，得到響應結果再和數(shù)據(jù)庫的期望結果做比較，正常場景需要手動寫邏輯，響應結果里重要字段的值和數(shù)據(jù)庫里的值做比較。

那個時候，考慮了很多前端無法測到的復雜的場景，并發(fā)、冪等之類的，因此發(fā)現(xiàn)的缺陷更有意義一點，但是維護成本依然比較高。

自動化是什么？

最近的一兩年，我有時會想到自動化測試是什么？自動化測試本來是為提高測試效率而生，有時候使用不得當，卻成為測試活動中的累贅。

但不可否認的是，自動化測試仍然是行之有效的，區(qū)別只是使用的動機和使用的方式，在我看來，做好自動化測試需要規(guī)避以下幾點：

1. 不要為了自動化為自動化

自動化測試不能基于KPI，而要看當前的項目適不適合做自動化，有沒有足夠資源的投入和外部團隊的配合。

2. 自動化不是萬能的

不要貪多求全，妄想所有的測試場景都能通過自動化實現(xiàn)，尤其是更新迭代快的項目。能把穩(wěn)定的功能實現(xiàn)，并且做好回歸 ，已經足夠了。

3. 自動化的場景

一種是基本場景，另一種可以是前端無法實現(xiàn)的場景。

而對于接口中無窮無盡的字段進行嚴苛的異常校驗，來保證足夠程序足夠健壯，有時候反而沒有那么必要。

因為開發(fā)周期短的公司一周好幾個版本，開發(fā)根本就沒時間對一些不太重要的字段做異常處理，當然重要字段的類型、長度、非空校驗等還是要做。

4. 對自動化的認知

有些同行認為，自動化就是為了發(fā)現(xiàn)缺陷的，但是自動化發(fā)現(xiàn)的缺陷根本比不上功能測試，發(fā)現(xiàn)不了缺陷的自動化就沒有意義嗎?

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

5. 團隊人才的培養(yǎng)

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