目錄

軟件與車輛：高度復雜

測試對象，測試用例和動態(tài)測試

測試級別

測試環(huán)境

無論是MiL、SiL、PiL、HiL、單元測試、軟件測試還是集成測試: 汽車軟件測試的世界有很多技術(shù)術(shù)語，所以可能會出現(xiàn)兩個人在同一個術(shù)語下理解不同的情況。誤解可能會發(fā)生，使有效的合作變得困難——我們也知道類似的情況。讓我們把事情弄清楚一點，從頭開始講。

汽車世界在不斷發(fā)展，“軟件定義的汽車”等新術(shù)語證明了軟件對當今汽車的重要性。

在發(fā)展過程中，以前純粹的機械領(lǐng)域逐漸擴展到包括軟件和數(shù)字功能。汽車的功能和行為現(xiàn)在幾乎完全是通過軟件來實現(xiàn)的。伴隨著這一點，當人們談到軟件時，測試也會立即被提及。但是為什么是軟件和測試呢? 軟件也只能在車上的硬件上運行，它們一起組成了一個ECU(電子控制單元)。這些車輛配備了多達150個ECU，大約有1億行代碼(LOC)。ECU之間相互通信和交互，以實現(xiàn)車輛的特定功能，并使其對客戶具象化。

有這么多編程代碼，還能出什么問題? 讓我們來看一個客戶可以直接體驗的車輛功能示例:在儀表盤中顯示交通標志。它是這樣工作的:

1. 照相機拍攝照片并對其進行評估。
2. 檢測到的交通標志被傳達到一個顯示控制單元，并進行可視化。
3. 此信息同時傳遞給其他控制單元上的其他功能，并進行處理。

所有傳感器、執(zhí)行器和控制單元的連接被稱為網(wǎng)絡(luò)架構(gòu)，該架構(gòu)至少需要三年的時間來開發(fā)一輛汽車，直到準備好量產(chǎn)。所有傳感器、執(zhí)行器和控制單元之間的正確交互自然會塑造車輛的功能和質(zhì)量。為了測試正確的交互作用，必須在多個階段重復和迭代地測試車輛。

最大的挑戰(zhàn)是，汽車的部件往往更多地是作為產(chǎn)品而不是作為項目來開發(fā)的，因此，來自幾個公司和部門的許多人都參與到汽車的創(chuàng)造中來。

總之，這意味著汽車的開發(fā)比人們最初想象的要復雜得多。這一方面是由于組織框架條件，另一方面是由于大量的系統(tǒng)組件具有軟件內(nèi)容。復雜性進一步增加，因為可以通過幾個系統(tǒng)組件的交互來體驗功能。

為了彌補這一切，需要對車輛進行許多測試。測試什么，具體地說，在哪個測試級別上，以及如何進行測試會在后文中提到。

什么是測試對象或被測試系統(tǒng)?

測試對象、被測系統(tǒng)和測試元素通常是同義詞。根據(jù)ISTQB，一個測試對象被非常一般地定義為“待測試的工作產(chǎn)品”。因此，測試對象可以是：

1. 一個單元
2. 幾個軟件部分的集合，
3. 一個完整的軟件程序，
4. 一個控制單元，
5. 幾個控制單元組成的網(wǎng)絡(luò)，
6. 一整輛車，
7. 任何其他被測試的對象

在下文中，我們將術(shù)語“測試對象”和“被測試系統(tǒng)”同義地用于要測試的所有內(nèi)容。

什么是測試用例?

一個測試用例總是至少包含以下兩部分信息:

1. 定義如何刺激測試對象的測試數(shù)據(jù)。

2. 測試對象的期望值，它定義了測試對象在模擬過程中應(yīng)該假設(shè)哪些計算/狀態(tài)。

而且可以選擇用進一步的相關(guān)信息來豐富測試用例。測試對象“ECU”的典型前提條件:ECU處于喚醒狀態(tài)并準備接收消息。

測試數(shù)據(jù)和期望值是所有測試級別的測試用例和以這種形式執(zhí)行的測試用例所需要的。期望值是由各種各樣的信息來源給出的——也稱為測試預言。測試預言可以是現(xiàn)有的系統(tǒng)(作為基準)、規(guī)范或個人的專業(yè)知識。在任何情況下，被測試的代碼都不應(yīng)該作為信息的來源。

什么是動態(tài)測試?

動態(tài)測試是測試對象的執(zhí)行。大多數(shù)人將測試與動態(tài)測試聯(lián)系在一起。

在動態(tài)測試中，創(chuàng)建并執(zhí)行測試用例，用測試數(shù)據(jù)刺激測試對象。刺激導致測試對象要么執(zhí)行計算，要么改變其狀態(tài)。在動態(tài)測試中記錄測試對象的反應(yīng)，并與期望值進行比較。如果反應(yīng)與期望相等，則認為測試用例已通過。如果不相等，就認為失敗了。

與動態(tài)測試相對的是靜態(tài)測試。在靜態(tài)測試中，測試對象不是模擬的，而是靜態(tài)分析的。靜態(tài)測試的一個例子是源代碼文件的審查。

