需求模型下的航天软件测试用例方法探讨

摘 要 为了解决随着软件规模和空间系统复杂性的增长，“空间模型在软件开发周期中的缩短”导致软件开发效率不足的问题，例如通过引入新的空间软件开发方法，模型驱动软件开发方法，模型驱动的软件开发方法采用“开发人员构建图形模型，由模型代码自动生成”模型，以提高软件开发效率，并具有正式的验证功能，以确保代码与模型的一致性。然而，模型驱动的软件开发方法不仅提高了航天模型软件的开发效率，而且还挑战了传统的软件测试方法。尽管目前在航空航天领域有相对完善的测试方法系统，并且部分测试工作可以自动执行，但是这些传统的测试方法基于需求文档的测试，因此无法应用于模型驱动的开发软件。如何有效地测试模型驱动的航空软件已经成为迫在眉睫的问题。

关键词 需求模型下;航天软件测试;用例方法

引言

随着各种航空技术的发展，航空软件的规模和复杂性也在增加。另外，航天模型的开发周期呈现出逐渐缩短的趋势，这导致传统软件开发模式无法满足航天模型软件开发的效率和可靠性要求。作为提高软件开发效率的解决方案，模型驱动的软件开发方法受到了越来越多的关注。目前，模型驱动软件开发方法已广泛应用于航空，轨道交通等高安全性实时嵌入式领域，航空航天领域已经尝试了模型驱动软件开发方法，并取得了一定的成果，验证了软件开发方法在航空航天领域的可行性。然而，新的软件开发模式不仅为“开发效率低下”的问题带来了解决方案，而且还带来了新的问题：如何有效地测试由新模式开发的软件。

1 基于数据流图的测试用例自动生成方法

在以前的基于数据流图的用例生成研究中，通常采用路径遍历的方法来规划测试用例中的每条路径。这种方法的缺点是无法建立输入和输出之间的关系，并且某些路径不可达，从而导致冗余的测试用例。因此，本文通过将输入输出映射表添加到数据流程图来设计用例生成方法。根据需求分析的完整性，使用数据流程图的测试用例设计分为两种情况：

①当前测试项目的数据处理节点中有一个输入输出映射表，或者虽然没有输入输出映射表，但是在其子图中的所有处理节点中都有一个输入输出映射表，因此父节点的输入-输出映射表可以自动从子图导出。在这种情况下，根据从节点本身或子图自动导出的输入输出映射表，如果表中有空格，则表示该行中空格对应的输入变量的值不会影响输出，并且变量定义中的值范围将添加到表中。然后，将表中的每一行计划为一个测试用例，用于检查输入表中指定范围内的数据时是否可以获得预期的输出。②当前测试项目的数据处理节点不存在输入输出映射表，也不能通过子图自动导出。在这种情况下，由于无法确认输入和输出之间的关系，因此可用于生成辅助测试用例。辅助测试用例仅包含输入变量的值范围。如果子图中输入变量的输入节点处有输入输出映射表，则通过映射表确定输入变量的值范围;否则，通过定义变量获得值范围[1]。

2 基于状态迁移图的测试用例自动生成方法

状态迁移图生成的用例应涵盖模型中的所有状态和状态迁移。像数据流程图一样，状态迁移图也可以抽象为有向图，状态抽象为有向图的节点，状态迁移也抽象为图的有向边。通过遍历有向图，可以获得所有状态迁移路径，并且将每个迁移路径计划为测试用例。用例应将路径中的所有状态迁移条件作为输入，并将路径中的状态迁移序列作为预期输出。通常，状态测试序列越长，错误暴露的可能性就越高，因此，设计的测试用例的错误纠正能力也就越强。基于此原理，深度优先算法更适合于路径遍历。通过分析状态迁移图的组成结构，主要有三种形式：①时间状态迁移图的特征在于，从一个状态向另一个状态进行正向迁移之后，没有反向迁移到先前状态的情况，即状态迁移是单向的。这种类型的状态迁移图可以抽象为有向图，并表示为树图。传统的深度优先算法可用于完成所有路径的遍历。②紧密连接的状态迁移图，即状态迁移图中的任何两个不同状态都具有可相互访问的迁移路径。从这种状态迁移图抽象出来的有向图将包含大量循环，因此很难直接遍历有向图。因此，可以考虑在遍历状态迁移图之前对其进行预处理。③将以上两种类型的状态迁移图组合在一起，即状态迁移图具有几个紧密连接的组件，但本身不是一个紧密连接的图。从这种状态迁移图抽象出来的有向圖也是带循环的有向图，不能直接遍历。首先，可以减少图中的强连接分量，并且可以将强连接的分量抽象为图的节点，以获得无环的有向图。然后，可以基于深度优先的路径遍历图。最后，可以计算每个牢固连接的组件的路径以补充深度优先遍历的路径[2]。

3 基于控制表的测试用例自动生成方法

在传统的手动测试方法中，决策表是重要且常用的需求分析和描述工具。判断表通常由条件堆，动作堆，条件元素和动作元素组成。其中，条件元素和动作元素分别代表输入条件和输出动作。条件堆是一组条件元素，枚举所有输入条件，动作堆是一组操作元素，枚举所有输出动作。测试人员通过覆盖决策表中所有可能的条件元素组合和相应的动作元素组合来设计测试用例。控制表可以视为传统决策表的变体。控制表的控制输入对应于决策表的条件堆，控制输出和处理激活对应于动作堆。因此，可以根据传统决策表测试用例的设计思路和方法生成基于控制表的测试用例，即完成控制表中控件输入，控件输出和处理激活的覆盖。显然，可以通过将控制表的每一行都计划为测试用例来满足测试元素的完全覆盖的要求。

4 结束语

本章主要介绍以下内容：解释了使用需求模型自动生成测试用例的整个思想;分析了模型存储格式，并通过XML解析技术提取了生成测试用例所需的模型信息;建立了自动划分测试项目的规则。分析了数据流图，状态迁移图，控制表和顺序图，并开发了基于不同类型模型的测试用例生成策略，然后设计了相应的测试用例生成算法。

参考文献

[1] 左万娟，虞砺琨，王小丽，等.基于共性需求的软件通用自动化测试设计研究[J].计算机技术与发展，2020，30（6）：49-54.

[2] 刘梦飞.航天软件测试用例设计质量的评估及提升[J].质量与可靠性，2020（2）：39-41，45.

作者简介

陈海燕（1983-），女，广西玉林人;学历：本科，研究方向：软件工程/软件测试。