基于模型的嵌入式软件测试技术研究

基于模型的嵌入式软件测试技术研究

段勇

江南机电设计研究所，贵州，550025

摘要：随着嵌入式系统在生活中不断普及, 对相关产品的质量性、可靠性等要求也越来越高, 特别是在电控系统领域, 功能安全已成为衡量产品的一项重要内容。电控系统属于嵌入式系统的一种, 本文以嵌入式软件测试为出发点, 着重对采用新型开发模式, 基于模型设计的电控系统嵌入式软件层面进行测试技术研究。

关键词：嵌入式软件测试;电控系统;基于模型设计;

基于上述背景, 本文首先介绍嵌入式软件测试的基本概念及方法;之后比较传统嵌入式软件开发与MBD开发模式的区别;进而着重分析MBD开发模式下的嵌入式软件测试即模型在环, 并以相关电控系统模型为例, 研究模型在环测试技术;最后对全文进行总结。

1 嵌入式软件测试

静态测试、动态测试是嵌入式软件测试的两种主要形式。相对于静态测试而言，不需要运行被测试的程序，重点是检测语法的错误、是否符合编码规则、代码逻辑，一般比较常见的静态检测工具包括splin、PC-Lint、cppcheck。动态检测技术实际上一种黑盒的测试，其实是在程序运行的时候注入数据，看测试结果和预期能否相吻合，进而更好的找到程序漏洞。模块测试与应嵌式软件测试V流程前半部分的设计对应着，也叫做单元测试，被测试的对象是可测的最小单元，进一步检查各单元能否根据设计达到预期目的，这就是白盒测试的主要范围。完成单元测试后再做集成测试。其实集成测试是为了发现模块和接口间存在的有关问题。

2 模型在环和传统嵌入式软件对比

现阶段，电控系统趋于复杂化，以往开发的形式不适用了，基于模型设计的使用可以充分加快开发的周期，并整体提高了软件的质量。而模型开发模式的特点是不光详细叙述了所有想要的功能，还详细提升了设计的实际信息，并成为代码生成的基础内容。对于传统开发模式的缺点来说，模型设计在整个过程里是互相验证，又是密不可分，互相联系的，耦合性比较高，规避了某一流程的独树一帜性质。流程里持续验证与设计，从需求到设计，始终将每个流程都贯穿进去。

3 基于模型的测试流程和关键技术

3.1 基于模型的测试流程

MDD模式，可将软件的测试验证工作大大前移，并在需求分析、概要设计、详细设计、代码生成等全生命周期执行基于模型的测试和迭代验证，开发和测试是螺旋前进的，互相验证，可规避如瀑布模型、V模型等某一流程的固有缺陷。其支持在开发过程的不同阶段，分别构建模型在环(需求模型、设计模型在环)、代码在环(基于模型生成的代码在环)、产品在环(基于模型生成的代码加载到处理器等产品环路)的多级软件测试过程。该验证方式区别于传统验证，具有手段单一、效率低的特点，其成本更低，效率更高，敏捷性和灵活度更好。

3.2 基于模型的测试技术

3.2.1 静态验证技术

在软件系统需求分析、概要设计、详细设计等早期阶段，可以进行模型的早期验证。主要技术手段有软件形式化验证技术和故障树分析法，其中形式化验证技术又分为定理证明和模型检验2种。通过模型的静态验证，可以在需求分析和设计早期，找出数据流不匹配、死循环等一系列错误，并提早进行错误定位，及时归零。

(1)定理证明为使用逻辑的语言和方法对软件中的算法、逻辑等进行规约描述，明确软件适用的公理，建立软件的推理规则，依据公理和推理规则证明软件的功能正确性。

(2)模型检查技术在具体使用时，可借助基于时间自动机模型的分析、SysML块依赖图模型的分析、基于状态事件故障树模型的分析等方法来开展。

3.2.2 测试需求模型的构建技术

依据软件业务逻辑、接口数据元素、接口约束、FTA故障树、FMEA软件失效模式等分别识别软件功能测试需求，性能、接口、边界、安全性等非功能性测试需求，以此确定测试需求的内容、范围及边界。

