軟件測試:用例篇

  • 2019 年 10 月 6 日
  • 筆記

軟件測試:用例篇

本節主要內容 – 測試用例的基本要素 – 測試用例的設計方法 – 測試用例的有效性 – 測試用例的粒度和評價

測試用例的基本要素

測試用例(Test Case)是為了實施測試而向被測試的系統提供的一組集合,這組集合包括:測試環境、操作步驟、測試數據、預期結果等要素。

評價測試用例好壞的標準: – 用例表達性清楚,無二義性。 – 用例可操作性強 – 用例的輸入與輸出明確。一條用例只有一個預期結果。 – 用例的可維護性好。可維護性好包含兩個方面:用例的可讀性好、用例易修改。 – 用例對需求的覆蓋率高。需求的覆蓋率=用例的條數/功能點的個數。 – 暴露程序Bug的能力強。

測試用例的優點 – 測試執行者的依據 – 自動化測試的基礎 – 評估需求覆蓋率 – 用例的復用 – 基類測試的方法思路以供後續借鑒

測試用例的缺點 – 費時費力,往往在設計測試用例時花費的時間比執行是花費的時間還多。 – 測試的覆蓋率無法衡量,不知道是否較全面的測試了所有功能。 – 對新版本的重複測試很難實施,存在大量冗餘測試影響測試效率。

測試用例具體的設計方法

設計方法有5種:基於需求的設計、等價類、邊界值、因果圖、正交排列、場景設計法、錯誤猜測法。

基於需求的設計

RBT是基於需求的測試方法,會使測試更加有效,因為它使測試專註於質量問題產生的根源,即需求。

基於需求的測試是一種最根本的軟件測試,主要關注以下兩個問題: 1. 驗證需求是否正確、完整、無二義性,並且邏輯一致。 2. 要從「黑盒」的角度,設計出充分並且必要的測試集,以保證設計和代碼都能完全符合需求。

案例:

等價類

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

  • 有效等價類:對於程序的規格說明來說是合理的、有意義的輸入數據構成的集合,利用有效等價類驗證程序是否實現了規格說明中所規定的功能和性能。
  • 無效等價類:根據需求說明書,不滿足需求的集合。 案例: 超市買水果 有效等價類:蘋果、桃子、香蕉… 無效等價類:牛奶、青菜…

邊界值

邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充,這種情況下,其測試用例來自等價類的邊界。

1

在實際的測試設計中,會將等價類和邊界值結合起來使用。

1

因果圖

因果圖是一種簡化了的邏輯圖,能直觀地表明程序輸入條件(原因)和輸出動作(結果)之間的相互關係。因果圖法是藉助圖形來設計測試用例的一種系統方法,特別適用於被測試程序具有多種輸入條件、程序的輸出又依賴於輸入條件的各種情況。 – 恆等

1

– 與

1

– 或

1

– 非

1

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

  1. 分析所有可能的輸入和可能的輸出;
  2. 找出輸出與輸入之間的對應關係;
  3. 畫出因果圖;
  4. 把因果圖轉換成判定表;
  5. 把判定表對應到每一個測試用例。 案例三: 假設業務單據的處理規則為:「淘寶618活動,訂單已提交,訂單合計金額大於300元或有紅包,則進優惠」。 1. 首先通過分析該條業務所有可能的輸入和可能的輸出為: – 輸入:訂單已提交、金額大於300元、有紅包 – 輸出:優惠、不優惠 2. 第二步,找出輸入與輸出之間的對應關係,經分析,有以下對應關係: – 訂單未提交,則不優惠; – 訂單未提交,金額 > 300,不優惠; – 訂單未提交,有紅包,不優惠; – 訂單未提交,金額 > 300,且有紅包,不優惠; – 訂單已提交,金額 <= 300,且沒紅包,不優惠; – 訂單已提交,金額 > 300,優惠; – 訂單已提交,有紅包,優惠; – 訂單已提交,金額 >300 且有紅包,優惠。 3. 第三步,根據上一步的分析,畫因果圖如下圖: 4. 第四步,根據因果圖畫出判定表,如下: 5. 最終的測試用例: 1,2,3,4,5(包含6,7,8)

因果圖:

判定表:

因果法測試用例可以幫助測試人員理清輸入和輸出的關係,但是對於比較複雜的輸入和輸出,會耗費大量的時間。所以引出了下面的正交法。

正交排列

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

