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

原创智能汽车开发者平台 2022-09-09 18:20

如何提升高压系统的实时性能? 如何增强电动汽车的实时控制能力？

摘要

汽车开放系统架构（AUTOSAR）操作系统规范为汽车嵌入式操作系统及其相关服务定义了一系列抽象的标准接口。传统的一致性测试案例设计方法存在高冗余度和低复用性的问题。本研究为AUTOSAR操作系统设计了一种基于决策表的一致性测试方法。决策表是表达事件逻辑相互依存关系的符号化手段，它可以详细列出复杂的逻辑关系和多个条件组合情况。通过对AUTOSAR标准操作系统的任务管理模块进行一致性测试实验，与传统方法相比，该方法消除了8个冗余的测试用例，而且决策表方法产生的与一致性类级别对应的测试用例也是可重复使用的，减少了16.3%的测试工作量。

I.简介

随着半导体和信息技术的发展，汽车电气和电子系统正变得越来越复杂。汽车开放架构（AUTOSAR）操作系统规范为汽车嵌入式操作系统和相关服务定义了一系列抽象的标准接口，这些接口独立于应用软件和硬件平台，并已获得广泛采用。

基于AUTOSAR标准的操作系统规范的广泛应用，给汽车电子的发展带来了巨大的进步，但也带来了新的挑战：由于AUTOSAR提供的统一规范都是抽象的要求，导致不同的开发商和服务商设计开发的ECU具有双重性，如何保证AUTOSAR规范在操作系统开发过程中的严格符合，成为一个亟待解决的问题。对于AUTOSAR操作系统来说，对系统服务接口的调用应该产生符合要求的结果，如果不同的操作系统在开发过程中不完全符合AUTOSAR操作系统开发规范，很可能在运行时产生各种错误。OS功能安全验证作为AUTOSAR架构OS开发的一个非常关键的部分，其中一致性测试发挥着重要作用。

一致性测试本质上是一种黑箱测试，其主要目的是验证被测系统的功能，为被测系统设计不同的环境和操作条件，通过比较其响应和行为来验证其是否与设计规范一致。其中一种一致性测试方法是基于形式化语言建立模型，通过数学方法证明具体实现是否符合一致性要求；另一种是基于测试用例的生成方法，如分类树、决策表、流程图等，设计测试集，并通过比较被测系统的测试集来验证一致性。参考文献[3]通过建立一个观察者模型，将测试用例转化为观察者的对象，实现了对OSEK标准操作系统的一致性测试，但是观察者模型的整体实现的开销很大。参考文献[4]提出了一种时间约束下的顺序测试的建模方法，该方法通过提出状态转移的允许区间来表示状态转移发生时前一状态的连续出现次数，从而扩展了状态转移的约束，但使用起来比较麻烦，可能会造成状态空间瘫痪的问题。参考文献[5]实现了多核AUTOSAR操作系统测试的形式化建模方法，通过实现临界锁定，大大抑制了状态空间，减少了状态空间瘫痪的可能性，显著提高了测试覆盖率，但尚未完成时序特性的建模，系统需要连续运行可执行的测试序列，以便覆盖尽可能多的测试案例。

AUTOSAR官方提供了一个基于分类树的一致性测试集生成方案和流程。这种方法节省了构建模型的时间，并消除了对其他语言的依赖性。文献[7]在此基础上利用分类树进一步优化了操作系统的测试集制作，并对中断管理模块进行了一致性测试。分类树方法相对简洁，可以更清晰地展示测试用例的设计过程，但在对现有操作系统进行频繁的一致性测试过程中，发现分类树方法没有对测试相关的元素如预测试配置、调用接口、通过标准等进行划分，而是简单地将其列在叶子节点中，这又导致一些属性节点存在属性重复，产生了一些重复的测试用例。此外，这种方法不允许测试特定级别的操作系统。目前，AUTOSAR提供了四个一致性类别（一种划分系统内核功能的机制），而这些等级没有统一的测试序列规划，因此测试人员需要自行筛选符合一致性等级要求的测试用例，这导致测试序列无法实现重复使用。

