測試用例設計

一、為什麼要使用測試用例

1、理清思路，避免遺漏

如果我們測試的項目大而複雜，我們可以把項目功能細分，根據每一個功能通過編寫用例的方式來整理我們測試系統的思路，避免遺漏掉要測試的功能點。

2、跟蹤測試進展

通過編寫測試用例，執行測試用例，我們可以很清楚的知道我們的測試進度。

3、曆史參考

在我們所做的項目中，也許會有很多功能是相同或相近的，我們對這類功能設計了測試用例，便于以後我們遇到類似功能的時候可以做參考依據。

4、重複性

我們測試一個系統不是一個人測一遍就算測完的，需要多人反複的進行測試，那麼我們就需要測試用例來規範和指導我們的測試行為。

5、測試确認

在少數高風險的測試中，必須證明确實執行了計劃執行的測試。

二、測試用例-要素

1、用例編号

測試用例的編号有一定的規則，比如系統測試用例的編号這樣定義規則： PROJECT1-ST-001 ，命名規則是項目名稱+測試階段類型（系統測試階段）+編号。定義測試用例編号，便于查找測試用例，便于測試用例的跟蹤。

2、測試标題

對測試用例的描述，測試用例标題應該清楚表達測試用例的用途。比如 “ 測試使用者登入時輸入錯誤密碼時，軟體的響應情況 ” 。

3、重要級别

定義測試用例的優先級别，可以籠統的分為 四個不同的等級

4、輸入限制

提供測試執行中的各種輸入條件。根據需求中的輸入條件，确定測試用例的輸入。測試用例的輸入對軟體需求當中的輸入有很大的依賴性，如果軟體需求中沒有很好的定義需求的輸入，那麼測試用例設計中會遇到很大的障礙。

5、操作步驟

提供測試執行過程的步驟。對于複雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分内容在操作步驟中詳細列出。

6、預期結果

提供測試執行的預期結果，預期結果應該根據軟體需求中的輸出得出。如果在實際測試過程中，得到的實際測試結果與預期結果不符，那麼測試不通過；反之則測試通過。

三、編寫用例參考什麼内容？

當根據客戶的需求整理出項目需求分析文檔時，我們就可以根據需求文檔來編寫測試用例了。

等到項目開發人員把項目開發出來，給我們系統文檔、部署環境、資料庫結構（如果系統牽涉到資料庫的話），我們根據這些文檔來設計測試用例。

我們編寫的測試用例經過評審之後，随着需求的變更、功能的改進，測試用例也需要更新和變動。

測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該删除這部分用例；也會發現若幹個備援的測試用例完全可以由某一個測試用例替代，那麼删除備援的測試用例。

四、黑盒測試用例的設計方法

具體的黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、場景法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法等。

這些方法是比較實用的，但采用什麼方法，在使用時自然要針對開發項目的特點對方法加以适當的選擇。

1、等價類劃分法

*在輸入條件規定了取值範圍或值的個數的情況下，則可以确立一個有效等價類和兩個無效等價類。

*在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可确立一個有效等價類和一個無效等價類。

*在輸入條件是一個布爾量的情況下，可确定一個有效等價類和一個無效等價類。

*在規定了輸入資料的一組值（假定n個），并且程式要對每一個輸入值分别處理的情況下，可确立n個有效等價類和一個無效等價類。

*在規定了輸入資料必須遵守的規則的情況下，可确立一個有效等價類（符合規則）和若幹個無效等價類（從不同角度違反規則）。

*在确知已劃分的等價類中各元素在程式進行中的方式不同的情況下，則應再将該等價類進一步的劃分為更小的等價類。

a)确定測試用例:

*為每一個等價類編号。

*設計一個測試用例，使其盡可能多地覆寫尚未被覆寫過的合理等價類。重複這步，直到所有合理等價類被測試用例覆寫。

*設計一個測試用例，使其隻覆寫一個不合理等價類。

b)舉例：

問題：  “一個程式讀入3個整數，把這三個數值看作一個三角形的3條邊的長度值。這個程式要列印出資訊，說明這個三角形是不等邊的、是等腰的、還是等邊的。”

我們可以設三角形的3條邊分别為A，B，C。如果它們能夠構成三角形的3條邊，必須滿足：

A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B。

如果是等腰的，還要判斷A=B，或B=C，或A=C。

如果是等邊的，則需判斷是否A=B，且B=C，且A=C。

根據以上分析，進而得到下圖清單中的測試用例。

2、邊界值分析法

使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來。但它不是從一個等價類中任選一個例子作為代表，而是将測試邊界情況作為重點目标，選取正好等于、剛剛大于或剛剛小于邊界值的測試資料。

