Ejecute sus pruebas end-to-end en cada build: un ejemplo con TeamCity que funciona con cualquier herramienta de CI/CD
Automatización de pruebas end-to-end en su pipeline: añada sus pruebas de GUI Test Studio a un build de TeamCity en un paso con gtr-cli y lea cada prueba, los fallos, el vídeo y las imágenes en TeamCity.El mismo comando ejecuta sus pruebas de interfaz, funcionales y de regresión en Jenkins, GitHub Actions, GitLab, Azure DevOps o cualquier script.
7 min de lecturaPor el equipo de GUI Test Studio
Por qué ejecutar pruebas end-to-end en cada build
Una prueba end-to-end maneja su aplicación como lo haría un usuario: la abre, hace clic y escribe a lo largo de un flujo completo, y verifica lo que muestra la pantalla al final.Es la prueba que detecta lo que las pruebas unitarias no pueden: un botón roto, un formulario que ya no se envía, una página que perdió su contenido.
Una prueba end-to-end que solo se ejecuta cuando alguien se acuerda de lanzarla detecta esos problemas tarde.Ejecútela en cada cambio y una regresión se detecta minutos después de subirla, mientras el cambio sigue fresco en la mente del desarrollador.
GUI Test Studio incluye un ejecutor de línea de comandos justo para eso: gtr-cli.Se instala con las aplicaciones.Ejecuta las pruebas end-to-end de interfaz gráfica que grabó y editó, sin abrir ninguna ventana, y responde como espera un pipeline: un código de salida, un archivo JUnit, un registro que su herramienta de CI entiende.
Un desarrollador sube un cambio
Cualquier rama
TeamCity inicia una compilación
Un solo paso de compilación
gtr-cli ejecuta las pruebas
En la pantalla de la máquina de compilación, o sin ventana
Usted lee el resultado
Pruebas, registro, vídeo e imágenes
Lo que necesita
| Qué | Por qué | Dónde conseguirlo |
|---|---|---|
| Una prueba hecha con GUI Test Studio | La prueba end-to-end que ejecuta el pipeline, guardada en su repositorio como cualquier archivo | Su primera prueba, paso a paso |
| Una máquina de compilación con Windows y GUI Test Studio instalado | gtr-cli viene con el instalador y reproduce la prueba en esa máquina | Instalar y configurar |
| TeamCity (u otra herramienta de CI) | Inicia una compilación con cada cambio y muestra sus resultados | TeamCity de JetBrains |
Paso 1: preparar la máquina de compilación
Una prueba end-to-end reproduce clics y escritura en una pantalla real, así que el agente de build necesita un escritorio en el que trabajar.
- 1
Instalar GUI Test Studio e iniciar sesión una vez
El instalador añade gtr-cli al PATH.Inicie sesión en las aplicaciones una vez en esa máquina, con la cuenta con la que se ejecuta el agente.
- 2
Ejecutar el agente en una sesión de Windows iniciada
Inicie el agente de TeamCity desde una sesión de usuario iniciada, no como un servicio de Windows: un servicio no tiene pantalla en la que reproducir una prueba.Conserve el tamaño de pantalla y la escala de la grabación.Consulte Preparar la máquina de compilación.
- 3
O ejecutar las pruebas web sin ventana
Una prueba de una aplicación web puede ejecutarse sin ninguna ventana del navegador, con
--headless on.Entonces no necesita una pantalla libre, y varios navegadores y dispositivos se ejecutan en paralelo.
Paso 2: componer el comando
No tiene que aprenderse las opciones.En cualquiera de las dos aplicaciones, abra la ventana Línea de comandos y CI/CD, marque lo que quiera y copie el comando, o el fragmento ya preparado para su herramienta de CI con sus rutas reales.
Este es el comando que ejecuta nuestro pipeline de ejemplo:
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| Opción | Qué hace |
|---|---|
| --branch all | Ejecuta la prueba en cada navegador y dispositivo para el que se hizo |
| --countdown 0 | Empieza de inmediato: no hay nadie ante la máquina de compilación que tenga que soltar el ratón |
| --format teamcity | Escribe cada prueba y cada fallo en el propio lenguaje de registro de TeamCity |
| --junit / --json | Escribe los resultados en archivos que cualquier herramienta puede leer |
| --artifacts | Conserva el vídeo de la ejecución, su informe y las imágenes de cada fallo |
| --bug-report pdf | Escribe un informe de defecto ya rellenado por cada prueba fallida |
Cada opción se explica en Ejecutar pruebas en su pipeline y con gtr-cli help en cualquier equipo en el que esté instalado GUI Test Studio.
Paso 3: añadir el paso de compilación en TeamCity
Cree una configuración de compilación para su repositorio, añada un paso de compilación y dele el comando.Sirve tanto un paso PowerShell como uno Command Line.En nuestro ejemplo, el paso ejecuta un pequeño script del repositorio que inicia la tienda y luego llama a gtr-cli.
Añada un desencadenador VCS para que cada subida a cualquier rama inicie una compilación.Esa es toda la configuración: TeamCity no necesita ningún complemento, porque gtr-cli habla su lenguaje de registro.
Paso 4: leer los resultados en TeamCity
Suba un cambio y observe.Cada navegador y dispositivo es una prueba propia, así que ve de un vistazo dónde falló.
El registro de compilación
gtr-cli escribe una línea por paso y dice con claridad qué falló: qué comprobación, en qué navegador y dispositivo, y por qué.
La compilación fallida
La vista general de la compilación nombra las pruebas fallidas y su motivo, sin abrir el registro.
Las pruebas
La pestaña Tests enumera todas las pruebas de la compilación.Como cada resultado se notifica como una prueba, TeamCity guarda también su historial, su duración y con qué frecuencia falló.
Las evidencias
Los artefactos contienen todo lo que vio la ejecución: una carpeta por navegador y dispositivo con el vídeo de la ejecución, su informe y su informe de defecto y, por cada fallo, las imágenes esperada y encontrada con lo que cambió resaltado en rojo.Abra la misma ejecución en GUI Test Runner-Recorder para ver el Informe de confianza completo.
Todos los navegadores y dispositivos en una sola compilación
Una prueba web puede hacerse una vez y ejecutarse en varios navegadores y dispositivos: Chrome, Edge y Firefox, escritorios, teléfonos y tabletas.En el pipeline, --branch all los ejecuta todos en una sola compilación, y los que no tienen ventana se ejecutan en paralelo.Lea Cada navegador y cada dispositivo a partir de una sola grabación.
¿No usa TeamCity?El mismo comando en cualquier parte
gtr-cli no está atado a ninguna herramienta.Es un programa que ejecuta pruebas y devuelve un código de salida, así que todo lo que pueda ejecutar un comando puede ejecutar sus pruebas end-to-end: un servidor de CI, una tarea programada, un script de release.Pruebas funcionales, de regresión, smoke tests, pruebas de aceptación: como quiera que llame a las pruebas que manejan su aplicación a través de su interfaz, se ejecutan igual.
| Su herramienta | Qué añadir al comando |
|---|---|
| TeamCity | --format teamcity |
| Azure DevOps | --format azure |
| GitHub Actions | --format github |
| Jenkins, GitLab, Bamboo y los demás | --junit results\junit.xml, que lee el informe de pruebas de la herramienta |
| Un script propio | Nada: lea el código de salida, o el archivo --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 salida | Significa |
|---|---|
| 0 | Todas las pruebas se superaron |
| 1 | Una prueba falló |
| 2 | El propio comando era incorrecto |
| 3 | Una prueba no se pudo ejecutar, por ejemplo por un archivo que falta |
| 4 | Se detuvo la ejecución |
Adónde ir después
¿Listo para grabar su primera prueba?
Todas las funciones, durante 15 días.
¿Prefiere verlo con el tipo de aplicación que prueba?Reserve una llamada gratuita de 30 minutos con nuestro equipo.