作者 | 冰糖葡萄皮

小編 | 吃不飽

上篇我們介紹了被測對象、動態測試和測試用例的概念，還提出了如何省時省力評估自動生成的測試用例的話題。事實上TPT能夠實現測試用例和評估解耦，為每條用例/多條用例創建符合其場景的測試評估：可以通過GUI界面來進行信號對比、事件查詢、信號邊界檢查、信號序列的正確性判斷以及信號調理；也可以通過腳本語言實現復雜場景的評估。本文會介紹測試級別和測試環境，并帶大家進一步了解模型動態測試工具——TPT。

什么是測試級別

ASPICE定義了以下五個測試級別：1. 軟件單元測試(SWE.4)2. 軟件集成與集成測試(SWE.5)3. 軟件合格性測試(SWE.6)4. 系統集成與集成測試(SYS.4)5. 系統合格性測試(SYS.5)01軟件單元測試
軟件單元測試也被稱為模塊測試或功能測試。在單元測試中，測試對象是最小的軟件組件，即單元。單元經常變化，因此單元測試必須經常調整、補充并再次執行。單元測試有兩個主要目標：
1. 早期質量保證2. 快速檢測模型/代碼更改中的交叉影響因為軟件或軟件組件是永久地調整和更改的，并且后續的回歸測試也總是充滿了重復性，因此最簡單的方法是在持續集成環境中自動化執行單元測試。TPT可以通過與Jenkins的集成實現自動化測試，提高測試效率。主要可實現的功能包括：基于TPT的Jenkins節點環境導入測試接口；自動生成TPT測試框架；自動執行TPT工程測試用例；自動生成測試報告。用Jenkins自動執行測試工程代替測試工程師手動執行，既能縮短測試周期，又能避免重復性勞動。

圖1. Jenkins端TPT測試結果

02軟件集成與集成測試
單元測試之后是軟件集成測試。軟件集成是單個軟件組件的組裝，這里的重點是測試軟件組件之間的兼容性。集成測試通常分幾個階段進行，根據整個軟件的結構，在幾個中間階段到幾百個中間階段之間提供集成測試。中間階段的數量和選擇最終取決于軟件體系結構和軟件設計。元素和級別越多，集成測試的中間階段就越多。通常，集成測試是自下向上開發的，首先集成和測試幾個單元(大約3-5個)。然后，所得到的單元組合與其他已經測試過的單元組合或其他單元集成在下一個中間階段，并再次測試。這個迭代鏈一直持續到ECU的整個軟件被構建和測試完畢。

圖2. 集成測試迭代圖
大量的集成測試一開始聽起來工作量很大，但它有一個明顯的優勢，就是可以更快更好地發現錯誤。而在TPT中，單元的測試用例能夠一定程度上復用到集成測試，為用戶減少集成測試階段的工作量。在《單元測試用例復用到集成測試？Testlet Library來助力！》一文中介紹了詳細操作方法。集成測試的另一大優勢在于，集成測試階段發現的錯誤可以更容易地定位到其原因，從而大大簡化了問題分析。經驗表明，大多數軟件錯誤都是在集成測試中發現的。

03軟件合格性測試
集成測試完成后，軟件合格性測試緊隨其后。軟件合格性測試通常在目標硬件上執行。軟件合格性測試中的測試對象與集成測試中的最后一個測試對象相同:它是完全集成的軟件。然而，它們各自的目的不同：

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

軟件合格性測試目的：檢查軟件是否符合要求，例如與傳感器和執行器的兼容性。

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

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

什么是測試環境

