软件在环测试理念在基于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.

(编辑" 凌" 波)

猜你喜欢
软件测试测试方法
基于泊松对相关的伪随机数发生器的统计测试方法
基于OBE的软件测试课程教学改革探索
计算机教育(2020年5期)2020-07-24 08:53:20
基于云计算的软件自动化测试方法
电子制作(2019年16期)2019-09-27 09:34:56
DLD-100C型雷达测试方法和应用
电子制作(2019年15期)2019-08-27 01:12:02
EXCEL和VBA实现软件测试记录管理
电子制作(2018年16期)2018-09-26 03:27:18
关于软件测试技术应用与发展趋势研究
电子测试(2017年15期)2017-12-18 07:19:20
软件测试工程化模型及应用研究
对改良的三种最小抑菌浓度测试方法的探讨