1、目的
為用例評審提供一個參考標準，保證評審的覆蓋率和有效性
2、范圍
本文檔閱讀對象為項目經理、測試工程師及項目組所有成員，適合于任何產品和項目。
3、評審分類
測試組內部的評審：測試部門成員參與
項目組內部的評審：項目經理、產品人員、開發(fā)人員和測試人員參與
4、評審內容
用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。
優(yōu)先級安排是否合理。
是否覆蓋測試需求上的所有功能點
用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數據和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法
是否已經刪除了冗余的用例
是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現
是否從用戶層面來設計用戶使用場景和使用流程的測試用例
是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。
5、評審方式
召開評審會議。與會者在設計人員講解之后給出意見和建議，同時進行詳細的評審記錄
通用OA與相關人員溝通
6、評審結束標準
1）評審過程中收集相關人員的反饋信息（即問題記錄清單），并在此基礎上進行測試用例更新，直到評審通過；
附：測試用例評審檢查項：
1）測試用例是否按照公司定義的模板進行編寫的；
2）測試用例的本身的描述是否清晰，是否存在二義性；
3）測試用例內容是否正確，是否與需求目標相一致；
4）測試用例的期望結果是否確定、唯一的；
5）操作步驟應與描述是否相一致；
6）測試用例是否覆蓋了所有的需求；
7）測試設計是否存在冗余性；
8）測試用例是否具有可執(zhí)行性；
9）是否從用戶層面來設計用戶使用場景和業(yè)務流程的測試用例；
10）場景測試用例是否覆蓋最復雜的業(yè)務流程；
11）用例設計是否包含了正面、反面的用例；
12）對于由系統自動生成的輸出項是否注明了生成規(guī)則；
13）測試用例應包含對中間和后臺數據的檢查；
14）測試用例應有正確的名稱和編號；
15）測試用例應標注有執(zhí)行的優(yōu)先級；
16）測試用例包含相關的配置信息：測試環(huán)境、數據、前置測試用例、用戶權限等；
17）每個測試用例步驟應<=15 Step
