主持人 > 博客 > 管理 > 负载测试作为开发人员的 CI 服务

负载测试作为开发人员的 CI 服务

负载测试作为开发人员的 CI 服务

多产品软件供应商经常面临的问题之一是几乎每个团队的工程师（开发人员、测试人员和基础设施管理员）的能力重复。 这也适用于昂贵的工程师——负载测试领域的专家。

工程师通常必须从头开始部署测试基础设施、配置负载工具并嵌入它们，而不是履行其直接职责并利用其独特的经验来构建负载测试流程、选择方法、最佳指标并根据负载配置文件编写自动测试自己在CI系统中设置监控并发布报告。

您可以找到我们在 Positive Technologies 中使用的测试中一些组织问题的解决方案 另一篇文章. 而在这一篇中，我将讨论使用“负载测试即服务”（load testing as a service）的概念将负载测试集成到通用 CI 管道中的可能性。 您将了解如何以及在 CI 管道中使用哪些加载源的 docker 镜像； 如何使用构建模板将加载源连接到 CI 项目； 用于运行负载测试和发布结果的演示管道是什么样的。 该文章可能对 CI 中正在考虑其负载系统架构的软件测试工程师和自动化工程师有用。

概念的本质

负载测试即服务的概念意味着能够将负载工具 Apache JMeter、Yandex.Tank 和您自己的框架集成到任意持续集成系统中。 该演示将针对 GitLab CI，但所有 CI 系统的原则都是通用的。

负载测试即服务是用于负载测试的集中式服务。 负载测试在专用代理池中运行，结果自动发布在 GitLab Pages、Influx DB 和 Grafana 或测试报告系统（TestRail、ReportPortal 等）中。 尽可能简单地实现自动化和缩放——通过在 GitLab CI 项目中添加和参数化常用的 gitlab-ci.yml 模板。

这种方式的好处是整个CI基础设施、负载代理、负载源的docker镜像、测试流水线、发布报告都由一个集中的自动化部门（DevOps工程师）维护，而负载测试工程师可以集中精力进行测试开发和分析他们的结果，而不处理基础设施问题。

为了描述简单，我们假设被测目标应用程序或服务器已经提前部署和配置（可以使用Python、SaltStack、Ansible等中的自动化脚本）。 那么负载测试即服务的整个概念分为三个阶段： 准备、测试、发布报告. 图表的更多细节（所有图片均可点击）：

负载测试作为开发人员的 CI 服务

负载测试中的基本概念和定义

在进行负载测试时，我们尽量遵守 ISTQB 标准和方法，使用适当的术语和推荐的指标。 我将简要列出负载测试中的主要概念和定义。

负载代理 - 将启动应用程序的虚拟机 - 加载源（Apache JMeter、Yandex.Tank 或自行编写的加载模块）。

测试目标（目标） - 服务器或安装在将承受负载的服务器上的应用程序。

测试场景（测试用例） - 一组参数化步骤：用户操作和对这些操作的预期反应，具有固定的网络请求和响应，具体取决于指定的参数。

配置文件或负载计划（配置文件） - 在 ISTQB 方法论 （第 4.2.4 节，第 43 页）负载配置文件定义了对特定测试至关重要的指标以及用于在测试期间更改负载参数的选项。 您可以在图中看到配置文件示例。

负载测试作为开发人员的 CI 服务

测试 — 具有一组预定参数的脚本。

测试计划（test-plan） - 一组测试和负载配置文件。

Testran（测试运行） - 使用完全执行的负载场景和收到的报告运行一项测试的一次迭代。

网络请求（request） — 从代理发送到目标的 HTTP 请求。

网络响应（response） — 从目标发送到代理的 HTTP 响应。
HTTP 响应代码（HTTP 响应状态）——来自应用服务器的标准响应代码。
事务是一个完整的请求-响应循环。 从开始发送请求（request）到接收到响应（response）完成，算一次事务。

