UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

“PERFORMANCE TESTING AUTOMATIZADO Y

ANÁLISIS DE MEMORY LEAK EN SERVICIOS
WEB”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO

DE DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I
.

POSTULANTE : LOURDES SELEN CHOQUE CHOQUECALLATA

TUTOR : LIC. MAURICIO GIOVANNY VISCARRA RIVERA

Cochabamba – Bolivia
2018
 A mis padres por su apoyo incondicional, y
a mis amigos y compañeros que
compartieron sus conocimientos en cada
etapa.

ii
Tabla de Contenido
TABLA DE CUADROS, GRÁFICOS Y FIGURAS 5

Resumen 6

Introducción 7

1. Generalidades 8

1.1 Antecedentes Generales 8

1.2 Antecedentes Específicos 8

1.3 Objetivo general 9

1.4 Objetivos específicos 9

2. Metodología 9

3. Tipos de pruebas de rendimiento 10

3.1 Prueba de carga 10

3.2 Prueba de estrés 11

3.3 Prueba de estabilidad 13

3.4 Prueba de concurrencia 14

4. Problemas comunes de rendimiento 15

5. Proceso de Performance Testing 16

6. Importancia de la automatización de las pruebas de rendimiento 17

7. Herramientas para automatización de Pruebas de rendimiento 17

7.1 JMeter 17

7.2 Load Runner 19

7.3 Web Load 21

7.4 LoadView 23

8. Memory Leak 25
3
 8.1 Efectos de memory leak 25

8.2 Identificación de fuga de memoria 26

9. Contadores del Monitor de rendimiento 27

10. Perfiladores de Memoria en Java 28

11. Conclusiones 30

12. Bibliografía 32

4
TABLA DE CUADROS, GRÁFICOS Y FIGURAS

Gráfico 1: Proceso de pruebas de rendimiento .................................................................... 16

Gráfico 2: Interfaz de LoadRunner ........................................................................................ 20

Gráfico 3: IDE WebLOAD........................................................................................................ 22

5
 RESUMEN

Hoy en día se tienen más expectativas de las aplicaciones web que se utilizan, es por esta razón
que las pruebas de rendimiento se han vuelto tan importantes, incluso el retraso de un segundo
en el tiempo de carga de un sitio web desencadena en menos conversiones, menos visitas y una
disminución crítica en la satisfacción del cliente.

Una prueba de rendimiento es una prueba no funcional que examina la relación entre la aplicación
web y su entorno, la prueba de rendimiento determina cómo se desempeñan los diferentes
componentes de un sistema en una determinada situación. El uso de recursos, la escalabilidad y
la confiabilidad son factores que también se evalúan bajo esta prueba.

Las pruebas de rendimiento incluyen diferentes tipos de test, desde pruebas de carga, pruebas
de estrés, pruebas de resistencia, cada una con diferentes objetivos. Estas pruebas son parte
esencial del ciclo de desarrollo, es necesario aplicarlas en cada versión para verificar si los
nuevos cambios o características tienen un impacto positivo o negativo en el rendimiento de la
aplicación.

Para evaluar y probar la carga de recursos, se tienen diversas herramientas que permiten crear
y diseñar scripts, estas herramientas consideran diferentes alternativas como el protocolo de
comunicación que se utiliza hasta la cantidad de usuarios simultáneos que se desea simular en
la aplicación.

Un complemento al análisis del rendimiento, es la consideración de la fuga de memoria (memory

leak) en los servicios. Cuando un programa no libera el bloque de memoria que ha reservado,
dependiendo de la cantidad y el tiempo de ejecución; puede llegar a agotar toda la memoria, este
fenómeno ralentiza significativamente el rendimiento del sistema y en algunos casos provoca que
el sistema finalice.

6
 INTRODUCCIÓN

Es fácil olvidarse de las pruebas de rendimiento y su importancia al entregar el software dentro

de plazos ajustados. Indistintamente sea el sistema que se esté desarrollando, es necesario estar
preparado para el tráfico que afectará el sistema. Y lo que es más importante, se debe
comprender, estimar y analizar, en función de las tendencias pasadas y futuras, el nivel de tráfico
a esperar y la eficiencia de respuesta para atender la misma.

Las pruebas de rendimiento son una tarea continua a lo largo del ciclo de vida de un proyecto.
No solo involucra a los evaluadores, sino también a los desarrolladores y las operaciones para
ejecutar y mantener la aplicación cumpliendo con las expectativas de rendimiento.

Las pruebas de rendimiento requieren conjuntos de habilidades multifacéticas para escribir scripts
de prueba, monitorear y analizar resultados, ajustar la aplicación y repetir todo el proceso
nuevamente.

Someter el software o la aplicación web a condiciones reales de carga, ayudan a identificar y

brindar soluciones a posibles problemas de rendimiento, por lo que es necesario emular los
diferentes usos de la aplicación. Con los scripts es posible emular la interacción del usuario con
la aplicación, para ello existen diferentes herramientas que permiten diseñar y ejecutar scripts,
que pueden ser usados para probar cargas de recursos estáticos y dinámicos.

7
1. GENERALIDADES

En los siguientes puntos se desarrolla un estudio detallado sobre las diferentes pruebas de
rendimiento, así como los problemas más comunes de rendimiento que se presenta en los
servicios web. Cada uno de los pasos para la ejecución de una prueba de Performance Testing
se detalla en el proceso de las pruebas de rendimiento.

Para realizar pruebas de rendimiento exitosas que ayuden a identificar los problemas en cuanto
al performance de los sistemas es necesario el uso de herramientas que ayuden a automatizar
estas pruebas, se presentan algunas herramientas útiles para este fin.

Para un programa que se abre con frecuencia o que se ejecuta de manera continua, incluso una
pérdida de memoria muy pequeña puede hacer que el programa finalice, se concluye este
documento con el análisis de memory leak o pérdida de memoria dentro de sistemas o
aplicaciones web.

1.1 ANTECEDENTES GENERALES

Es notable hoy en día la presencia de diferentes servicios en la web, juntamente con esto las
expectativas de los usuarios se ha incrementado. Se espera más de los sistemas o aplicaciones
web en cuanto a velocidad y confiabilidad, que en caso de cumplir con las expectativas
proporciona satisfacción al cliente o usuario.

Las pruebas de rendimiento (Performance Test) nos permiten tomar las medidas necesarias
dentro del proceso de desarrollo para asegurar un producto con un buen desempeño en cada
versión. Tomar las acciones correctivas en el momento oportuno garantiza que sea posible
ofrecer una buena experiencia al usuario final, y un ahorro económico en términos de ejecución
y mantenimiento de servicios web de alto tráfico con bajo rendimiento.

1.2 ANTECEDENTES ESPECÍFICOS

