FACTORES CRÍTICOS EN PRUEBAS DE ESTRÉS EN
SISTEMAS DE INFORMACIÓN TRANSACCIONALES
Simba Germán, Soto Sandro, Gómez Estevan
Dirección de Postgrados; Escuela Politécnica del Ejército, Sangolquí, Ecuador
germansimba@hotmail.com; sandrosoto@hotmail.com , estevan.gomez@ute.edu.ec
Resumen
El presente trabajo se produce por la necesidad de
conocer y comprender los límites del desempeño
en los sistemas informáticos transaccionales, bajo
un enfoque de identificar los factores críticos
dentro de las pruebas de estrés de dichos sistemas.
Con el creciente uso del Internet y las aplicaciones
móviles, los sistemas convencionales han visto
incrementar considerablemente su volumen
transaccional debido a la popularidad en el uso de
estos canales. Se pretende realizar una revisión del
Estado del Arte en cuanto a pruebas de estrés, por
lo que se ha recurrido a varios autores que han
generado grandes aportes en este tema para lograr
determinar varias conclusiones y sugerencias a la
hora de montar una fase de pruebas de estrés. Los
resultados de esta investigación bibliográfica han
sido satisfactorios, ya que tienen su basamento en
metodologías y experimentación de situaciones
reales, los cuales dejan un precedente para ponerlas
en práctica y ante cualquier otro tipo de estudio que
se desee complementar.
Palabras clave: pruebas de estrés, sistemas
transaccionales, carga de trabajo, desempeño.
Abstract
This work has been produced by the need to know
and understand the limits of performance in
transactional information systems, with a focus on
identifying the critical factors in stress testing of
such systems. With the increasing use of Internet
and mobile applications, conventional systems
have considerably increased its transactional
volume due to popularity in the use of these
channels. Thus, it has resorted to several authors,
who have generated great contributions in this
issue, in order to get some conclusions and
suggestions determine when mounting a stress test
phase. The results of this work has been
satisfactory, as they have their foundation in
methodologies and testing of real situations, which
leave a precedent to implement them and to any
other type of additional study.
Keywordse: Stress Testing, Trasactional
Information System, Workload, performance.
I. INTRODUCCIÓN
Cuando se habla del correcto funcionamiento de
una aplicación se debe tener en cuenta la suma de
la totalidad de sus componentes. A un alto nivel
podemos definir estos componentes como como el
software de la aplicación y los servidores
necesarios para ejecutar el software, así como la
infraestructura de red que permite que los
componentes se comuniquen. Si cualquiera de
estas áreas tiene problemas, el rendimiento de la
aplicación es probable que no sea el necesario o el
aceptado.
Se podría pensar que todo lo que necesitamos hacer
para asegurar un buen rendimiento de las
aplicaciones que se observe el comportamiento de
cada una de estas áreas bajo carga y el estrés y
corregir cualquier problema que ocurra. La
realidad es muy diferente, porque este enfoque es
a menudo "demasiado poco, demasiado tarde" y
por lo que terminan hacer frente a los síntomas de
los problemas de rendimiento antes que la causa.
“La mala realización de las pruebas a un sistema
crea un costo neto de tiempo, dinero, y la pérdida
de prestigio en los usuarios de la aplicación y por
lo tanto no se pueden considerar confiables. Si una
aplicación es causa una sensación de beneficios,
su continuidad está definitivamente en terreno
inestable, sin mencionarla de los arquitectos,
diseñadores, programadores y probadores”
(Molyneaux, 2009)
El 2013 en el JavaOne 2013, Adam Bien, explicó
que la mayoría de las pruebas no se realizan bajo
condiciones del mundo real. Menciona que
importancia de las pruebas comienza después de
que las pruebas de unidad e integración han
evaluado que las funciones trabajen por su cuenta
–ahí es donde comienzan las pruebas de esfuerzo
(o estrés) del software. “Las pruebas de esfuerzo
encuentran fallas en la aplicación que simplemente
no se mostrarían en una sola instancia, el objetivo
se centra en determinar o validar características de
rendimiento del sistema o aplicación bajo prueba
cuando se someten a condiciones superiores a los
previstos durante las operaciones de producción.
Las pruebas de estrés también pueden incluir
pruebas centradas en determinar o validar
características de rendimiento del sistema o
aplicación cuando se somete a otras condiciones de
estrés, como la memoria limitada, suficiente
espacio en disco, o falla en el servidor. Estas
pruebas están diseñadas para determinar en qué
condiciones una aplicación fallará, cómo va a
fallar, y qué indicadores pueden ser monitoreados
para advertir de un fracaso inminente.”
Tener un plan de pruebas crea confianza en la
calidad de productos y disminuye los lanzamientos
fallidos.
Finalmente, un problema que comúnmente las
empresas se encuentran hoy en día, es con la
necesidad de probar en un corto plazo sus sistemas
bajo nuevas condiciones; por ejemplo, un sitio
Web u otro sistema basado en Internet. Este
problema generalmente se presenta cuando una
empresa está a punto de desplegar en su sitio Web
nuevas aplicaciones, o crear más servicios dentro
de él, por ejemplo su servicio de comercio
electrónico (Scarlart, 2002)
Con base a esto, se inicia el presente estudio a fin
de localizar los factores críticos de éxito que
permitan llegar a probar los límites en la capacidad
de los sistemas de información transaccionales.
II. MARCO TEÓRICO
La fase de pruebas es, a veces, incorrectamente
pensada como una actividad a realizar después de
que el desarrollo está terminado. Lo correcto sería
pensar que las pruebas sean realizadas en cada
etapa de desarrollo del producto.
El desarrollo tiene las siguientes etapas "Análisis
de Requerimientos", "Diseño", "Programación /
Construcción" y "Operación y Mantenimiento"
(Pressman, 2010), el proceso de control de la
calidad tiene que estar relacionado en cada una
dichas etapas. Si las pruebas están aisladas en una
única fase al final del ciclo, los errores pueden
generar costos exorbitantes. Por lo tanto, las
pruebas no deberían estar aisladas como una
actividad de control. Más bien, las pruebas deben
estar presentes en todo el ciclo de desarrollo del
software para llegar a un producto de calidad. El
Modelo en V ayuda a visualizar las actividades del
proceso de desarrollo y la correspondencia con las
actividades del proceso de pruebas durante el ciclo
de vida del desarrollo del software. Este modelo
representa la secuencia de pasos del desarrollo
describiendo las actividades y resultados que se
producen. El lado izquierdo representa la
descomposición de los requerimientos y la
creación de las especificaciones del sistema. El
lado derecho representa la integración de las partes
y su verificación.
Figura 1: Modelo en V del proceso de desarrollo
Para esto es importante saber los distintos de
pruebas existes.
2.1. PRUEBAS DINÁMICAS VS ESTÁTICAS
2.1.1. Dinámicas._Proporciona información en
tiempo de ejecución sobre el funcionamiento de un
software. Se logra a través de la instrumentación
del programa de prueba. (Martìnez, 2010)
En el tipo de pruebas dinámicas se hacen pruebas
al comportamiento de la aplicación. Esto es, se
revisa la respuesta física del sistema a variables
que no son constantes y cambian con el tiempo. En
ellas el software debe ser ejecutado basándose en
unos casos de prueba. Adicionalmente, implica
trabajar con el software, dada unas entradas
iniciales se valida si la salida es la esperada.
Las pruebas unitarias, las pruebas de integración,
las pruebas de sistema y las pruebas de aceptación
son algunas de las metodologías de pruebas
dinámicas.
2.1.2. Estáticas._Se lleva a cabo sin ejecutar el
software para testear y pueden ser detectados los
siguientes errores:
• Código inaccesible.
• Variables no usadas.
• Tipo de parámetro inconsistente.
• Funciones y procedimientos que no son
ejecutados.
• Posible violación a los índices de los
arreglos.
2.2. FUNCIONAL VS NO FUNCIONAL
(Myers, 2004)
2.2.1. Pruebas Funcionales
Son un proceso para procurar encontrar
discrepancias entre el programa y la especificación
funcional. Una especificación funcional es una
descripción exacta del comportamiento del
programa desde el punto de vista del usuario final.
Las pruebas funcionales son una actividad de caja
negra. Para realizar una prueba funcional, la
especificación se analiza para derivar un conjunto
de casos de prueba utilizando las diferentes
técnicas de caja negra.
2.2.2. Pruebas no funcionales
Se enfocan a tipos de prueba como las de
performance.
Se distinguen los siguientes tipos de pruebas no
funcionales
2.2.2.1. Pruebas De Volumen._ (Volume
Testing) son pruebas hechas a una aplicación de
software para un cierto volumen de datos. Este
volumen puede ser en términos generales, el
tamaño de la base de datos o también el tamaño de
un archivo de interfaz.
2.2.2.2. Pruebas De Usabilidad._ (Usability
Testing) Según la norma ISO/IEC 9126-1, la
usabilidad es la capacidad de un producto software
de ser entendido, aprendido, usado y atractivo para
el usuario, cuando es usado bajo unas condiciones
específicas. Por lo tanto, las pruebas de usabilidad
consisten en comprobar la adaptabilidad del
sistema a las necesidades de los usuarios, tanto
para asegurar que se acomoda a su modo habitual
de trabajo, como para determinar las facilidades
que aporta al introducir datos en el sistema y
obtener los resultados. Normalmente se mide la
respuesta del sujeto que hace las pruebas en 4
áreas: Eficiencia, exactitud, recordación y
respuesta emocional. Los resultados de la primera
prueba se usan como base y las siguientes se
comparan con esta para ver los niveles de mejora:
 Desempeño
 Exactitud
 Recordación
 Respuesta Emocional
