画景观

在专注于任何功能测试自动化技术和工具之前，先看大局总是一个好主意。 这里有一些值得强调的点。

遵循正确的模式

众所周知，在设计自动化测试和持续集成管道时，应该遵循测试金字塔概念（而不是测试冰淇淋蛋卷）。

这背后的原因很简单——金字塔底层的测试执行得更快，而且实施起来通常更便宜。此外——我们越早发现错误——越好。这并不意味着自动化更高级别的测试（验证所有系统组件）不那么重要。

保持平衡

决定哪些测试应该自动化以及自动化程度如何始终是测试策略的关键部分。遵循测试金字塔是一个很好的起点，但同样重要的是不要低估其他测试技术的价值，包括功能性（例如探索性）和非功能性（代码分析、性能、弹性、安全性……）。在自动化功能测试时，根据经验，用户界面测试应保持在最低限度（涵盖关键业务路径），并尽可能地通过 API 进行测试。

选择你的工具

单元和集成测试的工具选择与开发组件的技术密切相关。 JUnit、Mockito、Jest 等工具可帮助开发人员在早期构建阶段实现测试覆盖。

我们可以在测试金字塔的更高层次上开始思考常见的测试框架。由 Spring Cloud Contract 和 PACT 等工具支持的 Consumer Driven Contracts 作为早期非功能性 API 合同验证的手段越来越受欢迎。

但是，如何在多个组件和服务协同工作的集成环境中验证对我们的业务至关重要的逻辑呢？我们如何组织我们的测试场景并通过合理的努力使它们可执行？

 这就是端到端测试框架可能派上用场的地方！

那里有很多商业框架，但我们决定采用开源并使用大型社区支持的成熟解决方案。

我们选择背后的原因是：

• 当事情成熟到可以正常工作时，我们喜欢它
• 我们希望从开源框架的广泛集成和定制可能性中受益
• 我们已经使用下面详细描述的工具集成功地满足了验收测试的内部和商业需求。

端到端测试框架

概述

我们的框架旨在支持自动化验收测试，旨在同时适应 API 和 GUI 测试。

它在 JAVA 中实现，如果需要，可以轻松扩展以连接到数据库和消息队列。

场景（与企业主/分析师一起创建）是用 Cucumber（Gherkin 语法）编写的，并被分组为特性。

基于场景标签（指定严重性、组件等）使用 TestNG+CubumberJVM 和 Maven 执行测试。测试可以并行运行；可以使用 TestNG 或 Cucumber hooks 设置测试数据。

引擎盖下是什么？

• Cucumber (Gherkin) –> 场景和功能
• RestAssured -> REST API 步骤定义，
• JAX-WS -> SOAP API 步骤定义，
• Selenium -> GUI 步骤定义
• Zalenium -> 在不同浏览器上运行 GUI 场景，视频录制仪表板
• Allure -> 通用格式 HTML 测试报告
• 支持库：
  • Swagger Codegen -> 从 Swagger 生成类模型
  • Apache CXF -> 从 WSDL 生成类模型
  • Java Faker -> 假数据生成器
  • Waiter -> selenium 等待包装器
• TestNG+CucumberJVM, Maven -> 运行测试，钩子之前/之后
• Jenkins （或类似的）-> CI/CD

优点和特点

准备部署

“样板”已准备好部署为本地或云中的 Docker 容器，例如作为 Openshift 或 K8s 项目（这是我们的开箱即用方法中的首选，以实现最高效的执行环境）。

可执行的测试规范

Gherkin 为人类友好的测试规范提供语法，可以作为代码实现和运行。特性、场景和步骤组成了面向业务的测试规范，而步骤定义和支持代码一起执行测试任务。

以下是可执行测试场景的两个示例。

API（基本场景）：

GUI (using a Scenario Outline):

请注意，使用数据驱动场景就像在“示例”表中添加新行一样简单！

友好的报告

Allure 为 RestAssured、Cucumber 和 Jenkins 提供美观的 HTML 报告和开箱即用的集成。

