通过这篇文章，我们将打开一系列出版物，说明如何在LANIT的一个主要项目中实现大型信息系统的手动测试过程的自动化以及其结果。

第一部分-组织和管理-应该首先对负责测试自动化并创建整个系统的人员有用。 项目经理，小组负责人以及功能和自动测试服务的所有者， 每个关心“如何为他们的IT系统构建具有成本效益的端到端测试”的人，都将在这里找到具体的计划和方法。

来源

第1部分-组织和管理。 为什么我们需要自动化。 组织开发和管理过程。 使用组织

最初，一开始有一个庞大而复杂的信息系统（我们将其称为“系统”），其中包含众多复杂，漫长且相互关联的业务场景。 所有脚本均通过Web界面以手动模式作为端到端测试（仅在最紧急的情况下有超过一千五百种这样的场景）。 此外，在对产品进行下一次部署更新之前，在每个新发行版或修补程序的回归期间，所有这些方案都必须至少完成一次。

在某个时刻，当以手动模式单击鼠标变得完全难以忍受时，我们决定将其全部自动化。 这就是他们通过开发基于java +硒+硒化物+硒化物的独立服务所做的事情，该服务又被称为“测试框架”或简称为“自动测试” 。

从历史上看，测试框架代码是由两个团队开发的。 首先，第一团队创建了具有数十种场景的原型。 然后，第二个团队进行了一年的扩展，扩展了原型的广度（测试数量）和深度（引入了典型的编码和实现模式）。

我是第二团队的团队和团队负责人，该团队采用了用于扩展的原型框架（于2018年5月）。

在撰写本文时，一年前设定的任务已经完成，并且为项目团队提供了稳定的自动化服务 。 我强调服务并不是徒劳的，因为最初的任务不是设置为开发应用程序，而是为“功能测试”组提供用于自动化测试的服务。 并且此功能随后极大地影响了开发的组织和测试框架的体系结构。

总结

大约有1,500个测试场景是自动化的：每个测试中有200至2000个用户操作。

该服务的总容量最多可同时运行60个浏览器，而这不是限制（由于虚拟机的原因，此数目可以增加5倍）。
完全回归的总持续时间不超过3小时，并且PreQA测试少于1小时。

已实现了广泛的功能：

• 本地使用（实时执行）和远程使用（通过Bamboo计划）；
• 通过过滤器限制运行测试的组成；
• 详细的报告，其中包含测试场景的每个步骤的结果（通过“魅力”框架）；
• 从/向浏览器下载文件和将文件上传到浏览器，然后根据文件的格式和内容检查其处理结果；
• 计费和控制角度接口的异步特性。 包括对Angular和REST服务之间的挂起请求（待处理请求）的控制；
• 控制浏览器日志；
• 视频测试录像；
• 在测试“下降”时删除页面快照；
• ELK中的事件传输；
• 在小事情上更多...

为什么需要所有这些？

一开始，该系统的目的非常简单明了。

想象一下，您有一个大型注册表系统，用于管理范围广泛的文档及其生命周期，这些文档提供了数百个业务流程。 此外，有数百万人，供应商-数以万计，服务-数以千计的复杂文档（包括框架和模板）以及提供业务流程的方式有数百种...

所有这些都变成了一个半千个测试方案，这只是最高优先级，也是积极的。

在自动化过程中，发现了各种细微差别，需要使用各种解决方案。

例如，一个脚本可能包含多达数百个单独的操作，其中包括一些有趣的操作：“下载包含数据的EXCEL文件，并验证系统是否处理了该文件中的每个记录”（为解决此问题，它花费了几个步骤来准备数据，然后检查将数据加载到其中的结果。系统）。 现在，我们增加了测试数据重用的限制：成功完成大多数测试场景的测试数据应该是“新鲜的”，并且以前在类似场景中不使用（测试期间，系统中数据的状态发生了更改，因此，它们无法用于以下用途）相同的检查）。

来源

在某个时候，作为回归的一部分对系统进行的手动测试似乎不再具有成本效益且足够快，他们决定通过Web用户界面对其进行自动化。

