¿Cómo se podría ejecutar una prueba de performance y que no se descubran tantos problemas?

Hay una frase de Scott Barber que me gusta mucho y refleja parte de lo que quiero contar aquí:

Only performance testing at the conclusion of system or functional testing is like ordering a diagnostic blood test after the patient is dead.
Que se entendería como Solo probar la performance al final de las pruebas de sistema o pruebas funcionales es como pedir un diagnóstico de sangre cuando el paciente ya está muerto.

Es típico que las pruebas de performance se dejen para el final de un proyecto (si hay tiempo y presupuesto aún), sin haber investigado nada en absoluto con anterioridad. Esto hace que se encuentren todos los problemas relacionados a la performance al final, juntos.

Pensemos qué pasa con respecto a las pruebas de aspectos funcionales. En general (lamentablemente no es siempre) se hacen pruebas unitarias por parte de cada desarrollador antes de integrar el sistema. Una vez integrado se hacen pruebas de integración, y ahí se le pasa una nueva versión al equipo de pruebas externo para que hagan las pruebas de sistema.

Nosotros creemos que este enfoque aplicado a la performance (y obviamente a muchos otros aspectos no-funcionales también) podría hacer que la aplicación llegue mucho más depurada al momento de la prueba final en la plataforma definitiva.

No parece muy difícil implementar un programa que ejecute muchas veces un método y que registre los tiempos. Mientras eso sucede, podríamos mirar la base de datos, qué tiempo tuvieron las SQLs, si utilizaron los índices correctamente, qué pasa si crece el tamaño de esa tabla, etc. Luego, ese programa en lugar de simplemente ejecutar muchas veces un método, podría levantar múltiples procesos que ejecuten muchas veces ese método (siempre teniendo en mente lo que sucederá cuando esté en producción). Podríamos ver qué tanta memoria consume, cómo se maneja el pool de conexiones, si observamos bloqueo entre tablas, etc.

Ventajas

• los desarrolladores se comprometen con la performance, verifican y no liberan módulos con problemas de performance graves 
• los desarrolladores se familiarizan con el uso de recursos de sus sistemas, descubren qué cosas de su código generan problemas y seguramente les ayude a evitarlo a futuro
• menos riesgo de tener problemas de performance
• los problemas se detectan antes, con lo cual será más barato resolverlos

Desventajas

• más tiempo para liberar la primera versión
• necesidad de aprender a utilizar herramientas de monitorización

Claro que esto no es para hacerlo con cada método que se desarrolle, pero se podría pensar en cuáles serán los más utilizados, los que tienen las tareas más demandantes en cuanto a consumo, los que deben procesar más datos, etc.

Claro que esto no sustituye las pruebas de performance, sino que nos prepara mejor para ellas. No las sustituye porque no se prueban las distintas funcionalidades en conjunto, no se prueba la operativa, no se prueba en un servidor similar al de producción, sino que en el de desarrollo, etc.


http://blog.abstracta.com.uy/2013/12/como-se-podria-ejecutar-una-prueba-de.html