总之，需要新的测试方法来进行AUTOSAR操作系统的一致性测试，以提高测试效率，减少冗余。

决策表是表达事件的逻辑相互依存关系的符号化手段，包含与流程图、布尔代数和卡诺图有关的知识。测试用例的生成和许多安全应用都可以基于决策表来实现。在文献[9]中，通过分析因果表达式的语法可以实现决策表的简化，这可以提高多条件组合问题测试用例的设计和维护效率。这种方法保留了关键信息，获得了知识的最小化表达，但没有考虑输入边界的值，所以测试覆盖率不完整。

本研究为AUTOSAR架构操作系统设计了一种基于决策表的一致性测试方法。第一节介绍了AUTOSAR操作系统的一致性测试规范和流程，第二节分析了传统测试方案的问题，并有针对性地设计了新的测试方法。第三节设计了实验来验证新方法与传统方法相比的测试性能。第四节对整个论文进行总结。

II.Autosar操作系统

的一致性测试

释了相关术语的背景，B章简要介绍了一致性测试的基本流程，随后的章节对测试目的提取、测试用例设计、测试序列组合和验证等步骤进行了分解。

A.相关概念介绍

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

(1)一致性类别（Conformance Classes）：由于不同的功能要求需要操作系统的不同特性，如任务级别（基本/扩展），任务优先级，任务类别的概念。这四个一致性类别是相互继承和扩展的：

BCC1级一致性类是其他一致性类的一个子集，它限制了操作系统只能完成基本任务，任务不能被多重激活；ECC1可以存在扩展的任务；BCC2在BCC1的基础上取消了任务不能被多重激活的限制；ECC2级的一致性类可以在BCC2级增加扩展的任务。通过一致性类别的划分，可以更好地理解AUTOSAR规范中不同功能的定义，同时提供一个由浅入深的研发升级路径。在不同的应用场景中，需要根据要求设计与一致性等级相对应的操作系统，并对有限的资源进行修整。

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

(3)测试序列：对于一个特定的测试目的，需要多个测试用例的组合来验证相应的测试目的，而相应的多个测试用例的组合就是测试序列。

(4)测试路径：对于AUTOSAR操作系统的一致性测试，能够完全验证测试目的的测试序列运行路径称为测试路径，验证操作系统的一致性需要覆盖尽可能多的测试路径。

B.一致性测试的基本流程

对于AUTOSAR标准操作系统，首先根据官方设计规范[2]（AUTOSAR_SWS_OS）抽象出具体的测试目的，然后通过一些工具或方法为测试目的指定相应的测试用例，再通过具体组合形成测试序列，通过在实际操作系统上运行测试序列获得结果。最后，将测试结果与预期结果进行比较，以验证系统的测试功能是否与测试目的一致。只有在静态代码测试通过后，才能进行动态测试，静态代码测试的失败会直接判断为一致性测试的失败。在随后的动态测试中，需要执行测试序列，以获得每个测试步骤对应的检查点的结果，如果检查点的结果与预期相同，那么测试序列的一致性测试就通过。

对于不同的被测系统，一致性测试的过程可能有所不同。AUTOSAR操作系统的一致性测试可参见下图1。

图1. 操作系统一致性测试流程

C.抽样测试目的

由于AUTOSAR的规范本身是用抽象的自然语言描述的，因此有必要从其中提取可以评估的内容，即测试目的，而测试目的的提取需要考虑相应的一致性类别和任务是否可以优先处理等参数来设计。以基本系统配置模块为例，根据开发规范可以抽象出几个测试目的，如表1所示。

表一. 系统基本配置测试目的

在这个测试目的中，论断对应的是需要测试的目的，影响变量是对应的测试目的需要满足的一致性等级和调度策略，以及返回值类型。

D.设计测试用例

目前AUTOSAR标准操作系统的测试用例生成是基于文献[2]作为分类测试树的扩展方法，对于每个功能模块通过属性节点、执行动作、返回结果等建立不同的分类子树，在子树中列出相关属性给自己的叶子节点，然后组合不同的子树叶子节点，即可得到具体的测试用例。如果测试结果符合规范中对接口的定义，就被认为是通过了一致性测试。

