摘要：
關於用例評審，你是否瞭解用例評審前的準備工作有哪些 ？ 
需要幾輪評審 ？
需要哪些人蔘加 ？ 
評審時長 ？
評審形式 ？ 
評審結束後，還需要做哪些 ？

• 什麼是用例評審？

  用例評審主要是產品、開發和測試人員，針對測試用例能否用於專案的測試而做的工作。

• 用例評審的目的

  為了減少測試人員執行階段做無效工作（執行無效case，提交無效問題） 為了避免三方需求理解不一致； 為了每個測試人員的質量標準與專案要求標準達成一致。

一、評審前需要做哪些準備工作

1、需求評審結束後，就可以著手把需求拆分為功能點 。

工具：建議用XMind，需包含預期結果和測試結果，Android和iOS測試結果可用標籤區分標註。

2、把功能點再分解為具體的測試用例 。

按照實際專案，需在思維導圖上補全預期結果和實際測試結果，便於測試結果跟進。

3、用例寫完後，自己先做好自檢，自檢中，針對有疑問的點羅列出來，可事先跟產品開發討論，確定結果後完善用例，仍有疑問的可先做標記，評審會上丟擲一起討論。

4、和評審人員（開發和產品）確定好具體的評審時間並提前把測試用例以郵件的形式發給參會人員檢視。針對我們的專案郵件抄送考核人。

二、用例評審參加人員

主要是產品、開發（客戶端和後端）、測試、專案負責人。

注：以上人員為必須參加人員，其他和專案質量、進度有關人員，根據實際情況可邀請參加。

三、用例評審時間

對於敏捷開發專案，建議控制在半小時以內。

如果你認為需求複雜，功能點太多，半小時講不完，那麼建議你對功能點劃分優先順序，優先評審優先順序高的用例，再針對疑問多的用例評審，最後對於功能簡單的用例可簡單帶過。時刻記住我們用例的評審目標，不能流於形式。

四、用例評審的形式

1、評審要按用例的優先順序，功能的複雜程度進行；先對功能複雜，優先順序高，疑問多的用例進行評審，再評審功能簡單，優先順序低的功能點。

2、評審過程中儘量做到，思路清晰，用最簡潔的語言闡述每一個功能點；

3、超過5分鐘無法確定結果的問題留作會後討論跟進。對於評審過程中，一時半會沒有結論的問題，可以記錄下來，作為會後討論跟進的重點。

五、評審結束後需要做些什麼事？

評審結束後，第一時間整理測試用例，把修正的內容重新整理補全。修改的功能點用黃色標記。

會上未確定的內容，會後繼續跟進，直到確定結果。如果有遺漏的功能點，新增後用綠色標記。

沒有任何有疑問的地方了，再做個簡單的用例評審會議總結（如修正了哪些功能點（黃色），補全了哪些（綠色）？哪些模組功能有變動（紫色）？哪些功能推遲到下一期做（紅色）？等）

這個總結是給自己整個用例評審工作總結，同時需同步給專案組其他成員，做好資訊共享。