基于决策表的AUTOSAR操作系统一致性测试研究*

1 引言

随着半导体和信息技术的发展,汽车电气和电子系统变得越来越复杂。汽车开放架构AUTOSAR(AUTomotive Open System ARchitecture)[1]操作系统规范为车载嵌入式操作系统及其相关服务定义了一系列的抽象标准接口,其独立于应用软件和硬件平台,获得了广泛的应用。

基于AUTOSAR标准的操作系统规范的广泛应用促进了汽车电子开发,但是也带来了新的挑战。由于AUTOSAR提供的统一规格说明中都是抽象的要求,导致不同开发者和服务提供商设计开发的电子控制单元ECU(Electronic Control Unit)有所不同,具有两义性。因此,操作系统开发过程中,如何保证严格遵守AUTOSAR规范成为了一个亟待解决的问题。对于AUTOSAR操作系统而言,调用应用程序编程接口API(Application Programming Interface)应该得到符合要求的结果。如果不同的操作系统在开发过程中没有完全遵守AUTOSAR操作系统开发规范[2],那么很有可能在运行时产生各种错误。因此,要确保操作系统使用前符合规范标准,需要对其进行严格测试,而一致性测试则扮演了重要的角色。

一致性测试本质上是一种黑盒测试,主要目标是对被测系统的功能进行验证,针对被测系统设计不同的环境和运行条件,通过比对其反应和行为来验证是否和设计规范一致。在对AUTOSAR操作系统进行一致性测试时,通常采用2种方式：一种是基于形式化语言建立模型,通过数学方法来证明具体的实现是否符合一致性要求;另一种是基于分类树、决策表、流框图等测试用例生成方法设计测试集,通过比对被测系统的测试集运行情况验证一致性。

文献[3]通过建立观察者模型,将测试用例转化为观察者对象,实现了对OSEK(Open Systems and the corresponding interfaces for automotive Electronics)标准操作系统的一致性测试,但实现观察者模型的开销较大。文献[4]设计了一种时序约束条件下的序列测试建模方法,通过状态转移允许区间来表示状态转移发生时前一项状态连续出现的次数,扩展了状态转移约束,但需要用户熟练使用建模语言及熟悉复杂的建模机理,并且可能引起状态空间爆炸问题。文献[5]通过形式化建模方法,实现了对多核AUTOSAR操作系统的测试,通过实现临界锁大大抑制了状态空间,降低了状态空间爆炸的可能性,并显著提高了测试的覆盖率。但是,暂未完成时序特性的模型建立,系统需要持续运行可执行的测试序列,从而覆盖尽可能多的测试路径。

嵌入式系统本身由于资源有限,在不同的应用场景中,需要对有限的资源进行裁剪,因此部分系统被划分成不同的级别。以AUTOSAR为例,操作系统目前提供了4个一致类(conformance class,划分系统内核功能的机制)[6]级别。针对不同一致类级别操作系统有特定的应用场景,因此需要对不同一致类操作系统有针对性地进行测试。AUTOSAR官方提供了一种基于分类树的一致性测试集生成方案和测试流程。这种方式节省了构建模型的时间,同时也去除了对其他语言的依赖。文献[7]在此基础上使用分类树对操作系统测试集的生成进行了进一步优化,并对中断管理模块进行了一致性测试。分类树方法相对而言较为简洁,能够较为清晰地展现测试用例的设计流程。但是,在对已有操作系统的频繁一致性测试过程中发现,该方法并不能有针对性地测试特定级别的操作系统,官方文档对应不同一致类级别的操作系统也没有统一的测试序列规划。需要测试人员自行抽取符合一致类要求的测试用例,这涉及多个模块的测试用例抽取,工作量相当庞大。

综上所述,需要新的测试方法来有针对性地对AUTOSAR操作系统进行一致性测试,提升测试效率。

决策表[8]是一种表达事件在逻辑上相互依赖关系的符号手段,包含了流程图、布尔代数和卡诺图等相关知识。基于决策表可以实现测试用例的生成及诸多安全方面的应用。文献[9]通过分析因果表达式的语法实现了决策表的化简,提高了多条件组合问题测试用例的设计和维护效率。文献[10]利用粗糙集理论对故障动作决策表进行最大限度的约简,此方法保留了关键信息的同时得到了知识的最小表达,但是没有考虑输入边界的取值,因此测试覆盖并不完全。

