Day23_用 User Story 產生 Test Case，再把案例變成自動化測試

前言

Day22 完成前後端串接後，程式已經可以建置，既有的自動化測試也能通過。不過，這些結果只代表「目前寫進測試的情境沒有失敗」，還不能回答另一個問題：User Story 裡的規則，真的都有被測到嗎？

可以把 User Story 想成屋主提出的需求，例如「浴室要有熱水」；Test Case 則是驗收清單，會繼續問水溫多少才算正常、熱水器沒啟動時要顯示什麼，以及兩個人同時用水會不會出問題。需求告訴我們要蓋什麼，測試案例負責把「怎樣才算完成」寫得更具體。

這一篇會先請 Codex 從規格與程式整理 Markdown 測試案例，再把確認過的案例分批轉成自動化測試。這兩個階段要分開：先寫測試案例，不等於程式已經測過；產生測試程式碼，也不等於測試已經通過。

先分清楚三種產物

剛接觸測試時，很容易把「案例、程式碼、執行結果」混在一起。它們其實是三份不同的證據。

因此，案例標成 Ready，只表示它的前置條件、操作步驟與預期結果已經寫清楚，可以開始測試；只有案例而沒有執行紀錄時，不能寫成「已通過」。同樣地，Skipped 是略過，不是通過。

安裝產生測試案例的 Skill

這次使用 stellarlinkco/myclaude repository 裡的 test-cases Skill。Skill 可以先想成一份交給 Agent 的工作手冊：它會提醒 Agent 從需求找出正常流程、邊界、錯誤情境與狀態轉換，再用固定格式整理成 Markdown。

在終端機執行：

npx skills add https://github.com/stellarlinkco/myclaude --skill test-cases

安裝第三方 Skill 前，仍要先看來源 repository 與 SKILL.md。Skill 會影響 Agent 的工作方式，不該因為一行安裝指令很方便，就跳過內容與權限檢查。

這個 test-cases Skill 的工作是「根據需求產生測試案例文件」。它不會自動替我們建立 NUnit、Vitest 或 Playwright 測試，也不會執行 SQL Server。後面的測試程式與實際驗證，仍要另外安排。

第一步：先產生 Markdown 測試案例

ProjectManagementWeb 的規格散在 User Story、Flowchart、Schema、API 契約與 UI Mock 裡，前後端也已經有實際程式碼。如果只讀其中一份，Agent 很可能寫出一張看似完整、實際上已經過期的驗收清單。

我先使用下面的 Prompt。路徑中的 User 要換成自己電腦上的實際帳號名稱：

請使用 test-cases Skill。

請重新讀取以下三個專案，不沿用先前對話記憶：

Spec：
/Users/User/Desktop/ProjectManagementWeb/ProjectManagementWeb_Spec

Backend：
/Users/User/Desktop/ProjectManagementWeb/ProjectManagementWeb_BackEnd

Frontend：
/Users/User/Desktop/ProjectManagementWeb/ProjectManagementWeb_FrontEnd

請根據 User Story、Flowchart、Schema、API 契約、UI 規格、
EF Core migrations 與目前前後端程式碼，產生 Markdown 測試案例文件：

/Users/User/Desktop/ProjectManagementWeb/ProjectManagementWeb_Spec/TestCases/ProjectManagementWeb-TestCases.md

每個案例至少包含：
1. 唯一 Test Case ID
2. 類型與優先級
3. 測試層級：Unit、API、SQL、UI、E2E 或 Service
4. 對應需求
5. 前置條件
6. 測試步驟
7. 預期結果
8. 資料後置狀態
9. 現有自動化覆蓋
10. 案例狀態：Ready 或 Planned

請先列出規格衝突與缺口，不要自行猜測業務規則。
本階段只產生或更新 Markdown，不要修改前後端程式，也不要產生測試程式碼。
完成後請回報案例總數、各類型數量、衝突與缺口，以及實際修改的檔案。

最後一段界線很重要。這一輪的目標是先得到可審查的測試清單，如果 Agent 一邊補規格、一邊改程式，出現差異時就很難知道它究竟依據哪一份規則。

畫面左側保留了第一次整理時的 94 個案例，右側則是後續解決缺口、補齊覆蓋後的文件，因此數量已增加到 118。這也提醒我們，測試案例不是產生一次就永遠不變；規格與程式改動後，案例也要一起更新。

第二步：人工檢查測試案例

Agent 很擅長把資料整理成表格，但它也可能把規格中的模糊處自行補成答案。開始寫測試程式前，我會先檢查下面幾件事：

1. API 路徑、Request、Response、HTTP status 與錯誤 code 是否以目前實作為準。
2. 每個 Test Case ID 是否唯一，也能追溯到 User Story 或契約。
3. 權限案例是否同時涵蓋 401、403 與資源不存在的情況。
4. SQL transaction、Foreign Key、UNIQUE constraint 與 rowversion 案例，是否要求使用真正的 SQL Server。
5. 標成 API + E2E 的案例，是否需要拆成不同層級的測試程式。
6. 尚未實作或仍有契約缺口的功能，是否標成 Planned，而不是假裝已經可以測。
7. 文件中是否混入密碼、JWT、Token、Cookie 或其他敏感資料。

