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

接觸自動化

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

整個公司當(dāng)時有一款已有的APP，因此在試用期內(nèi)，我的任務(wù)是完成對已有APP的自動化腳本編寫和調(diào)試。

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

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

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

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

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

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

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

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

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

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

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

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

話說回來，APP自動化測試做下來好像沒有產(chǎn)生多少收益，因?yàn)橹挥形乙粋€人開發(fā)和維護(hù)，所以到了維護(hù)階段就顯得耗時耗力，特別是本來一個固定的頁面改了或者中間插入了一套新的邏輯，就意味著相當(dāng)多的頁面需要調(diào)整。

第二次接觸項目

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

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

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

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

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

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

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

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

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

自動化是什么？

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

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

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

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

2. 自動化不是萬能的

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

3. 自動化的場景

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

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

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

4. 對自動化的認(rèn)知

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

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

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

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