将开发人员作为CI服务进行负载测试



多产品软件供应商经常遇到的问题之一是几乎每个团队中工程师(开发人员,测试人员和基础架构管理员)的能力重复。这也适用于昂贵的工程师-负载测试领域的专家。

工程师们不必承担直接的责任并利用他们独特的经验来构建负载测试过程,选择一种方法,最佳度量并根据负载配置文件编写自测,工程师通常不得不从头开始部署测试基础架构,配置负载工具并将其嵌入在CI系统中,配置监视和报告发布。

另一篇文章中,您可以找到我们在Positive Technologies使用的测试中一些组织问题的解决方案在此,我将讨论使用“负载测试即服务”的概念将负载测试集成到通用CI管道中的可能性。您将学习如何在CI管道中使用负载源的docker镜像以及如何使用它们。如何使用装配模板将负载源连接到CI项目;演示管道运行负载测试并发布结果的外观。本文对于考虑过其负载系统的体系结构的CI的软件测试工程师和自动化工程师可能有用。

概念的本质


负载测试即服务的概念意味着可以将Apache JMeter,Yandex.Tank负载工具和自己的框架集成到任意连续集成系统中。演示将针对GitLab CI,但陈述了所有CI系统共有的原理。

负载测试即服务是用于进行负载测试的集中服务。负载测试在专用的代理程序池中运行,结果将自动发布在GitLab Pages,Influx DB和Grafana或测试报告系统(TestRail,ReportPortal等)中。通过在GitLab CI项目中添加和参数化通常的gitlab-ci.yml模板,可以尽可能简单地实现自动化和扩展。

该方法的优势在于,整个自动化基础架构,负载代理,负载源的docker映像,测试管道和报告的发布均由中央自动化部门(DevOps工程师)支持,并且负载测试工程师可以将精力集中在测试开发上分析其结果,而无需处理基础架构问题。

为了简化描述,我们假设目标测试应用程序或服务器已经预先部署和配置(为此,可以使用Python,SaltStack,Ansible等中的自动化脚本)。然后,压力测试即服务的整个概念分为三个阶段:准备,测试,报告的发布。图上的更多详细信息(所有图片均可单击):




在进行压力测试时,我们尝试遵守ISTQB标准和方法,使用适当的术语和推荐的度量标准。我将简要列出负载测试中的基本概念和定义。

加载代理(加载代理) -将在其上启动应用程序的虚拟机-加载源(Apache JMeter,Yandex.Tank或自写加载模块)。

测试的目的(目标)是要承受负载的服务器或服务器上安装的应用程序。

测试用例(测试用例) -一组参数化步骤:用户操作和对这些操作的预期反应,并根据指定的参数具有固定的网络请求和响应。

配置文件或负载计划(配置文件) -在ISTQB方法 4.2.4 ,第43页)中,负载配置文件确定了对特定测试至关重要的度量标准以及在测试期间更改负载参数的选项。您可以在图中看到概要文件的示例。测试是具有一组预定义参数的脚本。测试计划 -测试套件和负载配置文件。Testrun(testrun) -使用完全执行的加载方案和收到的报告运行一个测试的一次迭代。网络请求(请求) -从代理发送到目标的HTTP请求。网络响应(响应) -从目标发送到代理的HTTP响应。












HTTP响应状态是来自应用程序服务器的标准响应代码。
事务(事务)-“请求-响应”的整个周期。从开始发送请求(请求)到完成接收响应(响应)的过程中对事务进行计数。

交易状态(交易状态) -是否可以成功完成周期“请求-响应”。如果此循环中有任何错误,则认为整个事务均未成功。

响应时间(延迟) -从发送请求(请求)结束到开始接收响应(响应)的时间。

负载量度(度量标准) -负载测试过程中定义的负载服务和负载代理的特征。

测量负载参数的基本指标


表显示ISTQB方法中一些最常用和推荐的指标(第36、52页)。代理和目标的相似指标显示在同一行上。

负载代理指标在负载下测试的目标系统或应用程序的指标
vCPURAM内存的数量  
磁盘 -“铁”负载代理的特征
CPU内存,磁盘使用情况 -
测试期间加载处理器,内存和磁盘的动态通常以
最大可用值的百分比来衡量
Network throughput (on load agent) —
,
.
(bps)
Network throughput(on target) —
. (bps)
Virtual users— ,

Virtual users status, Passed/Failed/Total —

, .

,
, .
,
Requests per second (minute)— ( ).

: .
Responses per second (minute)
— ( ).

:

HTTP responses status
, .
, 200 OK ,
404 —
Latency ( ) —
(request) (response).
(ms)
Transaction response time— ,
« — ».
(request)
(response).

( )
: ,
, , , 90- .

.
,
,
Transactions per second (minute)
(),