本文基于决策表设计了一种AUTOSAR架构操作系统的一致性测试方法。第2节介绍AUTOSAR操作系统的一致性测试规范和流程;第3节分析了传统测试方案的问题,并有针对性地设计新的测试方法;第4节设计了实验来验证所提方法对比传统方法的测试性能;第5节总结全文。

2 AUTOSAR操作系统一致性测试

本节对AUTOSAR操作系统的一致性测试进行介绍。首先,对相关名词背景进行解释;然后,简要概述一致性测试的基本流程;最后,对流程中细分的测试目的抽取、测试用例设计、测试序列组合和验证的步骤进行了剖析。

2.1 相关概念介绍

对于AUTOSAR操作系统一致性测试的相关概念介绍如下：

(1)一致类。由于不同的功能需求需要操作系统提供不同的特性,诸如任务级别(basic/extend)、任务优先级、任务激活次数等,这些不同特性的组合被称为一致类概念。4种一致类彼此是继承和拓展的关系：基础一致类BCC(Basic Conformance Class)1是其他一致类的子集,限制操作系统仅存在基本任务,且任务不能被多重激活;扩展一致类ECC(Extended Conformance Class)1可存在扩展任务;BCC2在BCC1基础上取消了任务不可被多重激活的限制;ECC2级别的一致类可在BCC2级别上增加扩展任务。通过一致类的划分,可以更好地理解AUTOSAR规范中对于不同特性的定义,同时提供了由浅及深的研发升级路径。在不同的应用场景中,需要按照需求设计对应一致类的操作系统,对有限资源进行裁剪。

(2)测试用例。对于每个需要被验证的规范,即测试目的,需要通过相关方法来设计对应的测试用例进行验证。具体的测试用例设计应该包括AUTOSAR操作系统需要配置的参数、具体的操作及对应符合要求的结果。

(3)测试序列。对于特定的测试目的,需要多条测试用例的组合才能验证对应测试目的,该组合即为测试序列。

2.2 测试框架概述

对于AUTOSAR标准的操作系统,首先根据官方提供的设计规范[2](AUTOSAR_SWS_OS)抽象出具体的测试目的;然后针对测试目的通过一些工具或方法来具化出对应符合标准的测试用例;再经过具体的组合形成测试序列,通过在实际的操作系统上运行测试序列得到不同校验点的结果;最后将该测试结果与预期结果进行比对,验证该系统的被测功能与测试目的是否一致。详细的一致性测试流程如图1所示。

Figure 1 Diagram of test flow
图1 测试流程图

2.3 测试目的抽取

由于AUTOSAR本身的规范是用抽象的自然语言描述的,因此需要从中抽取出可以验证一致性的内容,该内容即为测试目的。测试目的抽取的设计,需要考虑对应一致类级别、任务是否可抢占等参数。以系统基本配置模块为例,根据开发规范抽象出了如表1所示的几条测试目的。

Table 1 Test purposes of system basic configuration
表1 系统基本配置测试目的

表1中,断言对应测试目的的标准,SWS-ID指当前测试目的对应的规范ID。

2.4 测试用例设计

目前AUTOSAR操作系统的测试用例生成以文献[2]为基础,采取分类树方法。对于各功能模块,根据属性节点、执行动作、返回结果等构建出不同分类子树,在子树中罗列相关属性到自身的叶子节点,然后将不同子树的叶子节点进行组合,可以得到具体的测试用例。测试结果符合规范中的接口定义,即认为其通过一致性测试。

2.5 测试序列组合和结果验证

测试序列定义了测试程序执行过程中将执行的操作序列,即每个任务执行的指令序列。每个测试序列都完成了对操作系统测试计划中定义的多个测试用例的测试。完整的测试序列包括使用测试用例的特定设置、返回值类型、调度策略、任务和中断级别。在测试序列执行过程中,依次调用操作系统服务并得到结果,然后再对应每个校验点与预期结果进行比较,如果得到的结果与要求一致,则认为测试序列通过了一致性测试。一致性测试结果验证流程如图2所示。

Figure 2 Verification process of test results
图2 测试结果验证流程

Figure 3 Classification tree of task management module
图3 任务管理模块分类树

