測試用例的評審能夠應用例的結構更清晰，掩飾的用戶場景更全面;對于測試工程師來說也是一個快速提高用例設計能力的過程。
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、評審結束標準
在評審靜止中會收集到用例的反映信息，在此基礎上進行用例更新，直到通過評審。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
