摘自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)安排是否清晰、合理，是否利于高效對需求進行覆蓋。

　　2.優(yōu)先極安排是否合理。

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

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

　　5. 是否已經(jīng)刪除了冗余的用例。

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

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

　　8. 是否簡潔，復(fù)用性強。例如，可將重復(fù)度高的步驟或過程抽取出來定義為一些可復(fù)用標(biāo)準(zhǔn)步驟。

　三、用例評審過程

　　1.提前發(fā)出用例初稿，并確定參與用例評審人員，目前我們是只包含測試工程師和測試經(jīng)理參與；

　　2.先做簡單的業(yè)務(wù)流程介紹，這個是在評審開始尤為重要的一個過程，剛開始評審，參與人員會比較蒙圈，其他測測試工程師可能都不知道測試的思路，或者半途加入的新

　　的測試，對需求和業(yè)務(wù)都不夠熟悉，如何讓評審快速進入狀態(tài)，先做簡單的需求業(yè)務(wù)流程介紹，說明白打算如何去做評審。

　　3.按模塊進行，有些模塊，業(yè)務(wù)性不是特別強的，可以簡單說下有哪些模塊，每個模塊評審的時候，按測試項分類，UI、核心功能、基礎(chǔ)功能、邊界測試、兼容測試和異常

　　測試等，預(yù)期結(jié)果類似的，主要講清楚用例主題，讓參與人員知道每條用例是做什么的。

　　4.按業(yè)務(wù)流程進行，業(yè)務(wù)流程性較強的需求，需要有業(yè)務(wù)場景和邏輯，按一定的順序來；

　　5.按測試數(shù)據(jù)進行，涉及到計算邏輯、收益、報表等需求的，用例編寫時會先規(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.雜亂無章的評審，有順序有邏輯的進行評審是很重要的一點；

　　目前我們是測試組內(nèi)部的評審，我們著重于：

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

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

　?。?）是否針對需求變更進行跟著，覆蓋了所有的軟件需求；

　?。?）是否盡可能多的覆蓋了異常流程和異常測試點。