規則要素內容 |
使用范圍 |
審查結果 |
“否”的理由 |
“免”的理由 |
規則 |
建議 |
是 |
否 |
免 |
規范性規則 |
|
|
|
|
|
|
|
用例是否按照公司規定的模板進行編寫? |
√ |
|
|
|
|
|
|
用例的編號是否符合規范命名要求(項目縮寫-子特性-ST-測試類型-編號,如:HaiDaTicket-Login-ST-Function-001)? |
√ |
|
|
|
|
|
|
用例跟方案中的用例是否一致或者是否完全覆蓋方案中描述的所有系統測試項? |
√ |
|
|
|
|
|
|
是否更新了需求跟蹤矩陣,用例編號和需求跟蹤矩陣中的用例編號是否一一對應? |
√ |
|
|
|
|
|
|
用例是否覆蓋了基線化后的SRS? |
√ |
|
|
|
|
|
|
用例設計是否按照測試計划安排的時間完成? |
|
√ |
|
|
|
|
|
用例對新增或者變更的需求是否做了相應的調整? |
√ |
|
|
|
|
|
|
內容符合性 |
|
|
|
|
|
|
|
用例設計是否考慮了正向和反向兩方面的情況? |
√ |
|
|
|
|
|
|
用例是否可測試? |
√ |
|
|
|
|
|
|
用例的重要級別和優先級是否定義合理? |
√ |
|
|
|
|
|
|
用例是否清晰地描述了測試用例的標題? |
√ |
|
|
|
|
|
|
用例是否清晰地描述了預置條件? |
√ |
|
|
|
|
|
|
用例是否清晰無二義地描述了操作步驟? |
√ |
|
|
|
|
|
|
用例是否清晰描述了用例的輸入且輸入(測試數據)的准備是否有相關的描述? |
√ |
|
|
|
|
|
|
用例是否清晰的描述了預期結果以及預期結果是否可以驗證? |
√ |
|
|
|
|
|
|
用例設計是否使用了等價類分析、邊界值、因果圖、判定表、錯誤推測、正交分析、流程分析、狀態遷移分析、輸入域覆蓋、輸出域覆蓋等測試用例設計方法?是否針對不同的測試特性設計使用合適的設計方法? |
|
√ |
|
|
|
|
|
重點特性用例設計是否采用了多種方法結合來設計?是否過濾掉了重復的測試用例? |
|
√ |
|
|
|
|
|
用例中需要進行打印輸出(如報表)、表格的導入、導出是否說明了打印位置、表格名稱、指定數據庫表名或文件位置;表格和數據格式是否有說明或附件? |
|
√ |
|
|
|
|
|
質量目標 |
|
|
|
|
|
|
|
用例覆蓋率是否達到相應質量目標(如用例數(個)/KLOC)? |
√ |
|
|
|
|
|
|
用例評審發現的缺陷率(缺陷總數/用例總數)是否達到了相應的質量目標? |
√ |
|
|
|
|
|
|
用例的粒度是否合理和統一,是否均勻覆蓋了測試需求? |
√ |
|
|
|
|
|
|
用例發現的問題是否占整個測試執行發現問題的80%(當然越高越好)以上(事后驗證)? |
√ |
|
|
|
|
|
|
測試用例設計的時間占整個系統測試過程的時間是否合理(一般在30-40%)(這里排除一些專項測試如穩定性測試、長時間測試等)? |
|
√ |
|
|
|
|
|
其他 |
|
|
|
|
|
|
|
測試執行過程中發現用例不完善是否做相應的調整? |
√ |
|
|
|
|
|
|
軟件版本的升級,用例是否做相應的調整? |
√ |
|
|
|
|
|
|