2.2.2.3. Pruebas De Seguridad._ (Security
Testing) consisten en verificar los mecanismos de
control de acceso al sistema para evitar
alteraciones indebidas en los datos.
Las Pruebas de Seguridad pretenden medir la
Confidencialidad, Integridad y Disponibilidad de
los datos, desde la perspectiva del aplicativo, es
decir, partiendo de identificar amenazas y riesgos
desde el uso o interface de usuario final. Las
pruebas de seguridad pretenden medir y cuantificar
los riesgos a los cuales se ven expuestos los
aplicativos, tanto en la infraestructura interna
como externa, valiéndose de la filosofía del
Hacking ético. Las pruebas de seguridad simulan
un ataque informático desde cualquier perspectiva
(Internet, red interna, redes asociadas, acceso
remoto, etc.) para establecer qué tan posible sería
para un atacante, comprometer la seguridad de la
información y validar la posible ocurrencia de un
fraude.
2.2.2.4. Pruebas De Rendimiento._
(Performance Testing) El rendimiento del sistema
suele ser evaluado en términos de tiempo de
respuesta y tasas de rendimiento bajo diferentes
condiciones de procesamiento y de configuración.
Los problemas de rendimiento son a menudo el
resultado de una configuración del cliente o del
servidor, inadecuada o un problema de
construcción de la aplicación.
Las pruebas de rendimiento se dividen en los
siguientes géneros:
2.2.2.4.1. Pruebas De Carga (Load Testing)
Consisten en comprobar el funcionamiento del
sistema en el umbral límite de los recursos,
sometiéndole a cargas masivas. El objetivo es
establecer los puntos extremos en los cuales el
sistema empieza a operar por debajo de los
requisitos establecidos.
2.2.2.4.2. Pruebas De Estrés (Stress Testing)
Las pruebas de estrés tratan de la calidad de la
aplicación en el ambiente. La idea es crear un
ambiente más exigente del que la aplicación
tendría bajo cargas normales de trabajo. Esta es la
categoría más difícil y más compleja del testing ya
que requiere un esfuerzo conjunto de todos los
equipos.
2.2.2.4.3. Pruebas De Resistencia (Endurance
Testing) Las pruebas de resistencia se hacen para
determinar si la aplicación puede mantener una
carga continua. Durante estas pruebas, se
monitorea la utilización de la memoria para
detectar las posibles fallas. El objetivo es asegurar
que el rendimiento o los tiempos de respuesta
después de un largo periodo de actividad son tan
buenos como al inicio de la prueba o mejores.
2.2.2.4.4. Pruebas De Aislamiento (Isolation
Testing) Pruebas de los componentes individuales
de forma aislada a partir de componentes
circundantes para repetir la ejecución de una
prueba que dio lugar a un problema en la
aplicación. A menudo se utiliza para aislar y
confirmar el fallo.
2.2.2.4.5. Pruebas De Configuración
(Configuration Testing) Las pruebas de
configuración son otra variante de las pruebas de
rendimiento tradicional. En lugar de hacer las
pruebas de rendimiento desde la perspectiva de la
carga, lo que se prueba son los efectos de los
cambios de configuración en el rendimiento y el
comportamiento de las aplicaciones.
2.2.2.4.6. Pruebas De Comportamiento
Crítico._ (Spike Testing) Estas pruebas se realizan
aumentando el número de usuarios para entender
el comportamiento de la aplicación, para saber si el
rendimiento se verá afectado, si la aplicación
fallará o no, o si será capaz de manejar cambios
drásticos en la carga.
2.2.2.5. Pruebas De Compatibilidad._
(Compatibility Testing) Programas tales como
sistemas operativos, sistemas de gerencia de base
de datos, y programas de conmutación de mensajes
soportan una variedad de configuraciones de
hardware, incluyendo varios tipos y números de
dispositivos de entrada - salida y líneas de
comunicaciones, o diversos tamaños de memoria.
A menudo el número de configuraciones posibles
es demasiado grande para probar cada uno, pero en
lo posible se debe probar el programa con cada tipo
de dispositivo de hardware y con la configuración
mínima y máxima
2.2.2.6. Pruebas De Instalación
(Installation Testing) Algunos tipos de sistemas de
software tienen complicados procedimientos de
instalación. Las pruebas de los procedimientos de
instalación son una parte importante del proceso de
pruebas del sistema. Al funcionar incorrectamente
el programa de instalación podría generar una
experiencia desagradable al usuario con el sistema.
La primera experiencia de un usuario es cuando
instala la aplicación. Si esta fase se realiza mal,
entonces el usuario puede perder confianza en la
validez de la aplicación o incluso se pueden
generar errores en la aplicación debido a una mala
instalación.
2.2.2.7. Pruebas De Comunicación._
(Communication Testing) Pruebas que determinan
que las interfaces entre los componentes del
sistema funcionan adecuadamente, tanto através de
dispositivos remotos, como locales. Así mismo, se
realizan pruebas sobre las interfaces hombre -
máquina.
2.2.2.8. Pruebas De
Recuperación._(Recovery Testing) Pruebas no
funcionales que fuerzan el fallo del software de
muchas formas y verifican que la recuperación se
lleva a cabo apropiadamente.
2.2.2.9. Pruebas De
Almacenamiento._(Storage Testing) Los
programas tienen de vez en cuando objetivos de
almacenamiento que indican, por ejemplo, la
cantidad de memoria principal y secundaria que el
programa usa y el tamaño de los archivos
temporales. Se diseñan casos de prueba para
demostrar que estos objetivos de utilización de
recursos se satisfacen.
2.2.2.10. Pruebas De Documentación._
(Documentation Testing) Estas pruebas verifican
la calidad de la documentación, por ejemplo las
guías de usuario o los manuales de instalación. La
documentación del usuario debe ser el tema de una
inspección, comprobándola para saber si hay
exactitud y claridad. Cualquiera de los ejemplos
ilustrados en la documentación se debe probar.
2.2.2.11. Pruebas De Implantación._
(Resilience Testing) El objetivo de las pruebas de
implantación es comprobar el funcionamiento
correcto del sistema integrando el hardware y
software en el entorno de operación, y permitir al
usuario que, desde el punto de vista de operación,
realice la aceptación del sistema una vez instalado
en su entorno real y con base en el cumplimiento
de los requisitos no funcionales especificados.
III. ENFOQUE DE LA PRUEBA DE ESTRÉS
Las pruebas de estrés son pruebas de rendimiento
enfocadas en la determinación de la robustez de
una aplicación, la disponibilidad y la fiabilidad
bajo condiciones extremas. El objetivo de estas
pruebas es identificar los problemas de la
aplicación que pueden darse o ser evidentes sólo
bajo condiciones extremas. Estas condiciones
pueden incluir cargas pesadas, alta concurrencia, o
limitada recursos computacionales. Las pruebas de
estrés bien ejecutadas son útiles en la búsqueda de
errores de sincronización, problemas de bloqueo y
errores de pérdida de recursos. No se espera que el
sistema procese, por ejemplo, sobrecarga sin los
recursos adecuados, pero si se espera que su
comportamiento resulte de una manera aceptable,
por ejemplo, no se dañen o pierdan datos.
Las pruebas de estrés suelen incluir la simulación
de uno o más escenarios clave de producción bajo
una variedad de condiciones de estrés. Un caso
sería implementar la aplicación en un servidor que
ya está ejecutando una aplicación de uso intensivo
del procesador; de esta manera, las dos
aplicaciones compartirán recursos del procesador.
3.1. PRUEBAS DE ESTRÉS (Bansode & Meier,
2007)
Por otro lado, las condiciones de estrés pueden
incluir aspectos como:
 Un volumen excesivo en términos de usuarios o
