如何高效開展測試用例評審？附用例評審檢查清單及用例評審報告模板

1、前言

       在一個完整的測試流程中，測試用例是很核心的一個產出物。一份優秀的測試用例，能確保軟件產品質量的可控。但因爲每一個人思惟侷限性，對產品背景、需求、功能實現邏輯等理解深度不一致，編寫的測試用例或多或少存在一些遺漏點，就算是高級測試工程師，甚至是專家級的，也不能百分百保證說本身寫的測試用例質量沒有問題。所以，測試用例評審工做就顯得相當重要。

 

2、測試用例評審形式

按正式程度來講：

• 會議評審

          一種正式評審，須要以會議室且投屏的形式，進行評審活動

• 非會議評審

          不須要開會，能夠是項目組的成員對測試用例的書面檢查。

按參與角色來講：

•  測試組評審

           測試組內部成員參與的評審。當一份測試用例初稿完成後，通常先進行測試組內部評審。評審內容側重在測試思惟完整系統性、確保對需求是可追溯且高覆蓋的。尤爲是當測試團隊有測試新人時，測試思惟完整性不夠，測試組內部評審必不可少。

• 項目組評審

           即整個項目團隊人員參與的評審。通常在測試組評審以後進行。包括項目經理、開發人員、架構設計人員、測試人員、產品需求人員，另外像配置管理人員、運營人員具有評審能力都應積極參與。開發人員會注重用例對程序邏輯的覆蓋，產品需求人員會注重業務覆蓋，另外可確保測試、開發、產品對於需求理解的一致性。

• 客戶評審

          若是是外包項目，可能會有客戶方的表明，例如客戶方業務人員參與的評審。通常在外包公司較常見。

 

3、測試用例評審流程

 

• 評審計劃

          一次高效的用例評審活動，是須要提早作好評審計劃的。計劃中須要明確：本次評審的目的、評審範圍、參與人員的角色與職責、評審過程及形式、評審經過準則等。像用例評審檢 查清單(見最後附件模板)通常在此環節整理完成。

• 發起評審通知

          待評審文檔即測試用例編寫完成，便可發起評審通知。用例初稿完成後，先在測試組內部發起，內部確認用例ok，再到整個項目組評審通知。通常至少用例評審活動前2天發起評審通知，能夠是OA通知、郵件通知、或者釘釘/QQ討論羣發佈信息。通知內容包括：評審時間、地點、參與人員、待評審文檔(測試用例文檔)、評審內容(評審檢查清單)。這樣在正式評審活動以前，評審人員可先行檢查用例並記錄標註問題，提交匯總到測試負責人，保證後續會議評審效率。

• 用例評審

          測試組內部評審，通常評審彼此的用例，以文檔檢查的形式居多。若需求業務邏輯複雜，視狀況開展會議評審。項目組評審主要是會議評審。

          會議評審，通常測試負責人(參與測試的測試團隊負責人，多是測試主管、也多是臨時小組長)爲會議主持人，會議評審開始時，通常先會大體介紹用例編寫的思路，能夠按照核心業務流程展開評審，再到各個不一樣的模塊的用例設計，重點包括測試驗證點、測試數據、預期輸出。同時針對被指出的用例問題組織討論並作好用例標記記錄。會後，整理問題清單，並明確問題責任人。

• 問題跟蹤

          評審會議後，針對用例問題清單，需及時修改測試用例。修改完成後，發給評審組成員確認，直到已達評審經過準則，評審結束。不然需採起二次甚至屢次評審。

• 評審結束

          評審結束後，測試負責人整理測試用例評審報告(見最後附件模板)、評審結果項目經理贊成確認。測試用例評審經過後造成終版並完成歸檔。

 

4、總結

        做爲從業8年的軟件測試工程師，常常有接觸到一些測試從業者的感慨，例」公司用例不會要求去寫、更別說測試用例評審工做了!」 首先關於測試用例，若是由於項目時間關係，能夠作弱化，好比能夠用xmind整理下測試大綱，但不能沒有，它是必須！另外測試用例評審工做，大部分公司是沒有這個環節的，其實評審工做能夠幫助測試團隊更早地發現測試過程當中的問題，能夠預防問題被帶入發佈階段而致使屢次返工。從時間和人力成本上來講都是頗有必要實施的一項測試活動。最後，但願本文章給正在推行評審流程的你，一些幫助。

 

附用例評審檢查清單，僅供參考

 附用例評審報告，僅供參考