交易状态 - 是否有可能成功完成请求-响应周期。 如果在这个循环中有任何错误，那么整个交易就被认为是不成功的。

响应时间（延迟） - 从发送请求（request）结束到开始接收响应（response）的时间。

负载指标 ——负载测试过程中确定的负载服务和负载代理的特性。

测量负载参数的基本指标

方法论中一些最常用和推荐的 质量认证委员会 （第 36、52 页）指标如下表所示。 代理和目标的类似指标列在同一行。

负载代理的指标
在负载下测试的目标系统或应用程序的指标

数量  虚拟CPU 和记忆 内存,
圆盘 - 负载代理的“铁”特性
中央处理器, 内存，磁盘使用 - CPU、内存和磁盘加载的动态
在测试的过程中。 通常以百分比来衡量
最大可用值

网络吞吐量 （加载代理）- 吞吐量
服务器上的网络接口，
安装负载代理的位置。
通常以每秒字节数 (bps) 为单位
网络吞吐量（目标）- 网络接口带宽
在目标服务器上。 通常以每秒字节数 (bps) 为单位

虚拟用户- 虚拟用户的数量，
实施负载场景和
模仿真实的用户操作
虚拟用户状态, Passed/Failed/Total — 成功和
虚拟用户的失败状态
对于负载场景，以及它们的总数。

通常期望所有用户都能完成
负载配置文件中指定的所有任务。
任何错误都意味着真正的用户将无法
解决您在使用系统时遇到的问题

每秒请求数（分钟）- 每秒（或分钟）的网络请求数。

负载代理的一个重要特征是它可以生成多少请求。
其实这是模拟虚拟用户访问应用程序
每秒响应（分钟）
- 每秒（或分钟）的网络响应数。

目标服务的一个重要特征：多少
生成并发送对查询的响应
装载剂

HTTP 响应状态— 不同响应代码的数量
负载代理从应用程序服务器接收到的信息。
比如200 OK表示调用成功，
和 404 - 未找到资源

潜伏 (响应时间) - 从结束开始的时间
在开始接收响应（response）之前发送一个请求（request）。
通常以毫秒 (ms) 为单位

交易响应时间— 一笔完整交易的时间，
完成请求-响应周期。
这是从发送请求（request）开始的时间
直到完成接收响应（response）。

交易时间可以用秒（或分钟）来衡量
在几个方面：考虑最小值，
最大值、平均值以及例如第 90 个百分位数。
最小和最大读数是极端的
系统性能状态。
第 XNUMX 个百分位数是最常用的，
正如大多数用户所显示的那样，
在系统性能的阈值下舒适地运行

每秒事务数（分钟） - 完成的数量
每秒交易数（分钟），
也就是说，应用程序能够接受多少以及
处理请求并发出响应。
其实这是系统的吞吐量

交易状态 , 通过/未通过/总数 - 数量
成功、不成功和交易总数。

对于真实用户不成功
交易实际上意味着
无法在负载下使用系统

负载测试示意图

负载测试的概念非常简单，由三个主要阶段组成，我已经提到过： 准备测试报告，即为负载源准备测试目标和设置参数，然后执行负载测试，最后生成并发布测试报告。

负载测试作为开发人员的 CI 服务

原理图注释：

  • QA.Tester 是负载测试方面的专家，
  • 目标是您想要了解其负载下行为的目标应用程序。

图中实体、阶段和步骤的分类器

阶段和步骤
会发生什么
入口处有什么
什么是输出

Prepare：测试准备阶段

加载参数
设置和初始化
按用户
加载参数，
指标的选择和
测试计划准备
（负载配置文件）
自定义选项
负载代理初始化
测试计划
测试目的

VM
云端部署
虚拟机与
要求的特征
负载代理的 VM 设置
自动化脚本
虚拟机创建
虚拟机配置于
云

环保
操作系统设置和准备
环境为
负载代理工作
环境设置
负载代理
自动化脚本
环境设置
准备好的环境：
操作系统、服务和应用程序，
工作所需
负载代理

