人工智能和机器学习自动化测试介绍

人工智能和机器学习自动化测试介绍

敏捷世界的自动化功能测试标准和需求

人们通常认为需要在功能和产品稳定之后进行自动化功能测试。恕我直言，这是对自动化的浪费，特别是现在人们都看到了基于敏捷的交付实践的价值，并且开始使用了增量软件交付。

使用这种方法，最重要的是在产品构建的阶段尽可能多地自动化测试，我们要遵循自动化测试金字塔的原则。一旦团队知道现在在顶层（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）