騰訊優測優分享 | 這樣作測試用例評審更高效

騰訊優測是專業的移動雲測試平臺，提供多維度的自動化測試服務，讓測試更簡單！
最近的用例評審讓我感覺頗深，如下是我對於測試用例評審的一些感覺，發出來供你們討論學習。

聽聽你們對測試用例評審的吐槽？

「測試用例設計是測試的事情，爲何評審要咱們參加？」
「測試用例已經不少了，不知道須要評審什麼，我能提供什麼？」
「用例評審太枯燥了，200個用例case用一條一條評嗎？」
「這個是別人的開發的功能，跟我不要緊。」
相信以上幾句話是評審時常聽到的話，那麼爲何要進行測試用例評審？
這裏從參與用例評審幾個角色來（測試、開發、產品經理、項目經理）分析下進行用例評審的目的以及意義。

測試：

因爲不一樣測試同窗對於需求的理解和用例設計都不一樣，爲了提高用例的完整性、合理性、高效性，能夠經過評審的方式，收斂不一樣人以及不一樣專業的意見，豐富測試用例。測試是無窮盡的，沒有人能保證本身的設計用例覆蓋徹底。

開發：

測試和開發對於需求理解未達成一致，經過評審與開發對需求進行double check，保證在測試前對需求理解的一致性，以避免執行測試過程當中產生爭議和扯皮。
暴漏出開發在實現過程當中代碼邏輯考慮不充分的地方，提早預警，避免邏輯處理考慮不充分致使的缺陷。
開發能夠從實現層面評審用例，補充測試用例中，因爲測試人員不瞭解實現過程致使的測試用例缺失的狀況。

產品經理：

常常在測試用例設計的階段，有些細節是沒法從需求文檔上得知的，須要頻繁來和產品經理進行溝通；有些沒有溝通到就存在理解不一致或者考慮不充分的地方。產品經理參與用例評審，他們能幫助你找出更多的問題，同時在評審的過程當中，你也能幫助產品經理髮現一些他在產品設計過程當中考慮不充分的地方。好的測試用例會比需求文檔要更具體。

項目經理：

經過用例評審不但能夠評審測試用例是否足夠覆蓋全部需求邏輯，還能夠經過評審的的手段來評估測試的工做量。若是100個用例能夠用2我的1天進行，那麼能夠根據測試用例的數量能夠安排測試的時間。固然不一樣的用例執行的時間可能不一樣，可是用例的多少確實某種程度上能夠衡量人力消耗的成本。
因此項目經理在這個評審的過程當中，須要評審測試用例的覆蓋度以及冗餘性。

一、進行評審的時機

首先，咱們要說用例設計的時間，必定要在需求評審後就須要進行初步的用例設計，不管用例設計時通過多少深思熟慮，過一兩天都會忘掉一部分當時的思路，因此先作好整理和記錄。在參與開發的技術評審後，根據開發對需求的實現方式，進行修正和補充。
用例評審最好的時間是在開發中期階段：
若是開發前期階段發起用例評審，可能開發的技術評審還沒開始，測試也沒有足夠的時間去整理測試設計的思路，致使用例質量不高。若是開發完畢階段發起用例評審，在用例評審過程當中暴漏的問題極可能是產品經理和開發考慮不充分或者理解不一致形成的，問題暴漏較晚，會致使返工或者版本延期。

二、評審的流程

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

2. 評審前2天，測試用例發給全部評審人員

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

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

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

三、評審的內容

一、描述是否清晰，是否存在二義性
二、內容是否完整,是否清楚包含輸入條件和預期輸出結果並沒有爭議點
三、是否覆蓋了全部場景、邏輯分支、限制條件等
四、是否哪些需求不可測：沒法準備環境、可測試性達不到等等緣由
五、是否考慮到測試用例的執行效率（冗餘的用例）

四、最後囉嗦幾句

在用例評審過程當中每每出現一個現象，參與評審用例的評審人員參與度不高，用例評審的效果較差。
一般，在用例評審中，測試人員不是先闡述本身的用例的設計思路，而是直接就說具體執行的案例。一般一個輸入條件，不一樣的場景、不一樣的操做步驟，可能生成不少用例case;若是一條一條的評審確實很枯燥；並且不少用例case都是正常邏輯的，評審的意義不到。
當測試問：「還有什麼須要補充的嗎？」，估計開發也看得暈菜啦。若是測試人員能調整下，評審的時候先闡述設計的思路，能夠經過流程圖、用例圖、時序圖、狀態圖等輔助手段來幫助清晰用例設計的思路以及明確測試要點；開發在評審的過程當中也容易參與進來，增強互動性；而後在評審用例case，並以異常case爲主，正常邏輯的用例case儘可能一語帶過,提升用例評審的效率，相信這樣評審人員參與度會提升。
文/ 騰訊 孫麗晶
__騰訊優測是專業的移動雲測試平臺，爲應用、遊戲、H5混合應用的研發團隊提供產品質量檢測與問題解決服務。不只在線上平臺提供自動化兼容性測試、雲手機遠程租用與調試、漏洞分析、自動化測試工具Xtest等多種質量檢測工具，更爲VIP客戶配備了專家團隊提供定製化綜合測試解決方案。