定義測試案例和優先順序

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

Ramona Schwering

在上一篇文章中，您已瞭解測試策略、測試應用程式所需的測試次數，以及如何在考量資源的情況下，找出最適合您情況的測試策略，以便取得最可靠的結果。不過，這只是讓我們瞭解要測試多少內容。您仍需要明確決定要測試哪些項目。您可以參考下列三項條件，瞭解測試內容，並找出最適合的測試類型和詳細程度：

1. 確保正常流程運作。這是應用程式最常見或主要的使用者故事，使用者會很快發現錯誤。
2. 謹慎決定詳細程度。進一步瞭解您的用途是否容易遭到攻擊，或錯誤可能造成嚴重損害。
3. 盡可能優先執行較低層級的測試，例如單元和整合測試，而非高階端對端測試。

本文的其餘部分將探討這些條件，以及在定義測試案例時如何套用這些條件。

什麼是測試案例？

在軟體開發中，測試案例是一系列的動作或情況，用於確認軟體程式或應用程式的有效性。測試案例的目的在於確保軟體能按計劃運作，且所有功能都能正常運作。軟體測試人員或開發人員通常會建立這些測試案例，確保軟體符合指定的規範和規格。

執行測試案例時，軟體會執行一系列檢查，確保產生預期結果。在執行這項操作時，測試會執行下列工作：

• 驗證：徹底檢查軟體，確保其運作無誤的過程。因此，您必須判斷所建立的產品是否符合所有必要的非功能性需求，並成功達成預期目的。這個指標的答案是：「我們打造的產品是否正確？」
• 驗證。確保軟體產品符合必要標準或高層級需求的程序。這項測試會檢查實際產品是否與預期產品相符。基本上，我們要回答的問題是：「我們是否根據使用者需求打造合適的產品？」

假設程式無法達到預期的結果。在這種情況下，測試案例會成為訊息傳遞者，因此會回報失敗結果，而開發人員或測試人員則需要調查問題並找出解決方案。無論測試類型為何，您可以將檢查和動作視為電腦遵循的路徑。用於檢查的輸入資料或條件組合稱為「同等類別」。這些測試應可從測試系統中獲得類似的行為或結果。測試中執行的特定路徑可能會有所不同，但應與測試中執行的活動和斷言相符。

測試路徑：常見的測試案例類型

在軟體開發中，測試案例是指程式碼執行情境，可用於預期及測試特定行為。一般來說，有三種情境可用於建立測試案例。

第一個是大家最熟悉的，您可能已經在使用。這就是「滿意路徑」，也稱為「滿意情境」或「黃金路徑」。這項測試會定義功能、應用程式或變更最常見的用途，也就是這些功能、應用程式或變更應如何為客戶運作。

在測試案例中，第二個必須涵蓋的測試路徑通常會因為不方便而遭到忽略，這就是「可怕的路徑」，也就是負向測試。這個路徑針對導致程式碼異常或進入錯誤狀態的情況。如果您有極易遭到濫用，且對利益相關者或使用者造成高風險的用途，測試這些情境就特別重要。

您可能還想知道並考慮使用其他路徑，但這些路徑通常較少使用。下表總結了這些變更：

有幾種方法可以將這些路徑分類。兩種常見做法如下：

• 等值區隔。一種測試方法，可將測試案例分類為群組或區隔，進而協助建立同等類別。這項做法是基於以下概念：如果某個區隔中的一個測試案例發現缺失，同一個區隔中的其他測試案例可能也會發現類似的缺失。由於特定等價類別中的所有輸入內容都應顯示相同的行為，因此您可以減少測試案例的數量。進一步瞭解等價區隔。
• 限制分析。一種測試方法，也稱為邊界值分析，可檢查輸入值的限制或極端值，找出系統功能限制或限制可能發生的任何潛在問題或錯誤。

最佳做法：編寫測試案例

測試人員撰寫的傳統測試案例會包含特定資料，協助您掌握要進行的測試內容，並執行測試。一般測試人員會在表格中記錄測試工作。我們可在這個階段使用兩種模式，協助建構測試案例，並在稍後建構測試：

• Arrange、act、assert 模式。「安排、執行、斷言」(也稱為「AAA」或「Triple A」) 測試模式是一種將測試分成三個獨立步驟的做法：安排測試、執行測試，最後得出結論。
• 「Given-When-Then」模式。這個模式與 AAA 模式相似，但源自行為導向開發。

在後續文章中，我們會進一步說明這些模式，並介紹測試本身的結構。如果您想進一步瞭解這些模式，請參閱以下兩篇文章：Arrange-Act-Assert：寫出優質測試的模式和Given-When-Then。

根據本文的所有學習內容，下表列出經典範例：

在自動化測試中，您不需要以測試人員的方式記錄所有測試案例，雖然這麼做無疑很有幫助。只要留意，您就能在測試中找到所有這些資訊。因此，我們將這個傳統的測試案例轉換為自動化測試。