定義測試案例和優先順序

決定要測試的內容、定義測試案例，並排定優先順序。

Ramona Schwering

在前一篇文章中，您已瞭解測試策略、測試應用程式所需的測試數量，以及如何找出最適合取得結果的最佳方式，同時將資源列入考量。但這只是我們瞭解要測試多少量。您仍須明確決定要測試的內容。下列三項條件有助於瞭解測試相關預期，並查看哪種測試類型和詳細程度可能最適合：

  1. 做好萬全準備。這是您應用程式的最通用或主要使用者案例，使用者很快就會發現錯誤。
  2. 仔細決定資料詳細程度，此外，請進一步瞭解用途是否易受攻擊，或是某項錯誤會造成大量損害。
  3. 請盡可能優先執行低階測試 (例如單元和整合測試)，而非高階的端對端測試。

本文的其他部分將探討這些標準，以及如何在定義測試案例時應用這些標準。

什麼是測試案例？

在軟體開發階段，測試案例是指一系列操作或情況，旨在確認軟體程式或應用程式的有效性。 測試案例的目的在於確保軟體如預期運作，以及其所有功能與功能是否正常運作。軟體測試人員或開發人員通常會建立這些測試案例，確保軟體符合指定的需求與規格。

正在驗證測試案例。

執行測試案例時，軟體會執行一系列檢查，確認其可產生所需結果。執行時，測試會完成下列工作：

  • 驗證：徹底檢查軟體，確認軟體是否正常運作的程序。判斷現有產品是否符合所有必要的非功能性需求，並能否成功達成預定用途，至關重要。因此能解答這個問題：「我們的產品設計正確嗎？」
  • 驗證。確認軟體產品符合必要標準或高階需求的程序。包括確認實際產品是否符合預期。基本上，我們回答的問題是：「我們是否打造符合使用者需求的產品？」

假設程式未達成預期結果。在這種情況下，測試案例會是訊息傳遞工具，因此回報失敗的結果，開發人員或測試人員必須調查問題並找出解決方案。 您可以把這些檢查和動作想成電腦都是採取的路徑，不考慮測試類型。用於檢查的輸入資料或條件群組稱為「等價類別」。測試中系統應該也會取得類似的行為或結果。在測試中執行的特定路徑可能有所不同，但應與測試中的活動和斷言相符。

測試路徑：典型的測試案例類型

在軟體開發階段，「測試案例」是指程式碼執行情境，且會預期特定行為並進行測試。通常有三種情境可形成測試案例。

一切都順利

第一種是最知名的，您可能已經在使用過了。也就是快樂路徑，又稱為「愉快的日子」或「黃金路徑」。它定義了功能、應用程式或變動的最常見用途，也就是為客戶作業的方式。

真是令人不安的路徑。

在測試案例中，第二個最重要的測試路徑通常會遺漏，因為名稱可能就顯得並不舒適。這是「恐怖路徑」或「負測試」。這個路徑會鎖定可能導致程式碼異常或輸入錯誤狀態的情況。如果您的用途非常容易遭受攻擊，會使利益相關者或使用者受到高風險，測試這些情境就特別重要。

您也可以瞭解並考慮採用其他一些路徑，但這些路徑通常不受歡迎。下表摘要說明：

測試路徑 說明
憤怒的路徑 這會導致錯誤，但這是預期的情況；例如，如果您想要確保錯誤處理可正常運作，
欠款路徑 這個路徑會處理應用程式需要完成的任何安全性相關情境。
區隔路徑 您應用程式情境的路徑測試不足，資料不足以運作，例如測試空值。
健忘的步道 使用資源不足測試應用程式行為，例如觸發資料遺失。
決定路徑 邀請嘗試在應用程式中執行操作或追蹤應用程式使用者故事尚未完成，但尚未完成這些工作流程的使用者進行測試。舉例來說，當使用者中斷工作流程時，就可能發生這種情況。
貪婪路徑 嘗試使用大量的輸入內容或資料來進行測試。
壓力路徑 嘗試以任何必要的方式在應用程式上放置負載，直到不再正常運作為止 (類似負載測試)。

還有幾種方法可以分類這些路徑。以下提供兩種常見的做法：

  • 對等分區。一種測試方法，將測試案例分為群組或分區，因此有助於建立對等類別。根據概念，如果分區中的某個測試案例發現瑕疵，則同一個分區中的其他測試案例就可能會找出類似的瑕疵。由於特定等價類別中的所有輸入都應呈現相同的行為，因此您可以減少測試案例的數量。進一步瞭解對等分區。
  • 限制分析：一種測試方法，又稱為「邊界值分析」，可檢查輸入值的限製或極端，以找出可能引發系統功能限製或限制的任何潛在問題或錯誤。

最佳做法：編寫測試案例

由測試人員撰寫的傳統測試案例會包含特定資料，協助您掌握要進行的測試內容，當然也得執行測試。一般測試人員會用表格記錄測試成果，在這個階段，我們可以使用兩種模式，以便建立測試案例的結構，並於稍後自行建構測試：

  • 排列、行為、斷言模式。「安排、行為、斷言」(也稱為「AAA」或「Triple A」) 測試模式是將測試分為三個不同的步驟：安排測試、執行測試，以及最重要的是繪製結論。
  • Given, when, then 模式。這個模式與 AAA 模式類似，但在行為導向開發中有一些根層級。

等到我們涵蓋測試本身的架構後，之後的報導就會深入介紹這些模式。如想在這個階段深入瞭解這些模式，請參閱下列兩篇文章：Arrange-Act-Assert：撰寫成功測試的模式和Given-When-同樣。

根據本文中的所有學習成果，下表歸納出一個典型案例：

資訊 說明
必要條件 撰寫測試前必須完成的所有事項，
受測試的物件 需要驗證哪些資料？
輸入資料 變數及其值。
執行步驟 讓測試發揮所長，包括在測試中進行的所有動作或互動。
預期結果 客戶應採取的動作及達成的目標。
實際結果 實際上會發生什麼事。

在自動化測試中，您不一定要以測試人員需要的方式記錄所有測試案例，但這樣做並非很有用。如果您注意，可以在測試中找到所有資訊。我們接著將傳統測試案例轉化為自動化測試。

資訊 翻譯成測試自動化
必要條件 所有一切需求、安排測試，並思考哪些事項能順利測試。
受測試的物件 這個「物件」可以是各種內容：應用程式、流程、單元或測試中的元件。
輸入資料 參數值。
執行步驟 測試中執行的所有動作和指令、要執行的操作，以及瞭解您執行某些動作時會發生的情況。
預期結果 用來驗證應用程式的斷言，以及您在應用程式中主張的內容。
實際結果 自動化測試結果。