軟體測試—用例篇

測試用例（Test Case）概念

是為了實施測試而向被測試系統提供的一組集合，這組集合包括：測試環境、操作步驟、測試資料、預期結果等要素。

好的測試用例是不熟悉業務的人也能根據用例很go準

• 用例表達清楚，無二義性，不能出項“是否”這樣的詞彙
• 用例可操作性強
• 用例的輸入輸出明確，一條用例只有一個預期結果
• 用例可維護性好，即可讀性好
• 用例對需求的覆蓋性高
• 暴露程式bug的能力強，才能發現更多更深的bug。

測試用例的好處

測試執行者的依據
使得工作可重複，自動化測試的基礎
評估需求覆蓋率
用例的複用
積累測試的方法思路以供後續借鑑

測試用例除了有很多好處外，也有它的缺點：測試用例的設計是費時費力的工作，往往設計測試用例所花費的時間比執行測試的時間要多。

設計測試用例要解決的問題：

• 不知道是否全面的測試了所有的功能
• 測試的覆蓋率無法衡量
• 對新版本的重複測試很難實施
• 存在大量冗餘測試影響測試效率

測試用例的設計方法（七種）

1.基於需求的設計

RBT( Requirements-Based Testing)是基於需求的測試方法，會使測試更加有效，因為 它使測試專注於質量問題產生的根源，即需求。

基於需求的測試是最根本的軟體測試，它關注兩個關鍵問題：

• 驗證需求是否正確，完整，無二義性，邏輯一致
• 從黑盒角度，設計出充分並必要的測試集，使設計和程式碼能夠完全滿足需求

1.等價類劃分
概念：根據需求將輸入劃分為若干個等價類，從等價類中選出一個測試用例，若這個測試用例通過，就認為所代表的等價類測試通過，這樣就使用了較少的測試用例達到儘量多的功能覆蓋，解決了不能窮舉測試的問題。

• 有效等價類：對於程式的規格說明書是合理的、有意義的輸入資料構成的集合，利用有效等價類驗證程式是否實現了規格說明中所規定的功能和效能
• 無效等價類：根據需求說明書，不滿足需求的集合。
  

  eg:賬號為9位數字字元
  有效等價類：9位數字字元
  無效等價類：（1）有非數字字元 （2）少於9位數字字元 （3）多於9位數字字元

等價類只考慮到了輸入域的分類，未考慮輸入域的組合，需要其他方法來補充 **2.邊界值分析** 對輸入輸出邊界值進行測試的一種黑盒測試方法，一般是等價類劃分法的補充，邊界值來自於等價類的邊界。一般應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試資料，而不是選取等價類中的典型值或任意值作為測試資料。

常見的邊界值：

• 對16-bit 的整數而言 32767 和 -32768 是邊界
• 螢幕上游標在最左上、最右下位置
• 報表的第一行和最後一行
• 陣列元素的第一個和最後一個
• 迴圈的第 0 次、第 1 次和倒數第2 次、最後一次

–

1. 輸入框長度為1-11，取邊界值為：1、11、12、0
2. 運動員的參賽專案為1-3項，取邊界值為：0項、1項、3項、4項
3. 查詢面頁面有999行，每50行為一頁，取邊界值為：輸出0行、1行、50行、51行、999行、1000行

注意：要搞清楚是閉區間還是開區間

如：
（1，10）取邊界值為：1，2，9，10
[ 1,10 ] 取邊界值為：0，1，10，11
（1,10 ]取邊界值為：1，2，10，11

**3.因果圖** 是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，適合檢查輸入條件的各種組合情況。特別適用於被測試程式具有多種輸入條件、程式的輸出又依賴於輸入條件的各種情況。 等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關係。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了 **四種因果關係**

• 恆等

• 與

- 或

- 非

因果圖法設計測試用例的步驟
1.分析所有可能的輸入和輸出
2.找出輸入和輸出之間的對應關係
3.畫出因果圖
4.將因果圖轉成判定表
5.判定表對應每個測試用例

一個案例：
假設業務單據的處理規則為：“淘寶618活動，提單已提交，訂單合計金額大於300元或有紅包，則進優惠”
步驟一：

• 輸入：訂單已提交、金額大於300、有紅包
• 輸出：優惠、不優惠

步驟二：

• 訂單未提交，不優惠
• 訂單已提交，訂單金額大於等於300，沒有紅包，優惠
• 訂單已提交，訂單金額大於等於300，有紅包，優惠
• 訂單已提交，訂單金額小於300，有紅包，優惠
• 訂單已提交，訂單金額小於300，沒有紅包，不優惠

步驟三：因果圖

步驟四：判定表

步驟五：測試用例
1，2，3，4，5（包含6，7，8）