⑴如果輸入條件規定了值的範圍，可以選擇正好等于邊界值的資料作為合理的測試用例，同時還要選擇剛好越過邊界值的資料作為不合理的測試用例。如輸入值的範圍是[1，100]，可取0，1，100，101等值作為測試資料。

⑵如果輸入條件指出了輸入資料的個數，則按最大個數、最小個數、比最小個數少1、比最大個數多1等情況分别設計測試用例。如，一個輸入檔案可包括1--255個記錄，則分别設計有1個記錄、255個記錄，以及0個記錄的輸入檔案的測試用例。

⑶對每個輸出條件分别按照以上原則⑴或⑵确定輸出值的邊界情況。如，一個學生成績管理系統規定，隻能查詢95--98級大學生的各科成績，可以設計測試用例，使得查詢範圍内的某一屆或四屆學生的學生成績，還需設計查詢94級、99級學生成績的測試用例（不合理輸出等價類）。

由于輸出值的邊界不與輸入值的邊界相對應，是以要檢查輸出值的邊界不一定可能，要産生超出輸出值之外的結果也不一定能做到，但必要時還需試一試。

⑷如果程式的規格說明給出的輸入或輸出域是個有序集合（如順序檔案、線形表、連結清單等），則應選取集合的第一個元素和最後一個元素作為測試用例。

3、場景法

用例場景用來描述流經用例的路徑，從用例開始到結束周遊這條路徑上所有基本流和備選流。

按照上圖中每個經過用例的路徑，可以确定以下不同的用例場景：

場景 1 基本流

場景 2 基本流 備選流 1

場景 3 基本流 備選流 1 備選流 2

場景 4 基本流 備選流 3

場景 5 基本流 備選流 3 備選流 1

場景 6 基本流 備選流 3 備選流 1 備選流 2

場景 7 基本流 備選流 4

場景 8 基本流 備選流 3 備選流 4

注：為友善起見，場景 5、6 和 8 隻考慮了備選流 3循環執行一次的情況。

4、錯誤推測法

概念：

基于經驗和直覺推測程式中所有可能存在的各種錯誤，進而有針對性的設計測試用例的方法

基本思想：

列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例

5、因果圖法

因果圖法是一種利用圖解法分析輸入的各種組合情況，進而設計測試用例的方法，它适合于檢查程式輸入條件的各種組合情況

等價類劃分法和邊界值分析方法都是着重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的互相制約關系。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。

如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目将是天文數字，是以必須考慮采用一種适合于描述多種條件的組合、相應産生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。

6、判定表驅動法

判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。

能夠将複雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。是以，利用判定表能夠設計出完整的測試用例集合。

在一些資料處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分别執行不同的操作。判定表很适合于處理這類問題。

7、正交試驗設計法

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

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

8、功能圖法

功能圖由狀态遷移圖和布爾函數組成.狀态遷移圖用狀态和遷移來描述.一個狀态指出資料輸入的位置（或時間）,而遷移則指明狀态的改變.同時要依靠判定表或因果圖表示的邏輯功能.

從功能圖生成測試用例的過程：

1) 生成局部測試用例:在每個狀态中,從因果圖生成局部測試用例.局部測試用例由原因值（輸入資料）組合與對應的結果值（輸出資料或狀态）構成。

2) 測試路徑生成:利用上面的規則（三種）生成從初始狀态到最後狀态的測試路徑。

3) 測試用例合成:合成測試路徑與功能圖中每個狀态中的局部測試用例.結果是初始狀态到最後狀态的一個狀态序列,以及每個狀态中輸入資料與對應輸出資料的組合。

五：測試方法選擇的綜合政策

在實際測試中，往往是綜合使用各種方法才能有效提高測試效率和測試覆寫度，這就需要認真掌握這些方法的原理，積累更多的測試經驗，以有效提高測試水準，以下是各種測試方法選擇的綜合政策，可在實際應用過程中參考。

*首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，将無限測試變成有限測試，這是減少工作量和提高測試效率的最有效方法。

*在任何情況下都必須使用邊界值分析方法。經驗表明用這種方法設計出測試用例發現程式錯誤的能力最強。

*對照程式邏輯，檢查已設計出的測試用例的邏輯覆寫程度。如果沒有達到要求的覆寫标準，應當再補充足夠的測試用例。

*對于業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。

作者：

擱淺

出處:

http://www.cnblogs.com/xiaoxi-3-/

如果對您有幫助，請關注我的同名簡書:

https://www.jianshu.com/u/da1677475c27

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。