无障碍测试_持续测试的3大障碍

无障碍测试

让我们面对现实：企业不需要或不需要完美的软件。 他们确实希望尽快交付新的，具有业务差异性的软件。 为此，您需要快速反馈最新的创新是否会按预期工作或在生产中崩溃并烧毁。 您还需要知道这些更改是否以某种方式破坏了客户群以及业务所依赖的核心功能。

这是进行连续测试的地方。

连续测试是作为软件交付管道的一部分执行自动化测试的过程，以尽可能快地获取有关与候选软件版本相关的业务风险的反馈。

测试自动化对于连续测试必不可少，但这还不够。 测试自动化旨在生成与用户案例或应用程序需求相关的一组通过/失败数据点。 另一方面，连续测试着重于业务风险并提供有关是否可以发布软件的见解。 除了测试自动化之外，连续测试还涉及一些实践，例如使测试与您的业务风险保持一致，应用服务虚拟化和有状态的测试数据管理来稳定测试以进行持续集成，以及进行探索性测试以在每次迭代的早期揭示“大块”问题。 这不仅仅是解决更多工具或其他工具的问题。 它需要跨人员，流程以及技术的更深层次的转变。

毋庸置疑，持续测试已成为当务之急-尤其是现在，有97％的组织采用敏捷，而71％的组织正在实践或采用devop（根据Sauce Labs ）。 Forrester的最新研究证实，连续测试是将敏捷/开发者领导者与敏捷/开发者落后者分开的关键因素之一。 但是，大多数企业仍然没有成熟，可持续的连续测试过程。 Forrester发现 ，即使是积极从事敏捷和开发活动的组织，其持续测试采用率也相对较低：26％。

许多组织尝试了测试自动化。 通常，自动化一些UI测试并将其执行集成到持续集成过程中。 他们取得并庆祝了小的胜利，但是过程并没有扩大。 实际上，它会衰减。 为什么？ 通常，它可以归结为以下三个类别的障碍：

• 时间和资源
• 复杂
• 结果

时间和资源

团队严重低估了可持续测试自动化所需的时间和资源。 是的，让一些基本的UI测试自动运行是一个很好的开始。 但是，您还需要计划以下时间和资源：

• 保持臭名昭著的易碎测试脚本，以免因误报而压倒团队。
• 为每个新的或修改的需求创建测试（或确定将精力集中在什么地方以及可以跳过的地方）。
• 建立一个支持重用和数据驱动测试的测试框架，这两者对于使自动化长期可持续发展至关重要。
• 使单个测试和更广泛的测试框架与不断发展的应用程序保持同步。
• 执行测试套件-尤其是在您尝试频繁运行大型且耗费大量UI的测试套件时。
• 确定如何自动化更多高级用例，并使它们在连续的测试环境中保持一致运行（有关更多信息，请参阅下一节）。
• 查看并解释测试结果的安装量（稍后也会对此进行更多介绍）。

借助敏捷和发展，测试创建，维护，执行和分析的时间非常有限，但快速的反馈至关重要。 您如何确保最重要的事情得到充分测试而又不延迟上市时间？

复杂

在Web应用程序中自动化对一个简单的“创建”操作的测试是一回事（例如，创建一个新帐户并从头开始完成一个简单的交易）。 这是自动化最关键业务的事务的另一种方法，这些事务通常通过多种技术（SAP，API，移动接口，甚至大型机）进行，并且需要复杂的设置和编排。 您需要确保：

• 您的测试资源了解如何自动化所有不同技术的测试，以及如何将数据和结果从一种技术连接到另一种技术。
• 您拥有建立真实的测试以及通过一系列复杂的步骤（每次执行以及每次执行测试）进行测试所需的状态，安全且合规的测试数据。
• 您可以可靠，持续且经济高效地访问测试所需的所有从属系统，包括可能不稳定，不断发展或仅在有限时间访问的API和第三方应用程序。

此外，您还需要一种系统的方法来清除只有从用户角度评估应用程序的人员才能发现的关键缺陷。 自动化非常擅长快速重复检查某些操作是否继续产生预期的结果，但是它无法发现对用户体验产生重大影响的复杂可用性问题。

如果没有有关应用程序更改如何影响核心用户体验的快速，可靠的反馈，您如何知道某个发行版是否会对业务产生帮助或损害？

结果

带有测试结果的最常被引用的投诉是绝大多数需要检查和解决的误报。 当您刚开始进行测试自动化时，处理误报可能是可行的。 但是，随着测试套件的增加和测试频率的增加，Swift解决误报成为一项不可克服的任务。 最终，许多团队要么开始忽略误报（这会削弱对测试结果和持续测试计划的信任），要么完全放弃测试自动化。

当开发和持续交付计划开始起作用时，结果的另一个关键问题浮出水面：它们不提供快速做出/不做决定所需的基于风险的洞察力。 如果您曾经查看过测试结果，则可能会看到以下内容：

• 通过了42278次测试。
• 10,086测试失败。
• 910测试未执行。

这真的告诉你什么？ 您可以看到：

• 共有53,274个测试用例。
• 这些测试中几乎有80％通过了。
• 其中超过19％失败了。
• 约有百分之一没有执行。

但是，您是否愿意根据这些结果做出发布决定？ 也许测试失败与一些琐碎的功能有关。 也许它们是最关键的功能：系统的引擎。 或者，也许您最关键的功能甚至没有经过全面测试。 试图追踪这些信息将需要大量的手工调查工作，而这些工作会产生延迟的，通常不准确的答案。

在敏捷和发展的时代，发布决策需要Swift做出，甚至是自动且即时的。 专注于测试用例数量的测试结果给您留下了巨大的盲点，当您以敏捷和发展的速度前进时，这绝对是至关重要的，并且是极其危险的。

如果您的结果不能说明已测试和正常运行了多少关键业务功能，则不能依靠它们来推动自动发布。 将需要人工审查和评估，这不可避免地会延迟每笔交付。

翻译自: https://www.infoworld.com/article/3294197/3-biggest-roadblocks-to-continuous-testing.html

无障碍测试