Ambas as opções (JMeter e JUnit) vão resolver o problema, entretanto uma delas vai lhe dar problemas no futuro. Mas vamos falar sobre isto no final.
Para um teste básico no JMeter você precisará de um HTTP Request
- Informe a URL do serviço no campo Server Name or IP ( ex: servidor.qa.sua_empresa )
- Informe no campo Path o restante da URL ( ex: /aplicacaoX/login )
- Informe o tipo de requisição no campo Method ( ex: POST, GET, etc )
- Preencha no campo Body Data o JSON que o serviço precisar se necessário conforme imagem abaixo:
Precisará de HTTP Header Manager para definir o formato de requisição e resposta (ex: XML, JSON, TXT e etc) entre outras informações que podem ser necessárias ao serviço:
Precisará de um HTTP Cookie Manager caso o serviço persista alguma informação no cookie do usuário.
E um Response Assertion para validar conteúdo no retorno do serviço:
Se você decidir testar no JUnit precisará de duas classes.
A primeira classe é a chamada ao serviço através de um client ( Jersey é uma das bibliotecas disponíveis ).
No exemplo abaixo escrevemos um método que faz a requisição no serviço, mas precisa da URL e do JSON com os dados da requisição:
Na segunda classe foi criado o teste definindo o JSON, a URL e verificando se no retorno há o texto esperado:
Agora que sabemos como implementar o teste em ambas as ferramentas, partiremos para o seguinte problema: variação nos dados de teste.
Assim que você aplicar as técnicas de teste (valores limítrofes, equivalência de classes e etc) perceberá que manter os dados na ferramenta de teste é quase inviável.
Nessa hora você vai partir para o data-driven testing (DDT) e são duas as opções mas fáceis:
- CSV no JMeter
- Excel no JUnit
É importante que os dados permaneçam em um único local, pois a manutenção se torna inviável se parte estiver no arquivo e a outra parte na ferramenta. É exatamente ai que o JMeter falha.
Dados como: CPF, E-mail e etc precisam (quase sempre) ser dinâmicos, mas o JMeter usa o CSV, que não atualiza estes dados dinamicamente e salvo se você substituir manualmente o CSV, seus testes falharão.
Ai você tem a brilhante idéia de gerar os dados dentro do JMeter (como ensinamos em outro post) e cai no problema acima da manutenção dos testes e também da compreensão dos mesmos.
Tente entender mais de 500 casos de teste divididos entre CSV e os componentes do JMeter.
Neste caso o JUnit se mostrou mais eficiente, pois as funções do Excel atualizam/geram automaticamente (através da biblioteca Apache POI) os dados no início de cada teste. Em ambos os casos uma coluna adicional "Descrição" identifica o objetivo de cada linha de teste.
A propósito, vejo com certa frequência suites de testes do JMeter serem apagadas por falta de entendimento quando associados com CSV.
Alguém sabe resolver este problema e tornar compreensíveis estes casos de teste?
