一、用例評審是什么？

自我理解：用例寫完了之后，不代表這份用例寫的都是正確的，場景覆蓋是全的，需要在多方人員進行查漏補缺，所以我的理解是：用例評審是產品、開發、測試一起對寫好的用例進行一個review的過程。

測試用例評審是產品，開發、測試三者再一次對需求的充分理解和考慮，是對需求合理性的再一次驗證過程。一個完善的測試流程必須有測試用例評審， 要積極推動測試用例評審。

如果用例都沒有評審，直接去執行，可能會存在一些問題。

二、用例評審參會人員：產品、開發、測試。

詳細一點的話，就是 制定該需求的產品，實現該產品的前端開發、后端開發，負責該需求用例編寫的測試人員，負責該需求用例執行的測試人員。

三、用例評審在什么時候進行：開發提測前。

可能目前大部分公司的現狀：開發提測后（不建議此時評審）

一般我們會提前一天通知相關人員，並且預約好我們公司的會議室，看大家時間是否方便。

用例評審的作用

一個開發、測試、產品碰撞自己理解需求是否正確的過程;

於開發來說：需查閱用例，是否有自己未考慮到的場景，自己未注意到的需求，或者發現自己對需求理解歧義的地方。

與測試而言：也是發現自己用例中是否存在場景欠缺，需求遺漏的過程

產品也是在其中查看測試的測試范圍、測試場景、測試重點是否存在偏差與遺漏…

用例評審的作用最大化，就是在開發提測前評審。如若開發提測了再進行評審，用處大減!

四、用例評審前准備：

1.首先我會在用例評審前先把用例給測試小組評審一遍，看看有沒有什么問題

2.在用例評審前，會先把相關用例、需求頁面、開發設計頁面、原型圖打開

3.用例較多時，用例評審前會標注好 前端用例、后端用例，方便在用例評審的時候，分開去review，前后端分開，省時

4.在用例評審前，將自己寫好的用例發給相關人員，提前查閱

5.評審前五分鍾，提前去會議室做好review的准備

6.若需求有不確定或變更，評審測試點即可

五、用例評審的幾點建議參考：

1.時長 最好控制在1H，若東西太多，可以分多次review

2.設計時，表達要准確(盡量采用開發/標准的表述)

3.可視化結合：針對頁面時，還是需先打開 對應的UI頁面/原型/設計圖

4.陳述時，要有主題和層級，若主題/層次 切換，要有對應的過渡~

5.對有歧義的問題，要提醒對應的開發(最好是在評審前找對應的開發/產品確認下)

6.評審過程中，參與人員會存在 視覺和聽覺疲勞，主講人要 抓住重點和重要人員

7.評審過程中的問題，要及時做好標記

8.用例評審后，需對用例評審中的問題，跟進/補充用例/告知大家已完善

9.用例修改后，需對用例進行管理

10.測試覆蓋率和測試點覆蓋是否充分