模型驱动测试如何生成基于代码的测试结果

模型驱动测试可以将需求与设计联系起来，帮助开发人员以一种通用语言生成结果，将设计过程中的每个人联系起来。这改善了工作流程并清楚地传达了设计。

在系统和软件测试社区中，生成基于代码的结果被认为是软件测试的黄金标准。但是，软件复杂性的增加和上市时间的缩短迫使许多组织重新考虑他们如何处理测试过程。随着基于模型的测试 （MBT） 的引入，开发人员获得了更快的自动化流程，可以帮助他们获得完整的模型和代码覆盖率。

即便如此，一些开发人员认为 MBT 未能达到预期，因为它没有提供基于代码的结果。然而，随着 MBT 技术的最新进展，这种看法不再准确。新的 MBT 工具使测试人员能够通过基于代码的结果实现性能分析、内存分析和代码覆盖。

模型驱动测试 （MDT） 流程通过让开发人员在实际应用程序上执行场景并执行这些测试来增强此工作流程。但关键问题是开发人员在运行这些基于场景的测试时需要基于代码的测试结果。

入门

MDT 方法可以帮助组织满足紧缩的上市时间窗口，因为它允许开发人员使用他们设计时使用的相同语言进行测试，即统一建模语言 （UML）。除了节省时间之外，MDT 还提供了另一个优势，它以场景为需求，使测试与客户的规范保持一致。

尽管 MDT 提供了许多好处，但批评者强调它有一个弱点：缺乏基于代码的测试结果，这对于调试故障、泄漏和性能差距至关重要。

在深入探讨有关基于代码的测试的问题之前，让我们解释一下 MDT 过程。基于 UML 的测试用例可以用许多不同的格式编写，包括 UML 序列图、流程图，甚至代码（使用断言样式语句）。简而言之，MDT 流程迫使开发人员以上述格式之一阅读他们的需求并基于它们设计场景。接下来，将模型构建到满足这些场景的可执行文件中。然后将原始场景转变为测试。最后，在软件经过 MDT 过程之后，这些相同的场景可以作为测试执行。

使用传统代码和流程图来捕获测试用例行为

可以使用代码或流程图或序列图来描述测试用例行为，提供比传统编码更高的生产力。使用代码描述测试用例与目前描述测试用例的过程基本相同，不同之处在于，如图1所示，测试用例需要关注刺激和预期结果。测试用例执行的上下文是从模型中自动生成的。

图 1：开发人员可以使用代码来描述测试用例的纯粹行为。

捕获代码中的测试用例行为并让它执行是利用 MDT 的最直接方法，而且风险最小且几乎没有学习曲线。这种方法的另一个优点是它允许轻松重用现有的基于代码的测试用例。但是由于测试用例行为的逻辑通常很重要，开发人员倾向于将测试用例描绘成非正式的流程图。由于将流程图映射到代码相对简单，MDT 环境允许开发人员将测试用例行为捕获为流程图，从该流程图生成测试代码，将其链接到测试架构，然后运行测试。

将测试用例描述为流程图，如图 2 所示，具有与编码相同的表达能力，但它更容易捕获并与项目的所有利益相关者进行沟通。

图 2：在流程图/活动图中比在代码中更容易捕获测试用例行为。

用序列图描述测试用例行为

序列图提供了在基于代码的测试环境中很少使用的设计的独特视图。这些图可以描述整个系统和与之交互的参与者之间的操作场景。在其他情况下，它们可能包括有关内部设计组件之间消息的排序和交换的详细信息。

在系统级分析期间，设计人员确定了许多高级需求，并且大多数行为需求被描述为序列图。这构成了系统分析师创建基本要求的许多变体以及基本要求的“未雨绸缪”排列的过程的基础。此过程将作为序列图捕获的高级需求转换为具体的测试用例。

开发人员可以查看描述需求的序列图并将其作为测试用例以交互方式应用，将输入注入被测系统并检查输出以查看它们是否与序列图中定义的匹配。这些测试的来源包括记录应用程序的执行并手动编写它们。每个来源都有自己的好处。记录执行不测试需求，但有助于回归测试。手写序列在测试需求中很有用。无论如何创建测试，都需要基于代码的结果。

实现基于代码的结果

今天的开发人员可以通过多种方式获得基于代码的结果，所有这些都需要在某些工具中重写测试然后执行。完成后，团队将收到结果。

对某些人来说，这似乎是一种完全合乎逻辑的方法，但是在使用这种测试方法时会发现一些问题。首先，开发人员必须确定原始需求与软件可交付成果相匹配。要正确执行此操作，开发人员必须重写相同的基于场景的测试，否则代码结果可能无法映射到需求。开发人员需要能够编写符合其要求的测试并实现完整的基于场景和代码的结果。当前的测试工具使这成为可能，因为基于 MDT 的工具执行实际代码。

鉴于这些进步，为什么软件测试社区迟迟没有采用 MDT？这有几个原因，首先是早期基于模型的测试没有提供基于代码的测试结果。此外，许多开发人员需要代码覆盖率、内存分析和性能分析指标。当工具缺乏这些功能时，有些人会认为 MDT 是一种负担而不是解决方案，这是有道理的。

弥合这些差距是成功实施 MDT 的挑战。市场上有几种有效的基于代码的测试工具，重新创建此功能为开发人员喜欢的基于代码的结果样式提供了更少的选择。另一种选择是执行基于模型的测试并包含基于代码的结果。这是可能的，因为在运行基于模型的测试时，开发人员可以执行实际代码，而不是模拟。如果开发人员使用基于代码的测试工具来检测代码，则 MDT 可以运行，并且结果将在完成时出现。

分布式开发，更好的代码

寻找方法帮助分布式团队更好地协同工作，同时推动高质量的可交付成果是许多组织的首要任务。当开发过程采用 MDT 方法时，团队可以实现基于代码的测试结果。关键的支持技术是执行实际应用程序的 MDT 测试。这意味着使用可以直接提供测试结果的基于代码的测试工具运行 MDT 测试。基于代码的测试工具跟踪正在执行的应用程序，使其成为最佳方法。

MDT 在改进测试过程方面有着良好的记录，但它没有被广泛采用，因为它不会产生基于代码的测试结果。现在这是可能的，提供了两全其美的优势——在 MDT 流程中轻松创建和理解测试——以及开发人员可以使用的完整和彻底的测试结果。通过利用 MDT 方法的收益，开发人员也可以得到他们的蛋糕并吃掉它。

审核编辑：郭婷