新手測試評審的總結分析
為用例評審提供乙個參考標準，保證評審的覆蓋率和有效性
測試組內部的評審：測試部門成員參與需求評審、需求實現流程圖評審、測試大綱評審、測試用例檢查專案組內部的評審：專案經理、架構設計人員、開發人員和測試人員參與
需求評審
a 檢查講解的內容無丟失需求實現流程圖評審b 檢查需求理解無偏差
c 檢查需求講解思路清晰
d 檢查需求討論會議提出需求建議、需求討論的問題都有體現，並且記錄的詳細
e 檢查需求講解時存在問題的記錄，跟進結論
測試大綱評審
a 檢查用例大綱結構、思路清晰 b 檢查用例大綱內容齊全–物件齊全\影響因素齊全：測試用例檢查1.需求邏輯功能
2.ui（靜態+動態）
3.使用者行為（使用者常用場景， 常用資料）
4.黑盒用例設計方法
5.平台系統的特點（windows，ios，android，web）
6.開發語言特點
7.發現過的歷史bug
8.自身的版本相容性
9.功能之間相互影響
10.開發實現邏輯和建議 c 檢查用例大綱語言描述清晰 d 檢查用例去除冗餘用例 e 檢查用例進行整合，為測試執行的高效做準備
檢查每條測試用例都有明確的預期結果總結內容：根據正規化用例的各個字段要求對應的細節
用例設計的結構安排是否清晰、合理，是否利於高效對需求進行覆蓋。
優先順序安排是否合理。
是否覆蓋測試需求上的所有功能點
用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入資料和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法
是否已經刪除了冗餘的用例
是否包含充分的負面測試用例。充分的定義，如果在這裡使用2&8法則，那就是4倍於正面用例的量，畢竟乙個健壯的軟體，其中80%的**都是在「保護」20%的功能實現
是否從使用者層面來設計使用者使用場景和使用流程的測試用例
是否簡潔，復用性強。例如，可將重複度高的步驟或過程抽取出來定義為一些可復用標準步驟
2）評審結束後，測試負責人出測試用例評審報告給到相關人員；
3）評審結果經專案經理同意確認
測試用例評審檢查項：
1）測試用例是否按照公司定義的模板進行編寫的；參考評審學習資料：2）測試用例的本身的描述是否清晰，是否存在二義性；
3）測試用例內容是否正確，是否與需求目標相一致；
4）測試用例的期望結果是否確定、唯一的；
5）操作步驟應與描述是否相一致；
6）測試用例是否覆蓋了所有的需求；
7）測試設計是否存在冗餘性；
8）測試用例是否具有可執行性；
9）是否從使用者層面來設計使用者使用場景和業務流程的測試用例； 10）場景測試用例是否覆蓋最複雜的業務流程；
11）用例設計是否包含了正面、反面的用例；
12）對於由系統自動生成的輸出項是否註明了生成規則；
13）測試用例應包含對中間和後台資料的檢查；
14）測試用例應有正確的名稱和編號；
15）測試用例應標註有執行的優先順序；
16）測試用例包含相關的配置資訊：測試環境、資料、前置測試用例、使用者授權等；
17）每個測試用例步驟應<=15 step；
18）自動化測試指令碼必須帶有注釋（注釋應包括：目的、輸入、期望結果等）；
19）非功能測試需求或不可測試需求是否在用例中列出並說明？
如何評審功能測試用例？
用例評審目的 用例評審的四個環節 需求評審 需求實現流程圖評審 測試大綱評審 測試用例檢查 a 檢查講解的內容無丟失 b 檢查需求理解無偏差 c 檢查需求講解思路清晰 d 檢查需求討論會議提出需求建議 需求討論的問題都有體現，並且記錄的詳細 e 檢查需求講解時存在問題的記錄，跟進結論 a 檢查需求以...
測試用例評審
1 測試組內同行評審 2 開發組內評審 1 檢查測試用例是否符合規範 流程清晰 劃分合理 是否採用了合理的測試用例設計方法 用例是否唯 一 有沒有重複 巢狀重複 有沒有考慮異常 有沒有大資料量場景 有沒有考慮冪等 有沒有考慮併發 重複請求 便於橫向比較 提高透明度 展示用例設計能力 2 業務流程有沒...
測試用例評審
關於測試用例評審，很早就有這個想法，但是鑑於以下幾個因素，一直未執行 1.在剛來的時候 6年前，連需求都沒有，到版本提交測試時，才第一次了解到版本做成這樣，測試用例無從談起 2.來了兩三年之後 4年前，測試用例被提起，但是依然無用例 無專案流程，無寫用例時間 3.來了四五年後 兩年前，才開始有專案概...