Modelo de pirâmide de automação para teste de desempenho

Por Federico Toledo (Abstracta) e Leandro Melendez (Grafana k6)

A automação de vários tipos de testes de software gerou grandes benefícios, como mais eficiência, menos erro humano, aceleração dos processos de teste, redução de custo e mais cobertura de teste.

Em resumo, elas revolucionaram a forma de encarar o controle de qualidade no desenvolvimento de software.

Como entender a automação de testes de desempenho no desenvolvimento ágil¶

Entre os testes que precisam ser automatizados, os testes de carga se destacam pela importância de nos ajudar a preparar os sistemas para momentos críticos de alta demanda. Eles permitem entender como os sistemas se comportam quando muitas pessoas acessam ao mesmo tempo e, assim, prevenir possíveis problemas de desempenho.

Em contextos ágeis e em equipes ágeis, em que as aplicações evoluem o tempo todo, é essencial sublinhar a importância de manter scripts de teste de desempenho automatizados.

Os sistemas que testamos evoluem e mudam enquanto rodamos testes de desempenho durante as iterações de desenvolvimento de software. Portanto, funcionalidades novas serão liberadas com regularidade para teste, o que exige testes novos e também a execução dos que já existem, muitas vezes organizados numa suíte abrangente de teste de desempenho. Isso fará com que o código de teste precise ser mantido do mesmo jeito que o código da aplicação.

É aqui que entra a automação de testes de desempenho, considerando aspectos diferentes, como facilidade de preparação, manutenibilidade, possibilidade de execução recorrente etc.

Ainda assim, também encontramos algumas das mesmas desvantagens da automação funcional no teste de desempenho quando as boas práticas não são seguidas. Alguns aspectos são importantes para criar automação de qualidade.

Se não desenharmos e organizarmos a automação direito, ela pode acabar sendo contraproducente, porque o custo de manutenção vai superar o benefício de ter esses testes.

Como automatizar testes de desempenho com eficiência?¶

O modelo de pirâmide de automação, ou “pirâmide asteca de sacrifício da automação” (como o Leandro chama), dá diretrizes para as equipes otimizarem os esforços de teste e os resultados obtidos dos testes automatizados, tanto de teste funcional quanto de desempenho.

Essa estratégia é útil para tratar o teste de desempenho tanto em metodologias waterfall quanto ágeis.

A seguir, compartilhamos um modelo que pode servir de guia ao definir uma estratégia de teste de desempenho.

O modelo de pirâmide de automação aplicado a desempenho¶

Com base na famosa pirâmide de Cohn para testes funcionais automatizados, Leandro e Federico concordam que o modelo, explicado com o triângulo como pirâmide, se aplica ao teste de desempenho.

Esse modelo dá diretrizes sobre como priorizar tipos de automação. Como ele faz isso? Embora existam versões e interpretações diferentes, em geral indica que a maior prioridade e a maior abundância devem ir para a automação no nível de unidade.

Depois, para testes de integração (ou testes de API ou de serviço) e, numa categoria de menor prioridade, a automação no Front End ou na GUI (interface gráfica de usuário), que chamaremos de ponta a ponta, porque testam o sistema inteiro de ponta a ponta.

Estratégia de teste de integração¶

Testes de integração¶

Esses testes são essenciais para validar se módulos ou serviços diferentes usados pela aplicação interagem corretamente. Eles envolvem testar partes combinadas da aplicação para expor falhas nas interações e nas interfaces entre unidades integradas.

Suíte de teste e gestão¶

Uma suíte de teste abrangente sustenta testes unitários e de integração, e permite que quem desenvolve e os testadores verifiquem funcionalidade e desempenho em várias camadas da arquitetura da aplicação.

Modelo de Cohn e modelo de pirâmide de desempenho¶

Na imagem a seguir, mostramos as equivalências entre o modelo de Cohn e o modelo de pirâmide de desempenho. Nela, vemos o que corresponderia a cada nível.

A seguir, olhamos as vantagens e as desvantagens de cada camada. Conforme descemos a pirâmide de testes rumo à base, podemos obter:

• Teste de API e unitário mais barato: mais fácil de preparar, com menos infraestrutura.
• Mais fácil de manter, para rodar com mais frequência (todos os dias).
• Os testes podem ser feitos mais cedo.
• Desvantagens: eles não são conclusivos sobre as métricas reais da experiência do usuário.

Conforme subimos a pirâmide, encontramos:

• Cenários de carga que exigem infraestrutura e carga parecidas com as de produção.
• Testes mais caros, porque são mais difíceis de preparar e manter.
• Resultados melhores, com correspondência direta com as métricas de pessoas usando E2E.

