说实话：如果您使用的是旧式测试方法，则将花费大量时间维护数据驱动的测试。当你试图跟上一个开发团队的想法，”我们正在按照标准编码——它应该都运行在任何地方时，时间会减慢你的速度。
考虑编码和维护测试基础结构中最困难的部分。最简单的部分是编写初始测试。您可以使用您所看到的和对预期行为的理解来推动测试。测试维护成本可能会让您发疯。
您可能还有兴趣：
通过可视化 AI 实现现代功能测试自动化
所有关于测量行为
所有软件测试都涉及两个活动：应用输入和测量输出行为。当可以使用自动工具同时执行这两项操作时，可以自动执行测试。
正如我在其他地方讨论过的，Applitools 之所以存在，是因为我们知道在检查 DOM 方面构建测试自动化的局限性。 在响应 DOM 中测试 Web 元素是否存在可能会误导人，因为 DOM 的单个测量元素仍然存在测试代码不变，但用户会遇到视觉上的差异。
在 Raja Rao 的”通过可视化 AI 进行现代功能测试”课程的第 3 章中，Raja 比较了有关代码维护的测试方法。具体来说，他查看数据驱动的测试，用作测试自动化的构建基块。
如今，几乎所有的自动化都使用代码来检查 DOM 中的特定文本元素。和我们大多数人一样，您可能认为，只要元素继续存在，用户体验就不会改变。实际上，该假设在应用中的某个页数上失败。
进行全局或本地 CSS 更改的次数越多，无法直观地验证的次数越多，您的测试会错过客户遇到的错误。广告重叠或隐藏。文本格式设置失败。颜色更改不会得到验证，从而导致伪装行为。即使为预期行为编写特定的测试，也很容易编写在后续版本中无法捕获明显问题的测试。因此，您的用户想知道谁运行了这些测试。（提示：获取一面镜子。
简单示例登录屏幕
Raja 首先查看测试应用程序的登录页，演示了使用 Visual AI 进行数据驱动的测试。
在旧功能测试中，请求用户名和密码的登录屏幕有五种可能的行为：
- 缺少用户名和密码– 用户单击登录按钮而不填写用户名和密码，应用程序会回复一条错误消息，要求用户在登录前填写用户名和密码。
- 空密码– 用户填写用户名并单击登录按钮，应用响应时出现一条错误消息，指出用户必须包含密码
这种屏幕非常适合数据驱动的测试。您可以将每个组合与测试表或硬编码测试集一起应用，并测量来自应用的响应。 因此 – 数据驱动：测试数据各不相同，您可以测量不同的结果。
Java 中的示例测试代码 = 旧功能测试
下面是 Raja 用作测试代码的传统功能代码
查看Gist上的代码。
旧代码使用输入状态和预期输出条件的数据表。当 Raja 运行代码时，它的行为与预期一样 – 故障消息被检测到失败，通过测试正确通过。每个测试都使用故障消息的标识符来拉取故障响应，而通过测试只是移动到相应的屏幕。
顺便说一句，Raja无意中展示了等待测试人员生命的危险之一。在他的章节中，Raja只展示了五个测试组合中的四个。他跳过无效的用户名/密码组合。无赖。
测试经常为发现错误代码提供最后一道防线。当 Bug 因错过的测试用例而转出时，您的组织有何反应？与考虑测试覆盖率相比，您花费多少时间维护测试代码？
使用旧代码进行应用更改和测试更改
Raja 的下一个焦点是页面行为更改时发生的情况。页面行为可以在开发人员更新应用的任何时间更改。
Raja 专注于用户名和密码的四种组合（没有输入，一个不是另一个，两者兼而有之），使用现有的测试行为来突出显示测试代码需要更新的位置。
事实证明，应用更改可能会导致应用不再正确运行。但是，即使用户无法使用该应用程序，现有测试仍会通过。哎 呦。
以下是 Raja 部署的更改以及现有测试的进行情况：
- 在新的应用版本中，当用户不输入用户名或密码并单击”登录”按钮时，将显示新的警报文本。现有测试捕获了已更改的文本。需要更新代码的这一部分。您必须维护更改的测试代码。
- Raja 更新了丢失的 Pwd 案例，以便错误文本和文本框被屏蔽或隐藏在页面上。但是，它们存在于 DOM 中，但用户无法访问它们。因为它们存在于 DOM 中，因此通过了现有测试。哎 呦。
- Raja 更新了缺少用户名的情况，将错误消息包装到文本框中，文本框的起始坐标相对于页面顶部相同，但仅宽一个单词。在这种情况下，可视行为与先前的行为不匹配，但测试会随着正确的定位器和标识符保留而通过。
- 登录成功后，用于记录用户名的定位器不再可用。因此，用户成功登录，但测试失败。您需要进入并手动修改定位器到新代码。
因此，一个测试由于有意更改而失败，一个测试失败，因为更改可能是有意的，但不清楚。其他两个测试通过，因为测试只测量响应代码的存在
很容易理解为什么会发生这种情况 – 测试代码运行速度如此之快，以至于测试人员无法看到差异。
你对这些变化有何感想？当开发人员忘记记录新行为或忘记让您了解布局或 CSS 更改时，您是否感到意外？
当应用更改时，所有测试都需要维护。一些组织得出结论，他们必须限制其更改，以确保可测试性。他们需要维护该代码 – 这需要时间和精力。
其他人则寻找不同的方式。因此，Raja 使用 Visual AI 进行数据驱动的测试，以测量应用程序行为。
新方式 + 可视化 AI
Raja 使用 Visual AI 带领我们完成相同的测试。每个配置测试都有一个唯一的名称，并由 Applitools Eyes 单独捕获，而不是将元素定位器和文本捕获断言作为数据驱动测试的一部分。因此，为了清楚，浏览器自动化使用定位器输入数据和驱动操作。但是，测试使用应用页快照。
查看Gist上的代码。
实现应用更改时，Applitools 显示了所有三个差异。
下面是测试旧版本的应用的结果，然后在新版本的应用上运行相同的测试。
在最左侧，绿色测试显示登录继续运行。因此，即使旧版测试失败（由于用户名定位器的更改），Applitools 也通过了此测试。
使用可视 AI 处理故障
其他三个测试是前面讨论的。它们中的每一个都显示为橙色 = 未解决。这意味着 Applitools 表示差异，并要求操作员用竖起大拇指表示预期的差异，用大拇指向下表示故障。
- 对于缺少的用户名，将显示错误消息，但对齐方式已更改。应用工具突出显示了差异。操作员可以用大拇指指示此测试失败。
- 缺少密码时，即使 DOM 中存在代码，错误消息也显示为不可见。操作员可以用大拇指指示此测试失败。
- 在缺少用户名和密码的情况下，带有错误消息的文本框仍显示在同一位置，但应用包含更新的错误消息。操作员可以指示此测试以竖起大拇指通过。竖起大拇指还告诉 Applitools 接受更新的图像作为新的基线。
下面是最后一个示例的屏幕截图：
好吧，那是一张眼图。以下是应用程序工具为屏幕捕获显示的内容：
粉红色文本突出显示基线图像和检查点之间的差异。在这种情况下，我们只看到检查点和突出显示的差异。您可以将显示器配置为在突出显示差异时并排显示基线和检查点图像。由你决定。
作为操作员，您进行评估后，只需单击右上角的”竖起大拇指”或”向下竖起大拇指”图标：
同样，下面是在发生故障时发生的情况：
此失败捕获缺失密码上的错误;否则，将捕获缺少的密码。警报文本和文本框以不可见的方式呈现。应用工具将差异显示为粉红色区域。通过将此区域标记为错误，Applitools 允许您通过 Jira 通知开发团队可以发现错误的位置。而且，通过可选的根本原因分析，您甚至可以捕获导致行为的 DOM 代码。这些功能使您更加有效 – 当您遇到意外行为时，您可以提高覆盖范围并改善团队沟通。
数据驱动测试和可视化 AI 的要点是什么？
Raja 的课程清楚地表明，在构建应用时，我们所有人都会在测试开发中更加小心，但我们的测试维护团队在应用更新后会卡住运行测试，以此维护所有代码。即使我们的开发团队传达更改并提供更新的测试，Bug 也会经历。
Visual AI 允许浏览器呈现成为应用行为的指标。Visual AI 允许您说：”好的，让我们重新运行测试，看看有什么不同，而不是在未渲染的 HTML 中查找项目，并希望它们是正确的。
只需运行现有测试，Visual AI 就可以捕获开发人员想要的所有行为，以及他们忘记告诉你修改的内容。很酷，不是吗？
除了更好的工作流程外，Visual AI 还为您提供了广阔的视野。在一篇不同的博客文章中，我谈到了功能测试近视——你只为预期看到的行为编写测试，并在检查时测试失败。页面的其余部分呢？你只是假设那还是一样的，对吧？Visual AI 也捕获了所有这一切。
第 3 章的摘录
您花费大量时间构建数据驱动的测试。事实上，对于任何具有针对输出测试的输入组合的操作，最容易将这些操作视为数据驱动。但是，随着应用的发展，当应用实际上已更改时，您的测试将涵盖应用的行为，因此可能会自满。您可以提出应用测试通过的更改，但实际上，用户会失败。
你能做些什么呢？像往常一样驱动数据驱动测试，并使用可视 AI 断言输出。您可以捕获可视更改，并消除对上游开发人员的依赖，为您捕获更改。同时，通过减少必须管理的测试代码来提高效率。
下一篇：第4章！