用例評審目的：
用例評審的四個環節：
需求評審、需求實現流程圖評審、測試大綱評審、測試用例檢查
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 根據正規化用例的各個字段要求對應的細節
（測試目的、前提條件、實現說明、測試環境準備、測試步驟、優先級別、是否自動化等）
如何有效的評審功能測試用例？
新手測試評審的總結分析 為用例評審提供乙個參考標準，保證評審的覆蓋率和有效性 測試組內部的評審 測試部門成員參與 專案組內部的評審 專案經理 架構設計人員 開發人員和測試人員參與 需求評審 需求實現流程圖評審 測試大綱評審 測試用例檢查 需求評審 a 檢查講解的內容無丟失 b 檢查需求理解無偏差 c...
測試用例評審
1 測試組內同行評審 2 開發組內評審 1 檢查測試用例是否符合規範 流程清晰 劃分合理 是否採用了合理的測試用例設計方法 用例是否唯 一 有沒有重複 巢狀重複 有沒有考慮異常 有沒有大資料量場景 有沒有考慮冪等 有沒有考慮併發 重複請求 便於橫向比較 提高透明度 展示用例設計能力 2 業務流程有沒...
測試用例評審
關於測試用例評審，很早就有這個想法，但是鑑於以下幾個因素，一直未執行 1.在剛來的時候 6年前，連需求都沒有，到版本提交測試時，才第一次了解到版本做成這樣，測試用例無從談起 2.來了兩三年之後 4年前，測試用例被提起，但是依然無用例 無專案流程，無寫用例時間 3.來了四五年後 兩年前，才開始有專案概...