Pruebas inestables y falsos positivos: por qué fallan sin motivo
Pruebas inestables y falsos positivos: por qué fallan con una aplicación que funciona y cómo evitarlos sin pasar por alto regresiones reales.
12 min de lecturaPor el equipo de GUI Test Studio
Una compilación en rojo debería significar una sola cosa: la aplicación está rota.Con demasiada frecuencia significa otra cosa: una prueba hizo clic demasiado pronto, una fuente se mostró con un tono distinto, un indicador de carga aún giraba.Son las pruebas inestables y los falsos positivos, y son una de las principales razones por las que los equipos dejan de confiar en sus pruebas de extremo a extremo.
Esta guía explica de dónde vienen en las pruebas programadas y visuales, y cómo detener los falsos positivos sin dejar pasar los bugs reales.
¿Qué son las pruebas inestables (flaky) y los falsos positivos?
Un falso positivo es una prueba que falla mientras la aplicación funciona como debe.Los testers también lo llaman falso fallo o falsa alarma.La prueba da la alarma, alguien investiga y no hay nada mal.
Una prueba inestable (flaky) es una prueba que se supera y falla con el mismo código, sin que nada cambie entre las ejecuciones.Cada fallo inestable es un falso positivo.Pero no todo falso positivo es inestable: una prueba que falla siempre porque su imagen esperada está desactualizada está mal, no es inestable.
El error contrario es el falso negativo: una prueba que se supera mientras un bug real está en la pantalla.Es el más peligroso de los dos, porque nadie mira dos veces una prueba en verde.
| Lo que pasó | Su nombre |
|---|---|
| La prueba falla, la aplicación funciona | Un falso positivo, falso fallo o falsa alarma |
| La prueba se supera, la aplicación está rota | Un falso negativo: un bug no detectado |
| Mismo código, a veces en rojo, a veces en verde | Una prueba inestable |
| La prueba falla, la aplicación está rota | Un fallo verdadero: la prueba hizo su trabajo |
Lo que los falsos positivos le cuestan a un equipo
Una falsa alarma cuesta una investigación.Alguien abre los registros, vuelve a ejecutar la prueba y no encuentra nada.
El coste real llega después.Cuando la mayoría de las compilaciones en rojo son ruido, la gente deja de leerlas: es la fatiga de alertas.Luego llegan los hábitos que ocultan bugs: volver a ejecutar una prueba hasta que se pone en verde, aceptar cada nueva captura de pantalla como línea base sin mirarla, desactivar la prueba que siempre falla.
Cada uno de estos hábitos convierte el falso positivo de hoy en el falso negativo de mañana.El bug para el que se escribió la prueba pasa sin más, porque ya nadie cree en la prueba.
¿Qué vuelve inestables las pruebas de extremo a extremo?
Las pruebas de extremo a extremo manejan toda una aplicación a través de su interfaz, así que se encuentran con todo lo que encuentra un usuario real: servidores lentos, animaciones, otras ventanas.Las pruebas programadas añaden causas propias.
| Causa | Lo que pasa |
|---|---|
| Tiempos y esperas | La prueba hace clic antes de que el botón esté listo, o una pausa fija es demasiado corta un día de mucha carga. |
| Elementos obsoletos | La página se volvió a dibujar entre el momento de encontrar un elemento y el clic, así que la prueba tiene un elemento que ya no existe. |
| Selectores que cambiaron | Un desarrollador cambió el nombre de una clase o una actualización del framework cambió la estructura de la página, y el localizador no encuentra nada, o encuentra el elemento equivocado. |
| Datos de prueba | Una prueba anterior dejó un registro, o dos pruebas cambian la misma cuenta al mismo tiempo. |
| Entorno | Otro tamaño de pantalla, otra versión del navegador, otro sistema operativo o una máquina sobrecargada. |
| Animaciones | El elemento se encuentra mientras todavía se desliza o aparece con un fundido. |
| Red | Una petición lenta o fallida deja la página a medio cargar, o un script de terceros llega tarde. |
Los tiempos van primero por una razón.La propia documentación de Selenium llama a la carrera entre la prueba y el navegador una de las principales causas de las pruebas inestables.
Por qué las pruebas de regresión visual dan falsos positivos
Las pruebas de regresión visual comparan una imagen de la aplicación con una imagen de línea base aprobada.Detectan lo que las aserciones programadas no ven: un color incorrecto, una etiqueta que se superpone a otra, un icono que falta.También ven diferencias que nadie llamaría un cambio.
| Origen del ruido | Por qué difieren los píxeles |
|---|---|
| Suavizado de bordes | Los bordes del texto y de las formas se suavizan con colores intermedios, y el suavizado varía de una máquina a otra. |
| Renderizado de fuentes por subpíxeles | En Windows, el texto se dibuja con leves bordes de color que dependen de la pantalla y de su configuración. |
| Ruido de vídeo y de compresión | Una imagen tomada de una grabación, o comprimida, pierde un detalle fino de color que la pantalla en vivo conserva. |
| Tarjetas gráficas y controladores | Dos máquinas pueden mezclar y escalar la misma página de forma un poco distinta. |
| Contenido dinámico | Una fecha, un contador, un anuncio o un feed en directo cambia en cada ejecución. |
| Punteros y cursores de texto | El puntero del ratón o un cursor de texto parpadeante aparece en una imagen y no en la otra. |
| Estados al pasar el puntero | El puntero se quedó sobre un botón durante una ejecución, así que el botón está resaltado en una sola imagen. |
| Una página que aún se está cargando | La captura se tomó antes de que terminara una imagen, una fuente o una transición. |
Una comparación estricta, píxel a píxel, falla en cada uno de estos casos.Una comparación laxa deja pasar bugs reales.El arte de las pruebas visuales consiste en distinguir los dos.
Cómo corrigen hoy los equipos las pruebas inestables
En las pruebas programadas
Playwright espera antes de cada acción a que el elemento sea visible, esté estable, esté habilitado y no lo tape otro elemento, y si no, falla al agotarse el tiempo de espera.
Cypress reintenta sus consultas y sus aserciones hasta que se cumplen, durante un máximo de 4 segundos por defecto.También puede reintentar una prueba fallida completa, algo desactivado por defecto.
Selenium ofrece esperas explícitas que consultan la aplicación hasta que se cumple una condición, y su documentación desaconseja mezclarlas con esperas implícitas.
Los reintentos también sirven para detectar la inestabilidad.Playwright marca como inestable (flaky) una prueba que falló y luego se superó en un reintento, y Cypress Cloud marca una prueba así con una insignia Flaky.Un reintento pone la compilación en verde, pero no elimina la causa.
En las pruebas visuales
En Playwright, toHaveScreenshot admite un umbral de color por píxel, 0.2 por defecto, y o bien un maxDiffPixels absoluto, o bien un maxDiffPixelRatio.Puede enmascarar zonas dinámicas, y por defecto detiene las animaciones y oculta el cursor de texto.
BackstopJS admite un porcentaje de píxeles distintos, 0.1 por defecto, y puede ocultar o quitar los elementos que usted indique antes de tomar sus capturas.
Chromatic ignora por defecto los píxeles suavizados, y su diffThreshold, 0.063 por defecto, fija cuánto cambio tolera.
Argos estabiliza cada captura de pantalla por defecto: espera a las fuentes y a las imágenes, oculta el cursor de texto y las barras de desplazamiento, y señala las capturas que cambian de una ejecución a otra.
Percy congela las animaciones y otros elementos dinámicos, y los cambios se aprueban por compilación, por grupo o de captura en captura.Su Visual Review Agent resalta los cambios que considera significativos.
Applitools Eyes compara con niveles de coincidencia.Strict intenta ignorar lo que el ojo humano no vería, Layout solo comprueba la disposición, y Dynamic acepta cualquier fecha, dirección de correo o URL válida.
Cada una de estas opciones ayuda.Cada una le pide además elegir un número, una máscara o un nivel, prueba a prueba, y revisar a mano las imágenes nuevas.Para ver estas herramientas una junto a otra, lea el estudio comparativo.
Por qué una tolerancia más amplia no es la respuesta
Una tolerancia es una promesa: tanta diferencia es ruido.La cuestión es en qué se mide ese tanto.
Una proporción crece con la imagen.En una pantalla completa de 1920 × 1080 píxeles, el 0.1 % son unos 2000 píxeles, más que una palabra cambiada.En un botón de 100 × 40 píxeles, son 4 píxeles, menos que un solo borde que se renderizó distinto.
Un recuento absoluto no crece con la imagen, pero suma el ruido repartido por toda la imagen como si fuera un único cambio.Una máscara oculta el ruido, y también oculta cualquier bug que haya dentro de la máscara.
Cómo GUI Test Studio detiene los falsos positivos sin dejar pasar bugs
GUI Test Studio es una suite de automatización de pruebas de extremo a extremo para aplicaciones web, aplicaciones de escritorio de Windows, Android y juegos.Usted graba una prueba una vez, o la describe en una petición, la edita en una línea de tiempo y la ejecuta en cada compilación.Sus comprobaciones siguen una regla: una prueba falla cuando una persona vería un problema, y solo entonces.
Encontrar
Preguntar a la aplicación, o encontrar el elemento a la vista
Esperar
A la pantalla, nunca a un temporizador
Comparar
Contar lo que cambió claramente, y dónde
Decidir
Análisis inteligente con IA, si lo activa
Informe
Lo que cambió, con palabras sencillas
Los elementos se encuentran de dos maneras, sin selectores que se rompan
El GTS Engine + AI pregunta primero a la aplicación dónde está un elemento, a través de su información de accesibilidad en Windows, o de los propios elementos de la página en un navegador.Cuando la aplicación no lo dice, encuentra el elemento a la vista, en la pantalla.No hay ningún localizador que escribir, así que una clase renombrada o un framework nuevo no rompen una prueba.Consulte cómo encuentra GUI Test Studio cada elemento.
Las comprobaciones esperan a la pantalla, nunca a un temporizador
Cada comprobación sigue buscando hasta que lo que espera está en la pantalla, dentro de su tiempo de espera de 5 segundos por defecto, y la prueba continúa en cuanto aparece.Una aserción de ausencia visual espera a que desaparezca un indicador de carga, de modo que a una página lenta se la espera, no se la adivina.
Cuando una aserción visual o una aserción de texto no ha encontrado su elemento en su zona de búsqueda tras un segundo, busca también en toda la pantalla, así que una ventana que se movió no hace fallar la prueba.Antes de que empiece una ejecución, GUI Test Runner-Recorder compara su pantalla con el primer momento de la grabación y retiene la ejecución cuando la aplicación está en otra página.Consulte los ajustes de una comprobación.
La Fase de verificación cuenta lo que cambió, y dónde
Una vez encontrado el elemento, la Fase de verificación lo compara con lo que usted espera.Cuenta los píxeles que cambiaron claramente en la pequeña zona del elemento donde más se concentran: un número absoluto, nunca un porcentaje de la imagen.
El ruido está disperso: un borde más suave aquí, un tono más claro allá.Un cambio real se concentra en un sitio: una letra, un dígito, un icono.Por eso la misma regla sirve para un icono pequeño y para un cuadro de diálogo entero.
| En la pantalla | Lo que hace la Fase de verificación |
|---|---|
| Un píxel apenas distinto | Nunca se cuenta por sí solo, mientras que una letra que cambió de mayúscula a minúscula sigue haciendo fallar la comprobación |
| Bordes suavizados | Los tolera Ignorar pequeños artefactos de renderizado, activado por defecto, mientras que un icono que falta sigue haciendo fallar la comprobación |
| Detalle de color que solo la pantalla en vivo puede conservar | No se cuenta, mientras que un botón o una insignia que cambió de color sigue haciendo fallar la comprobación |
| Un cursor de texto parpadeante, aislado | No se cuenta, mientras que una letra cambiada a su lado sigue haciendo fallar la comprobación |
| Un dígito o una palabra cambiados | Hace fallar la comprobación, donde ocurrió |
Cada comprobación tiene una Exigencia de verificación: Exacta, Estricta, Estándar o Flexible.Estándar sirve para los botones, etiquetas e iconos de todos los días, y Flexible para zonas grandes y pantallas cargadas.Consulte las comprobaciones visuales.
El momento adecuado, con el puntero donde estaba
Un elemento se encuentra a menudo cuando la pantalla aún se está asentando: un menú que aparece con un fundido, una página que aún se carga.La Pasada de precisión mejorada mira los fotogramas que siguen a la coincidencia, se queda con aquel en el que el elemento se ve mejor, y se detiene donde empieza el siguiente paso de la prueba.Consulte la Pasada de precisión mejorada.
En una prueba grabada, la ejecución vuelve a poner el puntero del ratón donde estaba cuando se tomó la imagen.Así un botón aparece resaltado en la ejecución exactamente cuando lo estaba en la grabación.
Una prueba que acaba de grabar, y que aún no ha editado, recibe una ayuda extra.Cuando un elemento no aparece tal como se grabó, la ejecución ajusta la prueba de forma inteligente para encontrarlo, y nunca lo hace para ocultar una diferencia real.
Diferente a propósito: los perfiles de línea base
Algunas diferencias son reales y deseadas: el modo oscuro, la pantalla de un portátil en lugar de un monitor 4K, otra versión de Windows, la aplicación en otro idioma.Un perfil de línea base guarda una versión esperada de una comprobación por entorno, de modo que una sola prueba sirve para todos.Dónde buscar, cuánto esperar y qué exigencia aplicar se comparten entre todas las versiones.Consulte los perfiles de línea base.
El Análisis inteligente con IA da el veredicto final
Cuando una comprobación encuentra píxeles cambiados, el Análisis inteligente con IA puede echar un segundo vistazo y decidir, con un modelo en la nube y su propia clave, o un modelo de IA local en su propio ordenador, uno nuestro o uno suyo.Está desactivado hasta que usted lo activa.
Da por superada una comprobación cuando solo encuentra diferencias menores que un usuario quizá no note, mientras que una palabra, un número o un valor que cambia, o un icono o una insignia que falta, nunca es menor y hace fallar la comprobación.El informe dice de cuál se trataba.
El puntero del ratón y el cursor de texto parpadeante nunca cuentan como diferencia, mientras que una letra o un icono que cambió sí cuenta.También puede dar a una comprobación unas Instrucciones para la IA con sus propias palabras, por ejemplo: la fecha de la esquina cambia cada día.Consulte el Análisis inteligente con IA.
Un informe que dice lo que cambió
El Informe de confianza muestra cada comprobación visual en dos fases.La Fase de búsqueda responde si se encontró el elemento, y la Fase de verificación si se ve como se espera.Pulso resalta en la pantalla lo que cambió, y el veredicto lo dice con palabras sencillas.
Sus eslabones más débiles señalan las comprobaciones que se superaron por el margen más pequeño, las que tienen más probabilidades de fallar después.El Historial muestra cuándo empezó a fallar una comprobación.Cuando un cambio es deseado, acepta el nuevo aspecto en el informe, y no se escribe nada hasta que guarda.Consulte el Informe de confianza.
Detener o continuar: usted decide lo que significa un fallo
Cada comprobación indica qué hace su fallo: detener la prueba, o continuarla.Una comprobación de la que dependen los clics siguientes detiene la prueba por defecto, porque hacer clic sin ella daría en el sitio equivocado.Una comprobación que solo confirma lo que hay en la pantalla continúa, de modo que una ejecución informa de cada problema que encuentra.
En un pipeline, gtr-cli puede ejecutar una vez más una prueba fallida con su opción de reintentos.Úsela como último recurso: lo que hay que corregir son las causas anteriores.
Una lista de comprobación contra los falsos positivos
Do
- Esperar una condición: un elemento, un texto, un indicador de carga que desaparece.
- Mantener cada comprobación visual pequeña y característica.
- Dar a cada entorno legítimo su propia línea base.
- Leer por qué falló una comprobación antes de volver a ejecutarla.
- Vigilar las comprobaciones que se superan por un margen estrecho.
Avoid
- Las pausas fijas.
- Subir una tolerancia hasta que la compilación se pone en verde.
- Aceptar nuevas líneas base sin mirarlas.
- Reintentar los fallos hasta que se superan.
- Enmascarar zonas enteras de la pantalla.
¿Quiere verlo en su propia aplicación?Las pruebas visuales con GUI Test Studio muestran toda la idea en una página.
Preguntas
¿Qué es un falso positivo en las pruebas de software?
Un falso positivo es una prueba que falla mientras la aplicación funciona como debe.Los testers también lo llaman falso fallo o falsa alarma.Lo contrario, una prueba que se supera mientras hay un bug en la pantalla, es un falso negativo.
¿Cuál es la diferencia entre una prueba inestable y un falso positivo?
Una prueba inestable se supera y falla con el mismo código, sin que nada cambie entre las ejecuciones.Cada fallo inestable es un falso positivo, pero una prueba también puede fallar siempre por un motivo equivocado, como una imagen esperada desactualizada.
¿Qué vuelve inestables las pruebas de extremo a extremo?
Casi siempre los tiempos: la prueba actúa antes de que la aplicación esté lista.Los selectores que cambiaron, los elementos obsoletos, los datos de prueba compartidos, las animaciones, las redes lentas y las diferencias entre máquinas son las otras causas habituales.
¿Cómo se reducen los falsos positivos en las pruebas de regresión visual?
Espere a que la pantalla se asiente, mantenga pequeña cada zona comparada, ignore el ruido de renderizado como el suavizado de bordes, y tenga una línea base por entorno.GUI Test Studio solo cuenta los píxeles que cambiaron claramente en un mismo sitio, de modo que el ruido de renderizado pasa mientras una letra, un dígito o un color que cambia sigue haciendo fallar la prueba.
¿Hay que reintentar las pruebas inestables?
Un reintento pone la compilación en verde, pero no elimina la causa, y puede ocultar un bug real que solo ocurre a veces.Use los reintentos para detectar las pruebas inestables, y después corrija los tiempos, los datos o la comparación que hay detrás.
¿Puede la IA distinguir un bug visual real del ruido?
Sí, como un segundo vistazo después de la comparación de píxeles.En GUI Test Studio, el Análisis inteligente con IA da el veredicto final de una comprobación fallida: las diferencias menores pasan, mientras que una palabra, un número o un valor que cambia, o un icono que falta, sigue haciendo fallar la comprobación.
Selenium, Playwright, Cypress, BackstopJS, Chromatic, Argos, Percy y Applitools Eyes son marcas comerciales 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.