换句话说，功能测试组打开“页面”，选择“测试组”，然后按“执行”按钮（我们使用Bamboo）。 然后，自动测试（以下称为自动测试。通常指定创建的产品进行测试）通过浏览器自动模拟系统中用户的操作（“按下”必要的按钮，在字段中输入值，等等），完成后，显示有关所有用户的详细报告步骤和完成的动作以及验证结果（系统预期反应与其实际行为的对应关系）。

总体而言，自动测试的目的是自动化端到端测试。 这是一个“外部”系统，不参与被测系统的开发过程，并且与开发人员所使用的单元测试或集成测试完全无关。

目标

有必要显着降低进行End-2-End测试的人工成本，并提高完成量和减少量方面的退化速度。

任务

开发的主要任务很简单地制定了-在接下来的6个月内自动化1000个具有最高优先级的测试方案。

基本测试动作的预计数量在100到300之间，这为我们提供了大约20万种使用10-20行代码的测试方法，而没有考虑辅助程序，数据提供者和数据模型的一般和辅助类别。

因此，事实证明，考虑到时间限制（130个工作日），有必要每天至少进行10个测试，同时还要考虑到系统中发生的变化（系统正在积极开发），以确保已实施的自测的相关性。

根据专家估计，进行一项自动测试所需的劳动为4-8小时。 因此，我们至少有5人组成的团队（实际上，在自动测试开发的高峰期，该团队有10多名自动化工程师）。

需要解决的任务也是可以理解的。

• 配置过程和命令：
• 定义与客户（功能测试小组）的交互过程，确定测试用例描述格式，作为自动化团队的输入；
• 组织开发和维护过程；
• 组队。
  
• 使用以下功能开发自动测试：
• 在浏览器中自动单击按钮，并初步检查页面上是否存在元素以及必要的信息；
• 提供包含Yandex.Map等复杂元素的作品；
• 确保将自动生成的文件加载到系统中，并确保从系统下载文件并验证其格式和内容。
• 提供浏览器屏幕截图，视频和内部日志中的记录。
• 为了能够与邮件服务器，任务跟踪系统（JIRA）等外部系统集成，以检查受测系统与外部系统之间的集成过程。
• 提供有关所有已采取措施的书面报告，包括显示已输入和已验证的值以及所有必要的投资。
• 在并行模式下以所需的体积执行测试。
• 在现有基础架构中部署自动测试。
• 优化辅音目标概念的已经自动化的测试脚本（改进的速度-大约每周冲刺50次测试）。

正如我在简介中所提到的，一开始我们有另一个团队实施的MVP原型，必须将其从20个测试增加到1000个，并在此过程中添加新功能，并确保进行更改时具有可接受的可伸缩性和灵活性。

入口处另外还有一个工作原型，这为我们提供了一个技术栈，其中包括：Java SE8，JUnit4，Selenium + Selenide + Selenoid，Bamboo作为测试的“运行者”和Allure报告的“构建者”。 由于原型可以正常工作并提供必要的基本功能，因此我们决定不更改技术堆栈，而是集中精力开发解决方案的可伸缩性，提高稳定性并开发缺少的必需功能。

基本上，一切看起来都是可行和乐观的。 而且，我们在给定的时间完全可以应付任务。

以下内容描述了开发自动测试的各个技术和过程方面。

自动测试的说明。 用户故事和功能

来源

自动测试在测试组使用的上下文中实现了以下用户故事集：

• 手动测试自动化
• 自动完全回归；
• CI \ CD链中装配的质量控制。

实现细节和体系结构决策将在第2部分-技术中讨论。 体系结构和技术堆栈。 实施细节和技术惊喜 。

自动和手动测试（用户案例）

作为一名测试人员，我想执行目标E2E测试，该测试将在没有我直接参与的情况下（以自动模式进行）执行，并将根据所采取的步骤向我提供详细的报告，包括输入的数据和获得的结果，以及：

• 在开始测试之前，应该可以选择不同的目标支架。
• 应该能够管理所有已实施的运行测试的组成；
• 在测试结束时，您需要从浏览器屏幕上获取测试视频；
• 测试崩溃时，您需要获取活动浏览器窗口的屏幕截图。