datos;
 Reducción de recursos simulando una fallas de
discos.
 Sincronización inesperada.
 Apagones inesperados / recuperación
interrupción.
Mientras que los síntomas relacionados con el
estrés del sistema incluyen:
 Pérdida o daños de datos.
 La utilización de recursos sigue siendo
inaceptablemente alta después de eliminar el
estrés.
 Algunos componentes de la aplicación no
responde.
 Cuando se ejecutan pruebas de estrés o pruebas
de esfuerzo se tienen claramente definidas dos
grupos de entidades: entradas y salidas.
Para realizar las pruebas de estrés, es probable que
utilice como referencia uno o más de los siguientes
elementos de entrada o insumos:
 Los resultados de las pruebas de tensión
anteriores.
 Características de uso de aplicaciones
(escenarios).
 Los supuestos que se saben por la experiencia
sobre los escenarios que podrían dar problemas
en condiciones extremas.
 Características del perfil de carga de trabajo.
 La actual capacidad de carga máxima (obtenida
de las pruebas de carga).
 Hardware y arquitectura de red y datos.
 Evaluación del riesgo de desastres (por
ejemplo, la probabilidad de apagones,
terremotos, etc.).
Mientras que las salidas de una prueba de esfuerzo
puede incluir:
 Medidas de la aplicación bajo condiciones de
