Web 应用程序的动态、快速变化和关键业务的重要性不断挑战传统自动化测试和测试框架的极限。 本文讨论了最常遇到的关键挑战，以及如何帮助简单地或自动地应对这些挑战。

测试覆盖率

测试覆盖率是通过测试验证的重要指标之一。当人们表示他们在构建测试覆盖率方面遇到挑战时，通常意味着他们没有足够的资源来足够快地编写测试以跟上测试需求的增长。

解决挑战的尝试通常涉及招更多人活着将上线时间推迟，通常来说几乎不可能有立竿见影的解决方案。

低代码工具可以通过最小化复杂性和消除特定技能的门槛来帮助加速测试。与记录和回放的早期工具功能相比，现代主流的工具框架捕获测试用例更容易访问、更准确、更稳定。AI 驱动的工具有助于对被测应用程序进行建模、了解 DOM 元素之间的关系并使用多个属性来提高稳定性。通过加快测试速度，帮助许多敏捷团队赶上迭代速度。

识别动态元素

传统的测试自动化框架通过 CSS 属性或其在页面上的位置来识别应用程序中的可视元素。当这些属性在正常的开发活动发生变化时，通常会破坏相关的 UI 测试用例的有效性和稳定性。修复损坏的测试通常称为维护，通常维护成本随着自动化项目的复杂程度和用例数量的增加而指数增加。对传统开源框架的维护可能会消耗团队高达 40% 的优质资源。

识别动态元素的几种方法包括使用备用定位、相对定位、模糊定位或计算机视觉。

最稳定的测试来自人工智能驱动的工具，这些工具可以深入检查和理解应用程序的元素、属性以及元素之间的关系。如果应用程序从测试运行中学习并调整以反映应用程序随时间的变化，那就更好了。

同步测试

当测试在自动化平台中执行时，测试步骤的时间必须与应用程序的时间相匹配，否则测试将找不到正确的元素。使测试和应用程序保持同步的技术包括添加基于时间的等待（可以是每个步骤或测试）和基于事件的等待，以防止在事件发生之前执行下一步操作或者断言。可以参考Selenium等待：sleep、隐式、显式和Fluent

但是，添加等待会减慢执行速度。关键是添加尽可能少的等待以实现所需的稳定性，同时尽量减少对速度的影响。还有第二个相关的权衡：调整测试所花费的时间与获得稳定性和速度的最佳组合的平衡点。可以使用并行测试解决此问题：Selenium并行测试基础、Selenium并行测试最佳实践

部分公司正在尝试使用计算机视觉来识别页面何时准备好进行下一步以处理这些技术。但是，在该技术成熟之前，还是需要使用不同的基于时间、基于事件和条件等待的选项。

故障排除

当测试失败发生时，需要快速诊断它们，排除故障。这些工具应该使团队中的任何人都可以轻松确定测试失败的原因。团队还需要工具来帮助确定工作的优先级并指出可能影响多个测试的重复错误。

寻找在每个测试步骤中提供之前/之后屏幕截图而不需要额外编码的工具。视频可能会有所帮助，但加载速度较慢，并且通常无法快速查明问题所在。网络和控制台日志可能有利于额外的诊断，但应自动包含在测试结果中，而不是单独执行任务。

高级工具不仅会告诉您它在哪里坏了——它们还会告诉你它为什么坏了。智能工具还可以通过汇总常见错误并显示测试的最近结果历史记录来帮助对工作进行分类。

使用代码自定义无代码测试

市场上有许多低代码或无代码测试自动化工具，它们通过使用基于模型或记录/回放的方法来编写测试来简化 UI 测试编写。其中一些严重限制了测试人员对测试执行的操作范围，以及对功能到修改以适配自家的应用程序。

将代码添加到无代码测试应该是一项必备功能，以确保测试工程师能够灵活地满足独特的用例。确保添加代码的语言是团队成员都能力理解和使用的语言。更重要的考虑是选择与低代码和无代码工具所支持的语言。

跨浏览器测试

关于跨浏览器测试的重要性的文章很多，但许多开发团队只关注 Chrome。为什么？

其中一个重要大原因是：构建跨浏览器兼容测试框架和系统成本很高。

用户以不同的浏览器访问网站，那么应该至少执行跨浏览器测试覆盖主流的浏览器和系统组合矩阵，以确保网站在大部分用户使用时能够正常运行。有两个选项可以让这更容易：使用具有内置跨浏览器测试网格的工具，或者将测试与设备场或虚拟测试网格服务集成。前者往往更简单、更便宜，而后者将为您提供更广泛的设备和浏览器类型配置。

随机弹出窗口

弹出窗口是可能时造成自动化测试失败的最大的困扰。因为弹框的类型多种多样，通常难以不测，会阻止测试的顺利运行。

许多工具要求编写测试用例时候知道弹出窗口的位置，切换到活动窗口，将其关闭，然后再切换回应用程序的主窗口。虽然这些对预期的警告弹出窗口很有帮助，但它们对来自集成工具的随机弹出窗口没有帮助，这些工具可能会阻止元素直到关闭。

对于那些，需要寻找在每个步骤之前搜索弹出窗口的解决方案，然后通过关闭/取消来处理它们。 通常这种问题在编码阶段推行统一编码规范解决会具有更高的roi。

重用测试组件

不要重复自己，是一个也适用于测试的编码概念。如果测试包含在其他步骤中经常重复的步骤，则对基础元素的更改意味着需要更新许多测试。相反，如果这些步骤或组在测试中共享和重用，则可以更新一次以修复所有相关测试。

为了鼓励重用，编写测试的人需要快速轻松地访问那些可重用的组件，不然很难将重用的威力发挥出来。可重用组件应该足够灵活，以允许在特定测试中进行一些修改，无论是通过参数化、特殊处理等。如果是对于某一功能的封装，最好是提供丰富的API给使用者。

寻找一种可以轻松创建和共享可重用组件的工具。确保无论是在创作过程中还是在后续的编辑步骤中，都可以轻松找到这些组件并将其添加到测试中。即使它是一个低代码测试平台，它也应该启用某种形式的测试重构来清理重复项并用可重用的组件替换它们。

测试报告

通过/失败报告并不能让所有人都理解测试的结果。随着添加更多测试、测试类型（烟雾、回归等）以及用户评估结果，它的价值会继续降低。较大的项目需要更复杂的报告，以帮助说明质量的整体状态和方向。

寻找易于在团队中频繁运行和共享的内置报告，例如每周一次。通过过滤和排序来寻找灵活性，以创建不同视图。测试报告还需要提供访问更新详细的测试信息的功能。