介紹 測試是汽車開發過程中的一個重要部分。隨著軟件越來越多地被應用于現代汽車，對嚴格軟件測試方法的需求也變得越來越多。一個一直被忽略的特殊方面是：具有很多獨特特色的商用車領域的軟件測試的實踐。 本文是對商用車領域軟件測試的第一個全面的研究。但是，許多特征和相關結果可以外推到汽車行業的其他部分，而且更廣泛地，還可以外推到嵌入式系統領域。我們通過對用于汽車行業的26工具和歐洲市場的20個工具/服務提供商的調查研究了現行做法。最后，還預測了未來潛在機會的一些方向。 本文希望能給汽車行業從業人員提供現被用于汽車領域的軟件測試工具和服務的深刻見解。 由于本文重點是商用車領域，工具/服務提供商可以熟悉這一領域的潛在機會。 最后，對學生和研究人員來說，了解汽車嵌入式軟件測試是如何在實踐中進行的，及塑造汽車行業的新概念有哪些或許也挺有意思的。商用車領域 2.1定義 歐盟根據其結構及設備類型的設計目的來定義”商用車”，能夠運載：a）超過九人，包括司機在內；b）貨物和標準油箱[ 1 ] 的任何機動道路車輛都屬于”商用車”。 輕型商用車（ LCV ）是車總重≤3.5噸的商用車的歐盟正式術語，符合該類別的車輛有面包車，小巴和輕型卡車等；重型商用車（ HCV）是車總重>3.5噸的商用車的歐盟正式術語，符合該類別的車輛有貨車，卡車，油罐車等。HCV的一個更廣泛的定義里還包括農用車輛（拖拉機，收割機等），及施工車輛（巖石鉆機，推土機，輪式裝載機等）在內的重型設備和機械。 本文的研究范圍涵蓋了輕型和重型商用車。 2.2市場規模和潛力 商用車輛占有了汽車行業的一個具體且不可忽略的市場份額。按照ACEA （歐洲汽車制造商協會）數據顯示，2012年全世界生產的超過20萬臺的商用車占據了歐盟市場11.3％的份額。較2011年，2012年歐盟產的LCV / HCV出口收入增加了22.9 ％[3] 。 同樣， Frost＆Sullivan公司[ 2 ]指出，歐洲對輕型商用車的需求已經遠遠超過其他大洲。特別是混合商用車，在不久的將來將占據主要市場份額。一直會用到大約2016年的大多數混合LCVs將包括梅賽德斯－奔馳Sprinter和福特Transit Connect的電動版本。這兩款車型有望占據歐洲混合輕型商用車市場的三分之一。 不看生產數據統計，伴隨著全世界24%的年復合增長率[ 2 ]，所有主要地區均有望保持商用車遠程信息技術的增長速度。 2.3質量保證的挑戰概述 在現代汽車的發展趨勢已從純機械轉向廣泛地電子化。 一輛典型現代汽車里的電子控制單元（ECU）粗略估計大約有70個，包括100多萬的目標代碼指令和近1 GB的軟件[ 4 ] 。 這一趨勢也反映在商用車的發展中。對嵌入式控制器越來越多的使用已或多或少地充當了商用車遠程信息的催化劑。 這類車的價值創造主要是由嵌入式軟件決定的，這不僅增加了成本和復雜性的，還增加了嵌入式軟件的潛在缺陷。機械缺陷逐漸減少的同時，電子系統造成的缺陷卻正在迅速增加[ 5 ] 。傳動、線控、導航、人機工程學和信息娛樂類技術的進步要求嵌入式系統方法中有嚴格的質量保證措施。全球汽車業也普遍如此。 但是，商用車行業尤其受到旨在提高環境保護，安全（ ISO 26262/IEC 61508 ）和質量保證措施（ IEEE 610 ） [ 9 ]的嚴格法規的影響， 。 為了滿足當下目標，就要完全更新換代正在開發中的發動機，底盤和車身。所需解決的問題是：應該在商用車先進的嵌入式系統中使用什么樣的，以及如何運用恰當的質量保證策略。 3．視覺測試領域特征 本節從測試的角度來描述：商用車領域的特征是相當重要的。 3.1安全性高要求 安全性是商用車的一個極其嚴格的要求。 歐洲道路評估計劃的目的是：到2020年，要把歐洲交通事故的概率減少到零死亡。——該項目被稱為Vision Zero。相關的標準，如ISO 26262 [ 9 ] ，也對汽車行業施加壓力，使之為了讓工程道路更安全去開發協議，工具和最佳實踐準則。 還有一些其他專門針對商用車的安全措施。例如，重型卡車對由于開車時不經意地超出側翻閾值而直接造成的翻車事件要多加注意。因此，制造商已經投入了相當多的時間和資源建立安全措施（例如：翻滾穩定控制系統）以應付重型商用車的這種情況。 3.2可靠性高需求 可靠性關注的是系統中故障率的量化。軟件可靠性是一定執行時間內軟件不會失敗的概率。 迄今為止在汽車領域，相較于其他嵌入式系統領域如航空電子設備[4]，可靠性并未受到正式管理。 此外，商用車應該在艱苦的，安全性很苛刻的環境下也能正常工作，如重型卡車裝載數噸燃料，巖石鉆機鉆探不規則表面。因此，低可靠性會導致運行過程中出現危險情況。 他們的預期壽命要比正?？蛙囬L。所有這些情況都對車輛的可靠性和耐用性附加了要求?！ ?/span>
3.3實時電子控制單元（ECU）功能
商用車嵌入式系統的復雜性很大程度上是因為大多數汽車系統的其它類并不正視實時性和界面限制。
對汽車軟件工程實踐的研究[ 4 ]表明，大部分車輛功能是由硬質和軟質實時任務實現的。
極端情況下，多達95 ％的功能由硬實時任務模擬，最有可能是商用車，因為對于商用車，像具有離散事件軟實時功能的多媒體功能和人體舒適感功能并不太重要。
此外，要求不軟不硬但有時又介于兩者之間的功能，往往模擬為硬質[ 4 ]的 。典型的要求包括任務間的優先關系和抖動。
時間限制，例如截止時限在單個應用程序中可以變化多達三個數量級，通常從毫秒到幾秒。
這方面的測試是極具挑戰性的，因為一個系統的正確性不僅取決于其邏輯正確性，還取決于結果生成的確切時間。
往往很難追蹤和再現錯誤，因為這需要對決定何時模擬系統及何時期望反應有很高的精確度。 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測試階段