Um dos problemas que os fornecedores de software de vários produtos costumam encontrar é a duplicação de competências de engenheiros - desenvolvedores, testadores e administradores de infraestrutura - em quase todas as equipes. Isso também se aplica a engenheiros caros - especialistas na área de testes de carga.Em vez de se envolver em suas responsabilidades diretas e usar sua experiência única para criar o processo de teste de carga, escolhendo uma metodologia, métricas ideais e autoteste de gravação de acordo com perfis de carga, os engenheiros geralmente precisam implantar a infraestrutura de teste do zero, configurar ferramentas de carga e incorporá-las nos sistemas de CI, configure o monitoramento e a publicação de relatórios.Você pode encontrar soluções para alguns problemas organizacionais nos testes que usamos na Positive Technologies em outro artigo . E aqui falarei sobre a possibilidade de integrar testes de carga em um pipeline de IC comum usando o conceito de "teste de carga como serviço". Você aprenderá como e quais imagens da janela de encaixe das fontes de carregamento podem ser usadas no pipeline do IC; Como conectar fontes de carregamento ao seu projeto de IC usando um modelo de montagem; como é um pipe de demonstração para executar testes de carga e publicar resultados. Este artigo pode ser útil para engenheiros de teste de software e engenheiros de automação da CI, que pensaram na arquitetura de seu sistema de carga.Essência do conceito
O conceito de teste de carga como serviço implica a capacidade de integrar as ferramentas de carregamento Apache JMeter, Yandex.Tank e estruturas próprias em um sistema arbitrário de integração contínua. Uma demonstração será para o GitLab CI, mas os princípios são declarados comuns a todos os sistemas de CI.O teste de carga como serviço é um serviço centralizado para a realização de testes de carga. Os testes de carga são executados em conjuntos de agentes dedicados, os resultados são publicados automaticamente no GitLab Pages, Influx DB e Grafana ou em sistemas de relatório de teste (TestRail, ReportPortal, etc.). A automação e o dimensionamento são realizados da maneira mais simples possível - adicionando e parametrizando o modelo gitlab-ci.yml usual no projeto GitLab CI.A vantagem da abordagem é que toda a infraestrutura de CI, agentes de carga, imagens de encaixe de fontes de carga, pipelines de teste e publicação de relatórios são suportadas pelo departamento central de automação (engenheiros do DevOps) e os engenheiros de teste de carga podem concentrar seus esforços no desenvolvimento de testes e análise de seus resultados, sem lidar com questões de infraestrutura.Para simplificar a descrição, supomos que o aplicativo ou servidor de teste de destino já esteja implantado e configurado com antecedência (para isso, scripts automatizados em Python, SaltStack, Ansible etc. podem ser usados). Então, todo o conceito de teste de estresse como serviço se encaixa em três estágios: preparação, teste, publicação de relatórios . Mais detalhes no diagrama (todas as imagens são clicáveis):
Ao realizar testes de estresse, tentamos aderir aos padrões e metodologia do ISTQB , usamos a terminologia apropriada e as métricas recomendadas. Vou dar uma pequena lista de conceitos e definições básicas no teste de carga.O agente de carregamento (agente de carregamento) - a máquina virtual na qual o aplicativo será iniciado - a origem do carregamento (Apache JMeter, Yandex.Tank ou módulo de carregamento auto-gravado).O objetivo do teste (destino) é um servidor ou aplicativo instalado no servidor que será submetido ao carregamento.Um caso de teste é um conjunto de etapas parametrizadas: ações do usuário e reações esperadas a essas ações, com solicitações e respostas de rede fixas, dependendo dos parâmetros especificados.Perfil ou plano de carga (perfil) - na metodologia ISTQB (Seção 4.2.4, p. 43), os perfis de carga determinam as métricas críticas para um teste específico e as opções para alterar os parâmetros de carga durante o teste. Você pode ver exemplos de perfis na figura. Teste é um script com um conjunto predefinido de parâmetros. Plano de teste - suíte de testes e perfil de carga. Testrun (testrun) - uma iteração da execução de um teste com um cenário de carga totalmente executado e um relatório recebido. Solicitação de rede (solicitação) - uma solicitação HTTP enviada do agente para o destino. Resposta da rede (resposta) - uma resposta HTTP enviada do destino para o agente.
O status da resposta HTTP é um código de resposta padrão do servidor de aplicativos.Transação (transação) - um ciclo completo de "solicitação - resposta". Uma transação é contada desde o início do envio de uma solicitação (solicitação) até a conclusão do recebimento de uma resposta (resposta).Status da transação (status das transações) - se o ciclo "solicitação - resposta" foi concluído com êxito. Se houver algum erro nesse loop, a transação inteira será considerada malsucedida.Tempo de resposta (latência) - tempo desde o final do envio de uma solicitação (solicitação) até o início do recebimento de uma resposta (resposta).Métricas de carregamento (métricas) - as características do serviço carregado e do agente de carregamento definidas durante o processo de teste de carga.Métricas básicas para medir parâmetros de carga
Algumas das métricas mais comuns e recomendadas na metodologia ISTQB (p. 36, 52) são mostradas na tabela abaixo. Métricas semelhantes para o agente e o destino são mostradas na mesma linha.O esquema básico de teste de carga é muito simples e consiste em três estágios principais, que eu já mencionei: Preparar - Teste - Relatório , ou seja, preparar metas de teste e definir parâmetros para fontes de carga, depois executar testes de carga e, finalmente, gerar e publicar um relatório sobre o teste. Notas para o regime:
- QA.Tester - especialista em testes de estresse,
- Target é o aplicativo de destino para o qual você precisa conhecer seu comportamento sob carga.
Classificador de entidades, estágios e etapas no diagrama
CI-
Vamos para a parte prática. Quero mostrar como, em alguns projetos da Positive Technologies , implementamos o conceito de teste de estresse como serviço.Primeiro, com a ajuda de nossos engenheiros de DevOps, criamos um pool de agentes dedicado no GitLab CI para executar testes de carga. Para não confundi-los em modelos com outros, como conjuntos de montagens, adicionamos tags a esses agentes, tags : load. Você pode usar outras tags claras. Eles são definidos durante o registro dos GitLab CI Runners.Como descobrir a energia necessária por hardware? As características dos agentes de carregamento - uma quantidade suficiente de vCPU, RAM e disco - podem ser calculadas com base em que Docker, Python (para Yandex.Tank), agente de GitLab CI, Java (para Apache JMeter) devem estar em execução no agente. Para Java no JMeter, também é recomendável usar no mínimo 512 MB de RAM e, como limite superior, 80% da memória disponível .Portanto, com base em nossa experiência, recomendamos o uso de pelo menos 4 vCPU, 4 GB de RAM, 60 GB SSD para agentes de carregamento. A largura de banda da placa de rede é determinada com base nos requisitos do perfil de carga.Usamos principalmente duas fontes de carregamento - imagens do docker Apache JMeter e Yandex.Tank.Yandex.Tank- Esta é a ferramenta de código aberto do Yandex para testes de estresse. Sua arquitetura modular é baseada no gerador de solicitações HTTP assíncronas de alto desempenho Phantom. O tanque possui monitoramento interno dos recursos do servidor testado usando o protocolo SSH, pode interromper o teste automaticamente de acordo com as condições especificadas, pode exibir os resultados no console e na forma de gráficos, você pode conectar seus módulos a ele para expandir a funcionalidade. A propósito, usamos o Tank quando ele ainda não era popular. No artigo “ Yandex.Tank e automação de testes de carga ”, você pode ler a história de como, em 2013, a usamos para realizar testes de carga do PT Appllication Firewall - um dos produtos de nossa empresa.Apache JMeterÉ uma ferramenta de código aberto para realizar testes de estresse do Apache. Ele pode ser usado igualmente bem para testar aplicativos da Web estáticos e dinâmicos. O JMeter suporta um grande número de protocolos e maneiras de interagir com aplicativos: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET etc.), serviços da Web SOAP / REST, FTP, TCP, LDAP, SMTP (S), POP3 (S ) e IMAP (S), bancos de dados por meio do JDBC, podem executar comandos do shell e trabalhar com objetos Java. O JMeter possui um IDE para criar, depurar e executar planos de teste. Há também uma CLI para trabalhar na linha de comando de qualquer Java OS compatível (Linux, Windows, Mac OS X). A ferramenta pode gerar dinamicamente um relatório de teste HTML.Para facilitar o uso em nossa empresa, para a capacidade dos testadores de alterar e adicionar o ambiente, criamos imagens de docker de fontes de carga no GitLab CI com publicação no docker-register interno no Artifactory . Dessa forma, fica mais rápido e fácil conectá-los em tubulações para testes de carga. Como fazer o docker enviar o registro via GitLab CI - consulte as instruções .O arquivo docker básico para o Yandex.Tank foi o que fizemos:Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]
E para o Apache JMeter, este:Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]
Você pode ler como nosso sistema de integração contínua funciona no artigo “ Automação de processos de desenvolvimento: como implementamos as idéias de DevOps em tecnologias positivas ”.Modelo e pipeline
Um modelo de exemplo para a realização de testes de carga está disponível no projeto demo-load . Você pode ler as instruções para usar o modelo no arquivo leia - me . No próprio modelo (o arquivo .gitlab-ci.yml ), há observações sobre o que é responsável por esta ou aquela etapa.O modelo é muito simples e demonstra os três estágios do teste de carga descritos acima no diagrama: preparação, teste e publicação de relatórios. Responsável pelo diretório de estágios : o Preparar, o Teste e o Relatório .- Prepare . , - docker registry: Test. .
- Test , . : Yandex.Tank, Apache JMeter, . job-. :
: CI- . , bash-. , — QA-. . ./tests.
- Report , Test, , GitLab Pages . GitLab Pages , ./public index.html. GitLab Pages .
, :
:
Em um exemplo de demonstração, um pipeline com testes de carga e duas fontes de carga (você pode desativar desnecessariamente) é semelhante a: O Apache JMeter pode gerar um relatório em HTML, por isso é mais rentável salvá-lo nas páginas do GitLab usando ferramentas regulares. É assim que o relatório do Apache JMeter se parece: Na demonstração do Yandex.Tank, você verá apenas um relatório de texto falso na seção Páginas do GitLab. Durante o teste, o Tank pode salvar os resultados no banco de dados do InfluxDB e, a partir daí, eles podem ser exibidos no Grafana (a configuração é realizada no arquivo ./tests/example-yandextank-test.yml ). É assim que o relatório de Tank se parece no Grafana:
Sumário
No artigo, falei sobre o conceito de "teste de carga como serviço" (teste de carga como serviço). A idéia principal é usar a infraestrutura de pools pré-configurados de agentes de carregamento, imagens de encaixe de fontes de carregamento, sistemas de relatórios e um pipeline que os une no GitLab CI com base em um modelo simples .gitlab-ci.yml (exemplo por referência ). Tudo isso é suportado por uma pequena equipe de engenheiros de automação e é replicado a pedido das equipes de produto. Espero que isso ajude você a preparar e implementar um esquema semelhante em sua empresa. Obrigado pela atenção!PS: Gostaria de agradecer muito aos meus colegas Sergey Kurbanov e Nikolay Yusev, pela assistência técnica na implementação do conceito de teste de carga como serviço em nossa empresa.Autor :Timur Gilmullin - deputado. Chefe de Tecnologia e Processos de Desenvolvimento (DevOps), Positive Technologies