1 背景

前文讨论了UML活动图分析及用例生成实例。能够利用UML/SysML活动图模型生成测试用例，对软件或系统进行验证，自然是极好的。那是不是有了活动图模型，就可以生成用例呢？从我们看来，还有些问题需要澄清。

新时代新做法，有问题先ChatGPT一下。

这个回答中，包含了我们认为重要的两个问题，即：

（1）明确性：UML活动图是否遵循了UML规范所规定的语法、语义？

（2）可测试性：UML活动图是否包含了能够生成测试用例的必要信息？

2 明确性：是否设计了合规的活动图？

UML规范规定了活动图的表示法（notation）和语义（semantics）等。但是实际的UML活动图模型经常不符合UML规范。这导致对UML活动图进行程序分析时，或者发生错误，或者提取的语义与模型设计者预想的不一致，从而后续的用例生成也是无效的。

之所以出现这种情况，认为至少有如下两方面的原因。

第一个原因是对UML规范理解不足，用visio之类工具画流程图的方式，来使用UML活动图。

下图给出了一个不规范实例。

上图包括两方面的问题：

（1）Action1节点有两个入边。建模人员意图表示活动PreA及PreB都执行完后，Action1执行；但是，在UML语义下，只要PreA及PreB任意一个活动执行完，则Action1开始执行。

（2） Action1节点有两个出边。建模人员意图表示Action1执行完毕后，PostA及PostB都开始执行；但是，在UML语义下，PostA、PostB仅有一个能够执行，且不确定哪个得到执行。

对该实例，在Action1节点前应加入join节点，在其后应加入fork节点。

还有一种常见的对decision节点的误用，如下图：

虽然人可以理解上图，但不符合UML规范。更恰当的表示应如下图：

UML活动图不规范的第二个原因，是UML活动图主要作为一种设计、分析手段，一般来讲UML活动图是不能执行的。这导致一方面工具对UML活动图的语法检查不严格；另一方面由于不能执行，UML活动图表达的语义得不到反馈确认。

在基于UML活动图生成测试用例的过程中，需要对活动图进行语法检查及语义转换。这能够促进UML活动图的规范性。

3 可测试性：是否包含了足够的信息？

从UML活动图生成的用例，是一种“面向功能”的测试用例，需要至少包括测试输入、期望输出。这意味着（或者要求）从UML活动图模型中能够提取输入、输出，对各个分支约束条件能够进行计算。更具体的要求还包括：对UML活动图中使用的变量，应定义其数据类型、取值范围、默认值；guard表达式应符合规定的语法等。例如，对下图的例子，应指定cmd变量的类型（整型或枚举）、取值范围，则可以获得覆盖决策节点每个分支的可执行用例（即包含了变量cmd的具体值）。

然而，实际的UML活动图模型往往达不到这样的精细程度。这是否意味着用例生成不能发挥作用了？

用例生成仍然可以发挥作用，只是目标改变了。此时，可以生成测试场景（test scenario）。例如，对于一个描述系统功能的UML活动图，可以提取出全功能模式、降级模式、故障模式等场景。

测试场景的提取是结构化的，类似用例生成，同样可以定义覆盖目标，例如活动覆盖、迁移覆盖、路径覆盖等。每个场景中，包含了活动序列、迁移约束条件（此时对约束条件只表示、不求解）。基于提取的测试场景，通过人工处理、补充信息，可以进一步生成具体可执行的测试用例。

下图给出了一个场景提取实例，也即活动图的一个路径（详见UML活动图分析及用例生成实例）。

4 总结

本文说明了基于UML活动图生成测试用例时，常见的两方面问题，即模型的规范性和可测试性。

基本的和首要的，设计UML活动图模型应符合UML规范的语法、语义。

另一方面，我们的出发点是最大程度发挥已有UML活动图的价值。即使UML活动图模型存在设计不规范、信息不完全，也可以生成有价值的“测试场景”。

反过来，通过对UML活动图的程序化、形式化分析，可以发现对活动图的不恰当使用，促进活动图的规范性；这使设计的活动图更有效的支持开发、测试。这是一个迭代过程。

最后再ChatGPT一下。