如何進行測試用例評審

2021-05-12 13:19:16 字數 2723 閱讀 9819

進行測試用例評審

測試用例評審工作對測試人員能力的提高,測試效率的提高都有很好的作用,那麼如果進行測試用例評審呢?它又哪些標準呢?通過的標準又是什麼呢?

關於「測試用例內部評審的標準」的討論的摘要:

首先要清楚內部評審的定義,是測試組內部的評審,還是專案組內部的評審。評審的定義不同,內容也不會相同。

如果是測試組內部的評審,應該著重於:

1. 測試用例本身的描述是否清晰,是否存在二義性

2.是否考慮到測試用例的執行效率.往往測試用例中步驟不斷重複執行,驗證點卻不同,而且測試設計的冗餘性,都造成了效率的低下

3.是否針對需求跟蹤矩陣,覆蓋了所有的軟體需求,

4.是否完全遵守了軟體需求的規定。這並不一定的,因為即使再嚴格的評審,也會出現錯誤,應具體情況具體對待。

如果是專案組內部的評審,也就需要評審委員會來做了,角度不同,評審的標準也不同。比如:

收集客戶需求的人員注重你的業務邏輯是否正確;

分析軟體需求規格的人注重你的用例是否跟規格要求一致;

開發負責人會注重你的用例中對程式的要求是否合理。

要清楚地一點是:為了保證測試用例設計的質量,以及評審的收益,在提交專案組評審之前,必須通過測試部門或測試組內部的評審。

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個標準。

5、評審的方式

1) 召開評審會議。與會者在設計人員講解之後給出意見和建議,同時進行詳細的評審記錄。

2) 通用郵件與相關人員溝通

3) 通用im工具直接與相關人員交流

方式只是手段,得到其它人員對於用例的反饋資訊才是目的。

無論採用那種方式,都應該在溝通之前把用例設計的相關文件傳送給對方進行前期的學習和了解

,以節省溝通成本。

6、評審結束標準

在評審活動中會收集到用例的反饋資訊,在此基礎上進行用例更新,直到通過評審。

個人愚見,僅參考 ^o^

測試用例評審檢查單:

序號 主要檢查項

1《需求規格說明書》是否評審並建立了基線?

2 是否按照測試計畫時間完成用例編寫?

3 需求新增和變更是否進行了對應的調整?

4 用例是否按照公司定義的模板進行編寫?

5 測試用例是否覆蓋了《需求規格說明書》?

6 用例編號是否和需求進行對應?

7 非功能測試需求或不可測試需求是否在用例中列出並說明?

8 用例設計是否包含了正面、反面的用例?

9 每個測試用例是否清楚的填寫了測試特性、步驟、預期結果?

10 步驟/輸入資料部分是否清晰,是否具備可操作性?

11 測試用例是否包含測試資料、測試資料的生成辦法或者輸入的相關描述?

12 測試用例是否包含邊界值、等價類分析、因果圖、錯誤推測、等測試用例設計方法?是否針對需求不同部分設計使用不同設計方法?

13 重點需求用例設計至少要有三種設計方法?

14 每個測試用例是否都闡述預期結果和評估該結果的方法?

15 需要進行列印、**、匯入、匯出、介面是否存在列印位置、**名稱、指定資料庫表名或檔案位置;**和資料格式是否有說明或附件?

16 用例覆蓋率是否達到相應質量指標?

17 用例預期缺陷率是否達到相應質量指標?

測試用例如何進行評審?

設計能力的過程 1 需要評審的原因 測試用例是軟體測試 的準則,但它並不是一經編制完成就成為準則。由於用例開發人員的設計經驗和對需求理解的深度各不相同,所以用例的質量難免會有不同程度的差異。2 進行評審的時機 一般會有兩個時間點。第一,是在用例的初步設計完成之後進行評審 第二是在整個詳細用例全部完成...

如何評審功能測試用例?

用例評審目的 用例評審的四個環節 需求評審 需求實現流程圖評審 測試大綱評審 測試用例檢查 a 檢查講解的內容無丟失 b 檢查需求理解無偏差 c 檢查需求講解思路清晰 d 檢查需求討論會議提出需求建議 需求討論的問題都有體現,並且記錄的詳細 e 檢查需求講解時存在問題的記錄,跟進結論 a 檢查需求以...

測試用例評審

1 測試組內同行評審 2 開發組內評審 1 檢查測試用例是否符合規範 流程清晰 劃分合理 是否採用了合理的測試用例設計方法 用例是否唯 一 有沒有重複 巢狀重複 有沒有考慮異常 有沒有大資料量場景 有沒有考慮冪等 有沒有考慮併發 重複請求 便於橫向比較 提高透明度 展示用例設計能力 2 業務流程有沒...