嵌入式软件自动化测试技术

陈 佐，张怀相，方景龙

(杭州电子科技大学 计算机学院，浙江 杭州 310018)

0 引 言

在软件测试的过程中，存在着许多重复的、非创造性的工作，在这样的背景下，自动化测试系统(automated testing system，ATS)[1]以其节省人工、缩短测试时间、提高测试效率以及增强测试稳定性等优点在软件测试方面越来越受到人们的关注。

本文对嵌入式软件自动化测试技术进行相关的研究，设计了一个高性能的嵌入式测试系统，它提供了一个受控制的、确定的虚拟环境模拟平台，软件测试人员能够在这个平台上进行软件的自动化测试、软件结构体系验证及软件功能可靠性验证等各种技术指标检验，提高了嵌入式系统的测试效率，优化了嵌入式软件的设计，降低系统设计成本。

主要贡献可总结如下：①定义了一系列测试调度原则，优化分布式资源调度；②设计了一个自动化执行引擎，对测试用例进行高效率的测试执行；③构建了一个受控制的，确定性的虚拟仿真环境，以支持嵌入式软件运行环境；④以典型的无人机嵌入式软件为实例，验证嵌入式软件自动化执行框架的实用性、可靠性以及高效性。

1 嵌入式软件自动化测试模型

本文提出一种基于虚拟仿真环境的嵌入式软件自动化测试模型(embedded software automatic test model，EATM)，它集成了数据驱动测试架构、测试库架构以及分布式测试架构等的优点，以虚拟仿真技术构建测试环境，以用例库的形式统一管理测试用例，以测试用例作为数据驱动测试程序，并以分布式架构管理用例调度与数据分发。

EATM框架如图1所示，属于典型的分布式测试架构，具体可以分为两大组成部分：

(1)测试终端

测试终端模拟了软件需要运行的基本嵌入式硬件环境，将其作为整个自动化测试执行框架的环境基础。在如图1所示的QEMU半虚拟仿真环境基础上，可以将测试终端细化为两部分，一是被测软件部分，二是测试控制部分，两者之间以共享内存区域作为数据交互，从而达到测试的实时性以及稳定性。

(2)测试控制中心

测试控制中心是EATM框架的核心控制部分，主要对测试用例库进行管理；对测试用例进行筛选以及分布式任务调度；对测试结果进行检验并统计等。测试控制中心采用基于Java Swing框架技术开发，具有较强的可移植性。

图1 嵌入式软件自动化测试模型框架

测试终端和测试控制中心之间采用网络通信方式，主要采用可靠的TCP/Socket通信形式，建立端到端的连接，用于测试数据的发送以及测试结果报告的反馈。

该框架结构的优点是能充分发挥分布式架构的处理能力，具体表现在以下两点：

(1)测试终端轻负载

在测试控制中心对测试用例进行筛选，对高性能的测试终端分配重要度高、较复杂的测试用例，并且采用多测试终端来减少单个测试终端的测试负荷，极大程度地提高测试的效率。

(2)测试用例协同处理

对高负载的测试用例可以拆分成多个子任务，并采用一定的调度规则调度协同多个测试终端处理，可以减少单个测试终端的负荷，在很大程度上增加了并行处理测试数据的能力。

2 嵌入式软件自动化测试模型设计

整个EATM框架主要分为4个部分：测试用例分发引擎、测试用例封装引擎、测试用例执行引擎以及虚拟仿真引擎。

如图2所示，测试用例分发引擎主要以测试用例为数据流，从本地测试用例库中按照分发调度规则进行筛选以及分发；测试用例封装引擎主要将网络传输的测试用例进行实例化操作，并将实例结果存储在本地测试用例库；测试用例执行引擎主要以测试实例为数据来驱动整个自动化测试执行器，以完成对测试用例的测试执行并最终生成测试报告；虚拟仿真引擎主要搭建了整个自动化测试执行的必要软件环境。

图2 EATM框架

