測 試 組 內 評 審
1、用例描述是否清晰：比如看到用例標題就能明白這條用例測試的是什么（而不是直到看到期望結果才明白這條用例的目的）， 執行步驟和期望輸出是否有歧義。
2、操作步驟是否有可執行性：
-
其他人讀完你的操作步驟，是否明白如何去操作；
-
一條用例多個測試點，這可能導致其他人執行你的用例時產生遺漏；
-
測試點是否有連貫性，是否貼近測試執行時的步驟。
3、是否考慮到測試用例的編寫效率：即復用性要強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標准步驟。否則寫用例和執行時閱讀用例都會花費很多時間。
4、是否考慮到了執行效率：用例怎么跟版本迭代結合？（我的期望是可以快速篩選出每次冒煙、系統測試、回歸測試的用例，回歸用例包括bug回歸、功能新增回歸、功能修改回歸、 驗收前整體回歸）。
5、是否覆蓋了所有的軟件需求？測試人員對需求的理解是否透徹？期望結果是否與需求一致？
6、異常測試點：可以從測試思維框架和以前的bug中找找看。
7、其他，比如優先級安排是否合理；二次評審時是否修改/刪除了之前說過的問題。
項 目 組 內 評 審
外部評審涉及協調外部資源，需要注意：
1、確定參會人：一般情況下我們會跟產品、開發一起評審，但並非所有情況下都是如此；
2、提前約時間：在外部的人看來，用例評審並不是本職工作，是給測試人員幫忙的，也有的會認為評審需求跟產品評審就好了。加上開發人員一般開發任務都緊張，所以測試人員要提前跟別人約時間。
3、確定評審內容：我一般在外部評審時只討論測試范圍和測試執行時可能有的風險。比如有的測試數據測試人員不能自己做，需要研發配合做程序改動。盡量避免在會議上討論別人一句話或幾句話就能說清楚的需求問題（顯得不專業，浪費大家時間。這些內容應該在會前確認）。
4、評審形式：思維導圖形式進行。