①評審過程中收集相關人員的反饋信息，并在此基礎上進行測試用例更新，直到評審通過；②評審結束后，測試負責人出測試用例評審報告給到相關人員；③評審結果經項目經理同意確認。

1）測試用例是否按照公司定義的模板進行編寫的；?
2）測試用例的本身的描述是否清晰，是否存在二義性；
3）測試用例內容是否正確，是否與需求目標相一致；
4）測試用例的期望結果是否確定、唯一的；
5）操作步驟應與描述是否相一致；
6）測試用例是否覆蓋了所有的需求；
7）測試設計是否存在冗余性；
8）測試用例是否具有可執行性；
9）是否從用戶層面來設計用戶使用場景和業務流程的測試用例；
10）場景測試用例是否覆蓋最復雜的業務流程；?
11）用例設計是否包含了正面、反面的用例；?
12）對于由系統自動生成的輸出項是否注明了生成規則；
13）測試用例應包含對中間和后臺數據的檢查；
14）測試用例應有正確的名稱和編號；
15）測試用例應標注有執行的優先級；
16）測試用例包含相關的配置信息：測試環境、數據、前置測試用例、用戶授權等；
17）每個測試用例步驟應<=15 Step；
18）自動化測試腳本必須帶有注釋（注釋應包括：目的、輸入、期望結果等）；
19）非功能測試需求或不可測試需求是否在用例中列出并說明。?

按照規范、客戶需求、文檔，可行性等

一、需要評審的原因

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

二、用例評審內容

??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）是否盡可能多的覆蓋了異常流程和異常測試點。

①評審過程中收集相關人員的反饋信息，并在此基礎上進行測試用例更新，直到評審通過；

②評審結束后，測試負責人出測試用例評審報告給到相關人員；

③評審結果經項目經理同意確認。

• 目的

• 范圍

• 評審分類

• 評審內容

• 評審方式

• 評審結束標準

如下：

1.

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

2.

優先極安排是否合理。 ?

3.

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

4.

用例是否具有很好可執行性。