No existe duda de la importancia de las pruebas automatizadas, las cuales inciden directamente
en la experiencia del usuario, cada vez son más empresas que están conscientes de ello.

Tal es el caso de Wallmart que, como parte de una iniciativa para mejorar las experiencias de
comercio electrónico de sus clientes y la productividad de los desarrolladores, el equipo de
Walmart adoptó las mejores prácticas de pruebas continuas utilizando Selenium y Test Armada.

8
En su paso hacia las pruebas automatizadas, Walmart se dio cuenta de que no había
herramientas de administración de pruebas que funcionaran a la escala que requerían. Por eso,
en 2015, comenzaron a desarrollar Test Armada, una plataforma de automatización de código
abierto de calidad desarrollada para soportar servicios nativos, web y backend testing. Esta es
ahora una herramienta central que admite pruebas funcionales, pruebas de rendimiento,
maquetas e información de datos en todos los sistemas Walmart.com, de abarrotes y de tiendas
respaldadas. [1]

1.3 OBJETIVO GENERAL

- Coadyuvar a entender la importancia de las pruebas de rendimiento mediante información

útil y precisa para mejorar la entrega de sistemas y aplicaciones web fiables en
rendimiento.

1.4 OBJETIVOS ESPECÍFICOS

- Identificar la importancia de la ejecución de las pruebas de rendimiento más relevante

- Identificar los problemas más comunes de rendimiento existentes en los sistemas y
aplicaciones web
- Identificar herramientas de automatización para pruebas de rendimiento
- Realizar un análisis de fuga de memoria (memory leak) en servicios web

2. METODOLOGÍA

Para el presente trabajo se utilizarán el Método Bibliográfico como metodología de investigación.

La investigación bibliográfica proporciona conocimiento de las investigaciones ya existentes, de

un modo sistemático, a través de una amplia búsqueda de: información, conocimientos y técnicas
sobre un tema determinado.

En un sentido amplio, el método de investigación bibliográfico es el sistema que se sigue para

obtener información contenida en documentos.

Los métodos de información bibliográfica para la investigación permiten utilizar la información

registrada en determinados documentos para llevar a cabo una investigación propia. La utilización
de instrumentos bibliográficos en el desarrollo de cualquier investigación es absolutamente
imprescindible. Los métodos de investigación bibliográfica serán los hilos que permitan localizar
y seleccionar la información precisa de entre toda la masa documental que existe.
9
3. TIPOS DE PRUEBAS DE RENDIMIENTO

Las pruebas de rendimiento, son las pruebas que se realizan a un sistema para determinar la
capacidad y estabilidad de respuesta bajo diversas cargas de trabajo. Las pruebas de rendimiento
miden los atributos de calidad del sistema, como la escalabilidad, la fiabilidad y el uso de recursos.

El rendimiento de una aplicación de software como su tiempo de respuesta, confiabilidad, uso de

recursos y escalabilidad son importantes. El objetivo de “Performance Testing” no es encontrar
errores, sino eliminar los cuellos de botella de rendimiento.

Las pruebas de rendimiento verifican los siguientes parámetros en un sistema o aplicación web:

- Velocidad: Determina la rapidez de respuesta de la aplicación.

- Escalabilidad: Determina la cantidad máxima de usuarios que la aplicación puede
manejar.
- Estabilidad: Determina si la aplicación se mantiene estable bajo cargas variables.

Existen diferentes tipos de prueba de rendimiento, entre ellas:

- Prueba de carga
- Prueba de estrés
- Prueba de estabilidad
- Prueba de concurrencia

3.1 PRUEBA DE CARGA

La prueba de carga determina el rendimiento de un sistema en condiciones de carga de la vida

real, la prueba de carga implica aplicar estrés ordinario a una aplicación de software o sistema
para ver si puede funcionar como se espera en condiciones normales.

Esta prueba generalmente identifica:

- La capacidad operativa máxima de una aplicación.

- Determina si la infraestructura actual es suficiente para ejecutar la aplicación.
- Sostenibilidad de la aplicación con respecto a la carga máxima de usuarios.
- Número de usuarios simultáneos que una aplicación puede admitir.

A continuación, se lista algunas razones por las que es importante realizar las pruebas de carga:

- Las pruebas de carga dan confianza en el sistema.

10
 - La prueba de carga ayuda a identificar los cuellos de botella en el sistema en situaciones
de carga de usuarios pesados antes de que ocurran en un entorno de producción.
- Las pruebas de carga ofrecen una excelente protección contra el rendimiento deficiente y
se adaptan a estrategias complementarias para la gestión del rendimiento y la supervisión
de un entorno de producción.

Las pruebas de carga identifican los siguientes problemas antes de mover la aplicación al
mercado o producción:

- Tiempo de respuesta para cada transacción.

- Rendimiento de los componentes del sistema bajo diferentes cargas.
- Rendimiento de los componentes de la base de datos bajo diferentes cargas.
- Retraso de red entre el cliente y el servidor.
- Problemas de diseño de software.
- Problemas de configuración del servidor como servidor web, servidor de aplicaciones,
servidor de bases de datos, etc.
- Problemas de limitación de hardware como la maximización de la CPU, limitaciones de
memoria, cuello de botella de la red, etc.

Las pruebas de carga determinarán si es necesario ajustar el sistema o si se requiere una

modificación del hardware y el software para mejorar el rendimiento.

3.2 PRUEBA DE ESTRÉS

La prueba de estrés determina el límite en el que la aplicación se rompe al ser sometida a

condiciones de carga extrema, lo que permite verificar si el sistema demuestra una gestión eficaz
de errores en éstas condiciones. La prueba de estrés (Stress Testing) se realiza para garantizar
que la aplicación no se bloquee en situaciones de crisis.

Las pruebas de estrés también son importantes por las siguientes razones:

- Verificar el funcionamiento del sistema en condiciones anormales.

- Mostrar el mensaje de error apropiado cuando el sistema está bajo tensión.
- Realizar un plan de gestión de riesgos ante una crisis en el sistema.

Existen diferentes tipos de pruebas de estrés, entre ellas:

- Prueba de estrés distribuida

- Pruebas de estrés de aplicación

11
 - Pruebas de estrés transaccional
- Pruebas de estrés sistémico
- Prueba de estrés exploratoria

A continuación, se describe de forma breve cada una de estos tipos de prueba de estrés:

a. Prueba de estrés distribuida: En los sistemas cliente-servidor distribuidos, las pruebas se

realizan en todos los clientes desde el servidor. La función del servidor de estrés es distribuir un
conjunto de pruebas de estrés a todos los clientes y realizar un seguimiento del estado del cliente.
Después de que el cliente contacta con el servidor, el servidor agrega el nombre del cliente y
comienza a enviar datos para la prueba.