Mais adiante, neste mesmo artigo, vamos entrar em mais detalhe em cada um dos níveis da pirâmide. Como o modelo se baseia numa pirâmide, o Leandro o chama de “a pirâmide asteca dos sacrifícios da automação”.

Pirâmide de testes: por que mencionar “sacrifícios”?¶

Isso se relaciona com a ideia de que, como no tempo dos astecas, os sacrifícios acontecem no topo da pirâmide. Aplicado a software, é onde a maioria das pessoas tenta automatizar em excesso os tipos de teste ponta a ponta, o que pode ser visto como um sacrifício.

Infelizmente, é comum ver organizações ou equipes com uma estratégia em que as quantidades de automação, ou a cobertura de teste, são o oposto do que a pirâmide propõe. Esse antipadrão é conhecido como modelo de casquinha de sorvete. Por causa disso, o Leandro o chama de cone dos sacrifícios.

A estratégia proposta pela pirâmide de automação indica que a automação unitária deve ser priorizada, depois os testes de integração e, por fim, minimizar os sacrifícios no topo com automação ponta a ponta, em vez de gerar cones de sacrifícios.

Pirâmide de automação de testes para teste de desempenho, cada camada em detalhe¶

A ideia desta pirâmide é servir de referência ao estabelecer a estratégia de teste de desempenho do sistema. Isso será mais ou menos aplicável conforme a arquitetura. Podemos dizer que se aplica sobretudo quando há microsserviços ou, pelo menos, uma camada de serviços SOAP ou REST.

A seguir, vamos olhar com mais profundidade e detalhe os aspectos de cada uma das camadas que mencionamos no modelo. Começando pela base, onde estão os testes de desempenho unitários. Depois, vamos descrever a integração de testes de serviço, os testes ponta a ponta e, por fim, aspectos de desempenho do lado do cliente.

Teste de desempenho unitário¶

O objetivo é testar cada serviço individualmente, em isolamento, simulando uma certa carga sobre ele. Preparar um teste é extremamente simples, porque envolve um único pedido HTTP.

Apesar da abordagem de automação, o teste exploratório sempre tem um papel vital na nossa estratégia de teste ágil, permitindo que os testadores apliquem criatividade e intuição. Essa abordagem ajuda a descobrir defeitos que as metodologias de teste automatizado podem não pegar.

Aqui, vamos sempre rodar o mesmo teste e comparar os resultados mais recentes com os anteriores, para observar se os tempos de resposta mostram alguma degradação relevante, identificar e monitorar possíveis problemas de desempenho no sistema.

Quando falamos de testes ponta a ponta na simulação de carga, o nosso cenário de carga e as asserções se baseiam em objetivos de negócio.

A gestão eficaz dos dados de teste é crucial para a precisão e a eficiência dos testes de desempenho. Gerir bem os dados de teste ajuda a garantir que cada teste possa ser feito de forma consistente e possa imitar condições operacionais realistas.

Quantos usuários eu simulo quando fazemos testes unitários no nível de serviço?¶

Sobretudo quando esses testes serão executados num ambiente de teste reduzido. Os testes precisam ter critérios de aceitação (asserções) o mais apertados possível, para que, antes da menor degradação no desempenho daquela funcionalidade e antes de qualquer impacto negativo, uma validação falhe e sinalize o problema.

Em geral, isso se alcança checando taxas de erro, tempos de resposta e vazão (número de pedidos ou requisitos atendidos por segundo).

Problemas comuns no teste de desempenho unitário¶

Nos gráficos a seguir, compartilhamos um problema típico que queremos evitar:

Na primeira imagem, vemos que os tempos de resposta aumentam. Na segunda, notamos uma queda nos pedidos por segundo (RPS), mas o teste não reporta um erro nem dá um alerta sobre essa degradação, porque os critérios de aceitação não são estritos. O teste verifica se o desempenho está acima de 60 RPS, então, quando a funcionalidade cai de 250 para 200, ninguém vai prestar atenção nisso.

Para evitar esses problemas, precisamos que as asserções sejam mais estritas, para que uma degradação desse tipo faça o pipeline falhar.

Como definir a carga e as asserções?¶

O que precisamos fazer é algumas execuções em modo experimental, para determinar a carga e as asserções que vamos definir nos nossos testes de desempenho unitários, a fim de executá-los de forma contínua no nosso pipeline.

Digamos que o nosso primeiro teste rode 100 execuções em paralelo e termine sem erros, os tempos de resposta fiquem abaixo de 100 milissegundos (ms), pelo menos no percentil 95, e a vazão seja de 50 RPS.

