測試設計的過程中, 最主要是要說明測試要如何進行. 一般人會以為主要的產出是測試個案, 事實上還有其他的東西要思考.

我們舉開發人員在進行開發為例, 你會先做架構設計, 就是系統大約分成幾塊, 他們之間如何協作. 以及各個元件要遵守的設計原則會是什麼, 例如都是如何處理例外狀況, 版本升級都會做哪些處理等等. 然後我們才去進行細部設計, 把每個模組的運作細節給制訂出來.

同理, 在做測試也是如此. 在 IEEE 829 的標準中(這是針對軟體測試的標準), 如下圖所示, 我們會有測試設計規格書, 說明測試的高層次會怎麼做. 然後才是測試個案規格書, 說明每個測試個案詳細步驟是什麼. 然後這些測試個案會用怎樣的順序執行, 會描述在測試程序中.

或許你會覺得很神奇, 以前只聽過測試個案規格書之類的, 其他完全沒聽過. 這很正常, 在開發時, 很多人也是沒有做架構設計, 然後就直接開始寫他負責的元件, 然後對哪個元件, 簡單畫個示意圖就開工了. 開發部分會如此, 測試的部分也會如此.

圖 19-1 IEEE 829 標準中說明測試需要產出哪些文件

那你說這些測試文件有沒有用, 恩, 我會反問你說那些開發文件有沒有用. 其實重點不在於文件, 而是那些文件內容中所提到的那些項目, 你在做事的過程中會不會用到, 需不需要考量哪些項目? 如果會就是有幫助, 差別只是在於是否真的要把他們記錄到文件中, 如果要記錄, 要多少的詳細程度. 因此, 我先介紹他們是什麼, 你自己再自行判斷是否要記錄和使用.

測試設計規格書

說明要測什麼, 會用什麼方式去開立測試個案, 有什麼限制或是條件, 怎樣才算通過. 根據 IEEE 829 的規範, 其內容包含如下:

1. 測試設計規格書代碼
   通常會給每份文件一個代碼. 這裡只要不重複, 有意義的編號就可以.

2. 需要被測試的功能
   會說明這個文建會涵蓋哪些要測試的功能.
   通常會引用參照哪些需求文件或是設計文件

3. 測試方法的詳細說明
   說明會怎樣進行測試, 這邊會說明因為開發這樣設計, 所以我們需要這樣測試. 通常會提到受測系統的架構, 系統的運作流程, 介面, 或是資料庫設計等等.

也會說明是否有什麼限制, 例如沒有什麼硬體, 或者沒有直接驗證方式, 或是需要額外開發什麼程式才能驗證或測試.

說明會使用哪些測試方法, 黑箱白箱, 為什麼會選用這個方法.

4. 要執行的測試個案代碼
   根據這份文件, 會開立哪些測試個案出來

5. 功能通過/失敗條件
   每個功能通過/失敗的條件

以下是一個簡單的範例, 讓你知道大概會寫些什麼:

高鐵訂票系統

(1) 測試設計規格書代碼
THSC-V2-F001

(2) 需要被測試的功能
買票的功能, 測試的場景是客戶臨櫃時, 跟高鐵人員購買車票

(3) 測試方法的詳細說明
a. 會利用 Decision Table Testing 的方式, 列出重要排列組合的場景
b. 測試環境的結構如下
….
c. middleware API
我們會利用這些 API 去進行端到端測試
d. 資料庫結構
目前會有這些表格, 其欄位說明如下 ….

(4) 要執行的測試個案代碼
開立的測試個案包含: TC-F001-0012, TC-F001-0015, TC-F001-0016 ….

(5) 功能通過/失敗條件
需要驗證系統剩下票數購買前和購買後的變化
需要確認 debug log 中是有錯誤訊息

測試個案規格書

這分文件就比較容易了解, 因為大部分的人都會寫這份文件. 測試個案規格書在說明單一個測試個案會怎麼進行測試. 測試的場景是什麼, 步驟, 所需資料, 環境等等. 讓我們看看 IEEE 829 內說它包含什麼

1. 測試個案代碼

2. 要測試的功能或是場景

3. 輸入
   資料名稱/順序/資料數值/狀態/時間

4. 輸出
   資料名稱/順序/資料數值/狀態/時間

5. 環境
   硬體/軟體/其他

6. 特別的程序需求
   事先要執行步驟, 或是特殊的網路架構等等

7. 和其他測試個案的關聯
   是否有和其他測試個案有相依性, 是否先要先執行或是後執行.

我想這部分應該大家都很有經驗, 我就不特別舉例.

測試程序

這邊會描述某些測試個案會因某些目的, 一起組合起來執行. 這是因為測試個案可能會有很多個, 你不會每次都跑全部, 會根據某些特定的需求或目的, 選擇某些測試個案來執行.

1. 測試程序代碼

2. 目的
   這一堆測試個案是為了要測試什麼場景.或者是為了釐清某種狀況.

3. 特殊需求
   硬體/資料庫狀態/前置條件/所需技能

4. 程序的步驟
   這些測試個案要如何執行, 需要在什麼環境, 需要先設定什麼東西, 這些個案要以什麼順序執行, 測試完畢要收集什麼資訊, 要如何清除測試環境和資料 等等.

以下是一些簡單的範例, 讓你知道大概會寫些什麼:

(1). 測試程序代碼
TP-001

(2). 目的
為了確認受測系統是否可以開始進行大規模測試

(3). 特殊需求
需要有一個乾淨的測試環境 win 365

(4). 程序的步驟
會執行以下測試個案
安裝乾淨的測試環境 win 365
TC-003: 安裝受測程式
TC-008: 登入系統
TC-011: 登出系統
TC-003: 移除受測程式
還原測試環境

(1) 測試程序代碼
TP-002

(2) 目的
為了確認受測系統的主功能是否運作正常

(3) 特殊需求
需要有一個乾淨的測試環境 win 365

(4) 程序的步驟
會執行以下測試個案
安裝乾淨的測試環境 win 365
TC-003: 安裝受測程式
TC-004: 登入系統
TC-005: 主功能 1
TC-006: 主功能 2
TC-007: 主功能 3
TC-011: 登出系統
TC-003: 移除受測程式
還原測試環境

在描述測試個案時, 不是每次都寫到鉅細彌遺. 也不是每個團隊都有一樣的詳細程度. 這邊有幾種可能的詳細程度:

• 0: 沒有文件
• 1: 簡單敘述
• 2: 有簡單的執行步驟
• 3: 對每個步驟有詳細的操作說明
• 4: 有對應的自動化程式

哪什麼時候會新增或是更新測試個案呢? 以下是幾種場景:

• 為 新功能 新增測試個案
• 為 重要 bug 新增測試個案
• 某些 功能不需要 的時候
• 發現 重複或不正確 的測試個案

很多人會問到, 你會推薦用哪個測試個案管理的工具？這個問題很難回答, 因為每家公司有錢程度不同, 人數不同, 專案需求不同, 因此, 我先列出在國內比較常聽到的工具:

• 開源工具
BrowserStack
TestLink
• 商用產品
TestRail
qTest
PractiTest
• 百搭工具
Word
Excel
Confluence
xMind
• 微軟
Azure DevOps

基本上, 如果用工具, 在管理測試個案方面, 比較可以進行統計, 有些現成分析報表可以使用的. 另外, 在執行是可以方便挑選測試個案, 並且查看哪些執行通過, 哪些執行失敗. 但是, 在新增和維護的時候, 登打到這些系統是很花時間的, 我並沒有很想把時間花在打這些資訊到系統中, 而是希望多花時間在實際測試系統.