PROPUESTA METODOLÓGICA PARA LA REALIZACIÓN DE PRUEBAS DE DE SOFTWARE EN UN AMBIENTES PRODUCTIVOS CRHISTIAN DE JESÚS CARDONA VELÁSQUEZ

Transcripción

1 1

2 PROPUESTA METODOLÓGICA PARA LA REALIZACIÓN DE PRUEBAS 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

3 PROPUESTA METODOLÓGICA PARA LA REALIZACIÓN DE PRUEBAS 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

4 NOTAS DE ACEPTACIÓN PRESIDENTE DEL JURADO JURADO JURADO Medellín, 04 de Junio de

5 CONTENIDO Pág. RESUMEN... 9 ABSTRACT PALABRAS CLAVE KEY WORDS INTRODUCCIÓN UNA REVISIÓN CRÍTICA AL PROCESO DE ELABORACIÓN DE PRUEBAS EN APLICACIONES DE SOFTWARE PRUEBAS DE SOFTWARE TAXONOMÍA DE LAS PRUEBAS EN APLICACIONES DE SOFTWARE ANÁLISIS DE TRABAJOS EXISTENTES CMMI ISO IEEE TMM ISTQB LIMITACIONES DE LAS PRUEBAS DE SOFTWARE CICLO-P: UN MÉTODO PARA EL ACOPLAMIENTO DE PRUEBAS AL CICLO DE VIDA DEL SOFTWARE BASES TEÓRICAS SOBRE PRUEBAS DE SOFTWARE TRABAJOS RELACIONADOS Y DEBILIDADES ASOCIADAS PROPUESTA METODOLÓGICA Precondiciones CICLO-P: Proceso de pruebas acoplado al proceso de producción Roles

6 2.3.4 Tipos de pruebas Flujo de proceso de CICLO-P acoplado al proceso de desarrollo de software Métricas asociadas al seguimiento y control y a la estimación Proceso de retroalimentación ESTUDIO COMPARATIVO DE HERRAMIENTAS ESPECIALIZADAS EN PRUEBAS DE CARGA DE APLICACIONES WEB ANÁLISIS TEÓRICO SOBRE HERRAMIENTAS DE CARGA EN APLICACIONES WEB Diferencia entre pruebas de carga, pruebas de rendimiento y pruebas de estrés Relación entre las pruebas de carga y el rendimiento del sistema Características a medir en el estudio comparativo ANÁLISIS DE RESULTADOS COMPARACIÓN DE HERRAMIENTAS PARA PRUEBAS DE CARGA: UN CASO DE ESTUDIO MARCO TEÓRICO BASE PARA LA COMPARACIÓN Herramientas a utilizar y características generales CASO DE ESTUDIO Escenarios de prueba INFRAESTRUCTURA A UTILIZAR Medidas a tener en cuenta ANÁLISIS DE RESULTADOS CONCLUSIONES TRABAJO FUTURO BIBLIOGRAFÍA

7 ILUSTRACIONES Ilustración 1 - ISO/FDIS 9126 e ISO/IEC Ilustración 2 - Proceso de evaluación ISO/IEC Ilustración 3 - Estructura del modelo ISO/IEC Ilustración 4 - Etapas de CICLO-P Ilustración 5 - Proceso de las pruebas de carga. Tomado de [1] Ilustración 6 - Gráfica de carga versus rendimiento. Tomado de [1] Ilustración 7 - Comportamiento carga versus tiempo mediante función constante incremental Ilustración 8 - Comportamiento carga versus tiempo mediante función trapezoidal Ilustración 9 - Infraestructura de red Ilustración 10 - Consumo de Memoria y procesador herramienta WEBLOAD Ilustración 11 - Consumo de Memoria y procesador herramienta JMETER Ilustración 12 - Consumo de Memoria y procesador herramienta Ilustración 13 - Consumo de Memoria y procesador herramienta QENGINE Ilustración 14 - Consumo de Memoria y procesador herramienta NEOLOAD Ilustración 15 - Comparativa de Consumo de Memoria y procesador de las cinco herramientas probadas