什么是測試級別？

ASPICE間接地將測試級別分配給它的過程模型，并包含以下五個過程:

1.軟件單元驗證(SWE.4)

2. 軟件集成與集成測試(SWE.5)

3. 軟件資質(zhì)測試(SWE.6)

4. 系統(tǒng)集成與集成測試(SYS.4)

5. 系統(tǒng)資質(zhì)測試(SYS.5)

當根據(jù)ASPICE進行分配時，應(yīng)該注意：流程期望更多的活動而不僅僅是動態(tài)測試。

但是測試用例實際上是在哪個測試級別上執(zhí)行的，目的又是什么?我們從最小的層級開始:編碼。這些是最早可以測試的測試對象。

軟件編程之后是與開發(fā)相關(guān)的單元測試。它們也被稱為模塊測試、功能測試或單元測試。在單元測試中，測試最小的軟件組件，即單元。

單元經(jīng)常變化，因此單元測試必須經(jīng)常調(diào)整、補充并再次執(zhí)行。單元測試有兩個主要目標:

1. 早期質(zhì)量保證
2. 快速檢測代碼更改中的交叉影響

單元測試通常是軟件開發(fā)中首先自動化的。

因為軟件或軟件組件是永久地調(diào)整和更改的，所以在持續(xù)集成方法框架內(nèi)的一致性是非常有用的，并且已經(jīng)建立起來了。無論測試級別如何，測試的重復總是被稱為回歸測試，并且在ASPICE中，軟件單元驗證是必需的。實現(xiàn)回歸測試的最簡單方法是自動化測試并在持續(xù)集成環(huán)境中執(zhí)行它們。

單元測試之后是軟件集成測試。集成是單個軟件組件的組裝及其測試。這里的重點是軟件組件之間的兼容性。集成測試通常分幾個階段進行。根據(jù)整個軟件的程度，在幾個中間階段到幾百個中間階段之間提供集成測試。中間階段的數(shù)量和選擇最終取決于軟件體系結(jié)構(gòu)和軟件設(shè)計。元素和級別越多，集成測試的中間階段就越多。

通常，集成測試是自底向上開發(fā)的，首先相互集成和測試幾個單元(大約3-5個)。然后，所得到的復合體與其他已經(jīng)測試過的復合體或其他單元集成在下一個中間階段，并再次測試。這個迭代鏈一直持續(xù)到ECU的整個軟件被構(gòu)建和測試完畢。

大量的集成測試一開始聽起來工作量很大，但它有一個明顯的優(yōu)勢，就是可以更快更好地發(fā)現(xiàn)錯誤。在我們的經(jīng)驗中，在集成測試中建立一個額外的中間階段所需要的工作，可在最初建立測試階段時，通過減少創(chuàng)建測試用例所需的工作來得到補償。

還有什么是支持集成測試的? 發(fā)現(xiàn)的錯誤可以更容易地縮小到其原因，從而大大簡化了分析。

最重要的是: 經(jīng)驗表明，大多數(shù)軟件錯誤都是在集成測試中發(fā)現(xiàn)的。

對于那些還不相信的人來說，任何持續(xù)集成方法都提供了這些測試階段。

集成測試完成后，軟件測試緊隨其后，軟件測試通常在目標硬件上執(zhí)行。軟件測試中的測試對象與集成測試中的最后一個測試對象相同:它是完全集成的軟件。然而，它們各自的目的將兩個測試級別彼此區(qū)分開來。

1.集成測試的目的:檢查軟件組件之間的兼容性。

2. 軟件測試目標:檢查軟件是否符合要求，例如與傳感器和執(zhí)行器的兼容性，

3.信號處理

4. 軟件行為改變參數(shù)等方面

軟件測試之后是進一步的集成測試。但是，這一次不是在軟件級別，而是在系統(tǒng)組件級別。該過程與軟件集成測試相同。ECU與一個或多個傳感器或執(zhí)行器一起測試，然后一點一點地添加其他組件，直到系統(tǒng)就位。

最后的測試在系統(tǒng)測試中進行。在此過程中，將所有系統(tǒng)組件集成到一個系統(tǒng)中并進行測試。系統(tǒng)測試的重點是確定是否符合系統(tǒng)需求和系統(tǒng)的可交付性。

在汽車開發(fā)中，現(xiàn)在有一些額外的組織挑戰(zhàn)，例如: 什么是系統(tǒng)? 對于汽車OEM來說，它就是一輛車。但是，提供子系統(tǒng)(如動力系統(tǒng)或軟件組件)的供應(yīng)商如何回答這個問題呢? 在這種情況下，必須為測試階段更緊密地指定測試對象。

從合同的角度來看，還有一個進一步的測試階段: 驗收測試，由客戶進行。從合同的角度來看，驗收是對開發(fā)(軟件、硬件、系統(tǒng)等)符合合同標準的聲明。驗收合格后，剩余款項到期，保修開始。

什么是測試環(huán)境？