正交試驗設計(Orthogonal experimentaldesign)是研究多因素多水平的一種設計方法,它是根據正交性,由試驗因素的全部水平組合中挑選出部分有代表性的點進行試驗,通過對這部分試驗結果的分析了解全面試驗的情況,找出最優的水平組合。正交試驗設計是一種基於正交表的、高效率、快速、經濟的試驗。

正交法中的重要概念: – 因素:在一項試驗中,凡欲考察的變量稱為因素(變量)。 – 水平:變量的取值。

正交表的構成: – 行數:正交表中的行的個數,即試驗的次數,用N代表。 – 因素數:正交表中列的個數,用C代表。 – 水平數:任何單個因素能夠取到的值的最大個數。正交表中的包含的值為從0到數」水平數-1「或1到」 水平數「,用T代替。

正交表的表示形式: L=行數(水平數*因素數) 即:

L=N(TC)

正交表的兩條性質: – 每一列中各數字出現的次數都一樣多。 – 任何兩列所構成的各有序對出現的次數都一樣多。

正交法設計測試用例的步驟: 1. 分析有哪些因素(變量); 2. 每個因素有哪幾個水平(變量的取值); 3. 選擇一個合適的正交表; 4. 把變量的值映射到表中; 5. 把每一行各因素水平的組合作為一個測試用例; 6. 加上你認為可疑且沒有在表中出現的用例組合。

1

正交表:

作業:用什麼方法來設計以下兩個作業,5個條件都是可填和可不填的。

查詢頁面:姓名、性別、學號、學校、班級

1

正交表1:

場景設計法

事件流 通俗的說,單擊鼠標後不同的觸發順序和處理結果就形成了時間流。

控制流 是指按一定的順序排列程序元素來決定程序執行的順序。

場景設計法可以比較生動地描繪出事件觸發時的情景,有利於測試設計者設計測試用例,是測試 用例更容易理解和執行。 典型的應用是用業務流把各個孤立的功能點串起來,為測試人員建立整體業務感覺,從而避免陷入功能細節忽視業務流程要點的錯誤傾向。

錯誤猜測法

錯誤猜測法是經驗豐富的測試人員喜歡使用的一種測試方法。

基於經驗和直覺,找出程序中你認為可能出現的錯誤,有針對性地設計測試用例。 經驗可能來自於在對某項業務的測試較多,也可以來自於售後用戶的反饋意見,或者從故障管理庫中整理bug。梳理出產品以往哪些地方容易出現問題,問題越多的地方,潛在的bug也就越多。

以註冊郵箱為例: 1. 校驗中特殊字符空格的處理: – 當空格出現在前面或後面時,正規開發人員會對空格進行截取,所以不會影響; – 但當空格出現在中間時,就會將空格認為是一個字符,就會報錯。 2. 密碼校驗中的大小寫 3. 姓名中的特殊字符 4. 密碼發送是否明文

測試用例的有效性

  1. 蘋果7手機微信添加了mobile單車小程序,掃碼不能開鎖,只能使用mobile APP開鎖,測試用例未涉及到蘋果7微信小程序掃碼開鎖。此時該測試用例就是無效的。
  2. 蘋果7手機微信添加了mobile單車小程序,用例已寫到了蘋果7微信添加mobile小程序掃碼開鎖,問題被發現。此時該測試用例就是有效的。
  3. 已知某代碼此處無bug,用某條測試用例來測試也沒有出現bug,則這條測試用例也是有效的。

測試用例的粒度和評價

測試用例的粒度

粒度:指測試用例編寫的詳細程度 測試用例編寫時: 1. 寫的過於簡單,則可能失去了測試周例的意義; 2. 寫的過於複雜或詳細,會帶來兩個問題: – 效率問題 – 維護成本問題 – 容易限制測試人員的思維 大多數測試團隊編寫的測試用例的粒度介於兩者之間。而如何把握好粒度是測試用例設計的關鍵,也將影響測試用例設計的效率和效果。應該根據項目的實際情況、測試資源情況來決定設計出怎樣粒度的測試用例。

主要考慮可參考以下內容: – 產品的質量要求 – 項目對用例的要求 – 測試時間和資源是否充足

測試用例的評價

主要有: – 同行評審:體現了敏捷的「個體和交互比過程和工具更有價值」這一原則。 – 用戶檢查:體現了敏捷的「顧客的協作比合同談判更有價值」這一原則。 – 項目組評審

本文轉自:https://blog.csdn.net/bit666888/article/details/81078499