軟件在環(huán)測試理念在基于SOA架構汽車軟件測試中的應用探索

【摘" 要】文章旨在探討SIL在搭載了面向服務架構SOA汽車軟件功能測試中的應用，并重點關注軟件在環(huán)測試在早期測試階段的優(yōu)勢，包括對軟件缺陷的提前發(fā)現和解決，以及搭建SIL臺架所能節(jié)省的成本等，期望能在實際工程應用中，可以進一步縮短整體軟件開發(fā)周期，提高軟件測試的效率，提升軟件品質。

【關鍵詞】軟件測試；SIL；SOA；汽車軟件；測試方法

中圖分類號：U463.6" " 文獻標識碼：A" " 文章編號：1003-8639（ 2024 ）08-0087-04

Exploration of the Application of Software in the Environment Testing Concept in

Automotive Software Testing Based on SOA Architecture

HU Yudi1，FU Zhaohui2，CAI Weijie2，MA Yuxia2，LU Zhe2，TIAN Huaizhi2

（1.Tongji University School of Automotive Studies，Shanghai 201804；

2.Geely Automotive Research Institute（Ningbo）Co.，Ltd.，Cixi 315315，China）

【Abstract】The article aims to explore the application of SIL in functional testing of automotive software equipped with SOA，and focuses on the advantages of software in the environment testing in the early testing stage，including early detection and resolution of software defects，as well as the cost savings of building a SIL platform. It is expected that in practical engineering applications，it can further shorten the overall software development cycle，improve the efficiency of software testing，and enhance software quality.

【Key words】software testing；SIL；SOA；automotive software；test method

作者簡介

胡宇迪（1999—），男，碩士，車身軟件測試工程師，研究方向為汽車電子，主要從事車身軟件HIL/SIL測試的工作。

基于服務架構SOA（Service-Oriented Architecture）的車身應用層軟件在開發(fā)完成后，需要依照功能需求來對軟件中包含的功能邏輯進行測試。SOA主要實現了軟件硬件的解構，所以常規(guī)想完成硬件在環(huán)測試，需要等待硬件成熟后才可以開展，并不符合實際的情況。從應用層軟件開始第一版交付到實際車輛量產的這段時間內，可測試的時間非常有限，需要一種測試方法盡早去對功能覆蓋進行測試，以便能提高所交付軟件的品質。軟件在環(huán)測試（Software-in-the-Loop，SIL）作為一種創(chuàng)新的測試方法，能夠更好地應對此挑戰(zhàn)，通過軟件模擬測試數據，盡早地開始服務相關的業(yè)務與算法驗證，提前開展測試工作。

1" SOA架構在汽車軟件開發(fā)中的應用

SOA是一種以服務為中心的分布式體系結構，具有集成、可伸縮性和安全性的優(yōu)勢，其核心思想是將復雜的應用程序劃分為一系列松散耦合的服務，每個服務代表一個特定的業(yè)務功能。這些服務通過標準化的接口進行通信，可以被獨立開發(fā)、部署和管理。SOA通過提供松散耦合的組件和服務重用，提高了應用程序的靈活性、可擴展性和可維護性。當下汽車行業(yè)隨著智能化的發(fā)展，軟件定義汽車已經成為必然趨勢，當下汽車軟件需要快速升級并具備良好的可移植性，因此從架構層面基于SOA開發(fā)具有一定的優(yōu)勢。在進行軟件開發(fā)時，設立由中央計算單元和區(qū)域控制組成的中央集中式架構，將功能根據粒度大小封裝成不同的原子服務，在功能交互的過程中，雙方不需要考慮對方的協議，只需以標準服務接口來調用[1]。相比于基于信號的應用功能實現需要通信的建立、傳參前需預處理等前置操作，基于服務的應用功能實現只需要發(fā)送任意一個服務的調用即可實現，因此更加方便、高效。

在實際的汽車軟件開發(fā)中，為了提高開發(fā)的便利性，通常選擇在本地電腦端進行應用程序的開發(fā)，而最終汽車軟件運行的硬件架構并非一定與開發(fā)端一致。為了確保生成的可執(zhí)行文件在目標終端上具備可用性，采用了交叉編譯（Cross-compile）的方法，其工作原理如圖1所示。通過這種方法，在一個平臺上編譯生成適用于不同硬件架構的程序文件，從而使得同一份應用代碼可以在固定的編譯環(huán)境中與多種目標編譯器配合使用，最終可生成在多種不同平臺上運行的可執(zhí)行文件。這種技術的應用使得汽車軟件開發(fā)更加靈活和高效，為開發(fā)人員提供了跨平臺開發(fā)的便利性，同時確保了軟件在各種目標終端上的兼容性與可用性。

