首先要清楚內部評審的定義，是測試組內部的評審，還是項目組內部的評審。評審的定義不同，內容也不會相同。

如果是測試組內部的評審，應該著重于：

1.測試用例本身的描述是否清晰，是否存在二義性；

2.是否考慮到測試用例的執行效率.往往測試用例中步驟不斷重復執行，驗證點卻不同，而且測試設計的冗余性，都造成了效率的低下；

3.是否針對需求跟蹤矩陣，覆蓋了所有的軟件需求；

4.是否完全遵守了軟件需求的規定。這并不一定的，因為即使再嚴格的評審，也會出現錯誤，應具體情況具體對待。

如果是項目組內部的評審，也就需要評審委員會來做了，角度不同，評審的標準也不同。比如：

收集客戶需求的人員注重你的業務邏輯是否正確；

分析軟件需求規格的人注重你的用例是否跟規格要求一致；

開發負責人會注重你的用例中對程序的要求是否合理。

測試用例的評審能夠使用例的結構更清晰，覆蓋的用戶場景更全面；對于測試工程師來說也是一個快速提高用例設計能力的過程。

1、需要評審的原因

測試用例是軟件測試的準則，但它并不是一經編制完成就成為準則。由于用例開發人員的設計經驗和對需求理解的深度各不相同，所以用例的質量難免會有不同程度的差異。

2、進行評審的時機

一般會有兩個時間點。第一，是在用例的初步設計完成之后進行評審；第二是在整個詳細用例全部完成之后進行二次評審。如果項目時間比較緊張，盡可能保證對用例設計進行評審，提前發現其中的不足之處。

3、參與評審人員

這里會分為多個級別進行評審。

　　1) 部門評審，測試部門全體成員參與的評審。

　　2) 公司評審，這里包括了項目經理、需求分析人員、架構設計人員、開發人員和測試人員。

　3) 客戶評審，包括了客戶方的開發人員和測試人員。這種情況在外包公司比較常見。

4、評審內容

評審的內容有以下幾個方面：

　　1) 用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。

　　2) 優先極安排是否合理。

　　3) 是否覆蓋測試需求上的所有功能點。

　　4) 用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法。

　　5) 是否已經刪除了冗余的用例。

　　6) 是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現。

　　7) 是否從用戶層面來設計用戶使用場景和使用流程的測試用例。

　　8) 是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。

　　個人認為，一個“健康”的測試用例至少要通過前5個標準。

　　5、評審的方式

　　1) 召開評審會議。與會者在設計人員講解之后給出意見和建議，同時進行詳細的評審記錄。

　　2) 通用郵件與相關人員溝通

　　3) 通用IM工具直接與相關人員交流

　　方式只是手段，得到其它人員對于用例的反饋信息才是目的。

　　無論采用那種方式，都應該在溝通之前把用例設計的相關文檔發送給對方進行前期的學習和了解，以節省溝通成本。

　　6、評審結束標準

　　在評審活動中會收集到用例的反饋信息，在此基礎上進行用例更新，直到通過評審。

測試用例評審檢查單