menu_superior

Para qué sirven las pruebas de rendimiento(III). Pruebas rendimiento de componentes

Este post forma parte de una serie sobre pruebas de rendimiento. Aquí puedes acceder al segundo post de la serie y aquí a todos los posts publicados hasta ahora.

En este capítulo me gustaría explicar la utilidad de aplicar las pruebas de rendimiento en varias escalas a lo largo de la construcción del sistema ya que creo que es una utilización poco explorada. Quiero hacerlo por que creo que hay una tendencia a pensar en las pruebas de rendimiento como algo que sólo se puede llevar a cabo sobre la aplicación terminada.Pruebas de carga de componentes Es evidente que cuando el sistema está terminado en su totalidad es cuando más significativo es el resultado. Se podría decir que es un resultado tipo WYSIWYG (what you see is what you get), es decir que no hay que hacer extrapolaciones ni cálculos, si hemos hecho las pruebas a escala real con el sistema real, el resultado es el comportamiento exacto que tendrá el sistema cuando esté en producción con usuarios reales.

Todo perfecto, no? Es directo y no hay andar hacer elucubraciones… Pues no. La verdad es que en la mayoría de las ocasiones no es posible hacer las pruebas a escala real y en la práctica totalidad es aconsejable hacer pruebas a pequeña escala, sobre componentes. Si sigues leyendo te explico por qué.

¿Qué son las pruebas de rendimiento de componentes?

Este tipo de pruebas son las pruebas de rendimiento que ya conocemos (pruebas de carga, estrés y volumen) aplicadas sobre una escala reducida que vamos a llamar componente. A este componente le someteremos a las pruebas en unos escenarios acordes a su tamaño y funcionalidad, es decir, hay que calcular la concurrencia a nivel de componente en vez de a nivel de aplicación. La idea es que nos permita conocer detalles del comportamiento del componente en un escenario de carga y nos desvele, lo antes posible, si está bien diseñado y construido o si no va a estar a la altura de la exigencia.

¿Cómo elegimos los componentes?

No hay un patrón, una regla que nos diga qué tamaño tiene un componente por que depende muy mucho del contexto de la aplicación y del objetivo de las pruebas. Cuando afrontamos este tipo de pruebas la idea es someter a prueba aquellas funcionalidades críticas en el sistema que típicamente están relacionadas con la gestión de conexiones con bases de datos, conexiones con sistemas externos, gestión de memoria (y otros recursos del sistema), colas de mensajería, etc. En general son los puntos “calientes”, donde se concentran más carga de trabajo.

Al igual que no hay posibilidad de acotar las funcionalidades fuera del contexto del sistema, tampoco la hay de delimitar el tamaño que tendrá el componente elegido. Podemos plantearnos pruebas a nivel de objeto, a nivel de funcionalidad, de proceso de negocio o incluso de webservice. Depende del nivel de detalle que necesitemos. Nos conviene que sean detallados sin perder la perspectiva de sistema.

Vaya explicaciones que doy!! Si no explico ni el tamaño que tiene ni las funcionalidades a las que afecta… Bueno, la idea es que la experiencia en pruebas y el “instinto” nos indiquen que partes podemos considerar como componentes. Dónde hay más riegos, cúal es el punto débil, qué funcionalidad tienen que usar más usuarios, qué proceso de negocio puede interrumpir el servicio. Respecto al tamaño prefiero pasarme de pequeño que de grande por que un componente demasiado grande puede dar información poco detallada y que haya que invertir tiempo en analizar. Si es demasiado pequeño los resultados puede que sean poco concluyentes y en pruebas sucesivas verse cuestionados. Como podéis ver depende de los objetivos que tengan las pruebas y del contexto del sistema.

¿Para qué hacerlas? Qué beneficios aportan las pruebas de rendimiento de componentes.

1.- Divide y vence. Si reducimos la escala de las pruebas también reducimos la escala del coste en tiempo, en esfuerzo y en complejidad. Es evidente que un componente con una funcionalidad muy reducida será fácil de probar y tendremos la posibilidad de hacer una prueba significativa en poco tiempo. Obviamente hay que elegir componentes que nos aporten información significativa, es decir, componentes que sean estratégicos del sistema.

2.- Test early, test often. Cuanto antes examinemos el rendimiento, aunque sea a escala, antes podremos arreglar los defectos y menor coste tendrán que encontremos. Si en la prueba salen defectos, será fácil y barato corregirlos. Aprovechemos esta oportunidad! Detéctalos con poco esfuerzo y rápido para poder solucionarlos igual de rápido y seguir con avanzando con el proyecto.

3.- POC (proof of concept). Otra ventaja, que es igual de evidente aunque seguramente menos frecuente en los proyectos, es que podemos avanzar con varios diseños o tecnologías y someterlos a una prueba de rendimiento de componentes para ver cuál de ellos rinde mejor en nuestros escenarios o cual se integra mejor con lo que ya hay.

En definitiva, las pruebas de rendimiento de componentes son una herramienta que nos puede ayudar durante la fase de desarrollo y optimizar la construcción de componentes críticos en el rendimiento del sistema evitando vueltas atrás en el ciclo de desarrollo por un diseño o una implementación defectuosos.

Pincha aquí para ir al capítulo anterior y aquí para ir al siguiente.

, , , , , , , , , , ,