準則: 測試案例
這個準則說明如何識別和設計測試軟體。
關係
主要說明

說明

對於專案小組能不能確定軟體滿足關係人需求,是否取得關係人預期的明確規格所造成的影響最大。但不論有沒有一組夠好的需求規格,測試案例都是有助於反映關係人預期的構件,它使這些預期能夠接受驗證。

當能夠取得一組有用的需求時,測試小組必須規劃測試來適當驗證這些需求。請注意,對照需求來驗證軟體的方式,可能會隨著需求類型而不同。例如,執行軟體來驗證它的功能和效能需求,可能是由測試者利用自動化測試技術來進行,而驗證配置需求(如關閉主機系統)則可能需要利用手動測試技術來完成。

由於您可能無法(或負責)驗證所有需求,因此,請務必針對目前工作努力的範圍,將焦點放在最適當或最重要的需求。您選擇要驗證的需求,將是成本、風險及需求驗證之必要性的平衡,一般而言,只限於現行反覆的範圍。

需求雖是衍生測試的重要來源,但它們並不是唯一資訊來源。事實上,在許多情況下,它們並不足以提供開發測試的完整基礎。另外,您也應該考慮以風險、限制、技術、變更需求(問題)、錯誤等資訊來源為基礎的測試案例。
請參閱概念:測試觀念,以取得如何備妥測試衍生來源之觀念的相關資訊。

基於許多種原因,識別測試案例非常有用。

  • 測試案例可用來作為設計和實作實際測試的基礎。考量測試案例所花的時間,有助於深入瞭解設計和實作需求,且可能節省設計和實作工作所花的時間。
  • 有些測試特別複雜或詳細。這類特性的測試會因為在測試實作開始之前的謹慎考量而受益,測試案例和測試設計構件都是探索這些考量的好工具。
  • 測試的「深度」通常被認為與測試的數目成比例。當測試的潛在的可能「深度」可以根據所識別之測試案例的數目而推理時,測試流程本身的可信度通常也會越高。
  • 測試工作完成度的一項測量,是以針對某組動機元素來監視涵蓋面為基礎。涵蓋面報告的基礎可以是如下各項測量:識別的測試案例數目,以及針對各個測試案例來實作和/或執行的測試數目,或各個測試案例所耗費的工作量。
  • 測試工作的等級和複雜度與測試案例的數目,在某種程度上是成比例的。在分析測試案例之後,就可以在較精細的粒度層次上推斷測試工作。
  • 測試設計和開發的類型以及所需要的資源,會部分受到測試案例數目和複雜度的支配。

不過,關於測試案例,仍有些值得考慮的問題:

  • 並非所有測試的複雜度都足以合理要求付出成本來建立需要檢視和維護的測試案例構件:測試會簡單到只要簡短的說明文字,就足以表達所需要的項目。 事實上,大部分的測試案例都落入這個範疇中。建立大量簡單測試的文件所花的時間,可能會剝奪重要測試作業的時間。
  • 您某些最初的測試觀念,後來會證明為在某些方面有問題。這表示最初以這些觀念為基礎來識別的某些測試案例,最後會放棄。這個事實表明您為了詳細建立測試案例文件而花的工夫,後來也可能放棄,以測試案例為基礎的任何涵蓋面報告都必須考慮這個情況。因此,您最好將涵蓋面報告植基於比測試案例還高階的考量,將測試案例視為依照需要來使用的內部測試小組構件。

測試案例通常是依相關測試的測試類型或需求來分類,且會據此而有所不同。用來識別測試案例的一種探索方式是開始於:

  • 示範已實現需求(正面測試案例)
  • 示範在所想要的條件之下實現需求,這稱為負面測試。這個測試案例反映一些不可接受的、異常的或非預期的狀況或資料,軟體可能會適度地受到這些狀況或資料的支配。

從使用案例衍生測試案例

功能測試的測試案例是從測試目標使用案例衍生而來(請參閱工作成果:使用案例)。每個使用案例情境都應該開發測試案例。使用案例情境是藉由說明使用案例中的路徑來識別,在使用案例中,這些路徑會從頭到尾遍訪基本流程和備用流程。

