高效的汽車電子測試

　　[圖3：測試在所有開發(fā)階段都是不可或缺的]

　　這種分段式的工作方法產(chǎn)生于將開發(fā)過程中眾多不同的任務(wù)分配給專門的工作組。但是，如果對任務(wù)分割的要求太嚴(yán)格，那么存在于不同開發(fā)和測試任務(wù)間的眾多關(guān)聯(lián)點將很有可能不能被優(yōu)化利用。比如，只有很好地協(xié)調(diào)部件測試和系統(tǒng)測試才能避免開發(fā)大量內(nèi)容相同的冗余測試用例。當(dāng)使用兼容工具時，已經(jīng)開發(fā)出來的測試用例可以作為其它不同領(lǐng)域的開發(fā)基礎(chǔ)。避免冗余開發(fā)釋放了占用的資源，比如可以將其投入到現(xiàn)有測試用例及其高級開發(fā)的確認(rèn)工作中。全面的測試管理為協(xié)作提供了堅實的基礎(chǔ)，共用相同的測試用例優(yōu)化了測試的廣度和深度。協(xié)調(diào)也有助于發(fā)現(xiàn)和填補(bǔ)測試缺口。

　　除了連接不同的測試階段，開發(fā)和測試活動也必須相互聯(lián)系并互相適應(yīng)。應(yīng)當(dāng)將測試?yán)斫鉃殚_發(fā)的組成部分，需要使用恰當(dāng)?shù)姆椒ê凸ぞ邔ζ溥M(jìn)行廣泛的支持。這必須從程序上和組織上得到保證。這里，重要的是測試與開發(fā)一起進(jìn)行，而不是只在要求的正式確認(rèn)階段進(jìn)行。理想的情況是，可以直接在ECU開發(fā)者的工作地點利用現(xiàn)有的資源直接進(jìn)行測試。

　　為此，CANoe提供了一個用來執(zhí)行測試的運(yùn)行時環(huán)境，并可以與殘余總線仿真和分析功能并行使用 。該流程非常容易建立，尤其是在開發(fā)者已經(jīng)使用CANoe進(jìn)行殘余總線仿真和總線通信分析的情況下。

　　CANoe的測試組件可以手動、半自動和完全自動化的完成測試。開發(fā)者可以從簡單測試入手，然后對它們進(jìn)行擴(kuò)展和完善。通常，復(fù)雜測試的創(chuàng)建過程是確認(rèn)部門的任務(wù)，他們要在開發(fā)者的測試上建立他們的測試。

　　這種測試的重要基礎(chǔ)是殘余總線仿真。在理想情況下，這種仿真不是手工建立的，而是從系統(tǒng)的描述數(shù)據(jù)庫中自動生成和參數(shù)化的。實際工作由所謂的建模DLL（比如交互層、網(wǎng)絡(luò)管理等）完成，它們是隨工具一起提供的或者是由Vector作為OEM專用建模包提供的。殘余總線仿真為模擬節(jié)點提供的信號可以直接從測試腳本獲取，或者以手工方式激勵或添加。

　　與在測試階段系統(tǒng)進(jìn)行的計劃、執(zhí)行和歸檔活動相比，伴隨開發(fā)的測試通常省略了正式的執(zhí)行和歸檔。然而，這些測試對提高整體質(zhì)量做出了實際貢獻(xiàn)，因為他們讓開發(fā)者能夠為后續(xù)的測試階段提供更穩(wěn)定的產(chǎn)品。

　　4 成熟度評估和誤差分析

　　在開發(fā)過程中，為了評估ECU的成熟度，需要對所有執(zhí)行過的測試進(jìn)行全面的評價。必須考慮個體測試結(jié)果在可靠性和相關(guān)性方面的質(zhì)量，而更加重要

的是采用恰當(dāng)?shù)臏y試全面覆蓋所要求的特性。因此，不怎么正式執(zhí)行的測試，其結(jié)果對成熟度分析也是有幫助的。前提條件是（除了記錄測試過程外）使用兼容的配置管理。從完成面向質(zhì)量的、結(jié)構(gòu)化的開發(fā)過程的角度來說，這也是十分必要的。

　　不論在何時何地（測試實驗室或開發(fā)場所），使用CANoe執(zhí)行測試時都會生成一個測試記錄，該記錄創(chuàng)建時不需要用戶或測試用例開發(fā)者進(jìn)行干涉。這樣在進(jìn)行伴隨開發(fā)的測試時就不需要做額外的工作。用于測試記錄的XML是一種開放格式，可供其它工具使用以對結(jié)果進(jìn)行更深入的處理。例如，在進(jìn)行成熟度分析時可以使用一個測試管理系統(tǒng)來評價測試記錄。

