La metodolog\u00eda es lo suficientemente amplia para abarcar varios tipos de proyectos pero a su vez da una gu\u00eda muy \u00fatil a la hora de abordar estos temas.<\/p>\n
En este post me gustar\u00eda comentar brevemente las diferentes estapas de la metodolog\u00eda y cu\u00e1l es el objetivo de cada una.<\/p>\n
![\"Etapas](\"https:\/\/wordpress-test.ces.com.uy\/web\/wp-content\/uploads\/2011\/02\/images.jpg\" "\\"Etapas")
<\/p>\n
Etapa inicial<\/strong><\/h1>\nSe busca entender el contexto en el cual surge el proyecto y los objetivos que se persiguen. Se busca tambi\u00e9n, dimensionar el proyecto de testing de performance, acotando su alcance. Se requieren en general pruebas de concepto para analizar que herramientas se adecuan mejor al contexto y al sistema que se tiene que probar. Al finalizar esta etapa tenemos que tener una idea clara del esfuerzo necesario para llevar adelante el proyecto, \u00a0perfiles de gente se a involucrar, los recursos \u00a0materiales se van a necesitar, etc.<\/p>\n
Etapa de Relevamiento<\/strong><\/h1>\nEs una de las etapas fundamentales del proyecto. Se busca definir un modelo que simule de la manera m\u00e1s adecuada posible la realidad a la cual se va a enfrentar el sistema. En esta etapa debemos integrar personas con distintos perfiles (usuarios, analistas funcionales, desarrolladores, administradores, etc.) para definir qu\u00e9 transacciones se incluir\u00e1n, cu\u00e1ntos usuarios virtuales se ejecutar\u00e1n, cada cu\u00e1nto tiempo, c\u00f3mo se simularan otros sistemas, etc. Se deben tener en cuenta todos estos factores para reproducir las condiciones bajo las cuales se quiere estudiar el sistema.<\/p>\n
Tambi\u00e9n se deben detallar otros aspectos importantes como ser: la infraestructura que se utilizar\u00e1 para las pruebas, como se monitorizar\u00e1 la misma, los datos a utilizar en las pruebas, etc.<\/p>\n
Etapa de Automatizaci\u00f3n<\/strong><\/h1>\nEn general en las pruebas de performance debemos programar para simular el modelo definido en la etapa anterior. Este modelo en general incluye la necesidad de ejecutar funcionalidades con alta concurrencia. Para poder lograr esto, en general, las herramientas trabajan a nivel de protocolo. Para protocolos abiertos y ampliamente difundidos como HTTP existe una variedad importante de herramientas gratuitas y pagas, pero para protocolos propietarios es m\u00e1s complicado encontrar herramientas gratuitas (tal como comentamos en un post anterior<\/a>).<\/p>\nAl finalizar esta etapa se contar\u00e1 con todos los artefactos de prueba necesarios para recrear el modelo definido.<\/p>\n
Etapa de Armado de la Infraestructura definitiva<\/strong><\/h1>\nLuego que se ha dedicado mucho esfuerzo definiendo y programando la automatizaci\u00f3n, es hora de dejar el ambiente de pruebas listo para comenzar las ejecuciones. Esta etapa en general ocurre luego de la etapa de automatizaci\u00f3n debido a que por lo general los servidores a utilizar en las pruebas tienen un costo alto y se intenta minimizar el uso de los mismos. Las etapas anteriores se pueden realizar con un ambiente similar al que se va a utilizar en las pruebas.<\/p>\n
Al finalizar esta etapa se tiene toda la infraestructura lista para la ejecuci\u00f3n, eso incluye la monitorizaci\u00f3n (tanto de los servidores como de las generadoras de carga), procesos de backup\/restore en caso de que sean necesarios, etc.<\/p>\n
Etapa de Ejecuci\u00f3n<\/strong><\/h1>\nEn esta etapa se comienza a obtener los resultados. Generalmente las ejecuciones las comenzamos con las llamadas l\u00edneas bases (baselines) las cuales consisten en ejecutar cada transacci\u00f3n sin concurrencia ninguna (con la totalidad de los recursos disponibles) para obtener el mejor tiempo posible de cada una. Estos tiempos nos servir\u00e1n luego como puntos de comparaci\u00f3n. Al comenzar las pruebas se recomienda asignar un porcentaje de carga bajo (por ejemplo un 20% de la carga que se desea soportar), si todo funciona seg\u00fan lo esperado subir al 40%, y as\u00ed hasta llegar al 100% o 200% si se desea. La raz\u00f3n fundamental para tomar esta\u00a0estrategia\u00a0es encontrar con un nivel de complejidad menor los problemas m\u00e1s gruesos, atacarlos y luego pasar al siguiente escal\u00f3n. Si se ejecutar\u00eda de primera el escenario objetivo puede pasar que ocurran varios problemas al mismo tiempo, agregando complejidad \u00a0al an\u00e1lisis de los mismos.<\/p>\n
Luego de varias iteraciones de ejecuci\u00f3n, reportes y correcciones (l\u00f3gica, configuraci\u00f3n, re-dise\u00f1o, etc.) se llega a una versi\u00f3n del sistema que cumple con los desaf\u00edos planteados, o no se llega y se aprende sobre los puntos en los cu\u00e1les se debe mejorar.<\/p>\n
Es muy importante tener en cuenta que durante esta etapa el objetivo es mejorar el sistema y por este motivo se deben involucrar tanto los testers como los desarrolladores, los expertos en el DBMS, en el sistema operativo, en el balanceador de carga, en el servidor web, en el storage, etc, etc.<\/p>\n
Etapa de Finalizaci\u00f3n<\/strong><\/h1>\nLuego que se terminan las ejecuciones es aconsejable hacer un informe final en el cual se\u00a0cuente \u00a0el desarrollo del proyecto, qu\u00e9 mejoras se hicieron qu\u00e9 sugerencias quedan por implementar para mejorar la performance, etc. Tambi\u00e9n es aconsejable hacer una evaluaci\u00f3n postmortem en la cual se vean los puntos a mejorar y ajustar para el pr\u00f3ximo proyecto.<\/p>\n
Esperamos les sea \u00fatil esta informaci\u00f3n y pueda contribuir en la mejora de la performance de sus sistemas.<\/p>\n
Es una de las etapas fundamentales del proyecto. Se busca definir un modelo que simule de la manera m\u00e1s adecuada posible la realidad a la cual se va a enfrentar el sistema. En esta etapa debemos integrar personas con distintos perfiles (usuarios, analistas funcionales, desarrolladores, administradores, etc.) para definir qu\u00e9 transacciones se incluir\u00e1n, cu\u00e1ntos usuarios virtuales se ejecutar\u00e1n, cada cu\u00e1nto tiempo, c\u00f3mo se simularan otros sistemas, etc. Se deben tener en cuenta todos estos factores para reproducir las condiciones bajo las cuales se quiere estudiar el sistema.<\/p>\n
Tambi\u00e9n se deben detallar otros aspectos importantes como ser: la infraestructura que se utilizar\u00e1 para las pruebas, como se monitorizar\u00e1 la misma, los datos a utilizar en las pruebas, etc.<\/p>\n
Etapa de Automatizaci\u00f3n<\/strong><\/h1>\nEn general en las pruebas de performance debemos programar para simular el modelo definido en la etapa anterior. Este modelo en general incluye la necesidad de ejecutar funcionalidades con alta concurrencia. Para poder lograr esto, en general, las herramientas trabajan a nivel de protocolo. Para protocolos abiertos y ampliamente difundidos como HTTP existe una variedad importante de herramientas gratuitas y pagas, pero para protocolos propietarios es m\u00e1s complicado encontrar herramientas gratuitas (tal como comentamos en un post anterior<\/a>).<\/p>\nAl finalizar esta etapa se contar\u00e1 con todos los artefactos de prueba necesarios para recrear el modelo definido.<\/p>\n
Etapa de Armado de la Infraestructura definitiva<\/strong><\/h1>\nLuego que se ha dedicado mucho esfuerzo definiendo y programando la automatizaci\u00f3n, es hora de dejar el ambiente de pruebas listo para comenzar las ejecuciones. Esta etapa en general ocurre luego de la etapa de automatizaci\u00f3n debido a que por lo general los servidores a utilizar en las pruebas tienen un costo alto y se intenta minimizar el uso de los mismos. Las etapas anteriores se pueden realizar con un ambiente similar al que se va a utilizar en las pruebas.<\/p>\n
Al finalizar esta etapa se tiene toda la infraestructura lista para la ejecuci\u00f3n, eso incluye la monitorizaci\u00f3n (tanto de los servidores como de las generadoras de carga), procesos de backup\/restore en caso de que sean necesarios, etc.<\/p>\n
Etapa de Ejecuci\u00f3n<\/strong><\/h1>\nEn esta etapa se comienza a obtener los resultados. Generalmente las ejecuciones las comenzamos con las llamadas l\u00edneas bases (baselines) las cuales consisten en ejecutar cada transacci\u00f3n sin concurrencia ninguna (con la totalidad de los recursos disponibles) para obtener el mejor tiempo posible de cada una. Estos tiempos nos servir\u00e1n luego como puntos de comparaci\u00f3n. Al comenzar las pruebas se recomienda asignar un porcentaje de carga bajo (por ejemplo un 20% de la carga que se desea soportar), si todo funciona seg\u00fan lo esperado subir al 40%, y as\u00ed hasta llegar al 100% o 200% si se desea. La raz\u00f3n fundamental para tomar esta\u00a0estrategia\u00a0es encontrar con un nivel de complejidad menor los problemas m\u00e1s gruesos, atacarlos y luego pasar al siguiente escal\u00f3n. Si se ejecutar\u00eda de primera el escenario objetivo puede pasar que ocurran varios problemas al mismo tiempo, agregando complejidad \u00a0al an\u00e1lisis de los mismos.<\/p>\n
Luego de varias iteraciones de ejecuci\u00f3n, reportes y correcciones (l\u00f3gica, configuraci\u00f3n, re-dise\u00f1o, etc.) se llega a una versi\u00f3n del sistema que cumple con los desaf\u00edos planteados, o no se llega y se aprende sobre los puntos en los cu\u00e1les se debe mejorar.<\/p>\n
Es muy importante tener en cuenta que durante esta etapa el objetivo es mejorar el sistema y por este motivo se deben involucrar tanto los testers como los desarrolladores, los expertos en el DBMS, en el sistema operativo, en el balanceador de carga, en el servidor web, en el storage, etc, etc.<\/p>\n
Etapa de Finalizaci\u00f3n<\/strong><\/h1>\nLuego que se terminan las ejecuciones es aconsejable hacer un informe final en el cual se\u00a0cuente \u00a0el desarrollo del proyecto, qu\u00e9 mejoras se hicieron qu\u00e9 sugerencias quedan por implementar para mejorar la performance, etc. Tambi\u00e9n es aconsejable hacer una evaluaci\u00f3n postmortem en la cual se vean los puntos a mejorar y ajustar para el pr\u00f3ximo proyecto.<\/p>\n
Esperamos les sea \u00fatil esta informaci\u00f3n y pueda contribuir en la mejora de la performance de sus sistemas.<\/p>\n
Al finalizar esta etapa se contar\u00e1 con todos los artefactos de prueba necesarios para recrear el modelo definido.<\/p>\n
Etapa de Armado de la Infraestructura definitiva<\/strong><\/h1>\nLuego que se ha dedicado mucho esfuerzo definiendo y programando la automatizaci\u00f3n, es hora de dejar el ambiente de pruebas listo para comenzar las ejecuciones. Esta etapa en general ocurre luego de la etapa de automatizaci\u00f3n debido a que por lo general los servidores a utilizar en las pruebas tienen un costo alto y se intenta minimizar el uso de los mismos. Las etapas anteriores se pueden realizar con un ambiente similar al que se va a utilizar en las pruebas.<\/p>\n
Al finalizar esta etapa se tiene toda la infraestructura lista para la ejecuci\u00f3n, eso incluye la monitorizaci\u00f3n (tanto de los servidores como de las generadoras de carga), procesos de backup\/restore en caso de que sean necesarios, etc.<\/p>\n
Etapa de Ejecuci\u00f3n<\/strong><\/h1>\nEn esta etapa se comienza a obtener los resultados. Generalmente las ejecuciones las comenzamos con las llamadas l\u00edneas bases (baselines) las cuales consisten en ejecutar cada transacci\u00f3n sin concurrencia ninguna (con la totalidad de los recursos disponibles) para obtener el mejor tiempo posible de cada una. Estos tiempos nos servir\u00e1n luego como puntos de comparaci\u00f3n. Al comenzar las pruebas se recomienda asignar un porcentaje de carga bajo (por ejemplo un 20% de la carga que se desea soportar), si todo funciona seg\u00fan lo esperado subir al 40%, y as\u00ed hasta llegar al 100% o 200% si se desea. La raz\u00f3n fundamental para tomar esta\u00a0estrategia\u00a0es encontrar con un nivel de complejidad menor los problemas m\u00e1s gruesos, atacarlos y luego pasar al siguiente escal\u00f3n. Si se ejecutar\u00eda de primera el escenario objetivo puede pasar que ocurran varios problemas al mismo tiempo, agregando complejidad \u00a0al an\u00e1lisis de los mismos.<\/p>\n
Luego de varias iteraciones de ejecuci\u00f3n, reportes y correcciones (l\u00f3gica, configuraci\u00f3n, re-dise\u00f1o, etc.) se llega a una versi\u00f3n del sistema que cumple con los desaf\u00edos planteados, o no se llega y se aprende sobre los puntos en los cu\u00e1les se debe mejorar.<\/p>\n
Es muy importante tener en cuenta que durante esta etapa el objetivo es mejorar el sistema y por este motivo se deben involucrar tanto los testers como los desarrolladores, los expertos en el DBMS, en el sistema operativo, en el balanceador de carga, en el servidor web, en el storage, etc, etc.<\/p>\n
Etapa de Finalizaci\u00f3n<\/strong><\/h1>\nLuego que se terminan las ejecuciones es aconsejable hacer un informe final en el cual se\u00a0cuente \u00a0el desarrollo del proyecto, qu\u00e9 mejoras se hicieron qu\u00e9 sugerencias quedan por implementar para mejorar la performance, etc. Tambi\u00e9n es aconsejable hacer una evaluaci\u00f3n postmortem en la cual se vean los puntos a mejorar y ajustar para el pr\u00f3ximo proyecto.<\/p>\n
Esperamos les sea \u00fatil esta informaci\u00f3n y pueda contribuir en la mejora de la performance de sus sistemas.<\/p>\n
En esta etapa se comienza a obtener los resultados. Generalmente las ejecuciones las comenzamos con las llamadas l\u00edneas bases (baselines) las cuales consisten en ejecutar cada transacci\u00f3n sin concurrencia ninguna (con la totalidad de los recursos disponibles) para obtener el mejor tiempo posible de cada una. Estos tiempos nos servir\u00e1n luego como puntos de comparaci\u00f3n. Al comenzar las pruebas se recomienda asignar un porcentaje de carga bajo (por ejemplo un 20% de la carga que se desea soportar), si todo funciona seg\u00fan lo esperado subir al 40%, y as\u00ed hasta llegar al 100% o 200% si se desea. La raz\u00f3n fundamental para tomar esta\u00a0estrategia\u00a0es encontrar con un nivel de complejidad menor los problemas m\u00e1s gruesos, atacarlos y luego pasar al siguiente escal\u00f3n. Si se ejecutar\u00eda de primera el escenario objetivo puede pasar que ocurran varios problemas al mismo tiempo, agregando complejidad \u00a0al an\u00e1lisis de los mismos.<\/p>\n
Luego de varias iteraciones de ejecuci\u00f3n, reportes y correcciones (l\u00f3gica, configuraci\u00f3n, re-dise\u00f1o, etc.) se llega a una versi\u00f3n del sistema que cumple con los desaf\u00edos planteados, o no se llega y se aprende sobre los puntos en los cu\u00e1les se debe mejorar.<\/p>\n
Es muy importante tener en cuenta que durante esta etapa el objetivo es mejorar el sistema y por este motivo se deben involucrar tanto los testers como los desarrolladores, los expertos en el DBMS, en el sistema operativo, en el balanceador de carga, en el servidor web, en el storage, etc, etc.<\/p>\n