我们进一步定制了我们的报告，以提供：

对 GUI 测试执行的视频记录的引用

链接到票据管理系统（例如 JIRA）

需要时，还可以将执行结果报告回 JIRA（通过自定义“@after”钩子）。

最佳实践

以下是实施和执行方案时要遵循的一些最佳实践：

1. 场景应与企业主/分析师一起准备，并用 Cucumber (Gherkin) 编写，同时利用其功能，例如：
   1. 场景大纲和示例
   2. 数据表
   3. 标签（例如“@gui”、“@api”、“@blocker”等）
2. 场景必须相互独立，即它们中的每一个都应该能够单独运行（测试数据不应“泄漏”到其他场景）
3. 场景不应包含不必要的技术细节，并且应该易于理解
4. 场景应该根据测试的业务领域分组在 *.feature 文件中（不一定每个用户故事）
5. 实现 GUI 步骤定义时：
   1. 推荐使用页面对象模式
   2. 禁止“Sleeps” 
   3. id、css 选择器优于 xpath
6. 实现 API 步骤定义时：
   1. 公共属性应与 RestAssured RequestSpecifications 一起重用
   2. 过滤器应该用于记录
   3. 只要有可能，应该从 API 定义（.wsdl、.swagger）创建 DTO
7. 测试应在专用环境中/使用专用测试数据运行（以避免干扰手动测试）
8. 自动生成的数据应加前缀或后缀（以便与手动测试数据分开）
9. 应该模拟集成范围之外的系统（我们在环境中无法控制）

为什么不使用 Postman 和 Cypress.io 呢？

Postman（与 Newman 一起）和 Cypress.io 都是很棒的（半商业）工具，尽管有些有限。在大型企业环境中工作，对自动化测试的要求有时会更加苛刻。以 API 测试为例——我们实际上使用 Postman 作为开发（和测试开发）辅助工具，但 RestAssured 让您可以更好地控制测试的组织和执行。

一个很好的例子是我们最近必须涵盖的一个测试场景，它需要控制 SSL 会话。虽然 Postman 在请求之间保持 SSL 会话打开（以不可配置的方式），但 RestAssured 允许您选择是保持 SSL 连接处于活动状态还是在后续请求之后关闭它（通过其 connection-config 方法）。

Cypress.io 的受欢迎程度正在增长，但是当需要完整的浏览器控制（使用选项卡和 iframe）和跨浏览器测试时，Selenium 尽管有缺点，但仍然可以提供更多功能。

（请注意，框架组件可以根据项目需求进行修改和调整）

保持在一起

以下是有关如何充分利用自动化端到端测试的一些更一般的提示。

与您的 CI/CD 管道集成

自动化验收测试应集成到 CI/CD 管道中，作为将应用程序自动部署到专用测试环境（例如使用 OpenShift 项目模板创建）之后的下一步。验收测试失败意味着部署失败！

使您的自动化测试成为开发过程的一部分

自动化测试场景应该与产品开发一起编写。与开发功能并行编写测试（而不是事后才进行测试）将帮助您缩短反馈循环并提供更好的产品。

与利益相关者合作

邀请利益相关者（业务分析师、手动测试人员）参与 BDD 测试场景将使您的团队更好地沟通，甚至可能有助于在将错误/差距转化为代码之前识别它们。无处不在的领域语言将有助于避免误解。

不要重复你自己（和你的测试）

应避免跨不同测试级别重复业务逻辑覆盖。端到端测试应该只涵盖应用程序中最重要的用户旅程。

根据反馈采取行动

在任何测试步骤中发现的错误都应该被测试金字塔最低级别的测试覆盖。

注意执行时间

就 e2e 测试套件执行的时间预算达成一致是个好主意，例如 15 分钟。请记住，您的自动化测试是一个“安全网”，不应使部署过程过长而令人不安。

原文：https://bluesoft.com/acceptance-testing-in-enterprise-environments/

本文：https://jiagoushi.pro/node/1829