基于持續(xù)測試技術(shù)的整車控制器測試平臺研究

陳振宇,秦 琴,丁 鋒,吳 輝

(1.上海第二工業(yè)大學(xué) 智能制造與控制工程學(xué)院,上海 201209;2.聯(lián)合汽車電子有限公司,上海 201206)

0 引言

隨著敏捷和DevOps開發(fā)模式在軟件行業(yè)的推廣落地,更頻繁的交付加重了業(yè)界對測試的擔(dān)憂,測試不夠高效往往成為導(dǎo)致交付延期的首要原因,測試環(huán)節(jié)也成為了企業(yè)進(jìn)行DevOps轉(zhuǎn)型的最大瓶頸。為了應(yīng)對這種挑戰(zhàn),“持續(xù)測試”概念逐漸被汽車行業(yè)廣泛接受[1]。目前,新能源汽車整車控制器的測試領(lǐng)域主要存在以下兩大難題。第1個(gè)難題是使用自動測試平臺測試整車控制器,測試過程仍需測試工程師手工參與。測試工程師需要提前對測試環(huán)境進(jìn)行配置,然后從測試腳本管理庫中篩選測試腳本,并將其放置在測試環(huán)境中,最后觸發(fā)自動測試[2-3]。不同的測試內(nèi)容需要測試工程師不斷地篩選測試腳本和配置環(huán)境,這就導(dǎo)致了測試效率低下,消耗了太多的測試工程師的精力,使測試過程容易出現(xiàn)疏漏。另一個(gè)難題是整車控制器軟件測試不及時(shí)。軟件開發(fā)工程師希望在完成軟件開發(fā)之后盡快開始測試操作,并且希望盡早發(fā)現(xiàn)整車控制器軟件中的錯(cuò)誤。然而,測試工程師的精力有限,需要測試工程師完成現(xiàn)有的測試任務(wù)后才能執(zhí)行新觸發(fā)的測試任務(wù)。測試任務(wù)觸發(fā)與實(shí)際執(zhí)行測試任務(wù)之間的時(shí)間受到測試工程師任務(wù)量的影響,測試任務(wù)無法及時(shí)執(zhí)行。

為了保證軟件開發(fā)工程師們觸發(fā)的測試任務(wù)能夠及時(shí)被執(zhí)行,測試結(jié)果能夠及時(shí)反饋給相應(yīng)的軟件開發(fā)工程師,同時(shí)也為了進(jìn)一步提高測試設(shè)備使用率和整車控制器軟件測試效率,保證軟件質(zhì)量和縮短軟件開發(fā)周期。本文設(shè)計(jì)了一個(gè)基于持續(xù)測試技術(shù)的整車控制器測試平臺,在完成整車控制器軟件的編譯后,自動觸發(fā)整車控制器的軟件測試過程,如果測試任務(wù)的數(shù)量大于測試設(shè)備的數(shù)量,則對測試設(shè)備進(jìn)行調(diào)度管理,使軟件工程師能夠盡快了解整車控制器軟件中的錯(cuò)誤信息,修補(bǔ)軟件中的漏洞。該持續(xù)測試平臺對于提高設(shè)備使用率和測試效率,解放人力,縮短軟件開發(fā)周期,提高整車控制器軟件質(zhì)量具有重要意義,并為其他控制器的持續(xù)測試發(fā)展提供參考與理論基礎(chǔ)。

1 持續(xù)測試技術(shù)概述及原理

持續(xù)測試技術(shù)是一種以并行的方式對開發(fā)中的軟件進(jìn)行實(shí)時(shí)測試的過程,持續(xù)測試技術(shù)使軟件開發(fā)與軟件測試活動保持一致,以此向軟件開發(fā)工程師提供軟件錯(cuò)誤信息的一種技術(shù)理論,持續(xù)測試技術(shù)的目的是在軟件開發(fā)的早期發(fā)現(xiàn)軟件中的問題,以此避免軟件中出現(xiàn)不易察覺的錯(cuò)誤出現(xiàn)[4]。

