基于持续测试技术的整车控制器测试平台研究

陈振宇,秦 琴,丁 锋,吴 辉

(1.上海第二工业大学 智能制造与控制工程学院,上海 201209;2.联合汽车电子有限公司,上海 201206)

0 引言

随着敏捷和DevOps开发模式在软件行业的推广落地,更频繁的交付加重了业界对测试的担忧,测试不够高效往往成为导致交付延期的首要原因,测试环节也成为了企业进行DevOps转型的最大瓶颈。为了应对这种挑战,“持续测试”概念逐渐被汽车行业广泛接受[1]。目前,新能源汽车整车控制器的测试领域主要存在以下两大难题。第1个难题是使用自动测试平台测试整车控制器,测试过程仍需测试工程师手工参与。测试工程师需要提前对测试环境进行配置,然后从测试脚本管理库中筛选测试脚本,并将其放置在测试环境中,最后触发自动测试[2-3]。不同的测试内容需要测试工程师不断地筛选测试脚本和配置环境,这就导致了测试效率低下,消耗了太多的测试工程师的精力,使测试过程容易出现疏漏。另一个难题是整车控制器软件测试不及时。软件开发工程师希望在完成软件开发之后尽快开始测试操作,并且希望尽早发现整车控制器软件中的错误。然而,测试工程师的精力有限,需要测试工程师完成现有的测试任务后才能执行新触发的测试任务。测试任务触发与实际执行测试任务之间的时间受到测试工程师任务量的影响,测试任务无法及时执行。

为了保证软件开发工程师们触发的测试任务能够及时被执行,测试结果能够及时反馈给相应的软件开发工程师,同时也为了进一步提高测试设备使用率和整车控制器软件测试效率,保证软件质量和缩短软件开发周期。本文设计了一个基于持续测试技术的整车控制器测试平台,在完成整车控制器软件的编译后,自动触发整车控制器的软件测试过程,如果测试任务的数量大于测试设备的数量,则对测试设备进行调度管理,使软件工程师能够尽快了解整车控制器软件中的错误信息,修补软件中的漏洞。该持续测试平台对于提高设备使用率和测试效率,解放人力,缩短软件开发周期,提高整车控制器软件质量具有重要意义,并为其他控制器的持续测试发展提供参考与理论基础。

1 持续测试技术概述及原理

持续测试技术是一种以并行的方式对开发中的软件进行实时测试的过程,持续测试技术使软件开发与软件测试活动保持一致,以此向软件开发工程师提供软件错误信息的一种技术理论,持续测试技术的目的是在软件开发的早期发现软件中的问题,以此避免软件中出现不易察觉的错误出现[4]。

在整车控制器软件开发与测试中使用持续测试技术时,需要软件工程师根据开发需求进行任务分解,将测试任务分解成一个个具体的开发任务。当软件开发工程师开发完第1个子任务后,测试工程师对其进行测试,软件开发工程师在等待测试结果的时候,可以继续进行第2个子任务开发。第1个子任务测试完成后,测试工程师将软件中的问题反馈给软件开发工程师进行修复,直到软件测试通过。随后,软件开发工程师的第2个子任务开发完成,测试工程师能够立即进行第2个子任务的软件测试,软件开发工程师则进行第3个子任务的开发。以此类推,开发和测试同时进行,所有项目人员在软件开发的每个中间环节能参与其中,整车控制器持续测试技术原理如图1所示。

图1 整车控制器持续测试技术原理Fig.1 Technical principle of continuous testing of vehicle control unit

2 持续测试平台构成

持续测试平台分为硬件和软件两部分,硬件部分包括服务器主机、客户端主机、测试设备和整车控制器;软件部分包括RQM任务管理系统、测试脚本管理库和Jenkins主从程序。服务器主机上运行Jenkins主程序(Jenkins-Master),服务器主机作为平台的任务调度中心,监控待测软件的提交,触发整车控制的测试和管理测试结果,保证持续测试顺利运行。测试脚本管理库存放从RQM任务管理系统生成的测试脚本。客户端主机上运行Jenkins从程序(Jenkins-Slave),接收Jenkins-Master发送过来的控制指令。当有待测软件被Jenkins-Master检测到时,Jenkins-Slave根据Jenkins-Master的指令开启ECU-TEST,触发测试设备进行整车控制器软件测试[5]。测试完成后ECU-TEST生成测试报告,并通过Jenkins-Master上传到RQM中进行测试结果管理。持续测试平台的系统结构如图2所示。

图2 持续测试平台系统结构图Fig.2 System structure of continuous testing platform

3 持续测试平台基本测试流程