E.设计测试用例

测试序列定义了在测试程序执行过程中要执行的操作顺序，也就是每个任务要执行的指令顺序。每个测试序列都完成了操作系统测试计划中定义的多个测试用例的测试。一个完整的测试序列定义需要包括使用测试用例的具体设置、一致性类、返回值类型、调度策略、任务和中断级别。

对于一个具体的测试序列，依次调用操作系统服务并获得结果，然后在每个相应的检查点与预期结果进行比较，如果获得的结果与要求一致，则认为该测试序列通过了一致性测试。一个常见的结果验证流程如图2所示。

图2. 操作系统符合性测试流程

III.决策表驱动的一致性测试

软件测试方法中使用的分类树方法，作为软件测试中常用的测试用例生成方法，其优点是简洁易懂，可以提供非常直观的意义表示，但传统的操作系统一致性测试方法存在可重用性差、冗余度高的问题，为此，本研究提出一种基于决策表的一致性测试方法，针对AUTOSAR操作系统进行一致性测试。A节将分析传统的分类树方法，而B节和C节提出了决策表的新方法，D节将为任务管理模块的ActivateTask()接口设计测试案例。

A.用分类树法分析测试用例的生成

一致性测试从被测系统的配置开始，以达到相应的测试前状态，然后选择相应的测试用例，进行接口调用，得到相应的返回结果。传统的分类树方法只是简单地列出了测试前的状态、调用的接口和通过配置实现的返回状态。以图3所示的任务管理分类测试树为例。

图3. 任务管理模块分类测试树

可以看到，分类测试树方法将所有属性都部署在叶子节点上，其中任务属性子树属于测试前需要配置的状态选项，返回状态子树是调用与服务执行相关的OS服务子树后的状态选项。虽然任务属性子树中的一些属性属于不同的一致性类别，在分类树中没有划分，如下图4所示。

图4. 任务管理任务属性模块子树

在上图4中，虚线框标志着ECC1级和ECC2级符合性类别对应的任务属性；实线框标志着BCC2级和ECC2级符合性类别的任务属性。在实际测试中，如果一个不符合一致性类别的操作系统运行包含该属性节点的测试用例，即使该操作系统符合当前的一致性类别要求，也不会通过一致性测试。因此，之前的一致性测试需要从测试用例中提取符合要求的测试用例，然后进行组合，而该模块只是AUTOSAR操作系统标准中的8个模块之一，整个测试计划涉及的提取测试用例工作量巨大。此外，由于BASIC任务通过增加相应的WAITING状态升级为EXTENDED任务，涉及BASIC任务的三个状态开关和涉及EXTENDED任务的三个状态开关是相同的，因此造成重复测试的问题。因此，需要一种新的一致性测试案例生成方法，以减少重复性的工作量，并针对特定的一致性类操作系统进行测试。

B.决策表的介绍和设计

决策表是分析和表达多个逻辑条件下执行不同操作情况的工具，它能详细、简明、避免遗漏地列举复杂的逻辑关系和多个条件组合情况，因此该方法具有很强的覆盖性，测试效果较好。决策表的一般表示方法如图5所示。

图5. 决策表的一般表示方法

在决策表中，ai 表示可用的行为，其中i=1,2,3,...,m；θj表示行为实施后呈现的状态，其中j=1,2,3,...,n；而xij 表示在实施选择行为ai后确定相应状态为θj的后果。决策表的定义相对灵活，相应的行为和状态的设置也可以根据不同的要求重新制定。

对于AUTOSAR操作系统，其一致性测试的实质是检查测试执行前后的状态转换是否符合要求。根据决策表的定义，我们可以重新表述整个测试用例的设计，得到如下图6所示的状态切换图。

图6. 基于决策表的一致性测试状态切换图

根据上图，基于AUTOSAR操作属性的特点，我们需要在决策表中进行划分，形成如图7所示的决策表结构。