在整車控制器軟件開發(fā)與測試中使用持續(xù)測試技術(shù)時(shí),需要軟件工程師根據(jù)開發(fā)需求進(jìn)行任務(wù)分解,將測試任務(wù)分解成一個(gè)個(gè)具體的開發(fā)任務(wù)。當(dāng)軟件開發(fā)工程師開發(fā)完第1個(gè)子任務(wù)后,測試工程師對其進(jìn)行測試,軟件開發(fā)工程師在等待測試結(jié)果的時(shí)候,可以繼續(xù)進(jìn)行第2個(gè)子任務(wù)開發(fā)。第1個(gè)子任務(wù)測試完成后,測試工程師將軟件中的問題反饋給軟件開發(fā)工程師進(jìn)行修復(fù),直到軟件測試通過。隨后,軟件開發(fā)工程師的第2個(gè)子任務(wù)開發(fā)完成,測試工程師能夠立即進(jìn)行第2個(gè)子任務(wù)的軟件測試,軟件開發(fā)工程師則進(jìn)行第3個(gè)子任務(wù)的開發(fā)。以此類推,開發(fā)和測試同時(shí)進(jìn)行,所有項(xiàng)目人員在軟件開發(fā)的每個(gè)中間環(huán)節(jié)能參與其中,整車控制器持續(xù)測試技術(shù)原理如圖1所示。

圖1 整車控制器持續(xù)測試技術(shù)原理Fig.1 Technical principle of continuous testing of vehicle control unit

2 持續(xù)測試平臺構(gòu)成

持續(xù)測試平臺分為硬件和軟件兩部分,硬件部分包括服務(wù)器主機(jī)、客戶端主機(jī)、測試設(shè)備和整車控制器;軟件部分包括RQM任務(wù)管理系統(tǒng)、測試腳本管理庫和Jenkins主從程序。服務(wù)器主機(jī)上運(yùn)行Jenkins主程序(Jenkins-Master),服務(wù)器主機(jī)作為平臺的任務(wù)調(diào)度中心,監(jiān)控待測軟件的提交,觸發(fā)整車控制的測試和管理測試結(jié)果,保證持續(xù)測試順利運(yùn)行。測試腳本管理庫存放從RQM任務(wù)管理系統(tǒng)生成的測試腳本?？蛻舳酥鳈C(jī)上運(yùn)行Jenkins從程序(Jenkins-Slave),接收J(rèn)enkins-Master發(fā)送過來的控制指令。當(dāng)有待測軟件被Jenkins-Master檢測到時(shí),Jenkins-Slave根據(jù)Jenkins-Master的指令開啟ECU-TEST,觸發(fā)測試設(shè)備進(jìn)行整車控制器軟件測試[5]。測試完成后ECU-TEST生成測試報(bào)告,并通過Jenkins-Master上傳到RQM中進(jìn)行測試結(jié)果管理。持續(xù)測試平臺的系統(tǒng)結(jié)構(gòu)如圖2所示。

圖2 持續(xù)測試平臺系統(tǒng)結(jié)構(gòu)圖Fig.2 System structure of continuous testing platform

3 持續(xù)測試平臺基本測試流程

持續(xù)測試平臺是對自動測試流程的優(yōu)化,因此在進(jìn)行持續(xù)測試平臺測試流程設(shè)計(jì)前,需要了解自動測試基本流程。自動測試的硬件設(shè)備Labcar測試臺架(見圖2),在進(jìn)行整車控制器自動測試時(shí),軟件開發(fā)工程師通過郵件將需要的軟件發(fā)送給測試工程師。測試工程師在獲得軟件后,根據(jù)軟件需要測試的內(nèi)容在測試腳本管理庫中篩選出使用的測試腳本。測試工程師將待測軟件和測試腳本放到ECU-TEST的配置文件中,隨后ECU-TEST對測試環(huán)境進(jìn)行部署。測試環(huán)境部署完成后,測試工程師通過在ECU-TEST上手動運(yùn)行相對應(yīng)的測試腳本,觸發(fā)自動測試流程[6]。測試完成后,測試工程師對測試報(bào)告進(jìn)行整理,將測試報(bào)告反饋給軟件開發(fā)工程師,自動測試基本流程如圖3所示。

圖3 自動測試基本流程Fig.3 Basic process of automatic test

