測試用例 相關

測試用例（Test Case）是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否知足某個特定需求。

 

測試用例 （Test Case）是將軟件測試的行爲活動作一個

 

科學化的組織概括，目的是可以將軟件測試的行爲轉化成可管理的模式；同時測試用例也是將測試具體量化的方法之一，不一樣類別的軟件，測試用例是不一樣的。不一樣於諸如系統、工具、控制、遊戲軟件，管理軟件的用戶需求更加不一樣的趨勢。

要使最終用戶對軟件感到滿意，最有力的舉措就是對最終用戶的指望加以明 確闡述，以便對這些指望進行覈實並確認其有效性。測試用例反映了要覈實的需求。然而，覈實這些需求可能經過不一樣的方式並由不一樣的測試員來實施。例如，執行 軟件以便驗證它的功能和性能，這項操做可能由某個測試員採用自動測試技術來實現；計算機系統的關機步驟可經過 手工測試和觀察來完成；不過，市場佔有率和銷售數據（以及產品需求），只能經過評測產品和競爭銷售數據來完成。

既然可能沒法（或沒必要負責）覈實全部的需求，那麼是否能爲測試挑選最適合或最關鍵的需求則關係到項目的成敗。選中要覈實的需求將是對成本、風險和對該需求進行覈實的必要性這三者權衡考慮的結果。

 

肯定測試用例之因此很重要，緣由有如下幾方面。

測試用例

測試用例構成了設計和制定 測試過程的基礎。

測試的「深度」與測試用例的數量成比例。因爲每一個測試用例反映不一樣的 場景、條件或經由產品的事件流，於是，隨着測試用例數量的增長，您對產品質量和測試流程也就越有信心。

判斷測試是否徹底的一個主要評測方法是基於需求的覆蓋，而這又是以肯定、實施和/或執行的測試用例的數量爲依據的。相似下面這樣的說明：「95 % 的關鍵測試用例已得以執行和驗證」，遠比「咱們已完成 95 % 的測試」更有意義。

測試工做量與測試用例的數量成比例。根據全面且細化的測試用例，能夠更準確地估計測試周期各連續階段的時間安排。

測試設計和開發的類型以及所需的資源主要都受控於測試用例。

測試用例一般根據它們所關聯關係的測試類型或測試需求來分類，並且將隨類型和需求進行相應地改變。最佳方案是爲每一個測試需求至少編制兩個測試用例：

·一個測試用例用於證實該需求已經知足，一般稱做正面測試用例；

·另外一個測試用例反映某個沒法接受、反常或意外的條件或數據，用於論證只有在所需條件下才可以知足該需求，這個測試用例稱做 負面測試用例。

1、測試用例是軟件測試的核心

軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現 軟件系統的 缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每一個軟件產品或 軟件開發項目都須要有一套優秀的測試方案和測試方法。

測試用例

影 響軟件測試的因素不少，例如軟件自己的複雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。由於有些因素是客觀存 在的，沒法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來；一個具體的人工做也受情緒等影響，等等。如何保 障軟件測試質量的穩定？有了測試用例，不管是誰來測試，參照測試用例實施，都能保障測試的質量。能夠把人爲因素的影響減小到最小。即使最初的測試用例考慮 不周全，隨着測試的進行和軟件版本更新，也將日趨完善。

所以測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工做的指導，是軟件測試的必須遵照的準則。更是軟件測試質量穩定的根本保障。

 

 

 

設計:

 

（一）白盒技術

白盒測試是結構測試，因此被測對象基本上是 源程序，以 程序的內部邏輯爲基礎設計測試用例。

⒈ 邏輯覆蓋

程序內部的 邏輯覆蓋程度，當程序中有循環時，覆蓋每條路徑是不可能的，要設計使覆蓋程度較高的或覆蓋最有表明性的路徑的測試用例。下面根據圖7-1所示的 程序，分別討論幾種經常使用的覆蓋技術。

⑴ 語句覆蓋。

爲了提升發現錯誤的可能性，在測試時應該執行到 程序中的每個語句。 語句覆蓋是指設計足夠的測試用例，使被 測試程序中每一個語句至少執行一次。

如圖7-1是一個被測試 程序流程圖：

⑵ 斷定覆蓋。

