一、前言
在一個完整的測試流程中，測試用例是很核心的一個產出物。一份優秀的測試用例，能確保軟件產品質量的可控。但由於每個人思維局限性，對產品背景、需求、功能實現邏輯等理解深度不一致，編寫的測試用例或多或少存在一些遺漏點，就算是高級測試工程師，甚至是專家級的，也不能百分百保證說自己寫的測試用例質量沒有問題。因此，測試用例評審工作就顯得至關重要。
二、測試用例評審形式
按正式程度來說：
- 會議評審
一種正式評審，需要以會議室且投屏的形式，進行評審活動
- 非會議評審
不需要開會，可以是項目組的成員對測試用例的書面檢查。
按參與角色來說：
- 測試組評審
測試組內部成員參與的評審。當一份測試用例初稿完成后，一般先進行測試組內部評審。評審內容側重在測試思維完整系統性、確保對需求是可追溯且高覆蓋的。尤其是當測試團隊有測試新人時，測試思維完整性不夠，測試組內部評審必不可少。
- 項目組評審
即整個項目團隊人員參與的評審。一般在測試組評審之后進行。包括項目經理、開發人員、架構設計人員、測試人員、產品需求人員，另外像配置管理人員、運營人員具備評審能力都應積極參與。開發人員會注重用例對程序邏輯的覆蓋，產品需求人員會注重業務覆蓋，另外可確保測試、開發、產品對於需求理解的一致性。
- 客戶評審
如果是外包項目，可能會有客戶方的代表，例如客戶方業務人員參與的評審。一般在外包公司較常見。
三、測試用例評審流程
- 評審計划
一次高效的用例評審活動，是需要提前做好評審計划的。計划中需要明確：本次評審的目的、評審范圍、參與人員的角色與職責、評審過程及形式、評審通過准則等。像用例評審檢 查清單(見最后附件模板)一般在此環節整理完成。
- 發起評審通知
待評審文檔即測試用例編寫完成，即可發起評審通知。用例初稿完成后，先在測試組內部發起，內部確認用例ok，再到整個項目組評審通知。一般至少用例評審活動前2天發起評審通知，可以是OA通知、郵件通知、或者釘釘/QQ討論群發布信息。通知內容包括：評審時間、地點、參與人員、待評審文檔(測試用例文檔)、評審內容(評審檢查清單)。這樣在正式評審活動之前，評審人員可先行檢查用例並記錄標注問題，提交匯總到測試負責人，保證后續會議評審效率。
- 用例評審
測試組內部評審，一般評審彼此的用例，以文檔檢查的形式居多。若需求業務邏輯復雜，視情況開展會議評審。項目組評審主要是會議評審。
會議評審，一般測試負責人(參與測試的測試團隊負責人，可能是測試主管、也可能是臨時小組長)為會議主持人，會議評審開始時，一般先會大致介紹用例編寫的思路，可以按照核心業務流程展開評審，再到各個不同的模塊的用例設計，重點包括測試驗證點、測試數據、預期輸出。同時針對被指出的用例問題組織討論並做好用例標記記錄。會后，整理問題清單，並明確問題責任人。
- 問題跟蹤
評審會議后，針對用例問題清單，需及時修改測試用例。修改完成后，發給評審組成員確認，直到已達評審通過准則，評審結束。否則需采取二次甚至多次評審。
- 評審結束
評審結束后，測試負責人整理測試用例評審報告(見最后附件模板)、評審結果項目經理同意確認。測試用例評審通過后形成終版並完成歸檔。
四、總結
作為從業8年的軟件測試工程師，經常有接觸到一些測試從業者的感慨，例”公司用例不會要求去寫、更別說測試用例評審工作了!” 首先關於測試用例，如果因為項目時間關系，可以做弱化，比如可以用xmind整理下測試大綱，但不能沒有，它是必須！另外測試用例評審工作，大部分公司是沒有這個環節的，其實評審工作可以幫助測試團隊更早地發現測試過程中的問題，可以預防問題被帶入發布階段而導致多次返工。從時間和人力成本上來說都是很有必要實施的一項測試活動。最后，希望本文章給正在推行評審流程的你，一些幫助。
附用例評審檢查清單，僅供參考
附用例評審報告，僅供參考