　　該工作的本質(zhì)是測試結(jié)果到測試用例、測試用例到需求的映射。使用唯一的標(biāo)識符（比如一個需求ID）可以很容易地實現(xiàn)這一點，測試用例開發(fā)者在個體測試用例中會引用它。CANoe會自動將該標(biāo)識符復(fù)制到測試記錄中，這樣所有測試用例、測試結(jié)果和需求就可以明確地關(guān)聯(lián)起來（圖4）。

　　[圖4:測試用例和測試結(jié)果由ID明確地引用]

　　分析實際發(fā)生錯誤的原因至少與記錄和評估測試結(jié)果同樣重要。大多數(shù)測試工具都不會提供任何這樣的功能或者僅僅提供不完善的功能。一個重要原因就是錯誤分析經(jīng)常被當(dāng)作開發(fā)者的一項完全獨立的任務(wù)。首先，他們面臨理解測試中檢測到的錯誤并跟蹤其原因的問題。尤其是，當(dāng)測試實驗室報告錯誤時，開發(fā)者常常甚至不能使用測試中用到的系統(tǒng)。

　　因此，會強(qiáng)制要求準(zhǔn)確記錄測試臺上的測試步驟并記錄每一個與DUT間的交互動作，尤其是總線通信。在分析階段，CANoe允許重放和分析任何需要的記錄（日志記錄）。從而有可能在開發(fā)場所使用與測試臺上相同的測試系統(tǒng)并從中受益，因此開發(fā)者可以獨立地重新執(zhí)行錯誤生成測試用例。在很多情況下，甚至是有必要進(jìn)行簡化時（比如為了避免選擇不存在的測量硬件）都可以執(zhí)行相關(guān)測試用例。

　　5 信號抽象和診斷

　　抽象是處理軟件開發(fā)和系統(tǒng)設(shè)計中復(fù)雜度問題時普遍采用的重要方法。也可用它來處理測試。ECU中增長的功能不僅增加了系統(tǒng)的復(fù)雜度，而且需要更加廣泛和復(fù)雜的測試。選擇正確的抽象層組成測試不僅會影響創(chuàng)建測試用例所需要的工作量、進(jìn)而影響成本，而且會影響測試用例的質(zhì)量。就像所有其它軟件組件一樣，測試用例本身也可能會存在錯誤，應(yīng)該在使用之前進(jìn)行檢查。另一方面是必要的維護(hù)任務(wù)，比如適應(yīng)需求的改變和修訂測試用例。

　　信號層抽象是測試ECU功能的常用方法，這也是為什么在ECU中實際的應(yīng)用程序通常會基于信號抽象的原因（圖5）。例如，在一個CAN系統(tǒng)中，ECU交互層提供了信號抽象。這正是CANoe使用交互層的方式；它從網(wǎng)絡(luò)描述包含的信息中將自身參數(shù)化，而網(wǎng)絡(luò)描述也用于創(chuàng)建ECU軟件。這保證了ECU和測試環(huán)境使用相同的抽象層從而在相互間形成最佳的協(xié)調(diào)。

　　同時，信號抽象也表示了——至少在協(xié)議層——殘余總線仿真。比如，它保證周期性信號實際是按周期發(fā)送的。在測試中，ECU是運(yùn)行在有關(guān)總線通信的現(xiàn)實環(huán)境下的。此外，當(dāng)修改了系統(tǒng)通信矩陣時，通?？梢岳^續(xù)使用保持不變的測試用例。對相同的應(yīng)用程序，抽象使得相似項目中的測試用例得到重用。

　　[圖5：信號一方面提供了消息和I/O線路間的抽象，另一方面提供了測試定義和仿真模型間的抽象]

　　在ECU測試中，重要的并不僅僅是信號接口。只有在對ECU進(jìn)行較深層訪問時，對許多ECU功能的測試才會有意義。這樣的訪問是由診斷和標(biāo)定接口提供的，它們通過ECU的現(xiàn)有總線接口接入。使用簡單的消息序列對這些接口進(jìn)行訪問是沒有意義的，因為在通信進(jìn)程下面存在著規(guī)定的協(xié)議。使用合適的診斷和標(biāo)定抽象 會更加便捷和可靠。