測試環(huán)境就像測試對象及其參與者的訓練場。它應(yīng)該盡可能接近真實的生產(chǎn)環(huán)境，以便測試在與其他玩家、狀態(tài)和信號交互時的重要性盡可能高。

在這種情況下，經(jīng)常會討論在環(huán)測試，例如

1. 模型在環(huán)（Model-in-the-loop，MiL）
2. 軟件在環(huán)（Software-in-the-loop，SiL）
3. 處理器在環(huán)（Processor-in-the-loop，PiL）
4. 硬件在環(huán)（Hardware-in-the-loop，HiL）

“in- in- loop”之前的術(shù)語代表測試對象的類型。“在環(huán)”指的是測試對象與模擬生產(chǎn)環(huán)境的組件之間的一種特殊類型的交互。在“在環(huán)測試”中，環(huán)境對測試對象的狀態(tài)和計算做出反應(yīng)。因此，這些測試與開環(huán)測試相反，開環(huán)測試沒有模擬環(huán)境的反應(yīng)。

與開環(huán)測試相比，“在環(huán)測試”的優(yōu)點是更接近真實的生產(chǎn)環(huán)境。但是，在環(huán)環(huán)境的設(shè)置更加復雜。

在汽車環(huán)境中，開發(fā)通常是基于模型的。大多數(shù)模型是用MATLAB/Simulink或TargetLink創(chuàng)建的。這些模型通常在開發(fā)環(huán)境中直接以單元和軟件集成測試的形式作為模型在環(huán)(MiL)進行驗證。

這種類型的動態(tài)測試可以發(fā)現(xiàn)控制策略和邏輯中的錯誤。嵌入式系統(tǒng)的仿真是在同樣仿真的環(huán)境模型中執(zhí)行的。這種非常早期的測試的優(yōu)點是可以快速檢測到模型構(gòu)建中已經(jīng)存在的錯誤，并有可能對其進行修正。

在軟件在環(huán)測試（SiL）中，測試代碼是在PC上測試的。這要么是手寫的，要么是從模型生成的。這兩種代碼的作用域是不同的。

1.測試生成的代碼:檢查代碼生成器是否正常工作。生成的代碼的功能應(yīng)該盡可能接近模型。

2.對于手動代碼，SiL是第一個可能的測試級別。與MiL一樣，目標是在早期階段發(fā)現(xiàn)錯誤。

SiL用于測試階段的單元測試、集成測試，在某些情況下也用于軟件測試。硬件在這個階段還不適用。

在SiL中測試的代碼不能在嵌入式ECU上執(zhí)行。為了執(zhí)行，必須為目標處理器編譯代碼。在這個過程中生成的代碼可以通過兩種方式進行測試:

1. 通過一個評估板與有未來目標環(huán)境的處理器。

2. 在PC上模擬處理器的虛擬環(huán)境中。

在這兩種情況下，都提到了處理器在環(huán)(PiL)，實際上是指為目標處理器架構(gòu)構(gòu)建的軟件測試。嚴格地說，測試階段因此也可以稱為目標軟件在環(huán)。

處理器在環(huán)測試的主要目標是檢測編譯器錯誤，或者在軟件組件非常接近硬件的情況下，例如驅(qū)動程序或執(zhí)行器的控制，在早期階段檢查硬件和軟件組件的兼容性。

下一個邏輯步驟是測試硬件: 也就是說，在帶有外圍設(shè)備的物理ECU上完成軟件。現(xiàn)在的重點是輸入和輸出、通信總線和其他接口如何實時交互。這種測試的術(shù)語是硬件在環(huán)(Hardware-in-the-Loop，HiL)。HiL測試從ECU開始，可以實現(xiàn)到系統(tǒng)網(wǎng)絡(luò)級別。HiL試驗臺架可以對整車進行測試，但設(shè)置和操作成本相應(yīng)較高。盡管如此，他們還是很成熟的，因為進行手動車輛測試也很昂貴，而且更費時。

在車輛測試中，ecu、執(zhí)行器和傳感器組件在最終目標環(huán)境中進行測試。車輛大多在寒冷、溫暖和炎熱地區(qū)的不同環(huán)境條件下進行測試。即使在今天，這些測試也主要是手動執(zhí)行的。在某些情況下，測量結(jié)果會被自動記錄，然后在工具的幫助下進行評估。這個測試階段發(fā)生在每個OEM。要進行車輛測試，車輛及其所有部件必須可用。然而，由于手動測試需要訓練有素的司機和車輛，測試的可擴展性較差。

總結(jié)

術(shù)語和信息的密集使得一件事很清楚: 背景知識、過程和項目之間的溝通是有效和高效地開發(fā)、測試和成功實現(xiàn)嵌入式系統(tǒng)的關(guān)鍵。

在汽車軟件測試中，有許多方法和方法，在我們看來，沒有對與錯，而是有利與不利。當然，這取決于各種參數(shù)，涉及的組織，最終取決于一起工作的人。

我們是早期測試的支持者，我們建議直接從單元測試級別開始。進一步說到集成測試，可以測試不同的功能以獲得開發(fā)的直接反饋。所有這些都導致了快速、合作的產(chǎn)品開發(fā)。