P\u00e1ginas da web lentas ou que n\u00e3o respondem afetam diretamente a receita financeira, pois usu\u00e1rios frustrados provavelmente n\u00e3o retornar\u00e3o mesmo ap\u00f3s a resolu\u00e7\u00e3o do problema. Por isso, os testes de performance se tornaram uma parte fundamental da cadeia de desenvolvimento, com uma demanda crescente.<\/p>\n
As plataformas de teste de performance oferecem uma ampla variedade de m\u00e9todos de simula\u00e7\u00e3o de carga, como HTTP, navegadores headless e navegadores reais. Neste artigo, apresentamos os principais aspectos de cada abordagem, seguidos por uma matriz comparativa que pode ser usada para escolher a simula\u00e7\u00e3o mais adequada.<\/p>\n
Nos primeiros dias da era digital, os testes baseados em HTTP eram muito populares. Com o surgimento de tecnologias web ricas no lado do cliente, os m\u00e9todos de simula\u00e7\u00e3o baseados em HTTP se tornaram cada vez mais obsoletos. Um driver de teste HTTP t\u00edpico executa solicita\u00e7\u00f5es de servi\u00e7o e interpreta as respostas. Aplica\u00e7\u00f5es modernas Web 2.0 incluem muitos scripts no lado do cliente, que s\u00e3o completamente ignorados e n\u00e3o s\u00e3o medidos nesse tipo de teste. No pior cen\u00e1rio, casos de uso complexos n\u00e3o podem ser simulados no n\u00edvel do protocolo devido \u00e0 aus\u00eancia de IDs gerados no cliente.<\/p>\n
Devido \u00e0 natureza baseada em requisi\u00e7\u00e3o e resposta, a sobrecarga na m\u00e1quina de inje\u00e7\u00e3o de carga \u00e9 muito baixa. Um servidor t\u00edpico pode simular at\u00e9 800 sess\u00f5es simult\u00e2neas. Casos de uso complexos baseados em protocolo podem ser dif\u00edceis de implementar. Um engenheiro de performance precisa lidar com cookies, IDs de sess\u00e3o e outros par\u00e2metros din\u00e2micos. Dependendo do sistema testado, nomes de formul\u00e1rios podem mudar com novas vers\u00f5es, o que pode fazer com que scripts HTTP falhem.<\/p>\n
Com o avan\u00e7o das tecnologias Web 2.0, o setor de testes enfrentou s\u00e9rios desafios. Aplica\u00e7\u00f5es web ricas n\u00e3o podiam mais ser testadas no n\u00edvel de protocolo, devido \u00e0 aus\u00eancia da l\u00f3gica do lado do cliente durante a execu\u00e7\u00e3o dos scripts. Assim, surgiram navegadores headless como HtmlUnit, PhantomJS e SlimerJS. Eles s\u00e3o geralmente baseados no WebKit, o motor por tr\u00e1s do Chrome e do Safari.<\/p>\n
Navegadores headless s\u00e3o semelhantes a navegadores reais, mas sem interface gr\u00e1fica (GUI). Muitas plataformas de automa\u00e7\u00e3o de testes e de performance utilizam esses navegadores para simular tr\u00e1fego.<\/p>\n
No entanto, navegadores headless t\u00eam suas limita\u00e7\u00f5es: \u00e0 medida que novos navegadores surgem, os kits headless precisam acompanhar as atualiza\u00e7\u00f5es de performance e recursos dos navegadores reais.<\/p>\n
A simula\u00e7\u00e3o do renderiza\u00e7\u00e3o no lado do cliente tem seu custo. Um servidor t\u00edpico de inje\u00e7\u00e3o de carga consegue simular apenas de 10 a 12 sess\u00f5es headless simult\u00e2neas, contra 500 sess\u00f5es baseadas em HTTP.<\/p>\n
A cria\u00e7\u00e3o e personaliza\u00e7\u00e3o de scripts de teste n\u00e3o \u00e9 muito dif\u00edcil. Com conhecimentos b\u00e1sicos de programa\u00e7\u00e3o, \u00e9 poss\u00edvel desenvolver scripts simples. Nem todos os navegadores headless oferecem recursos de reprodu\u00e7\u00e3o visual, e sem esse recurso, a depura\u00e7\u00e3o e an\u00e1lise de erros pode ser bastante complicada.<\/p>\n
Aplica\u00e7\u00f5es Web 2.0 est\u00e3o repletas de JavaScript, Flash, Ajax e CSS. Sem um navegador completo, n\u00e3o \u00e9 poss\u00edvel medir com precis\u00e3o o tempo de resposta de ponta a ponta de uma p\u00e1gina. Testes de performance com navegadores reais permitem validar a funcionalidade e velocidade do site conforme percebidas pelo usu\u00e1rio final.<\/p>\n
Uma solu\u00e7\u00e3o t\u00edpica de teste com navegador real coleta o tempo de carregamento de imagens, JavaScript, CSS e outros elementos. Frequentemente, s\u00e3o fornecidos gr\u00e1ficos em cascata (waterfall) para visualizar esses tempos.<\/p>\n
A pegada de uso do navegador real \u00e9 ligeiramente maior. Considerando que a simula\u00e7\u00e3o com navegador headless n\u00e3o entrega tempos 100% realistas, \u00e9 justo afirmar que a simula\u00e7\u00e3o com navegador real \u00e9 prefer\u00edvel. Em cen\u00e1rios reais, navegadores headless t\u00eam apenas 20% de desempenho superior aos reais. Assim, se um injetor de carga consegue simular 10\u201312 sess\u00f5es headless, pode simular tamb\u00e9m 8\u201310 sess\u00f5es reais.<\/p>\n
A implementa\u00e7\u00e3o e manuten\u00e7\u00e3o de scripts \u00e9 f\u00e1cil, pois as a\u00e7\u00f5es do usu\u00e1rio s\u00e3o reproduzidas diretamente, e a reprodu\u00e7\u00e3o visual facilita a depura\u00e7\u00e3o. No exemplo abaixo, o navegador abre uma URL, insere usu\u00e1rio e senha e clica no bot\u00e3o de login.<\/p>\n
Nos \u00faltimos anos, os m\u00e9todos de desenvolvimento de software passaram a adotar o modelo \u00e1gil. Ciclos curtos de lan\u00e7amento s\u00e3o essenciais. Desenvolvedores e engenheiros de teste automatizam verifica\u00e7\u00f5es de qualidade e desempenho. Em geral, eles implementam testes de performance baseados em servi\u00e7os no n\u00edvel de protocolo ou simulam testes com navegador real para comparar tempos de resposta ponta a ponta com os limites estabelecidos.<\/p>\n
Objetivos<\/p>\n
Por v\u00e1rios motivos, testes de carga s\u00e3o ideais para verificar requisitos n\u00e3o funcionais. Permitem validar tempos de resposta sob condi\u00e7\u00f5es reproduz\u00edveis, al\u00e9m de verificar limites definidos. A medi\u00e7\u00e3o realista do tempo de resposta \u00e9 essencial nesse contexto. Por isso, engenheiros de teste usam simula\u00e7\u00e3o de usu\u00e1rios com navegador headless ou real.<\/p>\n
Objetivos<\/p>\n
Se voc\u00ea precisa testar a confiabilidade da aplica\u00e7\u00e3o sob carga m\u00e1xima, realize um teste de estresse. Esse tipo de teste define o n\u00famero m\u00e1ximo de usu\u00e1rios e o tempo de crescimento e estabiliza\u00e7\u00e3o da carga. O objetivo \u00e9 identificar o ponto de ruptura da aplica\u00e7\u00e3o.<\/p>\n
Objetivos<\/p>\n
Obviamente, h\u00e1 boas raz\u00f5es para utilizar simula\u00e7\u00e3o via protocolo, headless ou navegador real. A tabela abaixo ajuda a escolher a abordagem mais apropriada.<\/p>\n