因果法設計測試用例可以幫助測試人員理清輸入和輸出的關係，但是對於比較複雜的輸入和輸出，會耗費大量時間

4.正交法
正交法的出現時為了減少測試用例的數目，用盡可能少的用例覆蓋輸入的兩兩組合
利用因果圖來設計測試用例時, 作為輸入條件的原因與輸出結果之間的因果關係,有時很難從軟體需求規格說明中得到。往往因果關係非常龐大,以至於據此因果圖而得到的測試用例數目多的驚人，給軟體測試帶來沉重的負擔，為了有效地,合理地減少測試的工時與費用,可利用正交實驗設計方法進行測試用例的設計。

正交實驗設計方法:從大量的（實驗）資料（測試用例）中挑選適量的,有代表性的點（例）,從而合理地安排實驗（測試）的一種科學實驗設計方法.類似的方法有:聚類分析方法,因子方法方法等.

正交表的兩條性質

• 每一列中各數字出現的次數一樣多
• 任何兩列構成的有序數對出現的次數一樣多

因素（Factor）：在一項實驗中，凡欲考察的變數稱為因素（變數）
水平（Level）：實驗範圍內，因素被考察的值被稱為水平（變數的取值）

正交表的構成：
1.行數（Runs）：正交表中行的個數，即實驗的次數，用N表示
2.因素數（Factors）：正交表中列的個數，用C表示
3.水平數：任何單個因素所能取值的最大個數，從0~水平數-1或從1~水平數，用T表示

正交表的表示形式：
L=行數（水平數*因素數） L=N（TC）

正交法設計測試用例的步驟：
1.有哪些因素（變數）
2.每個因素有哪些水平（變數的取值）
3.選擇合適的正交表
4.把變數的值對映到正交表中
5.把每行各因素水平的組合作為一條測試用例
6.再加上可疑但沒在表中出現的測試用例

案例：繼續以註冊為例（類似工具可以使用微軟的PICT工具）
步驟一：
因素：姓名、郵箱、密碼、確認密碼、驗證碼
步驟二：
水平：填寫、不填寫
步驟三：
表中的因素數>=5；
表中至每個因素數的水平數>=2
行數取最少的一個，即試驗次數最少的一個
L=N（TC）
這裡的N是實驗次數，N（min）=因素數C*（水平數T-1）+1=5*（2-1）+1=6
選擇正交表，這裡選擇了L6_2_5。
步驟四：

正交表的建立需滿足正交表的兩條性質，並且實驗次數應大於等於最小試驗次數6
步驟五：
根據正交表生成八條測試用例
步驟六：
增補可疑測試用例，這裡我們沒有可疑的

6.場景設計法
軟體一般以事件觸發來控制流程
事件流：點選之後完成的動作，同一事件不同的觸發順序和處理結果就形成事件流。
場景法特別適用於控制流清晰的系統。

設計步驟：
1.畫出程式控制流圖（可先畫出程式流程圖，再把流程圖轉化成控制流圖）
2.根據控制流圖設計出場景
3.根據場景設計測試用例

7.錯誤猜測法
經驗豐富的測試人員經常用這種方式。
基於多年的經驗和直覺，找出程式中可能出現的bug，有針對性地設計測試用例。
經驗可能來自於在對某項業務的測試較多，也可以來自於售後使用者的反饋意見，或者從故障管理庫中整理bug。梳理出產品以往哪些地方容易出現問題，問題越多的地方，潛在的bug也就越多。

以註冊為例：
1.校驗中特殊字元空格的處理？
空格在前面或後面可直接擷取，在中間就認為出現錯誤
2.密碼校驗的大小寫？
3.姓名中的特殊字元？
4.密碼傳送是明文？

測試用例的有效性

測試用例對應的功能已刪除，不能進行操作
執行一條測試用例，發現了bug
執行一條測試用例未發現bug，實際該處BUG已修改，該條測試用例是有效的，是為了測試無bug

測試用例的粒度和評價

粒度：是指測試用例編寫的詳細程度
最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，如探索性測試中的測試設計，僅會指出需要測試產品的哪些要素、需要達到的質量目標、需要使用的測試方法等。
而最複雜的測試用例就像飛機維修人員使用的工作指令卡一樣，會指定輸入的每項資料，期待的結果及檢驗的方法， 具體到介面元素的操作步驟，指定測試的方法和工具等。

(1)測試用例寫得過於複雜或詳細，會帶來兩個問題：一個是效率問題，另一個是維護成本問題
(2)測試用例寫得過於簡單，則可能失去了測試的意義。

因此，我們可以根據產品的質量需求、專案對用例的要求、測試的時間和資源是否充足這三點來把握測試用例的粒度