通过设计好的评估系统,对发送桩程序传送的测试结果报文进行解析,进而判断待测操作系统是否符合一致性要求,是否满足设计规范。

3 决策表驱动一致性测试

分类树方法是软件测试中常用的测试用例生成方法,具有简明易懂,能够提供非常直观的意义表述的优点。但是,传统操作系统一致性测试方法存在复用性不高和针对性不强的问题[11]。为此,本文提出了基于决策表进行一致性测试的方法,有针对性地对AUTOSAR操作系统进行一致性测试。

3.1 分类树方法测试用例生成分析

一致性测试首先需要对被测系统进行相关配置,以达到对应的测试前状态;然后选取对应的测试用例,进行接口调用后得到对应的返回结果。传统分类树方法,是将通过配置达到的测试前状态、调用接口及返回状态简单地罗列在一起。如图3所示,分类测试树将所有的属性都部署在叶子节点上,其中的任务属性子树属于测试前应配置的状态选项,返回状态子树则是调用OS服务子树相关服务执行后的状态选项。

任务属性子树中,部分属性属于不同的一致类级别,在分类树中并未划分。如图4所示,虚线框标注出了对应ECC1及ECC2级别一致类的任务属性;实线框则标注出了BCC2及ECC2级别一致类的任务属性。

在实际测试中,如果不符合该一致类级别的操作系统运行了包含该属性节点的测试用例,即使该操作系统符合自身一致类要求也无法通过一致性测试。因此,以往的一致性测试需要从测试序列中抽取符合要求的测试用例再进行组合。而该模块仅仅是AUTOSAR操作系统标准8个模块中的1个模块,整体测试计划涉及的抽取测试用例的工作量非常庞大。

3.2 决策表介绍与设计

决策表是分析和表达多逻辑条件下执行不同操作情况的工具,可将复杂的逻辑关系和多种条件组合的情况详细地列举出来,简单明了,且避免了遗漏,因此该方法具有较强的覆盖率和较好的测试效果。此外,对于相关规则以表格形式进行罗列,更易于理解和维护。决策表的一般表示如表2所示。

Figure 4 Subtree of affect task properties module
图4 影响任务属性模块子树

Table 2 General representation of the decision table
表2 决策表的一般表示

在表2中,ai表示可供选择的动作,i=1,2,3,…,m;θj表示动作实施之后呈现的状态,j=1,2,3,…,n;xij表示实施动作ai后,对应状态是θj的决策后果。决策表的定义可以相对灵活,对应动作和状态的设定可以根据不同的需求进行重制。

对于AUTOSAR操作系统而言,其一致性测试的本质是校验测试执行前后状态的转换是否符合要求。根据决策表的定义,可以对整体的测试用例设计进行重制,对一般的决策表结构进行分割,得出如图5所示的决策表结构。

Figure 5 Structure diagram of decision table
图5 决策表结构图

条件桩：列举出了AUTOSAR操作系统需要满足的属性条件、服务调用的不同状态。

动作桩：对应满足不同条件可能产生的结果,对应OS服务中不同情况调用下的返回值。

条件项：AUTOSAR操作系统属性及其服务调用的参数的可能取值。

动作项：产生返回值的可能取值。

在决策表中贯穿条件项和动作项的取值,即为对应的测试用例。在实际的测试用例设计过程中,根据决策表能够将各种可能的情况全部列举出来,设计出完整的测试用例。经过重制的决策表结构将对应的测试前状态和测试后状态进行了切割,相较分类树方法更具条理性。

3.3 基于一致类级别划分条件桩

目前常用技术为基于分类树的一致性测试用例设计,没有考虑对应属性节点的一致类级别的划分,虽然整体测试用例设计简洁明了,但是却无法针对单独的一致类级别进行测试。对应每个模块,如果需要通过所有的测试序列,就必须满足最高级别一致类的要求,这导致无法对部分实现了基础一致类功能的操作系统进行一致性测试。因此,提出基于一致类级别划分对应的条件桩,根据一致类级别设计对应测试用例。划分条件桩后的AUTOSAR一致性测试决策表如图6所示。

Figure 6 Conformance test decision table after dividing condition stubs
图6 划分条件桩后的一致性测试决策表