自动完全回归

作为测试小组，我想每晚在自动模式下的特定测试台上执行所有测试，包括“自动手动测试”的所有功能。

CI \ CD链中的装配质量控制

作为一个测试小组，我想在更新目标功能测试阶段支架之前，在专用的preQA支架上对系统已部署的更新进行自动测试，然后将其用于功能测试。

实施的基本功能

来源

这是自动测试的主要实现的简要功能集，这些功能被证明是至关重要的或只是有用的。 一些有趣功能的实现细节将在本文的第二部分中。

本地和远程使用

该功能提供了两个用于运行自动测试的选项-本地和远程。

在本地模式下，测试人员可以在其工作场所运行所需的自动测试，同时可以观察浏览器中发生的情况。 发射是通过IntelliJ IIDEA-）中的“绿色三角形”完成的。 该功能在项目开始时对于调试和演示非常有用，但现在仅由自动测试的开发人员使用。

在远程模式下，测试人员将使用Bamboo计划的界面以及正在运行的测试的组成参数，支架和其他一些参数来启动自动测试。

该功能是使用环境变量MODE = REMOTE | LOCAL实现的，具体取决于在Selenoid云中初始化的是本地还是远程Web浏览器。

通过过滤器限制运行测试的组成

该功能使用户可以方便地限制远程使用模式下运行测试的组成，并减少测试时间。 使用两阶段过滤。 第一步基于FILTER_BLOCK变量阻止测试的执行，并且主要用于排除大量测试的运行。 第二步“跳过”仅测试与FILTER变量匹配的测试。

过滤器的值指定为一组正则表达式REGEXP1，...，REGEXPN，由“或”原理应用。

在手动模式下启动时，要求测试人员将特殊的环境变量设置为适用于特殊@ Filter（字符串值）注释的正则表达式列表，该注释会注释测试类中的所有测试方法。 对于每个测试，此批注都是唯一的，并且是根据由下划线分隔的一组标记构造的。 我们使用以下最小模板SUBSYSTEM_FUNCTION_TEST-ID_ {DEFAULT}，其中DEFAULT标记用于自动夜间回归中包含的测试。

该函数是通过org.junit.runners.BlockJUnit4ClassRunner类的自定义扩展实现的（详细信息将在本文后续的第2-1部分中给出）

用所有步骤的结果记录报告

显示所有测试动作（步骤）的测试结果，以及Allure Framework中可用的所有必需信息。 列出它们没有任何意义。 官方网站和整个互联网上都有足够的信息。 使用“魅力框架”并没有什么奇怪的，总的来说，我推荐使用它。

使用的主要功能是：

• 显示每个测试步骤（步骤名称与测试规范中的名称相对应-测试脚本）；
• 以人类可读的形式显示步骤参数（通过所有传输值的toString方法的必需实现）；
• 将屏幕快照，视频和各种其他文件附加到报告中；
• 通过类型和子系统对测试进行分类，以及通过使用专用注释在Test Link测试用例管理系统中将自动测试与测试规范链接起来。

从/向浏览器下载文件并上传到浏览器，并进行后续验证和分析

处理文件是测试脚本极其重要的方面。 必须同时提供上传各种文件和下载。

首先， 下载文件意味着根据测试脚本执行的上下文将动态生成的EXCEL文件加载到系统中。 下载是使用硒工具提供的标准方法实现的。

上载文件意味着通过在浏览器中按“按钮”到本地目录，然后将该文件随后“传输”到运行自动测试的服务器（安装了远程Bamboo代理的服务器），来下载文件。 此外，该文件已按照格式和内容进行了解析和分析。 主要文件类型为EXCEL和PDF文件。

事实证明，该功能的实现是一项艰巨的任务，这主要是由于缺乏标准的文件处理功能：目前，该功能仅通过“ chrome：// downloads /”服务页面为Chrome浏览器实现。

在第二部分中，我将详细介绍实现细节。

记账和控制Angular接口的异步性质。 Angular和REST服务之间的待处理请求控制

