網上查找了大量關於狀態遷移法的知識，都沒有得到自己想要的內容，因此自己動手來記錄這個測試用例設計方法，首先我在mantis上篩選了一些常用的缺陷狀態，如下；
| 新建 | new | 測試人員新建一個缺陷記錄 |
| 已分派 | assigned | 將缺陷指派給對應的開發 |
| 已確認 | confirmed | 開發確認這是的確是缺陷，並且后續會處理 |
| 打回 | feedback | 開發認為這不是缺陷，打回給測試，不做修改 |
| 已打開但未處理 | open | 將缺陷置為打開狀態，開始修改 |
| 已解決但未驗證 | resolved | 缺陷已被開發修改，但沒有被測試 |
| 已解決並已驗證 | fixed | 缺陷已被開發修改，並且測試通過 |
| 重新打開 | reopen | 被開發修改過的缺陷，未通過測試驗證 |
| 延期 | suspended | 缺陷當前不做修改或無法修改，需要延期處理 |
| 已關閉 | closed | 缺陷已確認被修復，並沒有再復現，關閉 |
除了上述的狀態以外，還有acknowledged(公認)、unable to reproceduce(無法復現)、duplicate(重復問題)、not fixable(無法修復)、no change required(不是問題)、won't fix(不做修改)等等
既然狀態已經得到了，那么接下來就開始嘗試使用狀態遷移法來設計用例，
第一步：
先在表格中找出有關聯的狀態，並標記出來：行中表示上一個狀態，列中表示下一個狀態，歸納出的表格如下圖所示；
| 新建 | 已分派 | 已確認 | 打回 | 已打開但未處理 | 已解決但未驗證 | 已解決並已驗證 | 重新打開 | 延期 | 已關閉 | |
| 新建 | ||||||||||
| 已分派 | 1 | 1 | ||||||||
| 已確認 | 1 | |||||||||
| 打回 | 1 | |||||||||
| 已打開但未處理 | 1 | 1 | 1 | 1 | ||||||
| 已解決但未驗證 | 1 | |||||||||
| 已解決並已驗證 | 1 | |||||||||
| 重新打開 | 1 | |||||||||
| 延期 | 1 | |||||||||
| 已關閉 | 1 | 1 | 1 |
假設缺陷生命周期的起始狀態均為新建。
第二步：
繪制狀態轉換流程圖，其實這個步驟感覺可以省略，直接整理向下或者向右的樹形圖，如下；
| 新建 | 已分派 | 已確認 | 已打開但未處理 | |||
| 延期 | 已打開但未處理 | |||||
| 打回 | 已分派 | |||||
| 已關閉 | ||||||
| 已打開但未處理 | 已解決但未驗證 | 已解決並已驗證 | 重新打開 | 已打開但未處理 | ||
| 已關閉 | ||||||
| 已關閉 | ||||||
以上就是整理出的向右的狀態遷移樹形圖，每一個分支都是一個測試路徑，接下來我們就可以做，
第三步：
將第二步的樹形圖轉換成狀態路徑，如下：
- 新建->已分派->已確認->已打開但未處理
- 新建->已分派->已確認->延期->已打開但未處理
- 新建->已分派->打回->已分派
- 新建->已分派->打回->已關閉
- 新建->已分派->已打開但未處理->已解決但未驗證->已解決並已驗證->重新打開->已打開但未處理
- 新建->已分派->已打開但未處理->已解決但未驗證->已解決並已驗證->已關閉
- 新建->已關閉
從上面羅列的狀態路徑可以看出，有些路徑的最后的狀態並不缺陷實際的最終狀態，主要是因為這些路徑的后續狀態在其他狀態中已經體現。
第四步：
根據這些測試路徑設計具體的用例和數據。