2.1 用例分发引擎

用例分发引擎可以抽象的概括为“分发-收集”的过程，即将大量的测试数据按照一定调度原则分解成多个子任务，每个子任务分配给各个终端节点，最后收集每个测试终端执行后的测试结果。对于每个子任务，可以由一个或者多个终端节点分工完成，即采用“功能分布”原则。对于给定任务的调度分配，描述了分布式测试环境中的行为信息，提供了描述分布式测试中的测试节点运行调度功能，比如不同的测试节点启动的先后顺序以及它们之间的同步关系，使框架具有扩展能力。

2.1.1 分发数据格式

可扩展标记语言(XML)[2]作为当前处理结构化信息的主流工具，具有高扩展性、强移植性以及强可控性等突出优点，本文基于XML设计了测试用例的结构化格式。

一个测试用例文件由测试包、测试用例和测试结果构成，以下给出这三者的概念：①测试包：所有测试用例的集合，根据产品的逻辑模块或者测试模式(功能、性能或压力)构成不同的测试用例集；②测试用例：完成一个明确的测试需求所需要的执行逻辑以及须给出的过程参数；③测试结果：对一个测试用例最后的测试结果。用XML表示总体结构如图3所示。

图3 测试数据XML结构

定义1 测试数据：一个测试数据格式可以表示为

TestCase=其中：

(1)Testsuite={Testsuite|Testsuite表示某个模式下的所有测试用例集合|model表示当前测试数据使用的测试模式}

(2)Testcase={Testcase|Testcase表示测试用例集合中的一条测试用例}

(3)Process={Process|Process用来表示一条测试用例中的某个激励}

(4)Operation={Operation|Operation表示激励名称}

(5)Input={Input|Input表示激励参数名称以及具体数值}

2.1.2 分发调度原则

在本文中的系统实时分发调度[3]采用静态的、不可抢占的分布式调度原则。在EATM框架中，每个测试终端节点都是异构的，同一时刻每个节点的性能是不同的。因此根据各节点的性能情况给各个测试终端分配不同数量以及不同“优先级”的任务，使得分布式中各节点负载基本均衡的同时达到效率最优。分发调度流程如图4所示。

图4中的“测试用例筛选引擎①”，根据测试用例类型和赌轮盘算法[4]将测试用例全集划分成多批次初级测试用例。

图4 分发调度流程

输入：软件系统的测试用例全集T

输出：初级测试用例t的集合FTestCaseList

(1)通过数据库连接池获取构建的测试用例数据库，取出测试用例全集T，并将每一条数据存储在AllTestCaseList集合中，遍历AllTestCaseList；

(2)构建List集合tf,tp,tt分别代表3种类型的分类子集；

(3)获对取第i个测试用例数据，通过测试数据的Testsuite属性来决定应该被划分到哪一个分类子集中；

(4)遍历完成所有测试用例后，对应的分类子集t全部构造完成，对应的分类子集规模大小为nf,np,nt；

(5)构建测试用例集合List，从tf,tp,tt这3个分类子集中根据赌轮盘算法选择一测试用例tk，将tk从原分类子集中移除并加入List，直到List的规模为(nf+np+nt)/3。

(6)构建FTestCaseList集合，并将List加入，递归第(5)步直到分类子集均为空。

图4中的“测试用例筛选引擎②”，根据测试用例的完整性以及复杂性评价测试用例，并对初始测试用例按优先级筛选，形成最终的“任务”。

定义4 测试用例优先级：测试用例优先级是根据测试用例需求的完整性以及复杂性为标准进行量化，根据以上给出测试用例描述的两个因素，可以量化的表示第i个测试用例的优先级值为

输入：初级测试用例t的集合FTestCaseList

输出：初级测试用例t对应的任务子集合task

(1)读取初级用例t的集合FTestCaseList，依次遍历；

(2)获取第i个初级测试用例集ti，对集合中每条测试用例Ti进行优先级评价记为Vi，并以此为关键字，以将测试用例Ti为值存储在PriorityMap中；

