怎樣做好測試用例的評審

大家都知道，軟體測試過程中，最重要的就是測試用例的設計。首先說說測試用例的重要性。

一、編寫用例的重要性

1.深入了解需求的過程，一個項目立項開始，測試就開始介入，我們從產品的PRD文檔、用戶交互圖，視覺圖等相關文檔去熟悉產品的各個模塊，各個業務流程。或者在產品規劃和設計階段，測試開始熟悉產品。而編寫用例的過程中，會充分的思考產品需求的細枝末節，需求的不合理、有矛盾、不明確的地方，還能對產品提出更好的建議，監督產品對需求做出更加詳細的設計。整個過程是對需求深入了解的過程，產品的整個印象都在測試腦海里。

2.測試執行的指導，用例編寫是把產品需求轉換為一種可操作步驟的行為，方便以後作為測試的標準，有步驟有計劃的進行測試。如果沒有這個標準，會使你的測試過程無計劃，無目標，變成一個放任主流的狀態，完全沒有受控性。這樣的產品質量保證顯然是空談。

3.規劃測試數據的準備，在我們的實踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤其象測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據

4.反應測試進度，測試人員開始按照測試用例的描述測試，每過完一個用例標記完成；這樣測試也知道自己做過哪些操作，避免沒有目的隨機測試。並且通過測試用例的執行條數，大致了解該模塊的測試進度。

5.舉一反三發現潛藏缺陷，測試人員在執行用例的過程中往往會突然發現當初設計的用例步驟中，還可以做這樣一個操作，於是發現了bug，這又體現了測試用例的作用， 幫助發現拓展測試範圍，擴大測試覆蓋面，發現軟體中潛藏的缺陷。

6.分析缺陷的標準

既然測試用例的重要性可想而知，那麼用例評審更加重要，用例評審即是對用例的評議和審查，是必須的過程。在工作過程中，對於測試用例的評審，分享幾點自己的心得。

二、用例評審內容

1.是否覆蓋測試需求上的所有功能點，不違背產品原型和代碼設計，用例設計的結構安排是否清晰合理，有利於高效覆蓋需求

2.用例是否具有可執行性，前提條件、執行步驟和預期結果是否正確，有明確的驗證方法。優先順序安排是否合理

3.是否從用戶層面來設計用戶使用的場景和業務流程

4.是否包含充分的異常測試用例

5.是否簡潔，不冗餘，復用性強

三、用例評審過程

1.提前發出初稿和會議邀約，至少提前一天發出用例初稿，並確定參與用例評審人員，以便項目經理，產品和開發提前閱讀用例，讓會議更有效率的進行

2.先做簡單的業務流程介紹，這個是在評審開始尤為重要的一個過程，剛開始評審，參與人員會比較蒙圈，產品和開發都不知道測試的思路，或者半途加入新的開發和測試，對需求和業務都不夠熟悉，如何讓評審快速進入狀態，先做簡單的需求業務流程介紹，說明白打算如何去做評審。

【舉個栗子】一個項目有用戶體系、電子賬戶、理財、生活模塊，可以先由大到小的細分下去；可用事先畫好的腦圖，各種流程圖，也可當場快速寫上板書。

3.按模塊進行，有些模塊，業務性不是特彆強的，可以簡單說下有哪些模塊，每個模塊評審的時候，按測試項分類，UI、核心功能、基礎功能、邊界測試、兼容測試和異常測試等，預期結果類似的，主要講清楚用例主題，讓參與人員知道每條用例是做什麼的。

4.按業務流程進行，業務流程性較強的需求，需要有業務場景和邏輯，按一定的順序來，讓參與人跟著你的思想，避免東一句西一句，

【舉個栗子】一個理財活期產品的測試用例評審，購買和贖回，跑批時間段分日間和日終，工作日和周末四個場景，按不同場景分為不同的業務流程進行評審，有理有據，邏輯思路清晰。

5.按測試數據進行，涉及到計算邏輯、收益、報表等需求的，用例編寫時會先規劃好測試數據，儘管測試數據也是按不同的業務場景來設計的，但直接用測試數據來評審你的測試點，會更清晰，跟上你思路的開發和產品會對應上自己的產品設計和代碼設計去評審你的測試點是否不合理或覆蓋率不全的地方，從而有效的評審測試用例。

三、用例評審後的確認

為了節約時間成本，第一次評審盡量對用例設計全面考慮，提前發現其中的不足之處；但是第一次評審難免會要修修補補的地方，在評審時儘快的修復，不能在一兩分鐘修復的，記錄下來，在會議結束後進行修改，如果改動不是很多的，可以發出郵件，標明修改部分，再最後確認最終版。如果需要進行二次評審，那麼重新開始邀約會議做二次評審。

四、用例評審需要避免

1.測試點含糊用語，每個用例評審都應該確定最終版，稍有矛盾或疑惑的需求點，都應該確認下來，不能含糊不清。

2.雜亂無章的評審，有順序有邏輯的進行評審是很重要的一點，如果臆想按照自己的思路評審，不顧他人感受，那麼就等同於做無用功。這樣的用例執行出來也會有一定的質量風險。