測試用例評審

轉載

測試用例評審

首先要清楚內部評審的定義，是測試組內部的評審，仍是項目組內部的評審。評審的定義不一樣，內容也不會相同。

一.評審分類：

 

測試組內部評審

測試組內部的評審，應該着重於：

1. 測試用例自己的描述是否清晰，是否存在二義性；
2. 是否考慮到測試用例的執行效率，每每測試用例中步驟不斷重複執行，驗證點卻不一樣，並且測試設計的冗餘性，都形成了效率的低下；
3. 是否針對需求跟蹤矩陣，覆蓋了全部的軟件需求；
4. 是否徹底遵照了軟件需求的規定。這並不必定的，由於即便再嚴格的評審，也會出現錯誤，應具體狀況具體對待。

項目組內部評審

若是是項目組內部的評審，也就須要評審委員會來作了，角度不一樣，評審的標準也不一樣。好比：

1. 收集客戶需求的人員注重你的業務邏輯是否正確；
2. 分析軟件需求規格的人注重你的用例是否跟規格要求一致；
3. 開發負責人會注重你的用例中對程序的要求是否合理。

二.測試用例評審步驟

測試用例的評審可以使用例的結構更清晰，覆蓋的用戶場景更全面；對於測試工程師來講也是一個快速提升用例設計能力的過程。

1.須要評審的緣由

測試用例是軟件測試的準則，但它並非一經編制完成就成爲準則。因爲用例開發人員的設計經驗和對需求理解的深度各不相同，因此用例的質量不免會有不一樣程度的差別。

2.進行評審的時機

第一，是在用例的初步設計完成以後進行評審；
第二是在整個詳細用例所有完成以後進行二次評審。若是項目時間比較緊張，儘量保證對用例設計進行評審，提早發現其中的不足之處。

3.參與評審人員

• 部門評審，測試部門全體成員參與的評審。
• 公司評審，這裏包括了項目經理、需求分析人員、架構設計人員、開發人員和測試人員。
• 客戶評審，包括了客戶方的開發人員和測試人員。這種狀況在外包公司比較常見。

4.評審類容

1. 用例設計的結構安排是否清晰、合理，是否利於高效對需求進行覆蓋。
2. 優先極安排是否合理。
3. 是否覆蓋測試需求上的全部功能點。
4. 用例是否具備很好可執行性。例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法。
5. 是否已經刪除了冗餘的用例。
6. 是否包含充分的負面測試用例。充分的定義，若是在這裏使用2&8法則，那就是4倍於正面用例的數量，畢竟一個健壯的軟件，其中80%的代碼 都是在「保護」20%的功能實現。
7. 是否從用戶層面來設計用戶使用場景和使用流程的測試用例。
8. 是否簡潔，複用性強。例如，可將重複度高的步驟或過程抽取出來定義爲一些可複用標準步驟。

我的認爲，一個「健康」的測試用例至少要經過前5個標準。

五、評審的方式

1. 召開評審會議。與會者在設計人員講解以後給出意見和建議，同時進行詳細的評審記錄。
2. 通用郵件與相關人員溝通
3. 通用IM工具直接與相關人員交流方式只是手段，獲得其它人員對於用例的反饋信息纔是目的。不管採用那種方式，都應該在溝通以前把用例設計的相關文檔發送給對方進行前期的學習和了解，以節省溝通成本。

六、評審結束標準

在評審活動中會收集到用例的反饋信息，在此基礎上進行用例更新，直到經過評審。