负载代理
安装、配置和参数化
装载剂。
或者从下载 docker 镜像
预配置负载源
加载源 docker 镜像
（YAT、JM或自写框架）
设置
负载代理
设置并准备就绪
工作负载代理

测试：负载测试的执行阶段。 源是部署在 GitLab CI 专用代理池中的负载代理

加载
启动负载代理
与选定的测试计划
和加载参数
用户选项
用于初始化
负载代理
测试计划
测试目的
执行日志
负载测试
系统日志
目标指标和负载代理的变化动态

运行代理
代理执行
大量测试脚本
根据
负载曲线
加载代理交互
为了测试的目的
测试计划
测试目的

日志
收集“原始”日志
在负载测试期间：
负载代理活动记录，
测试目标的状态
和运行代理的虚拟机

执行日志
负载测试
系统日志

指标
在测试期间收集“原始”指标

目标指标变化的动态
和负载代理

Report：测试报告准备阶段

发生器
处理收集
加载系统和
监控系统“原始”
指标和日志
报告的形成
人类可读形式
可能与元素
分析师
执行日志
负载测试
系统日志
指标变化的动态
目标和加载代理
处理过的“原始”日志
以适合的格式
上传到外部存储
静态负载报告，
人类可读的

发布
报告的发表
关于负载
外部测试
服务
处理过的“原始”
以合适的格式记录
用于卸载到外部
储存库
保存在外部
存储报告
负载，适合
用于人体分析

在 CI 模板中连接加载源

让我们继续进行实际操作。 我想展示如何在公司的一些项目上 积极的技术 我们已经实现了负载测试即服务的概念。

首先，在我们的 DevOps 工程师的帮助下，我们在 GitLab CI 中创建了一个专用的代理池来运行负载测试。 为了不在模板中将它们与其他的混淆，例如程序集池，我们为这些代理添加了标签， 标签： 加载。 您可以使用任何其他可理解的标签。 他们问 注册时 GitLab CI 运行程序。

如何通过硬件找出所需的功率？ 负载代理的特性——足够数量的 vCPU、RAM 和磁盘——可以根据代理上运行的 Docker、Python（对于 Yandex.Tank）、GitLab CI 代理、Java（对于 Apache JMeter）来计算. 对于 JMeter 下的 Java，还建议使用至少 512 MB 的 RAM，作为​​上限， 80% 可用内存.

因此，根据我们的经验，我们建议为负载代理使用至少 4 个 vCPU、4 GB RAM、60 GB SSD。 网卡的吞吐量根据负载配置文件的要求确定。

我们主要使用两个负载源 - Apache JMeter 和 Yandex.Tank docker 镜像。

Yandex.坦克 是来自 Yandex 的用于负载测试的开源工具。 其模块化架构基于 Phantom 的高性能异步基于命中的 HTTP 请求生成器。 tank通过SSH协议内置了对被测服务器资源的监控，可以在指定条件下自动停止测试，可以在控制台和图形的形式显示结果，可以连接你的模块以扩展功能。 顺便说一下，我们在 Tank 还不是主流的时候使用它。 在文章“Yandex.Tank 和负载测试自动化» 您可以阅读我们在 2013 年如何使用它进行负载测试的故事 PT应用防火墙 是我们公司的产品之一。

Apache JMeter 是来自 Apache 的开源负载测试工具。 它同样可以很好地用于测试静态和动态 Web 应用程序。 JMeter 支持大量协议和与应用程序交互的方式：HTTP、HTTPS（Java、NodeJS、PHP、ASP.NET 等）、SOAP / REST Web 服务、FTP、TCP、LDAP、SMTP(S)、POP3( S) ) 和 IMAP(S)，通过 JDBC 的数据库，可以执行 shell 命令并使用 Java 对象。 JMeter 有一个用于创建、调试和执行测试计划的 IDE。 还有一个 CLI，用于在任何 Java 兼容操作系统（Linux、Windows、Mac OS X）上进行命令行操作。 该工具可以动态生成 HTML 测试报告。

