Execute os seus testes end-to-end em cada build: um exemplo com o TeamCity que funciona com qualquer ferramenta de CI/CD
Automação de testes end-to-end no seu pipeline: adicione os seus testes do GUI Test Studio a um build do TeamCity em uma etapa com o gtr-cli, e leia cada teste, as falhas, o vídeo e as imagens no TeamCity.O mesmo comando executa os seus testes de GUI, funcionais e de regressão no Jenkins, GitHub Actions, GitLab, Azure DevOps ou em qualquer script.
7 min de leituraPela equipe do GUI Test Studio
Por que executar testes de ponta a ponta a cada build
Definição
Um teste de ponta a ponta conduz seu aplicativo como um usuário faz: ele o abre, clica e digita ao longo de um fluxo inteiro, e verifica o que a tela mostra no final.
- É o teste que pega o que os testes de unidade não conseguem: um botão quebrado, um formulário que não envia mais, uma página que perdeu o conteúdo.
Um desenvolvedor faz push
Qualquer branch
O TeamCity inicia um build
Uma etapa de build
O gtr-cli executa os testes
Na tela da máquina de build, ou sem janela
Você lê o resultado
Testes, log, vídeo e imagens
O GUI Test Studio vem com um executor de linha de comando exatamente para isso: o gtr-cli.Ele é instalado com os aplicativos.Ele executa os testes de interface de ponta a ponta que você gravou e editou, sem abrir nenhuma janela, e responde do jeito que um pipeline espera: um código de saída, um arquivo JUnit, um log que sua ferramenta de CI entende.
gtr-cli run tests --format teamcity --junit ci-out\junit.xml
Código de saída
0 · 1
0 quando todos os testes passaram, 1 quando um teste falhou
junit.xml
<testcase>
Cada teste como um teste, lido por qualquer ferramenta de CI
Log do build
##teamcity[...]
Cada teste e cada falha na própria linguagem de log do TeamCity
Do que você precisa
| O quê | Por quê | Onde obter |
|---|---|---|
| Um teste criado com o GUI Test Studio | O teste de ponta a ponta que o pipeline executa, guardado no seu repositório como qualquer arquivo | O seu primeiro teste, passo a passo |
| Uma máquina de build Windows com o GUI Test Studio instalado | O gtr-cli vem com o instalador e reproduz o teste nessa máquina | Instalar e configurar |
| TeamCity (ou outra ferramenta de CI) | Inicia um build a cada mudança e mostra os resultados | TeamCity, da JetBrains |
Etapa 1: Prepare a máquina de build
Um teste de ponta a ponta reproduz cliques e digitação em uma tela real, então o agente de build precisa de uma área de trabalho para trabalhar.
Como serviço do Windows
Nenhuma tela para reproduzir um teste.
Em uma sessão do Windows com usuário conectado
Uma área de trabalho de verdade, no tamanho de tela e na escala da gravação.
Sem janela (headless), para um teste web
Nenhuma tela necessária, e vários navegadores e dispositivos são executados lado a lado.
- 1
Instale o GUI Test Studio e entre uma vez
O instalador coloca o gtr-cli no PATH.Entre nos aplicativos uma vez nessa máquina, com a conta usada pelo agente.
- 2
Execute o agente em uma sessão do Windows com usuário conectado
Inicie o agente do TeamCity a partir de uma sessão de usuário conectado, e não como serviço do Windows: um serviço não tem tela para reproduzir um teste.Mantenha o tamanho de tela e a escala da gravação.Veja Preparar a máquina de build.
- 3
Ou execute testes web sem janela
Um teste de um aplicativo web pode ser executado sem nenhuma janela de navegador, com
--headless on.Assim ele não precisa de uma tela livre, e vários navegadores e dispositivos são executados lado a lado.
Etapa 2: Monte o comando
Você não precisa aprender as opções.Em qualquer um dos aplicativos, abra a janela Linha de comando e CI/CD, marque o que deseja e copie o comando, ou o trecho pronto para sua ferramenta de CI com os seus caminhos reais.
Este é o comando que o pipeline do nosso exemplo executa:
gtr-cli run tests\Checkout\Checkout.GTS --branch all --countdown 0 --format teamcity ^
--junit ci-out\junit.xml --json ci-out\result.json ^
--artifacts ci-out\artifacts --bug-report pdf| Opção | O que faz |
|---|---|
| --branch all | Executa o teste em todos os navegadores e dispositivos para os quais ele foi criado |
| --countdown 0 | Começa na hora: ninguém está na máquina de build para soltar o mouse |
| --format teamcity | Escreve cada teste e cada falha na própria linguagem de log do TeamCity |
| --junit / --json | Escreve os resultados em arquivos que qualquer ferramenta consegue ler |
| --artifacts | Guarda o vídeo da execução, o relatório dela e as imagens de cada falha |
| --bug-report pdf | Escreve um relatório de bug preenchido para cada teste que falhou |
Cada opção é explicada em Executar testes no seu pipeline e pelo gtr-cli help em qualquer computador com o GUI Test Studio instalado.
Etapa 3: Adicione a etapa de build no TeamCity
Crie uma configuração de build para o seu repositório, adicione uma etapa de build e dê a ela o comando.Tanto uma etapa PowerShell quanto uma de linha de comando funcionam.No nosso exemplo, a etapa executa um pequeno script do repositório que inicia a loja e depois chama o gtr-cli.
Adicione um gatilho de VCS para que cada push em cada branch inicie um build.Essa é toda a configuração: o TeamCity não precisa de plugin, porque o gtr-cli fala a linguagem de log dele.
Etapa 4: Leia os resultados no TeamCity
Envie uma mudança e acompanhe.Cada navegador e dispositivo é um teste próprio, então você vê de relance onde falhou.
O log do build
O gtr-cli escreve uma linha por etapa e diz claramente o que falhou: qual asserção, em qual navegador e dispositivo, e por quê.
O build que falhou
A visão geral do build nomeia os testes que falharam e o motivo, sem abrir o log.
Os testes
A guia Tests lista todos os testes do build.Como cada resultado é informado como um teste, o TeamCity também guarda o histórico dele, a duração e com que frequência falhou.
As evidências
Os artefatos guardam tudo o que a execução viu: uma pasta por navegador e dispositivo com o vídeo da execução, o relatório dela e o relatório de bug, e para cada falha as imagens esperada e obtida com o que mudou contornado em vermelho.Abra a mesma execução no GUI Test Runner-Recorder para ver o Relatório de confiança completo.
Todos os navegadores e dispositivos em um só build
Um teste web pode ser criado uma vez e executado em vários navegadores e dispositivos: Chrome, Edge e Firefox, desktops, celulares e tablets.No pipeline, --branch all executa todos eles em um build, e os que não têm janela rodam lado a lado.Leia Todos os navegadores e dispositivos a partir de uma gravação.
Não usa o TeamCity?O mesmo comando em qualquer lugar
O gtr-cli não está preso a nenhuma ferramenta.
- É um programa que executa testes e devolve um código de saída, então qualquer coisa que consiga executar um comando consegue executar seus testes de ponta a ponta: um servidor de CI, uma tarefa agendada, um script de release.
- Testes funcionais, testes de regressão, smoke tests, testes de aceitação: seja qual for o nome que você dá aos testes que conduzem seu aplicativo pela interface, eles rodam do mesmo jeito.
| Sua ferramenta | O que acrescentar ao comando |
|---|---|
| TeamCity | --format teamcity |
| Azure DevOps | --format azure |
| GitHub Actions | --format github |
| Jenkins, GitLab, Bamboo e os demais | --junit results\junit.xml, lido pelo relatório de testes da ferramenta |
| Um script seu | Nada: leia o código de saída, ou o arquivo --json |
- name: End-to-end tests
run: gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --artifacts results\artifacts| Código de saída | Significa |
|---|---|
| 0 | Todos os testes passaram |
| 1 | Um teste falhou |
| 2 | O próprio comando estava errado |
| 3 | Um teste não pôde ser executado, por exemplo por um arquivo faltando |
| 4 | A execução foi interrompida |
Para onde ir em seguida
Pronto para gravar o seu primeiro teste?
Todos os recursos, por 15 dias.
Prefere ver no tipo de aplicativo que você testa?Agende uma chamada gratuita de 30 minutos com a nossa equipe.