持續(xù)測試平臺進(jìn)行測試的流程如圖4所示。在進(jìn)行測試任務(wù)之前,測試工程師需要對RQM上登記的測試計(jì)劃和測試任務(wù)進(jìn)行檢查和維護(hù),并將測試計(jì)劃和測試腳本放置在GIT或者SVN中;服務(wù)器上軟件編譯完成后被Jenkins-Master識別,Jenkins-Master根據(jù)生成的待測軟件信息在RQM上查詢相應(yīng)的測試計(jì)劃和測試任務(wù);Jenkins-Master根據(jù)測試任務(wù)和測試計(jì)劃,指派當(dāng)前可以使用的Jenkins-Slave從GIT或者SVN上下載相應(yīng)的測試腳本到本地;測試腳本下載完成后,Jenkins-Slave控制客戶端電腦對ECU-TEST和Labcar進(jìn)行測試環(huán)境的部署;測試環(huán)境部署完成后,ECU-TEST按照測試腳本內(nèi)的測試流程對整車控制器進(jìn)行相應(yīng)的刷新和測試操作。Labcar測試完成后,ECU-TEST生成測試數(shù)據(jù)和測試報(bào)告;生成的測試數(shù)據(jù)和測試報(bào)告被儲存在Jenkins-Master服務(wù)器中,同時(shí)測試數(shù)據(jù)被存入到網(wǎng)盤中;Jenkins-Master將網(wǎng)盤地址上傳到RQM中進(jìn)行管理,同時(shí)將測試報(bào)告的網(wǎng)盤路徑發(fā)送給相應(yīng)工程師,由工程師對測試結(jié)果進(jìn)行檢查;最后,持續(xù)測試平臺等待下一個(gè)測試任務(wù)觸發(fā)。

圖4 持續(xù)測試平臺的基本測試流程圖Fig.4 Test flow chart of continuous testing platform

4 多測試任務(wù)調(diào)度算法

在持續(xù)測試平臺執(zhí)行整車控制器測試的任務(wù)中,一個(gè)測試任務(wù)可以按照具體測試內(nèi)容拆分成多個(gè)子測試任務(wù),子測試任務(wù)之間測試流程相互獨(dú)立,因此測試任務(wù)可以拆分成多個(gè)子測試任務(wù),安排多臺Labcar測試臺架對其進(jìn)行測試。軟件開發(fā)的生命周期越來越短,測試任務(wù)越高效,整車控制軟件質(zhì)量才能得到保障。因此,需要有一套高效的實(shí)時(shí)測試調(diào)度系統(tǒng)來提高測試效率,減少測試結(jié)果等待時(shí)間。在計(jì)算機(jī)操作系統(tǒng)中經(jīng)常會遇到資源調(diào)度問題,并且也有很多成熟穩(wěn)定的解決算法,銀行家算法是其中經(jīng)典算法之一[7]。本文使用銀行家算法來解決持續(xù)測試平臺的測試設(shè)備調(diào)度問題[8-9]:

設(shè)Reqi為進(jìn)程Ti的請求向量,如果Reqi[j]=K,表示進(jìn)程Ti需要K個(gè)Rj類型的資源。當(dāng)Ti發(fā)出資源請求后,系統(tǒng)按照下列步驟進(jìn)行檢查:

(1)如果Reqi[j]≤需求向量Need[i,j],便轉(zhuǎn)向步驟(2),否則認(rèn)為出錯(cuò),因?yàn)樗枰馁Y源已經(jīng)超過它所宣稱的最大資源。

(2)如果Reqi[j]≤可利用的測試設(shè)備數(shù)量Available[j]便轉(zhuǎn)向步驟(3),否則表示尚無足夠的Labcar資源,Ti須等待。

(3)系統(tǒng)試探著把資源分配給進(jìn)程Ti,并修改下面結(jié)構(gòu)中數(shù)據(jù)的數(shù)值:

(4)如果Need[i,j]≤Available[j],系統(tǒng)認(rèn)為將Labcar測試資源分配給該測試任務(wù)可行,測試任務(wù)Ti獲得此次分配的Labcar的使用權(quán)限,否則將本次的試探分配作廢,恢復(fù)原來的Labcar分配狀態(tài),讓測試任務(wù)Ti等待。

(5)當(dāng)按照銀行家算法分配完Labcar測試設(shè)備后,如果還有可以使用的Labcar測試設(shè)備,則將剩余的Labcar測試設(shè)備平均分配給剩下的測試任務(wù)使用。