(3)当对初级测试用例均进行完优先级评价后，Prio-rityMap进行降序排序。

(4)按照优先级越高越优先挑选的原则，对初级测试用例t进行任务子集合的筛选，形成任务子集合task。

2.2 用例封装引擎

测试用例通过分发引擎处理，以“任务”的形式被分发到各个分布式终端。在各个测试终端，框架将所有收到的“任务”存储在用例库中，并对其进行封装操作，将其实例化后的测试用例实体保存在终端的本地测试用例库中，以作为用例执行引擎的输入数据。

测试用例封装具体过程如下：

输入：测试用例的XML文件集合TCList

输出：测试用例实例集合TestCaseList

(1)读取系统构建测试用例的XML文件集合TCList，遍历TCList；

(2)获取第i个测试用例，创建TestCase对象并设置用例ID属性为i；

(3)创建Process对象，根据测试用例的XML数据格式对第i个测试用例中Process相关属性对象信息进行解析并封装到Process对象，最后将Process对象放入ProcessList集合中；

(4)重复(3)直到第i个测试用例中所有Process相关属性对象信息都被解析完成；

(5)将当前的ProcessList集合赋值给TestCase的ProcessList属性；

(6)获取第i个测试用例的ExeStatus属性，并赋值给TestCase的ExeStatus属性；

(7)对TestCase进行实体验证，若属于完整测试用例，则存储到TestCaseList集合之中；

(8)遍历完成集合TCList中所有测试用例后，将得到所有封装后的测试用例实体都保存到TestCaseList之中，若该集合不为空则返回，否则抛出文件处理异常。

2.3 用例执行引擎

在整个EATM框架中，以实例化后的测试用例库作为数据源，以插桩[5]处理方式对数据进行重定向，以任务调度机制来驱动测试终端平台上的嵌入式程序执行。

在整个测试过程中，测试用例执行引擎对任务的划分已经确定测试实体类的调度方式，即以上层模型对下层进行轮询检测的模式来有序地调度各个模型用例。对测试用例执行引擎通过插桩操作，不仅能够动态的重定向测试数据，而且能够实时地记录测试过程中的执行情况，起到了对测试进行动态跟踪作用，提高了测试过程的自动化测试水平。

整个测试执行引擎的执行流程如图5所示，其中图5(b)是图5(a)中测试用例执行子流程的扩展描述，整体测试用例执行具体过程如下：

输入：测试用例实例集合TestCaseList

输出：测试用例执行结果集合TestCaseResultList

(1)启动；

(2)初始化程序环境；

(3)任务调度队列初始化，其功能是不断触发测试用例的执行，每次触发相当于执行一条测试用例，即一条完整的程序执行路径；

(4)判断测试用例缓冲区中是否还有测试用例未执行，否则转到(16)；

(5)通过用例ID来从TestCaseList中获取用例，并将该用例设置为此次循环的当前测试用例；

(6)测试用例执行子流程执行开始，调用首激励；

(7)判断激励链表中是否还有未执行的激励，否则跳转到(14)；

(8)激励是否有参数，否则跳转到(10)；

(9)激励参数重定向，即从当前测试用例链表中获取当前激励的参数数值；

(10)激励执行起始插桩记录；

(11)激励调用执行；

(12)该激励是否调用其它激励，是则跳转到(8)；

(13)激励结束插桩以及当前激励状态回写，跳转到(7)；

(14)测试用例执行子流程执行结束；

(15)测试用例ID自增，跳转到(4)；

(16)结束。

图5 测试用例执行流程

2.4 虚拟仿真引擎

嵌入式软件被定义为嵌入在硬件中的操作系统和开发工具软件，其中硬件平台具有多样性是嵌入式系统的主要特点。对于嵌入式软件需要特定的硬件平台是阻碍开发与测试的主要因素，而仿真软件则通过软件模拟形成一个具有基本完整硬件系统功能的、相对封闭的隔离环境，并且能够保证在半虚拟化[6]环境下计算的安全性，该特性能够有效地弥补嵌入式软件开发测试中受平台限制的弊端。

