『測試基礎』| 如何理解測試用例管理和缺陷管理？

大话性能發表於2024-05-29

1 測試用例定義

  • 測試用例（TestCase）為測試物件編制一種測試輸入、執行條件和預期結果；
  • 用例可以體現測試方案、方法、技術和策略；
  • 用例的內容一般包含：
# 測試物件名稱
# 測試項
# 測試目標
# 測試環境
# 測試輸入
# 測試步驟
# 預期結果
# 測試指令碼等
  • 平常我們最簡化的測試用例至少應該包含測試輸入和預期結果。

2 測試用例設計原則

  • 測試用例應覆蓋三類事件：
# 1、基本事件：根據需求需要實現所有功能的測試用例，覆蓋率達到100%；
# 2、備選事件：程式執行中的備選情況；
# 3、異常事件：程式執行出錯處理的路徑。
  • 使用等價類劃分法實現基本測試用例，將無限測試變成有限測試；
  • 使用邊界值發現程式可能出現錯誤的邊界問題或臨界條件；
  • 使用錯誤推斷法追加一些測試用例，這個和一些經驗有關；
  • 對照程式邏輯，檢查已設計測試用例的邏輯覆蓋程度；
  • 關於有輸入條件的測試用例，在開始時應選擇決策表驅動法和因果圖法；
  • 對於引數配置類軟體，應採用正交實驗法設計用例；
  • 對於業務流程清晰的系統，可採用場景法設計用例。

3 測試用例的評審

評審的要點，可以分以下內容：

  • 是否覆蓋了測試需求的所有功能點？
  • 是否覆蓋了所有非功能性測試需求？
  • 測試用例編號是否和測試需求對應？
  • 測試設計是否包含了正面和反面的測試用例？
  • 是否明確了測試特性、步驟、執行條件、預期結果等內容？
  • 是否包含了測試資料、測試資料的生成辦法？
  • 是否具備可操作性？
  • 優先順序安排是否合理？
  • 是否刪除了冗餘的測試用例？
  • 用例設計的是否簡潔？是否複用性強？

4 測試如何維護？

一般情況下我們需要對測試用例進行維護更新，更新的點有：

  • 廢棄的用例如何處理？
  • 因需求的變更，用例的標識和需求的標識是否對應？
  • 經過多次迭代測試，用例的優先順序執行是否需要更改？
  • 用例的設計場景是否需要完善？
  • 用例的執行人員是否設定合理？
  • 用例的版本更新等。

另外，為什麼需要更新維護呢？原因有下：

  • 測試過程中發現用例設計不全，需要進行補充完善；
  • 軟體交付後反饋了軟體問題，而這些問題恰巧在測試時並沒有發現，需要對這些缺陷補充相關的用例；
  • 軟體的更新，導致需求有所變動，需要更新用例等。

5 用例的作用

  • 發現和跟蹤軟體缺陷；
  • 更準確的反應軟體的某一個特性；
  • 反應軟體的效能和質量；
  • 明確故障責任等。

6 用例管理工具

  • 用例管理的工具有很多，比如
1、PingCode；2、TestRail；
3、TestLink；4、Jira；
5、PractiTest；6、PractiTest；
7、Zephyr Enterprise；8、MeterSphere；
9、Bugzilla、10、ZenTao

7 缺陷關注的重點

  • 以下是列出了缺陷需要關注的一些部分重點欄位，當然不止這些：
關鍵欄位 說明
缺陷狀態 比如已提交、待修改、已確認、已修改、重複、待評審、關閉等等
缺陷標題 簡單明瞭說明缺陷
嚴重程度 一般為致命、嚴重、一般、提示、建議；有的也分 A、B、C、D 等
緊急程度 從 1 到 4，最高為 1 級
缺陷型別 功能缺陷、介面設計缺陷、安全性、介面、效能、資料等缺陷
提交人 缺陷的提交人員，便於缺陷復現、跟蹤和管理
所屬專案或模組 明確缺陷的所屬
解決人 一般為對應的開發人員
解決時間 比如專案經理指定的開發人員解決缺陷的時間
關閉時間 最終被關閉的時間等

8 缺陷分析

我們需要對缺陷進行統計分析，比如以下：

  • 缺陷的主要分佈模組；
  • 缺陷產生的原因；
  • 根據已知的缺陷，分析可能產生的缺陷模組；
  • 根據缺陷的產生，分析軟體的質量情況；
  • 根據提交缺陷，分析測試人員的技術提升點；
  • 根據缺陷修改的程度，分析對應解決人的缺陷解決質量情況等。

9 缺陷管理工具

  • 之前提到的用例管理工具同樣適用缺陷管理：
1、PingCode；2、TestRail；
3、TestLink；4、Jira；
5、PractiTest；6、PractiTest；
7、Zephyr Enterprise；8、MeterSphere；
9、Bugzilla、10、ZenTao

更多內容可以學習《測試工程師 Python 工具開發實戰》書籍、《大話效能測試 JMeter 實戰》書籍

相關文章