在我有限的軟體測試經歷里,一段專職的自動化測試經驗總結
Atstudy網校 · 程式 ·

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

摘要:在我有限的軟體測試經歷里,曾有一段專職的自動化測試經歷。

裡用的是Python,接口自動化測試的框架是requests+Excel

接觸自動化

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

自動化不是萬能的

不要貪多求全,妄想所有的測試場景都能通過自動化實現,尤其是更新疊代快的項目。能把穩定的功能實現,並且做好回歸 ,已經足夠了。

自動化的場景

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

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

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

對自動化的認知

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

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

團隊人才的培養

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

最後:

1)關注+私信回覆:「測試」,可以免費領取一份10G軟體測試工程師面試寶典文檔資料。以及相對應的影片學習教程免費分享!

2)關注+私信回覆:"入群" 就可以邀請你進入軟體測試群學習交流~~

聲明:文章觀點僅代表作者本人,PTTZH僅提供信息發布平台存儲空間服務。
喔!快樂的時光竟然這麼快就過⋯
繼續其他精彩內容吧!
more