Depois, rodamos o mesmo teste, mas com 200 RPS. De novo, não ocorrem erros, e os tempos ficam em 115 ms e o desempenho em 75 RPS.

Ótimo, está escalando.

Como identificar os limites de escala¶

Se continuarmos nesse caminho de teste, em algum momento vamos chegar a uma carga em que veremos que já não conseguimos aumentar a vazão.

Seguindo esse cenário, imaginemos que chegamos a 350 execuções em paralelo e temos uma vazão de 150 RPS, com tempos de resposta de 130 ms e 0% de erros.

Se passamos de 400, a vazão permanece em cerca de 150 RPS e, com 450 em paralelo, a vazão fica até menor que 150.

Há um conceito chamado ponto de joelho (joelho, pela quebra no gráfico) que encontraríamos num certo ponto, e que determina que estamos saturando algum gargalo.

Espera-se que o número de pedidos por segundo aumente quando aumentamos o número de execuções concorrentes. Se isso não acontece, é porque estamos sobrecarregando a capacidade do sistema.

Esse é o método básico para achar o ponto de joelho ao fazer teste de estresse, quando queremos saber o quanto os nossos servidores podem escalar na configuração atual.

Como definir referenciais de desempenho¶

Assim, ao fim deste experimento, chegamos a definir o cenário que queremos incluir no nosso pipeline, com as seguintes asserções:

Carga: 350 execuções concorrentes.

Asserções¶

• Menos de 1% de erro.
• Tempos de resposta P95 <130 ms + 10%.
• Vazão >= 150 RPS – 10%.

A seguir, o teste que vamos programar para continuar rodando com frequência é o que roda 350 execuções concorrentes. Esperamos que ele tenha menos de 1% de erro, com tempos de resposta abaixo de 130 ms, com uma margem possível de 10%, talvez 20%.

Por último, e não menos importante, temos de checar se a vazão é de pelo menos 150 RPS, também com uma margem de 10%.

Desse jeito, podemos detectar o mais cedo possível quando uma mudança faz o desempenho do sistema cair.

Para tudo isso ser válido, precisamos de um ambiente exclusivo para teste. Assim, os resultados ficam mais previsíveis e não são afetados por fatores como outras pessoas rodando outras tarefas ao mesmo tempo.

Teste de desempenho na camada de integração¶

Nesses testes, vamos poder testar vários serviços de uma vez para ver como eles afetam o desempenho uns dos outros. Para isso, vamos pegar os mesmos testes unitários e combiná-los num único cenário concorrente. Se já tivermos os outros preparados, montar esses testes não deve ser tão complexo.

Antes de continuar, gostaríamos de esclarecer por que é importante testar os mesmos serviços de forma combinada.

“Falácia da composição”¶

Testar as partes não basta para saber como o todo vai se comportar. O todo precisa ser testado para ver como as partes interagem.

Como Jerry Weinberg nos ensinou, boas equipes de teste sabem que não basta testar as “partes” para saber como o “todo” vai se comportar, porque o todo precisa ser testado para ver como as partes interagem.

Portanto, devemos complementar os testes unitários com testes de integração.

Testes de desempenho ponta a ponta¶

Estes são os testes de desempenho clássicos, em que simulamos a carga que esperamos no sistema (um certo número de pessoas acessando ao mesmo tempo) num ambiente que replica as condições do ambiente de produção. Os scripts precisam ser preparados no nível da comunicação do cliente (navegador, app mobile etc.) e não no nível de serviço.

O objetivo principal dos testes de desempenho ponta a ponta é identificar possíveis gargalos, problemas de escalabilidade ou degradação de desempenho que possam surgir em situações de uso real.

Esses testes costumam envolver a simulação de pessoas reais interagindo com a aplicação em vários passos, como navegar páginas, preencher formulários e fazer transações. Coletar dados de tempos de resposta, taxas de erro e outros indicadores-chave de desempenho é essencial para avaliar o comportamento do sistema sob carga.

Eles são, em resumo, uma parte fundamental do processo de garantia de qualidade, porque ajudam uma aplicação a operar com eficiência e eficácia em condições de produção, minimizando assim problemas de desempenho.

Desempenho do lado do cliente¶

Além das camadas anteriores da pirâmide, que focam no lado do servidor, gostaríamos de lembrar que nunca se esqueça do lado do cliente ou dos navegadores. Problemas no lado do cliente que causam atrasos na experiência final podem invalidar os esforços de otimização feitos no backend (os servidores).

No caso de aplicações web, há inúmeras ferramentas disponíveis para avaliar o desempenho dessa perspectiva. Elas não só vão dizer automaticamente quais problemas estão presentes no site, como também vão mostrar como resolvê-los. Compartilhamos algumas:

