規則要素內容
使用範圍
審查結果
「否」的理由
「免」的理由
規則建議是否
免規範性規則
用例是否按照公司規定的模板進行編寫？
√用例的編號是否符合規範命名要求（專案縮寫-子特性-st-測試型別-編號，如：haidaticket-login-st-function-001）？
√用例跟方案中的用例是否一致或者是否完全覆蓋方案中描述的所有系統測試項？
√是否更新了需求跟蹤矩陣，用例編號和需求跟蹤矩陣中的用例編號是否一一對應？
√用例是否覆蓋了基線化後的srs？
√用例設計是否按照測試計畫安排的時間完成？
√用例對新增或者變更的需求是否做了相應的調整？
√內容符合性
用例設計是否考慮了正向和反向兩方面的情況？
√用例是否可測試？
√用例的重要級別和優先順序是否定義合理？
√用例是否清晰地描述了測試用例的標題？
√用例是否清晰地描述了預置條件？
√用例是否清晰無二義地描述了操作步驟？
√用例是否清晰描述了用例的輸入且輸入（測試資料）的準備是否有相關的描述？
√用例是否清晰的描述了預期結果以及預期結果是否可以驗證？
√用例設計是否使用了等價類分析、邊界值、因果圖、判定表、錯誤推測、正交分析、流程分析、狀態遷移分析、輸入域覆蓋、輸出域覆蓋等測試用例設計方法？是否針對不同的測試特性設計使用合適的設計方法？
√ 重點特性用例設計是否採用了多種方法結合來設計？是否過濾掉了重複的測試用例？
√用例中需要進行列印輸出（如報表）、**的匯入、匯出是否說明了列印位置、**名稱、指定資料庫表名或檔案位置；**和資料格式是否有說明或附件？
√質量目標
用例覆蓋率是否達到相應質量目標（如用例數（個）/kloc）?
√用例評審發現的缺陷率（缺陷總數/用例總數）是否達到了相應的質量目標？
√用例的粒度是否合理和統一，是否均勻覆蓋了測試需求？
√用例發現的問題是否佔整個測試執行發現問題的80%（當然越高越好）以上（事後驗證）？
√測試用例設計的時間佔整個系統測試過程的時間是否合理（一般在30-40%）（這裡排除一些專項測試如穩定性測試、長時間測試等）？
√其他
測試執行過程中發現用例不完善是否做相應的調整？
√ 軟體版本的公升級，用例是否做相應的調整？
√
測試用例評審
1 測試組內同行評審 2 開發組內評審 1 檢查測試用例是否符合規範 流程清晰 劃分合理 是否採用了合理的測試用例設計方法 用例是否唯 一 有沒有重複 巢狀重複 有沒有考慮異常 有沒有大資料量場景 有沒有考慮冪等 有沒有考慮併發 重複請求 便於橫向比較 提高透明度 展示用例設計能力 2 業務流程有沒...
測試用例評審
關於測試用例評審，很早就有這個想法，但是鑑於以下幾個因素，一直未執行 1.在剛來的時候 6年前，連需求都沒有，到版本提交測試時，才第一次了解到版本做成這樣，測試用例無從談起 2.來了兩三年之後 4年前，測試用例被提起，但是依然無用例 無專案流程，無寫用例時間 3.來了四五年後 兩年前，才開始有專案概...
測試用例評審
首先要清楚內部評審的定義，是測試組內部的評審，還是專案組內部的評審。評審的定義不同，內容也不會相同。測試組內部的評審，應該著重於 測試用例本身的描述是否清晰，是否存在二義性 是否考慮到測試用例的執行效率，往往測試用例中步驟不斷重複執行，驗證點卻不同，而且測試設計的冗餘性，都造成了效率的低下 是否針對...