優測雲服務平臺是移動雲測試平臺，擁有50餘名測試領域專家，300餘人專業測試團隊，10餘年終端測試服務經驗，提供兼容性測試、自動化測試、雲真機，設備分享等多種服務方式。
最近的用例評審讓我感受頗深，以下是我對於測試用例評審的一些感受，發出來供大家討論學習。
聽聽大家對測試用例評審的吐槽？
“測試用例設計是測試的事情，爲什麼評審要我們參加？”
“測試用例已經很多了，不知道需要評審什麼，我能提供什麼？”
“用例評審太枯燥了，200個用例case用一條一條評嗎？”
“這個是別人的開發的功能，跟我沒關係。”
相信以上幾句話是評審時常聽到的話，那麼爲什麼要進行測試用例評審？
這裏從參與用例評審幾個角色來（測試、開發、產品經理、項目經理）分析下進行用例評審的目的以及意義。
測試：
由於不同測試同學對於需求的理解和用例設計都不同，爲了提升用例的完整性、合理性、高效性，可以通過評審的方式，收斂不同人以及不同專業的意見，豐富測試用例。測試是無窮盡的，沒有人能保證自己的設計用例覆蓋完全。
開發：
測試和開發對於需求理解未達成一致，通過評審與開發對需求進行double check，保證在測試前對需求理解的一致性，以免執行測試過程中產生爭議和扯皮。
暴漏出開發在實現過程中代碼邏輯考慮不充分的地方，提前預警，避免邏輯處理考慮不充分導致的缺陷。
開發可以從實現層面評審用例，補充測試用例中，由於測試人員不瞭解實現過程導致的測試用例缺失的情況。
產品經理：
經常在測試用例設計的階段，有些細節是無法從需求文檔上得知的，需要頻繁來和產品經理進行溝通；有些沒有溝通到就存在理解不一致或者考慮不充分的地方。產品經理參與用例評審，他們能幫助你找出更多的問題，同時在評審的過程中，你也能幫助產品經理髮現一些他在產品設計過程中考慮不充分的地方。好的測試用例會比需求文檔要更具體。
項目經理：
通過用例評審不但可以評審測試用例是否足夠覆蓋所有需求邏輯，還可以通過評審的的手段來評估測試的工作量。如果100個用例可以用2個人1天進行，那麼可以根據測試用例的數量可以安排測試的時間。當然不同的用例執行的時間可能不同，但是用例的多少確實某種程度上可以衡量人力消耗的成本。
所以項目經理在這個評審的過程中，需要評審測試用例的覆蓋度以及冗餘性。
1、進行評審的時機
首先，我們要說用例設計的時間，一定要在需求評審後就需要進行初步的用例設計，無論用例設計時經過多少深思熟慮，過一兩天都會忘掉一部分當時的思路，所以先做好整理和記錄。在參與開發的技術評審後，根據開發對需求的實現方式，進行修正和補充。
用例評審最好的時間是在開發中期階段：
如果開發前期階段發起用例評審，可能開發的技術評審還沒開始，測試也沒有足夠的時間去整理測試設計的思路，導致用例質量不高。如果開發完畢階段發起用例評審，在用例評審過程中暴漏的問題很可能是產品經理和開發考慮不充分或者理解不一致造成的，問題暴漏較晚，會導致返工或者版本延期。
2、評審的流程
測試人員確定評審日期和參與評審人員
評審前2天，測試用例發給所有評審人員
評審人員記錄測試用例問題
評審會議，測試用例編寫人員講解用例，參與人員提出評審
會議結束，修改用例，並郵件輸出
3、評審的內容
1、描述是否清晰，是否存在二義性
2、內容是否完整,是否清楚包含輸入條件和預期輸出結果並無爭議點
3、是否覆蓋了所有場景、邏輯分支、限制條件等
4、是否哪些需求不可測：無法準備環境、可測試性達不到等等原因
5、是否考慮到測試用例的執行效率（冗餘的用例）
4、最後囉嗦幾句
在用例評審過程中往往出現一個現象，參與評審用例的評審人員參與度不高，用例評審的效果較差。
通常，在用例評審中，測試人員不是先闡述自己的用例的設計思路，而是直接就說具體執行的案例。通常一個輸入條件，不同的場景、不同的操作步驟，可能生成很多用例case;如果一條一條的評審確實很枯燥；而且很多用例case都是正常邏輯的，評審的意義不到。
當測試問：“還有什麼需要補充的嗎？”，估計開發也看得暈菜啦。如果測試人員能調整下，評審的時候先闡述設計的思路，可以通過流程圖、用例圖、時序圖、狀態圖等輔助手段來幫助清晰用例設計的思路以及明確測試要點；開發在評審的過程中也容易參與進來，加強互動性；然後在評審用例case，並以異常case爲主，正常邏輯的用例case儘量一語帶過,提高用例評審的效率，相信這樣評審人員參與度會提高。