持续测试平台是对自动测试流程的优化,因此在进行持续测试平台测试流程设计前,需要了解自动测试基本流程。自动测试的硬件设备Labcar测试台架(见图2),在进行整车控制器自动测试时,软件开发工程师通过邮件将需要的软件发送给测试工程师。测试工程师在获得软件后,根据软件需要测试的内容在测试脚本管理库中筛选出使用的测试脚本。测试工程师将待测软件和测试脚本放到ECU-TEST的配置文件中,随后ECU-TEST对测试环境进行部署。测试环境部署完成后,测试工程师通过在ECU-TEST上手动运行相对应的测试脚本,触发自动测试流程[6]。测试完成后,测试工程师对测试报告进行整理,将测试报告反馈给软件开发工程师,自动测试基本流程如图3所示。

图3 自动测试基本流程Fig.3 Basic process of automatic test

持续测试平台进行测试的流程如图4所示。在进行测试任务之前,测试工程师需要对RQM上登记的测试计划和测试任务进行检查和维护,并将测试计划和测试脚本放置在GIT或者SVN中;服务器上软件编译完成后被Jenkins-Master识别,Jenkins-Master根据生成的待测软件信息在RQM上查询相应的测试计划和测试任务;Jenkins-Master根据测试任务和测试计划,指派当前可以使用的Jenkins-Slave从GIT或者SVN上下载相应的测试脚本到本地;测试脚本下载完成后,Jenkins-Slave控制客户端电脑对ECU-TEST和Labcar进行测试环境的部署;测试环境部署完成后,ECU-TEST按照测试脚本内的测试流程对整车控制器进行相应的刷新和测试操作。Labcar测试完成后,ECU-TEST生成测试数据和测试报告;生成的测试数据和测试报告被储存在Jenkins-Master服务器中,同时测试数据被存入到网盘中;Jenkins-Master将网盘地址上传到RQM中进行管理,同时将测试报告的网盘路径发送给相应工程师,由工程师对测试结果进行检查;最后,持续测试平台等待下一个测试任务触发。

图4 持续测试平台的基本测试流程图Fig.4 Test flow chart of continuous testing platform

4 多测试任务调度算法

在持续测试平台执行整车控制器测试的任务中,一个测试任务可以按照具体测试内容拆分成多个子测试任务,子测试任务之间测试流程相互独立,因此测试任务可以拆分成多个子测试任务,安排多台Labcar测试台架对其进行测试。软件开发的生命周期越来越短,测试任务越高效,整车控制软件质量才能得到保障。因此,需要有一套高效的实时测试调度系统来提高测试效率,减少测试结果等待时间。在计算机操作系统中经常会遇到资源调度问题,并且也有很多成熟稳定的解决算法,银行家算法是其中经典算法之一[7]。本文使用银行家算法来解决持续测试平台的测试设备调度问题[8-9]:

设Reqi为进程Ti的请求向量,如果Reqi[j]=K,表示进程Ti需要K个Rj类型的资源。当Ti发出资源请求后,系统按照下列步骤进行检查:

(1)如果Reqi[j]≤需求向量Need[i,j],便转向步骤(2),否则认为出错,因为它所需要的资源已经超过它所宣称的最大资源。

(2)如果Reqi[j]≤可利用的测试设备数量Available[j]便转向步骤(3),否则表示尚无足够的Labcar资源,Ti须等待。

(3)系统试探着把资源分配给进程Ti,并修改下面结构中数据的数值:

(4)如果Need[i,j]≤Available[j],系统认为将Labcar测试资源分配给该测试任务可行,测试任务Ti获得此次分配的Labcar的使用权限,否则将本次的试探分配作废,恢复原来的Labcar分配状态,让测试任务Ti等待。

(5)当按照银行家算法分配完Labcar测试设备后,如果还有可以使用的Labcar测试设备,则将剩余的Labcar测试设备平均分配给剩下的测试任务使用。

基于银行家算法,对测试任务进行优先级排序,在环仿真系统为测试任务分配最佳的硬件。假设现有5个硬件在环仿真系统,某个时间段有3个整车控制器软件测试任务需要进行系统测试,其测试队列的状态如表1所示。其中第1个测试任务T1包含整车控制器引脚的输入和输出测试等2个系统测试子任务,第2个测试任务T2包含整车控制器引脚的输入、输出测试、通信发动和通信接收等4个系统测试子任务,第3个测试任务包含整车控制器通信发动和通信接收等2个系统测试子任务(见表2)。

表1 某时刻持续测试平台测试队列初始状态Tab.1 Initial state of test queue of continuous test platform at a certain time

表2 持续测试平台分配方案1Tab.2 Continuous testing platform allocation scheme 1

为了保证持续测试平台能测试尽可能多的测试任务,测试平台根据银行家算法对测试任务进行优先级排序。在测试任务列表中T1包含两个测试任务,T2包含4个测试任务,T3包含2个测试任务。此时测试资源分配(见表2)。

当T1和T3的测试任务完成后,持续测试平台将剩下所有可用的Labcar分配给T2进行测试。此时测试资源分配如表3所示。