Mientras tanto, las máquinas cliente envían una señal de que están conectados con el servidor.
Si el servidor no recibe ninguna señal de la máquina cliente, debe investigarse más a fondo para
la depuración. El horario nocturno es la mejor opción para ejecutar estos escenarios de pruebas
de estrés.

b. Pruebas de estrés de aplicación: Estas pruebas se concentran en encontrar defectos

relacionados con el bloqueo de datos, problemas de red y cuellos de botella de rendimiento en
una aplicación.

c. Pruebas de estrés transaccional: Se realiza pruebas de estrés en una o más transacciones

entre dos o más aplicaciones. Se utiliza para ajustar y optimizar el sistema.

d. Pruebas de estrés sistémico: Esta es una prueba de esfuerzo integrada que se puede probar
en múltiples sistemas que se ejecutan en el mismo servidor. Se utiliza para encontrar defectos
donde una aplicación de datos bloquea a otra aplicación.

e. Prueba de estrés exploratoria: Es uno de los tipos de pruebas de tensión que se utiliza para
probar el sistema con parámetros o condiciones inusuales que probablemente no ocurren en un
escenario real. Se utiliza en escenarios inesperados para encontrar defectos como:

- Gran cantidad de usuarios registrados al mismo tiempo.

- Si un antivirus se inicia en todas las máquinas simultáneamente.
- Si la base de datos se ha desconectado cuando se accede desde un sitio web.
- Cuando se inserta un gran volumen de datos simultáneamente en la base de datos.

12
El objetivo de las pruebas de estrés es analizar el comportamiento del sistema después de una
falla. Para que las pruebas de estrés tengan éxito, el sistema debe mostrar el mensaje de error
apropiado mientras se encuentra en condiciones extremas.

Para realizar la prueba de estrés, a veces, se pueden usar conjuntos de datos masivos que
pueden perderse durante la prueba de estrés. Los evaluadores no deben perder esta información
relacionada con la seguridad mientras realizan pruebas de estrés.

El objetivo principal de las pruebas de estrés es asegurarse de que el sistema se recupere

después de una falla.

3.3 PRUEBA DE ESTABILIDAD

Las pruebas de estabilidad, Soak Testing en inglés, es un tipo de prueba de rendimiento que
verifica las características de estabilidad y rendimiento de un sistema durante un período de
tiempo prolongado. Es típico en este tipo de prueba de rendimiento mantener un cierto nivel de
concurrencia del usuario durante un período prolongado de tiempo. Este tipo de prueba puede
identificar problemas como:

- Pérdidas de memoria graves, que puedan resultar en una falla de una aplicación o sistema
operativo.
- Errores al cerrar las conexiones entre las capas del sistema que podrían detener algunos
o todos los módulos.
- Errores al cerrar las conexiones de la base de datos bajo ciertas condiciones pueden
resultar en una falla del sistema completo.
- Degradación gradual del tiempo de respuesta del sistema en el que la aplicación se vuelve
menos eficiente durante una prueba prolongada.

Un método de prueba de estabilidad estándar debe tener las siguientes características:

- La duración de la mayoría de las pruebas de estabilidad a menudo está determinada por

el tiempo disponible.
- Cualquier aplicación debe ejecutarse sin ninguna interrupción pues requiere un período
de tiempo prolongado.
- Debe cubrir todos los escenarios acordados por las partes interesadas.

13
La mayoría de los sistemas tienen un período de tiempo de mantenimiento regular en la ventana
y el tiempo entre dichos períodos de ventana es un factor clave para determinar el alcance de
una prueba de mantenimiento.

Un sistema o aplicación web puede comportarse normalmente cuando se usa durante 2 horas,
pero cuando el mismo sistema se usa continuamente durante 10 horas o más, puede fallar o
comportarse de forma anormal, aleatoria o puede colapsar. Para predecir tal falla, es necesario
realizar pruebas de estabilidad.

3.4 PRUEBA DE CONCURRENCIA

La prueba de concurrencia, también conocida como prueba de simultaneidad o prueba

multiusuario, se realiza para identificar cómo la aplicación se ve afectada cuando varios usuarios
inician sesión al mismo tiempo y realizan la misma acción.

Cuando varios usuarios realizan la misma acción al mismo tiempo, puede haber problemas como
un mayor tiempo de respuesta o bloqueos de aplicaciones. Realizar una prueba de concurrencia
permite:

- Identificar los efectos de acceder a los mismos registros de bases de datos, módulos o
código de una aplicación al mismo tiempo.
- Identifica el punto muerto, bloqueo y uso de código de un único subproceso.

Los desafíos que se pueden encontrar al momento de realizar pruebas de concurrencia son:

- Necesidad de probar en múltiples plataformas.

- Requiere pruebas más intensivas
- Las funciones no devuelven su resultado a la persona que llama de inmediato, sino que
pueden entregarse más tarde a través de notificaciones, bloques, funciones de devolución
de llamada o mecanismos similares, lo que dificulta las pruebas.
- La información o el flujo del programa no se refleja en la pila de llamadas.
- El número de rutas de ejecución en el sistema puede ser extremadamente grande, por lo
que los procesos en un sistema concurrente pueden interactuar entre sí mientras se
ejecutan.
- Los programas concurrentes tienen más proporción de fallos que los secuenciales.
- Depuración de programas concurrentes.

14
Las pruebas de concurrencia ayudan a mejorar la confiabilidad y la solidez de los programas
concurrentes.

4. PROBLEMAS COMUNES DE RENDIMIENTO

La mayoría de los problemas de rendimiento giran en torno a la velocidad, el tiempo de respuesta,

el tiempo de carga y la escasa escalabilidad. La velocidad es a menudo uno de los atributos más
importantes de una aplicación, una aplicación de ejecución lenta perderá usuarios potenciales.

Las pruebas de rendimiento se realizan para garantizar que una aplicación se ejecute lo
suficientemente rápido como para mantener la atención y el interés del usuario [2].

A continuación, se listan problemas comunes de rendimiento:

a. Largo tiempo de carga: El tiempo de carga normalmente es el tiempo inicial que tarda una
aplicación en iniciarse. Este parámetro generalmente debe ser mínimo, el tiempo de carga debe
mantenerse en unos pocos segundos si es posible.

b. Tiempo de respuesta pobre: El tiempo de respuesta es el tiempo que lleva desde que un
usuario ingresa datos en la aplicación hasta que la aplicación emite una respuesta a esa entrada.
En general, esto debería ser rápido. Si un usuario tiene que esperar demasiado, pierde interés.

c. Pobre escalabilidad: Una aplicación web presenta escasa escalabilidad cuando no puede
manejar la cantidad esperada de usuarios o cuando no se adapta a un rango suficientemente
amplio de usuarios. La prueba de carga debe hacerse para asegurar que la aplicación pueda
manejar la cantidad de usuarios prevista.

