1 嵌入式軟件測試（Testing of the embedded Software）

該活動目的是提供證據證明嵌入式軟件在目標環境中滿足其需求。可通過其他驗證活動的適當結果提供該證據。

• 目的：
  該子階段目的是提供證據證明嵌入式軟件：
• a) 在目標環境中執行時滿足安全相關需求；
• b) 不包含與功能安全相關的非所需功能和特性。

2 測試輸入

• 軟件安全需求規范；

可參考：

• 可考慮下列信息：
• 技術安全概念（參見ISO 26262-4:2018, 6.5.2）；
• 系統設計規范（參見ISO 26262-4:2018, 6.5.3）；
• 集成和測試策略（參見ISO 26262-4:2018, 7.5.1）；及
• 集成測試報告（參見ISO 26262-4:2018, 7.5.2）。

3 驗證要求和建議

為驗證嵌入式軟件在目標環境中滿足軟件安全需求，應在表13所列的適當測試環境中按照ISO 26262-8:2018第9章規定進行測試。
注：可以復用已有的測試用例，如來自軟件集成測試的測試用例。

3.1 測試環境

表13 用于執行軟件測試的測試環境：

備注：

• a 示例包括集成了車輛部分或全部電氣系統的測試臺架、“lab-car”或“mule-car”，以及剩余總線仿真。
• b 根據不同ASIL等級要求，合理靈活選取測試環境方法

3.2 測試方法

采用表14所列方法對嵌入式軟件進行測試，以提供證據證明嵌入式軟件滿足各自ASIL等級要求的軟件需求。
表14 嵌入式軟件的測試方法

備注：
a 在軟件測試環境中，故障注入測試是指通過破壞校準參數等方法將故障引入軟件。

3.2.1 基于需求的測試

• 定義： 基于需求的測試是一種驗證技術，其核心目標是確認嵌入式軟件的實現是否精確地滿足了其指定的（通常是高層次）功能安全需求和非功能安全需求。

• 目標： 證明軟件的輸出和行為與需求規范定義的預期結果完全一致。它通過正向測試來驗證軟件按預期工作的“功能正確性”和“安全機制的有效性”。

• 方法： 測試用例的設計直接來源于需求規范。每個測試用例都對應一個或多個具體的需求項。測試執行就是模擬需求定義的輸入條件、操作序列和環境狀態，并檢查軟件的輸出、行為以及時間特性是否與需求規定的輸出、行為和約束（如時間限制）完全匹配。

• ISO 26262 上下文： ISO 26262 強烈要求在軟件單元測試和軟件集成測試階段執行基于需求的測試（如Part 6中的章節6.4.3和6.5.3）。它被視為建立軟件功能安全可信度的基礎。

• 覆蓋要求： 通常追求100%的需求覆蓋度，即每個軟件安全需求（無論是功能性的還是非功能性的，如時序約束）都必須至少有一個對應的測試用例進行驗證。在更高ASIL等級下，甚至要求路徑覆蓋或MC/DC覆蓋作為補充。

• 驗證屬性： 主要關注功能正確性、接口正確性、安全機制的激活條件/邏輯/效果以及時間行為（如響應時間）。

• 汽車行業示例 - 外燈TSR需求（RBT視角）：

  • 需求： “CCU 應監控導致倒車時右轉向燈點亮的 SPF（信號處理故障）。若檢測到該 SPF，CCU 應在 500 毫秒內關閉右轉向燈并輸出故障報警信號。”
  • 基于需求的測試設計（部分關鍵測試點）：
    1. 測試用例 TC_RBT_SPF_Detection：
    • 測試場景： CCU處于倒車檔位，右轉向燈因正常操作（非故障）被點亮。
    • 注入條件： 模擬一個會被識別為“導致倒車時右轉向燈點亮的SPF”（例如，故意設置一個來自轉向燈信號處理模塊的標志位/內部狀態為“故障狀態”，或者模擬一個不符合安全期望的信號值序列）。
    • 預期輸出： CCU 應該檢測到這個模擬的SPF。
    • 驗證點： 確保監控機制（軟件邏輯）能夠正確識別出這類特定的故障信號。
    2. 測試用例 TC_RBT_SPF_Reaction：
    • 測試場景： CCU處于倒車檔位，右轉向燈被點亮（無論是正常點亮還是因其他原因點亮）。
    • 注入條件： 模擬CCU內部檢測到上述SPF（設置一個代表SPF被檢測到的標志位或事件）。
    • 預期輸出： CCU 在500毫秒內 完成以下動作：
      • 關閉右轉向燈的控制信號。
      • 生成并輸出一個故障報警信號（例如，設置一個診斷故障碼/內部標志位，或通過總線發送報警信息）。
    • 驗證點： 驗證安全機制的核心邏輯（關閉燈光+報警）及其關鍵時間特性（≤500ms）完全符合需求。
    3. 測試用例 TC_RBT_SPF_NoDetection：
    • 測試場景： CCU處于倒車檔位，右轉向燈工作正常，沒有任何SPF發生。
    • 注入條件： 無SPF。
    • 預期輸出： CCU不會關閉右轉向燈（它應保持工作），也不會輸出故障報警信號。
    • 驗證點： 確保安全機制僅在檢測到指定SPF時才被觸發，避免誤動作（確保“虛警率”符合要求）。
  • 總結 ： 這些測試嚴格對照需求文本設計，直接驗證需求描述的“監控”、“檢測到則500ms內關閉+報警”的行為是否在軟件中被精確實現。測試執行時會精確測量從注入SPF到燈滅+報警發出的時間差。