estrés.
 Los síntomas de la aplicación bajo tensión.
 Información del o los equipos que puede
utilizarse para hacer frente a la robustez, la
disponibilidad y fiabilidad
Los siguientes pasos están involucrados en una
prueba de estrés de una aplicación de base de
datos:
Paso 1 - Identificar objetivos de la prueba.
Identificar los objetivos de la prueba de esfuerzo
en términos de los resultados deseados de la
actividad de pruebas.
Paso 2 - Identificar escenario. Identificar el
escenario de aplicación o los casos para probar o
para identificar los problemas potenciales.
Paso 3 - Identificar la carga de trabajo. Identificar
la carga de trabajo que desea aplicar a los
escenarios identificados como críticos.
Paso 4 - Identificar las métricas. Identificar las
métricas que desea recopilar sobre el rendimiento
de la aplicación.
Paso 5 - Crear casos de prueba. Crear los casos de
prueba en el que se definen los pasos para ejecutar
una sola prueba, así como los resultados esperados.
Paso 6 - Simular carga. Utilice las herramientas de
prueba para simular la carga requerida para cada
caso de prueba y capturar los resultados de los
datos métricos.
Paso 7 - Analizar los resultados. Analizar los datos
métricas capturados durante la prueba. (Bansode &
Meier, 2007)
IV. METODOLOGÍA DE PRUEBAS DE
ESTRÉS
Generalmente, las metodologías empleadas para
este tipo de pruebas responden a técnicas y
prácticas basadas en el método empírico producido
por simple experimentación. Sin embargo, se
establecen varias fases dentro de un esquema
cíclico, donde cada iteración arrojará una serie de
conclusiones y mejoras para aplicar en la siguiente
iteración.
4.1.OBJETIVOS
Básicamente las metodologías deben perseguir dos
objetivos en común:
El objetivo de una metodología de prueba de estrés
es capturar la degradación del desempeño y
exponer los defectos del código interno, debido a
la combinación de la alta carga de trabajo y
deficiencia en la configuración del sistema.
Adicionalmente, se pretende seguir un enfoque
incremental, donde el sistema es probado desde su
configuración básica y carga normal de trabajo,
hasta llegar a una configuración más compleja y
mayor carga de trabajo, lo cual debe ser realizado
afinando la configuración de forma gradual.
4.2.HIPÓTESIS
Como parte de la metodología se presentan varias
hipótesis, mismas que deben ser comprobadas
(Meira, 2005):
1. Durante la prueba, la variación de la carga de
trabajo transaccional ejercita distintas partes del
código fuente del sistema y permite la
validación de diferentes funcionalidades
2. El sistema operativo (OS) no tiene efecto sobre
los resultados de las pruebas, sea que el mismo
defecto sea identificado en distintos tipos de OS
o el consumo de recursos permanece estable a lo
largo de la prueba.
3. El sistema manejador de base de datos DBMS
no utiliza todos los recursos asignados para la
carga de trabajo utilizada en la prueba.
V. CICLO DE UNA PRUEBA DE ESTRÉS
Por lo general, las metodologías empleadas para
este tipo de pruebas responden a técnicas basadas
en el método empírico; sin embargo, se establecen
varias fases contempladas dentro de una estrategia
iterativa, donde cada iteración o ciclo genera una
serie de conclusiones y mejoras para aplicar en la
siguiente iteración. Adicionalmente, se requiere de
un manejador de pruebas (test driver) el cual se
encarga de aumentar la carga para cada nueva
iteración, hasta gradualmente llegar al límite en el
cual el desempeño del sistema decae y
complementariamente localizar defectos en el
software.
Como entradas del manejador de pruebas se
requerirá de un módulo de programación que
registre las interacciones del usuario que se envían
al servidor de transacciones, incluyendo los
valores de los datos introducidos en las pantallas
del servidor transaccional, para poder generar una
prueba que sea adaptada (Weinberg, 2002).
Generalmente, una prueba de estrés debe
enmarcarse dentro de las siguientes fases:
1. Preparación del ambiente de pruebas.
2. Selección de la carga de trabajo.
3. Definición de los scripts y escenarios de prueba.
4. Ejecución de la carga.
5. Medición del desempeño y localización de
defectos.
6. Definición de mejoras para el afinamiento.
Figura 2: Ciclo de vida de una prueba de estrés
5.1. PREPARACIÓN DEL AMBIENTE DE
PRUEBAS
Esta fase debe enfocarse en definir los elementos
de hardware y software que intervendrán en la
instalación y configuración base del ambiente
computacional, lo que corresponde principalmente
a:
 Características de Hardware del servidor central