d. Cuello de botella: Los cuellos de botella son obstrucciones en el sistema que degradan el
rendimiento general del mismo. El cuello de botella se produce cuando los errores de codificación
o los problemas de hardware provocan una disminución del rendimiento bajo ciertas cargas.

15
5. PROCESO DE PERFORMANCE TESTING

Si bien no existe una metodología exacta para las pruebas de rendimiento, el objetivo de toda
prueba de rendimiento sigue siendo el mismo, ayudar a demostrar que una aplicación o sistema
de software cumpla con criterios de performance predefinidos, e identificar las partes del sistema
que degradan el rendimiento.

En el gráfico 5.1 es posible visualizar el proceso general que se sigue en las pruebas de
rendimiento.

Gráfico 1: Proceso de pruebas de rendimiento. Fuente: guru99.com

a. Identificar el entorno de prueba: Es fundamental conocer el entorno físico de prueba, el

entorno de producción y las herramientas de prueba disponibles, así como comprender los
detalles del hardware, software y configuraciones de red utilizados durante las pruebas antes de
comenzar el proceso de verificación. Esto es útil para crear pruebas más eficientes y también
ayuda a identificar los posibles desafíos que los evaluadores pueden encontrar durante los
procedimientos de prueba de rendimiento.

b. Identificar los criterios de aceptación del rendimiento: Esto incluye los objetivos y las
limitaciones del rendimiento, los tiempos de respuesta y la asignación de recursos. También es
necesario identificar los criterios de éxito del proyecto fuera de estos objetivos y limitaciones. Los
evaluadores deben estar facultados para establecer los criterios y objetivos de rendimiento
porque a menudo las especificaciones del proyecto no incluyen una variedad lo suficientemente
amplia de parámetros de rendimiento. Encontrar una aplicación similar para comparar es una
buena manera de establecer objetivos de rendimiento.

c. Planificar y diseñar pruebas de rendimiento: determine cómo es probable que el uso varíe
entre los usuarios finales e identifique escenarios clave para evaluar todos los posibles casos de
uso. Es necesario simular una variedad de usuarios finales, planificar datos de pruebas de
rendimiento y delinear qué métricas se reunirán.

d. Configuración del entorno de prueba: Es necesario preparar el entorno de prueba antes de

la ejecución, ajustar las herramientas y otros recursos.

16
e. Implementar diseño de prueba: Consiste en crear las pruebas de rendimiento de acuerdo al
diseño de la prueba.

f. Ejecutar las pruebas: Se refiere a poner en marcha las pruebas y supervisar las mismas.

g. Analizar, ajustar y volver a probar: Una vez se consolide la prueba, se analiza y comparte
los resultados. Luego se realizan los ajustes necesarios y se prueba nuevamente para verificar si
existe una mejora o una disminución en el rendimiento [3].

6. IMPORTANCIA DE LA AUTOMATIZACIÓN DE LAS PRUEBAS DE RENDIMIENTO

Uno tiene que estudiar y analizar los resultados de rendimiento en múltiples permutaciones y
combinaciones para pruebas de rendimiento efectivas. La reducción del tiempo del ciclo de
prueba es una de las principales ventajas de la automatización de las pruebas de rendimiento.
Para una automatización exitosa de las pruebas de rendimiento, se debe de probar múltiples
cargas de trabajo con diferentes combinaciones de transacciones. Una automatización exitosa
de las pruebas de rendimiento debería proporcionar resultados de rendimiento instantáneos y
debería reducir los errores humanos al aislar las intervenciones humanas tanto como sea posible.
Además, las pruebas de rendimiento deben ser automatizadas de tal manera que sea posible
ejecutar la prueba por un principiante o por una persona menos capacitada. Una de las otras
ventajas principales de la automatización de las pruebas de rendimiento es la posibilidad de
programar la prueba en un momento no prioritario. [4]

7. HERRAMIENTAS PARA AUTOMATIZACIÓN DE PRUEBAS DE RENDIMIENTO

Existe una variedad de herramientas disponibles para realizar pruebas de rendimiento, se lista
algunas de las herramientas más populares.

7.1 JMETER

La aplicación Apache JMeter es un software de código abierto, una aplicación Java 100% pura
diseñada para cargar el comportamiento funcional de la prueba y medir el rendimiento.
Originalmente fue diseñado para probar aplicaciones web, pero desde entonces se ha expandido
a otras funciones de prueba.

17
Apache JMeter se puede usar para probar el rendimiento tanto en recursos dinámicos como
estáticos, aplicaciones web dinámicas.

Se puede usar para simular una gran carga en un servidor, grupo de servidores, red u objeto para
probar su fortaleza o analizar el rendimiento general bajo diferentes tipos de carga. [5]

Entre las características de Apache JMeter se incluyen:

- Capacidad de carga y prueba de rendimiento de muchos tipos diferentes de aplicaciones

/ servidor / protocolo:
- Web: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.)
- Servicios Web de SOAP / REST
- FTP
- Base de datos a través de JDBC
- LDAP
- Middleware orientado a mensajes (MOM) a través de JMS
- Correo: SMTP (S), POP3 (S) e IMAP (S)
- Comandos nativos o scripts de shell
- TCP
- Objetos Java
- IDE de prueba con todas las funciones que permite la grabación rápida del plan de prueba
(desde navegadores o aplicaciones nativas), construcción y depuración.
- Modo de línea de comandos (modo no GUI / sin cabeza) para cargar la prueba desde
cualquier SO compatible con Java (Linux, Windows, Mac OSX, ...)
- Un informe HTML completo y listo para presentar.
- Correlación sencilla mediante la capacidad de extraer datos de los formatos de respuesta
más populares, HTML, JSON, XML o cualquier formato de texto
- Portabilidad completa y pureza 100% Java.
- El marco completo de subprocesos múltiples permite el muestreo simultáneo mediante
varios subprocesos y el muestreo simultáneo de diferentes funciones mediante grupos de
subprocesos separados.
- Caché y análisis / reproducción fuera de línea de los resultados de las pruebas.
- Núcleo altamente extensible:
- Los complementos permiten capacidades de prueba ilimitadas.

18
 - Complementos de secuencias de comandos (lenguajes compatibles con JSR223
como Groovy y BeanShell)
- Se pueden elegir varias estadísticas de carga con temporizadores conectables.
- Los complementos de análisis y visualización de datos permiten una gran
extensibilidad y personalización.
- Las funciones se pueden utilizar para proporcionar una entrada dinámica a una
prueba o para proporcionar manipulación de datos.
- Fácil integración contínua a través de bibliotecas de código abierto de terceros
para Maven, Gradle y Jenkins.

JMeter no es un navegador, funciona a nivel de protocolo. En lo que respecta a servicios web y

