测试工程师要凉凉？机器学习自动化测试可能只是骗人的营销手段

Posted 2021-07-14 测试员小静

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了测试工程师要凉凉？机器学习自动化测试可能只是骗人的营销手段相关的知识，希望对你有一定的参考价值。

导读： 人工智能和机器学习是当今软件行业最热门的词汇。测试社区、服务组织和测试产品和工具公司也开始在向这些方面快速倾斜。

虽然软件测试行业内确实发生了一些有趣的事情，但很多似乎只是炒作。非常遗憾，很难从这些复杂的事情中找出有趣的工作、研究和解决方案。

更多优质内容请关注微信公众号“程序员小濠”（免费获取测试资料）

现在流行的主题之一是“无代码自动化功能测试”，我们让机器识别如何自动化测试软件产品。搜索关键字“无代码测试自动化”或“测试自动化中的 AI”会查到一些该领域中的工具。

我非常想知道到底发生了什么。AI 如何帮助自动化功能测试，还是这仅仅是欺骗人们使用工具的营销手段？

在进一步讨论之前，我想从自动化功能测试设计、工具和框架的角度，尤其是在敏捷的方面强调几个我认为重要的标准或需求。

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

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

使用这种方法，最重要的是在产品构建的阶段尽可能多地自动化测试，我们要遵循自动化测试金字塔 (
https://martinfowler.com/articles/practical-test-pyramid.html) 的原则。一旦团队知道现在在顶层（UI 层）需要自动化一些什么之后，我们就应该自动化这些测试。

由于产品在不断发展，测试肯定会随着产品的发展而失败。这不是测试的问题，而是测试没有跟随产品的发展而发展。

想要让之前通过的测试再次通过，自动化功能测试工具、框架应该使现有测试的更新和演变尽可能地简单。可能需要在定位器中进行变更，或者需要在流中进行，这并不是很重要。

如果这个过程很简单，团队成员会从自动测试执行和其工具框架中获益匪浅。

自动化测试的目标清晰可见

这是我认为的自动化测试最重要的方面，了解什么自动化了，它是否能展现出相对于一系列 UI 操作之外的价值。

确定性和健壮性测试 – 定位器和维护

如果测试执行环境不变（比如说测试中的产品、与测试相关的测试数据等等），自动化测试的结果应保持一致。这个方面也可以被认为是测试稳定性。

如果因为某些原因，测试失败了（比如产品的缺陷，测试没有更新等），每次重复执行该测试也应该以相同的原因失败。

保证测试确定性和健壮性的一个方法是保证可以定位并可靠地更新定位器，从而让维护变得简单。在某些情况下，工具集可能会使用（人工）智能来找出识别相同元素的下一个最佳方案，防止因定位器改变而找不到元素导致的测试失败。尤其是在唯一的定位器不可用的情况下，或者定位器的变更是基于产品状态的情况下。

也可以用不同的方法来唯一地识别一个元素。工具和框架需要支持多定位器的识别，测试作者应该能够详细说明如何使用它们。

通常导致测试失败的原因如下：

定位器是动态的，每次产品的发布或使用都会造成变化。
定位器依赖于被测试产品的环境。
比如：基于运行测试时的数据集

上面提到的因素会让实现确定性和健壮性的自动化测试变得不太可能。

在相对来说比较新的工具集中，我很高兴看到它们能够以各种各样的定位器策略来识别一个元素。在你多次运行测试的时候，工具能知道测试的预期，也会尽可能用最可靠的方法找到元素。这样，测试的健壮性就得到了提升，既不会影响测试的质量，也不会让测试“不经意的通过”。

测试片段的编写、更新和自定义应简单且可复用

应该非常容易编写自动化功能测试的片段，并按照需求，选择不同的数据值复用它们。这些代码片段可能包含简单逻辑、条件逻辑，也可能包含一些重复的内容。

比如说：登录代码片段，被记录和实现一次，在所有需要使用特定数据登录的测试中使用。

很多时候我们需要更新现有的脚本。原因可能是因为测试的发展（由于需要测试的产品更新了），让测试变得健壮（比如处理变化、动态的测试数据），或处理特定的情况下保证在某些环境下能运行测试等等。

如果脚本是使用开源工具实现的，比如 Selenium WebDriver 等等，那么我们需要直接处理代码，这个任务相对比较容易。通过良好的编程实践也可以重构并升级代码。

然而，如果脚本是使用非编程、或非基于编程的工具（免费或商用）实现的，那么这项工作会变得很复杂。我们需要保证工具允许某些自定义，也不需要在仅仅做了一些小的变更的情况下重新实现整个测试。

测试数据

根据测试的领域和类型，测试数据可以是简单的或非常复杂的。有很多方法来制定测试数据，比如：

在测试实现中（比如在 Login.java 页面文件中硬编码用户名和密码）。
在测试规格说明或测试目的中（比如在测试中使用 @Test annotations）。
在代码中，单独的数据结构或类等等。
外部文件和数据存储：
CSV
JSON
YAML
Property
XML
INI
Excel
Database
…

测试自动化工具、框架应该：

支持多种方法制定或查询测试数据
支持对其规范和查询的优化
提供对不同类型的测试套件的不同数据集能力
提供在我们想要运行的测试的每个环境制定数据的能力。

API 测试解决了多个不同的目的，非常有价值。它在自动化测试金字塔中位于 UI 测试的下一层。

然而，作为自动化功能测试的一部分，在可行的情况下，以及被测试产品的支持下，我们应该在这些领域中使用 API 测试技术：

测试数据设置和创建
测试状态的设置
比如：使用 API 登录而不是让每个测试都通过 UI 交互登录，这是很耗费时间的，在测试执行的过程中也可能会发生问题。
我们可以在测试执行的时候使用 API 来做一些事情，这些活动不需要总是在 UI 中执行。

自动化测试框架和工具需要能够利用 API 来执行测试数据设置和创建。这代表着：

使用所需的头和参数创建适当的 API 请求
分析 API 响应，了解是否需要对响应执行断言。

并行执行

自动化功能测试很慢，需要一段时间来执行。随着自动化测试数量增加，获得反馈的时间也会增加，因此降低这些测试的价值。解决这个问题的一个方法（除了在功能层减少自动化测试的数量之外）就是并行执行测试。

这也代表着我们需要保证测试独立运行（可以用任何顺序执行），并且不共享，也不依赖于另外一个测试创造的被测试产品的状态。

根据本地变更运行测试

这是经常被忽视的一个方面。测试的实施者应该能够在实现阶段针对本地代码的变更来运行测试，或者针对被测试产品的特定问题进行调查或 RCA。

请注意我不是说在某个特定的本地计算机上执行测试，而重点是在本地产品代码变更的情况下仍然进行测试的能力。比如，我已经修复了错误，我需要针对它进行测试。所以我会在我的计算机上部署代码，并（在本地或在云上）运行测试（子集），将测试指向我的本地（和临时）环境来获得相同的反馈。如果所有的变更都运行正常，那么我需要把我的代码推送到版本控制系统中。

这应该是自动化解决方案的一个简单功能。

环境

我们应该能够在任何可选择的环境下执行测试。

如果在多个环境下（比如开发、测试、登台环境）部署的代码是相同的，那么在各个环境中的测试执行结果也应该是相同的。

这种环境变更应该做成只是简单的改变配置。

这里的重点是，应该可以根据特定的环境进行隔离并执行测试。需要有办法给能在一系列环境下可执行的测试打标签。运行测试的时候，根据所选择的执行环境，只有相关的测试才应该自动化运行。

支持多浏览器 / 移动端（本地应用程序）

这是另外一个重要的方面。只能在特定的操作系统浏览器组合或设备下运行的软件极为罕见。根据产品的环境，它可能需要支持多个浏览器，如果它是本地应用程序，那么它需要能够在多个设备下运作。

因此，实现的功能测试需要能在各个操作系统浏览器组合下运行，或者在被测试产品需要的设备上运行。

切换到不同的执行环境应该做成以简单地改变配置来实现。

调试和根本原因分析（RCA）

是测试就会失败的。实际上，如果你的测试从来都不会失败，那么就需要改改执行环境来检查一个测试是否有问题了，得确保它会失败，并能看到正确的失败类型和原因。

自动化测试的价值是保证每次测试失败的时候，会发生这些情况：

测试失败的原因是合理的，比如和测试不稳定性没关系。
你很容易就能够了解到测试失败的原因，比如说 RCA 很容易。
在很多情况下，测试的结果不足以了解它失败的原因。测试自动化框架和工具需要保证在调试模式下运行测试，一步一步了解并找出测试失败的根本原因，或者更好地是指导你找出具体失败了的测试元素以及具体原因。

基于 RCA，如果测试需要更新，自动化测试框架和工具需要足够简单可以修复问题。

版本控制

所有的测试和测试代码都要在版本控制系统中。在有需要时，这可以让你查看历史和变更。

和 CI（持续集成）工具的集成

任何形式的自动化的核心价值就是尽可能频繁地执行测试的能力、自由度和价值。

我比较推荐设置好的 CI 管道（请参考“介绍管道和作业
https://docs.gitlab.com/ee/ci/pipelines.html”），对于每个触发的构建，每种类型的测试都能在每次提交的时候自动化逐步运行。这可以给团队早期的反馈，了解什么失败了，这样他们就可以尽快调试并修复错误。

为了在 CI 过程中集成自动化功能测试，本文中列出的所有功能和测试执行所需的设置（安装软件、库、配置等等）都需要自动化进行，也就是通过在命令行中执行相关带有适当参数的脚本来实现。

丰富的测试执行报告，进行趋势分析

好的测试执行报告是了解被测试产品状态的重要依据，特别是在测试量很大的时候。报告中应该包含有助于理解产品总体质量的指标和信息，辅助我们采取有意义的步骤来提升产品的质量。

能够从整体、局部查看测试结果，并且以不同的可视化方式提供大量有意义的信息。

报告中应该包含大量已执行测试的信息，以及产品在执行期间的状态：比如

屏幕截图
视频录像
服务器日志
设备日志（如果运行在真实的设备上）等等
以及测试执行相关的元数据（比如 CI 构建号、被测试产品版本、浏览器、设备、操作系统、操作系统版本等等）

此外，不同的利益相关者需要不同类型的报告。

比如说：

经理可能想看更多的汇总报告、发展趋势、缺陷测试等。
团队成员可能会对测试运行的详细细节、失败的原因更感兴趣，就是帮助他们能快速进行根本原因分析，在后续步骤中采取有意义的步骤来提升产品和测试质量。

和其他工具和库集成

对于某些事情，有很多有趣的工具和库可以很好地完成。

比如说：

如果你想要记录日志，可以使用 log4j。
如果你需要和 CI 集成，只需要给测试的配置和执行选项提供命令行接口。这样，你的测试就可以和任何 CI 集成。

如果你认为自动化测试需要的所有功能都要从头开始构建，或者认为一个工具能提供所有的功能，这么想不仅很愚蠢，还会让工具变得很庞大，不能提供适当的功能。

你使用的自动化测试框架和工具应该可以很容易和不同工具集成。这样的集成可以让你更快地从自动化测试中获得价值。

为执行与云解决方案集成

实现自动化测试是一个方面。我们需要设置操作系统浏览器组合基础设施，或是在需要执行的测试上给出较好的设备覆盖（基于被测试产品的环境）。

在很多情况下，有了虚拟机或虚拟器的帮助，在内部设置这个基础设施变得可行。但是在很多情况下，设置、管理和维护变得非常复杂。同时，也可能会使关注点从产品的测试转向基础设施的管理和维护。

在这种情况下，有很多基于云或内部私有云的解决方案，帮助你在本地构建并实施测试，在云端执行。

这也减轻了创建实验室（web/mobile）和管理基础设施的负担和成本，相反，团队可以更关注于产品测试的核心方面。

值得关注的基于云的执行工具包括 SauceLabs、BrowserStack、pCloudy、AWS Device Farm、Google 的 Firebase Test Lab 等等。

可视化测试

在某些情况下，仅仅做功能验证是不够的。我们还需要确保，在一定的容忍范围之内，被测试的产品在一段时间内完全符合设计和预期。

有很多优秀的工具和实用程序，有开源的和商用的，可以和自动化测试集成，完成附加的可视化回归。这可以帮助从可视化的角度避免手动验证导致的错误。

一些值得关注的自动可视化测试案例包括 Nakal、Galen、Applitools 等等。

商用 / 开源

在我职业生涯的 20 年中，我主要都是使用开源软件和商用软件完成自动化功能测试。

近几年来，我听到和看到过太多开源工具由于是“免费的”而被使用的案例。这是一个很大的误解。你可能不需要给工具本身付费，但是使用它也会有相对的开销。

我不喜欢使用商用工具有自己的理由：

这些工具太贵了，有些甚至按小时和用户计算成本。
需要培训“选定的”人如何使用工具，现有的文档并不完善，因此培训变得很重要。对于这款工具，这就是额外的成本，将要使用工具的人（薪水）和培训的开销。
由于许可证和培训的成本很高，这些工具只能由“选中的”一小部分人使用，来帮助控制成本。
这些工具需要特别的、专用的硬件来运行。
这些工具大多数是录制回放的。就是说随着产品的发展，脚本需要重新录制。
商用工具不太易用，并有显著的提升或学习曲线。因此在没有支持的情况下使用这些商用工具可能是解决问题的巨大阻碍，团队最终需要工具支持以帮助和指导自动化的实现和执行。

同样，我喜欢开源工具的原因是：

它让我可以灵活地做我需要做的事情：这对于任何自动化框架和工具来说都是非常重要的。这可以帮助自动化随着被测试产品的发展而发展。
我可以查看工具的源代码，根据需要找到解决方案，而不需要等待“支持人员”来帮助解决我的问题。
我不需要花很多钱来买工具。如果我拥有（或者能学会）工具所需要的技术技能，那么就可以直接开始使用。（这里没有考虑程序员和自动化工程师的薪水和开销，或者某些库不能免费使用的情况。）
我喜欢编程和测试设计，大多数可用的开源工具（想当年）都需要编程。

但是在阅读了和使用了一些新的商用工具之后，我的想法发生了变化。原因如下：