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

【關(guān)鍵詞】軟件測(cè)試；SIL；SOA；汽車軟件；測(cè)試方法

中圖分類號(hào)：U463.6" " 文獻(xiàn)標(biāo)識(shí)碼：A" " 文章編號(hào)：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，F(xiàn)U 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

作者簡(jiǎn)介

胡宇迪（1999—），男，碩士，車身軟件測(cè)試工程師，研究方向?yàn)槠囯娮樱饕獜氖萝嚿碥浖﨟IL/SIL測(cè)試的工作。

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

1" SOA架構(gòu)在汽車軟件開發(fā)中的應(yīng)用

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

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

2" 軟件在環(huán)測(cè)試基于SOA架構(gòu)汽車軟件中的實(shí)際應(yīng)用

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

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

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

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

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

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

2.2.1" 測(cè)試原理簡(jiǎn)述

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

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

2.2.2" 測(cè)試用例設(shè)計(jì)與測(cè)試流程簡(jiǎn)述

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

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

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

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

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

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

3.1" 測(cè)試成本降低

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

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

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

3.2" 測(cè)試時(shí)間增加

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

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

3.3" 軟件品質(zhì)提高

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

4" 結(jié)束語

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

參考文獻(xiàn)：

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

[2] 李毅，顧健，顧鐵軍. 面向服務(wù)軟件架構(gòu)中的軟件測(cè)試[C]//全國計(jì)算機(jī)安全學(xué)術(shù)交流會(huì)論文集（第二十三卷）. 北京：中國科學(xué)技術(shù)大學(xué)出版社，2008：142-143.

[3] 柴華，劉建峰，顧強(qiáng)源，等. 一種應(yīng)用SOA汽車音樂燈光秀功能實(shí)現(xiàn)方案[J]. 汽車電器，2023（2）：16-18.

（編輯" 凌" 波）