目錄

軟件與車輛：高度復雜

測試對象，測試用例和動態測試

測試級別

測試環境

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

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

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

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

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

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

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

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

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

什么是測試對象或被測試系統?

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

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

在下文中，我們將術語“測試對象”和“被測試系統”同義地用于要測試的所有內容。

什么是測試用例?

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

1. 定義如何刺激測試對象的測試數據。

2. 測試對象的期望值，它定義了測試對象在模擬過程中應該假設哪些計算/狀態。

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

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

什么是動態測試?

動態測試是測試對象的執行。大多數人將測試與動態測試聯系在一起。

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

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

什么是測試級別？

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

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

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

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

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

5. 系統資質測試(SYS.5)

當根據ASPICE進行分配時，應該注意：流程期望更多的活動而不僅僅是動態測試。

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

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

單元經常變化，因此單元測試必須經常調整、補充并再次執行。單元測試有兩個主要目標:

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

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

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

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

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

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

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

最重要的是: 經驗表明，大多數軟件錯誤都是在集成測試中發現的。

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

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

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

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

3.信號處理

4. 軟件行為改變參數等方面

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

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

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

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

什么是測試環境？

測試環境就像測試對象及其參與者的訓練場。它應該盡可能接近真實的生產環境，以便測試在與其他玩家、狀態和信號交互時的重要性盡可能高。

在這種情況下，經常會討論在環測試，例如

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

“in- in- loop”之前的術語代表測試對象的類型。“在環”指的是測試對象與模擬生產環境的組件之間的一種特殊類型的交互。在“在環測試”中，環境對測試對象的狀態和計算做出反應。因此，這些測試與開環測試相反，開環測試沒有模擬環境的反應。

與開環測試相比，“在環測試”的優點是更接近真實的生產環境。但是，在環環境的設置更加復雜。

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

這種類型的動態測試可以發現控制策略和邏輯中的錯誤。嵌入式系統的仿真是在同樣仿真的環境模型中執行的。這種非常早期的測試的優點是可以快速檢測到模型構建中已經存在的錯誤，并有可能對其進行修正。

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

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

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

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

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

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

2. 在PC上模擬處理器的虛擬環境中。

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

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

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

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

總結

術語和信息的密集使得一件事很清楚: 背景知識、過程和項目之間的溝通是有效和高效地開發、測試和成功實現嵌入式系統的關鍵。

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

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