2" 軟件在環(huán)測試基于SOA架構汽車軟件中的實際應用

SIL用于驗證和評估嵌入式系統(tǒng)中的軟件功能和性能，在測試過程中，被測試的軟件在虛擬環(huán)境中與其他系統(tǒng)組件進行交互，以模擬真實的運行環(huán)境并對其進行測試，整個過程對硬件沒有依賴。

2.1" 軟件在環(huán)測試的接口信息處理

開展軟件在環(huán)測試，首先確定測試用例及功能需求中涉及需要被仿真的輸入接口以及輸出接口的相關信息，在生成軟件得以運行的最終可執(zhí)行二進制文件之前，只有引入相應接口信息的代碼參與構建，才能在軟件保持在環(huán)運行過程中從外界輸入所模擬的數據，否則軟件將一直保持獨立在環(huán)運行的狀態(tài)，無法與外界產生交互，功能也無法被測試。

對所處理的接口，共分為兩種：第1種作為觸發(fā)功能邏輯的輸入接口，在測試用例中體現為前提條件和測試步驟，只有當輸入條件全部滿足時，功能邏輯才會被觸發(fā)；第2種為觸發(fā)功能邏輯之后從被測軟件反饋回測試系統(tǒng)的輸出接口，在功能邏輯實現正常的情況下，在測試用例中體現為預期結果。需求接口信息處理示意如圖2所示。

使用與SOA應用層源碼相同的代碼語言，將對應的數據（所有涉及到的接口信息）封裝成相應的頭文件，并配置通信管理模塊（Communication Management，CM），使后期被測件與測試系統(tǒng)可以保持連接狀態(tài)，同時為保證測試系統(tǒng)中所裝載的測試用例涉及的輸入、輸出信號可以與封裝后的接口相匹配，需要確保雙方接口所屬的子系統(tǒng)結構、相應的數據類型、內部的成員枚舉信息完全一致。

2.2" 軟件在環(huán)測試的執(zhí)行

2.2.1" 測試原理簡述

對于具備硬件ECU的硬件在環(huán)測試而言，即便開發(fā)終端與運行終端之間架構不一致，只需在硬件成熟后模擬硬件ECU上引腳輸入的信號即可完成測試任務，軟件的運行環(huán)境本身不存在阻礙點。而對于軟件在環(huán)測試而言，不存在硬件ECU這一組成部分，需要引入硬件模擬器來作為軟件的實際運行終端。自動化測試系統(tǒng)通過TCP/IP通信協議與硬件模擬器軟件系統(tǒng)連接，并讀取編寫完成的測試用例。如圖3所示，建立內部局域網1，通過達成一致的IPV6通信協議，使硬件模擬器可以與其運行環(huán)境進行數據交互，通過接口將測試用例中提到的車輛模式及用戶模式等前提條件和激活車燈、雨刮、天窗等車身應用功能開啟的觸發(fā)條件等輸入信號傳入被測軟件，參與到功能邏輯的運行中。同時，在硬件模擬器運行環(huán)境與軟件測試系統(tǒng)之間通過無線路由器等傳輸媒介建立內部局域網2，使用硬件模擬器中的物理網絡板卡，使傳輸到硬件模擬器中的數據通過TCP/IP協議傳輸到軟件測試系統(tǒng)中。通過接口將經過功能邏輯運算后的代表功能狀態(tài)的輸出信號（諸如車燈開啟、雨刮電機轉動狀態(tài)、天窗電機轉動狀態(tài)等）傳出被測件，傳入到自動化測試軟件中，與測試用例中的預期結果比較，并進行統(tǒng)計。

