軟體測試設計(test design) 是一個描述測試如何被進行的過程, 你需要對受測試軟體進行分析, 了解它的需求, 才會知道要怎麼設計. 通常會包含以下資訊：

• 找出測試場景, 測試個案, 和測試資料
• 執行幾次, 執行的順序

為了進一步說明測試設計在做什麼, 我用下表來解釋.

我想大家應該都知道開發在做什麼. 開發在分析階段, 需要了解系統的需求是什麼, 會用哪些畫面來呈現. 在這個過程中會處理什麼資料.

到了開發的設計階段, 就會開始思考如何設計, 來完成分析時所提出的需求. 會拆解成哪些元件, 這些元件之間會如何互動, 等等.

那測試呢? 其實也是類似的狀況. 在分析階段, 它也是要了解要測什麼, 測試的功能會怎麼動, 哪些東西是要測試的, 哪些東西並沒有在這次的測試範圍內. 例如: 高鐵訂票系統, 需要測試的範圍有高鐵票的購買. 但是這次的測試範圍並沒有包含優惠票的處理, 只有一般高鐵票.

等到設計階段, 要思考如何進行測試, 因此要列出實際要測試的場景, 執行的步驟, 要如何確認測試是否通過, 哪些要先測試等等. 例如高鐵票的購買, 我們需要測試買購買 10 張一般票, 以及購買 10 張來回票, 10 張票但是目前系統只有5張對號座. 等等, 把要測試的場景詳細列出來.

所以從上面的整理你可以知道, 開發有分析和設計階段, 在測試的部分, 也是會有分析和設計階段.都是要列 what to do (分析) 和 how to do (設計).

哪我們要如何來描述如何進行測試呢? 這邊可以有兩種拆解的方式: (1) 從功能拆解 (2) 從架構拆解

1. 從功能拆解

一開始你收到的, 就是一堆功能. 可以先從功能的分類開始, 把他們分成幾堆接近的群組. 或者是每個功能就是一個群組. 前者可能是一堆有關聯的功能, 他們可能會交互使用. 像是 用戶管理群組, 它可能包含: 新增用戶, 編輯用戶資料, 和刪除用戶等三個功能.

接著拆解出要測試的場景. 例如: 正常的場景, 異常的場景, 支援不同語系, day night saving 等等不同.

然後我們可以對每個場景在展開測試個案出來. 例如在新增用戶的正常場景中, 你可以有: 新增一個用戶, 同時新增 3 個用戶, 多人同時一起新增用戶等等.

圖 18-1 從功能拆解來設計測試

2. 從架構拆解

另一個角度就是從架構出發. 有些系統是沒有 UI, 這時候便很容易從架構拆解. 或者他可能是 refactoring, 或者他是偏向 unit testing, integration 層級的測試, 也有些可能是系統測試的東西. 這些都有可能會利用架構來分出群組.

如下圖所示, 某個功能下, 你會列出幾個可能的模組的群組. 或者你可能是非功能的群組, 像是易用性, 安全, 或者是效能等議題.

這些群組列出來後, 有些狀況可能還會拆解出子群組. 像是 unit test 就會再拆 class 群組出來. 或者是某些場景這些 class 之間的互動. 或者 security 中要測試的場景太多, 會再根據優先級分類. 例如: Vulnerability Scan, Penetration Test, Rootkit 類別, 這時候不是每個都一樣重要, 你或許會分優先級來測試.

圖 18-2 從架構拆解來設計測試

當你在開立測試個案時, 你會把它放到某個, 可能測試個案管理工具, 也可能只是放到檔案總管內, 或是雲端硬碟中. 但是不管是什麼, 你不太可能一字攤開, 整個攤平放在一起. 大多狀況你會需要分群組. 就算你的測試個案不多, 沒有超過 100 個, 你也需要分類來存放, 這樣將來比較好尋找.

那你要怎樣分群組呢? 前面拆解的方法, 就給你最好的參考. 通常我們都會根據前面拆解的思維, 在使用的工具或是檔案總管上, 建立出相對應的 folder.

如下圖所示, 通常會有左邊紅色框框中的區域, 讓你來分類你的測試個案. 這時候你就可以依樣畫葫蘆來切割.

圖 18-3 測試個案的存放結構

接下來我們來簡單看一下測試個案的流程. 如下圖所示, 可以分成以下步驟:

• 和利害關係人合作
這時候需要和相關的利害關係人討論. 像是請客戶或 PM 解釋一下測試的目的, 了解特別需要注意的地方, 以及期待要的結果是什麼.

接著可以和開發人員一起快速對齊一下, 他大致要怎麼設計和開發, 架構會如何, 他自己會做什麼測試. 以及你對測試得部分, 你希望他們提供什麼幫助, 像是什麼測試用的 API, 有什麼 debug 資訊可以幫忙產生的, 或者驗證的機制會怎麼設計等等.

• 規劃優先級
這邊會先列出要測試的功能, 這時候應該是初步規劃, 會先參考測試計畫中的資訊. 然後針對每個要測試的項目, 規劃出高層次的測試場景, 並且排出優先順序, 這裡是需要和開發人員, PM 有共識. 避免做錯方向

• 系統化開立個案
接下來就是測試人員的事, 會思考要用哪種方式來開立測試個案, 黑箱或是白箱? 如果是黑箱, 是要用哪一種比較合適? 決定後, 就開始開立測試個案.

• 使用工具
這個過程會使用到一些工具, 至少你需要將測試個案放到團隊所使用的測試個案管理工具. 並且你也會用一些測試資料產生工具, 去建置相關的資料. 現在 AI 很紅, 也會利用 ChatGPT 之類, 看它能夠提供什麼建議.

• 檢視和更新個案
當測試個案開立完畢後, 接著就會請相關利害關係人一起檢視. 看看是否有遺漏的地方, 或者是對受測系統有所誤解.

圖 18-4 測試個案的處理流程

在進行測試個案的設計時, 我們需要的輸入資料和要產生的結果如下:

• 輸入
需求規格
測試計畫
測試人員：哪些人可以參與測試個案的設計
• 輸出
測試個案
檢視結果：把每次檢視結果保留下來, 可以反思是否每次都有進步. 或者是哪些常常犯錯, 可以放到檢查清單或是日後加強培訓.
測試個案和需求的對應關係：用來確認我們是否對所有需求都有涵蓋到, 涵蓋的程度如何.

在系統化開立測試個案那個步驟中, 我們可以使用以下作法. 這些作法大多在之前的章節有介紹過. 其中的作法還有很多, 但是因為篇幅的關係, 以及不想讓大家打瞌睡, 所以只列出部分讓大家知道.

圖 18-5 可能會使用的系統化開立測試個案的作法