需求式測試、Robustness、驗收環境
SWE.6 軟體資格測試：在目標環境（或高度模擬的環境）執行，證明完整軟體符合軟體需求。這是軟體層的「畢業考」。
| 測試 | 對象 | 環境 | 證明什麼 |
|---|---|---|---|
| SWE.4 單元 | 單元 | PC/模擬 | 單元符合詳細設計 |
| SWE.5 整合 | 整合後模組 | 模擬/部分目標 | 元件互動正確 |
| SWE.6 資格 | 完整軟體 | 目標環境 | 符合軟體需求 |
軟體資格測試計畫（AEB）
環境：目標 ECU + 訊號模擬（Vector CANoe）
需求覆蓋：SWR 共 45 條 → 測試 60 個用例（全數追溯）
Robustness 組：
RQ-01 CAN bus off 30s → 系統不崩潰、恢復正常
RQ-02 非法 frame（亂 CRC）→ 丟棄 + 日誌
RQ-03 CPU 滿載瞬間 → AEB 決策時序仍 ≤ 20ms
通過準則：無 CRITICAL 失敗；需求式用例全過；Robustness
全過（可接受低嚴重度例外並開問題單）
SWR-AEB-011（TTC<1.2s 輸出 BRAKE_REQUEST=ON）
資格測試 QT-031：
在目標 ECU 上送入模擬雷達資料流（真實 CAN 訊號）
其中一幀 TTC=1.1s → 觀察 BRAKE_REQUEST 訊號
期望：訊號在 TTC<1.2s 後 ≤5ms 內為 ON；
當 TTC 回 2.0s 以上 → 恢復 OFF
結果：PASS（實測延遲 3ms）
證據：CAN log + 時間戳 + 測試紀錄
動手：為你的 3 條軟體需求各設計一個資格測試用例（含環境與通過準則）。
SWE.6 與單元測試的關鍵差異是觀察整個軟體在代表性目標環境中的外部行為。資格測試不是把所有測試再跑一次，而是依 SWR 建立需求覆蓋，加入實際通訊、排程、硬體限制與 robustness。測試前先固定軟體、硬體、工具與校準版本；測試後保留原始 log、時間戳與問題單，否則 PASS 結論缺乏可重現性。
| 資格測試問題 | 應回答 | 證據 |
|---|---|---|
| 需求覆蓋 | 每條 SWR 由哪個 QT 驗證？ | 追溯矩陣 |
| 目標環境 | 測試配置是否接近實際 ECU？ | 配置快照、版本 |
| Robustness | 異常輸入與資源壓力如何反應？ | 故障 log、問題單 |
需求 SWR-014：CAN bus-off 後 30 s 內恢復接收，且 AEB 不崩潰。 測試 QT-042：在目標 ECU 注入 bus-off，記錄 reset reason、CAN 狀態、 BRAKE_REQUEST 與恢復時間。結果：無重啟，但 31.2 s 才恢復。 判定：FAIL，不可用「功能大致正常」放行；開問題單， 分析網路管理/排程，修正後保留原失敗證據並重跑回歸。
資格測試的放行條件應在測試前就定義，不能看完結果後才調整門檻。若有例外放行，必須記錄理由、風險接受者、補救措施與有效期限。
若測試因硬體供應、工具限制或場景不可重現而延期，應把它當成風險與變更管理議題，而不是從報告中刪掉。例外放行要清楚列出未驗證的需求、暫時控制、責任人與最晚完成日期；下一個版本必須能追蹤例外是否真正關閉。
評鑑目標：SWE.5（軟體整合測試）CL2 評鑑師：2 名，評鑑時間：3 天 ┌─ 客觀證據（Objective Evidence）準備 ──────────────────────┐ │ 1. 基本實踐（BP）對應證據： │ │ │ │ BP.1：建立整合測試計畫 │ │ 證據：整合測試計畫文件（SWITP_v2.1.pdf） │ │ 佐證：評審紀錄、核准簽章 │ │ │ │ BP.2：建立整合測試案例 │ │ 證據：測試案例規格文件（SWITS_v3.0.xlsx） │ │ 佐證：測試案例追溯到需求的矩陣 │ │ │ │ BP.3：執行整合測試 │ │ 證據：測試執行報告（SWITR_v2.5.pdf） │ │ 佐證：測試環境配置、測試腳本、原始數據 │ │ │ │ BP.4：建立測試結果摘要 │ │ 證據：測試摘要報告（SWITSUM_v1.2.pdf） │ │ 佐證：缺陷統計、覆蓋率報告 │ │ │ │ BP.5：解決問題 │ │ 證據：問題追蹤系統截圖（Jira） │ │ 佐證：問題關閉紀錄、根因分析報告 │ ├─ 評鑑師常見提問 ──────────────────────────────────────────┤ │ Q1：測試案例如何追溯到需求？ │ │ A：使用追溯矩陣（Traceability Matrix），每個測試案例 │ │ 連結到至少一條系統需求。 │ │ │ │ Q2：如何確保測試環境代表性？ │ │ A：測試環境配置文件記載硬體版本、軟體版本、周邊設備， │ │ 與量產環境保持一致。 │ │ │ │ Q3：未通過的測試案例如何處理？ │ │ A：建立問題追蹤單，進行根因分析，修正後執行迴歸測試， │ │ 由獨立人員驗證關閉。 │ └────────────────────────────────────────────────────────────┘
ISO 33020 要求評鑑基於「客觀證據」（Objective Evidence）。 客觀證據的定義：可驗證的文件、記錄或陳述，證明過程已執行且產出符合要求。
關鍵概念：「證據鏈」（Evidence Chain）。僅有「計畫」不夠—— 評鑑師會追問：計畫是否被核准？執行結果是否與計畫一致？偏離如何處理？ 完整的證據鏈 = 計畫 + 執行紀錄 + 結果 + 偏離處理 + 核准紀錄。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 評鑑師判定 BP 不符合 | 客觀證據不完整或不一致 | 建立 BP 對應的「證據清單」（Evidence Checklist），逐項準備 |
| 評鑑師追問深層問題無法回答 | 團隊僅了解「做什么」，不了解「為什么」 | 進行評鑑前的角色扮演演練，準備「为什么」的回答 |
| 文件版本混亂 | 缺乏版本管理機制 | 導入文件版本管理系統（如 SharePoint + 版本控制） |