O que é teste de volume? Aprenda com exemplos
Thomas Hamilton
⚡ Resumo Inteligente
O teste de volume submete uma aplicação a uma quantidade muito grande de dados para verificar como o armazenamento, as consultas e os tempos de resposta se comportam à medida que o banco de dados cresce. Também é chamado de teste de inundação e dimensiona os dados em vez do número de usuários.
O que é teste de volume?
Teste de Volume é um tipo de Teste de Software, onde o software é submetido a um grande volume de dados. Também é referido como testes de inundação. O teste de volume é feito para analisar o desempenho do sistema, aumentando o volume de dados no banco de dados.
Com a ajuda do teste de volume, o impacto no tempo de resposta e no comportamento do sistema pode ser estudado quando exposto a um grande volume de dados.
Por exemplo, um serviço de streaming de música poderia ser testado com um catálogo de 50 milhões de músicas. tracks e uma tabela de histórico de escuta com bilhões de linhas, para verificar se as consultas de pesquisa e recomendação ainda retornam em um tempo aceitável.
Observe a distinção: O volume de testes aumenta o quantidade de dados o sistema aguenta. Aumentando o número de usuários simultâneos É um teste de carga, que é um teste diferente com um objetivo diferente.
Benefícios do teste de volume
- Identificar problemas de capacidade precocemente evita o custo muito maior de corrigi-los na produção.
- Ajuda no início mais rápido dos planos de escalabilidade
- Identificação precoce de gargalos
- Ele garante que seu sistema agora seja capaz de uso no mundo real
Por que realizar testes de volume?
O objetivo de realizar o teste de volume é
- Verifique o desempenho do sistema com volumes crescentes de dados no banco de dados
- Identifique os problemas que provavelmente surgirão quando o conjunto de dados se tornar grande.
- Para descobrir o ponto em que a estabilidade do sistema se degrada
- O teste de volume ajudará a identificar a capacidade do sistema ou aplicativo – volume normal e pesado
Como realizar testes de volume
Em testes de volume, os seguintes itens precisam ser testados
- Teste para verificar se há alguma perda de dados
- Verifique o tempo de resposta do sistema
- Verifique se os dados estão armazenados corretamente ou não
- Verifique se os dados foram substituídos sem qualquer notificação
- Verifique se os avisos e mensagens de erro realmente aparecem quando um limite de volume é atingido.
- Verifique se o alto volume de dados afeta a velocidade de processamento
- Confirme se o sistema possui os recursos de memória e armazenamento necessários para o volume.
- Confirme se o teste de volume abrange todo o sistema e não apenas um componente isolado.
- Existe algum risco se o volume de dados for maior que o especificado
- Verifique se existe alguma garantia de que o volume de dados não excederá o limite máximo especificado.
Melhores Práticas para Testes de Alto Volume
Diversas das práticas abaixo são comuns aos testes de carga, pois ambos geralmente são executados no mesmo ambiente. As práticas específicas para cada volume dizem respeito ao próprio conjunto de dados:
- Pare todos os servidores e verifique todos os logs
- Antes do teste de carga, execute manualmente o cenário do aplicativo
- Para obter resultados mais úteis, escalone o número de usuários
- Para superar as restrições de licença, equilibre o tempo de reflexão
- Seja cauteloso com a nova construção
- Analise o caso de uso para melhoria depois que uma linha de base for estabelecida
- A repetição de partes específicas do teste de volume torna-se inevitável caso haja um gargalo de desempenho
Testes de volume versus testes de carga
| Teste de Volume | Teste de carga |
|---|---|
|
|
|
|
Desafios em testes de volume
- Fragmentação de memória difícil de gerar
- Geração dinâmica de chaves
- Relacional Integrity de dados gerados
Como este teste se compara a outros testes de desempenho
Os testes de desempenho são uma família de testes que diferem na forma da carga aplicada, razão pela qual são tão facilmente confundidos.
| Tipo de teste | O que é aumentado? | Pergunta que responde |
|---|---|---|
| Teste de carga | Usuários simultâneos, até o pico esperado | Será que atinge as metas em condições normais de pico de tráfego? |
| teste de volume | Dados armazenados no banco de dados | Será que ele consegue lidar com o crescimento do conjunto de dados? |
| Teste de estresse | Carga além da capacidade, até a falha | Onde e como se rompe? |
| teste de pico | Carregue instantaneamente e extremamente | Será que sobrevive e se recupera de um choque? |
| Teste de resistência | Duração, sob carga normal | O desempenho se deteriora com o tempo? |
| teste de imersão | Duração, recursos de visualização | Há vazamentos de memória ou de identificadores? |
| Teste de estabilidade | Condições variáveis | Ele permanece confiável mesmo com a mudança das condições? |
A distinção que mais importa aqui é: Os testes de volume dimensionam os dados, os testes de carga dimensionam os usuários. Um relatório que leva dois segundos para ser executado em dez mil linhas e dois minutos em dez milhões de linhas tem um problema de volume, não de carga, e nenhuma quantidade extra de capacidade do servidor irá resolvê-lo.
Como gerar dados de teste para testes em volume
A seção sobre desafios observa que gerar dados realistas é a parte mais difícil dos testes em larga escala. Quatro abordagens são usadas na prática, e cada uma envolve uma compensação.
| Abordagem | Realismo | Principal desvantagem |
|---|---|---|
| Cópia dos dados de produção | A maior | Exposição à privacidade e à conformidade |
| cópia de produção mascarada | Alto | O mascaramento pode comprometer a integridade referencial. |
| Geração sintética | Suporte: | As distribuições podem não corresponder à realidade. |
| tráfego de produção reproduzido | Alto | Requer infraestrutura de captura |
Independentemente do caminho escolhido, três propriedades devem ser válidas, caso contrário, o teste não mede nada de útil.
- Integridade referencial. Cada chave estrangeira precisa ser resolvida. Um milhão de linhas órfãs sobrecarregam o mecanismo de armazenamento, mas nunca os caminhos de junção que o aplicativo realmente usa.
- Cardinalidade realista. Se a tabela de produção tiver dez milhões de linhas distribuídas entre duzentos clientes, gerar dez milhões de linhas para dez milhões de clientes produzirá planos de consulta completamente diferentes.
- Distribuição realista. Os dados reais são distorcidos. Dados uniformemente aleatórios ocultam as partições mais acessadas e a contenção de índices que causam incidentes em produção.
Um alerta prático sobre privacidade. Copiar dados de produção para um ambiente de teste é a causa mais comum de violação de dados em testes. Mascare os campos pessoais antes que a cópia saia do ambiente de produção, não depois.