3.2.2 故障注入測試

• 定義： 故障注入測試是一種評估軟件安全機制在應對內部或外部故障時的魯棒性和有效性的負向測試技術。它故意在軟件運行過程中引入模擬的故障或錯誤狀態，以觀察系統（尤其是其安全機制）如何檢測、控制和處理這些故障。

• 目標： 驗證安全機制是否能夠按設計要求檢測到特定的故障模式，并且在指定時間內執行正確的容錯或失效安全操作（如進入安全狀態、降級運行、報警），從而防止或減輕因這些故障導致的危險（違背安全目標）。

• 方法： 在軟件運行時（通常在目標硬件或高保真模擬環境下），通過特定工具或手段，強制性地將錯誤或故障狀態（如：修改關鍵變量的值、強制設置/復位錯誤標志位、翻轉存儲位、注入錯誤的傳感器數據、模擬硬件寄存器/內存位翻轉、模擬總線通信錯誤/延遲/丟失）注入到軟件中。然后監控系統的行為。

• ISO 26262 上下文： FIT主要與軟件集成測試和硬件-軟件集成測試強相關（如Part 6中的章節6.5.3）。它對應ISO 26262中故障避免和故障控制策略的驗證，特別是針對由硬件隨機故障或瞬態干擾導致的軟件錯誤。

• 覆蓋要求： 通常追求覆蓋安全機制設計中考慮的關鍵故障模式列表。這個列表來源于FMEA/FTA等安全分析中識別出的、需要軟件安全機制處理的故障。

• 驗證屬性： 主要關注安全機制在故障存在下的檢測能力、故障覆蓋率、反應邏輯的正確性、時間可靠性（能否在規定時間內響應）以及整體系統的失效行為（能否進入并維持安全狀態）。

• 通俗易懂的解釋：

  • 想象你在測試一個設備的緊急備用系統（安全機制）。故障注入測試就像一個故意的“破壞者”。
  • “破壞者”會想方設法給設備制造一些麻煩或“假故障”（比如，往數據里加“噪音”，故意拔掉某個傳感器的“線”，或者在內部存儲里制造點“亂碼”）。
  • 然后，觀察設備的備用系統（安全機制）能不能發現這些麻煩（故障）？發現了之后是不是按照應急預案（安全需求）快速地采取了保護措施（比如緊急關機、報故障燈）？
  • 目的是確保在真的發生問題時，備用系統能可靠地頂上去，避免出現災難性的后果（違背安全目標）。

