轉念學 – 敏捷三叔公的學習之旅

這些年軟體開發大量引入 AI 產生程式碼後，很多團隊發現：AI 雖然能快速寫 code，但如果測試環節沒有跟上，整個系統很容易累積技術債、出現隱藏問題。OpenAI 內部用 AI 產出近百萬行程式碼的經驗顯示，關鍵不在 prompt，而在於打造一套完整的 Harness Engineering，讓 AI 能穩定跑完開發、測試、修復、驗證的循環。

在這個新時代，測試人員的專業遠遠不只寫 test case 或跑測試。你成為整個 AI 開發流程的設計者和守門人，需要把測試思維全面嵌入 harness 裡面，包括測試環境建置、系統測試（System Testing）、整合測試、E2E 測試等面向。

這篇文章用「台灣高鐵換票系統」當實際例子，詳細說明測試人員要加入哪些東西、怎麼設計、怎麼落地。全部都是實務上可以直接操作的做法。

1. 測試人員的新角色：不只是驗證，更是整個 Harness 的設計者

過去測試人員主要負責寫案例、執行測試、回報 bug。

現在 AI 自己會寫 code、改 code，測試人員的核心工作大幅擴展，包含：

• 定義明確的完成條件（Intent + Acceptance Criteria）
• 把測試知識轉成 AI 可讀的 repo 文件（Knowledge）
• 設計結構化失敗回饋（Observation）
• 建立測試環境與資料管理機制
• 設計並維護系統測試、整合測試、E2E 測試策略
• 建立防止系統腐化的長期品質循環（Entropy Control）

測試環境與系統測試正是測試人員最能發揮專業的地方，因為 AI 很難自己判斷「環境是否乾淨」「系統行為是否符合真實情境」。

2. Intent 階段：用 Acceptance Criteria 定義完成條件（包含測試環境與系統層級要求）

不好的任務描述：「幫我修票價差額計算錯誤」

建議的完整格式：

任務：修正高鐵換票功能中「票價差額計算錯誤」

Acceptance Criteria（AC）：

• RefundCalculator.test.ts 全部 18 個測試通過
• 票價差額必須先加總後再四捨五入，不可逐筆計算
• 最終金額以整數呈現
• 不得影響既有訂票流程（BookingFlow E2E 測試 100% 通過）
• 不可修改 API schema 與 UI 行為
• 測試環境要求：必須在 Staging 環境（含真實資料庫與外部金流 mock）下驗證通過
• 系統測試要求：高鐵全流程 System Test（查詢 → 訂票 → 付款 → 換票 → 退款）無 regression

邊界案例：

• 退票金額為 0 元
• 跨區間負值差額
• 四捨五入邊緣值（0.5、0.499）

建議做法：建立 AC-Template.md，把測試環境、系統測試、E2E 要求都列入模板，讓 AI 一開始就知道要考慮整體環境與系統行為。

3. Knowledge 階段：把測試環境與系統測試知識寫進 repo

AI 看不到的東西等於不存在。測試人員要把以下文件維護好：

• QUALITY.md —— 整體品質與環境標準
• TEST-PATTERNS.md —— 測試模式與反模式
• TEST-ENVIRONMENT.md —— 新增，專門管理測試環境
• SYSTEM-TEST-CATALOG.md —— 系統層級測試案例與情境

TEST-ENVIRONMENT.md 實際範例：

# 測試環境建置規則
- 所有測試必須使用乾淨的 Docker Compose 環境（包含 PostgreSQL + Redis + Mock Payment Service）
- 金流、票務系統 API 一律使用 mock server（WireMock 或 MSW）
- 測試資料使用專用 seed script，每次測試前自動 reset
- Staging 環境與 Production 環境配置差異必須記錄在 env-diff.md
# 禁止事項
- 測試中不可直接呼叫真實外部 API
- 不可使用共享測試資料庫

SYSTEM-TEST-CATALOG.md 實際範例：

## 高鐵換票全流程 System Test
情境 1：已付款訂單換日期 → 計算差額 → 扣款/退款 → 確認新票券狀態
前置條件：使用 Staging 環境 + 指定 seed data
驗證重點：
- 票價計算正確
- 庫存即時更新
- 通知系統（Email/SMS）正確觸發
- 無資料不一致情況

這些文件讓 AI 在修改時自動參考環境與系統層級的要求。

4. Observation 階段：結構化回饋要包含環境與系統資訊

除了程式錯誤，還要讓 AI 看到環境相關失敗：

{
  "test_suite": "System_Refund_Flow",
  "test_name": "should_handle_cross_station_refund",
  "failure_type": "system_inconsistency",
  "expected": "票券狀態更新為已退款",
  "actual": "票券狀態仍為已付款",
  "environment": "Staging_Docker",
  "suspected_files": ["RefundService.ts", "TicketRepository.ts"],
  "context": "資料庫 transaction 未正確 commit",
  "related_spec": "TEST-ENVIRONMENT.md#database-reset"
}

落地方式：修改 Playwright / Cypress / Testcontainers 的 reporter，加上環境資訊與系統測試 log。

5. Validation 階段：多層驗證必須包含系統測試

AI 修完後，強制執行以下層級：

1. 單元測試（相關模組）
2. 整合測試（含 mock 外部服務）
3. 系統測試與 E2E（完整高鐵流程，在 Staging-like 環境執行）
4. 跨模組 regression + 基本效能/相容性檢查

推薦 CI 指令：

pnpm test:unit --filter refund
pnpm test:integration
pnpm test:system --grep "RefundFlow|BookingFlow"
pnpm test:e2e --env=staging
check-environment-cleanup

測試人員要負責維護這些測試環境的 Docker Compose、seed data、mock server，讓每次驗證都能在一致、可重現的環境下執行。

6. Learning 與 Entropy Control：長期維護測試環境與系統測試

AI 長期運行容易讓測試環境變髒、系統測試案例過時。

測試人員每週應執行：

• 檢查測試環境是否能乾淨啟動與重置
• 審核系統測試覆蓋率與真實使用者路徑
• 更新 TEST-ENVIRONMENT.md 與 SYSTEM-TEST-CATALOG.md
• 清理過時 mock、過期 seed data
• 監控 flaky test 與環境不穩定問題

這條第二循環能確保 AI 修改不會破壞整體系統穩定性。

測試人員現在就能開始做的五件事

1. 建立 AC-Template.md，加入測試環境與系統測試要求
2. 新增 TEST-ENVIRONMENT.md 與 SYSTEM-TEST-CATALOG.md
3. 修改測試 reporter 輸出包含環境與系統資訊的結構化 JSON
4. 建置或優化 Docker-based 測試環境與 mock 服務
5. 在 CI/CD 加入系統測試與環境清理的強制步驟

在 AI Coding 時代，測試人員的專業價值反而更高。你不只驗證單一功能，還要確保測試環境一致、系統行為正確、整體架構不會劣化。這些正是 AI 目前最難自動處理的部分。

把測試環境與系統測試做好，AI 才能真正成為可靠的開發夥伴，而不是隱藏風險的來源。

你們團隊在 AI 輔助開發時，是怎麼處理測試環境和系統測試的？歡迎留言分享，一起交流實務經驗。