8 TABLAS Tabla 1 - Clasificación de pruebas de software vs ciclo de desarrollo Tabla 2 - Herramienta de nivel bajo Tabla 3 - Herramienta de nivel medio Tabla 4 - Herramienta de nivel avanzado

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 9

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. 10

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 11

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. 12

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. 13

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. 14

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 15

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 16

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. 17

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]. 18

19 1.2 TAXONOMÍA DE LAS PRUEBAS EN APLICACIONES DE SOFTWARE. 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. 19

20 Estáticas Dinámicas Requisitos Diseño Programación Listas de chequeo Informales Modelamiento Formal Análisis estático de diseño de documentos Información general Análisis estático de errores Ejecución simbólica Pruebas funcionales Pruebas por clases de datos de entrada Pruebas por clases de datos de salida Pruebas basadas en diseño 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 20

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. 21

22 1.3 ANÁLISIS DE TRABAJOS EXISTENTES 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 22

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. 23

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 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 [19][20][21][22][23][24] Software Product Evaluation o Evaluación del producto software ISO/IEC [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. 24

25 Ilustración 1 - ISO/FDIS 9126 e ISO/IEC Ilustración 2 - Proceso de evaluación ISO/IEC

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 (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 26

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 (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 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). 27

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 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 28

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 29

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] 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. 30

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]. 31

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 32

33 particulares sean aportadas por la entidad o instituto que aplique a la implementación de alguno de estos estándares [44] 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 33

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 34

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. 35

36 Los estándares diseñador por la ISO específicamente el ISO/FDIS 9126, ISO e ISO/IEC 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 36

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. 37

38 2 CICLO-P: UN MÉTODO PARA EL ACOPLAMIENTO DE PRUEBAS 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 38

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. 39

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 40

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. 41

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 que permiten abordar de manera metodológica la 42

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. 43

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 44

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 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. 45

46 2.3.2 CICLO-P: Proceso de pruebas acoplado al proceso 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. 46

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 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. 47

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 Flujo de proceso de CICLO-P acoplado al proceso 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, 48

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 49

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. 50

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 51

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 52

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. 53

54 Ilustración 4 - Etapas de CICLO-P 54

55 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].

56 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 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. 149

57 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. 150

58 3 ESTUDIO COMPARATIVO DE HERRAMIENTAS ESPECIALIZADAS 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 151

59 (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. 152

60 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] 153

61 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 154

62 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 rendimiento 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]: N VU : Número de usuarios virtuales. N C 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. X O : Tiempo promedio de peticiones por segundo Se usa entonces la ley del tiempo de respuesta [14] [48] R = N X VU O Z 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) 155

63 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). 156

64 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]. 157

65 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 comparativo 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: 158

66 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. 159

67 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 160

68 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 161

69 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 162

70 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. 163

71 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%. 164

72 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. 165

73 . 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. 166

74 Tabla 2 - Herramienta de nivel bajo. Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent 1. Dirección url del fabricante um.com er.net m.hu r.com qa.com uctions.com S$ Licencia con Prueba de 90 (50 UV), precios días. Licencia US$2,995.0 pactados por Producto acoplada al Licenciado. 2. Tipo licencia y precio 0 (100 UV) y más de 200 UV necesita contacto con distribuidor. Permite evaluar demo licenciado. Precio directament e dado por valor de la licencia Visual Studio Team System Desde $ US$ Licencia completa Precios mediante contacto directo con contacto previa contacto. Aproximadame distribuidor con el suscripción al nte desde fabricante. sitio. US$ Acceso al No No No No No No No 167

75 Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent código fuente Cualquier 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 plataforma que soporte Java 2 Standard Edition 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 168

76 Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent 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 Uso de variables Soporte IP Spoofing No No Si No Si Si No No No No No No No No 169

77 Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent Visualizació No 11. n en tiempo real Si Si especificad o Si Si Si Si Pruebas No 12. programada s No No especificad o No Si Si Si No 13. Proxy http Si Si especificad o Si Si No No 14. Proxy https No Si especificad o No Si No 15. Scripting Si Si Si Si Si Si 170

78 Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent 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 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 https Http https Http https 20. Monitoreo de Bases de Si (5 tipos) No No especificad No No No No 171