基于銀行家算法,對測試任務(wù)進(jìn)行優(yōu)先級排序,在環(huán)仿真系統(tǒng)為測試任務(wù)分配最佳的硬件。假設(shè)現(xiàn)有5個(gè)硬件在環(huán)仿真系統(tǒng),某個(gè)時(shí)間段有3個(gè)整車控制器軟件測試任務(wù)需要進(jìn)行系統(tǒng)測試,其測試隊(duì)列的狀態(tài)如表1所示。其中第1個(gè)測試任務(wù)T1包含整車控制器引腳的輸入和輸出測試等2個(gè)系統(tǒng)測試子任務(wù),第2個(gè)測試任務(wù)T2包含整車控制器引腳的輸入、輸出測試、通信發(fā)動和通信接收等4個(gè)系統(tǒng)測試子任務(wù),第3個(gè)測試任務(wù)包含整車控制器通信發(fā)動和通信接收等2個(gè)系統(tǒng)測試子任務(wù)(見表2)。

表1 某時(shí)刻持續(xù)測試平臺測試隊(duì)列初始狀態(tài)Tab.1 Initial state of test queue of continuous test platform at a certain time

表2 持續(xù)測試平臺分配方案1Tab.2 Continuous testing platform allocation scheme 1

為了保證持續(xù)測試平臺能測試盡可能多的測試任務(wù),測試平臺根據(jù)銀行家算法對測試任務(wù)進(jìn)行優(yōu)先級排序。在測試任務(wù)列表中T1包含兩個(gè)測試任務(wù),T2包含4個(gè)測試任務(wù),T3包含2個(gè)測試任務(wù)。此時(shí)測試資源分配(見表2)。

當(dāng)T1和T3的測試任務(wù)完成后,持續(xù)測試平臺將剩下所有可用的Labcar分配給T2進(jìn)行測試。此時(shí)測試資源分配如表3所示。

表3 持續(xù)測試平臺分配方案2Tab.3 Continuous test platform allocation scheme 2

最終持續(xù)測試平臺完成T1、T2和T3測試任務(wù),相較于沒有Labcar資源調(diào)度系統(tǒng)前,當(dāng)某個(gè)時(shí)間段有大量測試任務(wù)需要進(jìn)行測試,測試任務(wù)被拆分成多個(gè)子任務(wù)進(jìn)行并行測試,單個(gè)測試任務(wù)的測試效率得到了提升。

5 持續(xù)測試平臺使用

在整車控制器軟件測試中,測試內(nèi)容主要包含軟件刷新測試、IO接口測試和通信測試3個(gè)主要步驟,本文的持續(xù)測試平臺的使用過程以IO接口測試為例進(jìn)行介紹。持續(xù)測試流程在前文已經(jīng)詳細(xì)敘述,此處不再進(jìn)行贅述。

使用持續(xù)測試平臺時(shí),測試工程師只需要提前在RQM中登記測試的項(xiàng)目名稱、測試腳本路徑、模型文件路徑和相關(guān)工程師的郵箱,然后等待服務(wù)器中生成的測試軟件被Jenkins-Master檢測到。RQM登記測試任務(wù)信息界面如圖5所示。

圖5 RQM登記測試任務(wù)信息界面Fig.5 RQMregistration test task information interface

當(dāng)Jenkins-Master檢測到軟件編譯服務(wù)器的整車控制器軟件后,Jenkins-Master根據(jù)圖5所示的登記信息,選擇對應(yīng)的Jenkins-Slave開始進(jìn)行整車控制器的測試流程[10]。圖6所示為持續(xù)測試觸發(fā)后,Jenkins-Slave控制ECU-TEST進(jìn)行IO接口測試的過程。測試完成后,ECU-TEST自動生成整車控制器IO接口的測試報(bào)告,軟件工程師可以點(diǎn)擊具體的控制器引腳查看詳細(xì)的測試結(jié)果。測試報(bào)告部分截圖如圖7所示。

圖6 ECU-TEST進(jìn)行IO接口測試Fig.6 ECU-TEST performs IO interface test

圖7 測試報(bào)告部分截圖Fig.7 Screenshot of test report

