999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

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

2024-12-31 00:00:00胡宇迪付朝輝蔡偉杰馬玉霞路哲田懷志
汽車電器 2024年8期

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

【關鍵詞】軟件測試;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)的車身應用層軟件在開發完成后,需要依照功能需求來對軟件中包含的功能邏輯進行測試。SOA主要實現了軟件硬件的解構,所以常規想完成硬件在環測試,需要等待硬件成熟后才可以開展,并不符合實際的情況。從應用層軟件開始第一版交付到實際車輛量產的這段時間內,可測試的時間非常有限,需要一種測試方法盡早去對功能覆蓋進行測試,以便能提高所交付軟件的品質。軟件在環測試(Software-in-the-Loop,SIL)作為一種創新的測試方法,能夠更好地應對此挑戰,通過軟件模擬測試數據,盡早地開始服務相關的業務與算法驗證,提前開展測試工作。

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

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

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

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

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

2.1" 軟件在環測試的接口信息處理

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

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

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

2.2" 軟件在環測試的執行

2.2.1" 測試原理簡述

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

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

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

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

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

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

2.2.3" 測試腳本的開發

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

3" 軟件在環測試在實際應用中所具備的優勢淺析

3.1" 測試成本降低

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

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

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

3.2" 測試時間增加

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

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

3.3" 軟件品質提高

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

4" 結束語

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

參考文獻:

[1] 周芹. 基于SOA的車身控制器設計[J]. 汽車電器,2023(1):43-44.

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

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

(編輯" 凌" 波)

主站蜘蛛池模板: 欧美激情网址| 欧美亚洲国产视频| 久久五月天综合| 国产在线欧美| 欧美成人区| jizz亚洲高清在线观看| 日本道综合一本久久久88| 国产精品夜夜嗨视频免费视频| 在线日韩一区二区| 国产精品无码AV片在线观看播放| 99视频精品全国免费品| 人人妻人人澡人人爽欧美一区| 99久久精品国产自免费| 欧美在线视频a| 久久精品66| 欧美精品xx| 亚洲精品无码AⅤ片青青在线观看| 国产精品一区在线麻豆| 狠狠v日韩v欧美v| 亚洲最大福利视频网| 这里只有精品国产| 国产日韩久久久久无码精品| 999国产精品| 曰AV在线无码| 激情乱人伦| 人人艹人人爽| 中文字幕 日韩 欧美| 国产99在线观看| 欧美A级V片在线观看| 亚洲二区视频| 免费 国产 无码久久久| www亚洲天堂| 亚洲国产天堂久久九九九| www亚洲天堂| 手机在线看片不卡中文字幕| 亚瑟天堂久久一区二区影院| 亚洲婷婷六月| 亚洲无线一二三四区男男| 亚洲精品欧美日本中文字幕 | 欧美亚洲国产一区| 免费看美女自慰的网站| 国产亚洲视频播放9000| 亚洲中文精品久久久久久不卡| 国产成人精品在线1区| 亚洲另类色| 亚洲女同欧美在线| 色婷婷亚洲综合五月| 丁香婷婷在线视频| 亚洲不卡影院| 91精品小视频| 日韩天堂视频| 亚洲不卡无码av中文字幕| 久青草免费在线视频| 国产a v无码专区亚洲av| 天堂网亚洲系列亚洲系列| 国产成人91精品| 99在线视频精品| 亚洲男人天堂久久| 亚洲欧美日韩色图| 国产成人三级| 免费jjzz在在线播放国产| 五月天在线网站| 欧美在线一二区| 91成人免费观看在线观看| 日本三级欧美三级| 亚洲福利网址| 亚洲国产AV无码综合原创| 2021亚洲精品不卡a| 日韩a在线观看免费观看| 97在线国产视频| 国产麻豆va精品视频| 欧美伦理一区| 成人日韩精品| 99久久精品视香蕉蕉| 19国产精品麻豆免费观看| 一级一级特黄女人精品毛片| 99热这里只有精品国产99| 成人在线亚洲| 欧美激情视频二区| 久久精品电影| 国产福利拍拍拍| 91激情视频|