决策表可以对需要测试的值域进行完整的划分。由于每个类别上的类别和范围都是具备排他性的,决策表可以根据等价关系将测试套件划分为不相交和非空的子集。对于每一个系统调用API,该方法可以生成符合每种一致类的测试用例,进而使得测试用例可以针对不同一致类的操作系统进行有针对性的测试。对应不同的一致类,由于其内在的功能属于拓展关系,高级别一致类的测试用例可以对低级别的一致类测试用例进行复用,进而避免重复设计一致性测试用例。同时,对于接口调用的测试,基于一致类拓展的方法更具备针对性,后期对应功能的拓展也可以做到很好的适应,只需要在对应一致类级别的条件桩中添加新增功能需要的属性或API接口,即可新增需要的测试用例。

3.4 基于决策表设计测试用例

本节基于任务模块中调用较为频繁的ActivateTask()函数进行测试用例的分析与设计。对应4种一致类级别,将任务的优先级、状态、任务ID是否有效、任务是否达到最大激活次数根据一致类要求进行划分,并对当前决策表动作返回的各种结果进行划分,其中每一条基于条件桩和动作桩的组合可以生成一条测试用例,设计的决策表如表3所示。

在具体的决策表设计当中,针对该函数调用不同一致类级别生成了6,5,2,1条测试用例。以测试用例1为例,该测试用例属于BCC1级别,因此选取了不同的BCC1级别的条件桩和根据符合规范要求的结果项进行组合。而其他测试用例的生成也是基于一致类进行的延展。具体地,对应ECC1级别的测试用例是在BCC1级别的基础上增加2条涉及ECC1条件桩的测试路径,验证了被函数调用的任务处于WAITING状态的状态切换逻辑是否正确;对应ECC2级别也是在覆盖ECC1级别和BCC2级别测试用例的基础上做出的拓展,以验证扩展任务多次激活的具体性能。表3中设计的测试用例均是单独对应一致类级别的测试用例。在实际测试过程中,对应高级别一致类要求的被测系统只需要将低级别一致类测试用例与当前一致类级别测试用例进行组合即可进行该级别的一致性测试。

这种自底向上的测试用例生成方法,很大程度上减少了重复工作量,生成详尽而不重复的一系列测试用例,同时赋予每个测试用例以一致类属性,便于对不同一致类进行测试。

4 一致性测试实验

本文基于实验室开发的操作系统进行一致性测试。该操作系统支持4种一致类,参照的AUTOSAR官方规范文档版本为4.0.3,被测系统基于MPC5748G芯片平台,单片机主频为160 MHz,使用Vector VN1630A仿真CAN总线环境,一致性测试完成后将测试结果封装为CAN报文发送至上位机进行解析。

在实验中,被测系统在测试执行前已被验证一致性,通过配置将其设置在不同一致类级别来进行5个主要功能模块的一致性测试,进而查看不同一致类情况下2种方法生成的测试序列是否能有针对性地通过测试,以及无法通过测试的情况下需要额外抽取测试用例的数量,最终验证本文方法的有效性。测试前需要根据测试用例及配置将系统预先设置成对应的状态,以适应测试用例的运行,即图1中的检查预先情况是否符合要求。首先,对任务管理模块进行一致性测试,本文方法对应4个一致类生成了5,7,10,16条测试序列,测试序列生成时即拥有一致类属性,无需额外抽取测试用例即可通过对应每个一致类级别的测试。而传统的分类树方法生成的17条测试序列,由于并未提供针对单一的一致类级别的测试规划,对于每个级别的操作系统需要执行所有的测试序列,导致了只有符合最高级别一致类即ECC2的才能通过测试,对应其他每个一致类均需要抽取其中可测的测试用例才可以通过一致性测试。具体情况如表4所示。

Table 3 Decision table of activateTask() function
表3 ActivateTask()函数决策表

从表4可以看出,在对应不同一致类级别情况下,传统分类树方法需要分别从测试序列中额外抽取16,25,32条符合一致类要求的测试用例来进行一致性测试,才能够通过对应一致类级别的测试。所有被测功能模块的一致性测试通过情况如表5所示。

Table 4 Conformance test situation of TASK function module
表4 TASK功能模块一致性测试情况表

Table 5 Conformance test situation of main function modules
表5 主要功能模块一致性测试情况

