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

2022-10-09 13:18:08 字數 950 閱讀 4700

不要為了做自動化測試而做自動化,做的首要目標是問題出現時,能第一時間發現? 自動化中的**覆蓋率統計可以作為參考,但不能一開始就為了提高覆蓋率,陷入 case 設計之中。

注意:好的介面自動化 case 設計,依賴於 case 設計者的功能理解程度(手工測試的功力)+ 功能覆蓋點,在用例設計上面要遵循以下幾點原則:

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

2.覆蓋手工測試不易檢查/太浪費時間的檢查。例如乙個 http 介面設計大量的資料比較的時候; 介面的 json 返回不能直接檢查功能點是否正確(需要呼叫另乙個介面的 json 來間接驗證時);乙個介面的 json 返回需要和其他模組的介面聯合」 互相驗證 「(需要呼叫其他模組的介面的 json,兩個 json 相互來驗證彼此的正確性)

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

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

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

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

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

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

推薦閱讀:

自動化測試框架的型別有哪些?

怎樣判斷乙個軟體專案適不適合自動化測試?

企業選擇自動化測試方案的幾點建議

目前主要的自動化測試框架有哪幾種?

自動化用例設計原則

1.不是所有的手工用例都要轉化為自動化測試用例。2.考慮到指令碼考法的成本,不要選擇流程太複雜的用例。如果有必要考慮把流程拆分成多個用例來實現指令碼。3.選擇的用例最好可以構建場景。例如,乙個功能模組,分多個測試用例,多個用例使用同乙個場景。4.選擇的用例可以帶有目的性。例如 這部分用例做冒煙測試,...

自動化用例設計

用例設計部分,無論是手工測試還是自動化測試,都必須要的環節,也是非常重要的環節。在做自動化的時候,用例需要考慮前置後置 步驟和對比,每乙個部分都要有提供非常明確的測試資料,要考慮資料的重複使用是否會影響指令碼的執行結果。1.不是所有的手工用例都要轉成自動化測試用例 2.考慮到指令碼開發的成本,不要選...

自動化用例設計

自動化用例主要用來冒煙測試和回歸測試 冒煙測試,即為主要功能的用例執行 回歸測試,即為全部或者部分用例的執行 自動化測試得誤區 不編寫自動化測試用例,直接編寫自動化指令碼 直接拿手工測試用例來編寫自動化測試指令碼 自動化用例選型注意事項 1,不是所有的手工測試用例都要轉化為自動化測試用例 2,考慮指...