图7. 决策表结构图

条件桩：列出属性条件，需要AUTOSAR操作系统满足的服务调用的不同状态。
行动桩：对应于满足不同条件的可能结果，对应于操作系统服务中不同调用情况下的返回值。
条件：AUTOSAR操作系统属性及其服务调用参数的可能值。
行动项：返回值的可能值。

C.基于符合性类别水平的条件桩的分类

传统的通过分类树进行一致性测试用例设计的方式，没有考虑对应属性节点的一致性等级划分，虽然整体测试用例设计简单明了，但不可能针对单个一致性等级进行测试，对应的每个模块如果需要通过所有测试序列，必须满足最高等级的一致性等级要求，这使得部分实现基本一致性等级功能的操作系统，无法进行一致性测试。因此，建议根据一致性等级划分相应的条件桩，并针对一致性等级设计相应的测试用例。划分条件桩后的AUTOSAR一致性测试的决策表如图8所示。

图8. 划定条件桩后的符合性测试决策表

该方法可以为每个系统调用API生成特定于每个一致性类的测试用例，对应于不同的一致性类别，高层一致性类的测试用例可以重复用于低层一致性类的测试用例，这是因为扩展关系的固有功能。同时，对于接口调用的测试，基于一致性类扩展的方法更有针对性，可以很好地适应后期相应功能的扩展，只需要在相应的一致性类级别的条件堆中添加新功能所需的属性或API接口，即可添加所需的测试用例。

D.基于决策表设计测试案例

本节将根据任务管理模块中调用频率较高的ActivateTask()函数来分析和设计测试案例。考虑到BCC1层，任务ID对应两个状态，任务本身有三个状态，对应任务的优先处理策略和优先级分别有两个和三个状态，我们根据这个条件设计对应决策表的条件桩，通过组合得到对应的结果桩。对于ECC1级别，等待状态被添加到相应的任务属性中，而对于BCC2和ECC2级别，任务激活的最大数量限制被从BCC1和ECC1级别中删除。根据前面提到的决策表框架，设计的决策表如图9所示。

图9. 激活任务()决策表

从上图可以看出，测试用例是在一致性类扩展的基础上生成的，ECC1级对应的测试用例是在BCC1级的基础上增加了两条测试路径，ECC2级对应的测试用例是在覆盖ECC1级和BCC2级的测试用例的基础上进行扩展。上图中设计的测试用例都是单独对应于一致性等级的测试用例。在实际测试中，与高层次的一致性等级要求相对应的被测系统只需要将低层次的一致性等级测试用例与当前的一致性等级测试用例相结合，进行该层次的一致性测试。

IV.一致性测试实验

在实际实验中，被测系统被配置为不同的一致性等级，以比较本研究方法与传统方法的具体一致性测试结果。首先，对任务管理模块中的ActivateTask()接口进行一致性测试，以验证本研究提供的方法所设计的测试用例的可重用性和相关性。结果如下表2所示。

表二. 激活任务()接口一致性测试表

从表中可以看出，该研究方法在实际测试中可以实现测试用例的重用，根据不同的一致性等级可以重用6到13个测试用例，其中BCC1级的测试用例可以在其他3个一致性等级的测试中重用，而传统的分类树方法不能重用测试用例，需要按顺序执行所有的测试用例。此外，该研究方法针对操作系统不同一致性类别的测试用例，节省了测试用例提取的工作量，而传统的方法只能通过ECC2级的测试，没有提取相应的测试用例，不能重复利用已有的测试用例。

为了验证测试用例的冗余度，本实验对AUTOSAR任务管理模块的六个API功能，通过决策表法和分类树法进行测试用例设计的结果进行了比较。主要指标是在相应的设计测试集中是否设计了冗余的测试用例，并列出了冗余的原因。详细的测试用例设计见表3。

表三. 任务管理模块测试用例设计情况表

