測試用例評審：開發、產品、測試人員都覆蓋了哪些內容？

我們經常會聽到開發對測試抱怨說：這個問題怎麼現在才測出來，這個問題怎麼暴露到線上了，測試都是怎麼測的？ 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

為了消除誤解，讓開發瞭解到底測試都覆蓋了哪些內容，雙方更好的配合，保障線上版本質量，測試用例的評審就顯得十分重要。

測試用例評審的參與人員是：開發、產品、測試人員。

產品人員參與，可以方便核對測試用例是否覆蓋產品需求，在評審的過程中完善產品說明文件，完善產品的邏輯。

開發人員參與用例評審，可以從程式碼實現角度給出建議，防止漏測或過度測試，保證測試的全面性，減少無效測試，增加重點模組的測試。

測試人員參與用例評審，可以審查用例是否規範，對於互動模組的用例覆蓋的是否齊全。

預審時需要提供xmind思維導圖檔案，xmind思維導圖需要包含全部用例的設計思路及測試功能點，並重點標註出有疑問的測試點。

在評審前一天提前發出給相關與會人，預留時間給研發和產品先過下用例的內容，留意會議側重點。

評審中的要求

對於敏捷開發專案，會議時間一般建議控制在半小時以內，超過這個時間就需要中場休息了，因為人持續集中注意力的時間基本只有二十分鐘。為了保障評審效果，需要採取一些有效策略。

測試用例評審使用xmind軟體，這樣評審時更容易直觀的看到結構樹和層級關係，方便參評人員一目瞭然，更快的搞懂設計者要表達的意思。

複雜的功能在開始前先概述下文件構成，然後按照檔案順序講解。

切記不可一馬平川讀到底，應該重點抓用例設計時存疑的地方，然後三方確認，這個時候預審是標註的有疑惑的地方就派上用場了。

簡言之，對功能點劃分優先順序，優先評審優先順序高的用例，再針對疑問多的用例評審，最後對於功能簡單的用例可簡單帶過。

時刻記住我們用例的評審目標，不能流於形式。對於評審過程中，一時半會沒有結論的問題，可以記錄下來，作為會後討論跟進的重點。

功能舉例如下：在商品詳情頁，進行中的拼團列表，點選“去拼團”會進入拼團詳情頁。

原始版的用例如下圖：

實際上還應考慮一些瞬時場景和一些異常情況：比如點開頁面後團購結束，點選頁面時小程式賬號還未登入等。

另外，因為測試用例評審和開發程式碼設計是同步進行的，所以在評審過程中，稍微複雜的沒有把握的功能可以與開發確認實現方式。

比如，哪些資料是從介面獲取的，哪些資料是從其他頁面的介面請求帶過來的，哪些是前端寫死的，哪些頁面有必要實時重新整理，哪些頁面無需已進入就重新整理。

透過探討，明確可能的bug重災區，設計一些合理的處理方式，從根源上遏制bug的出現。

評審後的收尾

用例評審完成之後，需要及時整理會上的評審意見，形成會議紀要併傳送郵件。

同時測試人員需要根據會議上各方建議進行測試用例的修改完善，再將整理補充後的用例同步給專案相關人員，試具體情況確定是否有必要進行二輪評審。

若無其他問題則將用例整理後即可定稿等待執行。該用例經過評審的集思廣益之後，補充如下：

可以我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！，其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！