在过去，我们只有很少的服务，并且在一天内投入生产更新其中一项以上的服务是非常
成功的 。 然后世界加速了，系统变得更加复杂，我们转型为具有微服务架构的组织。 现在我们大约有一百种服务，并且随着它们数量的增加，发布的频率也增加了-每周有250多个。
而且，如果在产品团队内部测试了新功能，则集成测试团队的任务是验证发行版中包含的更改不会破坏组件，系统和其他功能的功能。
我在Yandex.Money担任测试自动化工程师。
在本文中，我将讨论Web服务集成测试的发展，以及调整流程以增加系统组件的数量并增加发布频率。
关于发行周期的变化和计算机制的发展由ops和dev在
先前的一篇文章中进行了描述。 我将告诉您有关此转换过程中测试过程变化的历史。
现在我们有大约30个开发团队。 该团队通常包括产品经理，项目经理，前端和后端开发人员以及测试人员。 它们通过针对特定产品的任务的工作而团结在一起。 通常，对服务负责的是团队，这通常是对其进行更改的。
端到端验收测试
不久前，随着每个组件的发布，仅运行单元和组件测试，此后，只有少数几个最重要的端到端脚本在成熟的测试环境中运行，然后才能将服务投入生产。 随着组件数量的增加，它们之间的连接数量开始呈指数增长。 通常-完全不重要的连接。 我记得，发布市场数据服务的不可用性如何彻底破坏了用户注册（当然是在很短的时间内）。
这种检查更改的方法开始越来越失败-它需要通过自动测试来覆盖所有关键业务场景，并在具有准备发布的组件版本的完整测试环境中运行它们。
好的，已经出现了针对关键场景的自动测试-但是如何运行它们？ 集成到发布周期中的任务是，通过错误的测试滴将其可靠性降至最低。 另一方面，我想尽快进行集成测试阶段。 因此，存在用于执行验收测试的基础架构。
我们试图最大程度地利用已经在发布周期和启动任务中用于执行组件的工具：分别是Jira和Jenkins。
验收测试周期
为了进行验收测试，我们确定了以下周期：
- 监视传入任务以进行发布的验收测试，
- 运行Jenkins作业以在测试环境上安装发行版，
- 检查服务是否上升，
- 通过集成测试启动Jenkins工作，
- 分析运行结果，
- 重复测试（如有必要），
- 更新任务的状态-完成或损坏，在注释中指示原因。
每次都手动执行整个循环。 结果，我已经第十天发布了，我想发誓要执行相同的任务，充其量只能是屏住呼吸，抓紧我的头，并要求缬草
啤酒 。
监控机器人
我们意识到，在Jira中跟踪和报告新任务是快速且易于自动化的重要过程。 因此，有一个机器人可以做到这一点。
用于生成警报的数据以来自Jira的推送通知的形式出现。 启动自动程序后，我们停止使用接受任务更新仪表板页面，并且自动机的微笑幅度略有增加。
inger
我们决定简化验证过程，以确保在测试环境中的部署过程中没有发生组装或安装错误，并且提出了所需的组件版本，而不是其他组件。 该组件通过HTTP给出其版本和状态。 如果不同的组件不是用不同的语言编写的，则检查服务是否返回正确的版本将是简单易懂的-有些使用Node.js，有些使用C＃。 此外，我们最受欢迎的Java服务也以不同的格式提供了该版本。
另外，我不仅希望获得有关版本更改的实时信息和通知，而且还希望获得有关系统中组件可用性的更改的实时信息和通知。 为了解决此问题，出现了Pinger服务，该服务通过周期性地轮询组件来收集有关组件状态和版本的信息。
我们使用消息传递的推送模型-在测试环境的每个实例上部署一个代理，该代理收集有关该环境的组件的信息，并每10秒将数据存储在一个中央节点上。 我们转到该节点以获取当前状态-这种方法使我们能够支持一百多个测试台。
储物柜
现在是执行更复杂任务的时候了-组件的自动更新和运行测试。 当时，我们的团队在OpenStack中已经有3个测试平台用于验收测试，首先必须解决管理测试平台资源的问题：如果在系统上运行测试时更新下一个版本“更新”，那将是不愉快的。 也有可能是测试台调试完毕，然后就不应将其用于验收。
我希望能够查看工作状态，并在必要时在分析下降的测试期间或直到其他工作完成之前手动锁定支架。
为此，出现了更衣室服务。 它可以长期保持测试平台的状态（“忙” /“免费”），允许您指定“忙”的注释，因此很明显，我们现在正在调试，重新创建测试环境的副本或为下一个版本运行测试。 我们还开始在晚上封锁站点-管理员在这些站点上按计划执行工作，例如备份和数据库同步。
阻止时，总是设置锁定到期的时间-现在，人们无需参与将看台返回到可用池中的工作，并且机器可以执行所有操作。
值班
为了将负载平均分配给团队成员以分析测试结果，我们提出了每日轮班的计划。 服务员负责发布的验收测试，解析下降的自动测试并报告错误。 如果服务员了解自己无法应付任务流程，则可以向团队寻求帮助。 此时，团队的其他成员将从事与发布无关的任务。
随着发行数量的增加，出现了第二个服务员的角色，如果队列中有阻塞或关键发布，则第二个服务员将与主要角色联系。 为了提供有关测试发布进度的信息，我们创建了一个页面，其中包含处于“打开” /“运行” /“等待值班响应”状态，阻塞测试台的状态以及测试台上无法访问的组件的任务数：
值班人员的工作需要专心致志，因此他有一个面包。值班当天，他可以为整个团队在办公室附近的地方选择午餐的地方。 这种风格的值班贿赂看起来特别有趣：“让我帮您整理任务，今天我们要去
我最喜欢的地方” =）
记者
推出手表时，我们遇到的任务之一是需要将知识从一名军官转移到另一名军官，例如，有关在新版本上进行的测试或更新组件的细节的知识。
此外，我们还有新的工作功能。
- 由于测试台的问题，有一类测试以或多或少的频率下降。 由于其中一项服务的响应时间增加或浏览器中的资源加载时间过长，可能会发生崩溃。 我不想关闭测试；提高可靠性的合理手段已经用尽。
- 我们有另一个带有自动测试功能的实验项目，因此需要同时查看“魅力”报告来分析两个项目的运行情况。
- 测试运行最多可能需要20分钟，并且您想在开始第一个drop之后立即开始分析结果。 尤其是当任务很关键并且负责发布的团队成员站在您身后时
，用可怜的眼睛将刀握在喉咙上。
这就是Reporter服务产生的方式。 在其中，我们在测试过程中实时推送测试结果。 该服务具有链接到特定测试的已知问题或错误的数据库。 此外，该公司的Wiki门户网站上还发布了一份出版物，其中汇总了记者的跑步结果。 对于不想深入了解Reporter或Allure界面的技术细节的经理来说，这很方便。
如果测试失败，则可以在Reporter中查找相关错误或修复任务的列表。 这样的信息缩短了解析时间，并促进了我们团队成员之间有关问题的知识交换。 已完成任务的记录已存档，但如有必要，您可以将它们“窥视”到单独的列表中。 为了避免在工作时间内加载内部服务，我们在晚上采访了Jira，并存档了有关最终状态问题的条目。
引入Reporter的好处是运行数据库的出现，在此基础上，您可以分析跌倒的频率，并根据发现的错误数量，根据测试的稳定性或“有用性”对测试进行排名。
自动运行
接下来，当发布跟踪的发布接受测试问题时，我们继续自动化测试的启动。 为此，编写了自动运行服务，该服务检查Jira中是否有新的接受任务，如果有，则根据任务的内容确定组件的名称及其版本。
对于该任务，执行几个步骤：
- 在Locker服务中锁定其中一个免费测试台，
- 开始在詹金斯（Jenkins）中安装必要的组件，等待组件以所需的版本升起，
- 运行测试
- 等待测试运行完成，在执行过程中将所有结果推送到Reporter中，
- 我们要求Reporter提供失败的测试数量，但不包括由于已知问题而导致失败的测试，
- 如果0下降-我们将用于验收测试的任务转移到“完成”并完成处理。 一切准备就绪=）
- 如果有“红色”测试-我们将任务转换为“等待”，然后转到Reporter对其进行解析。
阶段之间的切换是通过有限状态机的原理来组织的。 每个阶段本身都知道过渡到下一个阶段的条件。 阶段的结果存储在任务上下文中，这对于一个任务的阶段是通用的。
所有这些使您可以沿着部署管道自动传输发行版，根据测试，100％的测试是绿色的。 但是，不稳定不是由组件问题引起的，而是由UI测试的“自然”功能或测试台中增加的网络延迟引起的？
为此，我们实现了重试机制，很多人都在使用该机制，但很少有人意识到这一点。 收件箱是在Jenkins管道中按顺序进行的测试组织的。
运行后，我们从Jenkins向Reporter请求失败测试的列表-并仅重新启动失败的测试。 此外，我们减少了启动时的线程数。 如果放弃的测试数量与前一次运行相比没有减少，我们将立即终止Job。 在我们的案例中，这种重新启动方法使我们将验收测试的成功率提高了大约2倍。
快速封锁
最终的验收测试系统使我们能够进行60％以上的发布，而无需人工干预。 但是剩下的怎么办？ 如有必要，服务员将针对被测组件或将测试修复至开发团队的任务创建错误报告。 有时-向操作部门绘制测试台配置的错误。
校正测试的任务通常会阻碍自动测试的正确通过，因为无关的测试将始终为“红色”。 开发团队的测试人员负责编写新测试并更新现有测试-通过对具有自动测试的项目的拉取请求进行更改。 这些编辑需要进行强制检查，这需要审阅者和作者花费一些时间，我想暂时阻止不相关的测试，直到任务转换为最终状态。
首先，我们基于测试方法的注释实现了关闭机制。 随后，事实证明，由于存在强制性代码审查，阻止代码并不总是很方便，并且可能花费比我们想要的更长的时间。
因此，我们将阻止测试的任务列表移至带有网页-快速阻止的新服务。 因此，负责该组件的团队成员可以快速阻止测试。 在运行之前，我们进入此服务并获得隔离测试的列表，我们将其转换为跳过状态。
总结
我们已经从手动模式下的发布发布接受到了几乎完全自动化的过程，该过程能够通过每天超过50个发布的接受测试来进行。 这有助于公司减少发布更改所需的时间，并且我们的团队可以找到用于试验和开发测试工具的资源。
将来，我们计划提高流程的可靠性，例如，通过在上面列表中的每个服务的一对实例之间分配请求。 这将使您无需停机即可更新工具，并且仅对部分验收测试包括新功能。 此外，我们注意稳定测试本身。 在开发中，用于重构测试的票证生成器具有最低的成功率。
提高测试的可靠性不仅会增加对它们的信心，而且由于缺少重启的失败脚本，因此还可以加快发布的测试速度。