斷定覆蓋指設計足夠的測試用例，使得被測 程序中每一個斷定表達式至少得到一次「真」值和「假」值，從而使程序的每個分支至少都經過一次，所以斷定覆蓋也稱 分支覆蓋。

⑶ 條件覆蓋。

條件覆蓋是指設計足夠的測試用例，使得斷定 表達式中每一個條件的各類可能的值至少出現一次。

⑷ 斷定條件覆蓋。

該覆蓋標準指設計足夠的測試用例，使得斷定表達式的每一個條件的全部可能取值至少出現一次，並使每一個斷定表達式全部可能的結果也至少出現一次。

⑸ 條件組合覆蓋。

條件組合覆蓋是比較強的覆蓋標準，它是指設計足夠的測試用例，使得每一個斷定表達式中條件的各類可能的值的組合都至少出現一次。

⑹ 路徑覆蓋。

路徑覆蓋是指設計足夠的測試用例，覆蓋被測 程序中全部可能的路徑。

在實際的 邏輯覆蓋測試中，通常以 條件組合覆蓋爲主設計測試用例，而後再補充部分用例，以達到 路徑覆蓋測試標準。

⒉循環覆蓋

⒊基本 路徑測試

（二）黑盒技術

⒈等價類劃分

⑴劃分等價類。

①在輸入條件規定了取值範圍或值的個數的狀況下，則能夠確立一個有效等價類和兩個 無效等價類。

②在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的狀況下，可確立一個有效等價類和一個 無效等價類。

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

④在規定了輸入數據的一組值（假定n個），而且 程序要對每個輸入值分別處理的狀況下，可確立n個有效等價類和一個 無效等價類。

⑤在規定了輸入數據必須遵照的規則的狀況下，可確立一個有效等價類（符合規則）和若干個 無效等價類（從不一樣角度違反規則）。

⑥在確知已劃分的等價類中各元素在 程序處理中的方式不一樣的狀況下，則應再將該等價類進一步的劃分爲更小的等價類。

⑵肯定測試用例。

①爲每個等價類編號。

②設計一個測試用例，使其儘量多地覆蓋還沒有被覆蓋過的合理等價類。重複這步，直到全部合理等價類被測試用例覆蓋。

③設計一個測試用例，使其只覆蓋一個不合理等價類。

⒉邊界值分析

使用邊界值分析方法設計測試用例時通常與等價類劃分結合起來。但它不是從一個等價類中任選一個例子做爲表明，而是將測試邊界狀況做爲重點目標，選取正好等於、剛剛大於或剛剛小於邊界值的測試數據。

⑴若是輸入條件規定了值的範圍，能夠選擇正好等於邊界值的數據做爲合理的測試用例，同時還要選擇恰好越過邊界值的數據做爲不合理的測試用例。如輸入值的範圍是[1，100]，可取0，1，100，101等值做爲測試數據。

⑵若是輸入條件指出了輸入數據的個數，則按最大個數、最小個數、比最小個數少一、比最大個數多1等狀況分別設計測試用例。如，一個輸入文件可包括1--255個記錄，則分別設計有1個記錄、255個記錄，以及0個記錄的輸入文件的測試用例。

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

因爲輸出值的邊界不與輸入值的邊界相對應，因此要檢查輸出值的邊界不必定可能，要產生超出輸出值以外的結果也不必定能作到，但必要時還需試一試。

⑷若是 程序的規格說明給出的輸入或輸出域是個有序集合（如 順序文件、線形表、鏈表等），則應選取集合的第一個元素和最後一個元素做爲測試用例。

⒊錯誤推測

在 測試程序時，人們可能根據經驗或直覺推測程序中可能存在的各類錯誤，從而有針對性地編寫檢查這些錯誤的測試用例，這就是錯誤推測法。

⒋ 因果圖

等價類劃分和邊界值方法分析方法都只是孤立地考慮各個輸入數據的測試功能，而沒有考慮多個輸入數據的組合引發的錯誤。

⒌綜合策略

每種方法都能設計出一組有用例子，用這組例子容易發現某種類型的錯誤，但可能不易發現另外一類型的錯誤。所以在實際測試中，聯合使用各類測試方法，造成綜合策略，一般先用黑盒法設計基本的測試用例，再用 白盒法補充一些必要的測試用例。