在一輪軟件在環(huán)測試中，根據達成一致的通信協議，通過接口將輸入信號傳入被測件，參與到功能邏輯的運行中。通過接口將經過功能邏輯運算后的輸出信號傳出被測件，傳入到自動化測試系統(tǒng)中進行測試情況統(tǒng)計。自動化測試系統(tǒng)通過作為軟件運行載體的硬件模擬系統(tǒng)，向正在運行功能服務的軟件系統(tǒng)發(fā)送當前狀態(tài)下需要模擬的輸入信號。根據之前配置好的模擬接口位置，模擬的輸入信號被傳入程序中各自接口所在的地方，隨著程序的運行，覆蓋掉原先的初始數值。自動化測試系統(tǒng)基于編寫好的測試用例，獲取當前測試用例下所需要的運行數據，不斷調整模擬輸入信號的種類和數值，對正在運行功能服務的軟件系統(tǒng)進行測試，并同時準備下一個運行周期所要模擬的輸入信號。隨著程序在環(huán)運行，程序各個位置的接口新數據因功能需求需要先依照測試用例逐步被傳入，隨后再參與到程序功能的實現之中。當自動化測試系統(tǒng)完成測試用例的同時，相應的預期輸出結果通過運行功能服務的軟件系統(tǒng)傳回自動化測試系統(tǒng)。自動化測試系統(tǒng)通過比對傳回的數據與測試用例中預期結果的差異，得出測試報告。軟件測試系統(tǒng)結構示意如圖4所示。

2.2.2" 測試用例設計與測試流程簡述

對于搭載SOA架構汽車軟件而言，某一功能的觸發(fā)條件均由3個部分組成：①該功能實現的前提條件（Precondition）；②在前提條件滿足情況下的激活操作（Active）；③激活功能后軟件所做的反饋動作（Action）。因此，只有當這3個條件同時滿足，一組功能觸發(fā)才得以觸發(fā)。

在設計測試用例時，為保證功能正常實現與非正常實現，需從正向與反向測試用例兩個維度來開發(fā)。正向測試用例指在軟件功能需求下的所有條件均滿足時，功能被正常觸發(fā)，反向測試用例指系統(tǒng)不支持的輸入或狀態(tài)，在測試中引入非必須條件來檢測功能未被觸發(fā)的情況，這類用例可以檢查系統(tǒng)的容錯能力和可靠性。

以手套箱燈激活打開功能為例，如圖5所示，第1行（使用模式）與第2行（車輛模式）分別代表Precondition，第3行（手套箱激活請求）代表Active，第4行則代表服務功能被激活后Action。通過自動化測試系統(tǒng)，隨著每一輪在環(huán)測試的進行，前3行的3種數據被傳送入正在運行的服務軟件中，當條件滿足時，相應的測試數據就會傳送回自動化測試系統(tǒng)，顯示在第4行。如果是被正確激活，那代表反饋動作的第4行數值會變?yōu)?；若未被正確激活，則為0。通過對每一種功能需求描述的輸入值進行自動化排列組合，來確保對功能場景的全覆蓋，并適當引入不正確的輸入值來檢測功能未被誤觸發(fā)。通過自動化腳本進行排列組合和執(zhí)行的方式，可提高測試效率。

2.2.3" 測試腳本的開發(fā)

在設計腳本時，可以在腳本執(zhí)行之前，把本次測試中所涉及到信號數值的所有情況統(tǒng)一存放在數據庫中，方便程序運行時按序列提取，例如以數組的形式。在腳本程序運行的時候，隨著測試用例序列的進行，使用循環(huán)語句和嵌套語句相結合的方法依次讀取數據庫中存放的數值并寫入到測試步驟中，自動化完成所需排列組合的功能場景。如圖6所示，在腳本執(zhí)行的過程中，在功能激活完成后，使用判斷語句自動處理軟件系統(tǒng)輸出的預期值。在使用腳本進行自動化處理時，一旦測試用例數量龐大，數量眾多的信號端口賦值語句使得腳本編寫的界面可讀性差，從而導致腳本編寫邏輯出錯概率增加。故優(yōu)先使用函數封裝的方法，優(yōu)先使用功能場景來命名函數，從而把“調用函數”這個行為轉化為“執(zhí)行功能操作”這一行為，降低腳本邏輯錯誤的概率?？偠灾瑴y試自動化的主要意義有兩點，一是減少對多種信號數值所需排列組合的工作量，二是減少統(tǒng)計預期結果數據的工作量，尤其是在測試步驟復雜、測試用例數量多的情況下。