y servidores complementarios (Branch).
 Versión de OS, DBMS y aplicaciones de
servidor, sitio Web, etc.
 Plataforma de red y comunicaciones.
 Características de las estaciones de trabajo
5.2. SELECCIÓN DE LA CARGA DE TRABAJO
En esta fase se identifican las transacciones más
representativas dentro de la operativa normal del
sistema. Generalmente se hace uso de los logs de
las aplicaciones y de base de datos para obtener la
muestra transaccional.
Esta fase es clave para consolidar la conocida
mezcla transaccional, la cual proveniente de todos
los canales de conexión al sistema central y de esta
manera llegar a cubrir la mayor funcionalidad
posible.
Adicionalmente, es también factible determinar la
meta transaccional a la cual se quiere llegar.
5.3. DEFINICIÓN DE SCRIPTS Y ESCENARIOS
DE PRUEBA
Dentro de esta fase, se definen los scripts de
pruebas que contemplan el detalle de ejecución de
la carga y su secuencia. Para ello se utilizan
mecanismos como un manejador de pruebas o bien
llamados test drivers (Meira, 2005). Entre otros
aspectos se configura este manejador con la
cantidad de transacciones, número de ejecuciones
por transacción, intervalos de ejecución,
funcionalidades que se van a probar, entre otros.
Por otro lado, los escenarios de prueba contemplan
la configuración misma del sistema, lo que
involucra tomar factores como:
 Versiones de la plataforma: OS, DBMS,
