測 試 組 內 評 審
1、用例描述是否清晰：比如看到用例標題就能明白這條用例測試的是什麼（而不是直到看到期望結果才明白這條用例的目的）， 執行步驟和期望輸出是否有歧義。
2、操作步驟是否有可執行性：
4、是否考慮到了執行效率：用例怎麼跟版本迭代結合？（我的期望是可以快速篩選出每次冒煙、系統測試、回歸測試的用例，回歸用例包括bug回歸、功能新增回歸、功能修改回歸、 驗收前整體回歸）。
5、是否覆蓋了所有的軟體需求？測試人員對需求的理解是否透徹？期望結果是否與需求一致？
6、異常測試點：可以從測試思維框架和以前的bug中找找看。
7、其他，比如優先順序安排是否合理；二次評審時是否修改/刪除了之前說過的問題。
項 目 組 內 評 審
外部評審涉及協調外部資源，需要注意：
1、確定參會人：一般情況下我們會跟產品、開發一起評審，但並非所有情況下都是如此；
3、確定評審內容：我一般在外部評審時只討論測試範圍和測試執行時可能有的風險。比如有的測試資料測試人員不能自己做，需要研發配合做程式改動。盡量避免在會議上討論別人一句話或幾句話就能說清楚的需求問題（顯得不專業，浪費大家時間。這些內容應該在會前確認）。
4、評審形式：思維導圖形式進行。
測試用例評審
1 測試組內同行評審 2 開發組內評審 1 檢查測試用例是否符合規範 流程清晰 劃分合理 是否採用了合理的測試用例設計方法 用例是否唯 一 有沒有重複 巢狀重複 有沒有考慮異常 有沒有大資料量場景 有沒有考慮冪等 有沒有考慮併發 重複請求 便於橫向比較 提高透明度 展示用例設計能力 2 業務流程有沒...
測試用例評審
關於測試用例評審，很早就有這個想法，但是鑑於以下幾個因素，一直未執行 1.在剛來的時候 6年前，連需求都沒有，到版本提交測試時，才第一次了解到版本做成這樣，測試用例無從談起 2.來了兩三年之後 4年前，測試用例被提起，但是依然無用例 無專案流程，無寫用例時間 3.來了四五年後 兩年前，才開始有專案概...
測試用例評審
首先要清楚內部評審的定義，是測試組內部的評審，還是專案組內部的評審。評審的定義不同，內容也不會相同。測試組內部的評審，應該著重於 測試用例本身的描述是否清晰，是否存在二義性 是否考慮到測試用例的執行效率，往往測試用例中步驟不斷重複執行，驗證點卻不同，而且測試設計的冗餘性，都造成了效率的低下 是否針對...