文/ 騰訊 孫麗晶

最近的用例評審讓我感受頗深，以下是我對于測試用例評審的一些感受，發(fā)出來供大家討論學習。

聽聽大家對測試用例評審的吐槽？

“測試用例設計是測試的事情，為什么評審要我們參加？”

“測試用例已經很多了，不知道需要評審什么，我能提供什么？”

“用例評審太枯燥了，200個用例case用一條一條評嗎？”

“這個是別人的開發(fā)的功能，跟我沒關系?！?/span>

相信以上幾句話是評審時常聽到的話，那么為什么要進行測試用例評審？

這里從參與用例評審幾個角色來（測試、開發(fā)、產品經理、項目經理）分析下進行用例評審的目的以及意義。

首先，我們要說用例設計的時間，一定要在需求評審后就需要進行初步的用例設計，無論用例設計時經過多少深思熟慮，過一兩天都會忘掉一部分當時的思路，所以先做好整理和記錄。在參與開發(fā)的技術評審后，根據開發(fā)對需求的實現方式，進行修正和補充。

用例評審最好的時間是在開發(fā)中期階段：

如果開發(fā)前期階段發(fā)起用例評審，可能開發(fā)的技術評審還沒開始，測試也沒有足夠的時間去整理測試設計的思路，導致用例質量不高。如果開發(fā)完畢階段發(fā)起用例評審，在用例評審過程中暴漏的問題很可能是產品經理和開發(fā)考慮不充分或者理解不一致造成的，問題暴漏較晚，會導致返工或者版本延期。

1. 測試人員確定評審日期和參與評審人員

2. 評審前2天，測試用例發(fā)給所有評審人員

3. 評審人員記錄測試用例問題

4. 評審會議，測試用例編寫人員講解用例，參與人員提出評審

5. 會議結束，修改用例，并郵件輸出

1、描述是否清晰，是否存在二義性

2、內容是否完整,是否清楚包含輸入條件和預期輸出結果并無爭議點

3、是否覆蓋了所有場景、邏輯分支、限制條件等

4、是否哪些需求不可測：無法準備環(huán)境、可測試性達不到等等原因

5、是否考慮到測試用例的執(zhí)行效率（冗余的用例）

在用例評審過程中往往出現一個現象，參與評審用例的評審人員參與度不高，用例評審的效果較差。

通常，在用例評審中，測試人員不是先闡述自己的用例的設計思路，而是直接就說具體執(zhí)行的案例。通常一個輸入條件，不同的場景、不同的操作步驟，可能生成很多用例case;如果一條一條的評審確實很枯燥；而且很多用例case都是正常邏輯的，評審的意義不到。

當測試問：“還有什么需要補充的嗎？”，估計開發(fā)也看得暈菜啦。如果測試人員能調整下，評審的時候先闡述設計的思路，可以通過流程圖、用例圖、時序圖、狀態(tài)圖等輔助手段來幫助清晰用例設計的思路以及明確測試要點；開發(fā)在評審的過程中也容易參與進來，加強互動性；然后在評審用例case，并以異常case為主，正常邏輯的用例case盡量一語帶過,提高用例評審的效率，相信這樣評審人員參與度會提高。