1. 程式人生 > 其它 >介面自動化測試的 “能” 與 “不能”

介面自動化測試的 “能” 與 “不能”

本文為資深測試技術專家多則惑少則明對介面測試實戰的總結與思考,供大家探討(歡迎在評論區留言)。

一、介面自動化測試的 “能 “

介面自動化的目標

• 用於專案的 API 層的 HTTP 介面的功能邏輯驗證• 減少手工測試的工作(迴歸驗證;跨模組的驗證)•
實現手工驗證不能做的驗證(如介面涉及大量資料的排序比較)• 手工很難充分驗證的功能邏輯(如介面的功能驗證涉及大量的資料)

P.S. 實際專案中,介面自動化的根本目的是什麼?

個人認為是定時跑時,能監控介面,當介面功能失常時,可以及時發現,即發現 Bug。因此,可以使用程式碼覆蓋率來評估介面自動化的完整性,但
更重要的是發現問題

介面自動化 Case 用例設計原則

切記:

• 不要為了做自動化而做自動化,做的首要目標是問題出現時,能第一時間發現;• 自動化中的程式碼覆蓋率統計可以作為參考,但不能一開始就為了提高覆蓋率,陷入
Case 設計之中;

注意:好的介面自動化 Case 設計,依賴於 Case 設計者的功能理解程度(手工測試的功力)+ 功能覆蓋點

原則:

1. 將手工測試點轉換為自動化用例。Case 設計注意:驗證用例通過的標準---
參考一個功能點容易出問題的地方。或者說,一個用例的通過說明此功能點一定沒問題;反之,一定有問題。

2. 覆蓋手工測試不易檢查/太浪費時間的檢查

比如:

• 一個 HTTP 介面設計大量的資料比較的時候;• 介面的 json 返回不能直接檢查功能點是否正確(需要呼叫另一個介面的 json 來間接驗證時);•
一個介面的 json 返回需要和其他模組的介面聯合” 互相驗證 “(需要呼叫其他模組的介面的 json,兩個 json 相互來驗證彼此的正確性)

**3. **”邊緣性“的功能檢查 這裡主要指的是迴歸驗證。如果系統涉及邊緣性的功能驗證,把此類功能設計層自動化用例

4. 介面驗證的程度 介面的驗證:即判斷一個介面是否正常的標準。注意:介面引數”合理地“組合;

5. DB 資料更新檢查

(如果有必要)注意從介面的角度檢查 DB 資料的更新:

• 其他系統的資料更新到待測系統 DB 中的資料;• 每天待測系統由於使用者操作更新到 DB 中的資料;

**6. **介面自動化的資料準備

關於是否需要為介面自動化,特意在 DB
中準備需要的資料,適需要程度而定。原則:除非必須,否則不用準備。如果不準備資料,無法完成對介面的驗證,則自己準備資料即可。

注意:一旦自己準備資料,評估對其他功能驗證的影響。確保 DB 中資料量和真實性(模擬的資料需要充足,並且不能和真實資料差異性過大)。

介面自動化用例定時跑

自動化一般會選擇每天定時跑。這裡需要注意的一點就是定時跑的時間選擇。時間選擇上注意幾點:

1)在線上跑時,注意對線上介面的影響(一般要求:線上的迴歸驗證可以隨時跑);

2)如果要檢查 DB 資料更新的有關邏輯,注意資料的穩定性 (如使用者量少的時候);

3)在測試時(非生產環境),介面涉及讀,寫 DB,考慮是否需要定時跑;

二、介面自動化測試的”不能“

首先,介面自動化不是萬能的,總有覆蓋不到的時候。知道自動化的”不能“之處,才能更好配合手工測試出問題。

自動化的” 不能 “之處如下:

1)HTTP 介面突然出現壓力問題(前期的壓測);

2)Web 層面的手動測試 (新功能上線後,對原有功能迴歸時,仍需要介面自動化驗證介面,手工測試 Web 頁面功能);

3)異常情況(如需要第三方 API 掛掉/超時的場景);

介面自動化之難點:

1)實現變動 vs 維護的工作量 vs 檢查的詳細程度;

檢查詳細程度:自己和自己比;自己和同類介面同一指標比較(因為口徑不一致,或者內部實現變化,需要後續維護);

經驗:自己和自己比,擴充套件和相容性比較好(動態引數 + 完成功能檢查);而自己和別的介面比 看需求而定(介面提測前後 資料準確性檢查比較參考);

P.S. 小的點,執行時間和執行頻率;

用途:發現功能失常,功能不可用;

2)介面監控 —— 執行時間和執行頻率

• 檢查詳細程度 vs 執行時間和執行頻率 (只能和自己);• 檢查詳細程度 vs 經常頻繁報警(一個介面怎樣算是正常的,返回非200+功能正常)

3)資料報表;

資料的正確性:統計口徑(業務方的口徑+多個介面/模組口徑的差異後導致業務方不一致)。

介面自動化之痛點

痛點當然源自難點:

•當介面本身實現頻繁變動、對介面的檢查太過詳細、開發修復緩慢時,那麼不停的報警將會來了。•不合理的自動化設計及維護方案,造成自動化成本大於自動化收益時,介面自動化就變得無足輕重了。實際專案中的體會是:
為了自動化而自動化 。特別測試場景過於複雜時,當自動化實現成本遠大於手工測試成本時,就沒有必要非去自動化測試了。

P.S. 歡迎在評論區留言你對介面測試自動化的實踐心得和看法。

** _
來霍格沃茲測試開發學社,學習更多軟體測試與測試開發的進階技術,知識點涵蓋web自動化測試 app自動化測試、介面自動化測試、測試框架、效能測試、安全測試、持續整合/持續交付/DevOps,測試左移、測試右移、精準測試、測試平臺開發、測試管理等內容,課程技術涵蓋bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相關技術,全面提升測試開發工程師的技術實力

點選獲取更多資訊