天天看點

軟體測試_用例篇

軟體測試_用例篇

1.評價測試用例的标準

(1)用例表達清楚,無二義性

(2)用例可操作性強

(3)用例的輸入與輸出明确,一條用例隻有一個預期結果

(4)用例的可維護性好

(5)用例對需求的覆寫率高

(6)暴露程式bug的能力強

2.測試用例帶給我們的好處

(1)測試執行者的依據

(2)使得工作可重複,自動化測試的基礎

(3)評估需求覆寫率

(4)用例的複用

(5)積累測試的方法思路以供後續借鑒

3.測試用例帶給我們的困擾

測試用例的設計是費時費力的工作,往往設計測試用例所花費的時間比執行所花費的時間還多

測試用例的設計方法

(1)測試用例的總體設計方法

基于需求的設計

  • RBT是基于需求的測試方法,會使測試更加有效,因為他使測試專注于品質問題産生的根源,即需求
  • 基于需求的測試是一種最根本的軟體測試,需要關注以下兩個問題:

    (1)驗證需求是否正确、完整、無二義性,并且邏輯一緻

    (2)從“黑盒” 的角度,設計充分且必要的測試集,來保證設計和代碼都能完全符合需求

    (2)具體的設計方法

  • 等價類

依據需求将輸入劃分成若幹等價類,從等價類中選出一個測試用例,如果測試用例測試通過,則認為所代表的等價類測試通過。用較少的測試用例達到盡量多的功能覆寫,解決了不能窮舉測試的問題

(1)有效等價類:可以驗證程式是否是實作了規格說明中所規定的功能和性能

(2)無效等價類:依據需求說明書,不滿足需求的集合

缺點:等價類隻考慮輸入,沒有考慮到輸出,是以需要其他的設計方法補充

  • 邊界值

    邊界值分析法是對輸入和輸出的邊界值進行測試的一種黑盒測試。是對于等價類劃分法的補充。其測試用例來自等價類的邊界

  • 因果圖

因果圖是一種簡化了的邏輯圖,能直覺的表明程式輸入條件(原因)和輸出動作(結果)之間的互相關系。借助圖形來設計測試用例,适合被測試程式具有多種輸入條件、程式的輸出又依賴于輸入條件的各種情況

  • 恒等:如果原因為真,那麼結果必定為真(動物園運來大熊貓,那麼動物園一定有大熊貓)
  • 與:隻有兩個原因都為真,那麼結果為真(北京姑娘,必須有房且有車)
  • 或:2個原因中有一個為真時,結果就為真(北京姑娘,有房或者有車)
  • 非:隻有原因為假,結果才為真(你不好好學習,你會找到好工作)

    因果圖設計測試用例的步驟:

    (1)分析所有可能的輸入和輸出

    (2)找出輸入與輸出之間的對應關系

    (3)畫出因果圖

    (4)将因果圖轉換成判定表

    (5)把判定表對應到每一個測試用例

    缺點:對于複雜的輸入和輸出,會耗費大量時間

  • 正交排列

正交法是為了減少用例數目,用盡量少的用例覆寫輸入的兩兩組合

正交試驗設計:根據正交性,從試驗因素的全部水準組合中挑出部分具有代表性的點進行試驗,通過這部分的試驗結果分析了解全面試驗的情況,找出最優的水準組合。是一種基于正交表的、高效率的、快速的、經濟的試驗

因素: 在一項試驗中,凡是欲考察的變量稱為因素(變量)

水準(位級): 在試驗範圍内,因素被考察的值稱為水準(變量的取值)

正交表的構成

**行數:**正交表中行的個數,即試驗的次數(N)

因素數: 正交表中列的個數(C)

水準數: 任何單個因素能夠取得的值的最大個數(T)

正交表的兩條性質:

(1)每一列中各數字出現的次數都一樣多

(2)任何兩列所構成的有序數對出現的次數一樣多

正交法設計測試用例的步驟:

(1)有哪些因素(變量)

(2)每個因素有哪幾個水準(變量的取值)

(3)選擇一個合适的正交表

(4)把變量的值映射到表中

(5)把每一行的各因素水準的組合作為一個測試用例

(6)加上你認為可疑且沒有在表中出現的用例組合

  • 場景設計法

    用業務流把各個孤立的點串起來,為測試人員建立整體業務的感覺

  • 錯誤猜測法

    基于經驗和直覺,找出程式中你認為可能出現的錯誤,有針對性的設計測試用例。(經驗豐富)

測試用例的粒度

粒度:測試用例編寫的詳細程度

(1)測試用例編寫的過于複雜,會帶來兩個問題:效率問題、維護成本問題。另外,如果過于詳細,那麼留給測試人員的思考時間就會比較少,容易限制測試人員的思維

(2)測試用例編寫的過于簡單。過于簡單的測試用例設計并沒有進行設計,而是把需要測試的功能子產品記錄下來而已,作用僅僅是在測試過程中作為一個簡單的測試計劃,提醒測試人員測試的主要功能包括哪些而已。

測試用例的設計的本質是在設計的過程中了解需求,檢驗需求,并把軟體系統的測試方法的思路記錄下來,以便指導将來的測試

設計怎樣粒度的測試用例主要考慮一下内容:

(1)産品的品質要求

(2)項目對用例的要求

(3)測試時間和資源是否充分

  • 測試用例的評價

    (1)同行評審

    最靈活的方式。測試用例的目的是盡可能的全面覆寫需求,而測試人員總會存在某方面的思維缺陷,一個人的思維總是存在局限性,是以需要一起設計測試用例

    (2)使用者檢查

    引入使用者參與測試用例的設計中

    (3)項目組評審

    由測試負責人組織協調開展會議,用例編寫人員對用例進行講解,參會人員有異議當場提出