整合策略、相依性測試、介面測試
SWE.5 軟體整合與整合測試：把已驗證的單元依架構整合成子系統/完整軟體，並用整合測試證明元件間互動正確。
| 策略 | 做法 | 優點 | 風險 |
|---|---|---|---|
| Big-bang | 一次全部接 | 快 | 錯難定位（不建議） |
| Bottom-up | 底層→上層 | 介面早驗證 | 上層邏輯晚驗 |
| Top-down | 上層→底層（stub） | 流程早通 | 底層風險晚見 |
| Critical-path | 先合高風險/高 ASIL | 風險先驗 | 需計畫細 |
IT-021｜來源 SWR-AEB-011/014｜AEB 決策 + 安全狀態
情境：正常運行中，雷達心跳停止（模擬）
步驟：輸入停止的心跳 → 等 200ms
期望：AEB 決策模組收到逾時事件 → 進入安全狀態
（BRAKE_REQUEST 保持 OFF + 警示 ON）
通過準則：狀態轉換 < 200ms；無殘留記憶體增長
每輪整合要對應架構層（見單元 9）：先驗驅動層→服務層→應用層，每層整合都以該層介面為測試面。
Day1 驅動層：CAN + Watchdog 整合（frame 收發、心跳） Day2 服務層：通訊 + 排程整合（資料不丟、優先權正確） Day3 Critical path：TTC → AEB 決策 → 煞車命令（模擬致動） Day4 加入警示與安全狀態模組 Day5 全模組整合 + 資源檢查（記憶體/CPU） Day6 回歸：重跑 Day1-5 + 記錄整合測試報告
動手：為你的系統選一種整合策略，並寫出 3 個跨單元的整合測試用例。
SWE.5 的失敗通常不是單元演算法錯，而是資料格式、初始化順序、週期、共享資源或錯誤狀態在連接後產生差異。因此整合計畫要先辨識高風險介面，再使用 stub、driver 或真實硬體控制變因。每一輪應保留可工作的基線，這樣失敗能定位到最近一次變更，而不是等全部模組接完才面對不可分解的問題。
| 整合面 | 要驗證 | 典型刺激 |
|---|---|---|
| 資料 | 單位、格式、有效旗標 | 零值、最大值、亂碼 |
| 時序 | 週期、逾時、優先權 | 延遲與 CPU 負載 |
| 狀態 | 初始化、失效、復原 | 斷線、重啟、重入 |
現象：AEB 整合測試中 TTC 顯示 1.1 s，但決策模組未煞車。 第一輪：以 stub 固定輸入，確認決策與致動器介面正常。 第二輪：接入雷達解析器，發現距離單位由 mm 被當成 m。 修正：在介面契約標示單位與範圍，加入轉換測試與診斷； 以同一基線重跑單元、整合與資格回歸，避免只修一層。
整合測試報告最好同時附上介面版本與模擬器設定。沒有這些資訊，下一次回歸可能只是「同名測試」而不是同一個測試。
當單元測試通過、整合測試失敗時，優先比較輸入輸出格式、初始化順序、資料有效旗標、週期與執行緒優先權。直接修改演算法可能掩蓋真正的介面契約錯誤，讓單元與系統行為逐漸分叉。每次修正都要指出它屬於介面、排程、資源或功能缺陷，並選擇對應的回歸範圍。
組織：Tier-1 供應商，200 人研發團隊，首次導入 ASPICE。 目標：2 年內從 CL1 升級到 CL2。 ┌─ 組織現況診斷 ────────────────────────────────────────────┐ │ 優勢： │ │ • 技術能力強，產品品質穩定 │ │ • 已有基礎的文件管理系統 │ │ • 管理層支持 │ │ 劣勢： │ │ • 文件化程度不足（口頭溝通為主） │ │ • 需求追溯性差（使用 Excel 管理） │ │ • 缺乏正式的評審（Review）機制 │ │ • 變更管理隨意，無正式流程 │ ├─ 變革策略 ────────────────────────────────────────────────┤ │ Phase 1：意識提升（3 個月） │ │ • 全員 ASPICE 基礎培訓 │ │ • 管理層承諾書簽署 │ │ • 建立 ASPICE 專責團隊（3 人） │ │ │ │ Phase 2：流程導入（6 個月） │ │ • 選擇 SWE.1 ~ SWE.5 為先導 Process Area │ │ • 建立流程文件（Procedure + Template） │ │ • 導入需求管理工具（Jama / DOORS） │ │ • 建立正式的評審機制（Peer Review + Safety Review） │ │ │ │ Phase 3：試運行（3 個月） │ │ • 選擇 1 個專案試行 │ │ • 收集回饋並調整流程 │ │ • 內部模擬評鑑 │ │ │ │ Phase 4：正式評鑑（1 個月） │ │ • 聘請認證評鑑師 │ │ • 執行正式 CL2 評鑑 │ │ • 修正殘留問題 │ └────────────────────────────────────────────────────────────┘ 關鍵成功因素： 1. 管理層持續支持（不是一次性承諾） 2. 流程與專案實務結合（不是額外文件工作） 3. 工具導入降低人工作業負擔 4. 內部 champion（推動者）的影響力
ISO 33020 定義了「過程能力等級」的遞進關係： CL0（Incomplete）→ CL1（Performed）→ CL2（Managed）→ CL3（Established）→ CL4（Predictable）→ CL5（Optimizing）。
關鍵概念：「Managed」（CL2）的核心特徵。 CL2 不僅要求過程「執行」（CL1），更要求過程「有管理地執行」——包含： ① 計畫與追蹤（Planning & Tracking）、② 評鑑（Evaluation）、③ 認同（Agreement）、 ④ 可追溯性（Traceability）。這是多數團隊從 CL1 升級到 CL2 的最大挑戰。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 團隊抵觸流程變更 | 流程被視為「額外工作」而非「幫助」 | 展示流程如何減少重工（Rework）和缺陷，量化收益 |
| 需求管理工具導入失敗 | 工具太複雜，團隊不願學習 | 選擇易用工具（如 Jama Connect），並提供充分培訓 |
| 內部模擬評鑑發現大量缺失 | 流程文件與實際執行不一致 | 調整流程文件以反映實際做法，而非紙上作業 |