由于我们的测试对象是基于Angular的，因此我们必须学习与前端和超时的异步特性“战斗”。

通常，除了org.openqa.selenium.support.ui.FluentWait之外，我们还使用一种经过特殊设计的等待方法，该方法通过Javascript检查与前端REST服务的“不完整”交互，并根据此动态超时来获取有关是否遵循的信息。然后再等一会。

从功能的角度来看，由于无法满足静态期望，而无法以其他方式确定操作的完成程度，因此我们能够大大减少完成测试所需的时间。 此外，这使我们能够定义存在性能问题的“悬挂式” REST服务。 例如，他们捕获了一个REST服务，该服务的页面上显示的记录数设置为10,000个元素。

有关“冻结的” REST服务及其调用的所有参数的信息，由于基础结构原因导致测试“下降”，因此将其添加到下降的测试结果中，并作为事件在ELK中进行广播。 这使您可以立即将识别出的问题转移到系统的相应开发团队。

浏览器日志控制

添加了浏览器日志控制功能，以控制SEVERE级别页面上的错误，以接收有关已删除测试的其他信息，例如，监视诸如“ ...无法加载资源：服务器以状态500（内部服务器错误）进行响应”之类的错误。

浏览器中页面处理错误的组成适用于每个测试结果，并且还作为事件在ELK中卸载。

测试的视频记录，并在测试“下降”时删除页面快照

实现功能是为了方便诊断和解析掉落的测试。

对于所选的远程测试运行模式，将分别启用视频录制。 该视频作为附件附在“魅力”报告中。
测试崩溃时，将自动获取屏幕截图，并将结果也应用于“魅力”报告。

将事件传递给ELK

实现向ELK发送事件的功能，可以对AutoTest的一般行为和测试对象的稳定性进行统计分析。 目前，已发送事件以完成测试，包括结果和持续时间，以及严重级别的浏览器错误和固定的“冻结” REST服务。

发展组织

来源

开发团队

因此，我们至少需要5名开发人员。 添加另一个人以补偿计划外的缺勤。 我们得到6。再加上团队负责人，负责跨领域功能和代码审查。

因此，有必要雇用6名Java开发人员（实际上，在自动测试开发的高峰期，该团队超过了10名自动化工程师）。

考虑到市场的总体状况和相当简单的技术体系，该团队主要由实习生组成，其中大多数要么刚从大学毕业，要么就在去年。 实际上，我们正在寻找具有Java基本知识的人员。 优先选择希望成为程序员的手动测试专家，以及那些希望将来成为程序员的具有（微不足道的）开发经验的积极候选人。

对初学者的依赖要求以特定的职业提议，明确的工作时间表以及将应用程序划分为单独的功能域的形式引入补偿机制（更多内容请参见第2部分-技术，体系结构和技术堆栈。实现细节和技术惊喜）。

在组织自动测试的开发过程中，我们考虑了人员流动率高的预测，并与初级人员建立了联系，因此自动测试项目成为我们开发人员职业生涯中必不可少的第一步。毕业生或有条件的CodeRush课程的一种年度居留权。事实证明这种方法是正确的。

开发过程

开发过程实际上没有专门的迭代。开发人员在其职责范围的指导下，从待办事项中“拉”任务并开始执行它们。

任务主要是开发新测试或改进（更新）现有测试。完成的任务通过合并请求过程（使用GitLab）传递代码检查。成功检查代码后，结果立即“合并”到主分支（实际上合并到生产分支）并立即可供使用。

此过程的关键方面是测试交付产品的持续速度以及开发人员独立工作的可能性。在我们的过程中，在实现特定子系统的自动测试/自动测试时，实际上没有任何小组工作，这表现为禁止将自动化任务划分为子任务。

代码审查必定要走一步，如果在这一步结果（代码）与代码约定和体系结构要求不符，则该任务将返回以进行修订。代码审查使团队负责。

在将任务提交给代码审查之前，开发人员必须将测试通过的结果链接到该任务，并且该结果在所有步骤中都必须成功。