Aplicaciones de servidor, entre otros.
 Cantidad de procesadores, cores o thread
asignados al motor de base de datos.
 Cantidad total de memoria RAM disponible.
 Subsistema de I/O, tipo de discos, espacio
disponible.
 Configuración de memoria RAM asignada al
manejador de base de datos, así como los caches
de datos.
 Configuraciones adicionales al DBMS
 Configuración de los aplicativos
La configuración básica que se determina en esta
fase corresponde a la línea base, sobre la cual se va
a comparar con los siguientes ciclos.
5.4. EJECUCIÓN DE LA CARGA
Corresponde a la ejecución de los scritps de prueba
a través de los mecanismos provistos por el
manejador de pruebas, para cada uno de los
escenarios definidos en la fase anterior. Esta tarea
debe realizarse dentro de una ventana de tiempo
definida, ejemplo 1 hora. Se debe previamente
haber probado los scripts para que no contengan
fallas en la ejecución de las transacciones y así no
desvirtuar los resultados.
5.5. MEDICIÓN DEL DESEMPEÑO Y
LOCALIZACIÓN DE DEFECTOS
Paralelo a la fase de ejecución de la prueba, se
incorpora este proceso de medición del desempeño
e identificación de defectos en el sistema.
Previamente, es necesario definir ciertos
parámetros e indicadores como son los siguientes:
 Promedio de CPU utilizado.
 Picos de uso de memoria.
 Cantidad de operaciones de I/O.
 Cantidad de transacciones por segundo (TPS)
 Porcentaje de errores.
 Tiempo promedio, máximo y mínimo de
