建站
咨詢
售后
建站咨詢
新聞中心
在我有限的軟件測試經(jīng)歷里，曾有一段專職的自動化測試經(jīng)歷。
專注于為中小企業(yè)提供成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)臨潭免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
接觸自動化
那時第一次上手自動化測試，團隊里用的是Python，接口自動化測試的框架是requests+Excel+Jenkins，APP自動化測試的框架是Appium。
整個公司當(dāng)時有一款已有的APP，因此在試用期內(nèi)，我的任務(wù)是完成對已有APP的自動化腳本編寫和調(diào)試。
記得當(dāng)時剛開始去，很沒有經(jīng)驗，在跟功能測試同學(xué)了解了業(yè)務(wù)之后，只顧埋著頭部署環(huán)境，突然有一天，測試主管問我，是否要輸出一份自動化測試用例。我恍然大悟，于是把功能測試的用例拿來參考了一下，對用例做了一次篩選，輸出了一份自動化測試用例(現(xiàn)在回過頭看，當(dāng)時的做法真的很草率，既沒有一個自動化測試計劃，也沒有對自動化用例做評審，只知道功能測試同學(xué)的痛點就是迭代太快，回歸來不及做)。
用例輸出后，大概花了一個月的時間，完成了環(huán)境部署和基本用例腳本的編寫，那時候大概實現(xiàn)了四五十個場景，并且完成了自動發(fā)送測試報告。剩下的兩個月，我就一步一步的將場景擴充為二百多個。
其間也遇到了一些問題，比如登錄圖形驗證碼的獲取，不過使用OCR圖形識別很快就得到了解決，同事也有使用云打碼一類的平臺。
最大的一個問題是，當(dāng)APP版本更新迭代后，固定頁面所有的id、class等屬性都會變化，因為這些都是寫死在代碼里的，如果要更改意味著每個page都要更改，工作量非常之大，而且獲取這些屬性還需要借助一些工具，如UI AuTomatorviewer 、Appium自帶的Inspector。
在忙碌了一段時間后，先找到一個安卓開發(fā)，跟他排查了一下，他也找不到問題所在，后面又找了另一個開發(fā)，他排查之后發(fā)現(xiàn)是安卓混淆打包的問題，他給我出了一個不做混淆打包的APP，這才解決了這一問題。
另外一個比較大的問題是，APP自動化測試的運行時間非常久，我們兩三百條用例，如果加上失敗重試，大概要跑四五個小時，而且還會出現(xiàn)中間腳本出錯運行停止的問題。
記得一個印象比較深的事情是，我們第二天要發(fā)版了，頭一天下班前我開始跑腳本，等到晚上我一直沒有收到測試報告的郵件，于是晚上十點多趕回公司，發(fā)現(xiàn)自動化腳本已經(jīng)停止了。
對于時間久的問題，后面我嘗試引入UI AuTomator2(以下簡稱u2)框架來代替Appium，毋庸置疑，u2在執(zhí)行速度上有很大優(yōu)勢。
我曾經(jīng)對比過這兩個框架，同一個場景，Appium需要耗時60多秒的，u2只需要20多秒，足足節(jié)省了三分之二的時間。
但隨之而來新的問題是，u2不太穩(wěn)定，Appium中查找元素有用到顯式等待、隱式等待和強制等待，而u2中看似不需要這些，實際上多跑幾遍場景就會發(fā)現(xiàn)u2執(zhí)行太快會找不到元素，因此還得手動加上強制等待。這樣一來時間并沒有節(jié)省多少。
這個問題當(dāng)時沒有得到解決，反而是在我離職后的一段時間里，通過學(xué)習(xí)pytest-xdist的文檔，發(fā)現(xiàn)pytest-xdist可以基于ssh和socket來實現(xiàn)分布式執(zhí)行。
舉個例子，假如有200條場景，同時啟動2個執(zhí)行機，那么就會往執(zhí)行機-1上推送100個場景，往執(zhí)行機-2上推送另外100個場景，最終兩個執(zhí)行機的測試報告會集成為一個報告。這樣的解決方案如果當(dāng)時能應(yīng)用到實踐中，那么APP自動化測試時間過長的問題會得到完美解決，唯一需要注意的是，每個場景要獨立，不能相互依賴。
話說回來，APP自動化測試做下來好像沒有產(chǎn)生多少收益，因為只有我一個人開發(fā)和維護，所以到了維護階段就顯得耗時耗力，特別是本來一個固定的頁面改了或者中間插入了一套新的邏輯，就意味著相當(dāng)多的頁面需要調(diào)整。
第二次接觸項目
差不多這樣做了幾個月后，公司開始立新的項目，新的項目一開始就下決心要做接口測試，因此我又介入到這個項目中，參加立項會議、參加技術(shù)評審，了解了要做哪些，并且接口文檔怎么管理，接口怎么定義等等之后，就開始了新項目的接口測試。
那個階段，使用requests讀取Excel的方式在接口不多的時候還挺方便，因為代碼框架比較固定，只需要Excel里修改參數(shù)。
但隨著接口越來越多，也意味著接口之間的依賴越來越多，Excel管理簡直就是災(zāi)難，在Excel里要理清不同接口的依賴關(guān)系，是非常頭痛的一件事。
后來我使用Postman做了一些快速測試，等待時間充裕的時候，再慢慢把整個主流程的接口測試加上。在接口測試階段，前前后后發(fā)現(xiàn)了一些問題，但很大的不足是沒有解決Excel存儲數(shù)據(jù)的問題和沒有做數(shù)據(jù)正確性的校驗。
而且我們還是和支付相關(guān)的業(yè)務(wù)，這使得接口測試結(jié)果只能保證服務(wù)是正常的，返回碼是正常的，但是數(shù)據(jù)是否正確無從得知。
直到后來，自動化團隊換了一批人，新來的同事開始推行Java棧，使用Springboot+httpclient+Maven來作為接口自動化框架，基本舍棄了之前的Python自動化腳本。
那幾個月好幾位同事投入到同一個項目的接口自動化腳本的編寫中，對比之前我一個人負責(zé)兩個項目的自動化，情況的確好了很多。
這個自動化也是基于場景的，有做正常和異常輸入的校驗，以及最后的入庫檢查，腳本量非常大，所有異常場景的請求數(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)的缺陷更有意義一點，但是維護成本依然比較高。
自動化是什么？
最近的一兩年，我有時會想到自動化測試是什么？自動化測試本來是為提高測試效率而生，有時候使用不得當(dāng)，卻成為測試活動中的累贅。
但不可否認的是，自動化測試仍然是行之有效的，區(qū)別只是使用的動機和使用的方式，在我看來，做好自動化測試需要規(guī)避以下幾點：
1. 不要為了自動化為自動化
自動化測試不能基于KPI，而要看當(dāng)前的項目適不適合做自動化，有沒有足夠資源的投入和外部團隊的配合。
2. 自動化不是萬能的
不要貪多求全，妄想所有的測試場景都能通過自動化實現(xiàn)，尤其是更新迭代快的項目。能把穩(wěn)定的功能實現(xiàn)，并且做好回歸 ，已經(jīng)足夠了。
3. 自動化的場景
一種是基本場景，另一種可以是前端無法實現(xiàn)的場景。
而對于接口中無窮無盡的字段進行嚴苛的異常校驗，來保證足夠程序足夠健壯，有時候反而沒有那么必要。
因為開發(fā)周期短的公司一周好幾個版本，開發(fā)根本就沒時間對一些不太重要的字段做異常處理，當(dāng)然重要字段的類型、長度、非空校驗等還是要做。
4. 對自動化的認知
有些同行認為，自動化就是為了發(fā)現(xiàn)缺陷的，但是自動化發(fā)現(xiàn)的缺陷根本比不上功能測試，發(fā)現(xiàn)不了缺陷的自動化就沒有意義嗎?
事實并非如此，尤其是一些回歸測試的自動化，一方面是為了提高效率，一方面是為了增強上線前團隊的信心。
5. 團隊人才的培養(yǎng)
遇到了一些公司，好不容易做起了自動化，做得也不錯，等到負責(zé)人離職之后，就沒人維護了，然后再招一些自動化測試人員另起爐灶，反反復(fù)復(fù)，歸根結(jié)底是沒有人做技術(shù)備份。
本文題目：在我有限的軟件測試經(jīng)歷里，一段專職的自動化測試經(jīng)驗總結(jié)
URL網(wǎng)址：http://m.5511xx.com/article/dphgode.html
