摘自http://www.51testing.com/html/47/n-3725947.html
一、需要評審的原因
測試用例是軟件測試的準則，但它并不是編制完成后就直接成為準則。由于用例開發人員的設計經驗和對需求理解的深度各不相同，所以用例的質量難免會有不同程度的差異。
二、用例評審內容
1.用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。
2.優先極安排是否合理。
3.是否覆蓋測試需求上的所有功能點。
4. 用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法。
5. 是否已經刪除了冗余的用例。
6.是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現。
7. 是否從用戶層面來設計用戶使用場景和使用流程的測試用例。
8. 是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。
三、用例評審過程
1.提前發出用例初稿，并確定參與用例評審人員，目前我們是只包含測試工程師和測試經理參與；
2.先做簡單的業務流程介紹，這個是在評審開始尤為重要的一個過程，剛開始評審，參與人員會比較蒙圈，其他測測試工程師可能都不知道測試的思路，或者半途加入的新
的測試，對需求和業務都不夠熟悉，如何讓評審快速進入狀態，先做簡單的需求業務流程介紹，說明白打算如何去做評審。
3.按模塊進行，有些模塊，業務性不是特別強的，可以簡單說下有哪些模塊，每個模塊評審的時候，按測試項分類，UI、核心功能、基礎功能、邊界測試、兼容測試和異常
測試等，預期結果類似的，主要講清楚用例主題，讓參與人員知道每條用例是做什么的。
4.按業務流程進行，業務流程性較強的需求，需要有業務場景和邏輯，按一定的順序來；
5.按測試數據進行，涉及到計算邏輯、收益、報表等需求的，用例編寫時會先規劃好測試數據，盡管測試數據也是按不同的業務場景來設計的，但直接用測試數據來評審你
的測試點，會更清晰，跟上你思路的開發和產品會對應上自己的產品設計和代碼設計去評審你的測試點是否不合理或覆蓋率不全的地方，從而有效的評審測試用例。
四、用例評審需要避免
1.測試點含糊用語，每個用例評審都應該確定最終版，稍有矛盾或疑惑的需求點，都應該確認下來，不能含糊不清。
2.雜亂無章的評審，有順序有邏輯的進行評審是很重要的一點；
目前我們是測試組內部的評審，我們著重于：
（1）測試用例本身的描述是否清晰，是否存在二義性；
（2）是否考慮到測試用例的執行效率.往往測試用例中步驟不斷重復執行，驗證點卻不同，而且測試設計的冗余性，都造成了效率的低下；
（3）是否針對需求變更進行跟著，覆蓋了所有的軟件需求；
（4）是否盡可能多的覆蓋了異常流程和異常測試點。