对软件测试需求进行建模主要有软件功能性测试需求建模、非功能性测试需求建模。多数情况下，功能性测试需求模型可由软件需求进行分解、合并后得到，使用UML语言中的用例图、活动图、状态图、时序图等对功能性测试需求建模。

3.2.3 测试规程描述和生成技术

依据软件功能性测试需求模型、非功能性测试需求模型，识别软件全部的基本事件、基本路径、异常路径，生成测试用例集。

(1)依据基本逻辑生成测试用例规程。

依次对照功能性测试需求模型、非功能性测试需求模型，提取模型数据文件中面向相关功能、过程的逻辑信息、状态迁移条件、时序信息等过程信息，结合逻辑信息、状态迁移条件、时序信息生成测试用例规程。

(2)依据接口元素模型生成测试用例输入。

依次对照功能性测试需求模型、非功能性测试需求模型，提取模型数据文件中面向相关功能、过程的数据源、数据目的、接口约束等信息，结合测试框架，生成测试输入。在测试用例输入数据的生成方面，可借助传统的测试用例数据生成方法，如等价类、边界值，生成面向工程实践的最优解。

3.2.4 测试驱动和测试框架构建技术

针对功能性、非功能性测试用例模型，利用建模工具如Rhapsody、Scade构建支持单个用例运行的软件测试驱动，并提前设置测试用例的预期结果，自动判读是否执行通过；利用建模工具构建软件测试框架，支持测试用例的批量运行和批量判读。测试框架可理解为贯穿基于模型的整个测试过程的软件架构，其支持软件测试用例的自动化批量执行、自动判读，在Rhapsody、Scade工具中可使用功能结构图、类图等对软件架构建模。

3.2.5 测试充分性评估方法

测试充分性评估方面一般使用测试需求的覆盖率分析、结构覆盖分析(SC覆盖、DC覆盖、MC/DC覆盖)、数据耦合覆盖和控制耦合覆盖分析等方法，辅以软件最坏运行时间(WCET)和堆栈内存分析等方法保证基于模型的软件测试的充分性要求。具体有如下要求。

(1)测试需求的覆盖率分析，应开展如下分析： ①针对每一条标识的高层需求都有一条或多条测试用例通过追踪矩阵来对应，该追踪矩阵用于验证高层需求是否被实现； ②针对每一条测试用例在追踪矩阵里都有一条或多条高层需求相对应； ③测试用例应包括正常和鲁棒性测试。如通过SCADE Suite MTC覆盖率的评审来证明SCADE 模型对高层需求的覆盖率满足要求；基于需求的测试可能不能完整地达到模型覆盖率要求，因此模型覆盖率可以通过附加验证来达到要求，如分支覆盖。

(2)SC覆盖和DC覆盖分析基于源代码进行，使用Testbed、SCADE MTC工具分析和人工分析相结合的方法。

(3)针对代码在执行基于需求的测试，覆盖率未达到时，应执行附加分析，含以下4种情况： ①需求不充分。比如缺鲁棒性需求，需求需要修改或完善，从而产生附加的测试用例/规程。 ②测试不充分。应当补充测试用例/规程。 ③附加代码。附加代码可以保留在源代码中，但不能在目标代码中，软件生成过程(如：通过编译或链接去除)应保证其不会出现在目标代码中。 ④非激活代码。应当做一些组合的测试和分析来证明非激活代码不会被意外地执行或工作。

总结

本文首先介绍了简单介绍了嵌入式软件测试发展的背景, 并引出电控系统嵌入式软件测试;最后对全文进行了总结, 在新型开发模式的来临之时, 同时也要对测试技术加以提升, 保证软件产品的质量及功能安全性。

参考文献

[1]谭琪璘，梁欣颖.基于模型的嵌入式应用软件设计研究[J].信息通信，2018(3):110-111.

[2]秦凯，王楠，王海鹏，等.面向航天领域的模型驱动软件设计开发方法[J].航天控制，2017(5):74-79.

[3]王锐鑫，赵中华，沈国荣，等.基于模型的嵌入式软件开发研究[J].信息与电脑，2020(6):109-111.