servicios remotos, JMeter se parece a un navegador (o más bien, a múltiples navegadores); sin
embargo, JMeter no realiza todas las acciones admitidas por los navegadores. En particular,
JMeter no ejecuta el código Javascript que se encuentra en las páginas HTML y tampoco
representa las páginas HTML como lo hace un navegador.

7.2 LOAD RUNNER

Es una herramienta de prueba de software de Micro Focus. Se usa para probar aplicaciones,
medir el comportamiento del sistema y el rendimiento bajo carga. LoadRunner puede simular
miles de usuarios al mismo tiempo utilizando software de aplicación, grabando y luego analizando
el rendimiento de los componentes clave de la aplicación.

LoadRunner simula la actividad del usuario generando mensajes entre los componentes de la
aplicación o simulando interacciones con la interfaz del usuario, como pulsaciones de teclas o
movimientos del mouse. Los mensajes y las interacciones que se generarán se almacenan en
secuencias de comandos. LoadRunner puede generar las secuencias de comandos grabándolas,
como el registro de solicitudes HTTP entre un navegador web de un cliente y el servidor web de
una aplicación. [6]

19
 Gráfico 2: Interfaz de LoadRunner. Fuente: automation-consultants.com

LoadRunner simula usuarios humanos mediante la creación de múltiples procesos simultáneos

conocidos como usuarios virtuales o Vusers (en Windows, los Vusers se implementan como
procesos o subprocesos). Cada Vuser ejecuta un programa simple llamado script. HP
LoadRunner consta de cuatro componentes principales, el generador Vuser, el generador de
carga, el controlador y el análisis de LoadRunner.

a. Generador Vuser: El Vuser Generator, o VuGen, se utiliza para crear, personalizar y depurar
scripts. Los scripts normalmente se crean registrando las acciones de un usuario humano en el
sistema que se prueba. Para grabar un script, los detalles de la aplicación bajo prueba se ingresan
en VuGen y VuGen inicia la aplicación en modo de grabación. El usuario luego realiza las
acciones del script en la aplicación bajo prueba con el VuGen grabando cada acción. Una vez
que finaliza la grabación, VuGen puede reproducir las acciones del usuario.

b. Generador de carga: El generador de carga crea múltiples Vusers (cada uno de los cuales se
implementa como un hilo o un proceso, dependiendo de la configuración) y asigna un script a
cada uno. Cada Vuser luego ejecuta su script durante la duración de la prueba. El generador de
carga no es un programa interactivo; se ejecuta en segundo plano sin interfaz de usuario. Inicia
y detiene los Vusers, y aplica cualquier opción y configuración en las instrucciones del
controlador.
20
c. Controlador: El controlador LoadRunner controla la ejecución de las pruebas de rendimiento.
Tiene una interfaz de usuario que permite configurar varios aspectos de la prueba, incluido el
número de Vusers, la secuencia de comandos que debe ejecutar cada Vuser y la duración de la
prueba. La interfaz de usuario también se utiliza para iniciar y detener pruebas e informar sobre
el progreso de la prueba mientras se está ejecutando.

d. Análisis de LoadRunner: Los resultados de cada prueba de LoadRunner se almacenan en

una base de datos separada. HP LoadRunner Analysis lee esta base de datos después del final
de la prueba y analiza y muestra los resultados. Los resultados incluyen los tiempos de respuesta,
el rendimiento y la salida de cualquier monitor que se haya configurado en el controlador antes
de la prueba. Los datos se pueden mostrar en una amplia variedad de formas. Incluyen gráficos
de granularidad variable, tablas y exportaciones a Microsoft Excel o a archivos .csv. Los datos
comúnmente analizados incluyen el número de Vusers activos en la prueba, el tiempo de
respuesta para cada transacción y el rendimiento de la transacción en el transcurso de la prueba;
y métricas clave de uso de recursos para los servidores de aplicaciones y servidores de bases
de datos del sistema bajo prueba.

7.3 WEB LOAD

Es una herramienta de prueba de carga que combina rendimiento, escalabilidad e integridad

como un proceso único para la verificación de aplicaciones web y móviles.

Brinda capacidades completas para administrar pruebas de rendimiento a gran escala en

entornos empresariales complejos. WebLOAD ofrece funciones avanzadas de scripting,
grabación y correlación automatizada, al tiempo que permite a las organizaciones automatizar las
pruebas de carga para una integración sin problemas de DevOps y una entrega continua. [7]

Algunas características importantes son:

- Creación de prueba simple, permite crear y ver su script de carga rápidamente con las
opciones de grabación y reproducción.
- Lenguaje de script JavaScript nativo para lógica de negocios más compleja y uso de
bibliotecas de funciones.
- Correlación automática de valores dinámicos.
- Soporte de Selenium y Perfecto Mobile para medir la experiencia del usuario real.
- Generación de carga en las instalaciones y en la nube mediante la integración de AWS
incorporada.

21
 - Integración con herramientas APM para identificar la causa raíz de cuellos de botella.
- Complemento de Jenkins para incorporar pruebas de carga en procesos de entrega
continua.
- Potentes herramientas de análisis e informes personalizables.
- Panel web para ver los resultados de las pruebas en tiempo real.

Gráfico 3: IDE WebLOAD. Fuente: softwaretestinghelp.com

El IDE incluye varias otras características para mejorar y agregar lógica a un script.

a. Configuración de HTTP y del cliente: Es posible ajustar y mejorar los scripts de prueba,
existen opciones de configuración HTTP enriquecidas para los navegadores, el almacenamiento
en caché, las cookies, la velocidad de conexión, etc. Durante la ejecución se puede dar
diferentes parámetros a diferentes usuarios virtuales.

b. Parametrización y validación: WebLOAD ofrece una función de parametrización mejorada

con muchos algoritmos para consumir los parámetros, por ejemplo, global, único, aleatorio,
secuencial, así como validación de respuesta.

22
c. Bloques de construcción: La herramienta ofrece la capacidad de arrastrar y soltar bloques
de construcción, como una llamada FTP o una transacción de apertura/cierre, directamente en
el script, donde se abre una ventana con los parámetros que se deben completar.

7.4 LOADVIEW

LoadView es una herramienta para pruebas de carga y estrés, capaz de realizar pruebas de carga
que escalan a miles de usuarios simultáneos. LoadView es una poderosa herramienta de prueba
de carga basada en la nube que puede ejecutarse en navegadores reales, así como realizar
tareas http para probar su sitio o aplicación web. En el transcurso de una sola prueba de carga,
puede generar millones de visitas simulando tiempos de carga máximos en un sitio web. Todos
los resultados de las pruebas se registran, se agregan y están disponibles en gráficos en línea
en tiempo real e informes detallados para ayudar a rastrear el tiempo de respuesta del sitio web
a medida que aumenta el número de usuarios simultáneos.

