Artículo:

Daniel González Desarrollador Full-Stack

2 septiembre, 2016
En todo proyecto de desarrollo software es muy importante la realización de planes de pruebas
que garanticen que se cumplen los requisitos funcionales de la aplicación.

Además de éstas, existen otras que pueden marcar la calidad de una aplicación: de seguridad, de
usabilidad, de rendimiento.

Las pruebas de rendimiento son, desde la perspectiva más evidente, las que se realizan para
determinar lo rápido que un sistema realiza una tarea en unas determinadas condiciones de
trabajo. 

¿Para qué sirven las pruebas de rendimiento?

Para alcanzar un buen nivel de rendimiento de un sistema es fundamental que las pruebas
comiencen en el inicio del desarrollo del software. Al igual que en las pruebas funcionales, el coste
de solucionar defectos se ve aumentado conforme más se tarde en detectarlos.

Además, si queremos que los resultados sean lo más fiables posible, nuestro entorno de pruebas
debe ser lo más parecido posible al de producción, y no cruzarlo nunca con el de desarrollo ni el de
otras pruebas.

La pruebas de rendimiento sirven, entre otras cosas, para:

 Demostrar que el sistema cumple los criterios de rendimiento.

 Validar y verificar atributos de la calidad del sistema: escalabilidad, fiabilidad, uso de los
recursos.

 Comparar dos sistemas para saber cuál de ellos funciona mejor.

 Medir qué partes del sistema o de carga de trabajo provocan que el conjunto rinda mal.

  

Tipos de prueba de rendimiento

PRUEBA DE CARGA

Éste es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se realiza
generalmente para observar el comportamiento de una aplicación bajo una cantidad esperada de
peticiones. Esta carga puede ser el número esperado de usuarios concurrentes, utilizando la
aplicación que realizan un número específico de transacciones, durante el tiempo que dura la
carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones
importantes de la aplicación. Si también se monitorizan otros aspectos como la base de datos, el
servidor de aplicaciones, etc., entonces esta prueba puede mostrar el cuello de botella en la
aplicación.

1
Artículo:
Daniel González Desarrollador Full-Stack
2 septiembre, 2016
PRUEBA DE ESTRÉS

Se utiliza normalmente para romper la aplicación. Se va doblando el número de usuarios que se

agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba
se realiza para determinar la solidez de la aplicación en los momentos de carga extrema. Esto
ayuda a los administradores para determinar si la aplicación rendirá lo suficiente en caso de que la
carga real supere a la carga esperada.

PRUEBA DE ESTABILIDAD (SOAK TESTING)

Normalmente se hace para determinar si la aplicación puede aguantar una carga esperada
continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de memoria
en la aplicación.

PRUEBA DE PICO (SPIKE TESSTING)

La prueba de picos, como el nombre sugiere, trata de observar el comportamiento del sistema
variando el número de usuarios, tanto cuando bajan como cuando tiene cambios drásticos en su
carga. Esta prueba se recomienda que sea realizada con un software automatizado que permita
realizar cambios en el número de usuarios mientras que los administradores llevan un registro de
los valores a ser monitorizados.

Metodología

Según Microsoft Developer Network, la metodología de las pruebas de rendimiento consiste en las
siguientes actividades:

1. Identificar el entorno de pruebas. Identificar el entorno físico de pruebas y el entorno de

producción, así como las herramientas y recursos de que dispone el equipo de prueba. El
entorno físico incluye hardware, software y configuraciones de red. Tener desde el
principio un profundo conocimiento de todo el entorno de prueba permite diseños de
pruebas más eficientes. Facilita también la planificación y ayuda a identificar problemas en
las pruebas en fases tempranas del proyecto. En algunas situaciones, este proceso debe
ser revisado periódicamente durante todo el ciclo de vida del proyecto.

2. Identificar los criterios de aceptación de rendimiento. Determinar el tiempo de

respuesta, el rendimiento, la utilización de los recursos y los objetivos y limitaciones. En
general, el tiempo de respuesta concierne al usuario, el rendimiento al negocio, y la
utilización de los recursos al sistema.  Identificar cuáles serían criterios de éxito de
rendimiento del proyecto para evaluar qué combinación de la configuración da lugar a un
funcionamiento óptimo.

2
Artículo:
Daniel González Desarrollador Full-Stack
2 septiembre, 2016
3. Planificar y diseñar las pruebas. Identificar los principales escenarios, determinar la
variabilidad de los usuarios y la forma de simular esa variabilidad, definir los datos de las
pruebas y establecer las métricas a recoger. Consolidar esta información en uno o más
modelos de uso del sistema a implantar, ejecutarlo y analizarlo.

4. Configurar el entorno de prueba. Preparar el entorno de prueba, las herramientas y

recursos necesarios para ejecutar cada una de las estrategias, así como las características y
componentes disponibles para la prueba. Asegurarse de que el entorno de prueba se ha
preparado para la monitorización de los recursos según sea necesario.

5. Aplicar el diseño de la prueba. Desarrollar las pruebas de rendimiento de acuerdo con el

diseño del plan.

6. Ejecutar la prueba. Ejecutar y monitorizar las pruebas. Validar las pruebas, los datos de las
pruebas y recoger los resultados. Ejecutar pruebas válidas para analizar, mientras se
monitoriza la prueba y su entorno.

7. Analizar los resultados, realizar un informe y repetirlo. Consolidar y compartir los

resultados de la prueba. Analizar los datos, tanto individualmente como con un equipo
multidisciplinario. Volver a priorizar el resto de las pruebas y a ejecutarlas en caso de ser
necesario. Cuando todas las métricas estén dentro de los límites aceptados, ninguno de
los umbrales establecidos haya sido rebasados y toda la información deseada se ha
reunido, las pruebas han acabado para el escenario definido por la configuración.