La prueba de escalabilidad es la prueba de una aplicación de software para medir su capacidad de escalar vertical u horizontalmente en términos de cualquiera de sus capacidades no funcionales.
Los analistas de calidad de software generalmente agrupan las pruebas de rendimiento , escalabilidad y confiabilidad .
Los principales objetivos de las pruebas de escalabilidad son determinar el límite de usuarios para la aplicación web y garantizar que la experiencia del usuario final , bajo una carga alta, no se vea comprometida. Un ejemplo es si se puede acceder a una página web de manera oportuna con un retraso limitado en la respuesta. Otro objetivo es verificar si el servidor puede hacer frente a esto, es decir, ¿se bloqueará el servidor si está bajo una carga pesada? [1]
Dependiendo de la aplicación que se esté probando, se probarán diferentes parámetros. Si se está probando una página web, se probará el mayor número posible de usuarios simultáneos. [2] También depende de la aplicación que se esté probando los atributos que se prueban: estos pueden incluir el uso de la CPU , el uso de la red o la experiencia del usuario.
Una prueba exitosa proyectará la mayoría de los problemas que podrían estar relacionados con la red, la base de datos o el hardware/software. [3]
Al crear una nueva aplicación, es difícil predecir con precisión el número de usuarios que habrá en 1, 2 o incluso 5 años. Aunque se puede hacer una estimación, no se trata de un número definitivo. Un problema con un número creciente de usuarios es que puede crear nuevas áreas de falla. Por ejemplo, si tiene 100.000 visitantes nuevos, no solo el acceso a la aplicación podría ser un problema; también podría experimentar problemas con la base de datos donde necesita almacenar todos los datos de estos nuevos clientes. [4]
Por eso, al crear una prueba de escalabilidad, es importante escalarla en incrementos. Estos pasos se pueden dividir en cargas pequeñas, medianas y altas.
Debemos aumentar la escala en incrementos a medida que cada etapa prueba un aspecto diferente. Las cargas pequeñas garantizan que el sistema funcione como debería en un nivel básico. Las cargas medianas prueban que el sistema puede funcionar en su nivel esperado. Las cargas altas prueban que el sistema puede hacer frente a una carga alta. [5]
El entorno debe ser constante durante toda la prueba para proporcionar resultados precisos y confiables. Si la prueba es exitosa, deberíamos ver un cambio proporcional en el rendimiento. Por ejemplo, si duplicamos la cantidad de usuarios en el sistema, deberíamos ver una caída en el rendimiento del 50 %. [6]
Como alternativa, si se miden estadísticas del sistema como el uso de memoria o CPU a lo largo del tiempo, esto puede tener un gráfico diferente que no es proporcional ya que los usuarios no se representan en ninguno de los ejes.
Una vez recopilados los datos de todas las etapas, podemos proceder a representar gráficamente los resultados mediante diversos gráficos adaptados a las variables y métricas específicas que se analizan. El tipo de gráficos elegidos dependerá de la naturaleza de los datos y de los objetivos del análisis.
En la Figura 1, podemos ver un gráfico que muestra el uso de recursos (en este caso, memoria) a lo largo del tiempo. El gráfico no es proporcional, pero aun así se puede considerar que la prueba ha sido aprobada, ya que inicialmente hay una fase de aumento gradual a medida que el sistema comienza a funcionar; sin embargo, a medida que se agregan más usuarios, hay pocos cambios en el uso de la memoria. [7] Esto significa que la capacidad de memoria actual puede hacer frente a las 3 etapas de la prueba.
En la figura 2, podemos observar un incremento más proporcional, comparando el número de usuarios con el tiempo que se tarda en ejecutar un reporte. Con una carga baja de 20 usuarios, el tiempo promedio es de 5,5 segundos, a medida que aumentamos la carga a media (40 usuarios) y a una carga alta (60 usuarios), el tiempo promedio aumenta a 9,5 y 18 segundos respectivamente. [6]
En algunos casos, puede que sea necesario realizar cambios en el software o hardware del servidor. Una vez que se hayan realizado las actualizaciones necesarias, debemos volver a ejecutar las pruebas para asegurarnos de que las actualizaciones hayan sido efectivas para abordar los problemas planteados anteriormente. [8]
Cuando tenemos un resultado proporcional, no hay cuellos de botella a medida que ampliamos la escala y aumentamos la carga que soporta el sistema. [9]
Como resultado de las pruebas de escalabilidad, es posible que se requieran actualizaciones de software y hardware. Estas actualizaciones se pueden dividir en escalas verticales u horizontales.
El escalamiento vertical, también conocido como escalamiento ascendente, es el proceso de reemplazar un componente por un dispositivo que generalmente es más potente o mejorado. Por ejemplo, reemplazar un procesador por uno más rápido. El escalamiento horizontal, también conocido como escalamiento horizontal, consiste en configurar otro servidor, por ejemplo, para que se ejecute en paralelo con el original de modo que compartan la carga de trabajo. [10]
Ambos métodos de escalado tienen ventajas y desventajas. Aunque el escalado ascendente puede ser más sencillo, la adición de recursos de hardware puede dar como resultado rendimientos decrecientes . [11] Esto significa que cada vez que actualizamos el procesador, por ejemplo, no siempre obtenemos el mismo nivel de beneficios que con el cambio anterior.
Sin embargo, el escalamiento horizontal puede ser extremadamente costoso, no sólo el costo de sistemas completos como servidores, sino que también debemos tener en cuenta sus costos de mantenimiento regular. [11]