如果找到衝突，先停下來確認。例如「Project Owner 必須具備什麼資格」屬於業務規則；Agent 可以指出不同文件寫得不一樣，卻不該擅自替專案選一邊。

第三步：不要一次把 118 個案例全部丟進去

測試案例很多時，我不會用一句「全部自動化」就讓 Agent 長時間執行。一次改太多檔案，失敗後很難定位，也容易把略過或沒有執行的項目藏在漂亮的總結裡。

比較穩妥的做法，是先挑一批 P0 案例，例如註冊、登入、權限與 Token，再明確寫出輸入、輸出和停止條件。第一批確認做法正確後，再處理下一批。

請根據下列測試案例，先處理第一批 P0 Auth／RBAC 自動化測試：

/Users/User/Desktop/ProjectManagementWeb/ProjectManagementWeb_Spec/TestCases/ProjectManagementWeb-TestCases.md

工作方式：
1. 先列出本批包含的 Test Case ID、預計新增或修改的測試檔，以及執行指令。
2. 每個測試在名稱或註解中保留對應的 Test Case ID，讓案例與程式可以互相追查。
3. 先搜尋既有測試；相同行為已被覆蓋時，擴充原測試，不要重複建立另一份。
4. 如果測試案例、規格與目前程式互相矛盾，立即停止並列出證據，不要自行修改業務規則。
5. SQL constraint、transaction、concurrency 相關案例必須使用實際 SQL Server，不可用 EF Core InMemory 取代。
6. 依專案既有測試框架執行測試。若環境中有適用的測試 Skill，可以使用，但要回報實際使用的 Skill。
7. 完成後逐字回報執行指令、Passed、Failed、Skipped 與未執行數量。Skipped 不可算成 Passed。
8. 更新 Markdown 的自動化覆蓋與最後執行時間，但只有真正執行成功的案例才能標成已實測通過。
9. 不要 commit、push，也不要處理本批清單以外的案例。

請先提出本批計畫，等我確認後再修改程式碼。

這份 Prompt 沒有要求 Agent 一口氣跑到結束，而是先交出小批次計畫。人可以先確認案例範圍、測試層級與執行環境，再讓它動手。

規格打架時，停下來是正常的

我第一次請 Codex 依案例產生測試時，它沒有立刻修改程式，而是先找到兩組已定案、卻尚未同步的規格衝突。這不是失敗，反而是好現象。測試像拿尺量成品，如果兩把尺的刻度不同，應該先校正尺，而不是挑一把比較順眼的繼續量。

確認規則後，再回到同一個批次繼續。每完成一批都要查看 Git diff，確認只改到預期的測試、必要實作與測試案例文件；接著重新執行該批測試，最後再跑完整回歸。

怎麼閱讀最後的測試結果？

這次 ProjectManagementWeb 最後留下的全量回歸紀錄包括：

這些數字不能直接相加後，解讀成「總共有 256 個 Test Case」。一個 Markdown 案例可能需要 Unit、API 和 E2E 三個測試才能證明；一支自動化測試也可能同時覆蓋數個相近案例。真正的對照方式，是用 Test Case ID 與覆蓋矩陣查看每個需求由哪些測試負責。

同樣要留意測試環境。Moq 建立的 Repository 替身可以檢查 Service 如何呼叫介面，卻不能證明 SQL Server 的 Foreign Key 或 transaction 真的有效；Playwright 可以操作瀏覽器，卻不一定會連到真實 SMTP。報告裡若寫著「SMTP 未納入自動化測試」，這一項就仍然是限制，不能因為其他測試全綠而一起算成完成。

自動化測試全綠，為什麼還要手動測試？

自動化測試很像一群照表操課的檢查員。它們跑得快，也不會因為重複工作而分心，但只會檢查我們事先寫進去的條件。

按鈕放在很難找到的位置、下拉選單不方便搜尋、錯誤訊息讓使用者看不懂，這些問題未必會讓 Unit Test 或 API Test 失敗。就算 Playwright 找得到按鈕，也不代表第一次使用系統的人知道為什麼要按它。

所以，這一篇完成的是「規格到自動化測試」的追蹤鏈。下一篇會真的啟動資料庫、後端與前端，從使用者角度操作畫面。自動化測試負責反覆守住已知規則，手動測試則去找那些我們還沒想到、也還沒寫進案例的問題。

小結

User Story 不會自動變成完整測試。要先把需求拆成有編號、可執行、能核對結果的 Test Case，再經過人工確認，最後分批寫成測試程式並實際執行。

這套流程真正有用的地方，是每一層都找得到上一層：需求可以追到 Test Case，Test Case 可以追到測試程式，測試程式又有時間與結果可查。之後出現 Change Request 時，就比較容易知道哪些規格、程式與測試要一起調整，也比較不會發生「改了 A，B 卻悄悄壞掉」的情況。

參考資料

• stellarlinkco/myclaude：專案說明
• stellarlinkco/myclaude：test-cases Skill
• Skills CLI：安裝指令說明