3" 軟件在環(huán)測試在實際應用中所具備的優(yōu)勢淺析

3.1" 測試成本降低

軟件在環(huán)測試的應用可以降低測試臺架的搭建成本與人力成本。

硬件在環(huán)測試臺架搭建費用高，且需要搭建人員對線束硬件原理有較高的了解程度，在搭建過程中會出現硬件原料損耗、通信斷路潛在風險等問題。測試場地受環(huán)境限制，至少需要20m2的面積來存放臺架。測試人員需要了解線束硬件的相關理論知識，從而應對由于操作不熟練導致試驗臺架出現短路故障的情況，并需要排查軟件出現邏輯錯誤時，確認該錯誤是否是硬件本身存在通斷錯誤而引入的。

而軟件在環(huán)測試方案，不依托硬件條件，依托現有公開的硬件模擬器軟件，模擬出目標終端的軟件運行環(huán)境，保持被測件和測試工具通信后，直接通過外部引入條件相關接口數據去觸發(fā)功能邏輯，無需購買硬件，無需考慮線束原理要求。在成本方面，以目前市面上較為知名的德國Vector公司出品的VT system硬件在環(huán)測試系統(tǒng)為例，搭建一個虛擬臺架，預計可節(jié)省50萬元的硬件臺架搭建費用以及相應的測試工程師人員投入。這在早期開發(fā)階段和大規(guī)模不同種軟件的測試中降低了測試成本。

3.2" 測試時間增加

對于硬件在環(huán)測試，在軟件開發(fā)周期的前期花費時間占比較大，硬件ECU成熟后距離車輛量產節(jié)點較近，可供測試時間緊張。在功能層面依托硬件進行測試，如果出現軟件邏輯驗證不通過，需要排查的因素較多，包括被測硬件本身老化、線路通斷問題、軟件集成是否疏漏等。

采用軟件在環(huán)測試方案，在實際硬件設備準備好之前便可進行，因此在開發(fā)周期的早期階段可開展進行測試，及早發(fā)現和解決軟件缺陷和問題，并反饋給軟件開發(fā)人員，提高開發(fā)效率，降低后期修復成本，一輪軟件迭代可減少3個工作日。在硬件ECU交樣之前通過搭建軟件虛擬環(huán)境，此時間節(jié)點預計到車輛量產時間節(jié)點之間的測試時間充足，有利于發(fā)現潛在問題并修復。

3.3" 軟件品質提高

在完成接口信息的處理工作后，將新引入的接口放置在源代碼中，位于用來實現功能邏輯的同名接口首次被調用的位置。由于軟件在環(huán)測試是基于功能驗證的黑盒測試，關注點在于被測軟件最終的功能實現而非單元測試這類基于代碼覆蓋率與功能單元局部實現的白盒測試。軟件在環(huán)測試可以將需要接入的測試接口放置于任意代碼中某變量所在的地方，以便在排查問題時更方便定位問題發(fā)生的位置，提高軟件排查問題的效率，從而提高測試顆粒度，進一步提升軟件品質。

4" 結束語

本文提出的測試技術較為新穎，可以在硬件成熟之前開展功能測試，爭取更多的測試時間，減少后期修復軟件邏輯錯誤所耗費的工時，也能避免后期因工期緊張導致測試覆蓋不全面的情況。但同時也應注意，該測試方案屬于接口測試，和搭載真實負載的硬件在環(huán)測試相比，在需求覆蓋度這一維度尚存在一定距離。輸出的測試報告能作為輔助評判功能需求實現的依據，但不可作為唯一的依據。在實際工程應用中，將兩者同時結合，可以進一步縮短整體軟件開發(fā)周期，提高軟件測試的效率，提升軟件的品質，更進一步做到敏捷開發(fā)。

參考文獻：

[1] 周芹. 基于SOA的車身控制器設計[J]. 汽車電器，2023（1）：43-44.

[2] 李毅，顧健，顧鐵軍. 面向服務軟件架構中的軟件測試[C]//全國計算機安全學術交流會論文集（第二十三卷）. 北京：中國科學技術大學出版社，2008：142-143.

[3] 柴華，劉建峰，顧強源，等. 一種應用SOA汽車音樂燈光秀功能實現方案[J]. 汽車電器，2023（2）：16-18.

（編輯" 凌" 波）