有趣的一点：在开发过程中，经常发现自动测试无法成功通过，因为测试脚本已过时或被测试的子系统包含一个错误，该错误已通过手动测试中的变通办法得以克服。在这种情况下，自动测试的开发将停止，直到功能测试小组了解这是错误还是功能并更正规范和/或系统为止。

在“测试步骤”中对实现的复杂性进行了评估，这些“测试步骤”实际上是由自动化测试场景通过简单地汇总这些步骤而确定的。实际上，这是测试案例中所有段落的总和。

除了每周进行一次此过程外，我们每小时举行一次团队会议，以回顾性地回顾已完成的最新工作，确定组织和技术难题，并在可能的情况下确定改进开发过程的其他措施。与sprint回顾事件完全相似。

开发任务规范

积压工作中的最初开发任务来自功能测试小组的测试规范（测试脚本），该小组充当AutoTests的内部用户和利益相关者。

开发一种方便有效的格式来指定自动测试是构建过程的重要组成部分。一方面，我们计划使用条件分支将模棱两可和模棱两可的解释减至最少，这需要对自动测试所需的目标行为进行不断完善。另一方面，有必要确保在不进行大量处理的情况下使用现有的测试规范。最后，我们来到了下一个清单。

在描述测试用例的步骤（打开页面，在字段中输入值，等等）时，必须使用命令，这实际上是检查系统功能的要求。如果您需要指定其他（辅助）信息，则必须将其明确标记为“其他信息” /“注释”（重要的是，团队不要混淆这些信息是行动指南还是仅供参考）。

一个测试用例应包含线性的测试步骤序列，而不能在任何步骤上分支测试逻辑（分支的示例：如果执行步骤的结果是错误，则执行这些步骤，如果结果成功，则执行其他步骤步骤）。另外，不允许在一个测试用例中描述多个具有不同前提条件/不同步骤的测试脚本：规则“一个测试用例描述一个线性测试方案（正或负）”在此处适用。

为了避免测试用例中的步骤重复，可以完全重用测试用例（捐助者用例）的步骤作为另一个测试用例（“主要”用例）的一部分。因此，在“主要”测试用例的规范中，允许将完成捐赠者案例的必要性指示为“从案例X完成所有步骤”（但不允许捐赠者案例的部分步骤）作为步骤之一。

储存库组织

存储库的组织非常简单，可以满足开发过程的要求。只有一个主分支母版，从中分支功能分支。通过合并请求的功能分支在代码检查完成后立即合并到主分支中。

在项目开始时，我们决定不支持不同版本的自动测试-这是没有必要的，因此我们没有创建单独的发行分支。

特征：

（+）为小型团队连续交付功能的简单过程；
（+）允许您在开发功能时部署它们，而无需在代码级进行发布计划；
（+）可让您“赶上”真正的开发而不会引起发布延迟；
（-）仅支持一个版本的框架（当前）；
（-）在早期版本的自动测试中，仅支持修补程序错误。

结果，我们得出以下规则。

开发者

• 从MASTER中获取所需类型的分支。
• 运行开发。
• 在所需的FEATURE支座上进行测试。
• 如果自动化工具在分支上独立工作并且具有线性历史记录，则应通过重新设置基准执行“线性注释历史记录的压缩”。
• 将最终提交发布到Gitlab，并为团队负责人或负责人创建合并请求。在合并请求中，指定：
• 名称-Jira跟踪错误系统中的任务代码；
• 描述-在Bamboo中测试分支结果的链接。

GateKeeper（由团队负责人运行）

• 根据Bamboo中的自动测试结果检查开发分支的性能。
• .
• (merge) FEATURE DEVELOP, .
• .

---

kotalesssk .

1, , . 2.

第二部分-技术部分-主要集中在自动化小组UI端到端测试和领先的测试自动化的领导者。在这里，他们将找到用于代码和部署的体系结构组织的特定方法，从而在面对测试规范不断变化的情况下，支持大规模并行测试的大规模开发。另外，您可以在第二部分中找到UI测试所需的完整功能列表，其中包含一些实现细节。还有可能还会遇到的惊喜列表。