轉載請註明出處❤️
作者：測試蔡坨坨
原文連結：caituotuo.top/90b47990.html
你好，我是測試蔡坨坨。
眾所周知，對於測試同學來說，在軟體研發流程中有兩個重要的會議，一個是需求評審會議（關於需求評審可參考往期文章「需求評審，測試人員應該發揮怎樣的價值？兩分鐘讓你不再懵逼」），另一個是用例評審會議。
不知道大家把“用例評審”放在了什麼樣的“地位”。
在我看來，用例評審是測試流程中不可或缺的一環，用例評審很多測試人員不重視，但是往往不重視的環節其實做好了可以起到意想不到的效果。
所以，今天我們就來聊一聊測試用例評審。
什麼是用例評審
當我們寫完測試用例後，並不代表這份用例都是正確的，所有場景都已經覆蓋到，所以需要多方人員進行查缺補漏。
簡而言之，用例評審就是產品、開發、測試一起對寫好的測試用例進行review的過程。
參會人員
用例評審一定是要求產品（制定該需求的產品經理）、開發（實現該產品的前後端開發人員）、測試（負責該需求用例編寫和執行的測試人員）都參與。
會議由測試人員主導，相應需求的測試同學依次上去講解自己的測試用例。
何時進行
用例評審會議是在開發提測之前，一般會提前一天通知相關人員，並預約好會議室，確定大家時間是否方便。
會前準備
在用例評審之前需要確保測試用例編寫基本完成，可以先把用例給測試小組的同事先評審一遍，看看有沒有什麼問題。
提前五分鐘到達會議室做準備，把測試用例、需求頁面、原型圖、開發設計頁面、UI圖等都開啟。
用例較多時，提前做好標註，哪些是優先順序比較高的，哪些是前端用例，哪些是後端用例，哪些是有疑問的點，方便側重點評審，省時省力，而不是每條用例都需要評審。
還可以將測試用例給到相關人員提前查閱。
作用
對於產品經理：
- 檢查測試人員是否準確理解需求，確保每個需求點都覆蓋到。
- 透過評審正常和異常的測試用例，來反思當時設計需求時未考慮的情況，也是自我回溯的一個過程。
對於開發人員：
- 檢查自己的程式程式碼是否還有很多情況未考慮完善，對自己的程式碼也是一個自我回溯檢查的過程，間接實現了測試左移。
- 對於用例中無法實現的邏輯及時溝通，三方達成高度一致。
對於測試人員：
測試人員作為用例評審會議的主角，作用就不必多說了。
會後
用例評審會議後，需要對評審中的問題進行跟進和完善。
- 需要產品經理補充和修改的點需要讓其在需求文件和原型圖上進行記錄
- 對遺漏的測試點進行補充，對有誤的測試點進行修正，並對用例進行管理
其他注意事項
- 會議時長最好控制在1個小時之內，如果內容較多，可分多次評審
- 結合視覺化介面，針對頁面測試點可提前開啟原型圖、UI圖、設計圖等
- 陳述時要表達清晰，有主題和層次，比如上來可以先介紹一下你這個需求是幹嘛的，然後再分部分細講
- 對於有歧義的問題，需要與產品和開發同學確認清楚
- 評審過程中，參會人員可能會有視覺和聽覺疲勞，主講人要抓住重點和重要人員
- 對於評審過程中的問題，及時做好標記