3.4交錯配置及變體
商用車的產品體積通常比客車小。而且，用戶往往對諸如發動機扭轉力，有效載荷等[5]技術規范要求更多。因此，汽車制造商經常用產品變體滿足更大的客戶群，從而增加市場份額及產品生產量。所以，商用車輛的嵌入式系統包括來自多個供應商的組件，且存在于大量的配置和變體里。
這導致了為了覆蓋龐大的產品變體而進行的測試活動方面的巨大的工作量。
3.5分布式開發
由于商用車部件變體的不一致性，汽車制造商不可能開發其所有的內部產品。相反，他們更愿意依賴第三方供應商成熟的專業知識。
由于這個原因，部分還因為嚴格的成本要求，商用車的發展在很大程度上被分散和外包[ 6 ]了 。這形成了許多供應鏈關系使得規范新及各級一致很困難。
事實上，制造商終也沒能在一個“黑盒”元件的內部設計出什么細節[4]。這增加了定位單元和集成層次的組件測試誤差的復雜性。
4 .汽車軟件測試實踐
本節概述了汽車軟件測試里的實踐情況。
本研究著眼于商用車領域，但本節的研究結果適用于整個汽車行業。
請注意，本節中的經驗于汽車行業主要名人們使用的主流做法。還有其他一些包括研究和技術創新的做法，被排除在本研究之外。
這里，我們的目的是提供一些明確的汽車行業的主要做法。
4.1基于模型的開發和測試
根據作者與主要汽車制造商、供應商合作的經驗，現代汽車開發過程中模型驅動工程有著強勁的發展勢頭。這包括開發過程的各個階段，即從需求到驗證。
模型是表示系統行為一部分的一個抽象視圖。
工程師很早期使用特定領域建模技術為系統行為建模，使他們能夠通過模型自動生成代碼并在實施前測試系統，快速開發系統。
基于模型的測試的基本思想是：應用選定的算法由模型[13]自動生成測試，而不是手動創建測試用例。
除了自動化程度高，基于模型的測試還有助于由抽象層面來維持系統模型間的可追蹤性并由系統執行層面來測試輸出間的可追蹤性。這使得錯誤的來源容易追蹤，也降低了整體測試活動的精力和成本。
4.2循環X測試水平
基于模型的開發和測試的不同階段是用汽車SPICE開發標準所推薦的V模型（見圖1）手動描述的。
V模型通常被設計來進行符合開發流程的不同水平的測試工作。
這些水平的測試被稱為循環模型，循環軟件，循環處理器（HIL）和循環硬件（又名循環X [ 7 ] ）測試，說明如下。
MIL （循環模型） ：
MIL提供可用系統（或子系統）模型的測試，且該模型及其環境沒有任何物理硬件可以進行仿真模擬。該系統的輸入、輸出界面被定義為關于不同的測試場景。
輸入信號值進行了模擬，且相應的輸出信號值與在該場景中定義的預期值進行了比較。
很早期甚至早在實施之前，MIL測試可以進行系統的功能驗證。
由于在同一臺機器上的模型和環境類似，所以不需要實時硬件了。
SiL（循環軟件） ：
SIL進行可執行代碼段（或實施段）的測試。
在同一個機器上的操作情況相似。因此，此水平不需要實時硬件。
所有關于存儲容量，數據結構等的細節都是由被模擬的環境控制的。這確保了任何“運行時錯誤”（緩沖區溢出，除以零，非法類型轉換錯誤等）在實施時的檢測。
此外，它還使系統行為可以通過運行MIL里同樣的測試場景對模型進行驗證。
PIL （循環處理器） ：
PIL確保在目標處理器或目標處理器模擬器上運行時，可以測試實施過程。
執行環境通常仍是通過一個專用的實時仿真器模擬的。
這個階段的故障可以與目標編譯器（聯動，優化選項，等等）或目標處理器架構聯系起來。
MIL和SIL的測試場景在這可以用來與原結果進行比較，確保代碼功能正確，即使是在它已被編譯并在目標處理器上運行后。
HiL（循環硬件） ：
HiL使現被嵌入實際硬件（ECU）中的實施得以被測試。這是通過把ECU和一個專用的實時仿真器連接起來完成的，此仿真器闡明了ECU對分析結果的測試環境的實際輸入/輸出。
ECU用來交流的嵌入式系統的其他部分仍然可以被模擬。
然而，它們與真實的電子信號進行交互。
HiL里的測試可以在實時環境中分析代碼和硬件集成。
此水平的故障，也與輸入/輸出界面間的低水平通信，與嵌入式系統的其他部分的實時通信有關。
MIL和SIL的測試場景可以用來驗證先前觀察到的系統行為。
圖1. V模型闡明循環X測試階段
（未完待續……）
版權聲明：本文出自 SPASVO澤眾軟件測試網：http://m.eqie.com.cn/news/html/2014313145621.html
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
