¿Qué son las pruebas de caos?

Las pruebas de caos son una técnica que se usa para probar la resistencia de los sistemas de software mediante la introducción de errores inesperados o interrupciones. Las pruebas de caos también se conocen como ingeniería de caos. El objetivo de las pruebas de caos es identificar debilidades y mejorar la resistencia de la aplicación.

Las pruebas de caos se basan en la idea de que los sistemas fallan de maneras inesperadas. Los métodos de prueba tradicionales suelen quedarse cortos a la hora de descubrir estas formas de fallo inesperadas. Cuando se usan pruebas de caos, se simulan escenarios reales, como bloqueos del servidor, latencia de red o agotamiento de recursos. La simulación de estos comportamientos ayuda a exponer problemas ocultos y debilidades que podrían no ser evidentes en condiciones de prueba normales.

Estos son algunos puntos clave que se deben tener en cuenta sobre las pruebas de caos:

• Sea proactivo. En lugar de esperar a que se produzcan errores, las pruebas de caos introducen de forma proactiva errores para ver cómo responde el sistema. Las pruebas de caos le permiten identificar y corregir problemas antes de que se conviertan en problemas importantes.
• Obtenga información. El objetivo de las pruebas de caos es aprender de los errores. Al introducirlos, puede obtener información valiosa sobre cómo se comporta el sistema bajo estrés y usar esa información para mejorarlo.
• Promover un esfuerzo de equipo. Las pruebas de caos son más eficaces cuando se hace de forma colaborativa. Quiere obtener información de desarrolladores, evaluadores, operaciones y otras partes interesadas. Al trabajar juntos, puede identificar las áreas más importantes para probar y asegurarse de que todos están informados.
• Comience de a poco y vaya aumentando. Cuando empiece por primera vez con las pruebas de caos, es una buena idea iniciar pequeñas y aumentar gradualmente la complejidad de las pruebas. El inicio pequeño le ayuda a crear confianza y a desarrollar una mejor comprensión de cómo se comporta el sistema en condiciones diferentes.

En resumen, las pruebas de caos son una técnica eficaz que puede ayudarle a mejorar la resistencia de las aplicaciones. Al introducir de forma proactiva errores y aprender de ellos, puede identificar y corregir problemas antes de que se conviertan en problemas importantes.

Pruebas de caos para las API a las que llama la aplicación

Las pruebas de caos suelen centrarse en la infraestructura: servidores, redes y contenedores. Si la aplicación depende de las API, algunos de los errores que notan los usuarios proceden de esas API: un 500 de un proveedor de pagos, un 429 de GitHub o OpenAI, o una respuesta que tarda 8 segundos en lugar de 80 milisegundos. Puede aplicar las mismas ideas de prueba de caos a esas dependencias, en el nivel de respuestas de API individuales:

• Errores. Devuelve 5xx errores al azar y comprueba que la aplicación reintenta lo que es seguro para reintentar y muestra un mensaje útil para el resto.
• Limitación de peticiones. Devuelva 429 con una cabecera Retry-After y compruebe que la aplicación espera antes de volver a llamarla.
• Latencia. Retrasa las respuestas y comprueba los tiempos de espera, los spinners y lo que sucede cuando las respuestas llegan fuera de orden.

Approach	Lo que encuentras	Lo que te pierdes
Esperar a que esté en producción	Fallos reales	Todo, hasta que un usuario lo pulse
Simula la API en las pruebas o deja que el agente de codificación escriba el mock	Que se ejecuten las ramas de error	Los formatos de error reales de la API, la directiva de reintento del SDK y cómo se comporta la aplicación en ejecución. La aplicación también necesita un interruptor solo para pruebas para llegar al mock.
Dañar la infraestructura real (por ejemplo, detener un servicio o bloquear el tráfico de red)	Cómo el sistema se enfrenta a interrupciones	Errores de nivel de API, como un código de error específico o un encabezado Retry-After
Interceptar el tráfico real de la aplicación e insertar errores de API	Errores, limitación de tasa y latencia en las direcciones URL reales, a la tasa que elija	Fallos de infraestructura. Usa herramientas de caos de infraestructura para esos.

Pruébalo en tu app

Dev Proxy introduce errores de API en la aplicación mientras sigue llamando a las direcciones URL reales. Funciona con cualquier tipo de aplicación, en cualquier pila de tecnología, sin cambiar el código. Por ejemplo, para hacer fallar la mitad de las solicitudes a una API con errores aleatorios, siga Probar mi aplicación con errores aleatorios y, para que sean lentas, consulte Simular respuestas lentas de la API. Para ejecutar las mismas pruebas en la canalización de CI, consulte Usar Dev Proxy en CI/CD.

Paso siguiente

Prueba de mi aplicación con errores aleatorios