79 Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent datos o Monitoreo No 21. Sistema Operativo Si (2 tipos) 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 172

80 Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent Pruebas No 25. Web - Services No No especificad o No No No No Pruebas No 26. Bases de datos 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 173

81 Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent 30. Temporizad ores No Si No especificad o No Si (2) Si Si Pruebas en No 31. segmentos múltiples Si No especificad o No No Si No 32. Pruebas funcionales No No No No No No Si Posibilidade No 33. s de extensiones No No especificad o No No No No 34. Emulación de velocidad Si No No especificad o No Si No No 174

82 Visual Studio # Nombre vperforme r StressTester LoadMana ger Team System 2008 Test Webserver Stress Tool TestComplete 6 Jblitz Load Agent 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 175

83 Tabla 3 - Herramienta de nivel medio. PROXY Web Web # Nombre OPENSTA SNIFFE Qtest 5.0 performance performance WEBLOAD R load tester load tester 1. Dirección url del fabricante xy- a.org sniffer.co m.com manceinc.com anceinc.com m Entre 606 USD y USD Licenciado. Precios OpenSource. 2. Tipo licencia y precio Freeware - (Existen Opensource múltiples opciones de mediante contacto directo con distribuidor Licencia ilimitada $20,000 Licencia ilimitada $20,000 Licenciado. Precios mediante contacto directo con distribuidor. licencia miento) 176

84 PROXY Web Web # Nombre OPENSTA SNIFFE Qtest 5.0 performance performance WEBLOAD R load tester load tester 3. Acceso al código fuente Si No No No No Si Windows 2000/XP /2003/Vi Windows sta, Windows Windows 98/Me/ Windows 98/Me/ 4. Plataforma 9x/NT/2000/ XP Solaris, Linux, NT/2000/200 3/XP /2000/XP/2003 Linux - Solaris /2000/XP/2003 Linux - Solaris Windows, linux, Solaris BSD y Mac OS X 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 No especificados No especificados s 177

85 PROXY Web Web # Nombre OPENSTA SNIFFE Qtest 5.0 performance performance WEBLOAD R load tester load tester Idiomas soportados Manejo de perfiles de usuarios virtuales HD MB Inglés Inglés Inglés Inglés Inglés Inglés Si Si Si Si Si 9. Uso de variables Si Si Si No No Si 10. Soporte IP Spoofing Si Si No No No Visualización en 11. tiempo real 12. Pruebas Si Si Si Si Si Si Si Si Si Si Si 178

86 PROXY Web Web # Nombre OPENSTA SNIFFE Qtest 5.0 performance performance WEBLOAD R load tester load tester programadas Proxy http Si Si Si Si Si Si Proxy https Si Si Si Si Si Si Scripting Si Limitado Si Si Si Si 16. Controladores Lógicos No Si Si No No No Número de 17. informes nativos Diseño de 18. informes personalizados Si (algunos) No Si Si Si Si 19. Protocolos Http Http 1.0- Http https 1.1-https https Http-https Http-https Http https 179

87 PROXY Web Web # Nombre OPENSTA SNIFFE Qtest 5.0 performance performance WEBLOAD R load tester load tester Monitoreo de 20. 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 Monitoreo web 22. 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 Pruebas Web Services Pruebas Bases 26. de datos No No No Si Si No No No No No No No 180

88 PROXY Web Web # Nombre OPENSTA SNIFFE Qtest 5.0 performance performance WEBLOAD R load tester load tester Pruebas Mail- Server Manejador de Cookies No No No No No No Si Si Si Si Si Si Administración 29. remota No Si No No No No 30. Temporizadores Si Si Si Si Si Si (5) Pruebas en segmentos múltiples Pruebas funcionales Si Si No No No No No No No No No No Posibilidades de 33. extensiones Si No Si No No Si 181

89 PROXY Web Web # Nombre OPENSTA SNIFFE Qtest 5.0 performance performance WEBLOAD R load tester load tester 34. Emulación de velocidad de conexión de usuarios No Si No Si Si Si Escalabilidad de 35. usuarios No No No especific Especificada especificada ado No especificado No especificado No especificado 182

