带内部状态的多需求耦合用例生成

1 背景

前文讨论了“判定逻辑的测试用例生成实例”、“分支逻辑的测试用例生成实例”，本文讨论带内部状态的多需求耦合测试用例生成实例。

本文讨论的实例，包含如下特点：

（1）存在不可观测的内部变量，导致单个需求无法生成有效用例；

（2）存在由历史输入决定的内部状态，系统当前输出依赖历史输入；

（3）多个需求条目之间相互耦合，但是分散分布，没有显式的表明其依赖关系；

上述特点在需求中较常见，也是人工进行需求检查、用例生成时较为困难的情况。本文通过具体实例，说明OneLogic如何处理此类需求。

2 实例

2.1 需求描述

Req01：当舱温（cabin_temperature）大于等于 68℃，保持时间超过2s但不超过10秒，则触发短时超温事件(short_time_overtemperature)；

Req02：当舱温大于等于 68℃，保持时间超过10秒，则触发长时超温事件(long_time_overtemperature)；

Req03：当发生短时超温事件时，短时超温次数（counter_of_short_time_overtemperature）加1；

Req04：如果短时超温次数大于等于3，则超温告警（overtemperature_warning）；

Req05：当长时超温事件发生后，则超温告警；

Req06：当长时超温事件发生，则短时超温次数复位为0；

2.2 需求特点讨论

2.2.1 存在不可观测的内部变量

在基于需求的测试中，被测对象（SUT）被看作“黑盒”，仅能通过被测对象的外部可观测变量或其与外部环境的交互消息，来验证其是否满足设计需求。

然而，在实际系统测试中，经常存在由不可观测的系统内部变量作为参数的逻辑，导致无法生成有效测试用例。这是因为，系统内部变量不能被直接设置，不能作为激励信号，从而导致需求无法测试。

如果从系统的角度，可能在需求的其他部分，直接或间接的描述了这些系统内部变量与外部输入的逻辑关系。然而，由于系统是如此复杂，需求描述方式是如此多样，很难全面梳理清楚逻辑关系，也就导致部分测试无法进行。

在本例中，短时超温次数是一个不可观测的系统内部变量。虽然本例相对简单，但也可管窥工具是如何处理不可观测变量的。

2.2.2 存在由历史输入决定的内部状态

本例中的短时超温次数还是一个由历史输入决定的内部状态，该状态受多种因素影响，既可以递增又可以复位。如何在各种影响因素中，找到一个恰当的时间序列，以驱动系统达到所需的状态，往往较为费时费力。

2.2.3 多需求关联

一个系统的期望行为由包含多个条目的需求集合来描述。如何组织需求有不同的策略。可以基于场景来组织需求，也可以将各个场景的需求进行综合。一般来说，每个需求条目往往是一个逻辑片段，这些逻辑片段之间存在相互作用的耦合关系，共同决定系统的期望行为。

实际中，存在耦合关系的需求条目可能是分散分布的，这也给需求分析带来了困难。

本例中需求条目之间，即存在多种相互关系，会影响用例生成。

2.2.4 串行 or 并发？

在“分支逻辑的测试用例生成实例”中，讨论了需求条目的先后顺序与逻辑上的先后顺序的关系。在特定情况下，需求条目的先后顺序可以解释为实际逻辑的顺序，也即需求逻辑是串行的。

本文中，考虑更一般的情况，不假设需求条目的先后顺序意味着逻辑上的先后顺序。也即，各条需求是并发执行的，而不是按照需求条目的组织顺序串行执行。

将需求处理成并发的，所带来的好处，是不依赖各个需求条目在组织上的先后顺序，允许各个需求条目分散分布，仅根据相关性被关联起来进行联合分析。这更好的符合实际工程情况。

对本例来说，需求条目的先后次序，不影响分析结果。

3 需求结构化

将上述需求转化为逻辑图，如下图所示。

可见，从自然语言需求转换为结构化需求，是一种比较直观的映射，仍然保持了类似自然语言的可读性。

转换为结构化需求时的一种顾虑是所谓“关键字”问题，更高层次的需求，命名更偏向领域应用，而与最终实现（例如ICD）差距较大。在OneLogic中，可以直接使用原始名称（例如cabin_temperature，可直接使用“舱温”来命名），进行需求编辑，不影响分析。

4 需求关系分析

采用OneLogic工具，对需求进行关联关系分析，可得如下关系图。

图中给出了各个需求之间的依赖关系。这提供了一个理解系统输入、输出信号在各需求间传递关系的视图，非常有助于排查需求设计上的各种问题，例如不匹配信号、不期望路径等。

5 用例生成

5.1 含不可观测变量的用例生成

对如下需求生成用例：

Req04：如果短时超温次数大于等于3，则超温告警；

上述需求中，短时超温次数为不可观测变量，但有其他需求对该变量进行设置。即：

Req03：当发生短时超温事件时，短时超温次数加1；

Req06：当长时超温事件发生，则短时超温次数复位为0；

而Req03中的短时超温事件又是由下述需求描述：

Req01：当 舱温大于等于 68℃，保持时间超过2s但不超过10秒，则触发短时超温事件；

上述4个需求是相互关联的。要人工生成满足Req04条件的测试用例，需要根据Req01、Req03、Req06需求仔细设置 舱温 的时序，构造编写测试序列，是费时费力的工作。

OneLogic自动生成的用例如下图所示。

可见，OneLogic自动对Req01、Req03、Req04、Req06需求进行联合分析，3次触发短时超温事件，获得满足各个需求时序约束关系的激励序列，实现对Req04动作（action）的覆盖。

5.2 另一个用例

对如下需求生成用例：

Req05：当长时超温事件发生后，则超温告警；

Req05中的长时超温事件由下述需求描述：

Req02：当 舱温大于等于 68℃，保持时间超过10秒，则触发长时超温事件；

OneLogic生成用例序列如下图所示。可见，OneLogic在序列中设置 舱温 值并满足10s持续时间，从而覆盖Req05的动作。

6 总结

本文讨论的带内部状态的多需求耦合测试用例生成实例，体现了对实际需求进行缺陷检查、用例生成时的一些困难情况，包括大量需求耦合关联在一起；存在不可观测的内部变量；系统当前行为依赖历史输入等。

对上述情况，OneLogic工具通过需求关联关系提取、多需求并发联合分析等方式，实现了程序化用例生成。对工程上某些人工不易处理的问题，OneLogic提供了一种通过计算方法来解决的途径。