本文章轉載于搜狗測試

一位測試工程師在自己的經驗、知識、思維的束縛下，總是存在一些設計屏障，致使用例缺失，從而可能導致一個隱藏的卻很嚴重的線上事故發生，故多位測試工程師聚集在一起，進行一場用例評審顯得尤為重要，小編對組內的用例評審流程規范和方法進行了如下總結，請大家參考。

用例評審時間

在項目測試階段，有重要模塊改動或者全新模塊需求時，對相應的用例設計大綱要進行評審。

評審用例時間盡量選擇在一輪測試之前，不應該晚于二輪測試。

用例評審內容

項目測試階段，重要模塊改動或者全新模塊需求的用例需要評審。用例評審內容來源渠道：

1、項目負責人（即，負責項目質量、進度的測試人員）負責收集當前版本需要評審的用例，也要及時上報評審。（該渠道為評審用例的主要來源）

2、組內人員主動希望進行評審的用例也可以進行上報評審。

3、如果用例非常龐大且時間緊張的情況，用例評審人需要整理出重要的邏輯，從而在時間緊張的情況，可以讓用例評審參與人集中評審重要邏輯部分。

用例評審準備

1、用例評審人要在評審前將需求、測試大綱準備好。

2、用例評審人需要在評審前將需求中，存在明顯問題的內容進行確認。

3、用例評審人需要將測試大綱結構整理清楚，評審時不能存在嚴重的結構問題，以免影響到整體用例評審效率和進度。（如果用例評審人對自己的用例結構有所疑惑，應該找到項目負責人或者用例評審負責人進行初審）

用例評審會議邀請

1、用例評審負責人（大家可以選出一個專人，對用例評審進行組織負責，即為用例評審負責人）負責與各個平臺項目組負責人協調具體會議時間，并且發送會議邀請。

2、會議邀請中，要包含需求、用例設計大綱。

用例評審會議流程

1、用例評審參與者盡量提前閱讀了解需求。

2、用例評審人講解需求。

3、用例評審參與人員對需求提出問題，用例評審人進行解答。

4、對于流程性較強的，用例評審人需要給大家梳理一次流程，最好有提前準備好的流程圖。（不建議現場畫制）

5、用例評審人講解測試大綱，按照用例層次講解；首先對自己的子功能、子子功能劃分情況進行說明；之后到檢查點；最后到影響因素。

6、在5的整個過程中，用例評審參與人員可以隨時對評審人員的用例進行提問、給出建議等。

7、用例評審人要積極準備，用例評審參與人員要積極發言。

8、最后會議記錄者要將會議記錄及時發出，做好todo備忘。

9、本次會議完成。

用例評審會議內容

1、用例結構

前面已經提到少做用例結構的評審（是為了用更多的精力去擴大用例覆蓋度），但是對于一些典型的功能模塊，可以適當進行用例結構評審。例如一些流程較多，較復雜的，大家可以一起梳理一下流程，同時對用例結構完成檢查評審。

2、代碼層面

對于一些較為復雜的功能模塊，有些甚至不涉及到界面，只是一些內部方法的邏輯處理（如果瀏覽器的熱修復、云同步等功能），需要挖掘到類和方法層面，故用例評審人要了解代碼實現，并進行講解。

3、影響因素發散

對于使用場景較為復雜的功能模塊，需要重點進行影響因素的評審，大家在了解需求和實現流程的基礎上，一起進行影響因素的發散思考，將各種場景在用例設計階段思考到位。

4、服務端用例設計

對于服務端的用例，要單獨進行用例設計，與客戶端分離評審。必要時，需要設計接口測試相關用例。

用例評審后期

1、用例評審人修改用例后，需要將大家的審核建議整理后，修改測試大綱，并且更新到SVN上。

2、用例評審人要將會議中的建立的todo完成，如與開發、產品溝通某些會上提到的細節問題、完善模塊說明文檔等。