Tesis de Grado - Crhistian Cardona Velasquez - CC …bdigital.unal.edu.co/930/1/8357252_2009.pdfA...
146
1
Transcript of Tesis de Grado - Crhistian Cardona Velasquez - CC …bdigital.unal.edu.co/930/1/8357252_2009.pdfA...
1
2
PROPUESTA METODOLÓGICA PARA LA REALIZACIÓN DE PRUEB AS DE
DE SOFTWARE EN UN AMBIENTES PRODUCTIVOS
CRHISTIAN DE JESÚS CARDONA VELÁSQUEZ
UNIVERSIDAD NACIONAL DE COLOMBIA
SEDE MEDELLÍN
FACULTAD DE MINAS
ESCUELA DE SISTEMAS E INFORMÁTICA
2009
3
PROPUESTA METODOLÓGICA PARA LA REALIZACIÓN DE PRUEB AS DE
DE SOFTWARE EN UN AMBIENTES PRODUCTIVOS
CRHISTIAN DE JESÚS CARDONA VELÁSQUEZ
Trabajo de grado presentado como requisito parcial para optar al título de
Ingenieros de Sistemas
Asesor: CARLOS MARIO ZAPATA
MEDELLÍN
UNIVERSIDAD NACIONAL DE COLOMBIA
FACULTAD DE MINAS
ESCUELA DE SISTEMAS E INFORMÁTICA
2009
4
NOTAS DE ACEPTACIÓN
____________________________________________
____________________________________________
____________________________________________
____________________________________________
PRESIDENTE DEL JURADO
____________________________________________
JURADO
____________________________________________
JURADO
____________________________________________
Medellín, 04 de Junio de 2009
5
CONTENIDO
Pág.
RESUMEN ...................................................................................................................................... 9
ABSTRACT .................................................................................................................................... 11
PALABRAS CLAVE ........................................................................................................................ 13
KEY WORDS ................................................................................................................................. 13
INTRODUCCIÓN ........................................................................................................................... 14
1 UNA REVISIÓN CRÍTICA AL PROCESO DE ELABORACIÓN DE PRUEBAS EN APLICACIONES DE
SOFTWARE. ................................................................................................................................. 15
1.1 PRUEBAS DE SOFTWARE ............................................................................................. 17
1.2 TAXONOMÍA DE LAS PRUEBAS EN APLICACIONES DE SOFTWARE. ............................ 19
1.3 ANÁLISIS DE TRABAJOS EXISTENTES ........................................................................... 22
1.3.1 CMMI .................................................................................................................. 22
1.3.2 ISO ...................................................................................................................... 24
1.3.3 IEEE ................................................................................................................... 28
1.3.4 TMM ................................................................................................................... 30
1.3.5 ISTQB ................................................................................................................. 32
1.3.6 LIMITACIONES DE LAS PRUEBAS DE SOFTWARE ............................... 33
2 CICLO-P: UN MÉTODO PARA EL ACOPLAMIENTO DE PRUEBAS AL CICLO DE VIDA DEL SOFTWARE .................................................................................................... 38
2.1 BASES TEÓRICAS SOBRE PRUEBAS DE SOFTWARE...................................................... 39
2.2 TRABAJOS RELACIONADOS Y DEBILIDADES ASOCIADAS ............................................. 42
2.3 PROPUESTA METODOLÓGICA ..................................................................................... 44
2.3.1 Precondiciones .................................................................................................... 45
2.3.2 CICLO-P: Proceso de pruebas acoplado al proceso de producción. ................... 46
2.3.3 Roles .................................................................................................................... 47
6
2.3.4 Tipos de pruebas ................................................................................................. 48
2.3.5 Flujo de proceso de CICLO-P acoplado al proceso de desarrollo de software ... 48
2.3.6 Métricas asociadas al seguimiento y control y a la estimación ........................ 148
2.3.7 Proceso de retroalimentación........................................................................... 149
3 ESTUDIO COMPARATIVO DE HERRAMIENTAS ESPECIALIZADAS EN PRUEBAS DE CARGA DE APLICACIONES WEB .......................................................... 151
3.1 ANÁLISIS TEÓRICO SOBRE HERRAMIENTAS DE CARGA EN APLICACIONES WEB ...... 153
3.1.1 Diferencia entre pruebas de carga, pruebas de rendimiento y pruebas de estrés.
154
3.2 Relación entre las pruebas de carga y el rendimiento del sistema. ......................... 155
3.3 Características a medir en el estudio comparativo................................................... 158
3.4 ANÁLISIS DE RESULTADOS ........................................................................................ 164
4 COMPARACIÓN DE HERRAMIENTAS PARA PRUEBAS DE CARGA: UN CASO DE ESTUDIO 191
4.1 MARCO TEÓRICO BASE PARA LA COMPARACIÓN .................................................... 193
4.2 Herramientas a utilizar y características generales .................................................. 195
4.3 CASO DE ESTUDIO ..................................................................................................... 197
4.4 Escenarios de prueba ................................................................................................ 202
4.5 INFRAESTRUCTURA A UTILIZAR ................................................................................ 205
4.6 Medidas a tener en cuenta ....................................................................................... 208
4.7 ANÁLISIS DE RESULTADOS ........................................................................................ 208
CONCLUSIONES ......................................................................................................................... 218
TRABAJO FUTURO ..................................................................................................................... 223
BIBLIOGRAFÍA ............................................................................................................................ 226
7
ILUSTRACIONES
Ilustración 1 - ISO/FDIS 9126 e ISO/IEC 14598 ........................................................................... 25
Ilustración 2 - Proceso de evaluación ISO/IEC 14598 ................................................................ 25
Ilustración 3 - Estructura del modelo ISO/IEC 15504 .................................................................. 28
Ilustración 4 - Etapas de CICLO-P ................................................................................................ 54
Ilustración 5 - Proceso de las pruebas de carga. Tomado de [1] .............................................. 153
Ilustración 6 - Gráfica de carga versus rendimiento. Tomado de [1] ....................................... 157
Ilustración 7 - Comportamiento carga versus tiempo mediante función constante incremental.
.................................................................................................................................................. 203
Ilustración 8 - Comportamiento carga versus tiempo mediante función trapezoidal. ............. 205
Ilustración 9 - Infraestructura de red. ....................................................................................... 207
Ilustración 10 - Consumo de Memoria y procesador herramienta WEBLOAD. ........................ 209
Ilustración 11 - Consumo de Memoria y procesador herramienta JMETER. ............................ 211
Ilustración 12 - Consumo de Memoria y procesador herramienta 4........................................ 212
Ilustración 13 - Consumo de Memoria y procesador herramienta QENGINE .......................... 213
Ilustración 14 - Consumo de Memoria y procesador herramienta NEOLOAD. ........................ 215
Ilustración 15 - Comparativa de Consumo de Memoria y procesador de las cinco herramientas
probadas. .................................................................................................................................. 216
8
TABLAS
Tabla 1 - Clasificación de pruebas de software vs ciclo de desarrollo ........................................ 20
Tabla 2 - Herramienta de nivel bajo. ......................................................................................... 167
Tabla 3 - Herramienta de nivel medio. ..................................................................................... 176
Tabla 4 - Herramienta de nivel avanzado. ................................................................................ 183
9
RESUMEN
Las pruebas de software como parte de los planes de aseguramiento de la
calidad ofrecen a los productos de software la posibilidad de identificar y
remover los defectos que surgen dentro del proceso productivo. La
estandarización por parte de diferentes organismos ofrece diferentes formas de
implementar los procesos de pruebas, todos ellos con la característica común
de ser genéricos y basados en ciclos de madurez que permiten la medición y
optimización del mismo.
Los estándares y técnicas de pruebas de software, en general, no presentan un
grado de acoplamiento y especificidad mediante el cual el aseguramiento de la
calidad del producto sea tenido en cuenta en todas las etapas de desarrollo del
software. CICLO-P es un método que permite integrar el área de pruebas al
ciclo de desarrollo de software, este hecho permite mejorar el tiempo de
pruebas y los costos asociados. Adicionalmente, CICLO-P hace uso de una
variedad de tipos de pruebas que le permiten obtener un gran cubrimiento del
software bajo prueba con un impacto pequeño en el desarrollo del mismo.
Las pruebas de los productos de software enmarcadas en la tendencia
competitiva del mercado que en la actualidad se centra en brindar soluciones
informáticas con altos estándares de calidad, se han convertido en un
mecanismo vital para lograr la satisfacción del cliente. La utilización de
herramientas de carga y por ende el aseguramiento de la calidad de los
productos de software en términos de fiabilidad y eficiencia marcan las pautas
actuales en la construcción de aplicaciones web y por ende en las capacidades
10
de éstas para responder a las necesidades del mundo actual. Las pruebas de
carga específicamente, realizadas mediante herramientas que simulan
conexiones de usuarios virtuales en un mismo instante del tiempo, permiten
encontrar los puntos de quiebre de los aplicativos revelando así problemas de
arquitectura o configuración en condiciones de carga de usuarios y de procesos
excesivos; las herramientas que permiten realizar las pruebas de carga, sus
características y las ventajas comparativas que llevan a una división de las
mismas en varias categorías hacen parte del objetivo principal del presente
documento. Finalmente se demuestra una tendencia marcada de las empresas
productoras de dichas herramientas, que va dirigida a producir aplicaciones
integrales que permitan no solo realizar pruebas de carga, si no también a
ejecutar monitoreos globales y a aplicar automatización de pruebas funcionales
en un mismo entorno, siendo éste último tipo de soluciones de gran ayuda en el
ámbito de análisis de resultados y de toma de decisiones justo después de
terminar la ejecución de las pruebas.
Las pruebas de carga, permiten evaluar el comportamiento de una aplicación
de software bajo la influencia transaccional de determinado número de
usuarios. En la industria, predecir cómo se comportará una aplicación con
niveles de concurrencia específicos es de suma importancia y es por esto que
existen herramientas para realizar dichas predicciones. En este artículo, se
diseñan dos casos de prueba y se aplican a 5 herramientas de pruebas de
carga, para comparar sus características y comportamiento, con el fin de
suministrar criterios de selección para su uso.
11
ABSTRACT
The software tests as it leaves from the plans of securing of the quality offer to
software products the possibility of identifying and of removing the defects that
arise within the productive process. The standardization on the part of different
organisms offers different forms to implement the processes of tests, all with the
common characteristic of generic and being based on cycles of maturity that
allow to the measurement and optimization of he himself.
The standards and techniques for testing software, in general, do not exhibit a
degree of specificity and coupling whereby the quality assurance of the product
is taken into account at all stages of software development. CICLO-P is a
method that makes it possible to integrate the test area to the cycle of software
development, this enhances the testing time and associated costs. Additionally,
CICLO-P makes use of a variety of types of tests that allow you to a large
coverage of the software under test with a small impact on its development.
Testing software products covered by the competitive trend in the market which
currently focuses on providing software solutions with high quality standards
have become a vital mechanism to achieve customer satisfaction. The use of
tools for loading and hence the quality assurance of software products in terms
of reliability and efficiency mark the current patterns in the construction of web
applications and therefore in their abilities to meet the needs of the world today.
Load testing specifically undertaken by tools that simulate virtual user
connections in a single instant of time, can find points of breakthrough
applications revealing problems architectural or configuration in a position to
12
charge excessive users and processes; tools to perform load tests, their
characteristics and comparative advantages that lead to a division of the same
in several categories are part of the main objective of this document. Finally, it
shows a trend of companies producing these tools, which is intended to
produce integrated applications that allow not only perform load tests, but also
to implement and enforce global monitoring automation tests in the same
environment, since this Finally type of solutions of great help in the area of
performance analysis and decision-making just after completing the
implementation of evidence.
Load tests can be used for assessing software performance under transactional
influence of certain number of users. In software industry, it is important to
predict how a software application will behave at some specific concurrency
levels, and there are tools to perform such predictions. In this paper, we design
two test cases and we apply them to five load test tools, in order to compare
their features and behaviour. The final goal is the definition of use selection
criterion.
13
PALABRAS CLAVE
Pruebas de software, Ciclo de vida del software, artefactos de prueba, aseguramiento de la calidad, verificación y validación CMMI, ISO, plan de pruebas, casos de prueba, tipos de pruebas, técnicas de pruebas, reutilización de casos de prueba, pruebas por pares, prueba de carga, concurrencia, rendimiento.
KEY WORDS
Testing, Life cycle of software, Artifacts of test, Quality assurance, Verification,
Validation, CMMI, ISO, test plan, test case, test types, Testing techniques,
Reuse of test cases, test in pairs, load test, turnout, performance.
14
INTRODUCCIÓN
El presente es un trabajo en el cual se tratará el tema de pruebas de software y
se definirán algunos aspectos importantes para poder plantear en primera
instancia una metodología para realizar ciclos de pruebas en ambientes
productivos, y en segunda instancia, presenta el cómo realizar pruebas de
cargas en herramientas de tipo web y se presenta adicionalmente una
comparativa y un caso de estudio de una prueba de carga en una aplicación
web.
Es importante el contenido de éste trabajo ya que permite profundidad en el
tema de la calidad de software que actualmente forma parte de las
características esperadas de un software al entregarse a un cliente. El hecho
de conocer lo relacionado con las pruebas de software, su funcionamiento y su
posible ciclo acoplándose con técnicas y metodologías de punta ayudan a tener
una idea más clara a cerca de cómo se deben plantear entornos de alta calidad
en empresas que construyan y reciban software.
Se realizó mediante investigaciones en papers internacionales y libros
reconocidos de los cuales se relaciona la bibliografía. Es de aclarar que la
mayoría de los textos fue muy complejo conseguirlos ya que son demasiado
especializados.
15
1 UNA REVISIÓN CRÍTICA AL PROCESO DE ELABORACIÓN DE
PRUEBAS EN APLICACIONES DE SOFTWARE.
A través de la corta historia de la ingeniería de software las pruebas de
software se han convertido en una importante herramienta para el
aseguramiento de la calidad de los productos, debido a que ayudan a
comprobar que los productos de software satisfacen los requisitos del cliente.
Existen diferentes tipos de pruebas de software asociadas a determinadas
técnicas que establecen el grado de profundidad en el cual se diseñarán,
ejecutarán y evaluarán teniendo como referencia la estructura interna de la
aplicación; las principales técnicas son: Caja Blanca, Caja Gris y Caja Negra.
El proceso de pruebas de software tiene vinculadas limitaciones tales como: los
factores económicos, el recurso humano, el tiempo y la complejidad asociada a
los productos de software, las cuales han sido objeto de amplios estudios con
el fin de mitigar o eliminar sus consecuencias.
A nivel internacional existen organizaciones tales como: IEEE (Institute of
Electrical and Electronics Engineers), ISO (International Organization for
Standardization), CMU (Carnegie Mellon University), IIT (Illinois Institute of
Technolog), entre otras, que desarrollan metodologías como CMMI (Capability
Maturity Model Integration) y TMM(Testing Maturity Model) además de
estándares y buenas prácticas en el ámbito de las pruebas de software
ayudando a atenuar las limitaciones asociadas. Un organismo internacional que
16
la industria del software comienza a reconocer es el ISTQB (International
Software Testing Qualificatons Board), el cual se encarga de realizar
certificaciones de los probadores y de los procesos de pruebas usados al
interior de una organización.
Al surgir la ingeniería de software, la estandarización permitió que las pruebas
pasaran de un ámbito informal y poco fidedigno a una especificación formal, lo
cual introdujo procesos de pruebas que encajaban en metodologías y
estándares de desarrollo enfocados al mejoramiento continuo y la madurez de
los procesos; un ejemplo de éstos son los modelos CMM (Capability Maturity
Model) y CMMI(Capability Maturity Model Integrated) desarrollados por la
Carnegie Mellon University y el SEI [1], los cuales plantean áreas de procesos
dirigidas a verificación, validación y aseguramiento de la calidad; de forma
complementaria el modelo TMM (Testing Maturity Model) desarrollado en
Illinois Institute of Technology propone ciclos de pruebas basados en madurez;
éste surgió con el propósito de solventar las deficiencias del modelo CMMI e
ISO 9000 en el ámbito de pruebas de calidad de software dado que éstos no
manejan ni contemplan adecuadamente los tópicos de pruebas. En el modelo
TMM - a diferencia de otros, que se centran en testing de alto nivel estático –
se contempla niveles de testing de alto y bajo nivel de tipo estático y dinámico,
permitiendo un mayor nivel de refinamiento y madurez de los procesos de
prueba y logrando por ende mejores resultados [2].
Procesos como validación y verificación son implementados con el fin
responder a necesidades de pruebas específicas, estos utilizan mecanismos
como pruebas por pares, con el fin de asegurar que los objetivos de verificación
y validación se cumplan; respectivamente estas prácticas apuntan a establecer
que se contemplen los requisitos y a demostrar que el producto funciona como
se espera en su ambiente de trabajo. El SEI es el estamento internacional
17
encargado de mantener y soportar estas y las demás áreas de proceso
definidas por el ampliamente utilizado modelo CMMI [1].
En este artículo se realiza una revisión crítica del proceso de elaboración de
pruebas en aplicaciones de software y está organizado así: primero se
presentan las generalidades de las pruebas de software, en segunda instancia
se describen las taxonomías existentes referentes a las pruebas de software,
en tercer lugar se hace una revisión de los trabajos existentes en el área de
pruebas lo cual sienta las bases para argumentación de la cuarta y quinta parte
del artículo que se enfocan en las limitaciones y las dificultades de las pruebas
de software en la industria respectivamente. Finalmente se plantean las
conclusiones y el trabajo futuro ambas apuntando a las falencias encontradas
en los ítems anteriores.
1.1 PRUEBAS DE SOFTWARE
La definición de pruebas en el contexto del software tiene diferentes
connotaciones que en algunos casos llevan a malas interpretaciones. La
definición de pruebas de software de Myers es: “Las pruebas son el proceso de
ejecución de un programa con la intensión de encontrar errores” [3]; además,
ésta es una parte fundamental del aseguramiento de la calidad del software
(QA, por sus siglas en ingles), ya que ayuda a asegurar que el producto cumpla
con los requisitos [4][5]; sin embargo las pruebas de software no son QA, tan
solo son una parte de ella.
18
La industria del software a través de su historia ha encontrado la necesidad de
refinar tres aspectos fundamentales vinculados directamente a su proceso
productivo:
1. Los costos y el tiempo: la dificultad de planear proyectos de software
trae consigo problemas en la estimación de tiempos y por ende altos
costos asociados; la creación de métricas de software y procesos de
planeación eficientes han ayudado a amortiguar el peso de éstos
factores en el desarrollo del software.
2. La calidad: debido a la competitividad del mercado de software la calidad
se convierte en un factor determinante a la hora de comercializar los
productos. Igualmente, permite disminuir los tiempos de mantenimiento
al obtener productos con menor cantidad de errores inyectados y por
ende más confiables.
La importancia de las pruebas de software se puede visualizar teniendo como
referencia algunos autores:
• Las pruebas de software permiten pasar de forma confiable del cómodo
ambiente planteado por la ingeniería de software, es decir del
controlado ambiente de análisis, diseño y construcción, al exigente
mundo real en el cual los entornos de producción someten los productos
a todo tipo de fatiga [6].
• Las pruebas de software basadas en componentes permite la
reutilización y por ende la reducción de los ciclos de pruebas, lo cual se
ve reflejado en la disminución de costos y tiempos [7].
• La necesidad de productos de software de alta calidad ha obligado a
identificar y cuantificar factores de calidad como: capacidad de uso,
capacidad de prueba, capacidad de mantenimiento, capacidad de ser
medible, capacidad de ser confiable y a desarrollar practicas de
ingeniería que contribuyen a la obtención de productos de alta calidad
[8].
19
1.2 TAXONOMÍA DE LAS PRUEBAS EN APLICACIONES DE SOF TWARE.
Las pruebas de software se tipifican de acuerdo a los aspectos específicos que
se van a probar en el software. En la literatura existen diversos autores que
proponen taxonomías caracterizadas por su grado de profundidad o expansión.
La clasificación propuesta por Burnstein [8] se caracteriza por ser una
taxonomía generalizada, enfocada en tipos de pruebas típicos en la industria
del software. La clasificación incluye pruebas de: funcionalidad, de rendimiento,
de fatiga, de configuración, de seguridad y de recuperación.
Por otro lado existen taxonomías que buscan abarcar un conjunto de aspectos
más amplio en las pruebas, lo cual conduce a que éstas contengan una
expansión notable en la cantidad de tipos, ofreciendo una visión mas detallada
del horizonte de pruebas e influyendo positivamente en todo el proceso de
pruebas. Myers [3] clasifica los tipos de pruebas en: de locación, de volumen,
de fatiga, de capacidad de uso, de seguridad, de rendimiento, de
almacenamiento, de configuración, de compatibilidad y conversión, de
instalación, de capacidad de ser confiable, de recuperación, de utilidad, de
documentación, de procedimientos y de aceptación.
Las técnicas de pruebas de software constituyen un mecanismo conceptual
mediante el cual se pueden detectar defectos en el software. Si nos remitimos
a la taxonomía citada por Young y Taylor [9], se puede observar que se tipifican
las técnicas de pruebas de software teniendo en cuenta el ciclo de desarrollo
del mismo y su estado (característica estáticas o dinámicas). En la tabla 1 se
muestra dicha taxonomía.
20
Estáticas Dinámicas
Requisitos
Listas de chequeo
Informales
Modelamiento Formal
Pruebas funcionales
Pruebas por clases de
datos de entrada
Pruebas por clases de
datos de salida
Diseño Análisis estático de diseño
de documentos
Pruebas basadas en
diseño
Programación
Información general
Análisis estático de
errores
Ejecución simbólica
Pruebas estructurales
Pruebas de expresiones
Pruebas de flujo de datos
Tabla 1 - Clasificación de pruebas de software vs ciclo de desarrollo
Existen otras técnicas no clasificadas según su estado; es el caso de las
citadas por Burnstein [8] así:
1. Pruebas de tipo aleatorio: se generan los valores correspondientes a los
casos de pruebas de forma aleatoria teniendo en cuenta la
especificación de las entradas y en algunos casos las salidas – de forma
menos frecuente - . Algunos autores proponen técnicas de muestreo
aleatorio con restricciones [10][11] que permiten reducir la población
objetivo sin afectar los hallazgos de defectos.
2. Pruebas de partición de clases equivalentes: La población de entrada se
generan a partir del muestreo de conjuntos de valores llamados clases.
Las clases seleccionadas deben cubrir todo el dominio de valores de
entrada o salida y no deben traslaparse. Aunque existe una dificultad
asociada en el diseño de pruebas usando esta técnica, la probabilidad
21
de hallar defectos es bastante alta además elimina la necesidad de
realizar pruebas exhaustivas.
3. Pruebas de valores límite: Partiendo de la prueba de partición de clases
equivalentes se puede incorporar en los datos de pruebas, valores
limites de las clases particionadas, es decir, valores que se encuentran
en el borde de una u otra clase. Cuando se prueban los valores limites,
la probabilidad de encontrar defectos aumenta, dado que estos puntos
son los más susceptibles de contener errores.
4. Pruebas de suposición de error: La forma más intuitiva de seleccionar
valores de prueba es a través de la suposición de errores la cual se basa
en la experiencia del diseñador de pruebas. Esta técnica pretende
revelar defectos cuando se elijen valores del dominio de entrada que
producen determinados valores del dominio de salida.
5. Pruebas de transición de estados: Esta técnica se basa en el diagrama
de transición de estados construido para los objetos relevantes del
sistema. El diagrama de transición de estados presenta los diferentes
estados de un objeto y los eventos que generan las transiciones.
Cuando un diseñador de casos de prueba utiliza una técnica de
transición de estados tabula las combinaciones posibles que deben
ocurrir para que un objeto pase de un estado a otro. Esta información de
secuencia de eventos es utilizada por el probador para buscar falencias
en los estados y sus transiciones.
22
1.3 ANÁLISIS DE TRABAJOS EXISTENTES
1.3.1 CMMI
En CMMI [1], existen tres áreas de proceso (PA, por sus siglas en inglés) que
están dirigidas explícitamente a asegurar la calidad del software; éstas son:
1. QA o Aseguramiento de la Calidad: hace parte del segundo nivel de
madurez de CMMI (nivel gestionado) y su objetivo principal es que los
procesos y los elementos de trabajo cumplan los procesos; de ésta forma la
norma sugiere la realización de ciertas tareas para cumplir con dicha área
de proceso las cuales incluyen:
a) Evaluar objetivamente la ejecución de los procesos, los elementos de
trabajo y servicios contra las descripciones de procesos, estándares
y procedimientos.
b) Identificar y documentar los elementos no conformes.
c) Proporcionar información a las personas que están usando los
procesos y a los gestores de los resultados de las actividades del
aseguramiento de la calidad.
d) Asegurar que los elementos no conformes son corregidos.
Generalmente en la industria del software, al momento de implantar ésta
área de proceso se tiende a subcontratar las pruebas de software bajo el
modelo de “Outsourcing”. En otros casos la subcontratación no se da; en su
lugar se establece un área de pruebas al interior de la empresa ligada al
proceso productivo. En general los autores aseguran que la clave de éxito o
fracaso de los pruebas de software están asociadas a la subcontratación o
no de las mismas. Algunos como Myers [3] aseveran que la subcontratación
es vital para que la calidad del software sea conforme debido a que no se
23
sesgan los resultados de las pruebas. Contrariamente, otros autores dicen
que los procesos de aseguramiento de la calidad, específicamente los
relacionados con las pruebas de software, deben ir inmersos totalmente en
el proceso productivo de la organización, dado que la retroalimentación y su
interrelación agregan madurez a todo el proceso.
La verificación y la validación, pretenden en cualquier estándar (y
particularmente en CMMI [1]) convertirse en una herramienta para la
colaboración y el incremento del rendimiento del los equipos de trabajo,
permitiendo así la conformidad del producto final basada en altos
estándares de calidad [12].
2. Verificación: hace parte del tercer nivel de madurez en CMMI [1] (nivel
definido). Su propósito principal es el de asegurar que los productos de
trabajo seleccionados responden a los requisitos especificados. Sus
objetivos o metas específicas son: preparar la verificación, realizar
revisiones por terceros y verificar los productos de trabajo
seleccionados.
3. Validación: Hace parte del tercer nivel de madurez en CMMI [1] (nivel
definido). Su propósito es el de demostrar que un producto o
componente satisface su uso, en el ambiente operativo planeado. Sus
objetivos o metas específicas son: preparar la validación y realizar la
validación de los productos o componentes de trabajo.
Aunque ambas áreas de proceso no son consideradas como pruebas de
software directamente, si tiene un valor relevante a la hora de hacer que los
productos de software posean características de alta calidad. Las prácticas que
se derivan permiten realizar pruebas de software sobre productos más
maduros y confiables.
24
Es importante tener presente, que los procesos de pruebas no componen
totalmente área de proceso de aseguramiento de calidad; es así como las
pruebas proveen los elementos y prácticas de mejora con el fin de
retroalimentar los procesos.
1.3.2 ISO
La evaluación de la calidad de los productos mediante normas internacionales
es una práctica muy utilizada en la industrial del software actual dada la
relevancia de la calidad en la negociación de éste en el mundo contemporáneo
[13]. Tres de los documentos más importantes generados por la ISO que hacen
referencia a la calidad del software y a las pruebas son:
• ISO/FDIS 9126 [14][15][16][17][18] Information Technology — Software
Product Quality o Modelo de calidad de producto.
• ISO 14598 [19][20][21][22][23][24] Software Product Evaluation o
Evaluación del producto software
• ISO/IEC 15504 [25][26][27][28][29][30][31][32][33]: Modelo para la
mejora y evaluación de los procesos de desarrollo y mantenimiento de
sistemas y productos de software.
Los dos primeros documentos tiene una relación directa [34] y permiten
abarcar los principales aspectos de la producción conforme de las piezas de
software (ver Figura 1), el último es un modelo de madurez para la calidad
del software que se enfoca en evaluar los procesos, siendo éste compatible
con CMMI, pero no equivalente en cuanto a sus contenido y propósito
explícito.
25
Ilustración 1 - ISO/FDIS 9126 e ISO/IEC 14598
Ilustración 2 - Proceso de evaluación ISO/IEC 14598
26
El estándar ISO/FDIS 9126 es un estándar internacional para la evaluación del
software, supervisado por el proyecto SQuaRE ISO 25000:2005[17], el cual
sigue su misma filosofía. Se dividen en 4 partes: modelo de calidad [14],
métricas externas [15], métricas internas [16] y calidad en las métricas de uso
[17].
El modelo de calidad [14], las métricas externas [15] y las métricas internas
[16], describen los aspectos que se deben tener en cuenta para asegurar la
calidad externa e interna de un producto de software; entre ellos se encuentra
la funcionalidad, la fiabilidad, la capacidad de uso, la eficiencia, la capacidad de
mantenimiento y capacidad de ser portado.
La calidad en las métricas de uso [17] plantea 4 características por medio de
las cuales se puede evaluar la calidad de un producto, cada una de las cuales
mide la capacidad del mismo para satisfacerlas; dichas formas son: efectividad,
productividad, seguridad física o de acceso y satisfacción.
Los objetivos principales y aplicaciones más comunes son: validar e identificar
correctamente los requisitos, identificar los objetivos y especificaciones
conformes para el diseño y construcción del software, identificar los requisitos y
necesidades de las pruebas de software basados el modelo interno y externo
de calidad [35], identificar las necesidades para el aseguramiento de la calidad,
identificar los criterios de aceptación para el producto finalizado.
El estándar ISO/IEC 14598 (Ver Figura 2) compuesto por 6 partes, cubre los
temas en forma conjunta con el estándar ISO/FDIS 9126 y con una
estructuración que tiene concordancia bidireccional con el mismo, de ésta
27
forma se logra una interrelación entre dichos estándares que permite una
descripción más clara desde distintos puntos de vista del tema de la calidad del
software (Ver Figura 1). Las partes del estándar son: parte 1 [19]: visión
general, parte 2 [20]: planificación y gestión, parte 3 [21]: proceso para
desarrolladores, parte 4 [22]: proceso para adquisidores, parte 5 [23]: proceso
para evaluadores y parte 6 [24]: documentación de los módulos de evaluación.
También el estándar ISO/IEC 15504 (Modelo para la mejora y evaluación de
los procesos de desarrollo y mantenimiento de sistemas y productos de
software), conocido como proyecto SPICE [18] (Software Process Improvement
and Capability dEtermination) se enfoca en definir herramientas y metodologías
para realizar la evaluación de los procesos de construcción de software (ver
Figura 3). Sus características principales son:
1. Establece un marco para los métodos de evaluación de los procesos de
desarrollo de software, sin embargo no se considera un modelo o
metodología.
2. Contempla la evaluación de procesos, mejora de procesos y la
determinación de la capacidad.
3. Es concordante con el estándar ISO/IEC 12207 que define procesos del
ciclo de vida del desarrollo, mantenimiento y operación de los sistemas
de software.
4. Es compatible con CMMI, dado que ISO hace parte del proyecto CMMI y
el SEI mantiene la compatibilidad entre ambas normas.
Al interior de dicho estándar, se establece una arquitectura basada en dos
dimensiones:
• De proceso: agrupa los procesos en tres, que contienen cinco categorías
de acuerdo al tipo de actividad, así: procesos primarios (cliente,
proveedor, ingeniería), de soporte, organizacionales (gestión,
organización).
28
• De capacidad de proceso: se definen seis niveles para determinar la
capacidad de un proceso, así: nivel 0 (incompleto), nivel 1(realizado),
nivel 2 (gestionado), nivel 3 (establecido), nivel 4 (predecible), nivel 5 (en
optimización).
Ilustración 3 - Estructura del modelo ISO/IEC 15504
1.3.3 IEEE
La IEEE como organismo internacional encargado de desarrollar y mantener
estándares para temas ingenieriles define, además de recomendaciones para
pruebas unitarias, los estándares necesarios para realizar verificación y
validación junto con la información necesaria para desarrollar los planes de
aseguramiento de la calidad.
El estándar de validación y verificación, en contraparte con CMMI, indica cómo
se deben desarrollar los procesos específicos de Administración, Adquisición,
Alimentación, Desarrollo, Operación y Mantenimiento dentro del marco de
29
pruebas de software, igualmente trata la verificación y validación al nivel de
requisitos y describe los procesos de reporte, administración y documentación
[36]; este conjunto de procesos que están encaminados a Asegurar la Calidad
del software se unen al plan de aseguramiento de la calidad , también
estandarizado [37].
Es importante clasificar los errores para poder evaluar su gravedad y priorizar
las correcciones. La IEEE también ha estandarizado la clasificación de errores
[38] estableciendo diferentes niveles de criticidad para las anomalías así:
Crítico, Alto, Medio y Bajo, de esta forma una anomalía puede encontrarse en
uno u otro nivel dependiendo de que tanto afecta al sistema. El estándar es una
gran clasificación de diferentes tipos de errores que pueden ocurrir en las
diferentes fases del ciclo de vida del software. Así mismo define el proceso de
una anormalidad siguiendo las etapas discretas de: Reconocimiento,
Investigación, Acción y Disposición y sugiere el uso de herramientas de
“BugTracking”, ya sea comercial o desarrollada por los interesados, además de
la recolección y análisis de estadísticas con el objetivo de encontrar las
anomalías más comunes a fin de evitarlas en el futuro.
La IEEE cuenta entre sus publicaciones aquellas que abarcaban el ámbito de
las pruebas unitarias y buscan establecer las pruebas de software como un
proceso metodológico dentro del macro proceso de producción de software.
Con el tiempo la importancia de desarrollar buenas prácticas de pruebas ha
crecido, y por lo tanto la relevancia de estos estándares. La IEEE estandariza
las pruebas unitarias a través del siguiente conjunto de actividades
secuénciales: Planeación, Determinación, Refinamiento, Diseño,
Implementación, Ejecución, Comprobación y Evaluación. Este conjunto de
actividades debe incluir aspectos importantes como la Evaluación de riesgos
mientras se planea, el diseño de salidas y entradas en la fase de Diseño, la
30
ejecución y comprobación las entradas, las salidas y las tareas durante la
Ejecución y la Comprobación, entre otras [39].
Otros estándares como el de metodologías de métricas de calidad permiten
establecer requisitos enfocados en las métricas de calidad, así mismo ayudan a
identificar, implementar, analizar y validar las metodologías necesarias para
obtener las métricas que indiquen la calidad del software. Estas métricas son
sumamente importantes durante cualquier proceso de desarrollo, toda vez que
brindan estadísticas encaminadas a la mejora continua de los procesos al
interior de una organización [40].
1.3.4 TMM
TMM ha surgido como un complemento a CMM, y específicamente busca
acoplarse, de forma metodológica, a los procesos de pruebas. Al igual que
CMM, TMM es un modelo discreto basado en estaciones o niveles de madurez;
TMM define un conjunto de prácticas sistemáticas cuyo objetivo es soportar
procesos evolutivos de calidad.
Los objetivos de madurez del modelo son: planear y desarrollar las pruebas,
controlar y monitorear, prevenir defectos, evaluar y controlar la calidad, medir y
optimizar las pruebas; cada uno de estos objetivos se alcanza en los diferentes
niveles de madurez y el modelo como tal provee las actividades que se deben
realizar para obtener un proceso de pruebas metodológico y adaptable.
31
Cada uno de los cinco niveles de madurez (nivel 1: inicial, nivel 2: fase de
definición, nivel 3: integración, nivel 4: administración y medida, nivel 5:
optimización, prevención de defectos y control de calidad) están formados por
un conjunto de objetivos de madurez, un conjunto de objetivos específicos de
soporte de madurez y un conjunto de actividades, tareas y responsabilidades,
este último conjunto a su vez está organizado según la visión crítica del
administrador, el probador y el cliente. A través de esta organización TMM
busca la solidez del proceso al integrar a todos los actores relevante en los
detalles de las actividades de cada nivel [8][41].
Para alcanzar un nivel de madurez determinado deben ser implementadas un
conjunto de actividades propias de pruebas, de esta forma en el nivel 1 no
existen las pruebas propiamente, es una actividad desorganizada y confusa; en
el nivel 2 se utilizan técnicas y métodos básicos como caja negra, caja blanca y
también se deben iniciar los planes de pruebas; en el nivel 3 el proceso de
pruebas debe estar integrado al ciclo de vida del software, además de ser
medido y controlado, en el nivel 4 se tienen medidas cualitativas y se evalúa la
calidad del software, además de tener los casos de prueba en bases de datos
que permitan su reutilización y finalmente en el nivel 5 el proceso debe estar
optimizado y deben existir metodologías para la prevención de los defectos.
Este conjunto de áreas de proceso definidas en cada nivel conforman una guía
completa para la implementación de un proceso de pruebas sólido. La
elaboración y los detalles de implementación (al igual que en el modelo CMM)
escapan del alcance de TMM, dando libertad a quien adopta el modelo de
implementar los procesos de la forma más conveniente [42][43].
32
1.3.5 ISTQB
Considerando la importancia de las pruebas dentro del proceso de
aseguramiento de la calidad, y la de este último dentro del proceso de
producción de software, y dada la necesidad de certificación y cualificación, se
fundó en 2002 en Edimburgo el ISTQB, entidad encargada de otorgar la
certificación internacional en pruebas de software ISTQB.
El hecho que existan certificados internacionales para los probadores revela la
creciente necesidad de involucrar procesos de pruebas sólidos en el marco del
aseguramiento de la calidad. La certificación ISQTB estandariza y define los
conceptos más comunes de pruebas, así mismo ofrece una guía para el
desarrollo de pruebas de software, que permite unificar el lenguaje que los
probadores utilizan, además las técnicas practicadas durante el diseño y
ejecución de una prueba. Desde este punto de vista, ISTQB recoge
organizadamente las fases de pruebas mas importantes como son:
fundamentos de pruebas, ciclo de vida de las pruebas, planeación y manejo de
las pruebas y las herramientas más utilizadas; esta recopilación se establece
dentro de los programas que ISTQB ha desarrollado con el fin de certificar y
están divididos en dos esquemas diferentes: el básico y el avanzado, teniendo
esta último una mayor concentración en tópicos gerenciales como riesgos,
técnicas, costos, tiempos y administración de los recursos de pruebas.
La importancia de ISTQB mas allá de la certificación, es la estandarización de
la terminología, los procesos y manuales que se deben seguir para obtener una
metodología de pruebas robusta que permita definir sin ambigüedades el
modelo de pruebas concreto y genérico de tal forma que las especificaciones
33
particulares sean aportadas por la entidad o instituto que aplique a la
implementación de alguno de estos estándares [44].
1.3.6 LIMITACIONES DE LAS PRUEBAS DE SOFTWARE
Algunas de las limitaciones existentes a nivel de pruebas de software son:
• No existe una recopilación formal que especifique y describa los tipos de
prueba que se deben aplicar a una pieza de software y se detalle la
implementación precisa de cada uno de ellos. Aunque existen algunos
documentos, en su mayoría son de carácter muy académico y poco
práctico. Por otro lado, y aunque ISO plantea en normas como la ISO/FDIS
9126 ciertos aspectos en los cuales el producto de software debe ser
conforme, no es suficientemente especifico como para ligarlo con una
prueba de software con pormenores de ejecución, llevando esto a que a
que dicho estándar por si solo sea poco práctico.
• Las técnicas de pruebas generalmente son subestimadas como útiles, en
tanto que no se usan en la práctica para el diseño de casos de prueba
formales. En general y en entornos productivos, las técnicas utilizadas para
la detección de errores son del tipo suposición de errores y en el mejor de
los casos de tipo aleatorio el cual por sus características propias no es un
método que aporte mucho a la detección de errores en el producto de
software; todo esto se une a que habitualmente cuando se construyen
pruebas de software (casos de prueba) no se formaliza el uso de técnicas
específicas en tanto que no es considerado importante o no se cuenta con
el conocimiento y entrenamiento suficiente para su uso.
• TMM es un modelo de pruebas reciente y como tal poco maduro en su
interior. TMM está basado en CMM pero este hecho no implica que se
herede la experiencia y solides de CMM; por otra parte TMM no ha sido
sometido a revisiones que generen diferentes versiones, ni puesto
34
ampliamente en práctica en productos del mundo real, por lo cual las
deficiencias y problemas del modelo pueden no haber sido detectadas ni
corregidas. TMM es un modelo poco difundido en el ámbito de software
latinoamericano y pocas compañías a nivel global lo implementan o lo usan
dentro de sus procesos de calidad. A pesar de todo, la iniciativa de TMM es
bastante buena y debe ser sometida a la madurez que la industria y el
tiempo le confieran.
• Los estándares existentes que se refieren a pruebas de software y
aseguramiento de la calidad del producto tanto en ISO como en la IEEE
tienen un acceso muy restringido, siendo difícil lograr adquirir la
documentación relacionada. Adicionalmente, y basados en que dichos
estándares en la mayoría de los casos son muy específicos y aplicarlos sin
un modelo de calidad y desarrollo es sumamente difícil, modelos habituales
como CMMI e ISO 9000 no son tomados como referencia – en la mayoría
de los casos – para describir procedimientos o prácticas propias.
• Los estándares y modelos planteados en torno al aseguramiento de la
calidad de los productos de software por su carácter de universales y
genéricos son muy poco específicos a la hora de describir la forma de
realizar implementaciones en entornos productivos reales; en la mayoría de
los casos la generalidad es una de sus principales características. Esto
permite que su aplicación en diversos ambientes sea posible, pero limita las
prácticas a realizar puesto que deben ser diseñadas en su detalle por la
organización, lo cual en muchos casos exige un conocimiento experto y
asesorías externas que hacen a una compañía aferrarse a una práctica con
un conjunto de particularidades que no siempre son las mejores.
• Tomando en cuenta que una organización debe estar basada en un modelo
de calidad que permita un tratamiento global de los procesos, y que
adicionalmente deben existir un conjunto de estándares, reglas, prácticas y
normativas extras no especificadas en el modelo aplicado a la misma, es
importante comentar la inexistencia casi total de una descripción formal que
encierre en conjunto un modelo de calidad, un modelo de pruebas, una
metodología y unas prácticas específicas en pruebas de software que sean
35
concordantes entre si y entre las políticas generales de un modelo de
calidad determinado; en cambio de ello toda la información está
desagregada mediante modelos y estándares. Aunque ISTQB logra en
mediana medida generar cierta claridad a cerca de un conjunto de
actividades para el aseguramiento de la calidad del producto, por si solo no
se puede considerar como maduro y totalmente confiable, adicionalmente
se debe tener en cuenta, que cualquier modelo de pruebas, debe de una
forma u otra acoplarse al sistema de producción del producto de software lo
cual en gran medida no es contemplado a cabalidad por dicho organismo.
La ISTQB aunque en entornos académicos formales es poco reconocida, en
la industria se constituye como un organismo internacional encargado de
realizar certificaciones a nivel de pruebas de software teniendo como base
un conjunto de metodologías y características particulares, que a pesar de
basarse en estándares internacionales sigue siendo muy genérico y de
cierto modo descontextualizado de la realidad organizacional en la industrial
del software.
• La implementación de prácticas como verificación, validación y
aseguramiento de la calidad contempladas en CMMI y en normativas
específicas de la IEEE y la implantación de modelos como TMM específicos
de pruebas de software, suele ser sumamente difícil de implantar debido a
que requiere gran inversión por parte de de las organizaciones en recursos
como: personal capacitado, conocimiento y orientación experta, esfuerzo
adicional, tiempo, dinero, compromiso organizacional, entre otras [45].
Adicionalmente por ser modelos de calidad orientados a la madurez de los
procesos y los productos, los periodos de tiempo necesarios para que la
madurez llegue a un nivel deseable son relativamente largos, lo cual
conlleva a que aunque se logren avances en la calidad del los productos
paulatinamente se logra la madurez, solo se empieza a tener un esfuerzo
más proporcional al beneficio cuando todo el proceso es idealmente maduro
y la organización logra converger hacia las prácticas que plantea el modelo
de calidad general implantado.
36
• Los estándares diseñador por la ISO específicamente el ISO/FDIS 9126,
ISO 14598 e ISO/IEC 15504 presentan un nivel de complejidad variable al
momento de ser usados de acuerdo a la organización en donde se desee
implantar, sin embargo, una característica anexa, es que aunque es posible
su establecimiento en una organización que no cuenta de antemano con un
modelo de calidad ya preestablecido, lo recomendable y casi requisito no
especificado, es que si lo exista, ya que dichos estándares exigen
elementos como proceso definidos, políticas de aseguramiento de la calidad
claras, y prácticas que lleven a la madurez entre otras para cumplir sus
propios objetivos. Lo más común es tener modelos de calidad y de
mejoramiento continuo como ISO 9000 y CMMI con el fin de que la
aplicación de estándares de aseguramiento de calidad exigentes como los
mencionados tengan elementos suficientes como para que su adhesión a
los procesos organizacionales sea exitosa.
• La razón por la cual la industria no adopta metodologías y estándares es la
dificultad de la utilización de estos para pruebas de software. En las
pequeñas y medianas empresas la dificultad radica en la necesidad que
estas tienen de competir mediante tiempos y precios y dada la poco
practicidad que los estándares tienen asociados se incurre en consumos de
recursos poco tolerables; por otra parte las grandes compañías además de
los factores anteriores, compiten mediante calidad y para lograr un buen
indicador deben implementar los diferentes metodologías y estándares que
garanticen la madurez de los procesos, para estas compañías la falta de
practicidad de los estándares en más un requisito de sus clientes que un
riesgo asociado al uso de recursos.
• Implementar un proceso de pruebas al interior de una compañía es costoso,
además el proceso debe madurar para que se adapte a las necesidades
específicas de la organización; este hecho obliga a muchas empresas a
subcontratar los procesos de pruebas. En ocasiones esta es una buena
opción puesto que evita posibles sesgos en las pruebas pero en general
puede conllevar serios problemas al interior de la organización que van
37
desde la confidencialidad de la información hasta el incremento de los
tiempos de desarrollo.
• Las pruebas de software mas complejas basan su diseño y su ejecución en
los artefactos desarrollados en etapas de análisis y diseño; si estos
artefactos no son construidos o tienen deficiencias como falta de
consistencia y coherencia; aparte de afectar todo el proceso de desarrollo
se vera comprometido el aseguramiento de la calidad y dentro de esté las
pruebas los tipos de pruebas de software que buscan hallar defectos más
profundos. La buena ingeniería de software se convierte en una necesidad
básica para el correcto desarrollo de las pruebas de software.
• En general diversos son los problemas que se encuentran en un proceso de
pruebas; algunos de ellos son:
o Los probadores desconocen el dominio o los tipos y técnicas a utilizar
cuando se requieren pruebas de alto nivel, en general este problema
se da al tener personal poco capacitado para la labor.
o Los proveedores de pruebas generalmente posponen la labor de
pruebas a las etapas finales del ciclo de vida del software, lo que
ocasiona problemas por retrasos. Estos retrasos se dan
generalmente por que el equipo de pruebas debe adquirir el
conocimiento del dominio necesario y diseñar las pruebas, tareas que
se pueden realizar de forma transversal al proceso de desarrollo
optimizando los recursos disponibles.
o En ocasiones los probadores no cuentan con los insumos necesarios
para realizar un proceso de pruebas maduro y completo. Estos
insumos corresponden a una buena documentación y a un completo
y correcto levantamiento de requisitos, que orienten al probador,
tanto en la ejecución y desarrollo de las pruebas como en el
aprendizaje del dominio.
o Muchas organizaciones contemplan su proceso de QA basado en las
pruebas de software lo cual trae perjuicios en la calidad de los
productos al no incluir procesos como medición, análisis, verificación
y validación, todos ellos componentes esenciales de QA.
38
2 CICLO-P: UN MÉTODO PARA EL ACOPLAMIENTO DE PRUEBA S AL
CICLO DE VIDA DEL SOFTWARE
La constante demanda por productos de software de alta calidad ha motivado
al desarrollo de diversas metodologías y estándares internacionales de
pruebas, entre los que se encuentran el modelo de madurez CMMI [1], los
estándares de ISO y las prácticas recomendadas de IEEE, los cuales apuntan
al proceso de aseguramiento de la calidad del producto, el cual ha adquirido
una especial relevancia durante los últimos años y ha sido impulsado por la
competitividad del mercado y las exigencias de los clientes en materia de
calidad.
Infortunadamente, las metodologías que incorporan pruebas de software son
muy genéricas y no contemplan detalles ni pormenores en su implementación y
desarrollo, de esta forma cada organización implementa los procesos según
sus necesidades, objetivos y estrategias. A esta limitación de los modelos se
suman: la dificultad de acceso a la información, la dificultad de implementación
debida a la complejidad y a los recursos, y la falta de una recopilación general
que abarque los aspectos necesarios en un proceso de pruebas, haciendo que
muchas organizaciones desestimen la posibilidad de realizar pruebas de
software a su interior.
En este artículo se propone el método CICLO-P que hace uso de algunas de
las mejores prácticas sugeridas por la IEEE y estándares de ISO para pruebas
de software, contemplando las diferentes áreas de proceso que CMMI define
con el objetivo de asegurar la calidad del producto, además, se integra y
complementa con los diferentes productos de trabajo obtenidos en las
39
diferentes fases de desarrollo del software teniendo en cuenta el ciclo de vida y
los actores del mismo. CICLO-P también siguiere la implementación de un
conjunto de buenas prácticas para subsanar diversas vulnerabilidades
identificadas durante el proceso de producción de software. El proceso de
pruebas establece puntos de verificación y validación, además de un conjunto
de métricas que conforman un mecanismo de control y retroalimentación
posibilitando la obtención de la madurez necesaria para que el proceso sea
escalable y adaptable.
Este articulo está organizado así: en la sección 2 se presenta un marco teórico
de carácter introductorio al tema de las pruebas de software , en la sección 3
se realiza una revisión de los trabajos y metodologías existentes presentando
sus debilidades y fortalezas, en la sección 4 se propone un método de pruebas
de software; en este punto se presentan algunas definiciones previas y se
abordan los artefactos y las características que un software debe tener para
que sea susceptible de ser probado de forma intensiva y exitosa usando
CICLO-P como método. Posteriormente se esquematiza el proceso de pruebas
propuesto incluyendo tipos y técnicas asociadas, además de actores, puntos
de verificación y control, métricas, entradas y salidas entre otros, finalmente en
la sección 5 y 6 se presentan las conclusiones y el trabajo futuro.
2.1 BASES TEÓRICAS SOBRE PRUEBAS DE SOFTWARE
Las pruebas de software constituyen un universo en el mundo de la ingeniería
de software y su tarea principal es la de asegurar la calidad de los productos de
software.
40
Los casos de prueba constituyen una de las herramientas principales en las
pruebas de software, ya que mediante ellos, se formalizan las pruebas,
describiendo todo lo que puede implicar llevarlas a cabo y sugiriendo los
resultados que ésta debería arrojar. Los casos de prueba y su reutilización
juegan un papel fundamental a la hora de hacer que un proceso de pruebas
sea eficiente y cumpla con los tiempos que el mercado demanda.
Para el diseño de casos de prueba, se deben tener en cuenta técnicas [8]
como: de tipo aleatorio, de división de clases equivalentes, de valores límite, de
suposición de error y de transición de estados; todas ellas buscan encontrar
errores en el aplicativo mediante la elección de un conjunto de datos de
entrada que en algunos casos puede ser más eficiente para tal fin que en otros.
En las pruebas de software existen diversos enfoques, los cuales son
denominados tipos de pruebas; éstos determinan qué características del
software se probarán. Cada tipo de prueba en general tiene diferentes niveles
de dificultad y en alguna medida los errores que mediante ellas se detectan
están relacionados con dicha complejidad; por ejemplo, se esperaría que en un
tipo de prueba de capacidad de datos, los errores reportados no sean básicos,
debido a que ésta prueba tiende a ser aplicada en instancias muy avanzadas
del proceso y por ende dichos errores básicos no deberían existir en la pieza
de software en tal momento. Algunas de los tipos de pruebas más comunes
son pruebas de: funcionalidad, rendimiento, fatiga, seguridad, configuración, y
recuperación.
Los tipos de pruebas además de enfocarse a probar cierta funcionalidad del
software, tienen una tipificación según la capa en la cual se realiza determinada
prueba, así, cuando las pruebas se enfocan en la parte externa del aplicativo,
es decir en las interfaces, se dice que la prueba es de Caja negra [3], en
41
contraparte, cuando las pruebas se enfocan en la arquitectura interna, es decir
en el código fuente y su estructura, se habla de pruebas de Caja Blanca [4];
aunque éstas dos son las principales, existe una tercera, que combina
características de niveles externos e internos, es decir, pruebas en donde no
solo se tiene en cuenta la interfaz del aplicativo, sino también el código fuente
del mismo, éstas son llamadas prueba de Caja Gris.
El universo de tipos de pruebas está ligado al momento en el ciclo de desarrollo
de software en las cuales éstas se aplican y debido a esto y a prácticas
generalmente aplicadas para el aseguramiento de la calidad de los productos
de software, el flujo de aplicación de pruebas se conforma así: las pruebas de
caja blanca son realizadas generalmente en etapas finales de codificación
usualmente por el mismo programador y son llamadas pruebas unitarias,
posteriormente existen pruebas de caja gris o caja negra que son ejecutadas
mediante el concepto de pruebas por pares, estas prueba también son
llamadas pruebas de integración; finalmente existen pruebas de caja negra que
son realizadas por el equipo de pruebas; en éste último caso, se pueden
ejecutar cualquier tipo de prueba dependiendo de las características propias de
la pieza de software bajo prueba.
Los errores detectados constituyen la salida primaria de las pruebas de
software y por esto deben ser analizados con el fin de definir el momento en el
cual se inyectaron al producto de software (etapa de requisitos, análisis y
diseño, codificación) y determinar su criticidad y complejidad (alta, media, baja
y mínima). De ésta manera la solución de los mismos se hace de una forma
prioritaria y permite realizar procesos de retroalimentación al interior del equipo
de producción con el fin de que el proceso en general madure.
42
La estandarización a nivel internacional hace parte fundamental de las pruebas
de software, ya que permite no solo contar con procesos definidos altamente
eficientes, sino que también hace que las pruebas cuenten con el apoyo de las
técnicas que organismos internacionales han investigado y depurado por años
con el fin de mejorar los procesos de aseguramiento de la calidad. Organismos
como ISO, IEEE, SEI entre otros han desarrollado modelos de madurez y
metodologías que permiten que la calidad de software sea controlada y
asegurada; algunos de los más importantes estándares y normativas existentes
relacionados con el aseguramiento de la calidad y las pruebas de software son:
1. CMMI [1]: con áreas de proceso como QA, verificación y validación
directamente orientadas a pruebas de software y aseguramiento de la
calidad del producto de software.
2. ISO/FDIS 9126 [14]: modelo de calidad del producto.
3. ISO 14598[19]: Evaluación del producto de software.
4. ISO/IEC 15504[25]: Modelo para la mejora y evaluación de los procesos de
desarrollo y mantenimiento de sistemas y productos de software.
5. IEEE [36][12]: Estándar de verificación y validación.
6. IEEE [38]: Clasificación de errores.
2.2 TRABAJOS RELACIONADOS Y DEBILIDADES ASOCIADAS
Los antecedentes en pruebas de software implican organizaciones de
renombre internacional como IEEE e ISO, algunos otros modelos de pruebas
han sido desarrollados por instituciones y universidades, siendo uno de los
pioneros la Universidad de Illinois con su modelo de madurez TMM [43][12].
ISO ha desarrollado una serie de directivas alrededor de la norma ISO/FDIS
9126 e ISO/IEC 14598 que permiten abordar de manera metodológica la
43
recolección de métricas a través de un proceso de pruebas completo que
incluye las fases de especificación, diseño y construcción de pruebas de
software.
Uno de los problemas más generalizados dentro las pruebas de software es la
falta de estandarización tanto en metodologías como en terminología y en este
aspecto IEEE ha definido glosarios de pruebas, estándares y taxonomías de
defectos, además ha incursionado dentro de las metodologías proponiendo
buenas prácticas y sugerencias útiles a la hora de implantar o mejorar un
proceso de pruebas.
De otra parte los resultados de investigaciones dentro del área de calidad han
arrojado modelos de pruebas con prácticas genéricas. Tal es el caso de los
procesos descritos en CMMI Nivel 3 como Verificación y Validación, los cuales
se constituyen como aspectos de apoyo al área de Aseguramiento de la
Calidad del proceso y del producto, adicionalmente modelos como TMM
permiten enmarcar exclusivamente el proceso de pruebas dentro de un modelo
de madurez similar a CMMI y a la vez congruente con este.
Estas diferentes metodologías, sugerencias, prácticas y normas, tienen
asociadas algunas desventajas inherentes a su constitución, entre ellas se
encuentran:
• Falta de estandarización a nivel global entre unas y otras.
• Material escaso o de difícil consecución.
• Tópicos generales que no contemplan aspectos específicos como ciclo
de vida del software.
• Falta de madurez y de refinamiento en los procesos.
44
A estas dificultades se suman los obstáculos propios de las compañías
desarrolladoras como son:
• Falta de compromiso organizacional.
• Costos asociados a los procesos de calidad en general.
2.3 PROPUESTA METODOLÓGICA
CICLO-P es un método que permite realizar pruebas de software con el
objetivo de asegurar la calidad del producto.
CICLO-P es un método de pruebas cuya fortaleza principal es lograr una
correcta adherencia al proceso productivo de software y como consecuencia se
obtiene una disminución en los tiempos de pruebas y por ende en los costos de
las mismas. La correcta adherencia al ciclo de vida trae consigo otras
implicaciones de igual importancia, entre ellas se encuentran: lograr un proceso
productivo global de mayor calidad dado que los errores más críticos deben ser
descubiertos en las primeras fases del ciclo, se mitigan los riesgos inherentes a
un proceso productivos de software ocasionados generalmente por las
estimaciones de tiempos, costos y esfuerzo, y además se fortalece el proceso
de cierre de defectos y las practicas de programación.
CICLO-P cuenta con otros pilares secundarios para garantizar la eficiencia y
efectividad de las pruebas, entre ellas se encuentran: el uso clasificado de las
pruebas sobre un producto permite identificar claramente que aspectos o
características de este se encuentran en un estado conforme, el uso de
técnicas especializadas de pruebas permite seleccionar datos de pruebas que
revelen la mayor cantidad de defectos, la correcta administración de los casos
45
de prueba permite su reutilización y por lo tanto una disminución en el tiempo
de diseño y los criterios para las regresiones permiten identificar que módulos
del producto de software deben probarse nuevamente a consecuencia del
cierre de un defecto.
2.3.1 Precondiciones
La aplicación de CICLO-P está condicionada por diversos factores
organizacionales, entre ellos se encuentran los siguientes.
• La organización debe estar comprometida con los procesos de pruebas y de
calidad.
• La organización debe estar en capacidad de asumir los tiempos y costos
que implica la implantación de un proceso de pruebas.
• Los actores del proceso productivo se deben acoplar al ciclo de vida
unificado que propone CICLO-P para llevar a cabo las pruebas de forma
paralela al desarrollo de software.
• Es necesario que la organización cuente con un proceso claro y definido
para el levantamiento de requisitos, dado que estos son un insumo
indispensable para el diseño y ejecución de algunos de los tipos de pruebas
propuestos en el método CICLO-P.
• La implantación del proceso de pruebas, requiere un proceso productivo
maduro y refinado, cuyos cuellos de botella estén identificados y
optimizados, con el fin de que CICLO-P pueda obtener resultados positivos
en cuanto a tiempos de prueba se refiere.
• Es necesario contar con un sistema de gestión de calidad para que las
métricas generadas por CICLO-P sean administradas y se puedan utilizar
para retroalimentar el proceso de pruebas.
46
2.3.2 CICLO-P: Proceso de pruebas acoplado al proce so de producción.
Aunque algunos autores de la literatura como Myers[3] piensan que las
pruebas de software realizadas por agentes externos a las organizaciones son
más eficientes que las realizadas por un área de procesos inmersa en las
mismas, en organizaciones con sistemas de calidad que apuntan a un modelo
de mejoramiento continuo resulta peligroso este hecho, dado que uno de los
problemas que se presenta cuando se realizan pruebas por outsourcing es que
el proceso no se puede medir, controlar y por ende mejorar, es decir, se
convierte en una caja negra dado que el proveedor difícilmente permite que los
procesos organizacionales sean conocidos por el cliente. Es así, como
retrasos en las pruebas o malas estimaciones por parte del proveedor de
pruebas pueden convertirse en retrasos generales en proyectos, no
convenientes para las organizaciones de desarrollo de software. Asi, el
acoplamiento de las pruebas de software al proceso productivo al interior de
una organización como parte del proceso productivo de Aseguramiento de la
calidad del producto (PPQA) es la mejor elección a la hora de buscar un
producto que cumpla con altos estándares de calidad apoyado por procesos en
vía de mejoramiento continuo.
El hecho de que el proceso de pruebas esté acoplado al proceso productivo
tiene ventajas adicionales como:
• Más cohesión entre todos los procesos involucrados en el producto final.
• Mejor comunicación entre los actores del proyecto, lo cual facilita su exitosa
consecución y la detección de fallas y riesgos en etapas tempranas.
• Agilidad a la hora de notificar y solucionar errores en el software.
• Mejoramiento bidireccional de los procesos del área de producción hacia el
área de QA.
47
• Diseño de casos de prueba en etapas tempranas del proyecto, lo cual
permite ahorros tanto en tiempo como en dinero para la organización.
2.3.3 Roles
Los actores involucrados directamente en el área de pruebas deben ser
claramente definidos mediante una determinación de roles con el fin maximizar
las habilidades del factor humano y permitir la fácil asignación de tareas y
responsabilidades al interior. Así clasificación de roles y actores está dado
según el conocimiento, la responsabilidad y las tareas que se deben
desempeñar en dicho cargo, así:
• Coordinador de pruebas: encargado de liderar el grupo de pruebas,
constituye el puente principal de comunicaciones entre el personal de
aseguramiento de la calidad del producto y los líderes de otras áreas de
procesos y proyectos en general.
• Diseñador de pruebas: Dado que el diseño de las pruebas se constituye
como la actividad más compleja y que lleva más tiempo a través de todo
los procesos de aseguramiento de la calidad del producto, el desempeño
de éste rol constituye uno de los más importantes, además que se
desagrega con el fin de evitar la subestimación de habilidades y
conocimientos del personal humano. Así pues existen tres tipos de
diseñadores de pruebas que se determinan según el tipo y la
complejidad de las pruebas que diseñan; éstos son: diseñador de alto,
medio y bajo nivel.
• Probador: Ejecuta casos de prueba ya aprobados y reporta los errores al
área de producción.
48
2.3.4 Tipos de pruebas
Las pruebas de software pueden ser de muchos tipos, además de pruebas
estándares en el mercado del software existen pruebas más especializas que
agregan confiabilidad y estabilidad a largo plazo al producto y en algunos casos
mejor rendimiento y eficiencia. Las pruebas que son obligatorias para un
aplicativo son las funcionales que se apoyan directamente sobre los requisitos
y todo aquel artefacto que los exprese, defina o clarifique. Generalmente las
prueba funcionales son basadas en casos de uso y se orientan a detectar
posibles incoherencias con lo que el cliente necesita y errores de programación
y diseño en general. Existen otras pruebas que buscan determinar los límites
del aplicativo y sus debilidades, éstas son llamadas pruebas de tensión (stress)
y pruebas de rendimiento (performance). Finalmente existen prueba que se
especializan en descubrir que tan bueno es el producto de software en tareas
específicas como por ejemplo: pruebas de instalación, seguridad,
documentación, mantenimiento, recuperación, entre otras.
La elección de qué pruebas realizar y cuál es el criterio de aceptación del
producto constituye uno de los factores más importante a la hora de realizar
pruebas, y para esto se deben evaluar tanto los riesgos como las necesidades
del aplicativo mismo, según sus características propias y las del usuario final.
2.3.5 Flujo de proceso de CICLO-P acoplado al proc eso de desarrollo de
software
Uno de los elementos más importantes para el desarrollo de un buen método
de pruebas, es el ciclo de desarrollo y la definición de las etapas del proceso
productivo de la organización. El proceso de desarrollo de una organización,
49
debe estar basado no solo en un modelo de procesos, sino también en un
conjunto de documentos que abalen dichos procesos y los hagan
reproducibles. No solo los procesos deben estar descritos formalmente, sino
también – y más importante aun - deben estar altamente adheridos a la
organización.
Dado que las pruebas de software no deberían ser un proceso aplicado al final
del ciclo de producción, se deben realizar ciertos filtros durante dicho proceso,
con el fin de evitar que el equipo de pruebas alargué el periodo en el cual
captura errores simples, y más bien se dedique a encontrar errores complejos
que en un momento dado pueden convertirse en errores de interrupción del
sistema.
Las metodologías adoptadas para crear filtros en diferentes puntos del proceso
de producción son: verificación y validación, soportado a través del mecanismo
de pruebas por pares, en las cuales existen tres actores: dos probadores y un
árbitro. Las etapas en las cuales se propone introducir dichos filtros son:
• Etapa de toma y definición de requisitos: en este punto se debe verificar y
validar a través de listas de chequeo que el producto de software se
encuentra en un estado conforme en relación a los requisitos. Quien evalué
las listas de chequeo debe tener un amplio conocimiento acerca del dominio
del sistema.
• Etapa de Análisis y diseño: esta fase es crucial para obtener un producto
conforme con los requisitos y expectativas del interesado, es por ello que es
necesario asegurar que el software es una representación correcta de estos
artefactos. El artefacto más importante y que apunta a las pruebas de
funcionalidad son los casos de uso, otros no menos importantes, pero si
menos utilizados son los diagramas de transición de estados, de secuencias
y de actividades; estos además de ayudar al modelamiento de la solución
permiten utilizar pruebas basadas en novedosas técnicas para determinar
50
errores de graves consecuencias en el sistema. En ésta etapa se debe
definir un plan de pruebas que contemple: análisis del dominio, análisis del
aplicativo desde el punto de vista de las pruebas de software, delimitación
de alcances de las pruebas, definición de los tipos de pruebas a diseñar y
ejecutar, detección y manejo de riesgos, creación de cronograma con
tareas específicas e hitos, determinación de los recursos mediante la
estimación entre otros.
• Etapa de Codificación: en este punto se deben capturar los errores
superficiales que se comenten generalmente por descuidos y que por lo
general no alteran la funcionalidad del producto, estos errores se refieren a
interfaces a nivel comportamental, y ayudan a obtener un producto de
excelente calidad. También se deben realizar comprobaciones del uso de
estándares de programación ya definidos por la organización. Las pruebas
unitarias mediante técnicas de caja blanca son seguidas de pruebas por
pares mediante técnicas de caja negra que ayudan a obtener un grado de
madurez mayor al área de pruebas. El diseño de casos de prueba se debe
iniciar en ésta etapa antecedido de capacitaciones en el dominio a los
diseñadores y probadores encargados del proyecto.
• Etapa de pruebas: los subprocesos internos que se ejecutan en ésta etapa
son:
o Diseño de casos de prueba: por módulos y por tipos de pruebas
siguiendo lo establecido en el plan de pruebas. La reutilización
hace parte fundamental en éste subproceso ya que permite no
solo madurar pruebas específicas a través del tiempo, sino
también ahorro de tiempo y recursos. Se debe registrar cada caso
de prueba en una herramienta de administración de casos de
prueba, con el fin de automatizar ciertas tareas, reutilizar
fácilmente y llevar seguimiento. Al final de éste subproceso se
debe verificar mediante listas de chequeo que los casos de
prueba diseñados sean conformes y cumplan con los objetivos y
alcances de las pruebas.
51
o Ejecución de casos de prueba y reporte de errores: la ejecución
de casos de pruebas se realiza siguiendo los lineamientos de los
casos de prueba diseñados y concluye con el reporte de errores
encontrados en el aplicativo; para tal fin se pueden utilizar
formatos o herramientas administradoras de errores o bugtracker
con el fin de automatizar y facilitar ciertas tareas, además de
permitir el seguimiento de todo lo concerniente con el reporte y
corrección de los mismos. Al final de éste subproceso se debe
verificar mediante listas de chequeo que los errores reportados si
sean en realidad errores y que su reporte sea suficientemente
claro y bien documentado para su entendimiento y posterior
solución.
o Regresiones y aprobación: después del reporte de los errores, la
corrección de los mismo implica la reejecución de casos de
prueba fallidos con el fin de verificar que dichos errores en efecto
se solucionaron y no afectaron otros aspectos locales del
software. Antes de realizar una aprobación del producto de
software, se debe realizar un análisis en el cual se tengan en
cuenta las regresiones realizadas al software, los errores y las
correcciones hechas, debido a que su impacto puede ser alto en
otros puntos de aplicativo globalmente, lo cual podría suponer la
reejecución de pruebas a otros módulos o el diseño de pruebas
adicionales en partes específicas del aplicativo.
• Etapas de implantación, pruebas del cliente, soporte y mantenimiento:
cuando se realiza la instalación en el ambiente de preproducción y
posteriormente en el ambiente de producción del cliente, se deben utilizar
listas de chequeos que permitan verificar que la instalación es conforme y
se debe documentar el estado final de la instalación con el fin de tener un
apoyo para la posible determinación de la fuente de un error en la etapa de
soporte y mantenimiento. En ambientes de preproducción generalmente se
realizan algunos reportes de cambios y errores los cuales deben ser
manejados según su criticidad y complejidad, lo cual puede llevar a realizar
52
nuevas pruebas al software o a reejecutar muchas de las pruebas
realizadas en etapas anteriores.
Por otro lado, y apoyando directamente la etapa de pruebas, se contemplan las
siguientes técnicas de pruebas para la elección de los conjuntos de datos de
entrada para la generación de casos de prueba: aleatoria, división de clases
equivalentes, valores límite, transición de estado y suposición de error.
El método CICLO-P propuesto incluye las siguientes características que
permiten optimizar el proceso de pruebas:
• El diseño de los casos de prueba, que es una de las actividades que más
tiempo consumen, comienza tan pronto los artefactos de análisis y diseño
son construidos.
• La obtención del conocimiento del dominio necesario para diseñar y
ejecutar algunas pruebas debe ser obtenido antes de empezar la etapa de
codificación, teniendo presente que en el trascurso del desarrollo es muy
probable que se debe obtener información adicional del dominio.
• Las listas de chequeo de verificación y validación deben entrar como
insumo al proceso de pruebas, para evitar redundancias en las pruebas y
permitir la realimentación del área de pruebas.
• Las solicitudes de prueba deben generarse por eventos, estos eventos
están asociados con la terminación de la codificación de una nueva
funcionalidad o modulo, el reporte de un cambio, un error o un requisito
nuevo en etapas de mantenimiento del producto.
• Cuando se reporta un error este debe ser corregido por el área de
producción y generar una prueba llamada regresión para verificar que la
corrección elimino el error y no introdujo más. El determinar si ocurrieron
más errores es bastante difícil, puesto que la única solución sería probar de
nuevo todo el aplicativo, esto último es impráctico y no trae buenos
resultados, por lo tanto se debe considerar el juicio experto apoyado por
53
matrices de trazabilidad para determinar que otros módulos o
funcionalidades fueron afectados por la solución y así realizar las pruebas
necesarias a estos.
• La cobertura para pruebas de caja blanca esta medida en líneas de código
probadas, al ser esta una metodología basada en pruebas de caja negra es
necesario medir la cobertura en otros términos. Un análisis en términos de
pruebas básicas que cualquier aplicativo debe tener, número de casos de
prueba diseñados y ejecutados, y pesos relativos a los diferentes tipos de
pruebas permiten obtener a través de relaciones lineales el porcentaje de
cobertura de las pruebas.
54
Ilustración 4 - Etapas de CICLO-P
2.3.6 Métricas asociadas al seguimiento y control y a la estimación
El seguimiento de los proyectos de producción y específicamente de pruebas hace
parte esencial de los modelos de calidad de mejoramiento continuo y adquisición
de madurez como ISO y CMMI.
En un proceso de alta calidad basado en el mejoramiento continuo, las
estadísticas y los indicadores permiten no solo la vista global del proceso y sus
resultados, si no también, permite diseñar planes de mejora generales y
específicos.
En el área de pruebas se deben llevar estadísticas del resultado de las pruebas a
través de las etapas de diseño, ejecución y evaluación de casos de prueba, lo cual
conduce a procesos de análisis de cobertura.
Por otro lado, la buena estimación es un punto álgido en las organizaciones, ya
que permite realizar cronogramas con factores de dispersión con la realidad muy
bajos. Así pues, la organización debe contemplar la utilización de mecanismos que
“midan” el software, permitiendo que el área de producción pueda generar datos
históricos de su capacidad de producción usando métricas de esfuerzo versus
tamaño. Técnicas como puntos de función y puntos de casos de uso suelen ser
utilizadas para el manejo del tamaño de software y éstas son apoyadas con
procesos de estimación como COCOMO II [46].
149
El área de pruebas acoplada al plan de estimación de la compañía puede
beneficiarse, debido a que un estudio de la cantidad de errores inyectados por
aplicativo asociados a su nivel de complejidad y el de sus errores puede llevar a
generar una estadística de los errores esperados según el tamaño del software.
Existen técnicas asociadas a modelos de estimación que permiten calcular el
número de defectos esperados en una pieza de software medida, uno de los más
utilizados es COQUALMO [46] que hace parte de COCOMO II. Esto último suele
ser útil a la hora de decidir cuánto se debe probar y a qué nivel.
2.3.7 Proceso de retroalimentación
La retroalimentación en el área de aseguramiento de la calidad constituye una de
las herramientas más importantes para la obtención de madurez por parte de la
organización ya que permite introducir mejores prácticas según las realidades del
grupo humano que componen las áreas productivas. Las prácticas que permiten la
retroalimentación desde el área de aseguramiento de la calidad del producto, es
decir, pruebas, hacia el área de producción son:
1. Determinación de fallas comunes en el software y acoplamiento en listas de
chequeo de verificación y validación de preguntas que detecten dichas fallas y
eviten su propagación al área de pruebas.
2. Detección de posibilidades de mejora en aspectos como definición de
requisitos y construcción de artefactos de análisis y diseño, en tanto éstos se
diseñen conforme la herramienta fue concebida y evaluando su utilidad a la hora
de probar el producto final.
150
3. Retroalimentación de estándares de programación y buenas prácticas
llevadas a cabo por los programadores, mediante la definición de soluciones a
los problemas o debilidades más comunes en los aplicativos.
151
3 ESTUDIO COMPARATIVO DE HERRAMIENTAS ESPECIALIZADA S EN
PRUEBAS DE CARGA DE APLICACIONES WEB
Las pruebas de carga son aquellas en las cuales se lleva al límite una aplicación
web mediante la emulación de determinado número de usuarios con diversos
periodos de conexión simultánea y distintas funcionalidades específicas en
ejecución. Las pruebas de carga se relacionan directamente con las pruebas de
rendimiento debido a que este tiende a afectarse a medida que el aplicativo llega a
su límite, es por esto que el monitoreo del software y los sistemas que apoyan los
aplicativos web toma relevancia al realizar éste tipo de pruebas.
Las aplicaciones web actuales además de factores de funcionalidad y operatividad,
exigen más que nunca niveles de calidad del servicio (QoS) óptimos [47],
directamente relacionados con los tiempos de respuestas y la disponibilidad del
servicio, es por esto, que las pruebas de carga tiene una gran relevancia ya que
permiten encontrar el límite óptimo del funcionamiento de una aplicación web
determinada, lo cual conlleva en algunos casos a encontrar fallos de diseño en el
software de tipo arquitectónico facilitando la realización de ajustes en el mismo con
el fin de afinar sus características y mejorar su rendimiento.
Las pruebas de carga además de realizarse sobre sitios o aplicaciones web,
también se pueden realizar sobre servicios basados en protocolos de Internet y
servicios especializados tales como: FTP, Autenticaciones LDAP, Web Services
152
(SOAP), bases de datos, etc.; Estas funcionalidades, unidas a algunos otros
factores propios de herramientas para la realización de pruebas de carga hacen que
una aplicación especializada en dichas pruebas sea utilizada de forma más
conveniente en algunos sistemas o ambientes que en otros.
En éste trabajo se compararan 20 herramientas de software para realizar pruebas
de carga a aplicaciones basadas en protocolos de Internet y software con
arquitecturas cliente servidor. La comparativa estará orientada a estudiar las
características más representativas de las herramientas comparadas y a analizar la
tendencia del desarrollo de las mismas en cuanto a funcionalidades se refiere.
El estudio comparativo planteado permitirá identificar grupos de aplicaciones con
características similares, permitiendo elegir el uso de alguna de ellas según el
ambiente y las características de lo que se quiere probar.
El artículo se estructura así: en primera instancia se describirán los elementos
conceptuales relevantes en el tema de las pruebas de carga, posteriormente se
listarán y explicarán las características a tener en cuenta al realizar el estudio
comparativo; seguidamente se definirán 3 categorías de herramientas de pruebas y
se detallará cada herramienta de cada categoría con sus características específicas
mediante un conjunto de tablas; en el segmento siguiente se realizarán los análisis
de los resultados de las pruebas comparativas. Finalmente se enumerarán las
conclusiones y el trabajo.
153
3.1 ANÁLISIS TEÓRICO SOBRE HERRAMIENTAS DE CARGA EN APLICACIONES WEB
Las pruebas de carga, también conocidas en algunos casos como pruebas de
stress o test load tiene por objeto emular la conexión a un aplicativo web de
determinado número de usuarios con el fin de medir la reacción de este y del
sistema donde está instalado cuando la concurrencia alcanza niveles específicos.
Una herramienta de carga (test tool load) opera enviando continuamente
peticiones a un sitio web, parando por periodos de tiempos programables para
comenzar de nuevo con el envió de peticiones continuas concurrentes escalables
tanto como el sistema y el software de prueba lo permitan (Ver Figura 1). Cada
ingreso al aplicativo web es llamado usuario virtual y tal concepto permite:
• Obtener resultados similares a los que se logran con usuarios reales
conectados en forma concurrente.
• Obtener respuestas negativas por ingresos no concluidos, abandonos de sesión
y rechazo de peticiones por tiempo excesivo de respuesta.
Ilustración 5 - Proceso de las pruebas de carga. Tomado de [1]
154
3.1.1 Diferencia entre pruebas de carga, pruebas de rendimiento y pruebas de estrés.
Generalmente se tiende a confundir estos tres tipos de pruebas, debido a que en
muchas ocasiones se realizan paralelamente. Los objetivos de dichas pruebas
permiten encontrar sus diferencias y entender por qué en algunos casos son
usadas en forma intercambiables al mencionarlas:
a. Pruebas de rendimiento (performace testing): Su objetivo principal es
desarrollar estrategias eficaces para la mejorar el rendimiento del sistema. En
las pruebas de rendimiento se recopila y analiza información mediante un
proceso de medición en el que se recogen datos para predecir cuando los
niveles de carga agotará los recursos del sistema [62].
b. Pruebas de carga (load testing): evalúan el rendimiento del sistema con una
carga predefinida. La prueba de carga mide cuánto se tarda un sistema para
realizar diversas tareas y funciones del programa bajo condiciones normales o
predefinidas. Debido a que el objetivo de las pruebas de carga es determinar si
el rendimiento del sistema satisface los requisitos no funcionales de carga del
sistema, es pertinente que la configuración mínima y máxima y los niveles de
actividad se determine antes de comenzar las pruebas [62].
c. Pruebas de estrés (stress testing): evalúan el comportamiento de los sistemas
cuando éstos son llevados más allá de sus límites operacionales (esto puede
ser muy por encima de los requisitos no funcionales). Se evalúa las respuestas
del sistema y de la aplicación a periodos de mayor volumen de actividad que
superen las limitaciones del sistema. El objetivo principal de las pruebas de
estrés es determinar si un sistema se bloquea o se recupera en dichas
condiciones. Las pruebas de estrés deben ser diseñadas para llevar los límites
155
de los recursos del sistema hasta el punto en que los puntos débiles de la
aplicación queden expuestos [62].
3.2 Relación entre las pruebas de carga y el rendim iento del sistema.
El uso de pruebas de carga para predecir el rendimiento de un aplicativo web
basado en el nivel de carga del mismo es sumamente útil en sistemas con
requisitos de carga sumamente altos. Se deben considerar los siguientes factores
para el entendimiento de los conceptos de los análisis realizados comúnmente en
las pruebas de carga [47]:
VUN : Número de usuarios virtuales.
CN N c: Número de peticiones concurrentes por usuario virtual.
Z : Tiempo entre petición realizada al sitio.
R : Tiempo promedio de respuesta por cada petición.
OX : Tiempo promedio de peticiones por segundo
Se usa entonces la ley del tiempo de respuesta [14] [48]
ZX
NR
O
VU −=
En general, el gráfico estadístico más diciente en una prueba de carga es el de
tiempos de respuesta versus respuestas recibidas o usuarios virtuales
concurrentes que precisamente relaciona la carga con el rendimiento de la
aplicación web y permite el estudio de R (Rendimiento) (Ver figura 2)
156
Algunas de las características que en las pruebas de carga son relevantes, y por
ende es vital que sea posible medirlas en las herramientas evaluados son [57]:
comportamiento de tiempos de consulta DNS, tiempos de conexión TCP, tiempo
de obtención de paquetes, tiempo de redirección, tiempo de obtención de página
base, tiempo de obtención de contenido, entre otras.
Existen también algunos conceptos utilizados en el ámbito de las pruebas de
carga que son relevantes a la hora de realizar un análisis de resultados y van
directamente relacionadas con las características a medir mediante las
herramientas de pruebas de carga. Los más destacados son:
• Hits: es una solicitud hecha por un servicio, aplicación o explorador web a un
servidor Web. Así, por ejemplo cada imagen de una página web genera un
hits[60].
• Punto de quiebre: cantidad máxima de usuarios concurrentes que la aplicación
puede soportar antes de no entregar una respuesta efectiva.
• UVC (Usuarios Virtuales Concurrentes): Es la cantidad de usuarios virtuales
que son configurados para generar la concurrencia establecida en la prueba de
carga.
• Sesión: Es el espacio de tiempo donde el usuario virtual ejecuta la acción
programada mediante la herramienta de carga.
• MTR (Máximo Tiempo de Respuesta): Es la variable que permite medir el
tiempo máximo de respuesta que arroja algún objeto o elemento que ha sido
probado mediante la herramienta.
• Throughput: Es la respuesta del servidor de aplicaciones a la petición que
envía el generador de carga, específicamente con lo relacionado a la
capacidad de transmisión de un medio de comunicación en cualquier
momento; se suele medir en bits por segundo (bps).
157
• Response time (Tiempo de respuesta): tiempo que pasa entre la petición y la
respuesta de un servicio cliente servidor.
En los últimos años, las compañías de software han descubierto que la clave a
largo plazo es lograr una ventaja competitiva en el mercado mediante la
satisfacción del cliente a través de la fiabilidad, eficiencia los cuales hacen parte
de las características de un sistema de software con calidad según la norma ISO
9126[15], y además mediante la rapidez y tiempos de respuesta competitivos
presentes en sus aplicativos [49] [52]. Es por éstas razones que las pruebas de
carga siempre están presentes en los planes de prueba de sus aplicaciones y
como consecuencia, a mediano plazo o incluso antes los costos de mantenimiento
se ven claramente reducidos [55].
Ilustración 6 - Gráfica de carga versus rendimiento. Tomado de [1]
Generalmente, después de un ciclo de mantenimiento a un software, se debe
incluir en el plan de pruebas una prueba de carga en condiciones de uso reales y
en un ambiente de pruebas similar al que en etapa de producción se utilizará [50].
158
Las realización de pruebas de carga generalmente acarrea altos costos a las
pruebas en general de las aplicaciones, sin embargo, éstos se pueden justificar
mediante los beneficios al aplicar acciones correctivas durante la prueba que
potencialicen la fiabilidad del producto de software[51].
Las aplicaciones web no son las únicas piezas de software a las cuales se les
realizan pruebas de carga, también se realizan éstas pruebas a software de
teléfonos móviles[55], software de manejo de hardware especializado[54] y
circuitos electrónicos específicos (pruebas de carga realizadas mediante modelos
estadísticos[52]); de hecho, el ámbito de pruebas de carga a aplicaciones de
software se nutrió inicialmente de las experiencias adquiridas por otras áreas de la
ingeniería al realizar pruebas de carga a determinados objetos o construcciones.
Al evaluar posibles herramientas para realizar pruebas de carga surgen conceptos
y consideraciones que permiten realizar una escogencia correcta de acuerdo tanto
al ambiente como a las necesidades organizacionales y funcionales de la prueba.
3.3 Características a medir en el estudio comparati vo
En la comparativa se tendrán en cuenta 35 factores o funcionalidades
relacionados con cada una de las herramientas para realizar pruebas de carga.
Habitualmente cada ítem será evaluado dependiendo de su soporte o no por una
herramienta específica, con excepción de los ítems que son de carácter
informativo. Dichos factores serán definidos brevemente a continuación:
159
1. Dirección url del fabricante: sitio web en el cual se encuentran los manuales,
explicaciones y archivos instaladores de la herramienta.
2. Tipo de licencia y precio: el tipo de licencia delimita la forma de uso y está
directamente relacionado con el precio, ya que dependiendo de las
capacidades o límites del aplicativo los precios suben o bajan según sea el
caso. Generalmente en éste tipo de aplicaciones el precio lo delimita el número
máximo de usuarios concurrentes que es posible emular.
3. Acceso al código fuente: posibilidad de acceder al código fuente de la
herramienta y realizar modificaciones en ella. Generalmente esto depende del
tipo de licencia que cada una de ellas tenga.
4. Plataforma: sistemas soportados para la instalación de la herramienta que en
términos precisos se traduce en los sistemas operativos soportados o el
lenguaje de programación usado para la construcción de la herramienta que en
algunos casos se traduce en portabilidad entre sistemas, tal caso son las
herramientas programadas en java, las cuales generalmente son portables
entre sistemas Windows, Linux, UNIX, Solaris, entre otros.
5. Multiplataforma: Característica que describe que tan portable es la
herramienta. (Ver plataforma).
6. Requisitos de hardware: requisitos del sistema a nivel de hardware que se
requieren para que la herramienta se ejecute correctamente. Se refiere
generalmente al tipo de procesador, memoria RAM y disco duro.
7. Idiomas soportados: el hecho de que las herramientas sean multilingües les da
la capacidad de ser fácilmente adaptables sin importar la cultura en la cual se
utilicen, es por eso que el soporte de varios leguajes forma parte de las
funcionalidades deseables en dichas herramientas.
8. Manejo de perfiles de usuarios virtuales: generalmente en las aplicaciones
web, se manejan grupos de usuarios con características y perfiles distintos. La
posibilidad de emular los tipos de usuarios mediante usuarios virtuales
logrando agrupaciones que correspondan a la realidad de un ambiente
operativo permite que el diseño de las pruebas sea más fácil y moldeable.
160
9. Uso de variables: algunas herramientas admiten agregar contadores o
variables que permiten mediante la utilización de controladores lógicos cuantas
veces se carga un segmento de código específico de html durante la prueba.
Generalmente éstas variables se usan para construir gráficas personalizadas.
10. Soporte IP Spoofing: utilidad que permite a la herramienta de pruebas asignar
a un usuario virtual una ip, haciendo que la prueba sea más cercana a la
realidad de las peticiones concurrentes de usuarios conectados en distintas
estaciones de trabajo.
11. Visualización en tiempo real: función que permite visualizar los resultados de
las pruebas, las gráficas y las tablas de datos paralelamente la prueba se está
ejecutando.
12. Pruebas programadas: permite programar el inicio, las paradas y el fin de un
plan de pruebas específica.
13. Proxy http: para que las pruebas se realicen de forma más automática, en vez
de generar el script con los pasos que se deben seguir para la prueba, se
utiliza ésta funcionalidad que hace interfaz con el navegador web normal y
graba las acciones que se realizan en él, generando las instrucciones o script
necesarios para realizar la prueba específica. En el caso de http se monitorea
todo el flujo http y se graban las peticiones y respuestas no codificadas.
14. Proxy https: tiene el mismo objetivo y filosofía de el proxy http, solo que éste
graba de forma especial las secuencias, debido a que debe codificar y
decodificar las peticiones y respuestas y hace uso constante de las key y
certificados propios de SSL dependiendo de la versión y del cifrado utilizado
(128, 512 bits, etc.). Muchas herramientas para realizar pruebas de cargas no
permiten la grabación de páginas encriptadas con https debido a su
complejidad, lo cual corresponde por ende a una funcionalidad añadida y una
ventaja comparativa para la misma.
15. Scripting: al realizar el diseño de las pruebas, la forma en que éstas se
programan o estructuran tiene mucho que ver con la fácil manipulación que se
le puede dar a la misma. Generalmente se cuenta con un lenguaje definido por
161
el fabricante de la herramienta que permite diseñar las órdenes de petición,
espera, generación de flujos de navegación, etc.; en otros casos, algunas
herramientas cuentan con leguajes más conocidos que permiten realizar el
diseño de las pruebas de forma más amplia y fácil, con la ventaja que no se
requiere aprender un nuevo lenguaje programático para generarlas.
16. Controladores Lógicos: permiten en general asignar determinada variable de la
prueba con un valor si se da cierto evento lógico. Entre ellos se encuentran las
instrucciones. if, while, do while, for, entre otras.
17. Número de informes nativos: corresponde al número de informes nativos que
posee la herramienta, mientras más informes predeterminados tenga, la
facilidad de interpretación de resultados será más alta y por ende el tiempo de
la prueba se reducirá.
18. Diseño de informes personalizados: las herramientas generalmente traen
consigo ya por defecto informes específicos para el análisis de los resultados
de las pruebas, sin embargo, algunas más poderosas permiten la manipulación
de variables propias en las pruebas y su uso en la construcción de gráficas
personalizadas que permiten un análisis específico y acoplado al ambiente
determinado de las pruebas.
19. Protocolos: Protocolos de comunicación que puede capturar, manipular y
emular. Entre ellos los más comunes son HTTP 1.0 / 1.1 / HTTPS (SSL).
Generalmente es uno de los requisitos básicos de las herramientas en la
actualidad y termina siendo una ventaja comparativa el hecho de que posea
adicionalmente la funcionalidad de proxy http o https.
20. Monitoreo de bases de datos: funcionalidades propias de la aplicación que se
conectan directamente al motor de base de datos que utiliza la aplicación web
probada y permite visualizar su comportamiento en términos de rendimiento y
uso de recursos a medida que la prueba es ejecutada.
21. Monitoreo Sistema Operativo: funcionalidades propias de la aplicación que se
conectan directamente al sistema operativo y muestran mediante gráficas y
162
tablas el comportamiento de los recursos internos a medida que se ejecuta la
prueba.
22. Monitoreo web server: funcionalidad que permite conectarse a un servidor de
aplicaciones y monitorear el rendimiento, la memoria utilizada, entre otros
factores, con el fin de visualizar su comportamiento a través de un periodo de
tiempo determinado.
23. Pruebas LDAP (Lightweight Directory Access Protocol): Pruebas que se
realizan directamente sobre un servicio tipo LDAP, y permiten encontrar la
capacidad o límite de servicio de usuarios concurrentes autenticándose al
mismo.
24. Pruebas FTP: Prueba que se realiza sobre un servicio de transferencia de
archivos FTP y permite encontrar el límite de servicio de usuarios concurrentes
autenticándose y enviando o recibiendo información al mismo tiempo.
25. Pruebas de web services: los servicios web que funcionan bajo el lenguaje
SOAP, forma en la actualidad una de las tendencias más populares para la
construcción de aplicaciones web. Una herramienta que permite pruebas de
carga a dichos servicios está apta no solo para enviar peticiones e instanciar el
servicio congruente con SOAP, sino también para recibir mensajes e
interactuar completamente con dicho servicio.
26. Pruebas Bases de datos: esta funcionalidad permite realizar pruebas a
servidores de bases de datos y mediante el envió de consultas, ejecución de
procesos almacenados y generación de vistas temporales entre otras, se
estudia el rendimiento y la capacidad de carga de la base de datos en cuestión.
27. Pruebas mail-Server: esta funcionalidad permite realizar pruebas a servidores
de correo, mediante peticiones simultáneas de recepción y envió de correos.
28. Manejador de Cookies: las cookies son archivos temporales que manejan
información de sesión que permite agregar funcionalidades específicas a los
aplicativos web. Cuando se realizan pruebas de carga con flujos de navegación
específicos en aplicativos que usan las cookies es esencial, ya que si no es
163
soportado por la herramienta se presentarán errores de denegación de servicio
que no aportan a la medición ningún dato objetivo.
29. Administración remota: implica la posibilidad de realizar la configuración y
todas las funcionalidades propias de una prueba a distancia mediante una
conexión a un puerto específico desde un ambiente cliente compatible con la
herramienta. Esto es útil en casos en que las pruebas se deben llevar a cabo
en ambientes controlados de producción o en casos en que se utilicen pruebas
en segmentos múltiples o en ambientes distribuidos, en donde se deben
monitorear varias instancias de la herramienta a la vez.
30. Temporizadores: funcionalidad que permite programar tareas de inicio de carga
de hilos concurrentes teniendo en cuenta un patrón específico en cuya función
se obtiene finalmente una variable temporal que dispara el inicio del evento.
31. Pruebas en segmentos múltiples: se refiere a la posibilidad de realizar una
prueba desde distintos puntos de una arquitectura de red, ya sea aplicando el
mismo plan de pruebas o uno distinto. Se usa tanto para evaluar el
comportamiento de la aplicación web probada bajo la carga desde distintos
nodos de una red, como para potenciar más la carga de trabajo, ya que en
algunos casos el ambiente en el cual se ejecuta la herramienta para realizar la
prueba se puede sobrecargar y arrojar resultados incoherentes.
32. Pruebas funcionales: en herramientas muy especializadas, permiten
inicialmente realizar pruebas funcionales basadas en requisitos, generalmente
programables por medio de script. En algunas de ellas se pueden realizar
pruebas de carga basadas en las pruebas funcionales programadas,
permitiendo un ahorro de tiempo y un desempeño más realista durante las
pruebas.
33. Posibilidad de extensiones: Funcionalidad que permite incrementar las
funcionalidades de la herramienta mediante adiciones, script o subprogramas.
34. Emulación de velocidad de conexión de usuarios: Funcionalidad de emular
diferentes conexiones de red en los usuarios virtuales.
164
35. Escalabilidad de usuarios: funcionalidad de la herramienta de generar un
número de usuarios virtuales de acuerdo a los recursos específicos de la
máquina en la cual se ejecuta la prueba. Generalmente éste factor depende de
el número, tamaño y complejidad del script de prueba.
3.4 ANÁLISIS DE RESULTADOS
Al listar las herramientas para la realización de prueba de carga, se crearon 3
categorías teniendo en cuenta las características que posee cada herramienta y
por ende su funcionalidad general (Ver la tabla 2, 3 y 4 que contienen el listado
detallado de características por herramienta). Las categorías son:
• Bajo: corresponde a las herramientas con menor número de características
presentes en su estructura funcional.
• Medio: corresponde a las herramientas con un número de características
presentes en su estructura funcional aceptable y que se consideran normales o
estándar en éste tipo de herramientas.
• Avanzado: determinan a las herramientas que además de tener el mayor
número de funcionalidades propias de pruebas de carga poseen características
adicionales que las hace poseedoras de ventajas comparativas muy altas frente
a las demás.
En el proceso de análisis de las 19 herramientas se evidenciaron algunos detalles
que a continuación se citarán:
• La herramientas que componen la categoría bajo, en promedio tiene el 33%
de las funcionalidades evaluadas, las de la categoría medio tienen el 51% y
las de la categoría avanzada tiene el 71%.
165
• Solo el 21% de las herramientas evaluadas tienen la posibilidad de realizar
pruebas de funcionalidad y la mayoría de éstas está ubicada en la categoría
avanzada, lo cual podría indicar que uno de los factores diferenciadores de
las herramientas de carga, es la ausencia o presencia de dicha
funcionalidad.
• El 21% de las herramientas evaluadas es open source (Código libre) lo cual
permite no solo utilizar gratuitamente todas sus funcionalidades, si no
también modificar el código según se necesite. En muchos casos las
herramientas hacen parte de empresas que aportan código y toman
funcionalidades de la comunidad, y venden algunas funcionalidades mucho
más avanzadas bajo licencia de protección a los derechos de autor, ésta
modalidad es muy común en la actualidad y permite que el desarrollo de
productos de diversas funcionalidades avance ostensiblemente.
• El 89% de las herramientas están implementadas en idioma inglés lo cual
puede causar una baja tasa de utilización en regiones en las cuales éste
idioma no es muy popular y puede explicar el hecho de que herramientas
con Jmeter que tienen soporte para varios lenguajes sea muy popular en la
comunidad latina.
• El 68% de las herramientas son multiplataforma, es decir son portables lo
que indica que la tendencia del mercado es promover herramientas de éste
tipo que puedan ser utilizadas en distintos sistemas de forma transparente,
siendo muy congruente dicha cifra con el hecho de que el 47% de dichas
herramientas permiten realizar pruebas en múltiples segmentos, que en
algunos casos llevan a realizar pruebas en sistemas o plataformas de
distinto tipo.
• El 47% de las herramientas evaluadas permite la utilización de extensiones,
que generalmente son componentes adicionales de monitoreo. Es por esto
que dicha característica se convierte en un elemento diferenciador en el
mercado de las herramientas de carga.
166
• . El número promedio de reportes nativos de las herramientas evaluadas es
de 12 y demuestra que uno de los puntos fuertes de una herramienta de
este tipo se apoya en la posibilidad de visualizar y evaluar los resultados de
las pruebas correctamente.
• Finalmente el hecho de que el solo el 5% de las herramientas tenga una
descripción de la escalabilidad de los usuarios deja varios puntos muertos
en la planeación de las pruebas ya que no se pueden estimar los requisitos
de infraestructura necesarios, sin embargo se puede explicar, debido a que
son muchos los factores que pueden influir en las pruebas, lo que hace
sumamente difícil el cálculo de la escalabilidad de la infraestructura a usar
con determinados usuarios virtuales concurrentes, por parte de las
empresas desarrolladoras de las herramientas evaluadas.
167
Tabla 2 - Herramienta de nivel bajo.
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
1.
Dirección
url del
fabricante
www.verisi
um.com
www.stresstest
er.net
www.alvico
m.hu
www.microsoft
.com
www.paessle
r.com
www.automated
qa.com
www.clanprod
uctions.com
2.
Tipo
licencia y
precio
S$995.00
(50 UV),
US$2,995.0
0 (100 UV)
y más de
200 UV
necesita
contacto
con el
fabricante.
Licencia con
precios
pactados por
contacto con
distribuidor.
Permite
evaluar demo
previa
suscripción al
sitio.
Producto
licenciado.
Precio
directament
e dado por
contacto.
Prueba de 90
días. Licencia
acoplada al
valor de la
licencia Visual
Studio Team
System 2008 -
Aproximadame
nte desde
US$5190
Desde
$249.95
US$1999 -
Licencia
completa
Licenciado.
Precios
mediante
contacto
directo con
distribuidor
3. Acceso al No No No No No No No
168
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
código
fuente
4. Plataforma
Windows
XP/2000/20
03/NT
Windows –
Linux y Unix
Linux,
Windows,
HP Unix
Microsoft
Windows
98/Me/NT/200
0/XP/2003
Windows
98/ME/NT/20
00/XP/2003/
Vista
Windows
98/ME/NT/2000/
XP/2003/Vista/N
T
Cualquier
plataforma que
soporte Java 2
Standard
Edition 1.4.2 o
posterior
5. Multiplatafo
rma No Si Si No No No Si
6. Requisitos
de hardware
3 sistemas
independie
ntes pero
no
especificad
No
especificados
No
especificad
os
2.0-GHz CPU,
512 MB RAM,
8-GB de Disco
Duro
Procesador 1
Ghz – RAM
512 MB
Intel Pentium 4
3 GHz – RAM 1
GB
No
especificado
169
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
as sus
característi
cas
7. Idiomas
soportados Inglés Inglés Inglés Inglés Inglés Inglés Inglés
8.
Manejo de
perfiles de
usuarios
virtuales
Si Si
No
especificad
o
Si Si
(Limitados) Si Si
9. Uso de
variables No No Si No Si Si No
10. Soporte IP
Spoofing No No No No No No No
170
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
11.
Visualizació
n en tiempo
real
Si Si
No
especificad
o
Si Si Si Si
12.
Pruebas
programada
s
No No
No
especificad
o
No Si Si Si
13. Proxy http Si Si
No
especificad
o
Si Si No
14. Proxy https No Si
No
especificad
o
No Si No
15. Scripting Si Si Si Si Si Si
171
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
16. Controlador
es Lógicos No No
No
especificad
o
No Si Si No
17.
Número de
informes
nativos
10 Entre 4 y 10
No
especificad
o
No
especificado 10 +8 Si (7)
18.
Diseño de
informes
personaliza
dos
Si Si
No
especificad
o
Si No No No
19. Protocolos http Http-https http-https http-https Http 1.0-1.1-
https
Http 1.0-1.1-
https
Http 1.0-1.1-
https
20. Monitoreo
de Bases de Si (5 tipos) No No
especificadNo No No No
172
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
datos o
21.
Monitoreo
Sistema
Operativo
Si (2 tipos) No
No
especificad
o
Si Si (1) No No
22. Monitoreo
web Server
Si (11
tipos) Si
No
especificad
o
Si Si (5) No No
23. Pruebas
LDAP No No
No
especificad
o
No No No No
24. Pruebas
FTP No No
No
especificad
o
No No No No
173
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
25.
Pruebas
Web -
Services
No No
No
especificad
o
No No No No
26.
Pruebas
Bases de
datos
No No
No
especificad
o
No No No No
27. Pruebas
Mail-Server No No
No
especificad
o
No No No No
28. Manejador
de Cookies Si Si
No
especificad
o
Si Si Si Si
29. Administrac
ión remota No No No No No No No
174
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
30. Temporizad
ores No Si
No
especificad
o
No Si (2) Si Si
31.
Pruebas en
segmentos
múltiples
Si No
No
especificad
o
No No Si No
32. Pruebas
funcionales No No No No No No Si
33.
Posibilidade
s de
extensiones
No No
No
especificad
o
No No No No
34.
Emulación
de
velocidad
Si No
No
especificad
o
No Si No No
175
# Nombre vPerforme
r StressTester
LoadMana
ger
Visual Studio
Team System
2008 Test
Load Agent
Webserver
Stress Tool TestComplete 6 Jblitz
de conexión
de usuarios
35.
Escalabilida
d de
usuarios
No
especificad
a
No
especificado
No
especificad
o
Depende del
número de UV.
No
especificado No especificada
No
especificada
176
Tabla 3 - Herramienta de nivel medio.
# Nombre OPENSTA
PROXY
SNIFFE
R
Qtest 5.0
Web
performance
load tester
Web
performance
load tester
WEBLOAD
1. Dirección url del
fabricante
www.openst
a.org
www.pro
xy-
sniffer.co
m
www.quotiu
m.com
www.webperfor
manceinc.com
www.webperform
anceinc.com www.radview.com
2. Tipo licencia y
precio
Freeware -
Opensource
Entre
606 USD
y 8.288
USD
(Existen
múltiples
opciones
de
licencia
miento)
Licenciado.
Precios
mediante
contacto
directo con
distribuidor
Licencia ilimitada
$20,000
Licencia ilimitada
$20,000
OpenSource.
Licenciado. Precios
mediante contacto
directo con distribuidor.
177
# Nombre OPENSTA
PROXY
SNIFFE
R
Qtest 5.0
Web
performance
load tester
Web
performance
load tester
WEBLOAD
3. Acceso al
código fuente Si No No No No Si
4. Plataforma
Windows
9x/NT/2000/
XP
Windows
2000/XP
/2003/Vi
sta,
Solaris,
Linux,
BSD y
Mac OS
X
Windows
NT/2000/200
3/XP
Windows 98/Me/
/2000/XP/2003 –
Linux - Solaris
Windows 98/Me/
/2000/XP/2003 –
Linux - Solaris
Windows, linux, Solaris
5. Multiplataforma No Si No Si Si Si
6. Requisitos de
hardware
Pentium 200
mhz, 80 Mb
Ram, 20 Mb
120 MB
HD
RAM
No
especificado
s
No especificados No especificados
178
# Nombre OPENSTA
PROXY
SNIFFE
R
Qtest 5.0
Web
performance
load tester
Web
performance
load tester
WEBLOAD
HD. 512-
1024 MB
7. Idiomas
soportados Inglés Inglés Inglés Inglés Inglés Inglés
8.
Manejo de
perfiles de
usuarios
virtuales
Si Si Si Si Si
9. Uso de variables Si Si Si No No Si
10.Soporte IP
Spoofing Si Si No No No
11.Visualización en
tiempo real Si Si Si Si Si Si
12. Pruebas Si Si Si Si Si
179
# Nombre OPENSTA
PROXY
SNIFFE
R
Qtest 5.0
Web
performance
load tester
Web
performance
load tester
WEBLOAD
programadas
13. Proxy http Si Si Si Si Si Si
14. Proxy https Si Si Si Si Si Si
15. Scripting Si Limitado Si Si Si Si
16.Controladores
Lógicos No Si Si No No No
17.Número de
informes nativos 17 18 +20 6 6 +20
18.
Diseño de
informes
personalizados
Si (algunos) No Si Si Si Si
19. Protocolos Http 1.0-1.1-
https
Http 1.0-
1.1-https
Http 1.0-1.1-
https Http-https Http-https Http 1.0-1.1-https
180
# Nombre OPENSTA
PROXY
SNIFFE
R
Qtest 5.0
Web
performance
load tester
Web
performance
load tester
WEBLOAD
20.Monitoreo de
Bases de datos No Si (5) No No No
21.
Monitoreo
Sistema
Operativo
Si (1) No Si (2) Si (2 tipos) Si (2 tipos) No
22.Monitoreo web
Server No Si (10) Si (8) No No No
23. Pruebas LDAP No No No No No No
24. Pruebas FTP No No No No No No
25.Pruebas Web -
Services No No No Si Si No
26.Pruebas Bases
de datos No No No No No No
181
# Nombre OPENSTA
PROXY
SNIFFE
R
Qtest 5.0
Web
performance
load tester
Web
performance
load tester
WEBLOAD
27.Pruebas Mail-
Server No No No No No No
28.Manejador de
Cookies Si Si Si Si Si Si
29.Administración
remota No Si No No No No
30.Temporizadores Si Si Si Si Si Si (5)
31.
Pruebas en
segmentos
múltiples
Si Si No No No No
32.Pruebas
funcionales No No No No No No
33.Posibilidades de
extensiones Si No Si No No Si
182
# Nombre OPENSTA
PROXY
SNIFFE
R
Qtest 5.0
Web
performance
load tester
Web
performance
load tester
WEBLOAD
34.
Emulación de
velocidad de
conexión de
usuarios
No Si No Si Si Si
35.Escalabilidad de
usuarios
No
Especificada
No
especific
ado
No
especificada No especificado No especificado No especificado
183
Tabla 4 - Herramienta de nivel avanzado.
# Nombre MINQ -
PureLoad Jmeter QEngine TestMaker NeoLoad
APPPERFECT TEST
SUITE STUDIO
1. Dirección url
del fabricante www.minq.se
jakarta.
apache
.org/jm
eter
www.adven
tnet.com
www.pushtotest
.com
www.neotys.co
m www.appperfect.com
2. Tipo licencia y
precio
Edición Web,
$8,990 para
Usuarios
virtuales
ilimitados
Edición
empresarial
inicial para 50
usuarios
virtuales US
$9,990
Freewa
re -
Openso
urce
De US$795
a $12,995
dependiend
o del tipo
de licencia
y el número
máximo de
usuarios
virtuales
Freeware -
Opensource
De € 742 a €
32,063
dependiendo
de la licencia
más los
módulos
adicionales que
están entre €
2,142 y € 3,245
Toda la suite con las
funcionalidades totales
desde US$2980. Por
componente el precio
varía
184
# Nombre MINQ -
PureLoad Jmeter QEngine TestMaker NeoLoad
APPPERFECT TEST
SUITE STUDIO
3. Acceso al
código fuente No Si No Si No No
4. Plataforma
Windows
NT/200/XP
(Server
Editions), Linux
Redhat,
Solaris/SPARC 8
y plataformas
con Java 2
Standard Edition
1.4.2
Cualqui
er
platafor
ma que
soporte
Java 2
Standar
d
Edition
1.4.2 o
posteri
or
Linux y
Windows
Windows
2000/XP/2003/
Vista, Linux,
UNIX y Mac OS
X
Windows
2000/XP/2003/
Vista Linux
RedHat y
Mandriva,
Solaris 10
Windows
2000/XP/2003, Linux
x86, Solaris 8/9, Mac
OS X
5. Multiplataforma Si Si Si Si Si Si
6. Requisitos de RAM 512 MB 20 No
especifi
No
especificadNo 185 MB HD No especificado
185
# Nombre MINQ -
PureLoad Jmeter QEngine TestMaker NeoLoad
APPPERFECT TEST
SUITE STUDIO
hardware MB HD cados os especificados RAM 150 MB
7. Idiomas
soportados Inglés
Españo
l,
Inglés,
Japoné
s,
Norueg
o
Alemán
,
Francé
s,
Chino
Inglés Inglés Inglés –
Francés. Inglés
8.
Manejo de
perfiles de
usuarios
Si Si Si Si Si Si
186
# Nombre MINQ -
PureLoad Jmeter QEngine TestMaker NeoLoad
APPPERFECT TEST
SUITE STUDIO
virtuales
9. Uso de
variables Si Si Si Si Si Si
10.Soporte IP
Spoofing Si Si No Si Si
11.Visualización
en tiempo real Si Si Si Si Si Si
12.Pruebas
programadas Si Si Si Si Si Si
13. Proxy http Si Si Si Si Si Si
14. Proxy https Si No Si Si Si Si
15. Scripting Si Si Si Si Si Si
16.Controladores
Lógicos Si Si No Si Si Si
187
# Nombre MINQ -
PureLoad Jmeter QEngine TestMaker NeoLoad
APPPERFECT TEST
SUITE STUDIO
17.
Número de
informes
nativos
+8 13 16 +10 11 + monitores +15
18.
Diseño de
informes
personalizados
No Si No No No Si
19. Protocolos Http 1.0-1.1-
https
Http
1.0-1.1-
https
Http 1.0-
1.1-https
Http 1.0-1.1-
https
Http 1.0-1.1-
https Http 1.0-1.1-https
20.Monitoreo de
Bases de datos No No Si (3) No Si (5) Si (6)
21.
Monitoreo
Sistema
Operativo
No No Si (3) Si (1) Si (5) Si (5)
22. Monitoreo web No Si (1) No No Si (12) Si (10)
188
# Nombre MINQ -
PureLoad Jmeter QEngine TestMaker NeoLoad
APPPERFECT TEST
SUITE STUDIO
Server
23. Pruebas LDAP Si Si No No No No
24. Pruebas FTP Si Si No No No No
25.Pruebas Web -
Services Si Si Si No No Si
26.Pruebas Bases
de datos Si Si No No No No
27.Pruebas Mail-
Server Si Si No No No No
28.Manejador de
Cookies Si Si Si Si Si Si
29.Administración
remota No SI Si No No Si
30.Temporizadore Si Si Si (5) Si Si (3) Si
189
# Nombre MINQ -
PureLoad Jmeter QEngine TestMaker NeoLoad
APPPERFECT TEST
SUITE STUDIO
s
31.
Pruebas en
segmentos
múltiples
Si Si Si Si No Si
32.Pruebas
funcionales No No Si Si No Si
33.Posibilidades
de extensiones Si Si Si Si Si Si
34.
Emulación de
velocidad de
conexión de
usuarios
No No Si Si Si Si
35.Escalabilidad
de usuarios No especificada
No
especifi
cada
500 Mb por
250 UV
No
especificada
No
especificada No especificada
190
191
4 COMPARACIÓN DE HERRAMIENTAS PARA PRUEBAS DE CARGA : UN CASO DE ESTUDIO
Las pruebas de carga [17] permiten la medición del comportamiento del sistema mientras se aumenta la carga del
sistema (el número de usuarios que trabajan simultáneamente y el número de transacciones).
Las pruebas de carga, se realizan generalmente para emular los ambientes reales a los cuales un software
determinado se enfrentará, predecir su comportamiento y, en caso de encontrar un problema arquitectónico,
resolverlo. Así, se pretende la disminución de los riesgos de posibles problemas de concurrencia y caídas en
ambientes productivos reales.
[18] Las prueba de cargan utilizan generadores de carga que son usados para probar los requisitos de calidad tales
como el rendimiento y el estrés. Una carga es una serie de insumos que simula un grupo de transacciones; por otro
lado, [20] una transacción es una unidad de trabajo visto desde el sistema del lado del usuario final.
192
[21] Las pruebas de carga miden cuánto tiempo tiene un sistema para llevar a cabo diversos conjunto de tareas y
funciones en condiciones normales o predefinidas. Se presenta un error en éste tipo de pruebas cuando las tareas
no pueden ser ejecutados dentro de los plazos límites (de preferencia definidos por el grupo de gestión o
comercialización del producto). Debido a que un objetivo de las pruebas carga es determinar si el rendimiento del
sistema satisface los requisitos de concurrencia, es pertinente que la configuración mínima y máxima de los niveles
de actividad se determinará antes de que comience la prueba.
Alrededor de las pruebas de carga, existen conceptos básicos a la hora de diseñar, ejecutar y analizar dichas
pruebas, por lo cual es importante entenderlos y mostrar la forma en que se pueden aplicar a una prueba real.
En este artículo, se diseñan pruebas de carga a una aplicación web[78] y se ejecutan con 5 herramientas
especializadas, teniendo un caso de estudio compuesto por 2 casos de prueba y 2 escenarios que hacen uso de
dichos casos de prueba.
El artículo, se organiza de la siguiente manera: en primer lugar, se hace una introducción al tema de las pruebas de
carga, siguiendo con una base conceptual o marco teórico; posteriormente, se define el caso de estudio,
describiendo los casos y los escenarios de prueba; acto seguido, se realiza el análisis de los resultados y, en la
parte final, se presentan las conclusiones y el trabajo futuro.
193
4.1 MARCO TEÓRICO BASE PARA LA COMPARACIÓN
[19] Las pruebas de carga son un subconjunto de las pruebas de estrés (o rendimiento). En ellas, se comprueba que
un sitio web puede manejar un gran número de usuarios concurrentes, manteniendo al mismo tiempo aceptable de
respuesta.
Las pruebas de carga, se relacionan directamente con las pruebas de stress, que se definen como: “Pruebas
realizadas para evaluar un sistema o componente más allá de los límites de sus requisitos especificados” [58] y las
pruebas de rendimiento, que se definen como: “Pruebas realizadas para evaluar el cumplimiento por parte de un
sistema o componente de los requisitos de rendimiento especificados” [58], siendo su principal objetivo probar un
nivel específico de capacidad de concurrencia de usuarios generalmente especificados en los requisitos de una
aplicación de software.
Las pruebas de carga, vistas desde el marco evaluativo de un producto con calidad, según lo define la norma ISO
9126 [67], sirven para valorar los parámetros de eficiencia y, en cierta medida, de fiabilidad de un producto de
software.
194
Algunos conceptos importantes a la hora de diseñar, ejecutar y analizar unas pruebas de carga son:
1. Caso de prueba: según la norma IEEE 610[58] se define como: “Conjunto de entradas de prueba, condiciones de
ejecución, y resultados esperados desarrollados para un objetivo en particular, tal como el modo en el cual un
programa en particular se ejecuta o una verificación de la especificación de los requisitos”. Por otro lado, según la
norma IEEE 826[68], la especificación de un caso de prueba y la especificación de un procedimiento de prueba
se componen básicamente de los siguientes elementos: identificador, propósito, pasos, elementos por probar,
valores de entrada, valores de salida, precondiciones, posTcondiciones, necesidades del entorno, requisitos
especiales de procedimientos, resultados esperados, dependencias y requisitos.
2. Banco de pruebas (test bed): en el cual se describen las características del entorno de prueba. Según la normal
IEEE 610 [58], se define como: “ambiente formado por hardware, instrumentos, simuladores y el soporte software
necesario para probar un sistema o un componente”.
3. Temporizador o perfil de carga: función que determina la distribución de carga de usuarios virtuales concurrentes
(UVC) versus tiempo de carga. Existen diversas funciones, generalmente utilizadas, para realizar las pruebas de
carga, tales como: trapezoidal, incremental lineal, de rendimiento constante, aleatorio Gaussiano, aleatorio
uniforme, incremental a Intervalos e incremental por pasos, entre otras.
4. Escenario de prueba en pruebas de carga: define las características de ejecución y las políticas de carga
asociadas a uno o varios casos de prueba. Generalmente, durante una prueba de carga se deben definir varios
escenarios de prueba con el fin de comparar satisfactoriamente los datos medidos y así poder sacar deducciones
basadas en elementos matemáticos y comparaciones estadísticas.
195
5. Tipos de escenarios en pruebas de carga: Existen dos tipos de escenarios según la conformación de los flujos o
casos de prueba durante la ejecución de la prueba de carga:
a. Escenario simple: tiene solo un caso de prueba o flujo para ser emulado, es decir, el 100% de la carga
transaccional de usuarios concurrentes se utiliza para un solo flujo o caso de prueba.
Escenario compuesto: tiene dos o más casos de prueba o flujos para ser emulados. Así, cada uno de ellos tendrá un
porcentaje de carga transaccional de usuarios concurrentes asignado y, por ende, la sumatoria de la carga
transaccional de todos ellos deberá ser 100%.
4.2 Herramientas a utilizar y características gener ales
Se eligieron 5 herramientas de pruebas de carga disponibles de forma gratuita en las páginas de los fabricantes,
procurando seleccionar las más representativas en el mercado. Entre ellas, se encuentran herramientas de tipo
opensource y otras comerciales, las cuales requieren licencia. A continuación, se listan las herramientas usadas y
algunos datos relevantes sobre las mismas:
1. Webload[69]: software opensource que permite realizar pruebas de carga con ilimitado número de usuarios.
Existen modalidades adicionales de pago, que permiten ampliar las capacidades del programa. Web load Open
196
Source, hace parte de una suite de pruebas y monitoreo ofrecido por la empresa RADVIEW y cuya licencia es
distribuida según el límite de usuarios concurrentes simulados. Webload Open Source esta basada en 12 años de
desarrollo del producto propietario. Webload fue concebida por Ilan Kinreich quien fundó Mercury Interactive
adquirida en 2006 por HP. Entre los clientes más destacados que usan ésta herramienta se encuentra: NASA,
Airbus, Royal bank of Scotland, Citigroup, Adobe, American Express, entre otros.
2. Jmeter[70]: Es un herramienta de tipo Open source perteneciente al proyecto Apache Jakarta, la cual fue liberada
en su primera versión 1.0 por Stefano Mazzocchi (autor de Apache Cocoon) el 15 diciembre de 1998. Cuenta con
una licencia de tipo Apache License 2.0 y múltiples usuarios corporativos que la hacen uso de ella.
3. Proxy sniffer[71]: Herramienta con licencia propietaria cuyo precio depende del número máximo de usuarios
virtuales emulados. La versión usada para las pruebas es una versión libre limitada a 12 usuarios concurrentes
virtuales máximos y sin algunas funcionalidades de la versión profesional. Algunos de las organizaciones más
importantes que usan dicha herramientas son: Apple Inc.,Fujitsu Siemens Computers GmbH, Vodafone, Ericsson
Inc entre otros
4. QEngine[72]: herramienta tipo web multiplataforma con licenciamiento propietario. La versión que se usó en las
pruebas es la versión de pruebas profesional con 15 días de periodo de evaluación y con máximo 25 usuarios
virtuales emulados. La empresa diseñadora, AdventNet, cuenta con múltiples herramientas enfocadas al manejo
de funciones de red y administración y monitoreo de sistemas informáticos en empresas IT; entre sus clientes
más importantes están: NASA, departamento de defensa de los Estados Unidos, la armada de los estados
unidos, entre otras.
5. Neoload[73]: herramienta construida por la empresa NEOTYS con licenciamiento basado en los usuarios virtuales
emulados máximos. La versión usada durante las pruebas es una versión de pruebas con tiempo límite de 30
197
días y máximo 10 usuarios virtuales emulados. Entre sus clientes más importantes se encuentran: Xerox
Corporation, Motorola Inc., AOL Corp., Hilton International, entre otros.
4.3 CASO DE ESTUDIO
Para la implementación de la prueba, se instala el software Mantis versión 1.2.0a1 Released disponible de forma
gratuita [74], MySQL Versión 5.0 [75], Apache versión 2.0 [76] y PHP 4.4.9 [77], igualmente disponibles en la web
del proyecto respectivo y se crea un usuario tipo administrador en ambas instalaciones.
Mantis, es un software opensource para el reporte y administración de incidencias. Cuenta con distintas
funcionalidades como reporte, envío vía correo electrónico de notificaciones, manejo de incidencias por proyectos y
búsquedas con filtros, entre otros.
El planteamiento general de las pruebas, se compone de 2 casos de pruebas descritos bajo el estándar IEEE 829
[68]—obviando algunos ítems que no aplican para la prueba—puntos que definen los dos flujos que se ejecutarán
durante las pruebas mediante dos escenarios específicos y que corresponden a una radicación de un requisito y a
una búsqueda con filtros en la aplicación Mantis, siendo estas funciones las más usadas en dicha aplicación.
198
Al ejecutar las pruebas para cada aplicación y escenario, se establecen los siguientes parámetros, con el fin de que
las pruebas sean totalmente controladas y los ambientes sean iguales:
1. Desinstalación de herramientas o aplicaciones anteriores.
2. Reinicio tanto de servidor como de máquina de generación de carga por cada carga.
Caso de Prueba 1 (Especificación y procedimiento de prueba):
Objetivo: Ingresar a la aplicación y realizar la radicación de un requisito.
Pasos:
1. Ingresar a la dirección http://192.168.1.1/mantis
2. Autenticarse con el nombre de usuario: prueba y contraseña: prueba.
3. Dar clic en el menú superior “Solicitar Requerimiento”.
4. En los campos de la página, introducir los siguientes datos:
a. Reproductibilidad: siempre
b. Severidad: mayor
199
c. Prioridad: normal
d. Plataforma:
e. Sistema Operativo: Windows XP
f. Versión: SP1
g. Desarrollo del producto: No aplica
h. Asignar a: prueba
i. Resumen: se presenta un bloqueo en el correo web institucional.
j. Descripción: cuando se ingresa a la dirección de correo web institucional aparece un letrero de error con el
título: “PAGINA BANNEADA POR POLITICAS DE USO INTERNO”.
k. Pasos para reproducirlo: Ingresar a la dirección 192.168.1.1/webmail.
l. Información adicional: el navegador web utilizado es Mozilla Firefox 3.0 R.
m. Acceso: publico
5. Dar clic en el botón: Enviar Reporte.
6. Dar clic en el menú superior: “Salir”.
Resultados esperados:
1. Se debe guardar el requisito con los datos ingresados y con un identificador incremental correctamente.
Precondiciones:
200
• El nombre de usuario y contraseña, utilizados para la autenticación, se debieron configurar con anterioridad,
incluyendo los respectivos permisos de creación de requisitos.
• Se debió configurar un proyecto y una categoría, para que la radicación del requisito sea posible.
Poscondiciones : El sistema, además de tener un registro adicional, pasará de estar en estado “conectado” a
“desconectado”.
Requisitos: durante la prueba de carga, se deberá utilizar de carga del 60% respecto de la carga total emulada en
el escenario compuesto.
Caso de Prueba 2 (Especificación y procedimiento de prueba):
Objetivo: Realizar una búsqueda haciendo uso de 1 filtro.
Pasos:
1. Ingresar a la dirección http://192.168.1.1/mantis
2. Autenticarse con el nombre de usuario: prueba y contraseña: prueba.
3. Dar clic en el menú superior “Ver Requerimientos”.
201
4. En el Filtro “Status” elegir: “Cualquiera”
5. Dar clic en el botón filtrar.
6. Dar clic en el menú superior: “Salir”.
Resultados esperados:
1. Se deben mostrar los registros con cualquier estado.
Precondiciones:
• El nombre de usuario y contraseña utilizados para la autenticación, se debieron configurar con anterioridad con
los respectivos permisos de creación de requisitos.
• Se debió configurar un proyecto y una categoría para que la radicación del requisito sea posible.
• Se debieron realizar de 50 a 100 radicaciones con el fin de que se produzca una carga suficiente al realizar la
consulta en la base de datos. Para éste fin se deberá correr el caso de prueba 1 con una concurrencia de 100
usuarios por 1 minuto para que se generen los suficientes registros necesarios para la prueba.
Poscondiciones : El sistema, después de arrojar el listado de los registros encontrados, pasará de estar en estado
“conectado” a “desconectado”.
202
Requisitos : durante la prueba de carga se deberá reutilizar una carga del 40% respecto de la carga total emulada
en el escenario compuesto.
4.4 Escenarios de prueba
Se determinan dos escenarios de pruebas: el primero, es un escenario simple en el cual se realiza la prueba usando
únicamente un caso de prueba; el segundo, es un escenario compuesto, en el cual se usan los dos casos de prueba
planteados con anterioridad y se realiza un balanceo de carga específico para cada uno de ellos.
Escenario de prueba 1:
Nombre: Escenario Simple
Duración: 30 minutos
Descripción del generador de carga: Se configura una velocidad de emulación de conexión de 256 Kbps para cada
usuario concurrente.
203
Políticas de carga: se genera una carga con un temporizador con una función constante incremental (Véase la
Ilustración 1), determinada por un inicio de 1 usuario concurrente y finalizada por 10 usuarios concurrentes con un
incremento regular ascendente.
Descripción: La carga, corresponde al caso de prueba 1 y determina la función de radicación de la aplicación web.
Ilustración 7 - Comportamiento carga versus tiempo mediante función constante incremental.
204
Escenario de prueba 2:
Nombre: Escenario Compuesto
Duración: 30 minutos
Descripción del generador de carga: Se configura una velocidad de emulación de conexión de 256 Kbps para cada
usuario concurrente.
Políticas de carga: se generará una carga con un temporizador con una función trapezoidal (Véase la Ilustración 2),
determinada por:
• De 1 a 2 usuarios virtuales concurrentes durante 5 minutos.
• 10 usuarios virtuales concurrentes durante 26 minutos de forma constante.
• De 10 a 0 usuarios virtuales concurrentes durante 2 minuto
Descripción: La carga corresponde al caso de prueba 1, que determina la función de radicación del sistema web,
con un total del 40% de la carga y el caso de prueba 2, con un total de un 60% de la carga, que determina la función
de búsqueda de la aplicación web
205
Ilustración 8 - Comportamiento carga versus tiempo mediante función trapezoidal.
4.5 INFRAESTRUCTURA A UTILIZAR
Todas las pruebas se realizan sobre una LAN corporativa centralizada, como se muestra en la Ilustración 3, en un
conjunto de switch 10/100 con conexiones UTP CAT 5E con una configuración de red tipo C cuya parte constante es
192.168.1.x y cuya máscara de subred es de 24 bit (255.255.255.0).
Servidor
El servidor en el cual se instaló la aplicación cuenta con las siguientes especificaciones:
206
• Atlhon XP, 2 Ghz.
• Memoria RAM de 500 M.
• 1 Discos SATA de 200 GB.
• Conexión LAN. 100 Mbps.
• Sistema operativo: Windows 2003 Server R1.
La configuración de red está dada por:
• IP: 192.168.1.1
• Mascara de subred: 255.255.255.0
Computador portátil generador de carga
El computador portátil utilizado para instalar las herramientas de carga y posteriormente realizar las pruebas de
carga, cuenta con las siguientes especificaciones:
• Portátil HP 2345 Turion X2
• Memoria RAM de 2 GB DDR 2.
• 1 Discos Duro de 160 GB.
• Conexión LAN. 100 Mbps.
• Sistema operativo: Windows XP SP 2
207
La configuración de red es:
• IP: 192.168.1.2
• Mascara de subred: 255.255.255.0
Ilustración 9 - Infraestructura de red.
208
4.6 Medidas a tener en cuenta
Durante las pruebas realizadas con cada herramienta, se toman en cuenta las siguientes medidas para su posterior
análisis:
1. Consumo de recursos del sistema en el cual se genera la carga: incluye uso de la CPU y utilización de memoria
RAM.
2. Resultados generales de las mediciones arrojadas después de la carga por cada herramienta.
Cado una de estas medidas, se tomará teniendo en cuenta tanto el escenario como la herramienta que se está
utilizando en determinado momento.
4.7 ANÁLISIS DE RESULTADOS
Durante la ejecución de los dos escenarios de prueba contemplados, se presentó una similitud esperada en los
resultados de las pruebas en todas las herramientas, en donde no se encontraron puntos de quiebre en la aplicación
y el máximo tiempo de página fue de 7 segundos teniendo pequeñas varianzas de 500 a 1200 milisegundos entre
las mediciones de las herramientas.
209
Resultados arrojados por herramienta:
A continuación se presentan los resultados de las pruebas, y el rendimiento del equipo de hardware en el cual
estaba instalada cada herramienta de carga.
1. Webload[4]: durante la ejecución de los dos escenarios de pruebas, se presentaron picos en el carga de
procesamiento con un máximo de 50%, teniendo mayor constancia la lectura del escenario número dos. El
consumo de memoria física se comportó estable durante la ejecución de los dos escenarios con un valor máximo
de 40% ( Ver Gráfica 1).
Ilustración 10 - Consumo de Memoria y procesador herramienta WEBLOAD.
210
Generalidades: la forma de definir la ejecución de las pruebas es intuitiva y sencilla. La definición de los dos
escenarios de pruebas (tanto el simple como el compuesto) fueron posibles y los detalles como el ancho de banda y
el porcentaje de carga en el escenario compuesto fueron configurables mediante asistentes. Al arrojar los datos, los
informes que se presentan son de dos tipos, gráficos configurables y datos específicos con posibilidad para su
exportación en diferentes formatos. Ésta última opción es sumamente útil a la hora de realizar un análisis más
meticuloso ya que cuenta con 37 tipos de datos básicos sobre el comportamiento de la prueba. Es bastante notorio
que no tiene monitores adicionales en la versión open source, sin embargo, en la versión profesional cuenta con
adiciones tanto de monitoreo como de soporte de tecnologías como Flex[79], AJAX[80], entre otras.
2. Jmeter[70]: Ésta herramienta no permite definir pruebas con funcionalidades balanceadas específicas, sin
embardo, se pueden definir cargas con varios flujos sin especificar porcentaje de utilización de las políticas de
carga. Durante las dos pruebas, se presentaron picos de consumo de procesador con un máximo de 95% y el
comportamiento de la memoria fue relativamente constante con un consumo máximo de 55% durante ambas
pruebas (Ver Gráfica 2).
211
Ilustración 11 - Consumo de Memoria y procesador herramienta JMETER.
Generalidades: En general es una herramienta para pruebas de carga poderosa, fácil de usar y totalmente
gratis[13]. En pruebas es muy flexible, salvo cuando éstas no pueden ser en segmentos múltiples y todo se debe
centralizar en una misma máquina; en ese caso, se presentan bloqueos y malos funcionamientos cuando el
número de usuarios virtuales es muy alto. Con solo ejecutar el programa, el proceso del sistema ocupa de 90 a
120 megas de espacio en memoria con una utilización mediana del disco duro. En cuanto a sus informes, los
cuales son llamados listener se presentan confusos en muchos casos, aunque el llamado agregate graphic es
completo y fácil de entender. No permite una exportación específica a formatos como doc, pdf o algún tipo de
texto enriquecido, sin embargo, en los gráficos permite la exportación a jpg y de los datos a cvs. En ciertos
momentos de la prueba cuando se cambia de ventana de visualización y se intenta volver a la de resultados, se
pierde la imagen en tiempo real de la prueba y solo hasta que ésta termina se pueden visualizar la ventana
nuevamente. Algún importante es que no existe una información específica durante la prueba que ayuda a saber
212
en qué porcentaje se ha ejecutado y cuando falta para su terminación. No permite la emulación de velocidad de
usuarios virtuales.
3. Proxy sniffer[6]: Ésta herramienta, al igual que JMETER no permite definir pruebas con funcionalidades
balanceadas específicas, sin embargo, se pueden definir cargas con varios flujos sin especificar porcentaje de
utilización de las políticas de carga. Durante las dos pruebas, se presentaron picos en el consumo del procesador
con un máximo de 93% y en cuanto al consumo de memoria tuvo un máximo de uso del 48% (Ver Gráfica 3).
Ilustración 12 - Consumo de Memoria y procesador herramienta 4.
Generalidades: Proxy Sniffer, es una herramienta con interfaz web construida en java, que dada su forma de
trabajar consume inicialmente muchos recursos. Permite definir clúster para realizar pruebas con balanceo de
cargas en diferentes máquinas. Tiene 18 graficas con posibilidad de exportación a pdf e imágenes. Permite
213
exportar los datos a cvs para su posterior análisis. Además de esto cuenta con una funcionalidad muy útil que
permite comparar resultados entre varias pruebas.
4. QEngine[72]: Durante las dos pruebas, se presentaros picos en el consumo de procesador, especialmente
durante la segunda prueba con un máximo de 98%. En cuanto a la memoria el máximo consumo fue del 50%
(Ver Gráfica 4).
Ilustración 13 - Consumo de Memoria y procesador herramienta QENGINE
.
214
Generalidades: Ésta herramienta es de tipo web construida en java y jsp con grandes posibilidades, ya que permite
su fusión con otras soluciones como monitores y plugins de compatibilidad con tecnologías como Flex, AJAX, entre
otras. Permite realizar pruebas funcionales y pruebas a servicios web. Cuando se inicia, se ejecuta un agente java y
permite agregar una barra de administración y monitoreo al explorador web (Internet Explorer o Mozilla Firefox).
Cuenta con notificaciones por e-mail y 16 reportes divididos en 5 tipologías. Tiene monitoreo de sistema operativo
(Windows, Linux y Solaris) y de bases de datos (Oracle, MySql, MS Sql). Su manejo es intuitivo y permite exportar
los reportes a formatos como pdf y cvs, entre otros. Se pueden comparar los resultados de varias pruebas y se
permite la ejecución de pruebas distribuidas.
5. Neoload[8]: durante ambas pruebas, se pudieron observar picos de consumo de procesador de máximo 38% y
utilización de memoria constante de 47%.(Ver Gráfica 5).
215
Ilustración 14 - Consumo de Memoria y procesador herramienta NEOLOAD.
Generalidades: Ésta herramienta cuenta con múltiples monitores, facilidad de creación de plan de pruebas y un
manejo de reportes y estudio de resultados muy intuitivo y potente. Permite crear manualmente el modelo de
políticas de variación de carga, lo cual no es muy común en las herramientas en general. El manejo de usuarios,
sesiones y parámetros de páginas es muy sencillo y fácilmente implementable. Permite emulación de velocidad
de usuario tanto de bajada como de subida. Su conjunto de monitores incluyen: monitoreo de red (rstat, snmp),
bases de datos (MS SQL SERVER, MYSQL, ORACLE, DB2, POSTGRESQL), webserver y contenedores web
(IIS, WEBLOGIC, WEBSPHERE, JBOSS, TOMCAT, ORACLE) y sistemas operativos (Linux, Solaris, Windows
entre otros).
216
Comentarios generales
En general, se puede notar que el menor consumo de memoria y procesamiento lo tiene la herramienta NEOLOAD
seguido muy de cerca por WEBLOAD. (Ver gráfica 6).
Ilustración 15 - Comparativa de Consumo de Memoria y procesador de las cinco herramientas probadas.
217
En cuanto a limitaciones en sus funcionalidades para la prueba propuesta y consumos altos de memoria y
procesamiento JMETER y PROXY SNIFFER se destacan, en tanto QENGINE aunque tiene un rendimiento
semejante al de dichas herramientas posee excelentes funcionalidades que los destaca entre las dos primeras.
218
CONCLUSIONES
• En la mayoría de los casos, las pruebas de software al interior de las organizaciones aunque cuentan con un
nivel de documentación del proceso congruente con modelos de calidad como CMMI e ISO, en la práctica, es
decir en el diario hacer, son muy informales y no son lo suficientemente acopladas a los estándares
referentes a las pruebas de software y a todo lo que su aplicación implica.
• Prácticas como verificación y validación, son herramientas fundamentales para realizar el aseguramiento de
la calidad de los productos de software; es así como lo planteado por CMMI y estándares de la IEEE crean
bases sólidas para su aplicación y desarrollo al interior de las organizaciones.
• Los modelos existentes de pruebas de software, permiten establecer metodologías que sugieren adquirir
distintos niveles de madurez en los procesos, sin embargo no especifican particularidades, lo cual conduce a
que la implantación de los mismos sea compleja.
• Las normas ISO estandarizan las generalidades de los procesos de software pero en ningún momento
sugieren como hacerlas al interior de una organización, este hecho da flexibilidad al modelo permitiendo
219
adaptarse a necesidades particulares, pero también crea dificultad adicional cuando se implanta al interior de
una organización.
• El hecho de que existan certificaciones internacionales es una muestra de la importancia de los procesos de
pruebas y del creciente interés de las empresas en estos procesos en conjunto con el aseguramiento de la
calidad.
• La complejidad de los procesos de pruebas de software crean una barrera que impiden a las empresas
utilizarlos al interior y por este motivo son subcontratados, además el costo asociado a la creación y
sostenimiento de un departamento de pruebas influye para que muchas empresas opten por la modalidad de
“outsourcing”.
• Los procesos de pruebas desarrollados al final de la etapa de codificación trae consigo altos índices de
riesgos que se ven reflejados en retrasos, altos costos, y baja calidad del producto de software.
• La aplicación de métodos de validación y verificación como elemento fundamental en los procesos de
aseguramiento de la calidad del producto, utilizando la técnica de pruebas por pares constituye un gran pilar
en la construcción y el mantenimiento de un sistema de gestión de calidad y un modelo de madurez continua.
220
• La planeación de proyectos, la recolección de datos e indicadores y el ajuste de técnicas de estimación
permiten maximizar los beneficios de los proyectos de software y constituyen la base para realizar análisis y
planeación de cobertura de pruebas al inicio y al final de un proyecto de pruebas.
• Los procesos de pruebas y en general todos aquellos que apunten a asegurar la calidad del producto,
permiten obtener elementos para lograr la madurez del modelo de calidad de las compañías, mediante
actividades y procesos de retroalimentación.
• En términos reales, el factor más relevante a la hora de realizar el análisis de rendimiento de una aplicativo
sometido a una prueba de carga es el índice de respuesta efectiva del aplicativo web ante peticiones de
usuarios virtuales.
• Industria de software en los últimos años, ha tomado la ruta comercial de vender productos con altos
estándares de fiabilidad y eficiencia, por lo que las pruebas de carga y rendimiento se han convertido en
obligatorias en todos los planes de prueba de los proyectos de software, y ésta necesidad es claramente
evidenciada en la cantidad y calidad de productos de éste tipo que actualmente existen en el mercado.
• La tendencia actualmente en el mercado de las herramientas de pruebas de carga es orientada a el
suministro de soluciones integrales, que permitan no solo la realización de pruebas de carga, si no también la
posibilidad de monitoreo de servicios y sistemas y la automatización de pruebas funcionales. Además la
221
portabilidad de dichas herramientas para la realización de pruebas distribuidas hace parte de las
características que se están imponiendo en éste tipo de herramientas.
• Las herramientas NEOLOAD y WEBLOAD, entre las cinco herramientas evaluadas, son las que tienen un
consumo más bajo de recursos durante las pruebas y es posible, por ende, que durante pruebas con muchos
usuarios virtuales concurrentes sean más estables que las demás.
• Existen algunas tendencias en el mercado de herramientas de carga:
o Herramientas construidas bajo un entorno de escritorio, las cuales tiene en general dos programas,
uno para generación de script de pruebas, y otra para la ejecución de los mismos y por otro lado
herramientas construidas en entorno web apoyadas por un servicio tipo java que reside en memoria.
Ejemplo de herramientas de éste tipo son PROXY SNIFFER y QENGINE.
o Herramientas construidas en entorno completamente java y herramientas construidas en código C
como aplicaciones de escritorio. Ejemplo de herramientas de éste tipo son: JMETER, WEBLOAD y
NEOLOAD.
• Se presenta un contraste entre el rendimiento, la portabilidad y el modelo de construcción de las
herramientas, ya que las que son portables y/o cuentan además con un agente que carga inicialmente una
interfaz web (QENGINE, JMETER y PROXY SNIFFER) tienen altos consumo de recursos, a diferencia de las
que son programas de escritorio (WEBLOAD y NEOLOAD) las cuales tienen consumos bajos, salvo la
222
excepción de JMETER que aunque es una aplicación de escritorio construida en java y no cuenta con un
agente adicional, tiene altos consumo de procesador y memoria.
• La posibilidad de crear balanceos de funcionalidades durante un escenario de pruebas y el manejo de
detalles como la parametrización de la emulación de la velocidad de los usuarios virtuales son un factor
diferenciador presente solo en las herramientas WEBLOAD, NEOLOAD y QENGINE lo cual las convierte en
candidatas deseables para la realización de pruebas de cargas ya que pueden emular un ambiente muy
parecido al real mediante dichas opciones.
223
TRABAJO FUTURO
La problemática principal en el tema de pruebas de software no es la falta de estándares o investigación en el tema
de las pruebas de software y el aseguramiento de la calidad del producto si no más bien la dispersión de dichos
elementos y su difícil acceso. El trabajo futuro está enfocado entonces, a proponer un proceso unificado que
profundice y particularice los detalles que los estándares y modelos de calidad no contemplan. El carácter formal del
proceso unificado debería basarse en los estándares más importantes y reconocidos en la industria de software y en
las comunidades académicas, adaptándolos para que se acoplen entre si, sin llegar a la misma problemática de no
profundizar suficiente, dificultando su implementación práctica en un ambiente de producción real. Así pues y
siguiendo el mismo orden de ideas, el siguiente paso a realizar luego de dicha especificación es el sometimiento a
un proceso de madures de la propuesta logrando una retroalimentación positiva al modelo conjunto.
El mejoramiento de los procesos de pruebas no solo es posible a través de la retroalimentación y la madurez
continua. La automatización de pruebas sugiere un modo no solo de acelerar el diseño y ejecución de casos de
prueba, sino también de obtener un mayor grado de cobertura en las pruebas. Igualmente la automatización de
procesos de verificación y validación mediante la técnica de pruebas por pares, es un elemento útil a la hora de
hacer aseguramiento de la calidad del producto e incluso del proceso; una posible implementación estaría orientada
224
a un sistema experto parametrizable para la aprobación de productos y procesos conformes mediante la
automatización de listas de chequeo.
En cuanto al aseguramiento de la calidad del producto, un aspecto que ha tomado mucha relevancia en los últimos
años es la usabilidad, un ejemplo de ello son las normas ISO 23973 (estándar para la usabilidad en aplicaciones
web) y la normal ISO 9241-11 (Guías de usabilidad), las cuales apoyadas en un proceso integral y unificado como
CICLO-P podrían orientarse no solo a obtener productos conformes y de calidad, si no también piezas de software
que cumplan con estándares de usabilidad logrando cumplir el objetivo principal del software: el usuario final.
Las pruebas unitarias de caja blanca, que minimizan las posibilidades de existencia de errores en las piezas del
software, determinan un tema amplio y complejo para realizar pruebas en etapas tempranas de desarrollo, y
dotarían a CICLO-P de un método para generar un grado de cobertura mayor en cuanto a la intensidad de pruebas
en el software.
La posibilidad de conocer un conjunto determinado de herramientas para la realización de pruebas de carga, abre
un camino claro hacia la aplicación de estas en un caso de prueba sobre una herramienta web real, con el fin de
evaluar las características ya mencionadas y su usabilidad en ambientes reales de producción. La complejidad, las
limitaciones funcionales y las características de automatización en herramientas para pruebas de carga se
225
constituyen en el objetivo primordial a la hora de utilizarlas ejecutando un caso de prueba bajo las mismas
condiciones sobre cada una de ellas o sobre una muestra significativa de las mismas.
Después de estudiar herramientas que permiten realizar pruebas de cargas y tiene opciones adicionales para
realizar pruebas funcionales, y dada la importancia de éstas últimas en la automatización de pruebas y por ende en
la reducción de tiempos de retest, el trabajo futuro está orientado a realizar estudios de herramientas para la
automatización de pruebas funcionales.
226
BIBLIOGRAFÍA
[1] Carnegie Mellon University. 2006. Capability Maturity Model® Integration (CMMI) Versión 1.1.
[2] Veenendaal V., Swinkels, R. 2002. Guidelines for Testing Maturity. Published in: Professional Tester, Volume
Three, Issue No. 1
[3] Myers, G.J., 2004. The art of software Testing. pp 6.
[4] McGregor J.D., Sykes D.A., 2001. A Practical guide To testing Object-oriented software. pp. 14.
[5] Tian J. 2005. Software Quality Engineering. IEEE Computer Society Executive Staff.
[6] Dustin E. 2003. Effective Software testing. Pearson Education.
227
[7] Zuyu J., Tsao J., Wu Y. 2003. Testing y Quality assurance for component-based software.
[8] Ilene Burnstein. Practical Software Testing.Springer. NY Estados Unidos. Pág 732.
[9] Young M., Taylor R. 1989. Rethinking the Taxonomy of fault detection techniques. Department of Information and
Computer Science. University of California, Irvine.
[10] Ping K., Yueh C., Towey C. 2005. Restricted random testing: adaptive random testing by exclusion.
[11] Chen, Kuo, Merkel. Mirror adaptive random testing. 2004
[12] E. William East a, Jeffrey G. Kirby a, Liang Y. Liu. Verification and validation of a project collaboration tool
228
[13] Dávila, Melendez, Florez. Determinación de los Requerimientos de Calidad del Producto Software Basados en
Normas Internacionales.
[14] ISO/IEC 9126-1:2001 Software engineering - Product quality
[15] ISO/IEC TR 9126-2:2003 Software engineering - Product quality - Part 2: External metrics.
[16] ISO/IEC TR 9126-3:2003 Software engineering - Product quality - Part 3: Internal metrics
[17] ISO/IEC TR 9126-4:2004 Software engineering - Product quality - Part 4: Quality in use metrics
[18] ISO/IEC 25000:2005 Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE) -
Guide to SQuaRE
[19] ISO/IEC 14598-1:1999 Information technology - Software product evaluation - Part 1: General overview
229
[20] ISO/IEC 14598-2:2000 Software engineering - Product evaluation - Part 2: Planning and management
[21] ISO/IEC 14598-3:2000 Software engineering - Product evaluation - Part 3: Process for developers
[22] ISO/IEC 14598-4:1999 Software engineering - Product evaluation - Part 4: Process for acquirers
[23] ISO/IEC 14598-5:1998 Information technology - Software product evaluation - Part 5: Process for evaluators
[24] ISO/IEC 14598-6:2001 Software engineering - Product evaluation - Part 6: Documentation of evaluation modules
[25] ISO/IEC TR 15504-1 Information technology — Software process assessment — Part 1: Concepts and
introductory guide
230
[26] ISO/IEC TR 15504-2 Information technology — Software process assessment — Part 2: A reference model for
processes and process capability
[27] ISO/IEC TR 15504-3 Information technology — Software process assessment — Part 3: Performing an
assessment
[28] ISO/IEC TR 15504-4 Information technology — Software process assessment — Part 4: Guide to performing
assessments
[29] ISO/IEC TR 15504-5 Information technology — Software process assessment — Part 5: An assessment model
and indicator guidance
[30] ISO/IEC TR 15504-6 Information technology — Software process assessment — Part 6: Guide to competency of
assessors
231
[31] ISO/IEC TR 15504-7 Information technology — Software process assessment — Part 7: Guide for use in
process improvement
[32] ISO/IEC TR 15504-8 Information technology — Software process assessment — Part 8: Guide for use in
determining supplier process capability
[33] ISO/IEC TR 15504-9 Information technology — Software process assessment — Part 9: Vocabulary
[34] Mark C. Paulk. Analyzing the Conceptual Relationship Between ISO/IEC 15504 (Software Process Assessment)
and the capability Maturity Model for Software. 1999 International Conference on Software Quality.
[35] Zeiss,Vega, Schieferdecker, Neukirchen, Grabowski. Applying the ISO 9126 Quality Model to Test
Specifications.
[36] IEEE 1012, 1998, Standard for software verification and validation.
232
[37] IEEE - 0730, 2002, Standard for software quality assurance plans.
[38] IEEE 1044.1, 1995, Guide to classification for software anomalies.
[39] IEEE 1008, 1987, Standard for software unit testing.
[40] IEEE 1061, 1998, Software Quality Metrics Methodology
[41] Burnstein I., Homyen A., Grom R., Carlson C. R. 1998. A Model To Assess Testing Process Maturity.
[42] Olsen K., Staal P. 1998. Using the Testing Maturity Model in Practical Test Planing and Post-Evaluation.
[43] Burnstein I., Swannasart T. 1996. Developing a Testing Maturity Model.
233
[44] http://www.istqb.org/
[45] Jokella, lalli. Usability and CMMI: Does A Higher Maturity Level in Product Development Mean Better Usability?.
2003.
[46] W. Boehm , C. Abts, ET AL. Software Cost Estimation with Cocomo II. Prentice Hall. 2002.
[47] IEEE 610:1990 - IEEE Standard Glossary of Software Engineering Terminology.
[48] IEEE Standard for Software Test. Documentation. IEEE Std 829-1998
[49] Web site Webload: www.webload.org
[50] Web site Jmeter: jakarta.apache.org/jmeter/
234
[51] Web site Proxy sniffer: www.proxy-sniffer.com
[52] Web site QEngine: www.adventnet.com/products/qengine
[53] Web site Neoload: www.neotys.com
[54] Proyecto OpenSource Bug Tracker Mantis: http://www.mantisbt.org
[55] Proyecto OpenSource Mysql: http://dev.mysql.com/downloads/
[56] Proyecto OpenSource Bug Tracker Mantis: http://www.apache.org/
[57] Proyecto OpenSource Bug Tracker Mantis: http://www.php.net
235
[58] D. Menascé. “Load Testing of Web Sites”. IEEE. IEEE Internet Computing. Vol. 6 Nº 4, pp. 70-74. Julio-
Agosto, 2002.
[59] Emily H. Halili. Apache JMeter. Primera publicación.Junio 2008. Packt Publishing Ltda. Firmingham, Reino
Unido. Pag, 138
[60] R Blank et al. Flex application Development. Primera edicion. 2008. United States. Springer-Verlag New York.
Friendsoft Apress company. 486 pág.
[61] Paul j Deitel, Harvey M. Deitel. Ajax, Rich Internet Applications, and Web Development for programmers.
Pearson Education, Inc. 2008. United States, Indiana. 1025 pág.
[62] Paul j Deitel, Harvey M. Deitel. Ajax, Rich Internet Applications, and Web Development for programmers.
Pearson Education, Inc. 2008. United States, Indiana. 1025 pág.
236
[63] Andreas Spillner, Tilo Linkz, Hans Schaefer. Software testing foundations. Rockynook. Segunda edición.
2007. SB, Estados Unidos. 272 pag.
[64] Jeff Tian. Software Quality Engineering. IEEE Computer Society. John Wiley & Sons. 2005. NJ. Estados
Unidos. Pág 441
[65] U. Linnenkugel, M. Mullerburg, “Test data selection criteria for (software) integration testing,” Proc. First
International Conf. Systems Integration, April 1990, pp. 709–717.
[66] Hung Q. Nguyen. Testing Applications on the Web. Wiley Computer Puclishing. John Wiley & Sons, inc. 2001.
NY, Estados Unidos. Pág. 420.
[67] P. Denning, J. Buzen. “The Operational Analysis of Queuing Network Models”. ACM Computing Surveys,
Vol. 10, no. 3, pp. 225-261. Septiembre, 1978.
[68] D. Menascé, V. Almeida. “Capacity Planning for Web Services: Metrics, Models, and Methods”. Prentice Hall,
New York, Estados Unidos. Vol. 2459, pp 572. 2002.
237
[69] W. Ehrlich, S. Keith et al. “Applying Reliability Measurement: A Case Study”. IEEE Software. Vol. 7 Nº 2, pp.
56-64. Marzo, 1990.
[70] D. Draheim, J. Grundy, et al. “Realistic Load Testing of Web applications”. Software Maintenance and
Reengineering – CSMR - Proceedings of the 10th European Conference on". Bari, Italy. 2006.
[71] H. Chan, “A Formulation to Optimize stress Testing”. Electronic Components and Technology Conference -
Proceedings. 44th. Washington, Estados Unidos. 1994.
[72] M. Elbert, C. Mpagazehe et al. “Stress testing and reliability”. Southcon/94. Conference Record. Orlando,
Estados Unidos. 1994.
[73] L. Gullo, R. Davis, et al. “Accelerated Stress Testing to Detect Probabilistic Software Failures”. Reliability and
Maintainability, Annual Symposium – RAMS. 2004.
238
[74] H. Chan. “Accelerated Stress Testing for Both Hardware and Software”. Reliability and Maintainability, Annual
Symposium – RAMS. 2004.
[75] M. Hecht. “Use of importance sampling and related techniques to measure very high reliability software”. IEEE
Aerospace Conference Proceedings. Montana, Estados Unidos. 2000.
[76] M. Mazlan. “Stress Test on J2ME Compatible Mobile Device”. IEEE - Innovations in Information Technology.
pp. 1-5. Noviembre, 2006.
[77] V. Beltran, J. Guitart et al. "Performance Impact of Using SSL on Dynamic". Proceedings of XV Jornadas de
Paralelismo, JP'04. Almeria, España, 2004.
[78] T. Benito, L. Sanz et al."Un estudio sobre rendimiento web". Conferencia IADIS Iberoamericana
WWW/Internet. Madrid, España. 2004.
239
[79] M. Saerens, F. Fouss. "HITS is principal components analysis". Proceedings of the 2005 IEEE/WIC/ACM
International Conference on Web Intelligence". Compiegne, Francia. 2005.
[80] H. Nguyen, B. Johnson et al. “Testing Applications on the web”. Wiley Computer Publishing John Wiley &
Sons, inc. Segunda edición. New York, Estados Unidos. pp 400. 2000
