測試用例評審總結與規範

什麼是用例評審？

用例評審主要是產品、開發和測試人員針對測試用例可否用於項目的測試而作的工做。

·用例評審的目的

爲了減小測試人員執行階段作無效工做；（執行無效case，提交無效問題）
爲了不三方需求理解不一致；
爲了每一個測試人員的質量標準與項目要求標準達成一致。

 

測試用例評審加入測試流程規範並試用2個多月了，期間根據各方人員的反饋，及爲了提升用例評審的效率，特制定如下用例評審規範：

1、評審前須要作哪些準備工做

一、需求評審結束後，就能夠着手把需求拆分爲功能點 。

工具：建議用XMind，需包含預期結果和測試結果，Android和iOS測試結果可用標籤區分標註。 優勢：用畫思惟導圖的方式，邏輯清楚，便於評審人員（產品和開發人員）快速查看，評審效率高。

這裏須要說明的是，不少測試者喜歡用Excel設計用例，我也不例外，可是根據一段時間的試驗，和開發產品溝通後，你們都以爲用XMind寫思惟導圖的方式更好，看起來更便捷。因此具體用什麼工具方法，你們可依我的愛好而定，不過目標是同樣的，讓用例評審高效快捷的開展，併產生價值。

二、把功能點再分解爲具體的測試用例 。   

這裏需在思惟導圖上補全預期結果和實際測試結果，便於測試結果跟進。

三、用例寫完後，本身先作好自檢，自檢中，針對有疑問的點羅列出來，可事先跟產品開發討論，肯定結果後完善用例，仍有疑問的可先作標記，評審會上拋出一塊兒討論。

四、和評審人員（開發和產品）肯定好具體的評審時間並提早把測試用例發給參會人員查看。

2、用例評審參加人員

主要是產品、開發（客戶端和後端）、測試、項目負責人、運營。

注：以上人員爲必須參加人員，其餘和項目質量、進度有關人員，根據實際狀況可邀請參加。

3、用例評審時間

對於敏捷開發項目，建議控制在半小時之內。

若是你認爲需求複雜，功能點太多，半小時講不完，那麼建議你對功能點劃分優先級，優先評審優先級高的用例，再針對疑問多的用例評審，最後對於功能簡單的用例可簡單帶過。時刻記住咱們用例的評審目標，不能流於形式。

4、用例評審的形式

一、對照測試用例，從上而下，從左到右，逐條念。

這是目前不少公司的作法，若是你也這麼作過，相信你並不必定喜歡這種方式，由於它費時，不分主次，參會人員的熱情與注意力逐漸下降，整個用例評審效率低，做爲主持人也講的口乾舌燥，事倍功半。

二、先對功能複雜，優先級高，疑問多的用例進行評審，再評審功能簡單，優先級低的功能點。

對於評審過程當中，一時半會沒有結論的問題，能夠記錄下來，做爲會後討論跟進的重點。

這種作法，有不少優勢，評審剛開始的一段時間，你們注意力集中，參與激情高，這段時間討論有難度有疑問的問題，效率高。最重要的事最早作。

另外，整個評審會主次分明，有高潮有緩點，能夠更高效的達到咱們評審的目的。

5、正式評審

正式評審過程當中須要注意幾個細節，若是你都作到了，那麼能夠說整個評審是成功的，有價值的。

一、評審要按用例的優先級，功能的複雜程度進行；

二、評審過程當中儘可能作到，思路清晰，用最簡潔的語言闡述每個功能點；

三、超過5分鐘沒法肯定結果的問題留做會後討論跟進。

6、評審結束後須要作些什麼事？

不是說評審會結束了，就完事了，其實對於整個用例評審，這才作了一半。     

評審結束後，第一時間整理測試用例，把修正的內容從新整理補全。

會上未肯定的內容，會後繼續跟進，直到肯定結果。

沒有任何有疑問的地方了，再作個簡單的用例評審會議總結（如修正了哪些功能點，補全了哪些？哪些模塊功能有變更？哪些功能推遲到下一期作？等），這個總結是給本身整個用例評審工做總結，同時需同步給項目組其餘成員，作好信息共享，這點很重要。

好了，整個完整的用例評審及須要注意的地方大概就是這些，但願測試組人員認真去看，並落實到具體的工做中。個別地方根據項目實際狀況可靈活變更，最後，有問題歡迎隨時交流溝通。 

做者：木木0524 連接：https://www.jianshu.com/p/3a89f0ffc1ab 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。