介紹 測試是汽車開發(fā)過程中的一個重要部分。隨著軟件越來越多地被應(yīng)用于現(xiàn)代汽車，對嚴格軟件測試方法的需求也變得越來越多。一個一直被忽略的特殊方面是：具有很多獨特特色的商用車領(lǐng)域的軟件測試的實踐。 本文是對商用車領(lǐng)域軟件測試的第一個全面的研究。但是，許多特征和相關(guān)結(jié)果可以外推到汽車行業(yè)的其他部分，而且更廣泛地，還可以外推到嵌入式系統(tǒng)領(lǐng)域。我們通過對用于汽車行業(yè)的26工具和歐洲市場的20個工具/服務(wù)提供商的調(diào)查研究了現(xiàn)行做法。最后，還預(yù)測了未來潛在機會的一些方向。 本文希望能給汽車行業(yè)從業(yè)人員提供現(xiàn)被用于汽車領(lǐng)域的軟件測試工具和服務(wù)的深刻見解。 由于本文重點是商用車領(lǐng)域，工具/服務(wù)提供商可以熟悉這一領(lǐng)域的潛在機會。 最后，對學(xué)生和研究人員來說，了解汽車嵌入式軟件測試是如何在實踐中進行的，及塑造汽車行業(yè)的新概念有哪些或許也挺有意思的。商用車領(lǐng)域 2.1定義 歐盟根據(jù)其結(jié)構(gòu)及設(shè)備類型的設(shè)計目的來定義”商用車”，能夠運載：a）超過九人，包括司機在內(nèi)；b）貨物和標(biāo)準油箱[ 1 ] 的任何機動道路車輛都屬于”商用車”。 輕型商用車（ LCV ）是車總重≤3.5噸的商用車的歐盟正式術(shù)語，符合該類別的車輛有面包車，小巴和輕型卡車等；重型商用車（ HCV）是車總重>3.5噸的商用車的歐盟正式術(shù)語，符合該類別的車輛有貨車，卡車，油罐車等。HCV的一個更廣泛的定義里還包括農(nóng)用車輛（拖拉機，收割機等），及施工車輛（巖石鉆機，推土機，輪式裝載機等）在內(nèi)的重型設(shè)備和機械。 本文的研究范圍涵蓋了輕型和重型商用車。 2.2市場規(guī)模和潛力 商用車輛占有了汽車行業(yè)的一個具體且不可忽略的市場份額。按照ACEA （歐洲汽車制造商協(xié)會）數(shù)據(jù)顯示，2012年全世界生產(chǎn)的超過20萬臺的商用車占據(jù)了歐盟市場11.3％的份額。較2011年，2012年歐盟產(chǎn)的LCV / HCV出口收入增加了22.9 ％[3] 。 同樣， Frost＆Sullivan公司[ 2 ]指出，歐洲對輕型商用車的需求已經(jīng)遠遠超過其他大洲。特別是混合商用車，在不久的將來將占據(jù)主要市場份額。一直會用到大約2016年的大多數(shù)混合LCVs將包括梅賽德斯－奔馳Sprinter和福特Transit Connect的電動版本。這兩款車型有望占據(jù)歐洲混合輕型商用車市場的三分之一。 不看生產(chǎn)數(shù)據(jù)統(tǒng)計，伴隨著全世界24%的年復(fù)合增長率[ 2 ]，所有主要地區(qū)均有望保持商用車遠程信息技術(shù)的增長速度。 2.3質(zhì)量保證的挑戰(zhàn)概述 在現(xiàn)代汽車的發(fā)展趨勢已從純機械轉(zhuǎn)向廣泛地電子化。 一輛典型現(xiàn)代汽車里的電子控制單元（ECU）粗略估計大約有70個，包括100多萬的目標(biāo)代碼指令和近1 GB的軟件[ 4 ] 。 這一趨勢也反映在商用車的發(fā)展中。對嵌入式控制器越來越多的使用已或多或少地充當(dāng)了商用車遠程信息的催化劑。 這類車的價值創(chuàng)造主要是由嵌入式軟件決定的，這不僅增加了成本和復(fù)雜性的，還增加了嵌入式軟件的潛在缺陷。機械缺陷逐漸減少的同時，電子系統(tǒng)造成的缺陷卻正在迅速增加[ 5 ] 。傳動、線控、導(dǎo)航、人機工程學(xué)和信息娛樂類技術(shù)的進步要求嵌入式系統(tǒng)方法中有嚴格的質(zhì)量保證措施。全球汽車業(yè)也普遍如此。 但是，商用車行業(yè)尤其受到旨在提高環(huán)境保護，安全（ ISO 26262/IEC 61508 ）和質(zhì)量保證措施（ IEEE 610 ） [ 9 ]的嚴格法規(guī)的影響， 。 為了滿足當(dāng)下目標(biāo)，就要完全更新?lián)Q代正在開發(fā)中的發(fā)動機，底盤和車身。所需解決的問題是：應(yīng)該在商用車先進的嵌入式系統(tǒng)中使用什么樣的，以及如何運用恰當(dāng)?shù)馁|(zhì)量保證策略。 3．視覺測試領(lǐng)域特征 本節(jié)從測試的角度來描述：商用車領(lǐng)域的特征是相當(dāng)重要的。 3.1安全性高要求 安全性是商用車的一個極其嚴格的要求。 歐洲道路評估計劃的目的是：到2020年，要把歐洲交通事故的概率減少到零死亡。——該項目被稱為Vision Zero。相關(guān)的標(biāo)準，如ISO 26262 [ 9 ] ，也對汽車行業(yè)施加壓力，使之為了讓工程道路更安全去開發(fā)協(xié)議，工具和最佳實踐準則。 還有一些其他專門針對商用車的安全措施。例如，重型卡車對由于開車時不經(jīng)意地超出側(cè)翻閾值而直接造成的翻車事件要多加注意。因此，制造商已經(jīng)投入了相當(dāng)多的時間和資源建立安全措施（例如：翻滾穩(wěn)定控制系統(tǒng)）以應(yīng)付重型商用車的這種情況。 3.2可靠性高需求 可靠性關(guān)注的是系統(tǒng)中故障率的量化。軟件可靠性是一定執(zhí)行時間內(nèi)軟件不會失敗的概率。 迄今為止在汽車領(lǐng)域，相較于其他嵌入式系統(tǒng)領(lǐng)域如航空電子設(shè)備[4]，可靠性并未受到正式管理。 此外，商用車應(yīng)該在艱苦的，安全性很苛刻的環(huán)境下也能正常工作，如重型卡車裝載數(shù)噸燃料，巖石鉆機鉆探不規(guī)則表面。因此，低可靠性會導(dǎo)致運行過程中出現(xiàn)危險情況。 他們的預(yù)期壽命要比正常客車長。所有這些情況都對車輛的可靠性和耐用性附加了要求。 3.3實時電子控制單元（ECU）功能 商用車嵌入式系統(tǒng)的復(fù)雜性很大程度上是因為大多數(shù)汽車系統(tǒng)的其它類并不正視實時性和界面限制。 對汽車軟件工程實踐的研究[ 4 ]表明，大部分車輛功能是由硬質(zhì)和軟質(zhì)實時任務(wù)實現(xiàn)的。 極端情況下，多達95 ％的功能由硬實時任務(wù)模擬，最有可能是商用車，因為對于商用車，像具有離散事件軟實時功能的多媒體功能和人體舒適感功能并不太重要。 此外，要求不軟不硬但有時又介于兩者之間的功能，往往模擬為硬質(zhì)[ 4 ]的 。典型的要求包括任務(wù)間的優(yōu)先關(guān)系和抖動。 時間限制，例如截止時限在單個應(yīng)用程序中可以變化多達三個數(shù)量級，通常從毫秒到幾秒。 這方面的測試是極具挑戰(zhàn)性的，因為一個系統(tǒng)的正確性不僅取決于其邏輯正確性，還取決于結(jié)果生成的確切時間。 往往很難追蹤和再現(xiàn)錯誤，因為這需要對決定何時模擬系統(tǒng)及何時期望反應(yīng)有很高的精確度。 3.4交錯配置及變體
商用車的產(chǎn)品體積通常比客車小。而且，用戶往往對諸如發(fā)動機扭轉(zhuǎn)力，有效載荷等[5]技術(shù)規(guī)范要求更多。因此，汽車制造商經(jīng)常用產(chǎn)品變體滿足更大的客戶群，從而增加市場份額及產(chǎn)品生產(chǎn)量。所以，商用車輛的嵌入式系統(tǒng)包括來自多個供應(yīng)商的組件，且存在于大量的配置和變體里。
這就導(dǎo)致了為了覆蓋龐大的產(chǎn)品變體而進行的測試活動方面的巨大的工作量。
3.5分布式開發(fā)
由于商用車部件變體的不一致性，汽車制造商不可能開發(fā)其所有的內(nèi)部產(chǎn)品。相反，他們更愿意依賴第三方供應(yīng)商成熟的專業(yè)知識。
由于這個原因，部分還因為嚴格的成本要求，商用車的發(fā)展在很大程度上被分散和外包[ 6 ]了 。這就形成了許多供應(yīng)鏈關(guān)系使得規(guī)范最新及各級一致很困難。
事實上，制造商最終也沒能在一個“黑盒”元件的內(nèi)部設(shè)計出什么細節(jié)[4]。這就增加了定位單元和集成層次的組件測試誤差的復(fù)雜性。
4 .汽車軟件測試實踐
本節(jié)概述了汽車軟件測試里的實踐情況。
本研究著眼于商用車領(lǐng)域，但本節(jié)的研究結(jié)果適用于整個汽車行業(yè)。
請注意，本節(jié)中的經(jīng)驗僅限于汽車行業(yè)主要名人們使用的主流做法。還有其他一些包括研究和技術(shù)創(chuàng)新的做法，被排除在本研究之外。
這里，我們的目的是提供一些明確的汽車行業(yè)的主要做法。
4.1基于模型的開發(fā)和測試
根據(jù)作者與主要汽車制造商、供應(yīng)商合作的經(jīng)驗，現(xiàn)代汽車開發(fā)過程中模型驅(qū)動工程有著強勁的發(fā)展勢頭。這包括開發(fā)過程的各個階段，即從需求到驗證。
模型是表示系統(tǒng)行為一部分的一個抽象視圖。
工程師很早期就使用特定領(lǐng)域建模技術(shù)為系統(tǒng)行為建模，使他們能夠通過模型自動生成代碼并在實施前測試系統(tǒng)，快速開發(fā)系統(tǒng)。
基于模型的測試的基本思想是：應(yīng)用選定的算法由模型[13]自動生成測試，而不是手動創(chuàng)建測試用例。
除了自動化程度高，基于模型的測試還有助于由抽象層面來維持系統(tǒng)模型間的可追蹤性并由系統(tǒng)執(zhí)行層面來測試輸出間的可追蹤性。這就使得錯誤的來源容易追蹤，也降低了整體測試活動的精力和成本。
4.2循環(huán)X測試水平
基于模型的開發(fā)和測試的不同階段是用汽車SPICE開發(fā)標(biāo)準所推薦的V模型（見圖1）手動描述的。
V模型通常被設(shè)計來進行符合開發(fā)流程的不同水平的測試工作。
這些水平的測試被稱為循環(huán)模型，循環(huán)軟件，循環(huán)處理器（HIL）和循環(huán)硬件（又名循環(huán)X [ 7 ] ）測試，說明如下。
MIL （循環(huán)模型） ：
MIL提供可用系統(tǒng)（或子系統(tǒng)）模型的測試，且該模型及其環(huán)境沒有任何物理硬件就可以進行仿真模擬。該系統(tǒng)的輸入、輸出界面被定義為關(guān)于不同的測試場景。
輸入信號值進行了模擬，且相應(yīng)的輸出信號值與在該場景中定義的預(yù)期值進行了比較。
很早期甚至早在實施之前，MIL測試就可以進行系統(tǒng)的功能驗證。
由于在同一臺機器上的模型和環(huán)境類似，所以就不需要實時硬件了。
SiL（循環(huán)軟件） ：
SIL進行可執(zhí)行代碼段（或?qū)嵤┒危┑臏y試。
在同一個機器上的操作情況相似。因此，此水平不需要實時硬件。
所有關(guān)于存儲容量，數(shù)據(jù)結(jié)構(gòu)等的細節(jié)都是由被模擬的環(huán)境控制的。這確保了任何“運行時錯誤”（緩沖區(qū)溢出，除以零，非法類型轉(zhuǎn)換錯誤等）在實施時的檢測。
此外，它還使系統(tǒng)行為可以通過運行MIL里同樣的測試場景對模型進行驗證。
PIL （循環(huán)處理器） ：
PIL確保在目標(biāo)處理器或目標(biāo)處理器模擬器上運行時，可以測試實施過程。
執(zhí)行環(huán)境通常仍是通過一個專用的實時仿真器模擬的。
這個階段的故障可以與目標(biāo)編譯器（聯(lián)動，優(yōu)化選項，等等）或目標(biāo)處理器架構(gòu)聯(lián)系起來。
MIL和SIL的測試場景在這可以用來與原結(jié)果進行比較，確保代碼功能正確，即使是在它已被編譯并在目標(biāo)處理器上運行后。
HiL（循環(huán)硬件） ：
HiL使現(xiàn)被嵌入實際硬件（ECU）中的實施得以被測試。這是通過把ECU和一個專用的實時仿真器連接起來完成的，此仿真器闡明了ECU對分析結(jié)果的測試環(huán)境的實際輸入/輸出。
ECU用來交流的嵌入式系統(tǒng)的其他部分仍然可以被模擬。
然而，它們與真實的電子信號進行交互。
HiL里的測試可以在實時環(huán)境中分析代碼和硬件集成。
此水平的故障，也與輸入/輸出界面間的低水平通信，與嵌入式系統(tǒng)的其他部分的實時通信有關(guān)。
MIL和SIL的測試場景可以用來驗證先前觀察到的系統(tǒng)行為。
圖1. V模型闡明循環(huán)X測試階段