靜態分析、單元測試、覆蓋率
SWE.4 軟體單元驗證：證明每個單元（函式/模組）符合其詳細設計。方法：靜態分析（不執行）+ 動態測試（執行）+ 覆蓋率。
| 方法 | ASIL A | B | C | D |
|---|---|---|---|---|
| 靜態分析（規則/工具） | ＋ | ＋ | ＋＋ | ＋＋ |
| 需求式單元測試 | ＋ | ＋ | ＋＋ | ＋＋ |
| 背靠背測試 | ＋ | ＋ | ＋ | ＋＋ |
| 故障注入（單元層） | ＋ | ＋ | ＋ | ＋＋ |
＋ = 建議；＋＋ = 高度建議（ASIL 越高越嚴格）。
| 覆蓋率 | 意義 | 門檻建議 |
|---|---|---|
| 語句（Statement） | 每行程式都執行過 | ASIL A/B：100% |
| 分支（Branch） | 每個判斷的兩個方向都走過 | ASIL C：100% |
| MC/DC | 每個布林條件獨立影響結果 | ASIL D：100% |
UT-011｜TTC_Calculator｜來源 SWR-AEB-011 輸入：dist=30.0, vrel=25.0 期望：ttc_ms=1200, valid=true；誤差 ≤ 2ms UT-012｜邊界｜vrel=1.0（靜止判定邊界） 期望：valid=false, ttc_ms=0 UT-013｜異常｜dist=250.0（超出 200）→ 回傳 false UT-014｜異常｜傳入 NULL 指標 → 回傳 false，不崩潰
對 TTC_Calculator 跑 UT-011~014 後，gcov 顯示： 語句覆蓋率 92%、分支覆蓋率 75% 缺口：vrel < 1.0 分支只測了邊界 1.0（vrel=1.0 未進 if） 補 UT-015：vrel=0.5 → valid=false 補 UT-016：vrel=1.0 精確值 → 依規格判定 重跑後：語句 100%、分支 100%（ASIL D 需 MC/DC，再補真值表）
動手：為你的某個函式寫 5 個單元測試，並用覆蓋率工具找出漏測分支。
需求式測試回答「規格是否被實現」，覆蓋率回答「測試走過哪些程式路徑」。兩者要交叉分析：有需求但沒有測試是追溯缺口，有程式路徑但沒有需求可能是死碼、錯誤設計或未文件化行為。ASIL 越高，越要對未覆蓋程式碼給出合理解釋、補測或移除決策，並保存工具版本、編譯選項與排除理由，讓結果可重現。
| 發現 | 可能原因 | 處置 |
|---|---|---|
| 語句未覆蓋 | 缺少異常/邊界案例 | 補需求式或故障測試 |
| 分支未覆蓋 | 條件組合未枚舉 | 建立決策表與 MC/DC 用例 |
| 無需求的程式 | 死碼或遺漏規格 | 移除或補需求與評審 |
條件：if (valid && ttc_ms < 1200) BRAKE_REQUEST=ON 現有測試只涵蓋 valid=true 的 ttc=1100/1300。 缺口：valid=false 且 ttc=1000 未證明短路後不煞車； 也未證明 ttc=1200 的邊界行為。 補測：false/1000、true/1199、true/1200、true/1201， 並將每個結果連回 SWR-AEB-011 的驗收準則。
把覆蓋率報告和測試結果放在同一個基線中，才能判斷「這份覆蓋率」究竟對應哪一份程式。工具報告若沒有版本與原始輸入，數字本身不具證據力。
專案背景：Tier-1 準備首次 VDA-SPICE 評鑑，目標 CL2。 評鑑範圍：SWE.1（軟體需求分析）、SWE.2（軟體架構設計）、SWE.5（軟體整合測試） ┌─ 差距分析（Gap Analysis）────────────────────────────────┐ │ Process Area │ CL1 現況 │ CL2 差距 │ 修正措施 │ │ SWE.1 │ 部分符合 │ 5 項缺失 │ 補充追溯矩陣 │ │ SWE.2 │ 不符合 │ 8 項缺失 │ 重新設計架構文件 │ │ SWE.5 │ 部分符合 │ 3 項缺失 │ 補充整合測試計畫 │ ├─ 缺失細項（SWE.1 為例）──────────────────────────────────┤ │ 1. 基本實踐 BP.1：未建立「軟體需求規格文件」 │ │ → 建立 SWRS 文件，使用 reqIF 格式 │ │ 2. BP.3：需求追溯性不足（僅單向追溯） │ │ → 建立雙向追溯矩陣（功能→安全→軟體） │ │ 3. BP.5：需求變更未記錄 │ │ → 導入需求變更控制流程（Change Request） │ │ 4. BP.6：與硬體介面需求未定義 │ │ → 補充 HSI 需求文件 │ │ 5. BP.7：與客戶介面需求未定義 │ │ → 補充 API 需求文件 │ ├─ 修正計畫 ────────────────────────────────────────────────┤ │ Phase 1（4 週）：建立文件框架與模板 │ │ Phase 2（6 週）：補充內容與追溯矩陣 │ │ Phase 3（2 週）：內部模擬評鑑（Mock Assessment） │ │ Phase 4（1 週）：修正殘留問題 │ └────────────────────────────────────────────────────────────┘
ISO 33020（取代 VDA-SPICE 2016）定義了「過程能力」（Process Capability） 的評估框架。CL1（Base Practices performed）是最基本的要求——所有 BP 必須「執行」 （Performed），但不要求文件化或制度化。
關鍵概念：「基本實踐」（Base Practices, BP）vs「工作產品」（Work Products, WP）。 BP 是過程活動（做什么），WP 是過程產出（交付什么）。CL2 要求 BP 完整執行且 WP 有組織地管理—— 這是多數團隊從 CL1 升級到 CL2 的主要瓶頸。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 差距分析結果與實際評鑑不符 | 差距分析未考慮評鑑師的解釋差異 | 聘請有經驗的評鑑師進行差距分析，或與評鑑機構對齊評估標準 |
| 修正計畫執行延誤 | 修正措施未納入專案計畫 | 將 SPICE 修正納入專案里程碑，由專案經理追蹤 |
| 內部模擬評鑑發現新問題 | 差距分析遺漏了 BP 間的交互影響 | 在差距分析中加入 BP 間的依賴性分析 |