淺談功能測試用例模板設計[3]

　　淺談功能測試用例模板設計[3]   軟件測試

　　圖-3 測試用例生命周期

　　隊列中( In Queue ) -- 測試用例在排隊等待中;

　　進程中( In Progress ) -- 表示測試正在進行，并且可能會持續一段時間，如果一個測試花費的時間少于一天或兩天，只需將它顯示在處于排隊狀態;

　　阻塞( Block ) -- 一些外部條件 — 如缺少部分功能 — 將無法執行測試;

　　忽略( Skip ) -- 已經決定(或被告知)跳過這個測試用例;

　　通過( Pass ) -- 終點狀態，沒問題;

　　失敗( Fail ) -- 測試用例執行出錯;

　　警告( Warn ) -- 結果處于 Pass 和 Fail 之間，錯誤嚴重性等級較輕，不影響功能和性能;

　　關閉( Closed ) -- 以前識別出的錯誤都已經被修正。

　　實際項目中，一個測試用例有多個執行步驟，每個步驟可能有不同結果，如步驟 1 通過，步驟 2 失敗，步驟 3 被步驟 2 中的失敗所阻塞，那么該測試狀態如何?單純指出這個測試用例阻塞或失敗都將遺漏重要的信息。因此必須指定雙重狀態，如 Block/Fail ， Block/Warn ， Skip/Pass ， Skip/Closed 等。然而，如果顯示十幾個狀態，則測試結果可能更難以解釋。如何使結果明了又能精確反映實際結果，需要精明選擇包括哪些狀態。

　　使用該模板優點：

　　使用維護簡便，方便測試任務分配，易于與項目組其他角色交流，結果報告自動生成。

　　不足之處：

　　測試變更跟蹤不方便，每個測試用例的規模不等，所以測試覆蓋率結果只是作為參考，結果百分比不能精確反映工作量，需要具體分析項目情況。這個模版沒有跟蹤統計缺陷，同時考慮是否使用加權評估缺陷嚴重性，一個測試用例往往對應幾個缺陷的統計分析。

　　結論：

　　在實際項目中，應該根據項目特點和開發流程定義測試用例各項。在精確和簡單兩個特性相對立時，需要好好權衡。如果您有好的解決方案，我將很樂意知道。

原文轉自：http://www.anti-gravitydesign.com