为了在我们公司内部易于使用，为了测试人员自己更改和添加环境的能力，我们在 GitLab CI 上构建了负载源的 docker 图像，并发布到内部 Artifactory 的 docker 注册表。 这使得在管道中连接它们以进行负载测试变得更快、更容易。 如何通过 GitLab CI 将 docker 推送到注册表 - 请参阅 指示.

我们为 Yandex.Tank 使用了这个基本的 docker 文件：

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

对于 Apache JMeter 这个：

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

您可以在文章“中阅读我们的持续集成系统的工作原理”开发流程自动化：我们如何在 Positive Technologies 实施 DevOps 理念“。

模板和管道

项目中提供了用于进行负载测试的模板示例 演示加载。 在 自述文件 您可以阅读使用模板的说明。 在模板本身（文件 .gitlab-ci.yml) 有关于每个步骤负责什么的注释。

该模板非常简单，演示了上图中描述的负载测试的三个阶段：准备、测试和发布报告。 对此负责 实习: 准备、测试和报告.

  1. 阶段 Prepare 应该用于预配置测试目标或检查它们的可用性。 加载源的环境不需要配置，它们被预先构建为docker镜像并发布在docker registry中：只需在测试阶段指定所需的版本即可。 但是您可以重建它们并制作自己的修改图像。
  2. 阶段 测试 用于指定加载源、运行测试和存储测试工件。 您可以选择任何加载源：Yandex.Tank、Apache JMeter、您自己的或全部。 要禁用不必要的来源，只需注释掉或删除作业即可。 负载源的入口点：

    注意：程序集配置模板用于设置与 CI 系统的交互，并不意味着在其中放置测试逻辑。 对于测试，指定入口点，控制 bash 脚本所在的位置。 运行测试、生成报告和测试脚本本身的方法必须由 QA 工程师实施。 在演示中，对于两个加载源，Yandex 主页请求用作最简单的测试。 脚本和测试参数在目录中 ./测试.

  3. 在舞台上 报告进展 您需要描述如何将测试阶段获得的测试结果发布到外部存储，例如发布到GitLab Pages或特殊报告系统。 GitLab Pages 要求 ./public 目录非空，并且在测试完成后至少包含一个 index.html 文件。 您可以了解 GitLab Pages 服务的细微差别。 链接.

    如何导出数据的示例：

    发布设置说明：

在演示示例中，具有负载测试和两个负载源（您可以禁用不必要的）的管道如下所示：

负载测试作为开发人员的 CI 服务

Apache JMeter 本身可以生成 HTML 报告，因此使用标准工具将其保存在 GitLab Pages 中更有利可图。 这是 Apache JMeter 报告的样子：

负载测试作为开发人员的 CI 服务

在 Yandex.Tank 的演示示例中，您只会看到 假文字报告 在 GitLab Pages 部分。 在测试期间，Tank 可以将结果保存到 InfluxDB 数据库中，然后可以从那里显示结果，例如在 Grafana 中（配置在文件中完成 ./tests/example-yandextank-test.yml). 这就是 Tank 的报告在 Grafana 中的样子：

负载测试作为开发人员的 CI 服务

总结

在文章中，我谈到了“负载测试即服务”（load testing as a service）的概念。 主要思想是使用预先配置的负载代理池、负载源的 docker 图像、报告系统和基于简单的 .gitlab-ci.yml 模板（示例 链接). 所有这些都由一小群自动化工程师支持，并应产品团队的要求进行复制。 我希望这将有助于您在贵公司准备和实施类似的计划。 感谢您的关注！

PS 我想对我的同事 Sergey Kurbanov 和 Nikolai Yusev 表示衷心的感谢，他们为我们公司实施负载测试即服务的概念提供了技术援助。

作者: 蒂姆·吉尔穆林 - 副手Positive Technologies 技术和开发流程 (DevOps) 主管

来源： habr.com

添加评论