Olá pessoal! Na próxima semana, as aulas no grupo
Java QA Engineer serão iniciadas. Isso será programado para coincidir com a publicação atual.
Revisão:
A execução diária de testes de regressão automatizados como parte da montagem diária é inevitável no momento. É bom encontrar e relatar erros logo após encontrá-los. Ao mesmo tempo, é problemático executar centenas de testes automatizados e execução paralela remota. Assim que você tiver um conjunto de testes de regressão automatizados, poderá dividi-lo em vários conjuntos de módulos de negócios e executá-los em paralelo, como parte de um teste diário de regressão automatizada. A maioria desses conjuntos de testes é executada em uma máquina virtual remota e os resultados do teste estão disponíveis apenas após a execução. Caso contrário, você pode olhar no console do jenkins para ver os logs do processo de execução do teste. Isso às vezes é chato. Seria ótimo ter um aplicativo que fornece informações sobre como passar no teste enquanto eles estão sendo executados em máquinas virtuais remotas.
Vamos ver como você pode criar uma página simples com resultados de teste e um painel usando o InfluxDB e o Grafana.
Objetivo:
Coletaremos todas as métricas de teste disponíveis, como:
- Status do método de teste
- Duração do método de teste
- Status da classe com métodos de teste
- Tempo de execução de teste de classe única
- Status do conjunto de testes
- Duração da execução do teste
Podemos obter alguns dos indicadores em tempo real, como mostrado abaixo:
- O número de métodos de teste agrupados por status (por exemplo: Aprovado: 30, Falha: 2, Ignorado: 2) em um dia específico.
- A tendência na duração do conjunto de testes por uma semana, mês, ano etc.
InfluxDB:
O InfluxDB é um banco de dados de séries temporais usado para coletar todas as métricas de teste. O InfluxDB possui uma API REST para gravar dados e enviar solicitações. Você pode aprender mais
aqui . Abaixo, uso o comando docker para iniciar uma instância do InfluxDB.
sudo docker run -p 8086:8086 -v $PWD:/var/lib/influxdb influxdb
Criando um banco de dados:
Já levantamos e lançamos o banco de dados InfluxDB. Vamos criar um esquema de banco de dados separado para coletar os resultados do teste Selenium. Abaixo, eu executo um comando no terminal para criar um esquema chamado "selênio" no banco de dados. (Verifique a URL, substitua localhost por hostname / ipaddress se você não estiver executando no computador atual).
curl -i -XPOST http:
TestNG:
Vamos criar um teste testNG simples:
public class SampleTest { @Test(description = "login") public void login(){ } @Test(description = "search for flights", dependsOnMethods = "login") public void search(){ } @Test(description = "select flight", dependsOnMethods = "search") public void select(){ } @Test(description = "book flight", dependsOnMethods = "select") public void book(){ } @Test(description = "logout", dependsOnMethods = "book") public void logout(){ } }
Nosso objetivo é coletar resultados de teste no InfluxDB em tempo de execução. Portanto, precisamos de um driver / biblioteca em Java para o InfluxDB.
Dependências do Maven:
Adicione as dependências do Maven mostradas abaixo:
<dependency> <groupId>org.influxdb</groupId> <artifactId>influxdb-java</artifactId> <version>2.12</version> </dependency>
Alunos:
Os ouvintes do TestNG são ótimos para ouvir eventos e podem responder dependendo do que aconteceu. Primeiro, vamos criar uma classe simples responsável pelo envio dos resultados ao InfluxDB.
import org.influxdb.InfluxDB; import org.influxdb.InfluxDBFactory; import org.influxdb.dto.Point; public class ResultSender { private static final InfluxDB INFLXUDB = InfluxDBFactory.connect("http://localhost:8086", "root", "root"); private static final String DATABASE = "selenium"; static{ INFLXUDB.setDatabase(DATABASE); } public static void send(final Point point){ INFLXUDB.write(point); } }
Agora crie outra classe que implemente a interface ITestListener.
import org.influxdb.dto.Point; import org.testng.ITestContext; import org.testng.ITestListener; import org.testng.ITestResult; import java.util.concurrent.TimeUnit; public class ExecutionListener implements ITestListener { public void onTestStart(ITestResult iTestResult) { } public void onTestSuccess(ITestResult iTestResult) { this.sendTestMethodStatus(iTestResult, "PASS"); } public void onTestFailure(ITestResult iTestResult) { this.sendTestMethodStatus(iTestResult, "FAIL"); } public void onTestSkipped(ITestResult iTestResult) { this.sendTestMethodStatus(iTestResult, "SKIPPED"); } public void onTestFailedButWithinSuccessPercentage(ITestResult iTestResult) { } public void onStart(ITestContext iTestContext) { } public void onFinish(ITestContext iTestContext) { this.sendTestClassStatus(iTestContext); } private void sendTestMethodStatus(ITestResult iTestResult, String status) { Point point = Point.measurement("testmethod") .time(System.currentTimeMillis(), TimeUnit.MILLISECONDS) .tag("testclass", iTestResult.getTestClass().getName()) .tag("name", iTestResult.getName()) .tag("description", iTestResult.getMethod().getDescription()) .tag("result", status) .addField("duration", (iTestResult.getEndMillis() - iTestResult.getStartMillis())) .build(); ResultSender.send(point); } private void sendTestClassStatus(ITestContext iTestContext) { Point point = Point.measurement("testclass") .time(System.currentTimeMillis(), TimeUnit.MILLISECONDS) .tag("name", iTestContext.getAllTestMethods()[0].getTestClass().getName()) .addField("duration", (iTestContext.getEndDate().getTime() - iTestContext.getStartDate().getTime())) .build(); ResultSender.send(point); } }
Nota: Use uma tag opcional que atenda às suas metas no exemplo acima para classificar os resultados. Por exemplo, tag ("cenário", "fluxo de login").
O ouvinte do exemplo acima monitorará a execução do teste e, assim que um determinado método / classe do teste for concluído, ele enviará um nome, duração e alguns detalhes adicionais. Meu objetivo aqui é apenas dar uma idéia. Mude o código de acordo com suas necessidades.
Agora adicione o ouvinte ao pacote XML ou à classe base TestNG.
<suite name="My suite"> <listeners> <listener class-name="com.tag.realtime.ExecutionListener" /> </listeners> <test name="Test1"> <classes> <class name="com.tag.realtime.SampleTest"/> </classes> </test> <test name="Test2"> <classes> <class name="com.tag.realtime.Sample2Test"/> </classes> </test> </suite>
Ou então:
@Listeners(ExecutionListener.class) public class SampleTest { @Test public void test(){ } }
Grafana:
Conseguimos enviar os resultados para o InfluxDB. Mas como solicitar resultados e visualizar os dados recebidos? Para isso, usaremos outra ferramenta gratuita chamada “Grafana”.
O Grafana é uma excelente ferramenta de visualização para dados de séries temporais; ele interage perfeitamente com o InfluxDB. A seguir, são apresentados os comandos da janela de encaixe para criar uma instância do Grafana. [o plugin piechart é opcional na equipe, pode ser removido se não for necessário]
docker run -d -p 3000:3000 --name=grafana \ -e "GF_INSTALL_PLUGINS=grafana-piechart-panel" \ -v $PWD:/var/lib/grafana \ grafana/grafana
Fonte de dados para Grafana:
Vá para
Configurações -> Fontes de dados -> Adicionar nova fonte de dados , conforme mostrado na captura de tela. Clique no botão 'Salvar e testar' para garantir que o Grafana possa se comunicar com o InfluxDB.
Nota: Se você estiver usando o Grafana com Docker e tentando acessar como 'Padrão do servidor', NÃO use localhost na cadeia de conexão do InfluxDB. Isso porque aqui localhost é um contêiner Grafana, não uma máquina física. Portanto, o contêiner Grafana não poderá encontrar o InfluxDB.
Criando um painel:
Gostaria que você assistisse a este vídeo, porque não é fácil explicar todas as nuances deste artigo. Por isso gravei um vídeo de hotel.
Demo 2:Para resumir:
Espero que obter resultados em tempo real usando o InfluxDB e o Grafana seja interessante e útil. Requer mudanças mínimas na estrutura existente, porque usamos ouvintes TestNG. Remover o ouvinte do arquivo de classe set / base é suficiente para desativar esta função se você não precisar dela. Essa abordagem ajudará a evitar algumas frustrações na equipe se seus membros estiverem envolvidos apenas no monitoramento dos resultados do teste via E / S do console na máquina remota. Este artigo descreve apenas a ideia principal. Você pode melhorar essa abordagem adicionando mais informações, por exemplo, um ambiente de teste, adicionar filtros adicionais para atualizar os dados em gráficos para um ambiente / testes específicos etc.
Aqui está um material tão curto, mas bastante útil. Tradicionalmente, estamos aguardando seus comentários e lembre-se de que hoje será
dia aberto, na taxa em que qualquer pessoa possa se inscrever.