系列說明 >> 本系列大部分 PR 來自私人或公司專案，部分程式碼、環境設定與實作細節不便公開。
我只能保證文中提到的 PR 與問題皆為真實案例，但會經過必要的匿名化與內容調整。
本系列主要分享問題如何被發現、背後的思考方式，以及解法如何形成，不會深入討論完整實作與部署細節，敬請見諒。
Base Repo： testpilot-core
Change Ref： wifi_llapi PR #130－feat(audit): P1 workbook 對接
Issue： Audit 已經能找到正確的 Case，但 Workbook 的欄位與 Verdict 語意仍靠操作者記憶；大量根本不需要 Live Run 的 Row，仍會照流程準備環境、Upgrade FW、占用 DUT／STA。
Root Cause： Workbook 被當成資料來源，卻沒有把「欄位代表什麼」以及「哪些 Verdict 真的需要 Runtime 驗證」變成明確規則。
Solution： 加入 --profile base0410 固化欄位、統一歷史 Verdict 詞彙，並在 Live Run 前先分流 Not Supported／Skip／To Be Tested；Workbook Index 同時改成 bounded scan。
Evidence： Base0410 約可省下 54% Live Runs；Workbook 掃描約由 17 秒降到 0.22 秒。Audit Tests 最終 235 passed。
上一篇，我們總算把 Audit Pipeline 從舊 Repo Layout 拉回現在真正的 Case 路徑。
至少 TestPilot 不會再拿著：
plugins/wifi_llapi/cases/
去找早就搬到：
wifi_llapi/cases/
的檔案。
路終於接回來了。
那接下來應該可以開始 Audit 了吧？
理論上。
結果真正把 Workbook 丟進去後，第一個卡住我的不是 DUT，也不是 Serial。
是 Excel。
Agent 看著 Workbook。
「哪一欄是 API？」
「C。」
「5G、6G、2.4G 的結果？」
「R、S、T。」
老Go在旁邊問：
「所以每次跑 Automation 前，都要先來問你？」
「……目前是。」
好哦！！
這樣應該也算 Human in the loop 吧？
這份 Workbook 本來就是工程文件，不是為 Parser 設計的。
裡面同時留著不同世代的 Result Columns，Header 也不是工具原本期待的簡單名稱。
人類打開 Excel，大概幾秒就能理解：
Object → A
API → C
Test Steps → G
Command Output → H
5G Result → R
6G Result → S
2.4G Result → T
問題是，這些對應以前沒有真正存在系統裡。
每次跑 Audit，都可能再靠操作者重新告訴工具一次。
這次加上的：
--profile base0410
其實沒有什麼高深技術。
它只是把這份 Workbook 的 Sheet 與七個欄位定義正式記下來。
如果真的有特殊情況，仍然可以用 --col-* 覆寫；正常情況則不用每次重新背 A、C、G、H、R、S、T。
而且解析完成後，真正使用的設定會跟著 RID 寫進 Manifest。
這一點反而比 Profile 本身重要。
未來 Profile 就算改了，舊 RID 重跑時還是知道：
當時到底是用哪一組 Workbook 定義跑的。
上一篇固定的是 Case Path。
這一篇固定的，則是 Workbook 的讀法。
都是同一件事：
不要再把 Environment 藏在人腦裡。
欄位對好後，pass12 終於能正常讀 Workbook。
歷史 Workbook 裡還有一些 Fail／Failed、Not Support／Not Supported 之類的詞彙差異。
這種就先 Normalize 掉。
真正讓我停下來的是另外一件事。
Workbook 裡很多 Row 根本不是：
Pass
Fail
而是：
Not Supported
Skip
To Be Tested
這幾個字其實已經把事情講完了。
但原本的流程還是：
讀 Workbook
↓
準備 Test Environment
↓
Upgrade FW / 執行 Live Run
↓
操作 DUT / STA
↓
取得 Runtime Result
↓
再跟 Workbook 比
也就是說，一條 Workbook 已經寫著：
Not Supported
的 Case，我們還是會先照正常測試流程準備環境、占住設備、跑一輪，最後才發現：
「喔，這題原來不用測。」
……
這流程非常嚴謹。
嚴謹到連「不用做」都要先做一次才能確認。
老Go看著我。
「你們 Testbed 很閒嗎？」
沒有。
一點都不閒。
if 的所以這次真正有感的改變，是把判斷搬到 Live Run 前面。
流程從：
Workbook
→ Upgrade FW / Live Run
→ 再判斷結果該怎麼處理
改成：
Workbook Row
↓
Pre-classification
↓
Not Supported / Skip / To Be Tested
→ 直接分流
Pass / Fail
→ 進 Live Run
這些提前分流的 Row，不代表已經 Audit PASS。
也不會因此直接進 apply。
它只是在告訴 TestPilot：
這個問題不需要先 Upgrade FW，再拿 Runtime Result 回來回答。
以當時 Base0410 的資料分布來看，大約有 54% 的 Row 可以在進入 Live Run 前先離開。
看到這個數字，心情當然很好。
少一半。
少一半環境準備。
少一半 DUT／STA 使用時間。
Agent 也可以少等一半。
Perfect。
嗯。
這系列寫到現在，看到 Perfect 大概就知道準備出事了。
第一版 Pre-classification 很直覺：
看 Workbook 三個 Band 的 Result。
如果它屬於 Not Supported、Skip、To Be Tested 這種 Runtime 無法 Confirm 的類型，就先分流。
問題是：
Case 不一定測三個 Band。
例如某條 Case 只有：
bands:
- 5g
但 Workbook 仍然保留完整三欄：
5G : Pass
6G : Pass
2.4G : Not Supported
如果分類器三欄全部一起看，就可能被那個其實跟這條 Case 無關的 2.4G : Not Supported 帶走。
最後變成：
5G 明明需要 Live Run
↓
看到 out-of-scope 的 Not Supported
↓
提前分流
↓
該跑的測試直接消失
速度真的變快了。
畢竟最快的 Test，就是不要 Test。
老Go看了一眼。
「Optimization 成功。」
「閉嘴。」
所以這次真正重要的不是「省 54%」。
而是補上另一個條件：
先看這條 Case 真正負責哪些 Band。
Pre-classification 只處理 Case Scope 內的結果。
而且規則改得更保守：
只要有效範圍內還存在
Pass或Fail，就不能跳過 Live Run。
只有全部有效結果都屬於 Not Supported／Skip／To Be Tested，才可以提前分流。
後續 Adversarial Review 又繼續往這個邊界戳。
如果 bands 本身格式錯了呢？
例如出現未知 Band，或者格式根本不符合預期。
以前有些情況還可能退回預設行為繼續跑。
現在直接：
block
不知道，就是不知道。
不要因為想省一次 Upgrade FW 和 Live Run，就順便把 Correctness 也省掉。
後來又抓到 Mixed Row 的情境：Case 沒有明確宣告 Band Scope，但 Workbook 同時存在 Pass 與 Not Supported。
最後規則仍然一樣：
只要還有任何可以被 Runtime 驗證的 Pass／Fail，就跑。
54% 是可以省掉的成本。
不是 KPI。
Live Run 的問題處理完後，還有另一個比較單純的浪費。
這份 Workbook 真正的資料，大概只到七百多列。
Excel 的 Used Range：
573,715 rows
……
我不知道這份 Excel 過去經歷了什麼。
也不打算追究。
但舊的 build_index() 很相信它。
Excel 說五十七萬列？
那就掃五十七萬列。
每次大概：
17 sec
後來改成 Streaming Scan。
一路往下讀，只要連續遇到 200 個空 Row 就停止。
實際資料內部最大的空洞遠低於這個距離，所以仍然留著足夠的 Safety Margin。
實檔 Smoke 最後大概變成：
0.22 sec
從十幾秒變成零點幾秒當然很舒服。
但跟前面的 54% 相比，這反而只是小菜。
真正昂貴的是：
準備 Environment
Upgrade FW
占 DUT
占 STA
占 Serial
占 Agent
跑完以後
才發現這題原本就不用測
PR #130 最後留下的 Evidence，大致是：
--profile base0410
→ 可以直接初始化真實 Workbook
Workbook scan
→ 約 17s → 0.22s
Pre-classification
→ Base0410 約少 54% Live Runs
Band Scope / malformed bands / mixed row
→ 經 Adversarial Review 補齊
Audit Tests
→ 235 passed
不過 54% 這個數字還是要講清楚。
它不是：
Audit 整體快了 54%。
它代表的是：
約 54% 的 Workbook Rows，可以在 Upgrade FW、啟動 Live Run 之前，就先確認「這不是 Runtime 應該回答的問題」。
這差很多。
我們不是讓 DUT 跑得更快。
只是少叫它處理一些本來就不需要它回答的問題。
到這裡，剩下來的 Case 才真的值得花 DUT、STA 與人的時間去查。
很好。
那接下來應該只剩：
Agent 修得對不對？
了吧？
我看了一眼 verify-edit：
--yaml <before>
--proposed <after>
嗯？
等一下。
before 是誰提供的？
如果 Agent 拿另外一份 YAML 當成 Before 呢？
就算 Verify 時真的是正確版本，Verify 完之後正式 Case 又被別人改掉呢？
上一篇，我們發現 Audit 拿著舊地圖。
這一篇，我們先把根本不需要 Upgrade FW 的 Case 篩掉。
下一篇則更直接。
你說你驗證過這份 YAML。
但最後被套用的，真的是同一份嗎？
Have a nice day.
iThome鐵人賽
看影片追技術