持續(xù)測試平臺在整個(gè)測試流程結(jié)束后,將測試報(bào)告的路徑上傳至RQM任務(wù)登記界面,同時(shí)Jenkins-Master通過郵件將測試報(bào)告路徑發(fā)送給相關(guān)工程師查看測試報(bào)告。測試報(bào)告路徑上傳RQM如圖8所示。

圖8 測試報(bào)告路徑上傳RQMFig.8 Test report path uploaded to RQM

6 測試結(jié)果與分析

從測試效率以及測試成功率兩個(gè)維度對自動測試平臺和持續(xù)測試平臺進(jìn)行比較。

(1)測試效率對比。通過對整車控制器軟件刷新測試、IO接口測試和通信測試3種測試任務(wù)在相同的整車控制器、相同的測試腳本和相同的測試環(huán)境下進(jìn)行了20次測試,分別記錄每個(gè)測試任務(wù)的在持續(xù)測試平臺和自動測試平臺上消耗的時(shí)間,其結(jié)果如表4和圖9所示。

圖9 測試時(shí)長(t)對比Fig.9 Test time(t)comparison

表4 持續(xù)測試平臺和自動測試平臺測試時(shí)長Tab.4 Test duration of continuous test platform and automatic test platform

通過相同測試腳本和測試環(huán)境,得出持續(xù)測試平臺對自動測試平臺測試效率提升的程度,得到如表5所示持續(xù)測試與自動測試相對效率表。即

表5 持續(xù)測試與自動測試相對效率Tab.5 Relative efficiency of continuous test and automatic test

式中:η1為持續(xù)測試相對自動測試提高的測試效率;tz為相同測試條件下自動測試所用時(shí)間,s;tc為相同測試條件下持續(xù)測試所用時(shí)間,s。

本文在相同測試腳本和測試環(huán)境下,對相同整車控制進(jìn)行了測試。測試結(jié)果表明,持續(xù)測試平臺所需時(shí)間比自動測試平臺更少。持續(xù)測試平臺相較于自動測試平臺,軟件刷新測試、IO接口測試和通信測試等任務(wù)的測試平均效率分別提高了32.14%、36.03%和11.84%,總體測試效率提高了約14%。

(2)測試穩(wěn)定性對比。通過對軟件刷新、IO接口和通信3種測試任務(wù)在相同整車控制器、相同測試腳本和相同測試環(huán)境下進(jìn)行100次測試統(tǒng)計(jì),根據(jù)持續(xù)測試平臺和自動測試平臺執(zhí)行測試的成功的次數(shù)比較兩種測試平臺的穩(wěn)定性。計(jì)算得到持續(xù)測試平臺與自動測試平臺測試成功率比較(見表6)。實(shí)驗(yàn)表明,持續(xù)測試平臺比自動測試平臺的穩(wěn)定性要高出7%。其公式表示為

表6 持續(xù)測試平臺與自動測試平臺測試成功率比較Tab.6 Comparison of test success rate between continuous test platform and automatic test platform

式中:η2為測試平臺的穩(wěn)定性;P為測試成功的次數(shù);T為測試的總次數(shù)。

7 結(jié) 語

本文設(shè)計(jì)了一種基于持續(xù)測試技術(shù)的整車控制器測試平臺,該測試平臺檢測到待測整車控制器軟件后,自動開始測試流程,測試完成后自動將測試報(bào)告上傳到任務(wù)管理系統(tǒng)RQM中,并將測試報(bào)告自動發(fā)送給整車控制器相關(guān)工程師。相較于傳統(tǒng)自動測試平臺,本文設(shè)計(jì)的持續(xù)測試平臺使用持續(xù)測試技術(shù)觸發(fā)整車控制器測試流程,利用多測試任務(wù)調(diào)度算法將測試任務(wù)分配到不同的Labcar測試臺架中執(zhí)行測試。實(shí)驗(yàn)證明,整車控制器的測試效率提高了14%,測試穩(wěn)定性提高了7%。持續(xù)測試平臺能充分利用Labcar測試資源,控制器軟件中的問題能夠被及時(shí)發(fā)現(xiàn),軟件開發(fā)周期得到了縮短,整車控制器軟件質(zhì)量也得到了提高,同時(shí)也為其他控制器的持續(xù)測試提供參考與理論基礎(chǔ)。