測試環境是指執行測試所需要的環境，包括硬件、儀器、模擬器、軟件工具和其他支持要素。測試環境應該盡可能接近真實的生產環境，以便更準確地模擬實際環境中的操作和運行情況，從而確保軟件在生產環境中的可靠性和穩定性。在這種情況下，我們經常會討論在環測試，例如：模型在環（Model-in-the-loop ，MiL）軟件在環（Software-in-the-loop ，SiL）處理器在環（Processor-in-the-loop ，PiL）硬件在環（Hardware-in-the-loop ，HiL）“在環”指的是測試對象與模擬生產環境的組件之間的一種特殊類型的交互。在“在環測試”中，環境對測試對象的狀態和計算做出反應。TPT可以靈活適應于MiL/SiL/PiL/HiL/ViL整個在環測試階段，并且支持各階段的開發平臺。

圖3. TPT在環測試支持平臺總覽
現代新能源汽車軟件的開發往往基于模型，而大多數模型是用MATLAB/Simulink/TargetLink或ASCET創建的。這些模型通常在開發環境中直接以單元和軟件集成的形式作為模型在環(MiL)進行驗證。這種類型的動態測試可以發現控制策略和邏輯中的錯誤。嵌入式系統的仿真是在同樣仿真的環境模型中執行的。這種非常早期的測試的優點是可以快速檢測到模型構建中已經存在的錯誤，并有可能對其進行修正。

模型在環-MiL

TPT在MiL環境能夠自動從Simulink、TargetLink及ASCET模型獲取接口信息并生成測試框架，通過測試框架將測試用例定義的輸入信號激勵給到被測模型，再回采被測模型的輸出結果并對其進行評估，整個過程由TPT自動完成，無需用戶自定義。

圖4. 基于MATLAB/Simulink的TPT MiL測試過程

軟件在環-SiL

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

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

手寫代碼：SiL可能是第一個測試級別。與MiL一樣，目標是在早期階段發現錯誤。

對于第1種模型生成的代碼，為了驗證生成的代碼與原模型的等效性，應當進行背靠背測試。在TPT中，背靠背測試尤為便捷。以Simulink模型為例，用戶只需要點擊FUSION DLL就能調用Simulink生成代碼，并且一鍵生成SiL測試平臺，同時運行MiL和SiL平臺，還能自動實現對兩個平臺測試數據的對比，完成等效性驗證。

處理器在環-PiL

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

1. 通過調試器與目標芯片環境。

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

在這兩種情況下，都提到了處理器在環(PiL)，實際上是指為目標處理器架構構建的軟件測試。處理器在環測試的主要目標是檢測編譯器錯誤，或者在軟件組件非常接近硬件的情況下，例如驅動程序或執行器的控制，在早期階段檢查硬件和軟件組件的兼容性。在《PiL測試實戰（上）| 單元級代碼的PiL測試》一文中介紹了TPT做PiL測試的解決方案。簡單來說，TPT將測試用例數據發送到UDE，并讀取UDE從目標板讀到的輸出信號數據進行評估。這個過程中可以直接復用MiL/SiL環境的測試用例，單元級軟件測試可實現同一測試工程覆蓋MiL/SiL/PiL所有階段。

圖6. TPT+UDE PiL測試方案

硬件在環-HiL

下一個邏輯步驟是硬件測試，即在帶有外圍設備的物理ECU上完成軟件測試，重點是輸入和輸出、通信總線和其他接口如何實時交互。這種測試的術語是硬件在環(Hardware-in-the-Loop ，HiL)。HiL測試從ECU開始，可以實現到系統網絡級別。

圖7. TPT與VECTOR CANoe集成TPT支持通過XiL-API接口與HiL設備進行集成，包括：VT System、dSPACE、NI Veristand、Concurrent iHawk、Speedgoat。可以發送測試用例到HiL設備執行，接受測試數據進行評估，支持實時測試、故障注入，也可以通過CANape/INCA對ECU進行標定和測量。

05總結
在汽車軟件測試中，有許多術語和方法。在我們看來，掌握這些背景知識、合理運用測試工具和測試方法，是成功實現嵌入式系統測試的關鍵。本文帶大家從工具的層面出發，介紹了TPT在不同測試級別和測試環境中的作用。北匯信息之前也發布了許多測試方法、實踐經驗等文章，歡迎大家訂閱，并留言與我們交流！