人工智能和机器学习自动化测试介绍敏捷世界的自动化功能测试标准和需求人们通常认为需要在功能和产品稳定之后进行自动化功能测试。
恕我直言，这是对自动化的浪费，特别是现在人们都看到了基于敏捷的交付实践的价值，并且开始使用了增量软件交付。
使用这种方法，最重要的是在产品构建的阶段尽可能多地自动化测试，我们要遵循自动化测试金字塔的原则。
一旦团队知道现在在顶层（UI 层）需要自动化一些什么之后，我们就应该自动化这些测试。
由于产品在不断发展，测试肯定会随着产品的发展而失败。
这不是测试的问题，而是测试没有跟随产品的发展而发展。
想要让之前通过的测试再次通过，自动化功能测试工具、框架应该使现有测试的更新和演变尽可能地简单。
可能需要在定位器中进行变更，或者需要在流中进行，这并不是很重要。
如果这个过程很简单，团队成员会从自动测试执行和其工具框架中获益匪浅。
自动化测试的目标清晰可见这是我认为的自动化测试最重要的方面，了解什么自动化了，它是否能展现出相对于一系列UI 操作之外的价值。
确定性和健壮性测试–定位器和维护如果测试执行环境不变（比如说测试中的产品、与测试相关的测试数据等等），自动化测试的结果应保持一致。
这个方面也可以被认为是测试稳定性。
如果因为某些原因，测试失败了（比如产品的缺陷，测试没有更新等），每次重复执行该测试也应该以相同的原因失败。
保证测试确定性和健壮性的一个方法是保证可以定位并可靠地更新定位器，从而让维护变得简单。
在某些情况下，工具集可能会使用（人工）智能来找出识别相同元素的下一个最佳方案，防止因定位器改变而找不到元素导致的测试失败。
尤其是在唯一的定位器不可用的情况下，或者定位器的变更是基于产品状态的情况下。
也可以用不同的方法来唯一地识别一个元素。
工具和框架需要支持多定位器的识别，测试作者应该能够详细说明如何使用它们。
通常导致测试失败的原因如下：定位器是动态的，每次产品的发布或使用都会造成变化。
定位器依赖于被测试产品的环境。
比如：基于运行测试时的数据集上面提到的因素会让实现确定性和健壮性的自动化测试变得不太可能。
在相对来说比较新的工具集中，我很高兴看到它们能够以各种各样的定位器策略来识别一个元素。
在你多次运行测试的时候，工具能知道测试的预期，也会尽可能用最可靠的方法找到元素。
这样，测试的健壮性就得到了提升，既不会影响测试的质量，也不会让测试“不经意的通过”。
测试片段的编写、更新和自定义应简单且可复用应该非常容易编写自动化功能测试的片段，并按照需求，选择不同的数据值复用它们。
这些代码片段可能包含简单逻辑、条件逻辑，也可能包含一些重复的内容。
比如说：登录代码片段，被记录和实现一次，在所有需要使用特定数据登录的测试中使用。
很多时候我们需要更新现有的脚本。
原因可能是因为测试的发展（由于需要测试的产品更新了），让测试变得健壮（比如处理变化、动态的测试数据），或处理特定的情况下保证在某些环境下能运行测试等等。
如果脚本是使用开源工具实现的，比如Selenium WebDriver等等，那么我们需要直接处理代码，这个任务相对比较容易。
通过良好的编程实践也可以重构并升级代码。
然而，如果脚本是使用非编程、或非基于编程的工具（免费或商用）实现的，那么这项工作会变得很复杂。
我们需要保证工具允许某些自定义，也不需要在仅仅做了一些小的变更的情况下重新实现整个测试。
测试数据根据测试的领域和类型，测试数据可以是简单的或非常复杂的。
有很多方法来制定测试数据，比如：在测试实现中（比如在Login.java 页面文件中硬编码用户名和密码）。
在测试规格说明或测试目的中（比如在测试中使用@Test annotations）。
在代码中，单独的数据结构或类等等。
外部文件和数据存储包含：CSV 、JSON、YAML、Property、XML、INI、Excel、Database等，测试自动化工具、框架应该：支持多种方法制定或查询测试数据支持对其规范和查询的优化提供对不同类型的测试套件的不同数据集能力提供在我们想要运行的测试的每个环境制定数据的能力。
支持API 交互API 测试解决了多个不同的目的，非常有价值。
它在自动化测试金字塔中位于UI 测试的下一层。
然而，作为自动化功能测试的一部分，在可行的情况下，以及被测试产品的支持下，我们应该在这些领域中使用API 测试技术：测试数据设置和创建测试状态的设置比如：使用API 登录而不是让每个测试都通过UI 交互登录，这是很耗费时间的，在测试执行的过程中也可能会发生问题。
我们可以在测试执行的时候使用API 来做一些事情，这些活动不需要总是在UI 中执行。
自动化测试框架和工具需要能够利用API 来执行测试数据设置和创建。
这代表着：使用所需的头和参数创建适当的API 请求分析API 响应，了解是否需要对响应执行断言。
并行执行自动化功能测试很慢，需要一段时间来执行。
随着自动化测试数量增加，获得反馈的时间也会增加，因此降低这些测试的价值。
解决这个问题的一个方法（除了在功能层减少自动化测试的数量之外）就是并行执行测试。
这也代表着我们需要保证测试独立运行（可以用任何顺序执行），并且不共享，也不依赖于另外一个测试创造的被测试产品的状态。
根据本地变更运行测试这是经常被忽视的一个方面。
测试的实施者应该能够在实现阶段针对本地代码的变更来运行测试，或者针对被测试产品的特定问题进行调查或RCA。
请注意我不是说在某个特定的本地计算机上执行测试，而重点是在本地产品代码变更的情况下仍然进行测试的能力。
比如，我已经修复了错误，我需要针对它进行测试。
所以我会在我的计算机上部署代码，并（在本地或在云上）运行测试（子集），将测试指向我的本地（和临时）环境来获得相同的反馈。
如果所有的变更都运行正常，那么我需要把我的代码推送到版本控制系统中。
这应该是自动化解决方案的一个简单功能。
环境我们应该能够在任何可选择的环境下执行测试。
如果在多个环境下（比如开发、测试、登台环境）部署的代码是相同的，那么在各个环境中的测试执行结果也应该是相同的。
这种环境变更应该做成只是简单的改变配置。
这里的重点是，应该可以根据特定的环境进行隔离并执行测试。
需要有办法给能在一系列环境下可执行的测试打标签。
运行测试的时候，根据所选择的执行环境，只有相关的测试才应该自动化运行。
支持多浏览器 / 移动端（本地应用程序）这是另外一个重要的方面。
只能在特定的操作系统浏览器组合或设备下运行的软件极为罕见。
根据产品的环境，它可能需要支持多个浏览器，如果它是本地应用程序，那么它需要能够在多个设备下运作。
因此，实现的功能测试需要能在各个操作系统浏览器组合下运行，或者在被测试产品需要的设备上运行。
切换到不同的执行环境应该做成以简单地改变配置来实现。
调试和根本原因分析（RCA）是测试就会失败的。
实际上，如果你的测试从来都不会失败，那么就需要改改执行环境来检查一个测试是否有问题了，得确保它会失败，并能看到正确的失败类型和原因。
自动化测试的价值是保证每次测试失败的时候，会发生这些情况：测试失败的原因是合理的，比如和测试不稳定性没关系。
你很容易就能够了解到测试失败的原因，比如说RCA 很容易。
在很多情况下，测试的结果不足以了解它失败的原因。
测试自动化框架和工具需要保证在调试模式下运行测试，一步一步了解并找出测试失败的根本原因，或者更好地是指导你找出具体失败了的测试元素以及具体原因。
基于RCA，如果测试需要更新，自动化测试框架和工具需要足够简单可以修复问题。
版本控制所有的测试和测试代码都要在版本控制系统中。
在有需要时，这可以让你查看历史和变更。
和CI（持续集成）工具的集成任何形式的自动化的核心价值就是尽可能频繁地执行测试的能力、自由度和价值。
我比较推荐设置好的CI 管道（请参考“介绍管道和作业”），对于每个触发的构建，每种类型的测试都能在每次提交的时候自动化逐步运行。
这可以给团队早期的反馈，了解什么失败了，这样他们就可以尽快调试并修复错误。
为了在CI 过程中集成自动化功能测试，本文中列出的所有功能和测试执行所需的设置（安装软件、库、配置等等）都需要自动化进行，也就是通过在命令行中执行相关带有适当参数的脚本来实现。
丰富的测试执行报告，进行趋势分析好的测试执行报告是了解被测试产品状态的重要依据，特别是在测试量很大的时候。
报告中应该包含有助于理解产品总体质量的指标和信息，辅助我们采取有意义的步骤来提升产品的质量。
能够从整体、局部查看测试结果，并且以不同的可视化方式提供大量有意义的信息。
报告中应该包含大量已执行测试的信息，以及产品在执行期间的状态：比如屏幕截图视频录像服务器日志设备日志（如果运行在真实的设备上）等等以及测试执行相关的元数据（比如CI 构建号、被测试产品版本、浏览器、设备、操作系统、操作系统版本等等）此外，不同的利益相关者需要不同类型的报告。
比如说：经理可能想看更多的汇总报告、发展趋势、缺陷测试等。
团队成员可能会对测试运行的详细细节、失败的原因更感兴趣，就是帮助他们能快速进行根本原因分析，在后续步骤中采取有意义的步骤来提升产品和测试质量。
和其他工具和库集成对于某些事情，有很多有趣的工具和库可以很好地完成。
比如说：如果你想要记录日志，可以使用log4j。
如果你需要和CI 集成，只需要给测试的配置和执行选项提供命令行接口。
这样，你的测试就可以和任何CI 集成。
如果你认为自动化测试需要的所有功能都要从头开始构建，或者认为一个工具能提供所有的功能，这么想不仅很愚蠢，还会让工具变得很庞大，不能提供适当的功能。
你使用的自动化测试框架和工具应该可以很容易和不同工具集成。
这样的集成可以让你更快地从自动化测试中获得价值。
为执行与云解决方案集成实现自动化测试是一个方面。
我们需要设置操作系统浏览器组合基础设施，或是在需要执行的测试上给出较好的设备覆盖（基于被测试产品的环境）。
在很多情况下，有了虚拟机或虚拟器的帮助，在内部设置这个基础设施变得可行。
但是在很多情况下，设置、管理和维护变得非常复杂。
同时，也可能会使关注点从产品的测试转向基础设施的管理和维护。
在这种情况下，有很多基于云或内部私有云的解决方案，帮助你在本地构建并实施测试，在云端执行。
这也减轻了创建实验室（web/mobile）和管理基础设施的负担和成本，相反，团队可以更关注于产品测试的核心方面。
值得关注的基于云的执行工具包括SauceLabs、BrowserStack、pCloudy、AWS Device Farm、Google的Firebase Test Lab等等。
可视化测试在某些情况下，仅仅做功能验证是不够的。
我们还需要确保，在一定的容忍范围之内，被测试的产品在一段时间内完全符合设计和预期。
有很多优秀的工具和实用程序，有开源的和商用的，可以和自动化测试集成，完成附加的可视化回归。