表3 持续测试平台分配方案2Tab.3 Continuous test platform allocation scheme 2

最终持续测试平台完成T1、T2和T3测试任务,相较于没有Labcar资源调度系统前,当某个时间段有大量测试任务需要进行测试,测试任务被拆分成多个子任务进行并行测试,单个测试任务的测试效率得到了提升。

5 持续测试平台使用

在整车控制器软件测试中,测试内容主要包含软件刷新测试、IO接口测试和通信测试3个主要步骤,本文的持续测试平台的使用过程以IO接口测试为例进行介绍。持续测试流程在前文已经详细叙述,此处不再进行赘述。

使用持续测试平台时,测试工程师只需要提前在RQM中登记测试的项目名称、测试脚本路径、模型文件路径和相关工程师的邮箱,然后等待服务器中生成的测试软件被Jenkins-Master检测到。RQM登记测试任务信息界面如图5所示。

图5 RQM登记测试任务信息界面Fig.5 RQMregistration test task information interface

当Jenkins-Master检测到软件编译服务器的整车控制器软件后,Jenkins-Master根据图5所示的登记信息,选择对应的Jenkins-Slave开始进行整车控制器的测试流程[10]。图6所示为持续测试触发后,Jenkins-Slave控制ECU-TEST进行IO接口测试的过程。测试完成后,ECU-TEST自动生成整车控制器IO接口的测试报告,软件工程师可以点击具体的控制器引脚查看详细的测试结果。测试报告部分截图如图7所示。

图6 ECU-TEST进行IO接口测试Fig.6 ECU-TEST performs IO interface test

图7 测试报告部分截图Fig.7 Screenshot of test report

持续测试平台在整个测试流程结束后,将测试报告的路径上传至RQM任务登记界面,同时Jenkins-Master通过邮件将测试报告路径发送给相关工程师查看测试报告。测试报告路径上传RQM如图8所示。

图8 测试报告路径上传RQMFig.8 Test report path uploaded to RQM

6 测试结果与分析

从测试效率以及测试成功率两个维度对自动测试平台和持续测试平台进行比较。

(1)测试效率对比。通过对整车控制器软件刷新测试、IO接口测试和通信测试3种测试任务在相同的整车控制器、相同的测试脚本和相同的测试环境下进行了20次测试,分别记录每个测试任务的在持续测试平台和自动测试平台上消耗的时间,其结果如表4和图9所示。

图9 测试时长(t)对比Fig.9 Test time(t)comparison

表4 持续测试平台和自动测试平台测试时长Tab.4 Test duration of continuous test platform and automatic test platform

通过相同测试脚本和测试环境,得出持续测试平台对自动测试平台测试效率提升的程度,得到如表5所示持续测试与自动测试相对效率表。即

表5 持续测试与自动测试相对效率Tab.5 Relative efficiency of continuous test and automatic test

式中:η1为持续测试相对自动测试提高的测试效率;tz为相同测试条件下自动测试所用时间,s;tc为相同测试条件下持续测试所用时间,s。

本文在相同测试脚本和测试环境下,对相同整车控制进行了测试。测试结果表明,持续测试平台所需时间比自动测试平台更少。持续测试平台相较于自动测试平台,软件刷新测试、IO接口测试和通信测试等任务的测试平均效率分别提高了32.14%、36.03%和11.84%,总体测试效率提高了约14%。

(2)测试稳定性对比。通过对软件刷新、IO接口和通信3种测试任务在相同整车控制器、相同测试脚本和相同测试环境下进行100次测试统计,根据持续测试平台和自动测试平台执行测试的成功的次数比较两种测试平台的稳定性。计算得到持续测试平台与自动测试平台测试成功率比较(见表6)。实验表明,持续测试平台比自动测试平台的稳定性要高出7%。其公式表示为

表6 持续测试平台与自动测试平台测试成功率比较Tab.6 Comparison of test success rate between continuous test platform and automatic test platform

式中:η2为测试平台的稳定性;P为测试成功的次数;T为测试的总次数。

7 结 语

本文设计了一种基于持续测试技术的整车控制器测试平台,该测试平台检测到待测整车控制器软件后,自动开始测试流程,测试完成后自动将测试报告上传到任务管理系统RQM中,并将测试报告自动发送给整车控制器相关工程师。相较于传统自动测试平台,本文设计的持续测试平台使用持续测试技术触发整车控制器测试流程,利用多测试任务调度算法将测试任务分配到不同的Labcar测试台架中执行测试。实验证明,整车控制器的测试效率提高了14%,测试稳定性提高了7%。持续测试平台能充分利用Labcar测试资源,控制器软件中的问题能够被及时发现,软件开发周期得到了缩短,整车控制器软件质量也得到了提高,同时也为其他控制器的持续测试提供参考与理论基础。