本文共 6907 字，大约阅读时间需要 23 分钟。
深入了解敏捷环境下自动化功能测试的标准和需求，在你的自定义框架中需要构建的功能，或者是你应该选择的工具。Anand探索了可读性、复用、调试/rca、CI、测试数据、并行执行、和其他库或工具的集成、免费与开源以及支持等方面。
人工智能和机器学习，分别称为AI和ML，是当今软件行业最热门的词汇。测试社区、服务组织和测试产品和工具公司也开始在向这些方面快速倾斜。
虽然软件测试行业内确实发生了一些有趣的事情，但很多似乎只是炒作。非常遗憾，很难从这些复杂的事情中找出有趣的工作、研究和解决方案。请查看我的博客文章“”作为参考。
现在流行的主题之一是“无代码自动化功能测试”，我们让机器识别如何自动化测试软件产品。搜索关键字“无代码测试自动化”或“测试自动化中的AI”会查到一些该领域中的工具。
我非常想知道到底发生了什么。AI如何帮助自动化功能测试，还是这仅仅是欺骗人们使用工具的营销手段？
在进一步讨论之前，我想从自动化功能测试设计、工具和框架的角度，尤其是在敏捷的方面强调几个我认为重要的标准或需求。
人们通常认为需要在功能和产品稳定之后进行自动化功能测试。恕我直言，这是对自动化的浪费，特别是现在人们都看到了基于敏捷的交付实践的价值，并且开始使用了增量软件交付。
使用这种方法，最重要的是在产品构建的阶段尽可能多地自动化测试，我们要遵循的原则。一旦团队知道现在在顶层（UI层）需要自动化一些什么之后，我们就应该自动化这些测试。
由于产品在不断发展，测试肯定会随着产品的发展而失败。这不是测试的问题，而是测试没有跟随产品的发展而发展。
想要让之前通过的测试再次通过，自动化功能测试工具、框架应该使现有测试的更新和演变尽可能地简单。可能需要在定位器中进行变更，或者需要在流中进行，这并不是很重要。
如果这个过程很简单，团队成员会从自动测试执行和其工具框架中获益匪浅。
这是我认为的自动化测试最重要的方面，了解什么自动化了，它是否能展现出相对于一系列UI操作之外的价值。
如果测试执行环境不变（比如说测试中的产品、与测试相关的测试数据等等），自动化测试的结果应保持一致。这个方面也可以被认为是测试稳定性。
如果因为某些原因，测试失败了（比如产品的缺陷，测试没有更新等），每次重复执行该测试也应该以相同的原因失败。
保证测试确定性和健壮性的一个方法是保证可以定位并可靠地更新定位器，从而让维护变得简单。在某些情况下，工具集可能会使用（人工）智能来找出识别相同元素的下一个最佳方案，防止因定位器改变而找不到元素导致的测试失败。尤其是在唯一的定位器不可用的情况下，或者定位器的变更是基于产品状态的情况下。
也可以用不同的方法来唯一地识别一个元素。工具和框架需要支持多定位器的识别，测试作者应该能够详细说明如何使用它们。
通常导致测试失败的原因如下：
上面提到的因素会让实现确定性和健壮性的自动化测试变得不太可能。
在相对来说比较新的工具集中，我很高兴看到它们能够以各种各样的定位器策略来识别一个元素。在你多次运行测试的时候，工具能知道测试的预期，也会尽可能用最可靠的方法找到元素。这样，测试的健壮性就得到了提升，既不会影响测试的质量，也不会让测试“不经意的通过”。
应该非常容易编写自动化功能测试的片段，并按照需求，选择不同的数据值复用它们。这些代码片段可能包含简单逻辑、条件逻辑，也可能包含一些重复的内容。
比如说：登录代码片段，被记录和实现一次，在所有需要使用特定数据登录的测试中使用。
很多时候我们需要更新现有的脚本。原因可能是因为测试的发展（由于需要测试的产品更新了），让测试变得健壮（比如处理变化、动态的测试数据），或处理特定的情况下保证在某些环境下能运行测试等等。
如果脚本是使用开源工具实现的，比如等等，那么我们需要直接处理代码，这个任务相对比较容易。通过良好的编程实践也可以重构并升级代码。
然而，如果脚本是使用非编程、或非基于编程的工具（免费或商用）实现的，那么这项工作会变得很复杂。我们需要保证工具允许某些自定义，也不需要在仅仅做了一些小的变更的情况下重新实现整个测试。
根据测试的领域和类型，测试数据可以是简单的或非常复杂的。有很多方法来制定测试数据，比如：
测试自动化工具、框架应该：
参考资料：
API测试解决了多个不同的目的，非常有价值。它在自动化测试金字塔中位于UI测试的下一层。
然而，作为自动化功能测试的一部分，在可行的情况下，以及被测试产品的支持下，我们应该在这些领域中使用API测试技术：
自动化测试框架和工具需要能够利用API来执行测试数据设置和创建。这代表着：
自动化功能测试很慢，需要一段时间来执行。随着自动化测试数量增加，获得反馈的时间也会增加，因此降低这些测试的价值。解决这个问题的一个方法（除了在功能层减少自动化测试的数量之外）就是并行执行测试。
这也代表着我们需要保证测试独立运行（可以用任何顺序执行），并且不共享，也不依赖于另外一个测试创造的被测试产品的状态。
这是经常被忽视的一个方面。测试的实施者应该能够在实现阶段针对本地代码的变更来运行测试，或者针对被测试产品的特定问题进行调查或RCA。
请注意我不是说在某个特定的本地计算机上执行测试，而重点是在本地产品代码变更的情况下仍然进行测试的能力。比如，我已经修复了错误，我需要针对它进行测试。所以我会在我的计算机上部署代码，并（在本地或在云上）运行测试（子集），将测试指向我的本地（和临时）环境来获得相同的反馈。如果所有的变更都运行正常，那么我需要把我的代码推送到版本控制系统中。
这应该是自动化解决方案的一个简单功能。
我们应该能够在任何可选择的环境下执行测试。
如果在多个环境下（比如开发、测试、登台环境）部署的代码是相同的，那么在各个环境中的测试执行结果也应该是相同的。
这种环境变更应该做成只是简单的改变配置。
这里的重点是，应该可以根据特定的环境进行隔离并执行测试。需要有办法给能在一系列环境下可执行的测试打标签。运行测试的时候，根据所选择的执行环境，只有相关的测试才应该自动化运行。
这是另外一个重要的方面。只能在特定的操作系统浏览器组合或设备下运行的软件极为罕见。根据产品的环境，它可能需要支持多个浏览器，如果它是本地应用程序，那么它需要能够在多个设备下运作。
因此，实现的功能测试需要能在各个操作系统浏览器组合下运行，或者在被测试产品需要的设备上运行。
切换到不同的执行环境应该做成以简单地改变配置来实现。
是测试就会失败的。实际上，如果你的测试从来都不会失败，那么就需要改改执行环境来检查一个测试是否有问题了，得确保它会失败，并能看到正确的失败类型和原因。
自动化测试的价值是保证每次测试失败的时候，会发生这些情况：
基于RCA，如果测试需要更新，自动化测试框架和工具需要足够简单可以修复问题。
所有的测试和测试代码都要在版本控制系统中。在有需要时，这可以让你查看历史和变更。
任何形式的自动化的核心价值就是尽可能频繁地执行测试的能力、自由度和价值。
我比较推荐设置好的CI管道（请参考“”），对于每个触发的构建，每种类型的测试都能在每次提交的时候自动化逐步运行。这可以给团队早期的反馈，了解什么失败了，这样他们就可以尽快调试并修复错误。
为了在CI过程中集成自动化功能测试，本文中列出的所有功能和测试执行所需的设置（安装软件、库、配置等等）都需要自动化进行，也就是通过在命令行中执行相关带有适当参数的脚本来实现。
好的测试执行报告是了解被测试产品状态的重要依据，特别是在测试量很大的时候。报告中应该包含有助于理解产品总体质量的指标和信息，辅助我们采取有意义的步骤来提升产品的质量。
能够从整体、局部查看测试结果，并且以不同的可视化方式提供大量有意义的信息。
报告中应该包含大量已执行测试的信息，以及产品在执行期间的状态：比如
此外，不同的利益相关者需要不同类型的报告。
比如说：
对于某些事情，有很多有趣的工具和库可以很好地完成。
比如说：
如果你认为自动化测试需要的所有功能都要从头开始构建，或者认为一个工具能提供所有的功能，这么想不仅很愚蠢，还会让工具变得很庞大，不能提供适当的功能。
你使用的自动化测试框架和工具应该可以很容易和不同工具集成。这样的集成可以让你更快地从自动化测试中获得价值。
实现自动化测试是一个方面。我们需要设置操作系统浏览器组合基础设施，或是在需要执行的测试上给出较好的设备覆盖（基于被测试产品的环境）。
在很多情况下，有了虚拟机或虚拟器的帮助，在内部设置这个基础设施变得可行。但是在很多情况下，设置、管理和维护变得非常复杂。同时，也可能会使关注点从产品的测试转向基础设施的管理和维护。
在这种情况下，有很多基于云或内部私有云的解决方案，帮助你在本地构建并实施测试，在云端执行。
这也减轻了创建实验室（web/mobile）和管理基础设施的负担和成本，相反，团队可以更关注于产品测试的核心方面。
值得关注的基于云的执行工具包括、、、、等等。
在某些情况下，仅仅做功能验证是不够的。我们还需要确保，在一定的容忍范围之内，被测试的产品在一段时间内完全符合设计和预期。
有很多优秀的工具和实用程序，有开源的和商用的，可以和自动化测试集成，完成附加的可视化回归。这可以帮助从可视化的角度避免手动验证导致的错误。
一些值得关注的自动可视化测试案例包括、、等等。
在我职业生涯的20年中，我主要都是使用开源软件和商用软件完成自动化功能测试。
近几年来，我听到和看到过太多开源工具由于是“免费的”而被使用的案例。这是一个很大的误解。你可能不需要给工具本身付费，但是使用它也会有相对的开销。
我不喜欢使用商用工具有自己的理由：
同样，我喜欢开源工具的原因是：
但是在阅读了和使用了一些新的商用工具之后，我的想法发生了变化。原因如下：
实施自动化功能测试总而言之就是使用正确的工具和库，使用这些工具来实现测试。由于每个实现都是不同的，测试实现者的技术和能力也不同，因此需要某种形式的支持来帮助解答问题、修复工具库的错误，或找到并提供解决方案帮助团队继续向前。
这种支持可能的形式包括：
在很多情况下，当需要选择工具和库来实施自动化功能测试的时候，可用的支持机制都是考虑的决定因素。
基于上面提到的标准，我从自动化功能测试的角度来比较现在市场中比较新和有趣的工具。
在快速了解了工具之后让我意识到，入门自动化测试变得那么容易。此外，在评估新一代工具的时候，我有个的瞬间，在2009年6月我在普钠ThoughtWorks的上发表的第一次演说“未来的测试自动化工具和基础设施”里的一个想法，之后在很多地方发表，包括、等等。
我那时对于记录回放工具的想法是：作为大型的整体工具，测试比风中的羽毛还要脆弱，现在这个观点正受到挑战。这些工具是以自动化不断发展产品的理念构建的，与传统的记录回放工具只能自动化“稳定的功能”截然相反。
我在下一篇文章中，计划基于上述的标准回顾一些工具，包括、等等。
请持续关注！
参考文献
文章/博客：
自动化工具：
可视化回归工具：
用于执行测试的云解决方案：
有关作者
Anand Bagmar是软件质量布道师，在软件测试领域拥有20多年的经验。他热衷于交付高质量的产品，专注于产品质量策略和执行，并构建自动化测试工具、基础设施和框架。Anand写了与，并构建了软件测试相关的开源工具、和。你可以在Twitter关注他的账号，在上和他保持沟通，或者访问。
查看英文原文：
转载地址：http://xmfzx.baihongyu.com/