改一行程式，該重跑哪些測試？迴歸選測的工程方法

週五下午改了一行程式。測試主管面前兩個選項：三百多條測試全部重跑（跑到週一早上），或憑經驗挑「應該有影響的」跑（漏掉的那一條，三個月後在客戶那裡爆）。兩個選項都是輸——這題的正解是第三個選項：讓系統算出該跑哪些。

為什麼「憑感覺挑」註定會漏

人挑測試依賴的是「這個模組我熟」的心智模型，但變更的影響傳播走的是真實的依賴關係：共用的全域狀態、間接呼叫、編譯期組態、標定參數。心智模型跟不上這些隱性耦合，而且人會系統性地低估「看起來無關」的路徑——正是最容易出事的那種。

第一層：程式碼層的依賴。 從變更的函式出發，沿呼叫圖與資料相依找出受影響的單元，凡是覆蓋到這些單元的測試就入選。這一層工具能全自動——單元測試框架（如 VectorCAST）本來就記錄每條測試覆蓋了哪些程式碼，反查即得。它的極限是看不到「規格改了但程式碼沒改」的情況。

第二層：需求層的追溯。 變更單掛到需求，需求透過雙向追溯連到測試案例——需求改了，對應測試必選，同時上下游需求的測試進入候選。這一層的品質完全取決於追溯鏈的品質：追溯是人工事後補的，這層就是裝飾品；追溯是開發流程的一部分（例如 ALM 工具強制掛鉤），這層才有效力。

第三層：風險層的加權。 安全相關（帶 ASIL 屬性）的需求，其測試不管影響分析怎麼說都應該在迴歸集裡佔一席——影響分析是機率性的，功能安全的證據要求是確定性的。實務做法是維護一個「不可裁剪核心集」，每次必跑，選測只作用在核心集之外。

提交 → 靜態檢查(PC-lint Plus) → 影響分析 → 選出的單元測試(VectorCAST)
    → 選出的整合/系統測試(CANoe + vTESTstudio) → 覆蓋率與追溯報告

幾個工程細節決定成敗：

測試要可獨立執行：選測的前提是測試之間沒有隱性順序依賴。靠前一條測試留下的狀態才能跑的測試，一被單獨挑出來就假失敗
環境要分層：單元測試在建置機上跑、系統測試進 SIL、需要真實時序的進 HIL——選測結果應該標注每條測試的最低環境需求，才能把貴的環境留給非它不可的測試（分層邏輯見 HIL 測試是什麼）
每晚全量兜底：選測管快速回饋，夜間排程仍然全量跑一輪。選測漏掉而全量抓到的差集，就是校正影響分析的訓練資料

迴歸選測不是為了「少測」，是為了把回饋時間從天壓到小時，讓工程師在還記得自己改了什麼的時候看到結果。合規證據該有的完整執行紀錄一樣要有——選測與全量是互補的節奏，不是取捨。

從追溯鏈建立、影響分析到管線整合，歐特莫夫（Vector Informatik 合作夥伴）協助把「該跑哪些測試」變成算出來的答案。