目前主要的指令级仿真软件有以下几款：QEMU[7]、国内清华大学研发的Skyeye以及Realboard仿真软件平台[8]。本文中采用QEMU仿真软件对运行平台为ARM架构嵌入式软件进行仿真，例如UAV(unmanned aerial vehicle)无人机机载软件，QEMU仿真软件是目前较为先进且可开发源代码的跨平台仿真软件，具有模拟适配度广、速度快及跨平台等特性，可以较优秀的仿真出基ARM架构的虚拟化环境。

对于各个模块的仿真，如图6所示：采用TCG(tiny code generator)动态二进制翻译技术[9]进行指令的解析翻译工作实现嵌入式软件的CPU虚拟化；通过影子内存[10]对嵌入式软件内存虚拟化；通过设备模拟对嵌入式软件的I/O虚拟化。

图6 QEMU嵌入式环境虚拟化结构

3 实验结果

由于完整UAV系统庞大而复杂，本文通过精简无人机飞控系统，选取飞控系统中无人机某几个功能模块来对本文提出的自动化测试框架进行验证。该模块包含以下功能以及主要描述：操作员打开open按钮；无人机通过获取电机状态、电量的值、位姿信息以及飞行模式等来验证在给定飞行条件无人机位姿调控能力。

通过UML以及状态机的方式求解得到测试用例，将测试序列实例化求解得到的结果进行组合，生成测试用例数据库，共产生了7974条测试用例，作为自动化测试框架的主要数据输入。测试用例库中数据通过EATM框架调度、分发和执行后，结果数据被收集到测试控制中心，测试控制中心最终测试结果的统计并且可视化。

经过测试用例所有的测试用例执行结果见表1：99.51%的测试数据测试成功，说明绝大部分测试用例成功执行且测试结果与测试期望相一致；失败测试用例只占0.49%，具体的失败情况可以再进一步地分析。对39条测试失败的情况进行详细地分析，如表2所示，所有失败的用例均为测试执行结果与期望值不相匹配所致，造成该错误原因是给出测试用例不能正确有效地模拟真实环境中数据所致，与EATM框架执行无关。

表1 测试结果统计

表2 出错结果统计

对于表1中成功的测试用例，按照需求中的描述进行更具体的结果统计，更加直观地展现测试效果。如图7所示，量化指标为无人机的最大飞行高度，即拥有相同电池容量的多架无人机，分别在不同的风速级别下进行垂直爬升操作过程中，当无人机的电量被消耗到0%时无人机所处的高度。

图7 各个风速下最大高度柱状图

在测试过程中对所给的大规模测试用例，EATM框架可以有效地进行测试，并且在表2所示的出错测试用例中不存在由于框架自身错误而影响测试的情况，验证了EATM框架对嵌入式软件的自动化测试具有较好的稳定性。根据图7中所指定量化指标的数据值对比，可得到在该实验中测试结果与期望数据值基本保持一致，有效地验证了本文提出的EATM框架对嵌入式软件的自动化测试完全切实可行，具备较高的实用性。

4 结束语

本文提出了一种嵌入式软件的自动化测试方法，通过半虚拟化技术仿真嵌入式软件运行环境，构造分布式调度算法，并且设计相应的自动化执行引擎，对大量的测试用例进行测试，提升嵌入式软件测试的高效性。最后以简化开源无人机飞控系统的一个单元模块为实例，以通过模型产生的测试用例为数据，应用本文提出的自动化测试框架进行验证。实验结果表明，本框架执行方式正确，验证方法有效。该结果有助于对嵌入式软件系统进行自动化测试和分析。今后本人将对进一步提高系统的执行能力、优化测试用例调度、完善测试结果测评等方面开展研究。