我的測試之旅:(4)並行——自動化迴歸測試
在前一個測試子專案中的表現不錯,而後我又被調入一個產品釋出版本的迴歸測試子專案中去。相比之前的測試子專案(軟體模組的功能測試),迴歸測試就很不一樣了。迴歸測試所執行的,都是比較基礎的測試用例,也是不管版本如何變遷也都不必要進行太多改動的測試用例。也正因為需要比較頻繁地(每一個新的產品釋出版本)執行這些測試用例,所以這些用例幾乎都有相應的測試指令碼,可以縮短測試執行時間,指令碼就是利用之前我提到過的內部工具寫成的。指令碼語言本身可以抽取一些library出來,具有一定的模組化構造,可以減少一些重複的指令碼程式碼,但是後來我從測試自動化(TA,Test Automation)的角度來看,依然是非常低階別(基礎,非編譯)的自動化實踐。
相比之前跟著導師幹活,這一次的工作就需要我自己獨立進行,而且工作內容也增加了許多。包括要自己寫測試計劃,還要組織稽核會議(Inspection Meeting),通過稽核後的計劃會在系統裡被標示為“已批准”(Approved),這樣我才可以根據這個計劃以及測試用例開始執行測試。測試計劃還是不難寫,畢竟是迴歸測試嘛,把測試管理系統裡以前別的版本的迴歸測試計劃拿出來看一看,修改一些相關的欄位,例如產品版本啊、執行人名稱即可,大同小異。要隨便弄弄矇混過關倒是不難,依葫蘆畫瓢就行,難點是在於你是不是想弄明白這些迴歸測試的用例,畢竟這些用例都是別人寫的,而且除了用例之外,還有測試指令碼,萬一兩者之間有些互相沖突的資訊,或者指令碼報出的一些錯誤資訊在用例中沒有描述到,如何能夠處理妥當,這需要執行人多花點心思,多消耗點腦細胞才行。
迴歸測試的另一個挑戰在於,它涉及到的系統架構範圍往往不止一個模組。之前在導師的帶領下工作,只需要按照用例中所給出的資訊,執行相應的命令即可。就算你不太明白命令中一些部分的引數該如何設計,在人機介面上執行這些命令時,它自己也能發現不合規的命令格式並且給出提示,要求你輸入正確的值。只是執行、觀察、發現錯誤、修改命令或引數、重新執行、記錄結果,還是很輕鬆的。但如今由於要測試更多的模組、更廣的範圍,需要了解的命令也逐漸地多起來,在測試中發現一些異常現象後要檢視日誌、系統狀態也需要執行一些命令,而這些命令並不在我負責測試的技術領域中,所以還得去找相關領域的測試同事、專家請教學習,或者不願意求人的話就得自己找相關文件。在此,溝通以及查閱資料或者摸索的能力就非常重要了。
只是執行測試是相對簡單而且有點枯燥的活,因為這些功能多數都是穩定的,不大會出錯。於是我就把一些時間花在思考、理解這些測試用例和指令碼上,正好迴歸測試的用例中總有一些是執行時間比較長的,我就利用這些時間去查閱資料、文件,理解測試用例的設計理念,以及研究多個測試用例之間的關係,看看是不是有漏測的功能。
在當時,我們的迴歸測試用例都是從現有的功能測試用例中直接篩選出來的,挑選的是其中比較基礎的、通用的測試用例,是否容易實現指令碼化也是考量的因素之一。因此,如果只是去看測試計劃中的測試用例集,難以看到全貌,不知道為何要選擇這些用例,也不知道這些用例之間有什麼特別的聯絡,它們結合在一起是否有足夠完整地覆蓋了要測試的範圍。因而,想要理解這些測試用例以及其關係,找到是否有漏測的功能,需要額外花一些功夫順藤摸瓜地檢視相關技術領域、模組的測試用例和以往的測試計劃。看一看某個測試用例在它的模組裡,是否還有其他的測試用例也在驗證相似的功能,有什麼區別,為何不選擇其他的測試用例做迴歸測試,以及是否有一些應該測而沒有測的功能(這需要研究功能需求規格說明書文件才行)。研究這些問題其實是蠻有意思的事,它能夠幫助你更深刻地理解自己手中正在執行的測試用例,更能夠分辨出在執行中你對哪些輸出資訊應該保持關注,而對其他一些資訊則可以睜一隻眼閉一隻眼(因為有其他的測試用例會專門檢查這一塊的情況)。做到測試用例或者測試執行有重點、有針對性有著莫大的好處,專注能幫你過濾掉一些不必要關注的資訊,延緩測試過程中的緊張感,也能夠提高你對重點資訊的關注度和敏感度,更容易發現問題。
檢視更多“我的測試之旅”文章
1. 起點——作為軟體開發人員
2. 轉變——作為專職測試人員
3. 同期——加入測試自動化小組
4. 並行——自動化迴歸測試
5. 難點——功能改進的測試
6. 跳轉——追逐新鮮事物的探險者
7. 啟程——Scrum中的測試工作者
8. 困難——沒有現成的測試工具
9. 行動——簡化測試文件和流程
10. 貢獻——開發項流程(Development Item Process)
11. 嘗試——Scrum Master
12. 機遇——測試自動化培訓師和教練
13. 轉型——敏捷教練
相關文章
- 我的測試之旅:(9)行動——簡化測試文件和流程
- 測中策---我的Web自動化測試思路Web
- 自動化測試系列 —— UI自動化測試UI
- 利用Junit4進行程式模組的測試,迴歸測試行程
- 功能測試、自動化測試、效能測試的區別
- 軟體測試:自動化測試
- Web自動化-Selenium自動化測試-4-編寫測試用例Web
- 【自動化測試入門】自動化測試思維
- JB測試之旅-淺談自動化知識
- 如何學習自動化測試?從手工測試到自動化測試的過程…
- 自動化裝置測試與自動化測試的區別
- 手工測試和自動化測試 BattleBAT
- 自動化測試系列(三)|UI測試UI
- 小程式自動化測試--測試3
- Junit測試Android自動化測試Android
- 軟體測試學習教程—迴歸測試
- 詳解迴歸測試
- 迴歸測試總結
- 自動化測試如何管理測試資料
- 軟體測試框架——自動化測試框架框架
- 使用PostMan進行自動化測試Postman
- 使用 PostMan 進行自動化測試Postman
- 自動化測試理解
- 自動化測試思路
- airTest自動化測試AI
- 介面自動化測試
- API自動化測試API
- 自動化測試框架框架
- 自動化元件測試元件
- 軟體測試人員的華麗轉身——自動化測試之我見
- 測試開發之自動化篇-自動化測試框架設計框架
- 我的自動化軟體測試小結(2)
- API自動化測試平臺,高效實現對API的自動化測試API
- Docker與自動化測試及其測試實踐Docker
- 軟體測試理論(2)自動化測試
- Flutter應用進行自動化測試Flutter
- 真的要進行介面測試自動化?
- 自己動手寫Web自動化測試框架(6):自動化測試框架的規劃Web框架