大多数测试自动化工具只是执行测试执行自动化。在整个测试自动化过程中没有涉及测试设计的情况下，测试用例仍然是临时的并且只检测简单的错误。这个解决方案只是自动化，没有真正的测试。此外，测试执行自动化非常低效。
如果您以简单的方式编写测试代码，就会损害 DRY(不要重复自己)原则。对于测试自动化来说，意味着维护成本会更高。如果你使用页面对象模型——一种页面对象与自动化测试脚本分离的设计模式，代码将会更长，并且需要更多的时间来编写。
这就是高级测试自动化工具包括测试设计的原因。正如Bloor Research所说：“测试设计自动化为测试速度和效率提供了潜在的巨大提升。如果利用得当，它还可以显着改善最终用户体验。
涉及测试设计的工具是基于模型的测试(MBT)工具。ISTQB 将基于模型的测试定义为“基于或涉及模型的测试”。因此，我们不是一个一个地手动创建测试用例，而是创建一个合适的测试模型，MBT 工具能够从该模型生成测试用例。然而，模型本身是不够的。传统的测试设计需要应用测试选择标准，这使得知道何时停止创建测试用例成为可能。因此，MBT 工具根据适当的测试选择标准从模型中生成测试用例。
建模是一种分而治之的活动。它的主要目标是收集系统的那些元素(当时是需求规范)，通过这些元素可以可靠地测试系统。我们可以以分层的方式制作相对简单的模型，然后从这些模型中，一个工具可以生成抽象的测试用例。
可以用不同的方式对按需求规范规划的系统进行建模。对于测试，我们可能需要特殊的测试模型，但在实践中，会使用软件工程模型，例如状态转换图、UML 活动图、EFSM、BPMN、用例图等。这些不是创建可靠测试集的理想表示。
基于模型的测试的挑战
这些模型的一个共同特征是每个模型都可以表示为图形(即使是用例等文本模型也有图形表示)。以不同的方式遍历图形，可以选择不同级别的测试选择标准。可以生成测试用例以满足所选标准。以下是使用测试设计自动化的优势：它们不是以临时方式一个接一个地创建测试用例，而是根据公认的模型和测试选择标准生成测试用例。
一个问题是传统模型应该包含有关测试代码生成实现的信息。这意味着每个事件、输入和输出都应该在模型中。如果模型是在实现之前创建的，那么根据实际实现需要重复很多工作。另一方面，在实施后制作模型与左移原则相矛盾。
另一个常见问题是传统方法需要编码。遍历图会生成无效的测试用例。例如，将第二个项目添加到购物车，然后删除第三个是不可能的。添加保护条件以解决此问题。但是，保护条件是代码。如果保护条件由输出组成，则应对此输出进行编码。如果是难的函数，守卫代码也难，怎么测试呢?
分两个阶段生成测试用例
最流行的解决方案是使用无状态模型。它们可以普遍使用，这就是为什么它们是最受欢迎和使用最广泛的 MBT 工具的原因。一个具体的问题是，即使选择了更强的测试选择标准(例如所有转换对标准)，无状态模型也只会检测到最简单的错误，请参阅此博客文章。
状态转换图等状态模型可以检测更棘手的错误，但是，它们不能用于许多要实现的系统(状态难以识别或状态太多)。
所有这些问题都可以通过基于双相模型的测试来解决。
阶段 1：生成高级测试用例
这里的第一个模型是高级模型。从模型中生成抽象测试用例。这些测试用例可以在实施之前验证需求。通过这种方式，可以删除或修复大多数错误、误解等，这在 SDLC 的这个阶段非常便宜。我们将这些测试用例称为抽象的，因为它们可以由人类执行，但无法生成可执行的测试代码。
高级模型由文本步骤组成。每个步骤都包含一个(用户操作)、一个(系统)响应 - 可选和一个测试状态 - 可选。动作和响应在用例测试中是众所周知的，但是，测试状态与程序状态有很大不同。减少大量状态的解决方案是，如果两个动作相同，但系统以不同的方式计算响应，那么我们就到达了不同的状态。
例子。初始状态是'支付是不可能的'。如果我们添加任何项目以使总价保持在 10 欧元以下，那么我们将保持在支付限额以下的相同状态。然而，达到 10 时，我们到达了一个新状态“可以支付”。
测试状态背后的原因是应该测试每个不同的计算，因为它们中的任何一个都可能有错误。这样，状态的数量仍然是可管理的，但将涉及必要的测试。我们在解决我们网站的练习时验证了这个断言，并且这个模型已经找到了所有的错误。
这是建模的示例：
1 2 3 4 | INITIAL STATE cart empty R4 paying is possible when price 10: add items so that price remains below 10 => check that price <10 STATE paying is not possible add items so that price reaches 10 => check that price =10 STATE paying is possible |
第一行是初始状态。第二行是将需求R4连接到模型和测试用例的标签。第三行包含一个模型步骤。第一部分“添加商品以使价格保持在 10 以下”是用户操作，第二部分：“检查价格 <10 ”是对系统响应的验证，第三部分“无法付款”是结果测试状态。了解边界值分析的测试人员会将最接近低于 10 的值添加到购物车。当她验证结果时，她将检查是否还无法付款。
执行此测试步骤对于知道商品价格的测试人员来说很容易，但目前，对于一台应该了解测试设计技术、理解模型步骤的文本并识别屏幕上的价格(或通过阅读和解释规范)。
由上述两个模型步骤组成的该模型生成单个测试。可以轻松修改模型以在两个单独的测试用例中执行这些步骤：
1 2 3 4 | INITIAL STATE cart empty R4 paying is possible when price 10: add items so that price remains below 10 => check that price <10 STATE paying is not possible add items so that price reaches 10 => check that price =10 STATE paying is possible |
您可以看到制表使得继续测试用例或开始新的测试用例成为可能。
模型步骤真正独立于实现。您可以以任何方式实现这些模型步骤的购物功能。模型步骤也非常紧凑。它们应该包含较少的信息，足以让测试人员手动执行。例如某模型action修改密码成功
可能涉及要实施的五个步骤：单击密码更改菜单项、插入当前密码、输入新密码、第二次输入新密码、点击提交按钮通过这种方式，模型保持紧凑，并且可以更容易地理解和审查。
第 2 阶段：生成低级测试用例
下一阶段是生成已执行的测试代码。这可以通过手动执行测试用例来完成。在执行过程中，会动态生成一个低级模型，请参见下图：
图 1. 在执行抽象测试步骤“添加商品以使价格保持在 10 以下”期间生成低级模型
测试人员执行当前的操作或响应，这里是“添加项目以使价格保持在 10 以下”。
这里的低级模型是一个类似小黄瓜的描述，但可以是任何东西。考虑第一步：
1 | WHEN Go shopping IS #pressed |
Go shopping是标识 Go shopping UI 元素的选择器，# pressed表示单击它。验证有点困难，因为您应该选择验证类型或结果本身。例如，如果要验证支付按钮是否处于非活动状态，则可以先选择支付按钮，然后选择验证 (THEN)，最后选择#non-active命令
图 2. 支付按钮的验证无效
通过这种方式，您可以轻松生成包含用于测试代码生成的每条信息的低级模型。一个工具可以为任何编程语言和任何测试运行器生成测试代码。
结论
这种方法的一个明显优势是它是一种 DRY 测试解决方案。这意味着测试用例可能会多次包含某些步骤，但测试人员只会手动执行一次，因为同一步骤的第二次出现将自动执行。
这是一种自动化部分完全自动化的方法，测试人员可以在最高级别的制作模型上进行测试设计。这不是一项容易的任务，尤其是在涉及测试状态的情况下，但它很有趣并且会产生更高质量的代码。
两阶段建模是真正的左移解决方案，可用于有状态和无状态的情况。这也是一种有效的缺陷预防方法。这种方式的测试自动化不仅变得快速，而且非常舒适，因为测试人员不需要提前计算结果。他们只需要检查它们，这就容易多了。最后，此方法适用于测试人员，因为它需要测试设计但不需要编码知识。
卓码软件测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务，并出具合格有效的软件测试报告。点击→→可了解测试报价
部分文字、图片来自网络，如涉及侵权，请及时与我们联系，我们会在第一时间删除或处理侵权内容。负责人：曾菲 电话：4006070568