摘自http://www.51testing.com/html/47/n-3725947.html
一、需要評審的原因
測試用例是軟件測試的準(zhǔn)則闰靴，但它并不是編制完成后就直接成為準(zhǔn)則彪笼。由于用例開發(fā)人員的設(shè)計經(jīng)驗和對需求理解的深度各不相同，所以用例的質(zhì)量難免會有不同程度的差異蚂且。
二配猫、用例評審內(nèi)容
1.用例設(shè)計的結(jié)構(gòu)安排是否清晰、合理杏死，是否利于高效對需求進(jìn)行覆蓋泵肄。
2.優(yōu)先極安排是否合理。
3.是否覆蓋測試需求上的所有功能點识埋。
4. 用例是否具有很好可執(zhí)行性凡伊。例如用例的前提條件、執(zhí)行步驟窒舟、輸入數(shù)據(jù)和期待結(jié)果是否清晰系忙、正確；期待結(jié)果是否有明顯的驗證方法惠豺。
5. 是否已經(jīng)刪除了冗余的用例银还。
6.是否包含充分的負(fù)面測試用例。充分的定義洁墙，如果在這里使用2&8法則蛹疯，那就是4倍于正面用例的數(shù)量，畢竟一個健壯的軟件热监，其中80%的代碼都是在“保護(hù)”20%的功能實現(xiàn)捺弦。
7. 是否從用戶層面來設(shè)計用戶使用場景和使用流程的測試用例。
8. 是否簡潔孝扛，復(fù)用性強列吼。例如，可將重復(fù)度高的步驟或過程抽取出來定義為一些可復(fù)用標(biāo)準(zhǔn)步驟苦始。
三寞钥、用例評審過程
1.提前發(fā)出用例初稿，并確定參與用例評審人員陌选，目前我們是只包含測試工程師和測試經(jīng)理參與理郑；
2.先做簡單的業(yè)務(wù)流程介紹，這個是在評審開始尤為重要的一個過程咨油，剛開始評審您炉，參與人員會比較蒙圈，其他測測試工程師可能都不知道測試的思路臼勉，或者半途加入的新
的測試邻吭，對需求和業(yè)務(wù)都不夠熟悉，如何讓評審快速進(jìn)入狀態(tài)宴霸，先做簡單的需求業(yè)務(wù)流程介紹囱晴，說明白打算如何去做評審。
3.按模塊進(jìn)行瓢谢，有些模塊畸写，業(yè)務(wù)性不是特別強的，可以簡單說下有哪些模塊氓扛，每個模塊評審的時候枯芬，按測試項分類，UI采郎、核心功能千所、基礎(chǔ)功能、邊界測試蒜埋、兼容測試和異常
測試等淫痰，預(yù)期結(jié)果類似的，主要講清楚用例主題整份，讓參與人員知道每條用例是做什么的待错。
4.按業(yè)務(wù)流程進(jìn)行，業(yè)務(wù)流程性較強的需求烈评，需要有業(yè)務(wù)場景和邏輯火俄，按一定的順序來；
5.按測試數(shù)據(jù)進(jìn)行讲冠，涉及到計算邏輯瓜客、收益、報表等需求的竿开，用例編寫時會先規(guī)劃好測試數(shù)據(jù)谱仪，盡管測試數(shù)據(jù)也是按不同的業(yè)務(wù)場景來設(shè)計的，但直接用測試數(shù)據(jù)來評審你
的測試點德迹，會更清晰芽卿，跟上你思路的開發(fā)和產(chǎn)品會對應(yīng)上自己的產(chǎn)品設(shè)計和代碼設(shè)計去評審你的測試點是否不合理或覆蓋率不全的地方，從而有效的評審測試用例胳搞。
四卸例、用例評審需要避免
1.測試點含糊用語，每個用例評審都應(yīng)該確定最終版肌毅，稍有矛盾或疑惑的需求點筷转，都應(yīng)該確認(rèn)下來，不能含糊不清悬而。
2.雜亂無章的評審呜舒，有順序有邏輯的進(jìn)行評審是很重要的一點；
目前我們是測試組內(nèi)部的評審笨奠，我們著重于：
∠取（1）測試用例本身的描述是否清晰唤殴，是否存在二義性；
〉叫取（2）是否考慮到測試用例的執(zhí)行效率.往往測試用例中步驟不斷重復(fù)執(zhí)行朵逝，驗證點卻不同，而且測試設(shè)計的冗余性乡范，都造成了效率的低下配名；
（3）是否針對需求變更進(jìn)行跟著晋辆，覆蓋了所有的軟件需求渠脉；
（4）是否盡可能多的覆蓋了異常流程和異常測試點瓶佳。