respuesta.
 Tiempos muertos y períodos de latencia.
 Transacciones con tiempos más elevados.
 Cantidad de bloqueos entre procesos
Definidos estos índices y parámetros, se recurre a
herramientas especializadas para monitorear el uso
de recursos durante la ventana de tiempo de la
ejecución.
Como tarea adicional, se intenta localizar defectos
en las aplicaciones que bajo cargas normales no se
pudieran presentar. Estos defectos o errores
pueden clasificarse dependiendo de su origen en
DBMS o aplicaciones; además se debe identificar
el nivel de impacto que ellos generan, el cual puede
ser bajo, medio y alto.
5.6. DEFINICIÓN DE MEJORAS
Primeramente, se debe hacer una evaluación del
resultado de la prueba para determinar si la
configuración actual ha soportado la carga de
trabajo. Si no es así entonces se toma con mayor
importancia el análisis de resultados a fin de ajustar
el ambiente para el próximo ciclo con una mayor
carga.
Con ello, los resultados obtenidos en la fase de
monitoreo permitirán realizar análisis extensos e
intensificarlos según sea su impacto, los cuales
puedan generar recomendaciones a fin de:
 Indicar los ajustes de afinamiento a la
configuración del sistema en todos sus
elementos: OS, DMBS, aplicaciones.
 Determinar los cuellos de botella en alguno de
los componentes que conforman el sistema; y
optimizar los parámetros de configuración
relacionados.
 Identificar programas o aplicaciones que tienen
graves falencias de optimización, llegando a
determinar un plan de afinamiento de los
mismos.
Una vez determinadas las mejoras, se debe
elaborar un plan de ajustes para el nuevo ciclo de
prueba de estrés, contemplando el incremento de la
carga
VI. IDENTIFICACIÓN DE FACTORES
CRÍTICOS
A fin de cumplir con los objetivos de la
metodología y de la prueba en sí, se deben
identificar varios factores críticos que afectan en el
éxito de esta consecución, pero sobre todo en evitar
desviaciones o desvirtuar la prueba y sus
resultados.
6.1. FACTORES PRELIMINARES
Los siguientes puntos se enmarcan dentro de los
aspectos preliminares a tomar en cuenta antes de
iniciar un proceso de pruebas de estrés:
 El primer punto importante es entender que se
trata de un proceso donde existen varios ciclos
(iteraciones), hasta llegar progresivamente al
límite de la capacidad del sistema en cuestión.
Sin embargo, para sustentar la correcta
ejecución de la prueba es necesario tener las
siguientes consideraciones:
 La definición de un objetivo claro al llevar a
cabo la ejecución de este tipo de pruebas y el
aporte al mejoramiento del rendimiento del
sistema de producción, es un punto vital antes
de iniciar este proceso.
 Conformar un equipo técnico multidisciplinario
que comprenda principalmente administrador
de plataforma, administrador de base de datos,
arquitectos y programadores de aplicaciones,
los cuales ponga toda su experiencia y criterio
para llevar a cabo esta prueba y sobre todo
analizar sus resultados.
6.2. FACTORES TECNICOS
Los siguientes son aspectos netamente técnicos a
ser considerados propiamente como insumos para
las pruebas de estrés:
 Crear un ambiente computacional que
comprenda todos los elementos de la
arquitectura del sistema que se desea probar; de
manera que se refleje el sistema productivo con
las características de hardware y software.
 La selección de la carga de trabajo
