測試用例
是指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。
內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。
每個具體測試用例都將包括下列詳細信息：編制人、審定人、編制日期、版本、用例類型、設計說明書編號、用例編號、用例名稱、輸入說明、期望結果（含判斷標准）、環境要求、備注等。
測試用例設計
- 將軟件測試的行為活動，作為一個科學化的組織歸納。
- 挑選具有代表性或者特殊性的測試數據來進行測試。
- 軟件程序在測試用例限定的條件下，必須能夠正常運行並且達到程序所設計的執行結果。
測試用例的好處
- 在開始實施測試之前設計好測試用例，可以避免盲目測試並提高測試效率。
- 測試用例的使用令軟件測試的實施重點突出、目的明確。
- 在軟件版本更新后只修正少部分的測試用例便可展開測試工作，降低工作強度，縮短項目周期。
- 測試用例的通用化和復用化則會使軟件測試易於開展，並隨着測試用例的不斷精化其效率也不斷攀升。
常見黑盒測試用例設計方法
等價類划分法
等價類是指輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效，並合理地假設：測試某等價類的代表值就等於對這類其他值的測試。
等價類划分的辦法是把程序的輸入域划分成若干部分，然后從每個部分中選取少數代表性數據作為測試用例。
等價類划分有兩種不同的情況：有效等價類和無效等價類。
- 有效等價類：指對於程序的規格說明書來說是合理的、有意義的輸入數據構成的集合。利用有效等價類可以檢驗程序是否實現了規格說明書中所規定的功能和性能。
- 無效等價類：與有效等價類的定義恰巧相反。
設計測試用例時，要同時考慮這兩種等價類。因為，軟件不僅要能接收合理的數據， 也能經受意外的考驗。這樣的測試才能確保軟件具有更高的可靠性。
確定等價類的原則
- 在輸入條件規定了取值范圍或者值個數的情況下，可以確定一個有效等價類和兩個無效等價類。
- 在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可以確定一個有效等價類和一個無效等價類。
- 在輸入條件是一個布爾量的情況下，可以確定一個有效的等價類和一個無效的等價類
- 在規定了輸入數據的一組值（假定n個），並且程序要對每一個輸入值分別處理的情況下，可以確定n個有效的等價類和一個無效的等價類。
- 在規定了輸入數據必須遵守的規則的情況下，可以確定一個有效等價類類（符合規則）和若干個無效等價類（從不同角度違反規則）。
- 在確知已划分的等價類中，各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步地划分為更小的等價類。
確定測試用例步驟
為每個等價類規定一個惟一的編號。
設計一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類，重復這一步，最后使得所有的有效等價類均被測試用例所覆蓋。
設計一個新的測試用例，使其只覆蓋一個無效等價類。重復這一步使所有無效等價類均被覆蓋。
邊界值分析法
邊界值分析：是考慮邊界條件而選取測試用例的一種黑盒測試方法，是對等價類划分方法的補充。
實踐證明，軟件在輸入、輸出域的邊界附近容易出現差錯， 而不是在輸入范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
使用邊界值分析方法設計測試方案首先應該確定邊界情況，通常輸入等價類和輸出等價類的邊界，就是應該注重測試的程序邊界情況。
選取的測試數據應該正好等於、剛剛小於和剛剛大於邊界值。
也就是說，按照邊界值分析法，應該選取剛好等於、稍小於和稍大於等價類邊界值作為測試數據，而不是選取每個等價類內的典型值或任意值作為測試數據。
基於邊界值分析方法選擇測試用例的原則
- 如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數據。
- 如果輸入條件規定了值的個數，則用最大個數，最小個數，比最小個數少一，比最大個數多一的數作為測試數據。
- 根據規格說明的每個輸出條件 ，考慮值的范圍情況。
- 根據規格說明的每個輸出條件 ，考慮值的個數情況。
- 如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例。
- 如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例
- 分析規格說明，找出其它可能的邊界條件。
錯誤推測法
基於經驗和直覺推測程序中所有可能存在的各種錯誤， 從而有針對性的設計測試用例的方法。
錯誤推測方法的基本思想：
- 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。
- 設計一些非法、錯誤、不正確和垃圾數據進行輸入測試是很有意義，如果軟件要求輸入數字、就輸入字母，如果軟件只接受正數，就輸入負數，等等。
錯誤推測方法常見依據:
- 在單元測試時曾列出的許多在模塊中常見的錯誤。
- 以前產品測試中曾經發現的錯誤等。
- 已發現缺陷的測試方法的推廣。
- 容易發生錯誤的情況。
- 補充等價類和邊界值法遺漏的一些等價類組合。
- 一些位置使用了共享變量，設計測試用例，修改一個共享變量，看其他位置有沒有同時做修改。
因果圖法
因果圖方法是對等價類的擴展，可以理解為 “ 等價類組合判定表 ” 。是輸入等價類與輸出等價類的關系圖。
等價類划分方法和邊界值分析法都是着重考慮輸入條件，並沒有考慮到輸入情況的各組合，也沒有考慮各個輸入情況之間的相互制約關系。
利用因果關系描述多種條件的組合，相應地產生多個動作的形式來考慮設計用例。
生成測試用例的基本步驟
- 分析軟件規格說明描述中， 那些是原因 ( 即輸入條件或輸入條件的等價類 ) ，那些是結果 ( 即輸出條件 ) ， 並給每個原因和結果賦予一個標識符。
- 分析軟件規格說明描述中的語義。找出原因與結果之間， 原因與原因之間對應的關系 。根據這些關系，畫出因果圖。
- 表明約束條件。由於語法或環境限制， 有些原因與原因之間，原因與結果之間的組合情況不不可能出現。 為表明這些特殊情況， 在因果圖上用一些記號表明約束或限制條件。
- 把因果圖轉換成判定表。
- 為判定表中每一列表示的情況設計測試用例。
判定表驅動法
判定表是把作為條件的所有輸入的各種組合值以及對應輸出值都羅列出來而形成的表格。是分析和表達多邏輯條件下執行不同操作的情況的工具。
- 可配合因果圖后期使用
- 適合於多邏輯條件下的組合分析
能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。
判定表組成
- 條件樁（Condition Stub）：列出了問題得所有條件。通常認為列出的條件的次序無關緊要。
- 動作樁（Action Stub）：列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。
- 條件項（Condition Entry）：列出針對它左列條件的取值。針對條件樁給出的條件列出所有可能的取值
- 動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。
將任何一個條件組合的特定取值及相應要執行的動作稱為一條規則。在決策表中貫穿條件項和動作項的一列就是一條規則。
判定表的優點和缺點
- 優點：它能把復雜的問題按各種可能的情況一一列舉出來，簡明而易於理解，也可避免遺漏。
- 缺點：不能表達重復執行的動作，例如循環結構。
判定表的建立步驟
- 確定規則的個數。假如有n個條件，每個條件有兩個取值（0,1），故有2n種規則
- 列出所有的條件樁和動作樁
- 填入條件項
- 填入動作項。制定初始判定表
- 簡化。合並相似規則或者相同動作
正交試驗設計法
是從大量的試驗數據中挑選適量的、有代表性的點，從而合理的安排測試的一種科學的試驗設計方法。
設計出最少的測試組合，達到有效測試目的。
- 節省測試工時。
- 可控制測試用例的數量。
- 測試用例具有一定的覆蓋率。
生成測試用例的基本步驟
- 提取功能說明，構造因子 狀態表。
- 加權篩，生成因素分析表。
- 利用正交表構造測試數據集。
功能圖法
用功能圖形象地表示程序功能說明，並生成功能圖的測試用例。又可以稱作流程測試或狀態遷移測試。類似於白盒測試中的邏輯覆蓋和路徑法。
需要懂得控制語句（循環，順序，選擇，重復）
生成測試用例的基本步驟
- 在每個狀態生成局部測試用例。
- 測試路徑生成：從初始狀態到最后狀態的測試路徑。
- 測試用例合成：合成測試路徑和功能圖中每個狀態的局部測試用例。
- 測試用例合成算法：條件構造樹。
場景法
事件觸發控制流程，事件觸發時的情景便形成場景。
同一事件不同的觸發順序和處理結果就形成事件流。
用例場景用來描述流經用例的路徑，從用例開始到結束遍歷這條路徑的有基本流和備選流。
測試用例選擇的綜合策略
- 首先進行等價類划分，包括輸入條件和輸出條件的等價類划分，將無限測試變成有限測試，這是減少工作量和提高測試效率的有效方法。
- 在任何情況下都必須使用邊界值分析方法。經驗表明，用這種方法設計出的測試用例發現程序錯誤的能力最強。
- 可以用錯誤推測法追加一些測試用例，這些需要依靠測試工程師的智慧和經驗。
- 對照程序邏輯，檢查已設計的測試用例的邏輯覆蓋程序，如果沒有達到要求的覆蓋標准，應當再補充足夠的測試用例。
- 如果程序的功能說明中含有輸入條件的組合，則一開始就可以選因果圖法和判定表驅動法。
- 對參數配置類的軟件，要用正交試驗法選擇較少的組合方式達到最佳的測試效果。
- 功能圖法也是很好的測試用例設計方法，我們可以通過不同時期條件的有效性設計不同的測試數據。
- 對於業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。