Pruebas de extremo a extremo frente a pruebas de integración: qué detecta cada una (con ejemplos)
Pruebas de extremo a extremo frente a pruebas de integración: qué ve cada una, el error del pago que solo detecta una prueba de la pantalla, la pirámide de pruebas y cuántas pruebas de extremo a extremo necesita.
10 min de lecturaPor Ait Nohaila, Representante de desarrollo de negocio
Pruebas de extremo a extremo frente a pruebas de integración: la diferencia en una línea
Definición
Las pruebas de integración comprueban que dos o más partes de una aplicación funcionan juntas en su unión, a través del código o de una API, mientras que las pruebas de extremo a extremo comprueban toda la aplicación a través de su pantalla, tal como la recorre un usuario.
- Una prueba de integración hace una pregunta al código: ¿devolvió el servicio del carrito el total que espera el pago?
- Una prueba de extremo a extremo hace una pregunta a la pantalla: ¿ve el usuario el total correcto donde lo espera?
- Las dos hacen falta, y ninguna puede responder a la pregunta de la otra.
Las dos se confunden porque ambas prueban más de una pieza a la vez.La diferencia está en dónde se sitúa la prueba.Una prueba de integración se sitúa en la unión entre dos partes y observa lo que la cruza.Una prueba de extremo a extremo se sitúa donde se sitúa el usuario, delante de la pantalla, y observa el resultado de todo lo que hay detrás.
Las pruebas de integración comprueban la unión.Una prueba de extremo a extremo comprueba lo que se dibuja.
Pruebas E2E y pruebas de integración, lado a lado
Así se comparan las dos en las preguntas que se hace un equipo cuando decide qué automatizar.
| Pregunta | Pruebas de integración | Pruebas de extremo a extremo |
|---|---|---|
| Alcance | Dos o más partes de la aplicación, juntas: un servicio y su base de datos, la API y el módulo que la llama. | Toda la aplicación tal como la encuentra el usuario, con cada parte de la que depende: la pantalla, los servicios que hay detrás, a menudo otros sistemas como un proveedor de pagos. |
| Punto de entrada | El código o una API: la prueba llama a una función o envía una petición y lee la respuesta. | La pantalla: la prueba hace clic, escribe y lee lo que se dibuja, como lo haría una persona. |
| Qué encuentra | Una parte que ya no responde como espera la parte siguiente: un campo renombrado, un estado incorrecto, un registro que falta. | Un recorrido que ya no da al usuario el resultado correcto: un total incorrecto en la pantalla, un botón que no hace nada, una página que no se abre. |
| Velocidad | De milisegundos a segundos por prueba.Cientos pueden ejecutarse en cada commit. | De segundos a minutos por recorrido.Una suite de unas decenas se ejecuta en cada compilación o cada noche. |
| Coste | Barata de escribir para el desarrollador que conoce la unión, y barata de ejecutar. | Costosa cuando es código: cada rediseño rompe selectores.Barata cuando se graba desde la pantalla y se mantiene sin código. |
| Quién la escribe | Los desarrolladores, a medida que construyen cada unión. | Testers, ingenieros de QA y product owners que saben qué espera el usuario; también los desarrolladores. |
| Cuándo se ejecuta | En cada commit, en la compilación, antes de fusionar nada. | En cada compilación o pull request para unos pocos recorridos críticos, cada noche para toda la suite, en cada navegador y dispositivo antes de una versión. |
El error que una prueba de integración no puede ver
Tomemos un proceso de pago.El servicio del carrito suma los artículos, el servicio de precios aplica la tarifa de envío, y la página de pago dibuja el resultado en tres filas: Subtotal, Envío y Total.Un día un desarrollador ordena la plantilla del pago.Una fila se mueve.El código que hay detrás no se toca.
La prueba de integración pide a la API el total del carrito y lo compara con el número que espera.Recibe 48.90, exactamente lo correcto, y se supera.Cada servicio hizo su trabajo, y la unión entre ellos está sana.
La prueba de extremo a extremo hace lo que hace un cliente: añadir dos artículos, abrir el pago y leer el total antes de pagar.En la pantalla, la fila Total está vacía, y 48.90 aparece ahora junto a Envío.Un cliente lee que el envío cuesta 48.90 y que no hay nada que pagar.Es un error que nadie discutiría, y ninguna prueba de integración puede verlo, porque una prueba de integración nunca mira la página.
El mismo patrón esconde muchos de los errores que llegan a los usuarios.
- Un total calculado en dólares y dibujado con el signo del euro.
- Un botón Pagar empujado fuera de la vista por un banner nuevo.
- Un mensaje de confirmación que aparece detrás de la ventana.
- Una etiqueta demasiado larga para su campo tras una traducción.
- En todos los casos, los datos son correctos y la pantalla está mal.
Es la misma brecha que describe desde el otro lado los errores visuales que sus pruebas automatizadas no ven: una comprobación que pregunta si un elemento existe no puede saber si una persona puede verlo, leerlo o hacer clic en él.
La pirámide de pruebas: dónde se gana su sitio cada nivel
La pirámide de pruebas es la imagen habitual de cómo debe dimensionarse una suite.Su forma tiene que ver con el coste, no con la importancia: una prueba unitaria se ejecuta en un milisegundo y puede escribirse para cada caso, una prueba de extremo a extremo arranca la aplicación real y sigue un recorrido, así que hay menos.
La pirámide de pruebas: cuántas pruebas, y qué ve cada nivel
Pruebas unitarias
Una prueba unitaria se gana su sitio al detectar un cálculo erróneo en el momento en que se escribe, en la función que lo hizo.
Pruebas de integración
Una prueba de integración se gana su sitio al detectar una unión que se rompió: un campo renombrado en un servicio y que otro sigue esperando.
Pruebas de extremo a extremo
Una prueba de extremo a extremo se gana su sitio al detectar lo que solo muestra la pantalla: el número correcto en el campo equivocado, el botón en el que no se puede hacer clic, la página que nunca se abre.
Las pruebas de sistema se sitúan junto a la cima de la pirámide, y muchos equipos usan los dos nombres para lo mismo.La distinción útil: las pruebas de sistema comprueban la aplicación ensamblada contra sus requisitos, las pruebas de extremo a extremo siguen el recorrido de un usuario a través de todo lo que toca ese recorrido.Qué son las pruebas de extremo a extremo recorre el cuadro completo.
Pruebas de integración frente a pruebas de extremo a extremo: cuándo usar cada una
La elección rara vez es una u otra.Cada nivel es el más barato para un tipo distinto de pregunta, y un equipo que sabe qué pregunta está haciendo pone la prueba en el sitio correcto.
Use una prueba de integración cuando la pregunta trata de una unión.
- ¿Sigue respondiendo la API con la forma que espera el módulo?
- ¿Llega el pedido a la base de datos con todos los campos?
- ¿Vuelve el rechazo del proveedor de pagos como el error que maneja el código?
- Son muchos casos pequeños, que conviene comprobar rápido, en cada commit, por el desarrollador que construyó la unión.
Use una prueba de extremo a extremo cuando la pregunta trata del resultado del usuario.
- ¿Puede un cliente iniciar sesión, encontrar un producto, pagar y ver la confirmación con el número de pedido correcto?
- ¿Sigue abriéndose con las columnas correctas el informe que el equipo financiero exporta cada lunes?
- Son unos pocos recorridos completos, comprobados donde los comprobaría el usuario, en cada compilación.
Use ambas donde haya dinero, datos o inicio de sesión en juego.
- El pago de arriba necesita sus pruebas de integración, para que un total incorrecto se detecte en la unión que lo produjo, y su prueba de extremo a extremo, para que un total correcto dibujado en el sitio equivocado se detecte también.
- Ninguna podría haber sustituido a la otra ese día.
Los dos niveles son pruebas de regresión: se ejecutan de nuevo después de cada cambio para demostrar que nada de lo que funcionaba se ha roto.Qué son las pruebas de regresión explica cuándo ejecutar cada una y por qué se abandonan las suites cuando cuestan más de lo que detectan.
¿Cuántas pruebas de extremo a extremo necesita?
Menos de las que cree, y mejor elegidas.La cima de la pirámide no es un sitio para enumerar todas las pantallas.Es un sitio para los recorridos que más dolerían si se rompieran, cada uno seguido desde su primer clic hasta el resultado que el usuario venía a buscar, y cada uno verificando ese resultado.
La mayoría de las aplicaciones quedan cubiertas con una lista corta.
- 1El registro y el inicio de sesión, incluido el error cuando la contraseña es incorrecta.
- 2La tarea principal para la que existe la aplicación: hacer un pedido, reservar una cita, crear un cliente, presentar una reclamación.
- 3El pago, hasta la confirmación y su número de pedido.
- 4La búsqueda o la lista desde la que un usuario empieza cada día.
- 5La exportación o el informe del que depende un cliente.
- 6Cada recorrido que se rompió una vez y llegó a los usuarios.
Entre cinco y quince recorridos como estos, ejecutados en cada compilación, detectan la mayor parte de lo que deja pasar una suite de integración.Cada uno termina con una comprobación de lo que muestra la pantalla: el total, la confirmación, el archivo exportado.Una prueba que recorre un camino a golpe de clic y no verifica nada demuestra poco.
Qué verificar en cada paso es una elección que merece hacerse a propósito: una imagen del elemento, sus palabras, o lo que apareció en la pantalla.Elija qué verifica una prueba lo explica paso a paso.
Automatizar el nivel de extremo a extremo sin código
El nivel de extremo a extremo es el que la mayoría de los equipos deja más delgado, porque ha sido el más costoso de mantener: las pruebas en código encuentran los elementos mediante selectores, y cada rediseño los rompe.GUI Test Studio saca el código de ese nivel.Prueba aplicaciones web, aplicaciones de escritorio de Windows, teléfonos Android y videojuegos a través de su pantalla, como lo hace un usuario.
Grábelo, o descríbalo
Haga clic en Grabar y recorra el camino en su aplicación real: añada los artículos, abra el pago, lea el total.Los clics, lo escrito y las comprobaciones de lo que apareció se convierten en una prueba, sin código que escribir.También puede describir el recorrido en una petición a su asistente de IA, y la prueba se crea por usted.Su primera prueba, paso a paso lleva unos diez minutos.
La prueba comprueba lo que muestra la pantalla, no el código que hay detrás.
- Una aserción visual compara la imagen de un elemento, una aserción de texto lee sus palabras, y una comprobación de lo que apareció detecta el diálogo o el mensaje que abrió el paso.
- El GTS Engine + AI encuentra cada elemento primero mediante la información de accesibilidad de la aplicación, y visualmente cuando la aplicación no lo dice.
Ejecútelo en cada compilación
gtr-cli ejecuta la suite de extremo a extremo en una máquina de compilación de Windows y responde como espera un pipeline: un recorrido fallido hace fallar la compilación, un archivo JUnit llena la pestaña de pruebas, y cada imagen de lo que falló se conserva junto a los resultados de integración.
gtr-cli run tests\journeys --countdown 0 --junit results\junit.xml --artifacts results\artifactsFunciona en TeamCity, Jenkins, GitHub Actions, GitLab y Azure DevOps: vea Ejecutar pruebas en su pipeline.
El Informe de confianza dice qué cambió
Cada ejecución termina en un Informe de confianza.Para cada comprobación, dice si el elemento se encontró y si sigue teniendo el aspecto con que se grabó, con las imágenes esperada y encontrada lado a lado y la diferencia delimitada.Para el pago de arriba, muestra la fila Total vacía y 48.90 una fila más arriba: exactamente lo que un tester habría escrito en el informe de defecto.
El ruido se ignora y las regresiones se detectan.
- Las diferencias leves de renderizado que ninguna persona notaría no se cuentan, mientras que una palabra cambiada, una insignia que falta o un número en la fila equivocada hacen fallar la comprobación.
- Cuando una imagen difiere, el Análisis inteligente con IA puede echar un segundo vistazo y decir qué cambió en palabras sencillas, en la nube con su propia clave o en su propio equipo con un modelo de IA local, uno que proporcionamos nosotros o el suyo.
Se envía un cambio
Se ordena la plantilla del pago
Se ejecuta la compilación
Pruebas de integración, luego gtr-cli
Informe de confianza
El total está en la fila equivocada
Corregido antes de fusionar
El usuario nunca lo vio
Lo esencial
- 1Las pruebas de integración comprueban la unión entre las partes; una prueba de extremo a extremo comprueba lo que se dibuja para el usuario.
- 2El mismo error puede estar en verde y en rojo a la vez: la API devuelve el total correcto, la pantalla lo muestra en el campo equivocado.
- 3La forma de la pirámide tiene que ver con el coste, no con la importancia: muchas pruebas rápidas abajo, unos pocos recorridos completos arriba, cada uno detectando lo que los demás no pueden.
- 4Use ambas donde haya dinero, datos o inicio de sesión en juego, y elija el nivel según quién escribiría el informe de defecto: un usuario o un desarrollador.
- 5Entre cinco y quince recorridos, cada uno verificando su resultado, cubren la mayor parte de lo que deja pasar la suite de integración, y pueden grabarse sin código.
Preguntas
¿Cuál es la diferencia entre las pruebas de extremo a extremo y las pruebas de integración?
Las pruebas de integración comprueban que dos o más partes de una aplicación funcionan juntas en su unión, normalmente a través del código o de una API.Las pruebas de extremo a extremo comprueban toda la aplicación a través de su pantalla, tal como la recorre un usuario.Una prueba de integración puede superarse mientras la pantalla muestra algo incorrecto.
¿Las pruebas de extremo a extremo son lo mismo que las pruebas de sistema?
Se solapan, y muchos equipos usan las palabras para lo mismo.Las pruebas de sistema comprueban la aplicación completa y ensamblada contra sus requisitos.Las pruebas de extremo a extremo siguen el recorrido de un usuario desde el primer clic hasta el resultado, a través de cada parte que toca el recorrido, otros sistemas incluidos.
¿Pueden las pruebas de integración sustituir a las pruebas de extremo a extremo?
No.Las pruebas de integración demuestran que las partes se entienden entre sí, no que un usuario obtiene el resultado correcto en la pantalla.Un total puede calcularse bien en cada servicio y aun así dibujarse en el campo equivocado o quedar oculto tras un banner, y solo una prueba que mira la pantalla ve eso.
¿Qué debe escribirse primero, pruebas de integración o pruebas de extremo a extremo?
Los desarrolladores escriben las pruebas de integración a medida que construyen cada unión, así que esas suelen venir primero.Las primeras pruebas de extremo a extremo corresponden a los recorridos que más dolerían si se rompieran, como el inicio de sesión y el pago, y pueden grabarse en cuanto esos recorridos funcionan.
¿Cuántas pruebas de extremo a extremo debe tener un proyecto?
Menos de las que cree, y mejor elegidas.Entre cinco y quince recorridos cubren lo que la mayoría de las aplicaciones no puede permitirse romper: el registro, el inicio de sesión, la tarea principal, el pago, la exportación de la que dependen los clientes.Cada una sigue un recorrido hasta el resultado que el usuario venía a buscar, y verifica ese resultado.
¿Por qué las pruebas de extremo a extremo son más lentas que las pruebas de integración?
Una prueba de extremo a extremo arranca la aplicación real, maneja sus pantallas y espera a que cada una responda, así que un recorrido tarda de segundos a minutos donde una prueba de integración tarda milisegundos.Por eso las pruebas de extremo a extremo cubren unos pocos recorridos importantes, y las pruebas de integración cubren muchos casos.
¿Qué es la pirámide de pruebas?
La pirámide de pruebas es una forma de dimensionar una suite de pruebas: muchas pruebas unitarias rápidas en la base, menos pruebas de integración en el medio, y un número pequeño de pruebas de extremo a extremo en la cima.Cada nivel detecta lo que los niveles inferiores no pueden, y el nivel superior es el único que ve lo que ve el usuario.
¿Quién escribe las pruebas de extremo a extremo?
Cualquiera que sepa qué espera el usuario puede hacerlo, cuando la herramienta no necesita código.Con GUI Test Studio, un tester o un product owner graba un recorrido usando la aplicación, o lo describe en una petición, y la prueba se ejecuta en cada compilación con gtr-cli.
TeamCity, Jenkins, GitHub, GitLab y Azure DevOps son marcas de sus respectivos propietarios.
¿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.