Hay dos tipos principales de pruebas que puede realizar con LoadView, pruebas de carga y
pruebas de estrés.

LoadView es una plataforma única con diferentes tipos de tareas de generación de carga
disponibles. Estas diferentes tareas van desde llamadas simples para descargar contenido hasta
interacciones complejas que simulan a usuarios reales interactuando con la aplicación web.

Aquí hay un desglose de los diferentes tipos de tareas disponibles:

a. HTTP/S: Las tareas HTTP/S pueden ser tan simples como enviar solicitudes GET o POST al
servidor web y esperar la respuesta, o pueden ser más complejas para incluir la descarga de
cada elemento de la página. También hay opciones para descargar solo ciertos tipos de
elementos, como imágenes o scripts.

Las tareas HTTP son únicas porque puede agregar varias tareas a una prueba de carga para que
se ejecute en una secuencia. Por lo tanto, también puede pasar variables de una tarea a la
siguiente, como las cookies de sesión.

b. Carga de la página del navegador real: La opción de monitoreo de página web (AKA
BrowserView) consiste en una sola tarea que registra las métricas de carga de página para todos
los elementos asociados con una sola página web usando un navegador web real. Para configurar
un monitor de una sola página en LoadView, es necesario especificar el navegador y la URL de
la página web, así como las palabras clave o las acciones de filtrado avanzado. Las acciones de

23
filtrado avanzado incluyen el filtro de elementos de red que permite excluir componentes
específicos de la prueba de carga.

c. Scripts interactivos de navegador real: También conocidos como tareas UserView, estas
secuencias de comandos se registran utilizando la herramienta de grabación de secuencias de
comandos EveryStep. Una diferencia importante entre LoadView y la mayoría de las otras
herramientas de prueba de carga es la capacidad de ejecutar interacciones de usuario con
secuencias de comandos utilizando un navegador real. Aunque también puede ejecutar un
conjunto básico de solicitudes sin interfaz, el poder real de LoadView está en la grabación de
scripts dinámicos con EveryStep y luego realizar la prueba desde navegadores reales. Hay más
de 40 navegadores diferentes entre los que se puede elegir para grabar un script, incluidos los
dispositivos móviles Google Chrome, Microsoft Internet Explorer, Android iOS y Blackberry, y
más.

El monitoreo de sitios web en navegadores reales significa que estará generando una carga real
a través de la interacción con Aplicaciones de Internet Enriquecidas (RIAs) como JavaScript,
AJAX, JQuery, AngularJS, HTML5, Silverlight, applets de java y más. Los navegadores sin
interfaz solicitarán la descarga de elementos, pero no pueden replicar llamadas adicionales
realizadas por dichos elementos interactivos en una página. Esto tiene la capacidad de crear
llamadas de recursos adicionales e interacciones con la base de datos, creando así una
simulación más realista de la carga real de usuarios en la aplicación web.

d. Especificar palabras clave y umbrales de tiempo de espera: Con los scripts creados con
EveryStep se puede especificar palabras clave que se espera que aparezcan siempre en la
página una vez se encuentre cargada, y si esto no ocurre, se considera que la sesión de prueba
individual ha fallado. También se puede establecer un tiempo de espera de sesión, por lo que; si
cualquiera de las sesiones en la prueba de carga toma más tiempo que el período especificado,
las sesiones también se considerarán un fracaso. Todas las fallas se registran y se pueden
identificar en un gráfico de rendimiento.

e. Análisis de pruebas de carga: Mientras realiza una prueba de carga, es posible visualizar los
resultados en tiempo real a medida que cada sesión llega al servidor y registra los tiempos de
respuesta de las sesiones y páginas individuales. Si se observa picos en los tiempos de carga o
un aumento en los errores detectados, se puede seleccionar sesiones individuales para
profundizar y ver los tiempos de respuesta elemento por elemento y los errores para identificar
áreas problemáticas. Una vez que se completa una prueba de carga, también se puede descargar
24
un archivo que contiene todos los resultados de las pruebas para un análisis más detallado. Los
resultados permiten identificar el número máximo de usuarios simultáneos que causan problemas
con un sitio web o elementos individuales que deben optimizarse para manejar una carga de
usuarios más significativa.

8. MEMORY LEAK

Una fuga de memoria (más conocido por el término inglés memory leak) es un error de software
que ocurre cuando un bloque de memoria reservado no es liberado en un programa de
computación. Comúnmente ocurre porque se pierden todas las referencias a esa área de
memoria antes de haberse liberado.

Dependiendo de la cantidad de memoria perdida y el tiempo que el programa siga en ejecución,

este problema puede llevar al agotamiento de la memoria disponible en la computadora.

Este problema se da principalmente en aquellos lenguajes de programación en los que el manejo

de memoria es manual, y por lo tanto es el programador el que debe saber en qué momento
exacto puede liberar la memoria. Las fugas de memoria en lenguajes como JavaScript también
son comunes, pueden ocurrir cuando hay referencias circulares entre los objetos. Otros lenguajes
utilizan un recolector de basura o conteo de referencias que automáticamente efectúa esta
liberación. Sin embargo, todavía es posible la existencia de fugas en estos lenguajes si el
programa acumula referencias a objetos, impidiendo así que el recolector llegue a considerarlos
en desuso.

8.1 EFECTOS DE MEMORY LEAK

Si una aplicación o sistema tiene una fuga de memoria y su uso de memoria aumenta
constantemente, generalmente no habrá un síntoma inmediato. Cada sistema físico tiene una
cantidad finita de memoria, y si la fuga de memoria no está contenida eventualmente causará
problemas.

La mayoría de los sistemas operativos de escritorio para consumidores modernos tienen una
memoria principal que está físicamente alojada en microchips RAM y un almacenamiento
secundario, como un disco duro. La asignación de memoria es dinámica, cada proceso obtiene
la cantidad de memoria que solicita. Las páginas activas se transfieren a la memoria principal
para un acceso rápido; las páginas inactivas se envían al almacenamiento secundario para dejar
25
espacio, según sea necesario. Cuando un solo proceso comienza a consumir una gran cantidad
de memoria, por lo general ocupa más y más de la memoria principal, esto empuja a otros
programas a un almacenamiento secundario, ralentizando significativamente el rendimiento del
sistema. Incluso si el programa con fugas termina, puede tomar algún tiempo para que otros
programas vuelvan a la memoria principal y para que el rendimiento vuelva a la normalidad.

Cuando se agote toda la memoria de un sistema, cualquier intento de asignar más memoria
fallará. Esto generalmente hace que el programa intente asignar la memoria para terminar por sí
mismo, o para generar un error de segmentación. Algunos programas están diseñados para
recuperarse de esta situación (posiblemente recurriendo a la memoria reservada previamente).