具体地,传统的分类树方法针对不同模块均出现需要额外抽取测试用例的情况。其中,SCHEDULE TABLE功能模块由于测试序列最多,需要根据不同一致类的被测系统从生成的测试序列中抽取168条符合要求的测试用例,重新组合成新的测试序列来进行测试,耗费巨大。决策表方法生成的测试序列可针对不同一致类级别操作系统进行一致性测试,不需要进行额外测试用例的抽取,具备良好的针对性,节省了额外抽取测试用例的时间和精力,能有效提升测试效率。

5 结束语

本文提出根据决策表设计测试用例的方法,通过将决策表结构中的条件桩根据一致类进行划分,重新构造了一致性测试集,进而赋予每个测试用例一致类的属性,可以有效地对AUTOSAR架构操作系统进行一致性测试,一定程度上解决了传统方式针对性较差的问题;能够针对不同应用场景下不同一致类级别的操作系统进行一致性测试,省去了传统一致性测试方案抽取符合一致类级别测试用例的繁杂工作,在实验中针对5个主要功能模块的一致性测试避免抽取额外测试用例共计379条。此外,根据一致类划分条件桩得到的测试用例能够带来较高的复用性能,减少重复编写测试代码的工作量,在后期针对其他复杂模块进行一致性测试时能够有效地提升测试效率。未来的工作将根据本文设计方法对AUTOSAR操作系统的其他功能模块进行一致性测试用例的生成,以及面向其他AUTOSAR模块如CAN协议栈进行一致性测试。

参考文献：

[1] AutoSAR[EB/OL].[2021-12-07]. http：//www.AutoSAR.org.

[2] AutoSAR Partners, AUTOSAR_SWS_OS, specification of operating system[EB/OL]. [2020-11-10]. http：//www.AutoSAR.org.

[3] Sheng Yun-long,Wei Chang-an,Liu Yu-qi,et al. Modeling method for sequence testing with temporal constraints[J].Chinese Journal of Scientific Instrument,2019,40(6)：213-220.(in Chinese)

[4] Bechennec J L,Roux O H,Tigori T .Formal model-based conformance verification of an OSEK/VDX compliant RTOS[C]∥Proc of the 5th International Conference on Control, Decision and Information Technology,2018：628-634.

[5] Fang L,Takashi K,Do T B N,et al.Formal model-based test for AUTOSAR multicore RTOS[C]∥Proc of the 5th International Conference on Software Testing,Verification and Validation,2012：251-259.

[6] AutoSAR Partners, AUTOSAR_SRS_OS, requirements of operating system[EB/OL]. [2020-10-07].http：//www.AutoSAR.org.

[7] Zhang Zhi-xiong, Li Xi. Research on test of OSEK/VDX operating system based on CTM[J].Computer System &Applications,2010,19(11)：208-212.(in Chinese)

[8] Huysmans J, Dejaeger K, Mues C, et al. An empirical eva- luation of the comprehensibility of decision table,tree and rule based predictive models[J].Decision Support Systems,2011,51(1)：141-154.

[9] Wang Min,Xie Yong-ping.A new approach to test case design for multi-condition combination problem[J].Computer Applications and Software,2018,35(4)：21-27.(in Chinese)

[10] Shang Chuan-lei,Zhang Wu-yi,Chen Jun-ying,et al.Improvement and application of rough set attribute reduction algorithm based on decision table[J].Science &Technology and Economy,2019,32(5)：52-56.(in Chinese)

[11] Ma Bao, Luo Xiao-min, Tu Shi-liang,et al. Research on functional test of OSEK/VDX operating system [J].Computer Engineering,2012,38(6)：262-264.(in Chinese)

附中文参考文献：

[3] 盛云龙,魏长安,刘玉奇,等.时序约束条件下序列测试建模方法[J].仪器仪表学报,2019,40(6)：213-220.

[7] 张志雄,李曦.基于分类树的OSEK/VDX操作系统一致性测试研究[J].计算机系统应用,2010,19(11)：208-212.

[9] 王敏,谢永平.用于多条件组合问题的测试用例设计新方法[J].计算机应用与软件,2018,35(4)：21-27.

[10] 商传磊,张悟移,陈俊营,等.基于决策表的粗糙集属性约简算法改进及应用[J].科技与经济,2019,32(5)：52-56.

[11] 马保,罗晓敏,涂时亮,等.OSEK/VDX操作系统功能测试研究[J].计算机工程,2012,38(6)：262-264.