Estoy preparando parte de la presentación que voy a dar en un par de semanas en el Agile Testing Days (que por primera vez se hará en Estados Unidos), y quería tener algo de feedback sobre la forma de presentar algunas ideas relacionadas a las pruebas de performance en integración continua. Como siempre queda bien hablar de pirámides, terminé representando algunas ideas con esta pirámide, basada en la famosa pirámide de Cohn para pruebas automatizadas funcionales, a la cual le llamé “Pirámide para las Pruebas de Performance” (para nada original, ¡eso seguro!).
Pirámide para las Pruebas de Performance
La idea de la pirámide es que sirva como referencia al momento de establecer la estrategia de pruebas del sistema en cuanto a performance. Esto será más o menos aplicable dependiendo de la arquitectura (es más que nada aplicable cuando hay microservicios, o al menos una capa de servicios SOAP o REST).
Niveles de la Pirámide
Paso a explicar un poco la idea detrás de cada uno de los niveles:
- Services Unit Tests: La idea es probar individualmente cada uno de los servicios de forma aislada, simulando cierta carga sobre el mismo. Preparar una prueba es sumamente simple, ya que se trata de un solo request http.
- Integration Tests: En estas pruebas vamos a querer probar varios servicios a la vez para ver cómo afectan la performance unos a otros. Para esto tomaremos las mismas pruebas unitarias y las combinaremos en un único escenario concurrente, así que si ya tenemos las otras preparadas, armar estas pruebas no debería ser tan complejo.
- E2E Load Simulation: Estas son las clásicas pruebas de performance donde simulamos la carga que esperamos en el sistema. Los scripts se deben preparar a nivel de usuario y no a nivel de servicio, o sea, simulando el tráfico que se dispara desde el navegador. Esto hace que las pruebas sean bastante más complejas de preparar, ya que hay que manejar otro montón de cosas a nivel de protocolo (cookies, pedidos embebidos, seguridad, etc.). Además, otras cosas que sean más complejas de preparar, es que tenemos que usar infraestructura similar a producción, un volumen de base de datos representativo, etc. Es costosa de preparar, pero los resultados que obtenemos serán los más cercanos a la experiencia de usuario.
Lo fundamental de esto es qué tan frecuente puedo ejecutar cada tipo de pruebas. Esto depende de qué tan fácil de preparar, codificar, y mantener son esas pruebas, y por otro lado, qué información me aportan. Por esto es que la propuesta es ejecutar las pruebas unitarias de los servicios en cada build, tal como lo expliqué en este webinar o en este post. Para ver cómo impactan los servicios unos sobre otros, es que de vez en cuando deberíamos ejecutar pruebas donde combinemos varios servicios, a lo que le podríamos llamar “pruebas de integración”. Estas son un poco más complicadas de preparar, pero podrían llegar a ayudarnos a descubrir otro tipo de problemas que podrían llegar a suceder en producción, ya que ahí van a ejecutar los servicios todos juntos. Como hasta acá no tengo idea de qué tiempos de respuesta puede recibir un usuario, esto lo tengo que complementar con las pruebas clásicas de carga. Son mucho más complicadas de preparar, pero son las únicas que me ayudan a reducir riesgos. Lo bueno es que si ya hice pruebas unitarias y pruebas de integración, seguramente llego a esta etapa con menos probabilidad de encontrar problemas serios, o al menos, ya me adelanté a varios de ellos.
Me encantaría recibir feedback sobre estas ideas, ver si alguien más tiene algo de experiencia con estos enfoques, o si quieren alimentar el brainstorming con algunas otras ideas.
Tal vez se podría agregar algún ejemplo de los escenarios de carga como para visualizar bien la diferencia entre cada nivel de la piramide, también podría estar bueno mencionar las herramientas que se pueden utilizar en cada nivel.
La idea está muy buena.
Una pregunta frecuente que he recibido de muchos colegas es si solo podemos lograr esto teniendo la misma infra de producción? O si vale la pena ejecutar en infras más chicas como de testing, si los resultados son de interés? Si bien en enfoques de IC las pruebas se pueden ejecutar en ambientes de testing o preproduccion y la respuesta puede ser clara, para quienes no están aún en este esquema la duda surge. Tal vez podemos recordar que todas estas pruebas tienen validez en la infra en que se pueda probar. Hay errores más grandes más relacionados a la app y no tanto a los servidores que pueden ser atacados por más de no contar con ambientes como producción. Las pruebas de performance siempre arrojan resultados valiosos en todos los escenarios 🙂
Leti! gracias!
Obvio que siempre aporta. Si es similar a prod, vamos a poder analizar más problemas, o problemas más parecidos a los que tendremos en prod, pero vamos a necesitar generar más carga para que la infra lo note 🙂 …. en ese sentido es que conviene hacer un scale down
Excelente Mati!
Hola,
yo creo que una parte fundamental en los 3 enfoques de pruebas, es poder definir correctamente las assertions, SLA´s y criterios de aceptación y con esto poder “jugar” con los resultados que se peresenten en cada tipo de prueba realizada. Tomar unas lineas base consistentes que nos permitan medir los cambios e impactos que se pudieran presentar sobre todo en las etapas tempranas de pruebas. Todo esto además con un buen monitoreo de aplicaciones ya sea con herramientas APM o scripts automatizados.
respecto a esto tambien me surge una duda, que tanto impacto tendria el uso de herramientas mas expacializadas en penrformance que nos puedan dar información en una sola herramienta? es decir, aquellas en las que puedo tener toda la información y correlacionarla como tiempos de repsuesta, TPS, Monitoreo entre otras cosas, todo en una solo herramienta, si de agilismo y velocidad se habla, estas herramientas podrian tener un ROI bastante rápido?.
Carlos, cómo va?
Excelentes tus apuntes, algunas de esas cosas no las había hecho explícitas, tal vez porque las contaba en otros posts enlazados, pero me hiciste ver que vale la pena destacarlo.
Con respecto a la herramienta integrada, todo eso lo podés ver en un APM, cierto? y las herramientas de pruebas de performance en el Cloud generalmente se integran con los APM, así que podrías tener todo junto incluso los resultados de pruebas. No lo he llegado a probar, pero entiendo que herramientas como Dynatrace están pensadas para funcionar en CI, pudiendo detectar diferencias en los comportamientos entre una ejecución de prueba y otra equivalente.
Abrazo