Algunos sistemas operativos tienen un límite de memoria por proceso, para evitar que un solo
programa acapare toda la memoria del sistema. La desventaja de esta disposición es que el
sistema operativo a veces debe reconfigurarse para permitir el funcionamiento correcto de los
programas que legítimamente requieren grandes cantidades de memoria, como los que tienen
que ver con gráficos, video o cálculos científicos.

Si la pérdida de memoria está en el núcleo, es probable que el sistema operativo falle. Las
computadoras sin administración de memoria sofisticada, como los sistemas integrados, también
pueden fallar por completo debido a una fuga de memoria persistente.

Los sistemas de acceso público, como los servidores web o los enrutadores, son propensos a
ataques de denegación de servicio si un atacante descubre una secuencia de operaciones que
puede desencadenar una fuga. Tal secuencia se conoce como un exploit.

8.2 IDENTIFICACIÓN DE FUGA DE MEMORIA

La fuga de memoria es común en los programas tradicionales. En los servicios web, lenguajes
de programación como Java, C # están diseñado para liberar automáticamente la memoria
cuando ya no se usa el objeto. Pero aún es posible que los objetos no se liberen, como en la
programación de java utilizando JDBC. Las fugas de memoria no solo aparecen en el lenguaje
de programación en los servicios web, sino también en algunas circunstancias en el servidor de
bases de datos. Si aparecen demasiadas conexiones al mismo tiempo, el servidor de la base de
datos no llega a soltar el cursor a tiempo en algunas circunstancias. La pérdida de memoria es
extremadamente difícil de detectar. Con poco uso de los servicios web, las pérdidas de memoria
rara vez se encuentran, ya que la prueba no genera suficiente uso del producto antes de que se

26
complete. Incluso a través de las pruebas de carga/estrés, aún es posible no encontrar pequeñas
fugas de memoria. [9]

Un patrón de "diente de sierra" de utilización de memoria puede ser un indicador de una pérdida
de memoria dentro de una aplicación, particularmente si las caídas verticales coinciden con
reinicios de esa aplicación.

Existen varias formas de luchar contra este problema. Una forma es el uso de un recolector de
basura incluso en el caso en el que éste no sea parte estándar del lenguaje. Otras técnicas
utilizadas son la adopción de esquemas de conteo de referencias o el uso de pools de memoria
(técnica menos popular, utilizada en el servidor Apache y en el sistema de versiones Subversion).

También hay herramientas para "explorar" un programa y detectar las fugas. Una de las
herramientas más conocidas es Valgrind.

9. CONTADORES DEL MONITOR DE RENDIMIENTO

Determinar si una aplicación presenta pérdida de memoria en Microsoft Windows generalmente

implica ver los contadores del Monitor de rendimiento e interpretar los resultados.

Los contadores individuales se organizan en objetos de rendimiento, que son simplemente

categorías en las que se almacenan los contadores del Monitor de rendimiento. Los contadores
individuales presentan el siguiente formato: Objeto / Contador de rendimiento. [12]

Para detectar una pérdida de memoria con el uso del Monitor de rendimiento, es de utilidad
supervisar los siguientes contadores:

a. Memoria / Contador de Bytes disponibles: Permite ver el número total de bytes de memoria
disponible. Este valor normalmente fluctúa, sin embargo; al tener una aplicación con pérdida de
memoria, este dato disminuirá con el tiempo.

b. Memoria / Contador de Bytes confirmados: Este valor aumenta constantemente en caso

que se produzca una pérdida de memoria, pues a medida que aumenta el número de bytes
disponibles de memoria, aumenta el número de bytes confirmados.

c. Proceso / Contador de Bytes privados: Muestra el número de bytes reservados

exclusivamente para un proceso específico. Si se produce una pérdida de memoria, este valor
tiende a aumentar constantemente.

27
d. Proceso / Contador de Bytes del archivo de paginación: Muestra el tamaño del archivo de
paginación. Windows usa la memoria virtual (el archivo de paginación) para complementar la
memoria física de una máquina. A medida que la memoria física de una máquina comienza a
llenarse, las páginas de la memoria se mueven al archivo de paginación. Es normal que el archivo
de paginación se use incluso en máquinas con mucha memoria. Pero si el tamaño del archivo de
paginación aumenta constantemente, es una señal de que se está produciendo una pérdida de
memoria.

e. Proceso / Contador conteo Identificadores: Las aplicaciones usan identificadores para

definir los recursos a los que deben acceder. En caso de que existiese una pérdida de memoria,
una aplicación a menudo creará controladores adicionales para identificar los recursos de
memoria. Por lo tanto, un aumento en el número de identificadores podría indicar una pérdida de
memoria. Sin embargo, no todas las fugas de memoria provocarán un aumento en el conteo de
identificadores.

10. PERFILADORES DE MEMORIA EN JAVA

La administración de la memoria es la mejor opción de Java y una de las muchas razones por la
cual los desarrolladores eligen Java en lugar de otras plataformas y lenguajes de programación.
En un escenario ideal, se crea objetos y Java despliega su Recolector de Basura (Garbage
Collector) para asignar y liberar memoria. Sin embargo, Java no es impecable; en la vida real, las
fugas de memoria ocurren y ocurre mucho en las aplicaciones Java. [13]

Existe muchas herramientas de monitoreo y diagnóstico que se pueden usar para identificar y
corregir fugas de memoria. Los perfiladores de Java son una buena forma de rastrear fugas de
memoria y ejecutar el recolector de basura manualmente. Los perfiladores de Java permiten
monitorear cómo se está utilizando la memoria, y muestra que procesos y clases usan demasiada
memoria cuando no deberían hacerlo.

Las herramientas de creación de perfiles de Java permiten tener una visión más detallada de
cómo la aplicación está utilizando la memoria y otros recursos, en lugar de revisar el código para
encontrar problemas, el uso de estas herramientas contribuye al ahorro de esfuerzo y tiempo para
garantizar que el código sea correcto.

28
Estas herramientas brindan un conjunto completo de estadísticas y otra información que se puede
usar para rastrear errores de codificación. También es útil para encontrar lo que realmente está
causando una disminución del rendimiento, problemas de subprocesos múltiples y pérdidas de
memoria. En resumen, dan una aplicación más estable y escalable. Lo más rescatable, es que
las herramientas de creación de perfiles de Java pueden ofrecer un análisis detallado de cada
problema y cómo resolverlo.

Si se usa estas herramientas al inicio del proyecto y con regularidad, especialmente cuando se
usa junto con otras herramientas de rendimiento de Java, es posible crear aplicaciones eficientes,
de alto rendimiento, rápidas y estables. También puede ayudar a conocer problemas críticos
antes de implementar la aplicación.

Algunas de las métricas que se encuentran al usar las herramientas de perfiles de Java incluyen:

- El tiempo de CPU de un método

