Um dos problemas que os fornecedores de software de vários produtos geralmente enfrentam é a duplicação das competências dos engenheiros - desenvolvedores, testadores e administradores de infraestrutura - em quase todas as equipes. Isso também se aplica a engenheiros caros - especialistas na área de teste de carga.
Em vez de cumprir suas funções diretas e usar sua experiência única para criar um processo de teste de carga, escolher uma metodologia, métricas ideais e escrever autotestes de acordo com perfis de carga, os engenheiros geralmente precisam implantar uma infraestrutura de teste do zero, configurar ferramentas de carga e incorporá-las se inserem em sistemas de IC, estabelecem monitoramento e publicação de relatórios.
Você pode encontrar soluções para alguns problemas organizacionais nos testes que utilizamos na Positive Technologies em . E neste, falarei sobre a possibilidade de integrar testes de carga em um pipeline de CI comum usando o conceito de “testes de carga como serviço” (load testing as a service). Você aprenderá como e quais imagens docker de origens de carga podem ser usadas no pipeline de CI; como conectar origens de carga ao seu projeto de CI usando um modelo de construção; a aparência do pipeline de demonstração para executar testes de carga e publicar os resultados. O artigo pode ser útil para engenheiros de teste de software e engenheiros de automação em CI que estão pensando na arquitetura de seu sistema de carga.
A essência do conceito
O conceito de teste de carga como um serviço implica a capacidade de integrar as ferramentas de carga Apache JMeter, Yandex.Tank e suas próprias estruturas em um sistema de integração contínua arbitrária. A demonstração será para o GitLab CI, mas os princípios são comuns a todos os sistemas de CI.
O teste de carga como serviço é um serviço centralizado para teste de carga. Os testes de carga são executados em pools de agentes dedicados, os resultados são publicados automaticamente no GitLab Pages, Influx DB e Grafana ou em sistemas de relatórios de teste (TestRail, ReportPortal, etc.). A automação e o dimensionamento são implementados da maneira mais simples possível - adicionando e parametrizando o modelo usual gitlab-ci.yml no projeto GitLab CI.
A vantagem dessa abordagem é que toda a infraestrutura de CI, agentes de carga, imagens docker de fontes de carga, pipelines de teste e relatórios de publicação são mantidos por um departamento de automação centralizado (engenheiros de DevOps), enquanto 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, assumiremos que o aplicativo ou servidor de destino em teste já foi implantado e configurado com antecedência (scripts automatizados em Python, SaltStack, Ansible, etc. podem ser usados para isso). Então, todo o conceito de teste de carga como um serviço se encaixa em três estágios: preparação, testes, publicação de relatórios. Mais detalhes no diagrama (todas as imagens são clicáveis):
Conceitos básicos e definições em testes de carga
Ao realizar testes de carga, tentamos aderir a , use a terminologia apropriada e as métricas recomendadas. Vou dar uma pequena lista dos principais conceitos e definições em testes de carga.
Agente de carga - uma máquina virtual na qual o aplicativo será iniciado - a fonte de carregamento (Apache JMeter, Yandex.Tank ou um módulo de carregamento autoescrito).
Objetivo do teste (alvo) - servidor ou aplicativo instalado no servidor que estará sujeito à carga.
Cenário de teste (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) - em (Seção 4.2.4, p. 43) os perfis de carga definem métricas que são críticas para um determinado teste e 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 predeterminado de parâmetros.
Plano de teste (plano de teste) - um conjunto de testes e um perfil de carga.
Testran (testrun) - uma iteração de execução de um teste com um cenário de carga totalmente executado e o relatório recebido.
Solicitação de rede (solicitação) — Uma solicitação HTTP enviada de um agente para um destino.
Resposta da rede (resposta) — Uma resposta HTTP enviada do alvo para o agente.
Código de resposta HTTP (status de respostas HTTP) - código de resposta padrão do servidor de aplicativos.
Uma 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 - se foi possível concluir com sucesso o ciclo solicitação-resposta. Se houve algum erro neste ciclo, toda a transação é considerada malsucedida.
Tempo de resposta (latência) - o tempo desde o final do envio de uma solicitação (pedido) até o início do recebimento de uma resposta (resposta).
Carregar métricas — as características do serviço carregado e do agente de carga determinadas no processo de teste de carga.
Métricas básicas para medir parâmetros de carga
Algumas das mais utilizadas e recomendadas na metodologia (p. 36, 52) as métricas são mostradas na tabela abaixo. Métricas semelhantes para agente e destino são listadas na mesma linha.
Métricas para o agente de carregamento
Métricas do sistema de destino ou aplicativo sendo testado sob carga
Número vCPU e memória RAM,
Disco - características "ferro" do agente de carga
CPU, Memória, uso de disco - dinâmica de carregamento de CPU, memória e disco
no processo de teste. Geralmente medido como uma porcentagem de
valores máximos disponíveis
Taxa de transferência da rede (no agente de carga) - taxa de transferência
interface de rede no servidor,
onde o agente de carregamento está instalado.
Geralmente medido em bytes por segundo (bps)
Taxa de transferência da rede(no alvo) - largura de banda da interface de rede
no servidor de destino. Geralmente medido em bytes por segundo (bps)
Usuários virtuais- o número de usuários virtuais,
implementando cenários de carga e
imitando ações reais do usuário
status de usuários virtuais, Aprovado/Reprovado/Total — número de sucessos e
status malsucedidos de usuários virtuais
para cenários de carga, bem como seu número total.
Geralmente, espera-se que todos os usuários sejam capazes de concluir
todas as suas tarefas especificadas no perfil de carga.
Qualquer erro significará que um usuário real não será capaz de
resolva seu problema ao trabalhar com o sistema
Solicitações por segundo (minuto)- o número de solicitações de rede por segundo (ou minuto).
Uma característica importante de um agente de carga é quantas requisições ele pode gerar.
Na verdade, trata-se de uma imitação de acesso ao aplicativo por usuários virtuais
Respostas por segundo (minuto)
- o número de respostas de rede por segundo (ou minuto).
Uma característica importante do serviço-alvo: quanto
gerar e enviar respostas a consultas com
agente de carregamento
status da resposta HTTP— número de códigos de resposta diferentes
do servidor de aplicativos recebido pelo agente de carregamento.
Por exemplo, 200 OK significa uma chamada bem-sucedida,
e 404 - que o recurso não foi encontrado
Latência (tempo de resposta) - tempo desde o fim
enviar uma solicitação (request) antes de começar a receber uma resposta (response).
Geralmente medido em milissegundos (ms)
Tempo de resposta da transação— tempo de uma transação completa,
conclusão do ciclo solicitação-resposta.
Este é o tempo desde o início do envio da solicitação (solicitação)
até a conclusão de receber uma resposta (resposta).
O tempo de transação pode ser medido em segundos (ou minutos)
de várias maneiras: considere o mínimo,
máximo, médio e, por exemplo, o percentil 90.
As leituras mínima e máxima são extremas
estado de desempenho do sistema.
O nonagésimo percentil é o mais comumente usado,
como mostra a maioria dos usuários,
operando confortavelmente no limite do desempenho do sistema
Transações por segundo (minuto) - o número de completos
transações por segundo (minuto),
ou seja, quanto o aplicativo foi capaz de aceitar e
processar solicitações e emitir respostas.
Na verdade, este é o rendimento do sistema
Status da transação , Aprovado / Reprovado / Total - número
bem-sucedido, malsucedido e o número total de transações.
Para usuários reais sem sucesso
a transação realmente significará
incapacidade de trabalhar com o sistema sob carga
Diagrama Esquemático de Teste de Carga
O conceito de teste de carga é muito simples e consiste em três etapas principais, que 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, ao final, gerar e publicar um relatório de teste.
Notas esquemáticas:
- QA.Tester é especialista em testes de carga,
- Target é o aplicativo de destino para o qual você deseja saber seu comportamento sob carga.
Classificador de entidades, estágios e etapas no diagrama
Fases e etapas
O que acontece
o que tem na entrada
Qual é a saída
Preparar: estágio de preparação para testes
Carregar Parâmetros
Configuração e inicialização
do utilizador
Parâmetros de carga,
escolha de métricas e
preparação do plano de teste
(carregar perfil)
Opções personalizadas para
carregar inicialização do agente
Plano de teste
Finalidade do teste
VM
implantação na nuvem
máquina virtual com
características exigidas
Configurações de VM para agente de carga
Scripts de automação para
Criação de VM
VM configurada em
nuvem
Env
Configuração e preparação do sistema operacional
ambiente para
trabalho do agente de carga
Configurações de ambiente para
agente de carga
Scripts de automação para
configurações do ambiente
Ambiente preparado:
SO, serviços e aplicativos,
necessário para o trabalho
agente de carga
Agentes de carga
Instalação, configuração e parametrização
agente de carga.
Ou baixando uma imagem docker de
fonte de carga pré-configurada
Carregar imagem do docker de origem
(YAT, JM ou framework auto-escrito)
Definições
agente de carga
Configure e pronto
agente de carga de trabalho
Teste: etapa de execução dos testes de carga. As fontes são agentes de carga implantados em pools de agentes dedicados para o GitLab CI
Ver
Iniciando o Agente de Carregamento
com plano de teste selecionado
e carregar parâmetros
Opções do usuário
para inicialização
agente de carga
Plano de teste
Finalidade do teste
Registros de execução
testes de carga
Registros do sistema
Dinâmica de mudanças nas métricas de meta e agente de carga
Executar Agentes
Execução do agente
muitos scripts de teste
de acordo com
carregar perfil
Carregar Interação do Agente
para fins de teste
Plano de teste
Finalidade do teste
Logs
Coleção de logs "brutos"
durante o teste de carga:
carregar registros de atividade do agente,
estado do alvo de teste
e a VM executando o agente
Registros de execução
testes de carga
Registros do sistema
Métrica
Coletando métricas "brutas" durante o teste
Dinâmica de mudanças nas métricas de meta
e agente de carga
Relatório: etapa de preparação do relatório de teste
Gerador
Processamento coletado
sistema de carregamento e
sistema de monitoramento "cru"
métricas e registros
Formação de um relatório em
forma legível por humanos
possível com elementos
Analistas
Registros de execução
testes de carga
Registros do sistema
Dinâmica de mudanças nas métricas
alvo e agente de carga
Logs "brutos" processados
em formato adequado para
uploads para armazenamento externo
Relatório de carga estática,
legível por humanos
Publique
Publicação do relatório
sobre carga
testando em externo
serviço
Processado "cru"
registros em um formato adequado
para descarregar para o exterior
repositórios
Salvo em externo
relatórios de armazenamento em
carga, adequado
para análise humana
Conectando origens de carga no modelo de CI
Vamos para a parte prática. Quero mostrar como em alguns projetos da empresa implementamos o conceito de teste de carga como um serviço.
Primeiro, com a ajuda de nossos engenheiros de DevOps, criamos um pool dedicado de agentes no GitLab CI para executar testes de carga. Para não confundi-los em templates com outros, como pools de montagem, adicionamos tags a esses agentes, : carregar. Você pode usar quaisquer outras tags compreensíveis. Eles perguntaram Corredores de CI do GitLab.
Como descobrir a potência necessária por hardware? As características dos agentes de carga - um número suficiente de vCPU, RAM e disco - podem ser calculadas com base no fato de que Docker, Python (para Yandex.Tank), agente GitLab CI, Java (para Apache JMeter) devem estar em execução no agente . Para Java sob JMeter, também é recomendável usar no mínimo 512 MB de RAM e, como limite máximo, .
Assim, com base em nossa experiência, recomendamos o uso de pelo menos 4 vCPUs, 4 GB de RAM, 60 GB de SSD para agentes de carga. A taxa de transferência 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.
é uma ferramenta de código aberto da Yandex para teste de carga. Sua arquitetura modular é baseada no gerador de solicitação HTTP baseado em hit assíncrono de alto desempenho do Phantom. O tanque possui um monitoramento integrado dos recursos do servidor em teste através do protocolo SSH, pode parar automaticamente o teste sob 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 ainda não era popular. No artigo "» você pode ler a história de como realizamos testes de carga com ele em 2013 é um dos produtos da nossa empresa.
é uma ferramenta de teste de carga de código aberto da Apache. Ele pode ser usado igualmente bem para testar aplicativos da Web estáticos e dinâmicos. JMeter suporta um grande número de protocolos e formas de interagir com aplicações: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) e IMAP(S), bancos de dados via JDBC, podem executar comandos 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 operação de linha de comando em qualquer sistema operacional compatível com Java (Linux, Windows, Mac OS X). A ferramenta pode gerar dinamicamente um relatório de teste HTML.
Para facilitar o uso dentro de nossa empresa, para a capacidade dos próprios testadores de alterar e adicionar o ambiente, fizemos builds de imagens docker de fontes de carga no GitLab CI com publicação no interno . Isso torna mais rápido e fácil conectá-los em pipelines para testes de carga. Como fazer docker push para o registro via GitLab CI - veja .
Pegamos este arquivo docker básico para Yandex.Tank:
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 funciona nosso sistema de integração contínua no artigo "".
Modelo e pipeline
Um exemplo de modelo para realização de testes de carga está disponível no projeto . Em Você pode ler as instruções para usar o modelo. No próprio template (arquivo ) há notas sobre o que cada etapa é responsável.
O modelo é muito simples e demonstra as três etapas do teste de carga descritas no diagrama acima: preparação, teste e publicação de relatórios. Responsável por isso : Preparar, testar e relatar.
- Etapa deve ser usado para pré-configurar alvos de teste ou verificar sua disponibilidade. O ambiente para as fontes de carregamento não precisa ser configurado, eles são pré-construídos como imagens docker e postados no registro docker: basta especificar a versão desejada no estágio de teste. Mas você pode reconstruí-los e criar suas próprias imagens modificadas.
- Etapa usado para especificar a fonte de carregamento, executar testes e armazenar artefatos de teste. Você pode escolher qualquer fonte de carregamento: Yandex.Tank, Apache JMeter, seu próprio ou todos juntos. Para desativar fontes desnecessárias, apenas comente ou exclua o trabalho. Pontos de entrada para fontes de carga:
- Os parâmetros de inicialização do Yandex.Tank são especificados no arquivo .,
- Os parâmetros de inicialização do Apache JMeter são especificados no arquivo .
Observação: o modelo de configuração de montagem é usado para configurar a interação com o sistema CI e não implica a colocação de lógica de teste nele. Para testes, o ponto de entrada é especificado, onde o script bash de controle está localizado. O método de execução de testes, geração de relatórios e os próprios scripts de teste devem ser implementados pelos engenheiros de QA. Na demonstração, para ambas as fontes de carregamento, a solicitação da página principal do Yandex é usada como o teste mais simples. Scripts e parâmetros de teste estão no diretório .
- Na fase você precisa descrever como publicar os resultados do teste obtidos no estágio de teste para armazenamentos externos, por exemplo, para GitLab Pages ou sistemas de relatórios especiais. O GitLab Pages exige que o diretório ./public não esteja vazio e contenha pelo menos um arquivo index.html após a conclusão dos testes. Você pode ler sobre as nuances do serviço GitLab Pages. .
Exemplos de como exportar dados:
- de JMeter para ,
- de Yandex.Tank para .
Instruções de configuração de postagem:
- estática HTML em ,
- para InfluxDB e depois para .
No exemplo de demonstração, o pipeline com testes de carga e duas fontes de carga (você pode desabilitar a desnecessária) tem a seguinte aparência:
O Apache JMeter pode gerar um relatório HTML por conta própria, portanto, é mais lucrativo salvá-lo no GitLab Pages usando ferramentas padrão. É assim que o relatório Apache JMeter se parece:
No exemplo de demonstração do Yandex.Tank, você verá apenas na seção de páginas do GitLab. Durante o teste, o Tank pode salvar os resultados no banco de dados InfluxDB, e a partir daí podem ser exibidos, por exemplo, no Grafana (a configuração é feita no arquivo ). É assim que o relatório de Tank aparece no Grafana:
Resumo
No artigo, falei sobre o conceito de "teste de carga como serviço" (teste de carga como serviço). A ideia principal é usar a infraestrutura de pools pré-configurados de agentes de carga, imagens docker de fontes de carga, sistemas de relatórios e um pipeline que os combina no GitLab CI com base em um modelo simples .gitlab-ci.yml (exemplo ). Tudo isso é apoiado 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 Quero agradecer muito aos meus colegas, Sergey Kurbanov e Nikolai Yusev, pela assistência técnica na implementação do conceito de teste de carga como serviço em nossa empresa.
autor: - Deputado Head de Tecnologia e Processos de Desenvolvimento (DevOps) na Positive Technologies
Fonte: habr.com