用例評審目的：
-
為了減少測試人員執行階段做無效工作；（執行無效case，提交無效問題）
-
為了避免三方需求理解不一致；
-
為了每個測試人員的質量標准與項目要求標准達成一致；
用例評審的四個環節：
需求評審、需求實現流程圖評審、測試大綱評審、測試用例檢查
-
需求評審：
A 檢查講解的內容無丟失
B 檢查需求理解無偏差
C 檢查需求講解思路清晰
D 檢查需求討論會議提出需求建議、需求討論的問題都有體現，並且記錄的詳細
E 檢查需求講解時存在問題的記錄，跟進結論
-
需求實現流程圖評審：
A 檢查需求以及實現邏輯內容正確
B 檢查需求以及實現邏輯內容齊全,補充流程缺失部分
C 檢查實現邏輯的深度與仔細程度
例如：軟件升級實現邏輯--什么時候獲取服務器版本信息？版本信息有什么？ 版本信息獲取失敗的處理？獲取的版本信息版本比對策略是什么？比對后的下載邏輯策略是什么？下載的文件保存在哪里？下載過程的失敗處理？下載成功后的安裝策略是什么？安裝失敗的處理邏輯是什么？安裝成功后的數據加載時機以及加載哪些數據？ 等等
-
測試大綱評審：
A 檢查用例大綱結構、思路清晰
B 檢查用例大綱內容齊全--對象齊全\影響因素齊全：
1.需求邏輯功能
2.UI（靜態+動態）
3.用戶行為（用戶常用場景， 常用數據）
4.黑盒用例設計方法
5.平台系統的特點（windows，ios，android，web）
6.開發語言特點
7.發現過的歷史bug
8.自身的版本兼容性
9.功能之間相互影響
10.開發實現邏輯和建議
C 檢查用例大綱語言描述清晰
D 檢查用例去除冗余用例
E 檢查用例進行集成，為測試執行的高效做准備
（由於我們是面向對象的用例設計思想，會把流程拆分成幾段，所以在執行的時候不夠流暢，因此需要將case整合集成）
-
測試用例檢查：
（站在正規化測試用例的角度進行用例的審核）
A 檢查大綱和用例內容一一對應，影響因素無丟失
B 檢查語言描述簡潔、清晰、明了
C 檢查每條測試用例都有明確的預期結果
D 根據正規化用例的各個字段要求對應的細節
（測試目的、前提條件、實現說明、測試環境准備、測試步驟、優先級別、是否自動化等）