.
Transactions status , Passed / Failed / Total —
, .





负载测试的基本方案非常简单,包括三个主要阶段,我已经提到了它们:Prepare-Test-Report,即准备测试目标并为负载源设置参数,然后执行负载测试,最后生成并发布报告关于测试。 该计划的注意事项:





  • QA.Tester-压力测试专家,
  • 目标是您需要了解其负载情况下的行为的目标应用程序。

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


阶段和步骤发生了什么入口处是什么输出是什么
准备:测试准备阶段
负载参数设置和初始化
用户
负载参数,
选择指标并
准备测试计划
(负载配置文件)


-
VM




Env




:
, ,

LoadAgents,
.
-
-
(, JM )



Test: . , GitLab CI
Load
-



-



RunAgents




-
Logs«»
:
,

,


Metrics«»
Report:
Generator

«»


,





«»
,

,
Publish


«»
,



,

CI-


让我们继续实践部分。我想展示在Positive Technologies的某些项目中我们如何实现负载测试即服务的概念。

首先,在DevOps工程师的帮助下,我们在GitLab CI中创建了一个专用的代理程序池来运行负载测试。为了不使它们在模板中与其他组件(如程序集池)混淆,我们向这些代理添加了标签tag:load。您可以使用任何其他清除标签。它们是 GitLab CI Runners 注册期间设置

如何通过硬件找出所需的功率?可以基于必须在该代理程序上运行Docker,Python(对于Yandex.Tank),GitLab CI代理程序,Java(对于Apache JMeter)的负载代理程序的特性-足够数量的vCPU,RAM和磁盘-进行计算。对于Java,JMeter还建议使用至少512 MB的RAM和80%的可用内存作为上限

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

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

Yandex.Tank-这是Yandex进行压力测试的开源工具。它的模块化体系结构基于高性能的基于异步命中的HTTP请求生成器Phantom。储罐使用SSH协议对受测服务器的资源进行内置监控,可以根据给定条件自动停止测试,可以将结果输出到控制台并以图形形式输出,您可以将模块连接到它以扩展功能。顺便说一下,我们在尚未成为主流的时候使用了Tank。在“ Yandex.Tank和负载测试自动化 ”一文中,您可以阅读有关如何在2013年使用它对公司产品之一PT Appllication Firewall进行负载测试的故事

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 OS(Linux,Windows,Mac OS X)的命令行上工作。该工具可以动态生成HTML测试报告。

为了便于在公司内部使用,为了使测试人员能够更改和添加环境,我们在GitLab CI上制作了负载源的docker映像,并在Artifactory的内部docker-register中进行了发布这样可以更快,更轻松地将它们连接到管道中以进行负载测试。如何通过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想法”中阅读我们的持续集成系统的工作原理

模板和管道


demo-load 项目中提供了用于进行负载测试的示例模板。您可以自述文件中阅读有关使用模板的说明。在模板本身(.gitlab-ci.yml文件)中,有关于此步骤或该步骤负责的内容的注释。

该模板非常简单,并在图中说明了上述负载测试的三个阶段:准备,测试和发布报告。负责它的Stage目录Prepare,Test和Report

  1. Prepare . , - docker registry: Test. .
  2. Test , . : Yandex.Tank, Apache JMeter, . job-. :

    : CI- . , bash-. , — QA-. . ./tests.
  3. Report , Test, , GitLab Pages . GitLab Pages , ./public index.html. GitLab Pages .

    , :
    :

在一个演示示例中,具有负载测试和两个负载源(您可以禁用不必要的负载)的管道如下所示: Apache JMeter本身可以生成HTML报告,因此使用常规工具将其保存在GitLab Pages中更有利可图。这是Apache JMeter报告的样子: 在Yandex.Tank的演示中,您将在GitLab Pages部分中仅看到假文本报告在测试过程中,Tank可以将结果保存到InfluxDB数据库中,然后可以在其中显示结果,例如,在Grafana中显示(配置在文件./tests/example-yandextank-test.yml中进行)。这是Tank的报告在Grafana中的样子:











摘要


在本文中,我讨论了“负载测试即服务”(负载测试即服务)的概念。主要思想是使用预配置的负载代理池,负载源的docker映像,报告系统以及基于简单的.gitlab-ci.yml模板在GitLab CI中将它们组合在一起的管道的基础架构(请参考示例)。所有这一切都由一小组自动化工程师提供支持,并应产品团队的要求进行复制。我希望这可以帮助您在公司中准备和实施类似的计划。感谢您的关注!

PS:我要对我的同事Sergey Kurbanov和Nikolay Yusev表示非常感谢,他们为在我们公司中实现负载测试即服务的概念提供了技术帮助。

作者Timur Gilmullin-副主席。积极技术技术与开发流程(DevOps)负责人

All Articles