QA 自動化不是寫更多測試，是建閉環 — 從票務到只重跑失敗

很多團隊衡量自動化成熟度的方式是「我們寫了幾個測試」。這個數字幾乎沒有意義。

真正決定價值的是跑完之後發生什麼：測試結果透明嗎？失敗會不會自己重跑？季末講得出成效數字嗎？票務進來會不會自動變成測試？如果這些都是「人工」或「不知道」，那你寫再多測試，都只是一堆黑箱。

自動化的天花板不在「寫得多」，在「有沒有形成閉環」。這篇是一條跑真交易所（帳戶／出入金／訂單簿／餘額，錯了會出事）的完整閉環怎麼組起來的。

四層各司其職：AI 引擎產碼、BDD 場景庫是唯一真相源、Robot 執行層跑真環境、儀表板收指標並反過來觸發重跑。重點不是任何單層多聰明，是四層串成一條會自己轉的環。

閉環的地基，是把測試案例從無版控的 Excel（動輒幾 MB、沒人敢動）搬進 git。搬進來之後做一件關鍵的事——WHAT 跟 HOW 分兩層：

• 場景庫存「測什麼」：意圖、預期、user level 矩陣，用業務語言寫成 Given/When/Then。QA/PM 看得懂、能 review。
• Robot 層存「怎麼測」：自動化程式碼。
• 兩層只靠測試案例的名字對映，各自獨立演進。

這樣 QA/PM 不用讀一行自動化 code 就能 review 測試意圖，而自動化實作可以重構、可以換 driver，完全不動到 spec。這 12,293 個場景（App + Web 合計、近百個模組）就是這樣變成可 diff、可 MR review、可 branch-per-ticket 的。

level 參數化是另一個放大器：一個「人類場景」用 level 矩陣展開成 N 個 Robot 測試（例如同一個提領流程，對 L0/L1/L2/未綁銀行各有不同預期）。這就是為什麼「12k 場景」對映到的自動化面比 12k 大得多。

閉環的入口是票務。一張功能票有驗收條件（AC）和對應的 MR，這些就是產測試的原料：

票（AC + MR） → AI 產 Python 測試骨架 + harness → 寫進測試分支 → merge

單元測試要行級細節、整合測試只要邊界，所以餵 context 時主票給完整 diff、聚合子票只給檔名（省約 95% token）。產出的不是「能跑就好」的碼，而是符合團隊慣例的碼——因為慣例本身被寫成了機器可檢查的規範（見下一節）。

跑真交易所最容易犯的錯，是把費率、提領上下限、上架幣種寫死在測試裡。這些東西天天在變，寫死的測試明天就是紅的（而且是假紅）。

正解：對平台自己的真相源驗證。每次跑之前先抓一份即時的交易所 metadata 快照（幣別確認數、提領上下限、維護狀態、下市對、VIP 費率……），在 runtime 導出預期值。

測試斷言的不是「手續費應該是 0.1%」，而是「手續費應該等於平台此刻宣告的值」。真相源變了，測試自動跟上，不用改一行 code。

夜跑 App 測試最惱人的是 flaky——早上來看一片紅，重跑又全綠。多數 flaky 的根因是「還沒真的 ready 就開始測」。

以 Android 冷開機為例，別用盲目的 sleep 30，改用三訊號就緒閘門：

三個訊號都過才開跑。搭配：殺乾淨舊的 emulator / session（別讓上一輪殘留污染）、調冷開參數（不載入 snapshot、指定 GPU 模式、加大 partition 防 APK 累積爆磁碟）。這樣就能把「flaky 夜跑」變成「確定性夜跑」。

最後一段，也是「閉環」真正閉起來的地方：

• 完整跑一輪，結果寫進 Sheet。
• 儀表板讀失敗標記，過通過率閘門（例如 >85%）才觸發重跑——用 <tag> 對 Sheet，不是用 test name（名字會改、tag 穩定）。
• CI 只重跑失敗的、再用 rebot 合併，不重跑全套。
• 結果回填 Sheet → 儀表板消費 → Slack 通知。

按 user level 分組平行跑、只重跑失敗、合併——這幾步讓「一個 flaky 失敗」不用賠掉整輪的時間。

慣例即程式碼：AI codegen 需要一個「機器可檢查的目標契約」。把團隊慣例（keyword 命名、xpath 大小寫、「≥2 個斷言要用 continue-on-failure」等）寫成幾百行規範，再配一個 linter skill 對分支 diff 報 🔴🟡🟢——這就是 AI 產碼的驗收閘門。沒有這層，AI 產的碼會慢慢腐化成各寫各的。

誠實計量（管理層最在意的一條）：

• 自動化數量兩來源對帳——從執行結果 Sheet 讀，再用季末 commit 快照數（數 Robot 的 *** Test Cases ***、JS 的 test()）交叉驗，對得上才報。
• AI 測試輔助 = 按規格手刻加速 + 人把關，絕不寫成「全自動、不耗人力」。取材分界也要明確：哪些算「QA 用 AI」、哪些屬另一個專案，不能混報。

浮誇一次，就賠掉整個儀表板的公信力。閉環的最後一塊，是讓數字誠實到主管敢拿去對 keynote。

自動化的價值不在「寫了幾個測試」，在「跑完之後這條路會不會自己轉」——從票務進來、產碼、跑真環境、只重跑失敗、回流儀表板。你建的不是測試，是一條會自我修復的閉環。