- Utilización de la memoria
- Información sobre llamadas a métodos
- Objetos que se crean
- Objetos que se eliminan de la memoria o recolector de basura

Entre las herramientas de diagnóstico y creación de perfiles en Java se tiene:

a. Analizador de memoria (MAT): Permite analizar el heap Java para buscar el aspecto de la
memoria y disminuir su uso. Permite analizar fácilmente los volcados de pila incluso cuando
existen millones de objetos en ellos, y ver los tamaños de cada objeto y examinar porque el
recolector de basura no los elimina de la memoria. Se puede obtener un informe sobre estos
objetos, lo que ayuda a reducir las sospechas de fugas de memoria.

b. Java Flight Recorder: Java Flight Recorder es básicamente una herramienta de diagnóstico
y creación de perfiles que brinda más información sobre una aplicación en ejecución. Proporciona
mejores datos que los proporcionados por otras herramientas, permite API’s creadas por servicios
de terceros y reduce el costo total de propiedad. Una función comercial de Oracle Java SE, Java
Flight Recorder, brinda una manera fácil de detectar fugas de memoria, encontrar las clases
responsables y localizar la fuga para corregirla.

c. NetBeans Profiler: Herramienta que admite Java SE, Java FX, EJB, aplicaciones móviles y
aplicaciones web, y útil para monitorear recursos de memoria, subprocesos y CPU.

29
d. JProfiler: Una herramienta de creación de perfiles de CPU, memoria y subprocesos que
también es útil para analizar fugas de memoria y otros cuellos de botella de rendimiento.

e. GC Viewer: Una herramienta de código abierto que permite visualizar fácilmente la información
producida por JVM. Útil para ver las métricas de rendimiento relacionadas con la recolección de
basura, incluidas las pausas acumuladas, las pausas más largas y el rendimiento. Además de
que permite ejecutar el recolector de basura.

f. VisualVM: Basado en la plataforma NetBeans, VisualVM es una herramienta fácilmente

extensible que utiliza una variedad de complementos. Obtiene datos detallados sobre sus
aplicaciones, y estos datos pueden usarse para monitorear aplicaciones tanto remotas como
locales. Puede obtener perfiles de memoria y ejecutar manualmente el recolector de basura con
esta herramienta.

g. JRockit: Es una solución patentada de Oracle, JRockit es para aplicaciones Java SE y puede
usarse para predecir la latencia. Permite visualizar el recolector de basura y clasificar los
problemas relacionados con la memoria.

h. GCeasy: Es una herramienta que analiza los registros relacionados con el recolector de
basura. Es una forma fácil de detectar problemas de fugas de memoria a medida que se analizan
los registros de recolección de basura. GCeasy está disponible en línea; y no es necesario
instalarlo en un equipo para utilizarlo.

11. CONCLUSIONES

El propósito de las pruebas de rendimiento proporciona a sus inversores un alto nivel de

confianza; en cuanto a la capacidad de una aplicación web para manejar grandes volúmenes y
patrones de tráfico antes de comenzar a funcionar.

Las pruebas de rendimiento tienen un papel fundamental en la medida en que contribuyen a la

entrega de un sistema o aplicación web que satisfaga con las expectativas de rendimiento del
cliente, realizarlas durante el proceso de desarrollo permite reducir los costos que provocaría en
caso de encontrarse fallas en el rendimiento en la finalización del producto.

Probar el rendimiento web de un sitio es una parte importante del diseño web y el proceso de
optimización, un engranaje integral que une a la empresa y al consumidor.

30
Un problema que inevitablemente surge en los sistemas de software complejos de larga ejecución
es el uso de la memoria. En el peor de los casos, se manifiesta como un bloqueo después de
varias horas o días de ejecución debido que el sistema ha consumido toda la memoria disponible.

Otra posibilidad inevitable es que estos bloqueos de memoria insuficiente se detectan muy tarde
en el ciclo de desarrollo, justo antes de la fecha de entrega. O, peor aún, se encuentran después
de la entrega. Dado que los bloqueos tardan horas o días en ocurrir debido a la extensión de los
ciclos de prueba.

La prueba temprana y continua de los sistemas es la clave para evitar la entrega con pérdidas de
memoria. Para ello es importante configurar un sistema dedicado para las pruebas de estabilidad
(Soak testing). Esta prueba debe ejecutarse tan pronto como exista suficiente software
desarrollado para poder realizar cualquier funcionalidad significativa de manera repetitiva.

Para efectuar un control de calidad inteligente, es necesario tener en cuenta el análisis de pérdida
de memoria para evitar los bloqueos de aplicaciones o sistemas, antes de que el cliente lo
informe, asegurando así la entrega de software de alto rendimiento.

31
12. BIBLIOGRAFÍA

[1] Preimesberger, Chris J. (2018, Agosto 31). IT Science Case Study: How Walmart Embraced
Test Automation, Open Source. Obtenido de http://www.eweek.com/development/it-science-
case-study-how-walmart-embraced-test-automation-open-source

[2] Guru99. Performance Testing Tutorial: Types, Process & Important Metrics. Obtenido de:
https://www.guru99.com/performance-testing.html

[3] Wikipedia. Software performance Testing. Obtenido de

https://en.wikipedia.org/wiki/Software_performance_testing

[4] B. M. Subraya (2006, Enero 6). Integrated Approach to Web Performance Testing: A
Practitioner's Guide. IGI Global.

[5] Apache JMeter™. Jmeter. Obtenido de: http://jmeter.apache.org/

[6] Mar, Wilson. "LoadRunner architecture". Obtenido de: http://www.wilsonmar.com/

[7] Radview. WebLoad. Obtenido de: http://www.radview.com/

[8] J.D. Meier, Carlos Farre, Prashant Bansode, Scott Barber, and Dennis Rea (Noviembre 21,
2007). Performance Testing Guidance for Web Applications. Microsoft Press.

[9] Minglu Li, Xian-He Sun, Qianni Deng, Jun Ni (2004, Abril 28). Grid and Cooperative
Computing: Second International. Springer.

[10] Automation Consultants. LoadRunner, HP LoadRunner. Obtenido de:

https://www.automation-consultants.com/products/hp-products/hp-loadrunner/

[11] Software Testing Help. WebLOAD Review – Getting Started with WebLOAD Load Testing
Tool (2018, Junio 7). Obtenido de: https://www.softwaretestinghelp.com/webload-load-testing-
tool-review/

[12] Brien M. Posey. Finding memory leaks using Performance Monitor (2007, Febrero). Obtenido
de: https://searchwindowsserver.techtarget.com/tip/Finding-memory-leaks-using-Performance-
Monitor

[13] Stackify. What to Do About Java Memory Leaks: Tools, Fixes, and More (2017, Agosto 2).
Obtenido de: https://stackify.com/java-memory-leaks-solutions/

32