具体来说，本文根据一致性类扩展设计的测试用例避免了冗余的测试用例设计，而在分类树的不同API接口中存在一些冗余的测试用例，其中ActivateTask()函数、ChainTask()函数、GetTaskID()函数和Schedule()函数都有1~4个冗余的测试用例。造成测试用例冗余的主要原因是分类树属性节点的罗列没有考虑到属性的包含关系，例如，基本任务的三个状态和扩展任务的四个状态中的三个完全相同，所以扩展任务的三个相同状态所对应的测试是重复的。因此，扩展任务的三个相同状态的切换测试是重复的测试，这就导致了文件任务管理模块中的测试序列13和测试序列15具有相同的内容。本文提出的决策表方法避免了在不同的一致性类别中列出重复的属性节点，减少了重复测试案例的产生。

V.总结

本研究提出了一种基于决策表的测试用例设计方法，可以有效地对AUTOSAR架构的操作系统进行一致性测试，在一定程度上解决了传统方式的高冗余度问题，减少了重复测试用例的产生，而根据一致性类别划分条件桩得到的测试用例可以带来高复用性能，减少重复测试代码的编写，在后期对其他复杂模块的一致性测试可以有效提高测试效率。此外，该方法可以很好地适应未来AUTOSAR功能的扩展，对于自下而上的开发，本研究提供的测试用例也可以适用于测试目前已完成的一致性类水平，节省了提取测试用例的工作量，具有更好的针对性。后面的工作将根据本文的设计方法，为AUTOSAR操作系统的其他功能模块设计一致性测试案例，以及AUTOSAR其他模块的一致性测试，如CAN协议栈。

参考文献：

[1]AutoSAR Partners. http://www.AutoSAR.org. 2020-11.

[2]AutoSAR Partners. AUTOSAR_SWS_OS,Specification of Operating System,http://www.AutoSAR.org. 2020-11.

[3]Sheng, Y. L., Wei, C. A., Liu, Y. Q., et al. A modeling approach for sequence testing under timing constraints[J]. Journal of Instrumentation, 2019(6):8.

[4]Bechennec, J. L., Roux, O. H., & Tigori, T. (2018). Formal model-based conformance verification of an OSEK/VDX compliant RTOS. International Conference on Control.

[5]Fang, L., Kitamura, T., Do, T. B. N., & Ohsaki, H. (2012). Formal model-based test for AUTOSAR multicore RTOS. IEEE Computer Society.

[6]AutoSAR Partners. AUTOSAR_SRS_OS,Requirements of Operating System,http://www.AutoSAR.org. 2020-11.

[7]Zhang Z. X.,Li X., Research on OSEK/VDX operating system conformance testing based on classification tree[J]. Computer System Applications,2010,19(11):208-212.

[8]Johan, Huysmans, and, et al. An empirical evaluation of the comprehensibility of decision table, tree and rule based predictive models[J]. Decision Support Systems, 2011.

[9]Wang M, Xie Y P. A new approach to test case design for multi- conditional combination problems[J]. Computer Applications and Software,2018,35(04):21-27.

[10]Shang, C. L., Zhang, W. Y., Chen, J. Y., Li, J. L. Improvement and application of decision table-based rough set attribute approximation algorithm[J]. Technology and Economics,2019,32(05):52-56.

[11]Ma, B., Luo, X. M.,Tu, S. L., Shen, H., Qiu, Rui. Study on functional testing of OSEK/VDX operating system [J]. Computer Engineering,2012,38(06):262-264.

END

分享不易，恳请点个【👍】和【在看】

登录阅读全文



免责声明：该内容由专栏作者授权发布或作者转载，目的在于传递更多信息，并不代表本网赞同其观点，本站亦不保证或承诺内容真实性等。若内容或图片侵犯您的权益，请及时联系本站删除。侵权投诉联系： nick.zong@aspencore.com！

智能汽车开发者平台分享汽车最新前言技术解读，行业分析，与授权行业资料分享平台。

进入专栏

智能汽车开发者平台分享汽车最新前言技术解读，行业分析，与授权行业资料分享平台。

文章：470篇粉丝：31人

 私信

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

最近文章

热门文章

推荐

最新资讯