例如,在下圖中,利用箭頭來表示使用案例中每個反映了基本和備用流程的不同路徑。黑色直線所代表的基本流程是使用案例中最簡單的路徑。每個備用流程都開始於基本流程,之後,再依賴特定條件來執行備用流程。備用流程可以重新結合基本流程(備用流程 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。
  1. 起始提款 - 客戶將信用卡插入 ATM 機的讀卡機
  2. 驗證信用卡 - ATM 從信用卡的磁條中讀取帳戶碼,檢查信用卡是否有效。
  3. 輸入 PIN - ATM 要求客戶的 PIN 碼(4 位數)
  4. 驗證帳戶碼和 PIN - 驗證帳戶碼和 PIN 來判斷帳戶是否有效,輸入的 PIN 是否為帳戶的正確 PIN。在這個流程中,帳戶是有效帳戶,PIN 是關聯於這個帳戶的正確 PIN。
  5. ATM 選項 - ATM 顯示這個 ATM 所提供的不同選擇方案。在這個流程中,銀行客戶一律選取「提款」。
  6. 輸入金額 - ATM 會詢問提款金額。在這個流程中,客戶選取預設金額 ($10、$20、$50 或 $100)。
  7. 授權 - ATM 利用交易來傳送信用卡 ID、PIN、金額和帳戶資訊,起始銀行系統的驗證流程。在這個流程中,銀行系統在線上,依權限回答來順利完成這項提款,並據此更新帳戶餘額。
  8. 發放 - 發放現金。
  9. 退回卡片 - 退回信用卡。
  10. 收據 - 列印和發放收據。ATM 也會據此更新內部日誌。 

使用案例結束,ATM 在備妥狀態。

備用流程 1 - 不是有效的卡 在基本流程「第 2 步驟中 - 驗證信用卡」中,如果無效,便將它退出,並顯示適當訊息。
備用流程 2 - ATM 金額用完 在基本流程「第 5 步驟 - ATM 選項」中,如果 ATM 金額用完,就無法使用「提款」選項。
備用流程 3 - ATM 金額不足 在基本流程「第 6 步驟 - 輸入金額」中,如果 ATM 的金額不足,無法發放所要求的金額,就會顯示適當的訊息,且會重新結合基本流程「第 6 步驟 - 輸入金額」。
備用流程 4 - PIN 不正確 在基本流程「第 4 步驟 - 驗證帳戶和 PIN」中,客戶可以試三次輸入正確的 PIN。  

如果輸入不正確的 PIN,ATM 會顯示適當的訊息,如果仍有重試機會,這個流程會重新結合基本流程「第 3 步驟 - 輸入 PIN」。 

如果最後一次嘗試輸入的 PIN 號碼仍不正確,就會保留卡片,ATM 會返回備妥狀態,這個使用案例便告終止。
備用流程 5 - 沒有帳戶 在基本流程「第 4 步驟 - 驗證帳戶和 PIN」中,如果銀行系統傳回的代碼指出找不到帳戶或帳戶不允許提款,ATM 會顯示適當的訊息,且會重新結合基本流程「第 9 步驟 - 退回卡片」。
備用流程 6 - 帳戶金額不足 在基本流程「第 7 步驟 - 授權」中,銀行系統傳回一個代碼,指出帳戶餘額小於基本流程「第 6 步驟 - 輸入金額」所輸入的金額,ATM 會顯示適當的訊息,且會重新結合基本流程「第 6 步驟 - 輸入金額」。
備用流程 7 - 已達每日提款金額上限 在基本流程「第 6 步驟 - 授權」中,銀行系統傳回一個代碼,指出包括這個提款要求,客戶已超出或將超出 24 小時期間內所允許的金額上限,ATM 會顯示適當的訊息,且會重新結合基本流程「第 6 步驟 - 輸入金額」。
備用流程 x - 日誌錯誤 如果在基本流程「第 10 步驟 - 收據」中,無法更新日誌,ATM 會進入「安全模式」,暫停所有功能。這時會傳送適當的警報給銀行系統,指出 ATM 已暫停作業。
備用流程 y - 退出 客戶隨時可以決定終止交易(退出)。這時會停止交易,退出卡片。
備用流程 z - "傾斜" ATM 包含許多監視不同功能的感應器,如電源、施加於各個門板和閘道的壓力,以及動作探測器。如果在任何時候啟動了某個感應器,就會傳送一個警報信號給警察,ATM 會進入「安全模式」,暫停所有功能,直到採取適當的重新啟動/重新起始設定動作。


在第一次反覆時,依照反覆計劃,我們必須驗證已正確實作「提款」使用案例。這時只實作了下列部分,尚未實作整個使用案例:

  • 基本流程 - 提領預設金額 ($10、$20、$50、$100)
  • 備用流程 2 - ATM 金額用完
  • 備用流程 3 - ATM 金額不足
  • 備用流程 4 - PIN 不正確
  • 備用流程 5 - 沒有帳戶/帳戶類型不正確
  • 備用流程 6 - 帳戶金額不足

這個使用案例可以衍生下列情境:

情境 1 - 順利提款 基本流程  
情境 2 - ATM 金額用完 基本流程 備用流程 2
情境 3 - ATM 金額不足 基本流程 備用流程 3
情境 4 - PIN 不正確(仍可嘗試) 基本流程 備用流程 4
情境 5 - PIN 不正確(不能再嘗試) 基本流程 備用流程 4
情境 6 - 沒有帳戶/帳戶類型不正確 基本流程 備用流程 5
情境 7 - 帳戶餘額不足 基本流程 備用流程 6

附註:為了簡單,上表未併入備用流程 3 和 6(情境 3 和 7)的迴圈及迴圈的組合。

這七個情境都要識別測試案例。您可以利用矩陣或決策表來識別和管理測試案例。以下顯示一般格式,每列都代表個別測試案例,直欄用來識別測試案例資訊。在這個範例中,每個測試案例都有一個測試案例 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 不正確(可以再試 > 1 次) V n/a V V 警告訊息,返回基本流程第 4 步驟 , 輸入 PIN
CW5. 情境 4 - PIN 不正確(可以再試 1 次) V n/a V V 警告訊息,返回基本流程第 4 步驟 , 輸入 PIN
CW6. 情境 4 - PIN 不正確(可以再試 0 次) V n/a V V 警告訊息,保留卡片,使用案例結束

在上述矩陣中,六個測試案例執行四個情境。對基本流程而言,上述 CW1 測試案例稱為正面的測試案例。它會在使用案例中執行基本流程路徑,不會有任何偏差。基本流程的綜合性測試必須包括負面的測試案例,以確保只有在條件正確時,才採取基本流程。這些負面的測試案例是測試案例 CW2 - 6 所代表(陰影化的資料格表示執行備用流程所需要的條件)。雖然 CW2 - 6 對基本流程而言是負面測試案例,但對備用流程 2- 4 而言,它們是正面測試案例,每個這些備用流程(CW1 - 基本流程)至少有一個負面測試案例。

情境 4 是每個情境只有正負測試案例各一個並不夠的範例。如果要徹底測試「情境 4 - PIN 不正確」,至少需要 3 個正面測試案例(用來呼叫情境 4):

  • 輸入不正確的 PIN,仍可以嘗試,這個備用流程會重新結合基本流程「第 3 步驟 - 輸入 PIN」。
  • 輸入不正確的 PIN,不能再試,這個備用流程會保留卡片,終止使用案例。
  • 當不能再試時,輸入 CORRECT 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 不正確(可以再試 > 1 次) 4978  809 - 498 n/a 500.00 2,000 警告訊息,返回基本流程第 4 步驟 , 輸入 PIN
CW5. 情境 4 - PIN 不正確(可以再試 1 次) 4978 809 - 498 n/a 500.00 2,000 警告訊息,返回基本流程第 4 步驟 , 輸入 PIN
CW6. 情境 4 - PIN 不正確(可以再試 0 次) 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 所屬的銀行,相對於所用信用卡(和帳戶)是來自對手銀行或試圖使用非參與銀行信用卡的「銀行客戶」,這時「銀行客戶」參與者可能會執行不同的使用案例事件流程。

請遵循上面列出的相同準則來處理功能測試案例。

請參閱定義測試案例的測試資料一節,以取得其他指引。

安全和存取的範例測試案例:

TC ID# 狀況 卡片

(V 表示卡片有效)

讀卡機

(V 表示讀卡機能正確運作)

銀行網路 預期的結果
ACW1. 在銀行網路中 V V V 所有使用案例都可以使用
ACW2. 銀行網路無法使用 V V I 只限「提款」使用案例
ACW3. 無法讀卡 I V V 警告訊息,退出卡片
ACW4. 報告卡片遭竊用 I V V 警告訊息,保留卡片
ACW5. 卡片過期 I V V 警告訊息,保留卡片

衍生配置測試的測試案例

在一般分散式系統中,支援的軟硬體組合有許多種。 應該執行測試來驗證在不同的配置中,測試目標都能夠以可接受的方式來運作或執行,比方說,有不同的作業系統、瀏覽器或 CPU 速度。另外,測試也必須涵蓋各種元件的組合,以彰顯出不同元件互動所產生的問題,例如,確定應用程式所安裝的 DLL 版本不會與另一應用程式所預期之相同 DLL 的版本衝突。

如果要衍生配置測試的測試案例,請使用下列準則:

  • 確定至少有一個識別每個重要配置的測試案例。這項作業的方式是識別測試目標環境所需要的軟硬體配置,以及排定配置的優先順序,確定最常用的配置最先測試,其中包括:
    • 印表機支援
    • 網路連線 - 區域和廣域網路
    • 伺服器配置 - 伺服器驅動程式、伺服器硬體
    • 安裝在桌面和/或伺服器中的其他軟體
    • 所有已安裝的軟體之軟體版本
  • 確定每個可能有問題的配置至少都有一個測試案例。這裡面可能包括:
    • 效能最差的硬體。
    • 有相容性問題歷程的共存軟體。
    • 利用可能最慢的 LAN/WAN 連線來存取伺服器的用戶端。
    • 資源不足(CPU 速度太慢、記憶體或解析度太小、磁碟空間...等)

衍生安裝測試的測試案例

安裝測試必須確認在所有可能的安裝情境之下,都能夠安裝測試目標。安裝情境可包括第一次安裝測試目標,或安裝測試目標較新的版本或建置(安裝到含有較舊版本的機器中)。另外,安裝測試也應該確定在發生異常狀況時,如磁碟空間不足,也能夠以可接受的方式來執行測試目標。

測試案例應該涵蓋的軟體安裝情境包括:

  • 分送媒體,如磁片、CD-ROM 或檔案伺服器。
  • 新的安裝。
  • 完整安裝。
  • 自訂安裝。
  • 升級安裝。

主從架構軟體的安裝程式有一組特殊的測試案例。安裝程式不像主機型的系統,它通常會有伺服器和用戶端之分。因此,安裝測試必須執行測試目標所有元件的安裝,用戶端、中間層和伺服器都包括在內,這一點非常重要。

衍生其他非功能測試的測試案例

理想上,您應該找出所有必要的輸入來衍生在使用案例模型、設計模型和增補規格構件中的測試案例。不過,這時往往需要補充其中所發現的內容。

例如:

  • 作業測試的測試案例(確認當「長時間」使用軟體時,在失敗之間,軟體仍能夠運作)。
  • 探索效能瓶頸、系統容量或迫使測試目標失敗的測試案例。

在大部分情況下,您都可以建立先前識別的測試案例所衍生之測試案例的變式或聚集來尋找這些測試案例。

衍生產品驗收測試的測試案例

產品驗收測試是部署軟體之前的最後一個測試動作。驗收測試的目標是確認軟體已就緒,使用者可以利用軟體來執行軟體建置所要完成的功能和作業。產品驗收測試通常不只包括執行軟體以確認備妥,另外,它也包括交付給客戶的這個產品的所有工作成果,如訓練、文件和套裝。 

軟體工作成果的測試案例是依照上述各節所說明的方式來衍生的。依產品驗收測試的程度和形式而定,測試案例會如同或類似上面所識別的測試案例(正式),或其中一部分(非正式)。在實作和執行產品測試之前,應該就測試案例和產品驗收準則達到共識,它與測試案例的深度無關。

非軟體工作成果的評估會隨著所評估的工作成果而大不相同。請參閱每個特定非軟體工作成果的準則和核對清單,以取得評估內容及方式的相關資訊。

建置迴歸測試的驗證測試案例

迴歸測試會比較相同測試目標的兩個建置或版本,且會將差異識別為潛在的問題。這時它會假設新版本的行為應該類似舊版本,且會確定變更結果沒有造成問題。

理想上,您會想將一次反覆的所有測試案例用來作為後來反覆的測試案例。您應該利用下列準則來識別、設計和實作測試案例,使它們既能將迴歸測試的價值最大化,加以重複使用,又能將維護減到最少:

  • 確定測試案例只識別了關鍵資料元素(建立/支援測試的條件時所需要的資料元素)
  • 確定每個測試案例都依測試目標來說明或代表會產生獨特行為的一組獨特輸入或事件序列
  • 刪除多餘或相等的測試案例
  • 將有相同測試目標起始狀態和測試資料狀態的測試案例放在一起

定義測試案例的測試資料

討論了測試案例,有了一般共識/核准之後,就可以開始更詳細識別實際的資料值(例如,在測試案例實作矩陣中)及建立測試資料構件。

請參閱準則:測試資料,以取得定義和維護測試資料的其他相關資訊。