As duas famílias de ferramentas de teste de performance de UI
Laboratório, sintéticas
Carregam uma página sob condições controladas e atribuem uma pontuação.
Repetíveis e comparáveis. Medem um ambiente limpo com dados limpos.
Campo, usuários reais
Coletam tempos de sessões reais.
Honestas sobre a realidade. Avisam você depois que já aconteceu com alguém.
O que fica entre elas
As ferramentas de laboratório rodam contra um ambiente de teste, o que significa um conjunto de dados pequeno. As de campo enxergam volumes reais de dados e só reportam depois que um usuário real sofreu. Então uma tela que é rápida com dez linhas e inutilizável com duas mil passa no laboratório e aparece no campo, que é a pior ordem possível.
Fechar essa lacuna não exige uma nova categoria de ferramenta. Exige uma conta populada com dados do tamanho de um cliente grande e os mesmos fluxos exercitados contra ela antes do release.
Como escolher dentro de cada família
Ferramentas de laboratório: prefira as que medem a latência de interação, não apenas o carregamento inicial. O carregamento é um custo único por sessão; a interação acontece o tempo todo.
Ferramentas de campo: verifique se você consegue segmentar por tamanho de conta. Uma média entre todos os clientes esconde justamente os clientes que estão sofrendo.
Ambas: compare com o seu próprio histórico em vez de uma pontuação absoluta. Limiares emprestados raramente se transferem entre produtos.
Segmentar os dados de campo para que signifiquem algo
O monitoramento de usuários reais é a mais honesta das duas famílias, e é fácil torná-lo inútil olhando para o agregado errado.
Uma média entre todos os usuários mistura um cliente com cinquenta registros e outro com cinquenta mil, e o segundo é todo o sinal. O mesmo vale para misturar dispositivos, misturar geografias e misturar seus usuários internos com seus clientes. O número geral pode melhorar enquanto suas maiores contas pioram continuamente, e esse é o modo de falha que custa renovações.
Segmente pela dimensão em que seu produto de fato varia, que na maioria dos softwares corporativos é o tamanho da conta, e não o dispositivo ou a rede. Se a ferramenta não consegue segmentar assim, o número que ela reporta não está medindo aquilo que importa para você.
O pré-requisito que ninguém lista
Uma tela que renderiza instantaneamente porque a requisição falhou silenciosamente vai tirar uma nota ótima em uma ferramenta de laboratório. A corretude é a base de qualquer número de performance, e verificá-la sai mais barato do que qualquer uma das ferramentas acima.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
A mesma configuração está disponível no dashboard do TestSprite, caso você prefira não instalar nada localmente. O restante da superfície do CLI está no repositório do CLI.
Onde cada uma roda
Ferramentas de laboratório no pipeline, em cada pull request, comparando com a sua baseline. Monitoramento de campo sempre ligado. Verificação funcional contra uma conta de tamanho realista, também a cada mudança, porque essa é a lacuna que as outras duas deixam aberta.
O gatilho importa mais do que o mecanismo. Apontá-lo para o seu evento de deploy significa que toda mudança é verificada sem que ninguém precise decidir por isso; o GitHub App faz isso a partir do dashboard, e um passo do GitHub Actions faz isso de dentro do seu workflow.
Onde o TestSprite se encaixa entre laboratório e campo
Na lacuna que as duas deixam aberta: exercitar fluxos reais contra um ambiente com dados realistas, antes do release. A cobertura é gerada a partir do seu produto e roda a cada mudança, então uma tela que funciona com dez linhas e quebra com duas mil é pega pelo comportamento, e não por um percentil.
Ele também entrega o pré-requisito que nenhuma das duas famílias verifica. Uma página que renderiza instantaneamente porque a busca de dados falhou é rápida e errada, e uma pontuação de laboratório não vai te dizer isso.
As ferramentas de laboratório continuam medindo carregamento e tempo de interação; o monitoramento de campo continua reportando o que os usuários vivenciaram. O ganho aqui é que a falha que só aparece no volume de dados do seu maior cliente é encontrada antes que esse cliente a encontre.
O TestSprite está nessa categoria?
Não. Ele verifica se os fluxos se comportam corretamente, que é o pré-requisito para qualquer número de performance significar alguma coisa.
Precisamos de ferramentas de laboratório e de campo?
Sim. O laboratório dá a você um sinal repetível antes do release; o campo conta o que de fato aconteceu. Nenhum dos dois basta sozinho.
E o monitoramento sintético?
É uma ferramenta de laboratório apontada para a produção em intervalos programados. Útil para disponibilidade, e ainda assim roda contra quaisquer dados que aquela conta tenha.
Qual deve ser o tamanho de uma conta de teste populada com dados?
Do tamanho do seu maior cliente real. Menos do que isso e você está testando um caso que não existe em produção.
Pontuações de performance devem bloquear merges?
Uma regressão grande em relação à sua própria baseline, sim. Um limiar de pontuação absoluta, geralmente não, porque ele acompanha o benchmark, e não o seu produto.
O laboratório é limpo demais; o campo é tarde demais.
As ferramentas de teste de performance de UI são de laboratório ou de campo, e as duas deixam passar a degradação com volumes reais de dados. Popule uma conta do tamanho de um cliente grande, exercite os fluxos contra ela antes do release e verifique a corretude primeiro.