90 Tabla 4 - Herramienta de nivel avanzado. # Nombre MINQ - PureLoad Jmeter QEngine TestMaker NeoLoad APPPERFECT TEST SUITE STUDIO jakarta. 1. Dirección url del fabricante apache.org/jm tnet.com m eter Edición Web, $8,990 para De US$795 De 742 a Usuarios a $12,995 32, Tipo licencia y precio virtuales ilimitados Edición empresarial inicial para 50 Freewa re - Openso urce dependiend o del tipo de licencia y el número máximo de Freeware - Opensource dependiendo de la licencia más los módulos adicionales que Toda la suite con las funcionalidades totales desde US$2980. Por componente el precio varía usuarios usuarios están entre virtuales US virtuales 2,142 y 3,245 $9,

91 # Nombre MINQ - PureLoad Jmeter QEngine TestMaker NeoLoad APPPERFECT TEST SUITE STUDIO 3. Acceso al código fuente No Si No Si No No Cualqui Windows er NT/200/XP platafor 4. Plataforma (Server ma que Editions), Linux soporte Redhat, Java 2 Solaris/SPARC 8 Standar y plataformas d con Java 2 Edition 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 Standard Edition o posteri or 5. Multiplataforma Si Si Si Si Si Si 6. Requisitos de RAM 512 MB 20 No especifi No especificad No 185 MB HD No especificado 184

92 # Nombre MINQ - PureLoad Jmeter QEngine TestMaker NeoLoad APPPERFECT TEST SUITE STUDIO hardware MB HD cados os especificados RAM 150 MB Españo l, Inglés, Japoné s, 7. Idiomas soportados Inglés Norueg o Inglés Inglés Inglés Francés. Inglés Alemán, Francé s, Chino 8. Manejo de perfiles de usuarios Si Si Si Si Si Si 185

93 # Nombre MINQ - PureLoad Jmeter QEngine TestMaker NeoLoad APPPERFECT TEST SUITE STUDIO virtuales Uso de variables Soporte IP Spoofing Si Si Si Si Si Si Si Si No Si Si Visualización 11. en tiempo real Si Si Si Si Si Si 12. Pruebas programadas Si Si Si Si Si Si Proxy http Si Si Si Si Si Si Proxy https Si No Si Si Si Si Scripting Si Si Si Si Si Si Controladores 16. Lógicos Si Si No Si Si Si 186

94 # Nombre MINQ - PureLoad Jmeter QEngine TestMaker NeoLoad APPPERFECT TEST SUITE STUDIO 17. Número de informes nativos monitores +15 Diseño de 18. informes personalizados No Si No No No Si 19. Protocolos https Http Http https Http https Http https Http https Http https Monitoreo de 20. 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) 187

95 # 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 Pruebas Web Services Pruebas Bases 26. de datos Si Si Si No No Si Si Si No No No No Pruebas Mail- Server Manejador de Cookies Si Si No No No No Si Si Si Si Si Si Administración 29. remota 30. Temporizadore No SI Si No No Si Si Si Si (5) Si Si (3) Si 188

96 # Nombre MINQ - PureLoad Jmeter QEngine TestMaker NeoLoad APPPERFECT TEST SUITE STUDIO s Pruebas en segmentos múltiples Pruebas funcionales Si Si Si Si No Si No No Si Si No Si Posibilidades 33. 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 189

97 190

98 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. 191

99 [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. 192

100 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. 193

101 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. 194

102 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 generales 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 195

103 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 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

104 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 [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. 197

105 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 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 198

106 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 /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: 199

107 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 2. Autenticarse con el nombre de usuario: prueba y contraseña: prueba. 3. Dar clic en el menú superior Ver Requerimientos. 200

108 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. 201

109 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. 202

110 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. 203

111 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 204

112 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 x y cuya máscara de subred es de 24 bit ( ). Servidor El servidor en el cual se instaló la aplicación cuenta con las siguientes especificaciones: 205

113 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: Mascara de subred: 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 206

114 La configuración de red es: IP: Mascara de subred: Ilustración 9 - Infraestructura de red. 207

115 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. 208

116 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. 209

117 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). 210

118 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 211

119 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 212

120 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. 213

121 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 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). 214

122 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). 215