• Lighthouse, como parte do Google Chrome Developer
• Google PageSpeed Insights
• Website.io
• Yslow

No caso de apps mobile, recomendamos usar o Apptim, uma ferramenta especializada em avaliar o desempenho de aplicações mobile.

Essas ferramentas podem ser muito úteis para ajudar a sua aplicação a operar com eficiência e oferecer uma experiência ótima.

Além disso, é importante mencionar que existe a possibilidade de fazer testes híbridos, como propõe Marie Cruz no artigo dela sobre teste de desempenho de navegador. Essa estratégia combina ferramentas como k6 browser e Google Lighthouse para ter uma visão completa do desempenho da sua aplicação a partir de perspectivas diferentes.

A proposta de teste híbrido pode ser especialmente benéfica para identificar problemas tanto no lado do servidor quanto no lado do cliente.

Outras visões do modelo de pirâmide de testes¶

Uma coisa boa dos modelos é que eles permitem analisar visões diferentes que podem ser úteis. Além do que já foi dito, queremos compartilhar outros aspectos interessantes ao analisar o mesmo modelo, o que dá mais dimensões a considerar.

Frequência das execuções¶

Imaginemos outra visão da pirâmide, que se refere à frequência de execuções que deveriam ser feitas em cada nível de teste. Isso é especialmente importante em projetos modernos que seguem o estilo ágil, contínuo ou variações do estilo ágil.

O fundamental aqui é determinar com que frequência posso executar cada tipo de teste. Isso depende de quão fácil é preparar, codificar e manter esses testes e, por outro lado, de qual informação eles me dão.

Portanto, a proposta é executar os testes unitários dos serviços com frequência, talvez em cada build do pipeline, como explicado (por Federico) neste webinar e neste post.

Para ver como os serviços impactam uns aos outros, devemos executar de vez em quando testes em que combinamos vários serviços, chamados de testes de integração.

Como até aqui não sabemos nada sobre qual será a experiência do usuário, temos de complementar isso com os testes de carga clássicos. Eles são muito mais complicados de preparar, mas são os únicos que nos ajudam a reduzir esses riscos.

O bom é que, se fizermos testes unitários e testes de integração com frequência, provavelmente chegamos a essa etapa com menos probabilidade de achar problemas graves ou, pelo menos, já antecipamos vários deles.

Parecido com o que foi explicado na pirâmide anterior, muitas organizações seguem uma estratégia invertida e focam em executar testes de carga com mais frequência, enquanto fazem quantidades muito baixas e executam testes unitários com pouca frequência.

Infraestrutura de teste de desempenho¶

Quantas vezes você também ouviu que só podemos executar testes de desempenho em infraestrutura muito parecida com a de produção?

Acreditamos que essa afirmação se aplica sobretudo aos testes que correspondem à camada mais alta da pirâmide, isto é, aos testes ponta a ponta que vão nos permitir saber os tempos de resposta que quem acessa o sistema vai obter.

Por outro lado, vale esclarecer que podemos executar testes de desempenho em infraestruturas de menor potência, como ambientes de teste ou de desenvolvimento, e obter resultados muito úteis dessas execuções.

O que precisa ficar em mente é que os resultados não devem ser extrapolados. Em outras palavras, se eu executo num ambiente de teste, não é seguro assumir que, em produção, onde a infraestrutura tem o dobro da potência, os tempos de resposta serão a metade.

Rodar testes unitários e de integração em ambientes reduzidos, como teste ou desenvolvimento, traz muitas vantagens. Alguns erros e otimizações podem ser atacados mesmo sem ter ambientes como o de produção.

Testes de desempenho sempre rendem resultados valiosos em todos os cenários.

Em particular, a vantagem de rodar esses testes em ambientes reduzidos (em escala menor) é que vamos poder estressar o sistema, para analisar como ele se comporta perto dos limites, com cargas menores. Isso implica custos menores de infraestrutura de teste ou de licença da ferramenta de simulação de carga. A preparação e a gestão serão mais fáceis, e os resultados podem ser obtidos mais cedo.

Você aplicaria o modelo de pirâmide aos seus testes de desempenho? O que achou deste tema? O que acha da pirâmide de automação de testes de software aplicada a desempenho? Tem outras dicas ou ideias sobre o assunto para compartilhar? Adoraríamos ouvir a sua opinião e a sua experiência!

Precisa de ajuda com serviços de automação de testes ou teste de desempenho? Não perca este artigo! Como elevar o nível: primeiros passos com um parceiro de testes de software.