3.錯誤推測
在測試程序時，人們可能根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例，這就是錯誤推測法。
4.因果圖
等價類劃分和邊界值方法分析方法都只是孤立地考慮各個輸入數據的測試功能，而沒有考慮多個輸入數據的組合引起的錯誤。
5.綜合策略
每種方法都能設計出一組有用例子，用這組例子容易發現某種類型的錯誤，但可能不易發現另一類型的錯誤。因此在實際測試中，聯合使用各種測試方法，形成綜合策略，通常先用黑盒法設計基本的測試用例，再用白盒法補充一些必要的測試用例。
六、測試用例設計的誤區
（來源：關河測試網）
·能發現到目前為止沒有發現的缺陷的用例是好的用例；
首先要申明，其實這句話是十分有道理的，但我發現很多人都曲解了這句話的原意，一心要設計出發現“難于發現的缺陷”而陷入盲目的片面中去，忘記了測試的目的所在，這是十分可怕的。我傾向于將測試用例當作一個集合來認識，對它的評價也只能對測試用例的集合來進行，測試本身是一種“V&V”的活動，測試 需要保證以下兩點：
程序做了它應該做的事情
程序沒有做它不該做的事情
因此，作為測試實施依據的測試用例，必須要能完整覆蓋測試需求，而不應該針對單個的測試用例去評判好壞。
·測試用例應該詳細記錄所有的操作信息，使一個沒有接觸過系統的人員也能進行測試；
不知道國內有沒有公司真正做到這點，或者說，不知道有國內沒有公司能夠將每個測試用例都寫得如此詳細。在我的測試經歷中，對測試用例描述的詳細和復雜程度 也曾有過很多的彷徨。寫得太簡單吧，除了自己沒人能夠執行，寫得太詳細吧，消耗在測試用例維護（別忘了，測試用例是動態的，一旦測試環境、需求、設計、實 現發生了變化，測試用例都需要相應發生變化）上的時間實在是太驚人，在目前國內大部分軟件公司的測試資源都不足的情況下，恐怕很難實現。但我偏偏就能遇到 一些這樣的老總或者是項目負責人，甚至是測試工程師本身，全然不顧實際的資源情況，一定要寫出“沒有接觸過系統的人員也能進行測試”的用例。
在討論這個問題之前，我們可以先考慮一下測試的目的。測試的目的是盡可能發現程序中存在的缺陷，測試活動本身也可以被看作是一個Project，也需要在 給定的資源條件下盡可能達成目標，根據我個人的經驗，大部分的國內軟件公司在測試方面配備的資源都是不足夠的，因此我們必須在測試計劃階段明確測試的目 標，一切圍繞測試的目標進行。
除了資源上的約束外，測試用例的詳細程度也需要根據需要確定。如果測試用例的執行者、測試用例設計者、測試活動相關人對系統了解都很深刻，那測試用例就沒有必要太詳細了，文檔的作用本來就在于溝通，只要能達到溝通的目的就OK。在我擔任測試經理的項目中，在測試計劃階段，一般給予測試設計30% - 40%左右的時間，測試設計工程師能夠根據項目的需要自行確定用例的詳細程度，在測試用例的評審階段由參與評審的相關人對其把關。
·測試用例設計是一勞永逸的事情；
這句話擺在這里，我想沒有一個人會認可，但在實際情況中，卻經常能發現這種想法的影子。我曾經參與過一個項目，軟件需求和設計已經變更了多次，但測試用例 卻沒有任何修改。導致的直接結果是新加入的測試工程師在執行測試用例時不知所措，間接的后果是測試用例成了廢紙一堆，開發人員在多次被無效的缺陷報告打擾 后，對測試人員不屑一顧。
這個例子可能有些極端，但測試用例與需求和設計不同步的情況在實際開發過程中確是屢見不鮮的，測試用例文檔是“活的”文檔，這一點應該被測試工程師牢記。
·測試用例不應該包含實際的數據；
測試用例是“一組輸入、執行條件、預期結果”、毫無疑問地應該包括清晰的輸入數據和預期輸出，沒有測試數據的用例最多只具有指導性的意義，不具有可執行 性。當然，測試用例中包含輸入數據會帶來維護、與測試環境同步之類的問題，關于這一點，《Effective Software Test》一書中提供了詳細的測試用例、測試數據的維護方法，可以參考。
·測試用例中不需要明顯的驗證手段；
我見過很多測試工程師編寫的測試用例中，“預期輸出”僅描述為程序的可見行為，其實，“預期結果”的含義并不只是程序的可見行為。例如，對一個訂貨系統， 輸入訂貨數據，點擊“確定”按鈕后，系統提示“訂貨成功”，這樣是不是一個完整的用例呢？是不是系統輸出的“訂貨成功”就應該作為我們唯一的驗證手段呢？ 顯然不是。訂貨是否成功還需要查看相應的數據記錄是否更新，因此，在這樣的一個用例中，還應該包含對測試結果的顯式的驗證手段：在數據庫中執行查詢語句進行查詢，看查詢結果是否與預期的一致。
七、從用例中生成測試用例
用于功能性測試的測試用例來源于測試目標的用例。應該為每個用例場景編制測試用例。用例場景要通過描述流經用例的路徑來確定，這個流經過程要從用例開始到結束遍歷其中所有基本流和備選流。
例如，下圖中經過用例的每條不同路徑都反映了基本流和備選流，都用箭頭來表示�；玖饔弥焙诰�來表示，是經過用例的最簡單的路徑。每個備選流自基本流開始，之后，備選流會在某個特定條件下執行。備選流可能會重新加入基本流中（備選流 1 和 3），還可能起源于另一個備選流（備選流 2），或者終止用例而不再重新加入某個流（備選流 2 和 4）。
用例的事件流示例
遵循上圖中每個經過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結合起來，可以確定以下用例場景：
場景 1 基本流 場景 2 基本流備選流 1 場景 3 基本流備選流 1 備選流 2 場景 4 基本流備選流 3 場景 5 基本流備選流 3 備選流 1 場景 6 基本流備選流 3 備選流 1 備選流 2 場景 7 基本流備選流 4 場景 8 基本流備選流 3 備選流 4注：為方便起見，場景 5、6 和 8 只描述了備選流 3 指示的循環執行一次的情況。
生成每個場景的測試用例是通過確定某個特定條件來完成的，這個特定條件將導致特定用例場景的執行。
例如，假定上圖描述的用例對備選流 3 規定如下：
“如果在上述步驟 2'輸入提款金額’中輸入的美元量超出當前帳戶余額，則出現此事件流。系統將顯示一則警告消息，之后重新加入基本流，再次執行上述步驟 2'輸入提款金額’，此時銀行客戶可以輸入新的提款金額�！�
據此，可以開始確定需要用來執行備選流 3 的測試用例：
測試用例 ID 場景條件預期結果 TC x 場景 4 步驟 2 - 提款金額 > 帳戶余額在步驟 2 處重新加入基本流 TC y 場景 4 步驟 2 - 提款金額 < 帳戶余額不執行備選流 3，執行基本流 TC z 場景 4 步驟 2 - 提款金額 = 帳戶余額不執行備選流 3，執行基本流注：由于沒有提供其他信息，以上顯示的測試用例都非常簡單。測試用例很少如此簡單。
下面是一個由用例生成測試用例的更符合實際情況的示例。
示例：
一臺 ATM 機器的主角和用例。
下表包含了上圖中提款用例的基本流和某些備用流：
本用例的開端是 ATM 處于準備就緒狀態。 準備提款 - 客戶將銀行卡插入 ATM 機的讀卡機。
驗證銀行卡 - ATM 機從銀行卡的磁條中讀取帳戶代碼，并檢查它是否屬于可以接收的銀行卡。
輸入 PIN - ATM 要求客戶輸入 PIN 碼（4 位）
驗證帳戶代碼和 PIN - 驗證帳戶代碼和 PIN 以確定該帳戶是否有效以及所輸入的 PIN 對該帳戶來說是否正確。對于此事件流，帳戶是有效的而且 PIN 對此帳戶來說正確無誤。
ATM 選項 - ATM 顯示在本機上可用的各種選項。在此事件流中，銀行客戶通常選擇“提款”。
輸入金額 - 要從 ATM 中提取的金額。對于此事件流，客戶需選擇預設的金額（10 美元、20 美元、50 美元或 100 美元）。
授權 - ATM 通過將卡 ID、PIN、金額以及帳戶信息作為一筆交易發送給銀行系統來啟動驗證過程。對于此事件流，銀行系統處于聯機狀態，而且對授權請求給予答復，批準完成提款過程，并且據此更新帳戶余額。
出鈔 - 提供現金。
返回銀行卡 - 銀行卡被返還。
收據 - 打印收據并提供給客戶。ATM 還相應地更新內部記錄。
用例結束時 ATM 又回到準備就緒狀態。
如果 PIN 輸入有誤，ATM 將顯示適當的消息；如果還存在輸入機會，則此事件流在步驟 3 - 輸入 PIN 處重新加入基本流。
如果最后一次嘗試輸入的 PIN 碼仍然錯誤，則該卡將被 ATM 機保留，同時 ATM 返回到準備就緒狀態，本用例終止。 備選流 5 - 帳戶不存在在基本流步驟 4 中 - 驗證帳戶和 PIN，如果銀行系統返回的代碼表明找不到該帳戶或禁止從該帳戶中提款，則 ATM 顯示適當的消息并且在步驟 9 - 返回銀行卡處重新加入基本流。 備選流 6 - 帳面金額不足在基本流步驟 7 - 授權中，銀行系統返回代碼表明帳戶余額少于在基本流步驟 6 - 輸入金額內輸入的金額，則 ATM 顯示適當的消息并且在步驟 6 - 輸入金額處重新加入基本流。 備選流 7 - 達到每日最大的提款金額在基本流步驟 7 - 授權中，銀行系統返回的代碼表明包括本提款請求在內，客戶已經或將超過在 24 小時內允許提取的最多金額，則 ATM 顯示適當的消息并在步驟 6 - 輸入金額上重新加入基本流。 備選流 x - 記錄錯誤如果在基本流步驟 10 - 收據中，記錄無法更新，則 ATM 進入“安全模式”，在此模式下所有功能都將暫停使用。同時向銀行系統發送一條適當的警報信息表明 ATM 已經暫停工作。 備選流 y - 退出客戶可隨時決定終止交易（退出）。交易終止，銀行卡隨之退出。 備選流 z - “翹起” ATM 包含大量的傳感器，用以監控各種功能，如電源檢測器、不同的門和出入口處的測壓器以及動作檢測器等。在任一時刻，如果某個傳感器被激活，則警報信號將發送給警方而且 ATM 進入“安全模式”，在此模式下所有功能都暫停使用，直到采取適當的重啟/重新初始化的措施。
在第一次迭代中，根據迭代計劃，我們需要核實提款用例已經正確地實施。此時尚未實施整個用例，只實施了下面的事件流：
可以從這個用例生成下列場景
場景 1 - 成功的提款基本流 場景 2 - ATM 內沒有現金基本流備選流 2 場景 3 - ATM 內現金不足基本流備選流 3 場景 4 - PIN 有誤（還有輸入機會）基本流備選流 4 場景 5 - PIN 有誤（不再有輸入機會）基本流備選流 4 場景 6 - 帳戶不存在/帳戶類型有誤基本流備選流 5 場景 7 - 帳戶余額不足基本流備選流 6 注：為方便起見，備選流 3 和 6（場景 3 和 7）內的循環以及循環組合未納入上表。對于這 7 個場景中的每一個場景都需要確定測試用例�？梢圆捎镁仃嚮驔Q策表來確定和管理測試用例。下面顯示了一種通用格式，其中各行代表各個測試用例，而各列則代表測試用例的信息。本示例中，對于每個測試用例，存在一個測試用例 ID、條件（或說明）、測試用例中涉及的所有數據元素（作為輸入或已經存在于數據庫中）以及預期結果。
通過從確定執行用例場景所需的數據元素入手構建矩陣。然后，對于每個場景，至少要確定包含執行場景所需的適當條件的測試用例。例如，在下面的矩陣中，V（有效）用于表明這個條件必須是 VALID（有效的）才可執行基本流，而 I（無效）用于表明這種條件下將激活所需備選流。下表中使用的“n/a”（不適用）表明這個條件不適用于測試用例。
TC（測試用例）ID 號場景/條件 PIN帳號
輸入的金額
（或選擇的金額）
帳面金額
ATM 內的金額
預期結果 CW1. 場景 1 - 成功的提款 V V V V V 成功的提款。 CW2. 場景 2 - ATM 內沒有現金 V V V V I 提款選項不可用，用例結束 CW3. 場景 3 - ATM 內現金不足 V V V V I 警告消息，返回基本流步驟 6 - 輸入金額 CW4. 場景 4 - PIN 有誤（還有不止一次輸入機會） I
V n/a V V 警告消息，返回基本流步驟 4，輸入 PIN CW5. 場景 4 - PIN 有誤（還有一次輸入機會） I
V n/a V V 警告消息，返回基本流步驟 4，輸入 PIN CW6. 場景 4 - PIN 有誤（不再有輸入機會） I
V n/a V V 警告消息，卡予保留，用例結束
在上面的矩陣中，六個測試用例執行了四個場景。對于基本流，上述測試用例 CW1 稱為正面測試用例。它一直沿著用例的基本流路徑執行，未發生任何偏差�；玖鞯娜鏈y試必須包括負面測試用例，以確保只有在符合條件的情況下才執行基本流。這些負面測試用例由 CW2 至 6 表示（陰影單元格表明這種條件下需要執行備選流）。雖然 CW2 至 6 對于基本流而言都是負面測試用例，但它們相對于備選流 2 至 4 而言是正面測試用例。而且對于這些備選流中的每一個而言，至少存在一個負面測試用例（CW1 - 基本流）。
每個場景只具有一個正面測試用例和負面測試用例是不充分的，場景 4 正是這樣的一個示例。要全面地測試場景 4 - PIN 有誤，至少需要三個正面測試用例（以激活場景 4）：
輸入了錯誤的 PIN，但仍存在輸入機會，此備選流重新加入基本流中的步驟 3 - 輸入 PIN。 輸入了錯誤的 PIN，而且不再有輸入機會，則此備選流將保留銀行卡并終止用例。 最后一次輸入時輸入了“正確”的 PIN。備選流在步驟 5 - 輸入金額處重新加入基本流。注：在上面的矩陣中，無需為條件（數據）輸入任何實際的值。以這種方式創建測試用例矩陣的一個優點在于容易看到測試的是什么條件。由于只需要查看 V 和 I（或此處采用的陰影單元格），這種方式還易于判斷是否已經確定了充足的測試用例。從上表中可發現存在幾個條件不具備陰影單元格，這表明測試用例還不完全，如場景 6 - 不存在的帳戶/帳戶類型有誤和場景 7 - 帳戶余額不足就缺少測試用例。
一旦確定了所有的測試用例，則應對這些用例進行復審和驗證以確保其準確且適度，并取消多余或等效的測試用例。
測試用例一經認可，就可以確定實際數據值（在測試用例實施矩陣中）并且設定測試數據
TC（測試用例）ID 號場景/條件 PIN帳號
輸入的金額
（或選擇的金額）
帳面金額
ATM 內的金額
預期結果 CW1. 場景 1 - 成功的提款 4987 809 - 498 50.00 500.00 2,000 成功的提款。帳戶余額被更新為 450.00 CW2. 場景 2 - ATM 內沒有現金 4987 809 - 498 100.00 500.00 0.00 提款選項不可用，用例結束 CW3. 場景 3 - ATM 內現金不足 4987 809 - 498 100.00 500.00 70.00 警告消息，返回基本流步驟 6 - 輸入金額 CW4. 場景 4 - PIN 有誤（還有不止一次輸入機會） 4978
809 - 498 n/a 500.00 2,000 警告消息，返回基本流步驟 4，輸入 PIN CW5. 場景 4 - PIN 有誤（還有一次輸入機會） 4978
809 - 498 n/a 500.00 2,000 警告消息，返回基本流步驟 4，輸入 PIN CW6. 場景 4 - PIN 有誤（不再有輸入機會） 4978
809 - 498 n/a 500.00 2,000 警告消息，卡予保留，用例結束
以上測試用例只是在本次迭代中需要用來驗證提款用例的一部分測試用例。需要的其他測試用例包括：
場景 6 - 帳戶不存在/帳戶類型有誤：未找到帳戶或帳戶不可用 場景 6 - 帳戶不存在/帳戶類型有誤：禁止從該帳戶中提款 場景 7 - 帳戶余額不足：請求的金額超出帳面金額在將來的迭代中，當實施其他事件流時，在下列情況下將需要測試用例：
無效卡（所持卡為掛失卡、被盜卡、非承兌銀行發卡、磁條損壞等） 無法讀卡（讀卡機堵塞、脫機或出現故障） 帳戶已消戶、凍結或由于其他方面原因而無法使用 ATM 內的現金不足或不能提供所請求的金額（與 CW3 不同，在 CW3 中只是一種幣值不足，而不是所有幣值都不足） 無法聯系銀行系統以獲得認可 銀行網絡離線或交易過程中斷電在確定功能性測試用例時，確保滿足下列條件：
已經為每個用例場景確定了充足的正面和負面測試用例。 測試用例可以處理用例所實施的所有業務規則，確保對于業務規則，無論是在內部、外部還是在邊界條件/值上都存在測試用例。 測試用例可以處理所有事件或動作排序（如在設計模型的序列圖中確定的內容），還應能處理用戶界面對象狀態或條件。 測試用例可以處理為用例所指定的任何特殊需求，如最佳/最差性能，有時這些特殊需求會與用例執行過程中的最小/最大負載或數據容量組合在一起。 八、從補充規約中生成測試用例并不是所有的測試目標需求都將在用例中有所反映。非功能性需求（如性能、安全性和訪問控制）以及配置要求等將會說明測試目標的其他行為或特征。補充規約是為其他行為生成測試用例的主要來源。
關于如何生成這些其他測試用例的指南說明如下：
為性能測試生成測試用例 為安全性/訪問控制測試生成測試用例 為配置測試生成測試用例 為安裝測試生成測試用例 為其他非功能性測試生成測試用例 為性能測試生成測試用例性能測試用例的主要輸入是補充規約，補充規約中包含了非功能性需求（請參見工件：補充規約）。為性能測試生成測試用例時，請使用下列指南：
對于補充規約內闡明性能標準的各條說明都應確保至少要確定一個測試用例。性能標準通常表示為時間/事務、事務量/用戶或百分數的形式。 對每個關鍵用例，都應確保至少要確定一個測試用例。關鍵用例是在上述說明中和/或在工作量分析文檔中確定的、必須采用性能評測方法來評估的用例（請參見工件：工作量分析文檔）。與功能性測試的測試用例類似，通常對于每個用例/需求都會存在不止一個測試用例。常見的情況是：存在一個低于性能閾值的測試用例、一個處于閾值上的測試用例，還有一個測試用例高于閾值。
除了以上性能標準以外，確保已確定影響響應時間的特定條件，包括：
數據庫的大小 - 存在多少個記錄？ 工作量 - 同時執行操作的最終用戶的數量和類型，以及要同時執行的事務的數量和類型 環境特征（硬件、網件以及軟件配置）將用于性能測試的測試用例記錄在類似于功能測試所使用的矩陣中。
以下是各種性能測試的一些示例：
對于負載測試：
TC（測試用例）ID 號工作量條件預期結果 PCW1. 1 （單個 ATM） 完成提款交易 全部交易（不依賴于主角的時間）在 20 秒之內完成 PCW2. 2 （1,000 個同時運行的 ATM） 完成提款交易 全部交易（不依賴于主角的時間）在 30 秒之內完成 PCW3. 3 （10.000 個同時運行的 ATM） 完成提款交易 全部交易（不依賴于主角的時間）在 50 秒之內完成
對于強度測試：
TC（測試用例）ID 號工作量條件預期結果 SCW1. 2 （1,000 個同時運行的 ATM） 數據庫鎖定 - 2 個 ATM 請求同一帳戶 ATM 請求排成隊列 SCW2. 2 （1,000 個同時運行的 ATM） 無法實現銀行系統的通信 交易排成隊列或超時 SCW3. 2 （1,000 個同時運行的 ATM） 在交易過程中，銀行系統通信被終止 顯示警告消息為安全性/訪問控制測試生成測試用例
主角和用例一同說明系統外部用戶與系統所執行的動作之間的交互，以便為特定主角生成測試結果。復雜系統包含許多主角，所以我們編制測試用例時必須確保只有指定執行用例的主角可以進行此操作，這一點非常關鍵。在基于主角類型的用例事件流存在差別時，尤其如此。
例如，在 ATM 用例中，如果主角“銀行客戶”的卡和帳戶有的屬于擁有這個 ATM 機的銀行，有的是競爭銀行的銀行卡（和帳戶），或是企圖使用該 ATM 不支持的銀行卡，則將對該主角“銀行客戶”執行不同的用例事件流。
對于功能性測試用例，請同樣遵循上面列舉的指南。
關于安全性和訪問控制測試用例的示例：
TC（測試用例）ID 號條件卡（V 表明卡有效）
讀卡機（V 表明讀卡機工作正常）
銀行的網絡預期結果 ACW1. 在銀行網絡之內 V V V 所有用例都可用 ACW2. 銀行網絡之外 V V I 只有提款用例可用 ACW3. 無法讀卡 I V V 警告消息，卡被退出 ACW4. 因被盜，卡已掛失 I V V 警告消息，卡予保留 ACW5. 卡已過期 I V V 警告消息，卡予保留為配置測試生成測試用例
文章來源于領測軟件測試網 http://www.kjueaiud.com/
