menu_superior

Escalabilidad de las pruebas de carga

escalabilidadPara empezar este post me gustaría hacer una reafirmación de mis ideas sobre cómo organizamos el testing: Debemos adaptarnos siempre al contexto. No me gustan las verdades universales para casi nada, así que el testing, que debe correr en paralelo a algo tan mutable como el desarrollo de software, no es una excepción.

Esto aplica en todas las direcciones, tanto para adaptar la metodología al cliente como para adaptar las prácticas a los objetivos y necesidades. Estos esquemas tan clásicos y que tanto nos han enseñado también son cuestionables a día de hoy. No me atrevo a hablar de un planteamiento “agile” estricto para las pruebas de rendimiento… Sería algo como tomar el agile como una inspiración para las el testing de rendimiento.

No podemos dejar las pruebas de rendimiento para el final: si encontramos algo grave será costoso de resolver tanto si el origen es el software (parches, nueva versión, nuevas pruebas funcionales, ciclo de regresión, etc.)  como si es el hardware (más infraestructura, mayores riesgos de corte de servicio, más coste de gestión y mantenimiento, etc.)

Las pruebas de carga no siempre son lineales

El matiz que introduce la palabra “siempre” no es menor. Hay muchos contextos lineales (pero muchos) y aquí seguramente no podemos hacer nada diferente porque las clásicas pruebas (carga, estrés y volumen sobre el sistema completo) son lo único que funciona. Insisto en que hay muchos contextos en que esto no se puede hacer de otra forma… Conspiraremos para cambiarlo, pero mientras tanto, hay lo que hay.

Para los demás contextos, lo mejor es empezar pronto a hacer pruebas de rendimiento y escalarlas a lo largo de las distintas fases del ciclo de vida y de los diferentes entornos por donde pasará la aplicación.

Lo ideal es que las pruebas, tanto funcionales como técnicas, duren tanto como el desarrollo. Es decir, no es algo que muere cuando el software llega a producción si no que es cíclico. Algo parecido a esto:

Pruebas de componentes

Las pruebas de rendimiento sobre los componentes se pueden realizar tanto sobre el software que desarrollamos como sobre el software externo. Se realizan en un entorno de pruebas y bajo una configuración controlada.

Por poner un ejemplo, someteríamos a pruebas a cada servicio web para verificar que son capaces de funcionar a 100 transacciones/segundo durante 10 minutos y que su tiempo de respuesta durante la prueba es inferior a 0,005 segundos.

Pruebas de profiling

Aplicadas típicamente con operaciones de entrada y salida de datos con la idea de depurar las querys y reducir al mínimo los tiempos de respuesta y los recursos utilizados. De hecho, se puede utilizar la prueba como una especie de debugger de soluciones para encontrar aquella que funcione mejor desde el punto de vista del rendimiento.

Pruebas de resiliencia

Con el sistema montado al completo eliminamos algún componente para verificar la continuidad del servicio en estas condiciones. Evidentemente este tipo de pruebas deben ser críticas en aplicaciones de comercio electrónico o que se requiera alta disponibilidad.

Pruebas de rendimiento preproducción

Estas son las clásicas pruebas que se han hecho siempre de rendimiento. Con toda la aplicación montada en un entorno de preproducción muy similar al de producción ejecutamos una pruebas para verificar que el sistema certifica los datos obtenidos en las pruebas anteriores. A diferencia de los enfoques más clásicos, este tipo de pruebas las postulo como una especie de regresión… Unas pruebas para no encontrar errores, para certificar que se cumplen las expectativas.

Pruebas de rendimiento en producción

Éstas son solo para valientes! Bromas aparte, las aplicaciones tienen una evolución que hay que controlar. Resulta muy lógico pensar que una aplicación que es modificada continuamente necesita tener una cierta vigilancia en este aspecto. Por lo tanto, además de monitorizarla en tiempo real, es importante planificar periodos de pruebas en entorno de producción que midan como está evolucionando el rendimiento.

, , ,

Comments are closed.