接口自動化測試的 “能” 與 “不能”

發表于:2020-10-07 19:52  作者:佚名   來源:知乎

字體: | 上一篇 | 下一篇 |我要投稿 | 推薦標簽: 功能測試 接口測試

  一、接口自動化測試的 “能 “
  接口自動化的目標
  ·用于項目的 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)數據報表;
  數據的正確性:統計口徑(業務方的口徑+多個接口/模塊口徑的差異后導致業務方不一致)。
  接口自動化之痛點
  痛點當然源自難點:
  ·當接口本身實現頻繁變動、對接口的檢查太過詳細、開發修復緩慢時,那么不停的報警將會來了。?不合理的自動化設計及維護方案,造成自動化成本大于自動化收益時,接口自動化就變得無足輕重了。實際項目中的體會是:為了自動化而自動化。特別測試場景過于復雜時,當自動化實現成本遠大于手工測試成本時,就沒有必要非去自動化測試了。

  本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系博為峰小編(021-64471599-8017),我們將立即處理

評 論

論壇新帖

頂部 底部


建議使用IE 6.0以上瀏覽器,800×600以上分辨率,法律顧問:上海信義律師事務所 項棋律師
版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2021, 滬ICP備05003035號
投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

滬公網安備 31010102002173號

51Testing官方微信

51Testing官方微博

掃一掃 測試知識全知道

日本av