• 汽車行業示例 - 外燈TSR需求 (FIT視角)：

  • 需求中的安全機制： CCU對SPF的監控和處理邏輯本身就是一種軟件安全機制。
  • 可能相關的故障模式及測試設計：
    1. 測試用例 TC_FIT_MemoryBitFlip：
    • 目標故障模式： 硬件隨機故障（如單粒子翻轉SEU）導致CCU內存中存儲的 SPF_DetectionFlag (假設用來表示是否檢測到SPF) 的值從 False (未檢測到) 意外翻轉為 True (檢測到）。
    • 注入方式： 在軟件運行過程中（尤其是在倒車時，無論右燈是否點亮），通過調試接口、硬件故障注入工具或仿真平臺，強制修改內存地址將該標志位設為True。
    • 預期行為： CCU的安全機制（監控邏輯）應“誤以為”檢測到了SPF。
    • 預期安全反應： CCU 應在500毫秒內 關閉右轉向燈并輸出故障報警信號。
    • 驗證點： 驗證安全機制對自身狀態錯誤的容錯能力。即使這個故障標志位是由于硬件錯誤被錯誤置位的，機制也應正常觸發關閉和報警，防止轉向燈因虛假信號在倒車時意外點亮。
    2. 測試用例 TC_FIT_CorruptedSensorData：
    • 目標故障模式： 從轉向燈信號處理模塊（或其他相關源）到CCU的信號在傳輸/處理中被破壞（例如，數據幀因EMC干擾被篡改、延遲或丟失），導致它看起來像是一個“導致倒車時右轉向燈點亮的SPF”（盡管實際上不是）。
    • 注入方式： 在CCU接收相關信號的輸入端口（軟件接口層面），模擬注入異常的、無效的、或符合SPF錯誤模式的數據包或值。
    • 預期行為： CCU的監控邏輯應識別出這是一個SPF（無論信號是真的故障還是被注入的錯誤）。
    • 預期安全反應： CCU應在500毫秒內關閉右轉向燈并輸出故障報警信號。
    • 驗證點： 驗證監控邏輯對輸入信號故障/錯誤的檢測能力和魯棒性。
    3. 測試用例 TC_FIT_LatentFault：
    • 目標故障模式： 一個SPF確實發生了，但CCU的監控邏輯自身因為某個軟件錯誤（比如一個關鍵循環計數變量溢出）未能成功設置 SPF_DetectionFlag 為 True。
    • 注入方式： 在SPF實際發生（或模擬其發生）的同時，通過故障注入工具阻止或篡改監控邏輯內部設置標志位的代碼路徑或變量值。
    • 預期安全反應: 機制失效（Flag保持為False）。在這個例子中，CCU不會關閉右轉向燈也不會報警！
    • 驗證點： 這時需要監控更高層的安全機制或者看是否違背了更高層的安全目標（e.g., “車輛在倒車時不得有轉向燈意外點亮”）。這可能暴露當前監控機制的單點弱點，需要分析其影響是否符合ASIL等級要求（可能要求額外的獨立監控機制或更高級別的故障探測）。這個測試用于驗證安全機制的診斷覆蓋度（發現自身內部問題的能力）。
  • 總結 (FIT)： 這些測試主動模擬各種可能影響安全機制本身或其輸入的異常情況和故障，檢驗該機制在這些“壞情況下”是否還能正確、及時地履行其安全職責（關閉燈+報警），或者暴露機制本身的缺陷。它與RBT相輔相成，RBT驗證“好路上走的對”，FIT驗證“壞路上還能不能撐得住”。

3.2.3 兩種方法的區別與聯系總結

特性	基于需求的測試	故障注入測試
核心目標	驗證功能正確性 & 實現符合需求	驗證安全機制在故障下的魯棒性、檢測能力和容錯效果
測試方向	正向測試 (驗證需求要求的“應該發生”)	負向測試 (驗證在“不應該發生”的故障下系統的反應)
輸入來源	直接從需求規范導出測試用例	從FMEA/FTA等分析得出的關鍵故障模式、失效場景導出測試用例
測試條件	正常輸入條件、預期的操作序列	人為注入異常/錯誤/故障狀態 (篡改數據、狀態、輸入信號、模擬硬件錯誤)
主要關注點	功能行為、接口、時間約束是否正確實現	安全機制的覆蓋率、故障檢測率、反應時間、失效安全行為
ISO 26262關聯	軟件單元/集成測試驗證的基礎	軟件集成/HSI測試驗證安全機制有效性的核心手段
類比	質檢員 (按說明書檢查功能)	破壞測試員 (故意搗亂看應急系統頂不頂得住)
案例重點	能否正確檢測SPF？能否在500ms內關閉+報警？	如果監控邏輯內存出錯怎么辦？如果輸入信號被污染怎么辦？

關聯性：
兩者是高度互補且必要的。RBT是基礎，確保安全機制在“晴空萬里”時能正確工作；FIT是深化，證明安全機制在“風雨交加”（故障）時依然可靠。在安全驗證中，尤其是對于高ASIL等級的軟件，兩者都必須嚴格執行，以達到要求的測試覆蓋度和置信度。RBT建立功能的信心，FIT建立安全韌性的信心。

3.3 測試用例導出方法

為確保軟件測試的測試案例規范符合11.4.2要求，應通過表15所列方法導出測試用例。
表1.5： 獲取嵌入式軟件測試案例的方法

備注：
a 軟件的操作使用案例包括現場更新軟件，僅在通過引導程序確保軟件完整的情況下啟動名義應用程序，嵌入式軟件在啟動、診斷、降級、休眠（進入睡眠狀態）、恢復電源（喚醒）、校準等不同操作模式下的安全相關行為，與不同ECUs之間的同步模式或為保障生產人員安全的生產線終端測試臺模式相關的功能。

測試用例導出方法介紹：

1. 需求分析 (Requirements-Based Testing - RBT)

   • 專業解釋： 測試用例直接從軟件安全需求（SRs）和軟件架構設計需求（SWADs）中推導出來。目的是驗證軟件是否實現了所有指定的需求。每個需求至少對應一個驗證其被滿足的測試用例（正向測試）。對于關鍵需求（尤其是安全目標相關），還需要考慮其被違反的情形（負向測試）。
   • 通俗解釋： 就像按照說明書檢查軟件。拿軟件的“任務清單”（需求列表）一條條看軟件做的對不對。主要關注“軟件應該做什么”。
   • 汽車示例 - TSR:
     • 需求： CCU 應監控導致倒車時右轉向燈點亮的 SPF（信號處理故障），若檢測到該 SPF，CCU 應在 500 毫秒內關閉右轉向燈并輸出故障報警信號。
     • 需求分析導出的測試用例：
       • TC_RBT_1 (正向)： 模擬在倒車檔位下注入一個導致右轉向燈錯誤點亮的SPF信號。預期結果： CCU在500ms內關閉右轉向燈，并輸出故障報警信號。
       • TC_RBT_2 (負向)： 模擬在非倒車檔位下（如前進擋）的相同SPF信號。預期結果： CCU不應該因為該信號而關閉右轉向燈或輸出報警（因為該SPF在非倒車時可能無危害或有其他處理邏輯）。
       • TC_RBT_3 (邊界/負向)： 模擬一個導致右轉向燈錯誤點亮的SPF信號，但信號特征僅略微超出“正常”范圍，檢查CCU是否仍能識別為SPF并做出響應。

2. 等價類生成與分析 (Equivalence Class Partitioning - ECP)

   • 專業解釋： 將輸入數據、輸出結果或內部狀態的取值范圍劃分為若干個被稱為“等價類”的區間。這些區間具有關鍵特性：同一個等價類內的所有值，預期會觸發相同的軟件行為或導致相同的處理結果。通過從每個等價類中選擇代表性值（通常是典型值）進行測試，就能在顯著減少測試用例數量的同時，提供合理的覆蓋率。
   • 通俗解釋： 把輸入數據分成“看上去差不多”的幾組。比如，考試分數：0-59不及格，60-79及格，80-100優秀。每組里抽一個分數測試就夠了，不用每個分數都考一次。
   • 汽車示例 - TSR:
     • 輸入： SPF檢測模塊的輸入信號強度（假設范圍0-5V，0V正常，>4V表示有效SPF）。
     • 等價類劃分：
     • EC1: 無效/弱信號 (0V - 3.9V)： 不應觸發故障處理（正常范圍）。
     • EC2: 邊界模糊信號 (~3.9V - 4.1V)：需要明確定義處理方式（可能不計為SPF，或計入但需考慮信號毛刺）。
     • EC3: 有效SPF信號 (>=4.1V)： 應觸發故障處理（關燈+報警）。
     • 等價類測試用例：
     • TC_ECP_1: 輸入信號 = 2.0V (EC1典型值)。預期結果： 無動作（右轉向燈保持正常或關閉狀態）。
     • TC_ECP_2: 輸入信號 = 4.0V (EC2典型值/邊界值)。預期結果： 需根據需求定義（可能無動作，或設置警告但不關燈）。
     • TC_ECP_3: 輸入信號 = 4.5V (EC3典型值)。預期結果： 同TC_RBT_1： 500ms內關燈+報警。

3. 邊界值分析 (Boundary Value Analysis - BVA)

   • 專業解釋： 經驗表明，很多缺陷發生在輸入等價類的邊界區域附近。BVA強調測試邊界值以及邊界值兩側的鄰點（即邊界值和剛剛超過/低于邊界的值）。它通常是對等價類劃分的補充和完善。
   • 通俗解釋： 特別關注“臨界點”附近。比如，上面考試的例子，不僅要測60（及格），還要測59（不及格）和61（及格），因為及格線附近最容易出判分錯誤。再比如電梯限重1000Kg，要測1000Kg能上（邊界），999Kg能上（邊界內鄰點），1001Kg不能上（邊界外鄰點）。
   • 汽車示例 - TSR:
     • 關注邊界： 500ms 的時間要求是核心安全關鍵邊界。
     • 邊界值測試用例：
     • TC_BVA_1: 模擬SPF發生，CCU在499ms時響應（關燈+報警）。預期結果： 不滿足需求！（必須前進檔）。預期結果： CCU應能正確處理檔位變化，在檔位變更為非倒車后停止關燈動作或維持安全狀態？具體行為需定義（根據設計，可能停止關燈并清除報警？或者仍需完成關燈動作以消除潛在風險？）。
     • TC_FDA_2: 模擬SPF發生時，右轉向燈驅動電路報告硬件故障（如短路）。預期結果： CCU仍應在500ms內嘗試關燈，并輸出故障報警信號（報警信號應能同時或額外指示硬件故障）。
     • TC_FDA_3: 資源沖突： 在SPF發生、CCU準備啟動500ms計時器時，另一個高ASIL等級的任務（如剎車控制）請求搶占同一個計時器資源。預期結果： 安全相關功能（計時器）應得到保障，可通過優先級或專用資源實現，避免延遲導致超時。

4. 操作使用案例分析 (Operational Scenario Analysis - OSA)

   • 專業解釋： 識別并測試在實際車輛運行環境中預期發生的各種操作情景（包括正常、降級、故障和緊急情況），特別是那些涉及安全機制激活的場景。場景涵蓋用戶操作、環境條件、系統狀態變化序列（前置條件）及其觸發的事件（如特定傳感器輸入），然后驗證軟件在該場景下的響應（輸出）。
   • 通俗解釋： 測試軟件在“實際開車時會遇到的各種情況”下的表現。比如：一邊開雨刮、一邊開空調、同時手機在充電、然后倒車入庫時觸發故障，看軟件還能不能正確處理關鍵安全動作。
   • 汽車示例 - TSR:
     • 操作場景：
     • 場景“倒車入庫”： 車輛緩慢倒入停車位（掛倒擋），駕駛員無轉向操作。此時，突然發生導致右轉向燈異常點亮的SPF。
     • 場景“故障后倒車修正”： 在TC_RBT_1場景后（右轉向燈已被關，報警已輸出），駕駛員嘗試再次倒車（掛D檔后重新掛R檔）。
     • 操作場景分析導出的測試用例：
     • TC_OSA_1: (基于“倒車入庫”) 結合功能依賴或錯誤猜測的用例（如TC_ERR_1），再加入典型倒車工況的負載（如超聲波雷達工作、儀表顯示倒車影像、EPB駐車動作等）。預期結果： CCU在綜合負載下仍滿足TC_RBT_1的要求（500ms關燈+報警）。
     • TC_OSA_2: (基于“故障后倒車修正”) 在TSR處于“右轉向燈因SPF已關閉且報警持續中”的狀態下，駕駛員再次掛入倒擋。預期結果：
       • 報警信號應持續存在（提醒維修）。
       • 在再次倒車時，沒有發生新的SPF：右轉向燈應保持關閉（不會點亮）。
       • 如果模擬一個新的SPF再次發生在倒車時：CCU應能再次檢測到并執行關燈+報警（即使之前已報過警）。確保安全機制能重復觸發。
       • 故障信號是否在特定條件下可清除？（如IGN OFF/ON復位），清除后行為？ (需根據需求定義測試)

總結：
這些測試用例導出方法不是互斥的，而是互補的。在ISO 26262合規的嵌入式軟件測試中，通常需要綜合運用這些方法：

1. 需求分析 (RBT) 提供基礎和強制性覆蓋。
2. 等價類(ECP) 和 邊界值分析(BVA) 用于高效處理輸入輸出空間，提高黑盒覆蓋率。
3. 錯誤猜測(Error Guessing) 利用經驗挖掘深層次和邊界外問題。
4. 功能依賴分析(FDA) 關注模塊間復雜的交互和資源沖突，這對嵌入式并發系統尤其重要。
5. 操作使用案例分析(OSA) 確保軟件在真實、復雜的環境下行為符合預期。

通過這種多層次、多角度的測試方法，才能最大限度地驗證嵌入式軟件的功能安全性，滿足ISO 26262對高ASIL等級系統的嚴格要求。您提供的TSR示例清晰地展示了如何將這些抽象的方法映射到一個具體、關鍵的安全需求上。

4 嵌入式軟件的測試結果評價

從以下幾個方面評價嵌入式軟件的測試結果：

• a) 是否符合預期結果；及
• b) 是否覆蓋軟件安全需求。
  注 其中包括是否覆蓋配置和校準范圍參見ISO 26262附件C

5 測試輸出物

• 軟件驗證規范（用例）
• 軟件驗證報告