transaccional, así como la mezcla transaccional
debe ser muy representativa, sugiriendo que un
porcentaje mayor o igual al 80% de las
transacciones correspondan a aquellas más
recurrentes y que tienen mayor impacto.
 Si se trata de un sistema actual de producción,
se considera otro factor clave en enfocarse en
una muestra proveniente de una hora pico en
días de alta carga, por ejemplo un sistema de
ventas en festivos, sistema de pagos en fin de
mes, etc.
 Incluir todos los canales que invocan
transacciones al sistema central, incluyendo
procesos en línea y procesos batch, a fin de
simular un escenario real. Esto es definitivo a
fin de contar con todos los elementos que
puedan incidir en los resultados.
 La calidad del universo de datos que se van a
utilizar como insumos de la prueba debe
corresponderá a datos consistentes e íntegros
para disminuir la probabilidad de errores de
ejecución de las transacciones.
6.3. FACTORES INTRINSECOS
Propiamente hablando ya de la ejecución de la
simulación, es importante resaltar los siguientes
factores como críticos a fin de lograr resultados
consistentes y valederos:
 Es indispensable realizar un monitoreo en el uso
de recursos del equipo y verificar si se está
llegando al límite del desempeño, incluyendo
signos de problemas o defectos que puedan
mostrarse bajo estas condiciones de alta carga.
 El análisis de los resultados obtenidos durante la
prueba, para la obtención de métricas (índices e
indicadores) fiables que identifiquen el grado de
disponibilidad y productividad del ambiente, es
requerido para determinar si se está llegando al
límite de las prestaciones.
 Finalmente, con los resultados obtenidos, se
debe comprobar si no se ha llegado al límite de
las capacidades del sistema; con lo cual se
puede realizar los ajustes a la configuración del
ambiente, a fin de preparase una vez más para
un nuevo escenario en el cual se aumentará la
carga.
 Meira, J. e. (2005). Stress Testing Of Transactional
VII. CONCLUSIONES Database Systems. Journal of Information and
1. La ejecución de una prueba de estrés viene Data Management.
delineada por factores que se aplican en
cada paso dentro de las fases de su ciclo de Molyneaux, I. (2009). The Art of Application
vida. Estos factores son definitivos para Performance. United States of America:
garantizar la efectividad de los resultados O’Reilly Media.
de la prueba y no desvirtuar ninguno de los
análisis que tienen por finalidad ajustar la Myers, G. J. (2004). The Art of Software Testing 2nd
configuración del sistema para altas cargas Edition. New York.
de trabajo.
2. Una estrategia iterativa e incremental prevé Pressman, R. (2010). Ingenieria del software. Un
que en cada nueva iteración o ciclo se enfoque practico. McGraw Hill.
manejen mayores volúmenes de carga, con
lo cual el sistema se comportará con una Scarlart, Y. e. (2002). Service for Load Testing a
menor medida de su desempeño normal, Transactional Server Over The Internet.
siendo el monitoreo en los distintos
elementos, el que determine donde está el o Weinberg, A. e. (2002). Software System And
los puntos donde se quiebra el sistema bajo Methods For Testing The Functionality Of A
estas cargas. Transactional Server.
3. La simulación de una carga de trabajo, bajo
condiciones normales debe incluir todos
los elementos del sistema de producción,
esto se refiere a todos los canales que se
comunican con el sistema central, a fin de
no dejar de lado componentes que pueden
resultar cuellos de botella bajo altas cargas.
4. Generalmente, las pruebas de estrés no se
llevan a cabo bajo un marco riguroso, por
lo cual, este estudio al menos pretende que
se tome en cuenta los aspectos claves de la
misma, para que los resultado no se
desvirtúen y reflejen el comportamiento del
sistema bajo altas cargas de trabajo.
5. Las bases de este estudio, permiten que
futuros trabajos puedan ahondar en estos
criterios; más aún, acorde a las nuevas
tecnologías se pueda identificar nuevos
criterios de éxito para el desarrollo
efectivos de las pruebas de estrés.

VIII. REFERENCIAS BIBLIOGRAFICAS

BIBLIOGRAFÍA
Bansode, P., & Meier, J. (2007). Performance Testing
Guidance for Web Applications.

Martìnez, M. F. (2010). FRAMEWORK PARA EL

PROCESO DE TESTING. MEDELLÍN.