Teste de imersão em software: significado e exemplos
Thomas Hamilton
⚡ Resumo Inteligente
O teste de resistência (Soak Testing) aplica uma carga sustentada e realista a uma aplicação durante um período prolongado para expor problemas que só aparecem com o tempo. Vazamentos de memória, esgotamento de conexões e queda gradual de desempenho são os defeitos que ele visa detectar.
O que é teste de imersão?
Teste de imersão é um tipo de teste não funcional usado para medir o desempenho de um aplicativo de software sob um grande volume de carga por um longo período de tempo. O objetivo do teste Soak é garantir se o aplicativo de software sustenta um alto volume de uso e verificar o que aconteceria fora das expectativas de design.
A imagem abaixo mostra um ciclo de teste que mostra em qual estágio o teste de imersão (Tipo de teste de desempenho) é executado em um aplicativo.
Nesse tipo de teste, o que basicamente monitora é a utilização de memória por uma aplicação em um sistema. Ele está testando no nível do sistema, para descobrir se o sistema resistirá a um volume muito alto de uso e para ver o que aconteceria fora das expectativas de design.
Por que fazer o teste de imersão?
Um sistema pode se comportar normalmente quando usado por 2 horas, mas quando o mesmo sistema é usado continuamente por 10 horas ou mais do que isso, ele pode falhar ou se comportar de forma anormal/aleatória/pode travar. Para prever tal falha, o teste de imersão é realizado.
Quando fazer o teste de imersão?
O teste de imersão deve ser feito nos seguintes cenários: –
- Antes que o build seja implantado no cliente, ou seja, antes do lançamento de qualquer aplicativo em uma plataforma específica, ele precisa passar por uma série bem-sucedida de testes de carga em níveis de tráfego altos ou equivalentes. Depois disso o teste de imersão é realizado. Isso nos ajuda a determinar como executar qualquer aplicativo específico por um longo período. Se problemas como vazamentos de memória/corrupção de memória forem encontrados durante o período, ou seja, quando estiver no Soak, isso deverá ser relatado imediatamente.
- O melhor momento para fazer um teste de absorção é nos finais de semana, pois um aplicativo precisa estar em execução por pelo menos um dia ou uma noite. Depende totalmente das limitações da situação de teste. Os testes de imersão são um dos requisitos de conformidade mais importantes que devem ser seguidos rigorosamente por todas as empresas.
Estratégia de teste de imersão
O Long Session Soak Testing é uma estratégia em que um sistema fica sob carga por mais tempo.
Um exemplo simples é quando o usuário permanece conectado a um sistema por muitas horas executando uma série de transações comerciais. Dessa forma, muitos dados são criados. Pode haver muita carga no servidor do sistema/banco de dados, o que pode resultar em travamento/travamento do servidor do sistema/banco de dados.
No teste de absorção de sessão longa, atividades de vários dias (digamos 30 dias) são realizadas em um período de tempo restrito (digamos 2 dias). O número de transações neste período restrito deve corresponder ou ultrapassar o valor de transações de vários dias. O foco deve estar no número de transações processadas. A parte mais importante do Soak Testing é verificar a memória disponível na CPU e a quantidade de memória que estará em uso. Precisamos registrar o uso de memória no início e no final de um teste de absorção. Se necessário, então o uso de memória de recursos como Java Máquinas Virtuais também são importantes e precisam ser monitoradas.
Abaixo estão mais algumas verificações que precisam ser feitas por qualquer usuário/testador antes de começar o teste de imersão:
a) Monitore o consumo de recursos do banco de dados.
b) Monitorar o consumo de recursos do servidor (ex-uso de CPU).
c) O teste de imersão deve ser executado com simultaneidade realista do usuário.
Características do teste de imersão
Um método de teste de imersão padrão deve ter as seguintes características: –
- A duração da maioria dos testes de imersão geralmente é determinada pelo tempo disponível.
- Qualquer aplicativo deve ser executado sem qualquer interrupção se exigir um longo período de tempo.
- Deve abranger todos os cenários acordados pelas partes interessadas.
- Quase todos os sistemas têm um período de janela de manutenção regular e o tempo entre esses períodos de janela é um fator chave para determinar o escopo de um teste de saturação.
Exemplos de Testes de Imersão
- No caso de domínio bancário, quando há uma grande quantidade de dados de comerciantes, o testador colocará o sistema sob carga continuamente por 70 horas a 150 horas para verificar como o aplicativo se comporta durante esse período de carregamento.
- Suponha que sejam 33,000 logins, que precisam ser inseridos no sistema, isso representa sete dias e meio de atividade. Neste caso, um teste de imersão de 60 a 70 horas pode ser iniciado na sexta-feira à noite, por volta das 6h, e pode ser concluído até Monday manhã às 6h. Somente com esse teste será possível observar qualquer degradação de desempenho nas condições controladas.
- No caso dos videogames, Mobile aplicativos, etc. envolvem deixar o jogo ou aplicativo em execução por um período de tempo prolongado, em vários modos de operação - como inativo, pausado na tela de título e assim por diante para descobrir se um aplicativo pode lidar com a carga continuamente esperada .
Problemas comuns observados durante o teste de imersão
- Alocação de memória (vazamentos de memória que eventualmente resultariam em crise de memória ou erros de arredondamento que se manifestam apenas com o tempo).
- Utilização de recursos do banco de dados (falha ao fechar os cursores do banco de dados sob algumas condições que eventualmente resultariam na paralisação de todo o sistema).
- Também pode levar à degradação do desempenho, ou seja, garantir que o tempo de resposta após um longo período de actividade sustentada seja tão bom como era no início do teste.
- Falha ao fechar conexões entre camadas de um sistema multicamadas em algumas circunstâncias que podem paralisar alguns ou todos os módulos do sistema.
- A degradação gradual do tempo de resposta de algumas funções à medida que as estruturas de dados internas se tornam menos eficientes durante um teste longo.
Como este teste se encaixa na família de testes de desempenho
Teste de desempenho é um termo genérico. As variantes abaixo diferem apenas na forma da carga aplicada e na duração em que ela é mantida, razão pela qual são frequentemente confundidas umas com as outras.
| Tipo de teste | Padrão de carregamento | Pergunta que responde |
|---|---|---|
| Teste de carga | Pico de carga esperado, curta duração | O sistema atinge suas metas em condições normais de pico de tráfego? |
| Teste de estresse | Aumentou além da capacidade até a falha. | Onde ocorre a falha, e ela é resolvida de forma elegante? |
| teste de pico | Aumento repentino e extremo, seguido de retirada. | Será que sobrevive e se recupera de um choque de tráfego? |
| Teste de resistência | Carga normal mantida por muitas horas | O desempenho se deteriora com o tempo? |
| teste de imersão | Carga sustentada por um período prolongado | Há vazamentos de memória ou esgotamento de recursos? |
| Teste de estabilidade | Carga variável em diferentes condições | O sistema mantém sua confiabilidade mesmo com a mudança das condições? |
| teste de volume | Usuários normais, volume de dados muito grande | Será que ele consegue lidar com o crescimento da base de dados? |
Os testes de resistência e de imersão são frequentemente tratados como sinônimos. Em termos comuns, ambos os testes são usados para avaliar a capacidade de suportar uma carga constante por um longo período. Quando as equipes os distinguem, o teste de resistência se concentra em verificar se os tempos de resposta aumentam, enquanto o teste de carga se concentra no consumo de recursos, como memória, arquivos e conexões. Executar um deles geralmente fornece evidências para ambos.
Principais métricas a serem coletadas durante o teste
A qualidade de um teste de desempenho depende da qualidade dos registros feitos durante sua execução. Capture esses seis parâmetros no servidor e no cliente e compare-os com a linha de base, em vez de se basear em uma intuição.
| métrico | O que isso te diz | Sinal de aviso |
|---|---|---|
| Tempo médio de resposta | Experiência típica do usuário | Qualquer deriva ascendente ao longo da rota |
| tempo de resposta do 95º percentil | A experiência dos usuários mais lentos | Muito acima da média, o que significa inconsistência. |
| Produtividade | Solicitações processadas por segundo | Queda com carga constante |
| Taxa de erro | Proporção de solicitações com falha ou que expiraram. | Qualquer aumento acima do limite acordado |
| Uso de CPU e memória | Espaço livre nos recursos do servidor | Memória que sobe e nunca retorna |
| Conexões de banco de dados e threads | exaustão da piscina | Contagens que crescem constantemente sem liberação |
Leia a média e o percentil juntos. Uma média de 800 ms com um percentil 95 de 900 ms descreve um sistema consistente. A mesma média com um percentil 95 de 9 segundos significa que um em cada vinte usuários está tendo uma experiência ruim, e a média está mascarando isso.
Observe a forma, não apenas o valor. Em qualquer teste de longa duração, uma linha de recurso estável indica aprovação e uma linha ascendente indica vazamento, mesmo quando o valor absoluto ainda estiver confortavelmente dentro do limite no momento em que a execução termina.
