UNIVERSIDAD SIMÓN BOLÍVAR

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN DISEÑO Y EJECUCIÓN DE PRÁCTICAS DE EVALUACIÓN DEL RENDIMIENTO DE APLICACIONES WEB Y SU OPTIMIZACIÓN. Por: Br. Isaac Jacobo Rondón Sosa INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, Junio de 2014

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN DISEÑO Y EJECUCIÓN DE PRÁCTICAS DE EVALUACIÓN DEL RENDIMIENTO DE APLICACIONES WEB Y SU OPTIMIZACIÓN. Por: Br. Isaac Jacobo Rondón Sosa Realizado con la asesoría de: Tutor Académico: Marlene Goncalves Tutor Industrial: Pedro García INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, Junio de 2014

3

4 DISEÑO Y EJECUCIÓN DE PRÁCTICAS DE EVALUACIÓN DEL RENDIMIENTO DE APLICACIONES WEB Y SU OPTIMIZACIÓN. Elaborado por: Br. Isaac Jacobo Rondón Sosa RESUMEN Actualmente la empresa DBAccess aporta una gran cantidad de esfuerzo en mantener sus proyectos a un alto nivel de calidad, lo cual se puede observar en la gran cantidad de certificaciones y logros obtenidos en esta área. Por este motivo, es de gran importancia consolidar y fomentar prácticas las cuales faciliten los procesos de gestión de la calidad. El desempeño es un criterio fundamental para el aseguramiento de la calidad de un producto de software, el cual determina los límites del mismo para que sea aceptado por sus usuarios. El proyecto de pasantía larga consistió en diseñar e implementar pruebas de desempeño en la capa de servicios del proyecto Order Tracking del cliente Avon, con la intención de aplicar mejoras en el desempeño de la aplicación. El desarrollo de este proyecto tiene, además, el objetivo de identificar prácticas para la elaboración de este tipo de pruebas, así como para el desarrollo de software orientado al desempeño. Para el desarrollo de este proyecto se usó una adaptación de la metodología DBAccess, enfocada a la complejidad y tipo del proyecto que se desarrolló. Para esto se tuvieron las fases de requerimiento, pruebas y validación, diseño y desarrollo e implantación, y se produjeron una serie de artefactos para sustentar el desarrollo. Dicha adaptación permitió obtener mejoras en el desempeño de la aplicación Order Tracking en aquellos servicios que resultaron más críticos luego de la evaluación y la identificación de prácticas para la elaboración de pruebas de desempeño y para el desarrollo de software enfocado al desempeño del mismo. Palabra clave: Pruebas de Desempeño, Optimización, Hibernate, Java, Aseguramiento de la Calidad, JMeter, JProfiler. iv

5 DEDICATORIA A mis padres, Por su incondicional apoyo, orientación y darme la fortaleza para seguir adelante. v

6 AGRADECIMIENTOS Primero quiero agradecer a Dios, por todas las oportunidades que me ha brindado y por estar conmigo en cada paso que doy. A mis padres Marisela Sosa y Willian Rondón, que siempre me han guiado en toda decisión que he tomado en mi vida y me han brindado todo su amor y dedicación, razón por la cual soy la persona que soy. A mi hermano Abraham Rondón, por ser no solo un hermano sino un amigo quien me ha apoyado incondicionalmente y se ha convertido en un ejemplo para mí. A mis familiares, quienes me han apoyado y animado para seguir adelante cada día. No lo hubiese logrado sin su cariño y soporte. A mis amigos, con los que he vivido muchas experiencias y he aprendido valiosas lecciones, por sus consejos y su apoyo. Aprovecho destacar a mis futuros colegas Carlos Castillo, Karen Da Silva y María José Ramos, siempre nos apoyamos en nuestra formación profesional, compartimos buenos y malos momentos y siempre estuvieron a mi lado cuando los necesité. José Rodriguez, quien me acompañó durante toda la pasantía, me apoyó durante toda la elaboración de este proyecto e hizo esta experiencia mucho más agradable. A Luis Mendoza, Yadixa Martínez, Juan Bustamante y Pedro García por el apoyo y la tutoría brindada durante el desarrollo del proyecto y Marlene Goncalves por la asesoría durante la elaboración de este tomo. A la organización DBAccess, por brindarme la oportunidad de desarrollar este proyecto. A muchas personas que quisiera nombrar específicamente, pero nombrarlas y explicar el por qué les estoy agradecido me tomaría mucho más las páginas contenidas en este tomo. Pero, no cabe duda que han sido una parte importante en mi vida. vi

7 ÍNDICE GENERAL RESUMEN... iv DEDICATORIA... v AGRADECIMIENTOS... vi ÍNDICE GENERAL... vii ÍNDICE DE FIGURAS... xi ÍNDICE DE TABLAS... 1 LISTA DE SÍMBOLOS Y ABREVIATURAS... 2 INTRODUCCIÓN... 3 CAPÍTULO 1 ENTORNO EMPRESARIAL Reseña histórica Objetivo Estructura organizacional Organización funcional Ubicación del pasante CAPÍTULO 2 MARCO TEÓRICO Y TECNOLÓGICO Conceptos teóricos Pruebas de Desempeño Tipos de Pruebas de Desempeño Pruebas de benchmark Pruebas de estrés Pruebas de perfil de desempeño Pruebas de carga Tecnologías utilizadas REST Java Apache JMeter vii

8 Hibernate JProfiler CAPÍTULO 3 MARCO METODOLÓGICO Metodología DBAccess Adaptación de la metodología de DBAccess al desarrollo del proyecto Proceso de Análisis de Requerimientos Proceso de Pruebas y Validación Proceso de Diseño y Desarrollo Técnico Proceso de Implantación CAPÍTULO 4 DESARROLLO DEL PROYECTO Proceso de Análisis de Requerimientos Levantamiento de información Análisis Proceso de Pruebas y Validación Planificación de Pruebas Revisión y entendimiento de la arquitectura y funcionalidad de la aplicación Evaluación de Usabilidad de la herramienta de medición de Desempeño Expectativas de Desempeño Métricas de Evaluación de Desempeño Enfoque y Estrategia de Evaluación de Pruebas CAPÍTULO 5 CONFIGURACIÓN Y EJECUCIÓN DE PRUEBAS Configuración de las Pruebas Crear y validar Escenarios de Prueba Crear guiones de pruebas y poblar la base de datos Ejecución de los casos de prueba de desempeño y proceso de supervisión viii

9 Validar los resultados Objetivos de las Pruebas Análisis y revisión de las pruebas Revisión de los datos generados CAPÍTULO 6 DESARROLLO Y PRUEBAS DE SOLUCIÓN PROPUESTA Identificación de problemas relacionados al sistema o en la infraestructura Proceso de Diseño y Desarrollo Técnico Diseño de Alto Nivel Situación Actual Propuesta de Solución Diseño Detallado Decisiones de Diseño Servicios RESTful Persistencia Interfaz Gráfica Construcción de la Solución Implementación de los servicios Desarrollo de Pruebas Unitarias Aspectos de configuración Proceso de Implantación Implantación de la aplicación Ejecución de Pruebas CONCLUSIONES Y RECOMENDACIONES BIBLIOGRAFÍA Apéndice A-Documento de Análisis Apéndice B-Plan de Pruebas ix

10 Apéndice C-Artefacto de Casos de Prueba Apéndice D-Documento Estrategia de Pruebas... Error! Bookmark not defined. Apéndice E-Informe de Pruebas Apéndice F-Comparación de Herramientas Apéndice G Tutorial JMeter Apéndice H-Diseños Detallados Apéndice I-Informe Final de Pruebas Apéndice J Prácticas Identificadas... Error! Bookmark not defined. Apéndice k Retos Enfrentados x

11 ÍNDICE DE FIGURAS Figura 1.1. Espacio de emprendimiento [1]... 7 Figura 1.2. Estructuras de Coordinación [1]... 7 Figura 1.3. Relación entre el CDS y los roles de sus miembros [1]... 8 Figura 1.4. Equipo de Proyecto PRT [1] Figura 3.2. Procesos de Ejecución de DBAccess. Elaboración propia Figura 4.1. Proceso de Pruebas y Validación Figura 4.2. Modelo General de Componentes Figura 4.1. Tiempo de Respuesta de los servicios de Monitor Figura 4.5. Tiempo de Respuesta de los servicios de Control de Envío Figura 4.3. Tiempo de Respuesta de los servicios de Reportes Figura 4.4. Porcentaje de errores de Control de Envío Figura Tasa de respuestas recibidas en los servicios de Monitor Figura Tasa de respuestas recibidas en los servicios de Control de Envío Figura Tasa de respuestas recibidas en los servicios de Reportes Figura Proceso de Diseño y Desarrollo Técnico Figura Tiempos de respuestas de implementación anterior y optimizada Figura 4.19.Porcentaje de errores implementación anterior y optimizada. Elaboración propia. 55 Figura Tasa de respuestas recibidas en los servicios de Control de Envío xi

12 ÍNDICE DE TABLAS Tabla 4.1. Atributos de Calidad de la aplicación OT... 26

13 2 LISTA DE SÍMBOLOS Y ABREVIATURAS AJAX Asynchronous JavaScript And XML CDC Centro de Desarrollo de Software CMM Capability Maturiry Model CVS Sistema de control de versiones HTML HyperText Markup Language JSON JavaScript Object Notation RUP Racional Unified Process TI Tecnología de la Información CPU Central Processing Unit DB Data Base SQL Structural Query language UML Unified Modeling Language URL Uniform Resource Locator XML Extensible Markup Languaje OT Order Tracking API Application Programming Interface

14 3 INTRODUCCIÓN Toda empresa dedicada a prestar servicios de desarrollo de software, como es el caso de DBAccess, tiene la necesidad de asegurar ciertos niveles de calidad en el desarrollo de una aplicación para poder generar confianza en el cliente al cual se le presta dicho servicio, y mantener un nivel de satisfacción que permita futuras negociaciones con este u otro cliente. A partir de esta necesidad, las empresas poseen áreas de pruebas dedicadas a la ejecución de éstas, lo cual permite tener ese nivel de seguridad y calidad en el software que se entrega. La elaboración de las especificaciones funcionales y técnicas de un software está contemplada dentro de las primeras etapas del ciclo de vida del mismo. Desde la fase más temprana de esta etapa, es preciso determinar los criterios de calidad del Software y metas de arquitectura esperadas. Entre los criterios de calidad del software se encuentra la eficiencia, la cual a su vez posee una serie de características que relacionan el nivel de desempeño del software y la cantidad de recursos requeridos bajo condiciones establecidas. Este criterio tiene como meta determinar los límites para que el software sea aceptado por parte de sus usuarios o clientes. Durante el desarrollo y, en particular, a lo largo de la etapa de construcción, los desarrolladores de software deben asegurar que el producto cumpla con estas características acordadas previamente. De aquí la importancia de incorporar prácticas y herramientas que faciliten la evaluación del software, incluyendo la simulación de condiciones críticas o extremas, así como identificar prácticas de optimización del código que incidan en un desempeño óptimo. Dicha evaluación debe estar incluida en la fase de pruebas en el ciclo de vida de un software, fase de vital importancia, la cual garantiza una óptima calidad del código entregado. En este sentido, cuando se habla de la calidad del software, las pruebas son un elemento primordial y crítico. La importancia de este elemento radica en los costos asociados a los errores así como en el descontento de los usuarios finales del software. Dicha importancia estimula la

15 4 definición e implementación de un proceso de pruebas minuciosas y bien planificadas. A diferencia de muchos tipos de prueba, las pruebas de desempeño comúnmente no se les dan el nivel de importancia que requieren, por lo que la realización de estas pruebas no es considerada una práctica común en comparación con otros tipos de pruebas, como lo son las pruebas funcionales. El objetivo de este proyecto de pasantía es la implementación de Pruebas de Desempeño a la capa de servicios de un aplicativo Web y, en base a la evaluación y resultados obtenidos, lograr una optimización del código de la aplicación evaluada con el fin de obtener una mejora en su rendimiento. En el cumplimiento de este objetivo, se identifican buenas prácticas tanto para la evaluación del desempeño de aplicativos Web, haciendo uso de herramientas de apoyo, como en la optimización del mismo para lograr un mejor desempeño en la aplicación. En este sentido, los objetivos específicos del proyecto de pasantía describen lo siguiente: Definir el marco teórico en el desarrollo de pruebas de desempeño de aplicativos Web. Evaluar la viabilidad y experimentación con las herramientas de software a utilizar en la implementación de pruebas de desempeño. Diseñar y ejecutar las pruebas de desempeño a la aplicación seleccionada. Realizar los correctivos al aplicativo con el fin de garantizar un mejor desempeño en base a los resultados obtenidos luego del proceso de pruebas. A continuación se presenta la estructura de este informe. El informe está compuesto por 6 capítulos, además de la Introducción, los mismos están organizados de la siguiente forma: el Capítulo 1 presenta una descripción del entorno empresarial en el cual se desarrolló la pasantía; el Capítulo 2 define los conceptos teóricos que fundamentan la base tecnológica de este proyecto; el Capítulo 3 describe la metodología a utilizar, la cual es propia de la empresa, en la cual se realizaron adaptaciones necesarias para cumplir la meta del proyecto; el Capítulo 4 describe el desarrollo del proyecto, el Capítulo 5 describe el proceso de configuración y ejecución de las pruebas desarrolladas y el Capítulo 6 describe el desarrollo de la solución propuesta junto con los resultados de la evaluación de desempeño luego de la implementación de dicha solución. Finalmente, se enumeran las Conclusiones y Recomendaciones.

16 CAPÍTULO 1 ENTORNO EMPRESARIAL DBAccess es una empresa latinoamericana de proyección global. Desde hace más de 25 años se dedica a brindar soluciones especializadas en tecnologías de información de clase mundial, bajo altísimos estándares de calidad certificada a nivel internacional [1]. La organización cuenta con numerosos Centros de Desarrollo de Software (CDS), los cuales producen tecnologías adaptadas a las necesidades específicas de sus clientes. Su portafolio especializado de servicios incluye: Planificación y Estrategia de TI, Gestión del Portafolio de Proyectos y Aplicaciones, Gestión y Administración de la Plataforma de TI, Arquitectura Empresarial de TI, Infraestructura Tecnológica, Aseguramiento de la Calidad, Auditoria y Gestión de Procesos, Gestión de Pruebas y Mantenibilidad, Usabilidad, Experiencia del Usuario e Interfaz Gráfica [1] Reseña histórica DBAccess es una empresa venezolana fundada en el año 1988, dedicada en sus inicios principalmente al Desarrollo de Software. Su sede comercial y administrativa está ubicada en Caracas, Venezuela. A sus casi 10 años de existencia da inicio a un proceso de expansión hacia el mercado latinoamericano. Con los años consolida el Centro Global de Desarrollo de Software (GDC) localizado en la ciudad de Mérida, y abre oficinas en EEUU, Perú, Panamá y más recientemente en Brasil. Cuenta con un gran equipo de profesionales calificados, y ofrece sus servicios al mundo, habiendo ejecutado exitosamente proyectos en Venezuela, Colombia, Perú, Trinidad, Brasil, Estados Unidos de América, Francia, Finlandia, Holanda y Australia. Como toda organización, ha evolucionado en el tiempo y hoy por hoy se ha consolidado como una organización en red, proceso de transformación que se inició en el 2004 y que

17 6 abarcó los procesos, la gente, la estructura organizacional desde sus raíces, siendo hoy una organización reconocida por su innovación, liderazgo y calidad. Es una organización Great Place to Work por 4 años consecutivos desde el 2007, con certificaciones de calidad internacional en producción de software y, entre otros reconocimientos más recientes, acreedoras del Premio a la Excelencia , como organización venezolana [1] Objetivo DBAccess sirve a clientes en el mercado nacional y Near Shore desde su Centro Global de Desarrollo, con énfasis en los atributos de soporte metodológico en ingeniería de software, dominio de tecnologías de punta, calidad certificada, procesos de producción costo-efectivos y capacidad de comunicación eficiente, apoyándose en procesos claves de mercadeo, servicios, operaciones, gestión de la calidad y gestión de capital humano, para ofrecer servicios de desarrollo de aplicaciones y soluciones tecnológicas innovadoras, a la medida de las necesidades de los clientes, con la mejor relación precio-valor del mercado. Con un enfoque neutral hacia las principales tecnologías, busca orientar al cliente en la mejor elección para su plataforma, para lo cual mantiene una estrecha relación con los más importantes proveedores de tecnología a nivel global. Se esfuerza en ofrecer la mejor solución, alineada con los objetivos estratégicos del negocio y de acuerdo a la estrategia de TI de la organización cliente [1] Estructura organizacional La organización DBAccess está conformada por un conjunto de Unidades de Negocios organizadas en Red, siguiendo una perspectiva orgánica (Sosa, 2000), y que hoy se denomina Espacio de Emprendimiento. Estas Unidades se pueden apreciar en la Figura 1.1.

18 7 Figura 1.1. Espacio de emprendimiento [1]. En esta estructura organizacional, las distintas unidades que conforman la empresa son a su vez clientes y proveedores de servicios entre sí. De esta manera, cada unidad presta sus servicios a las otras unidades. En este modelo existen dos tipos de unidades de negocios, las de servicios y las de producción. Las Unidades de Producción denominadas también Centros de Desarrollo de Soluciones (CDS), están orientadas 100% a la producción, mantienen una relación directa con el cliente y con las mismas Unidades de Servicios. Los CDS se encuentran soportados por la Plataforma de Servicios, o el conjunto de Unidades de Negocios orientadas al servicio y apoyo a los distintos nodos de la red para garantizar la satisfacción de sus clientes. En el siguiente organigrama presentado en la Figura 1.2 se puede observar una vista de las interrelaciones entre las distintas unidades de negocios y las Estructuras de Coordinación de la Red. Figura 1.2. Estructuras de Coordinación [1].

19 Organización funcional Para la ejecución de proyectos se plantea un modelo de equipos organizados (Project Realization Team o Equipo de Realización de Proyectos) como un equipo pequeño de iguales trabajando bajo roles multidisciplinarios, que contribuyen a cubrir con eficiencia todas las fases del proceso de diseño, producción y entrega de las soluciones de software, a menor costo y con garantía de satisfacción por parte del cliente. Cada rol en su especialidad, pertenece a su vez a una de las unidades de negocios dándole vida al CDS, su trabajo en conjunto es garantía para la entrega a tiempo y con las características de calidad deseadas (ver Figura 1.3). Figura 1.3. Relación entre el CDS y los roles de sus miembros [1]. Estos equipos PRT conforman los CDS o Centros de Desarrollo de Soluciones y tienen la responsabilidad de producir y entregar al cliente las soluciones encargadas, de acuerdo con los criterios y especificaciones contractuales establecidas entre las partes. Cada equipo es coordinado por el Gerente de Programa quien se encarga de garantizar el correcto funcionamiento del equipo y de llevar a feliz término la ejecución de las actividades planificadas. La participación de todos los roles no es requerida para todo tipo de proyecto. Los roles involucrados dependerá de las necesidades del cliente y de las características del proyecto a ejecutar. La estructura del PRT se puede apreciar en la Figura 1.4.

20 9 Figura 1.4. Equipo de Proyecto PRT [1]. La organización DBAccess posee una particularidad en su estructura, en ella no existe una jerarquía de cargos, no se cuenta con un organigrama tradicional y no existen estructuras burocráticas; esto debido a que todas las unidades se encuentran al mismo nivel y sus miembros se organizan por roles. Los roles que conforman el PRT se encuentran brevemente descritos a continuación: Gerente de Programa: El Gerente de Programa es el encargado de garantizar el apropiado funcionamiento del equipo que conforma el PRT y llevar los proyectos del portafolio a un término satisfactorio para el cliente. Líder de Soluciones de Negocio: Es el encargado de velar en el proceso interno de ingeniería por los criterios de aceptación y estándares de calidad establecidos por el cliente. Líder de Desarrollo: Es el Líder en el área técnica en el desarrollo del proyecto. Desarrolladores: Responsables del desarrollo de las actividades de construcción. Líder de Calidad: Encargado de garantizar la calidad de los productos, los procesos y un modelo de operación que cumpla con los lineamientos convenido con el cliente. Líder de Pruebas de Software: Encargado de definir el proceso de pruebas, así como también establecer los parámetros y criterios a utilizar en las mismas.

21 10 Líder de Arquitectura: Tienen la responsabilidad de garantizar la calidad técnica de la producción, evaluar nuevas tecnologías e identificar brechas que requieren entrenamiento específico para el personal. Líder de Infraestructura: Presta servicio a todos los integrantes del proyecto con actividades de instalación de aplicaciones, configuración de software, conectividades de redes y otros aspectos técnicos planificados o no, que sean requeridos por el equipo de proyecto. Líder de Configuración de Software: Tiene la responsabilidad de mantener los repositorios de los proyectos, donde se almacenan versiones de software, documentos de diseño y toda la información en general del proyecto. Líder de Usabilidad y Experiencia Usuario: Encargado de garantizar que el software pueda ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso Ubicación del pasante Durante el período de elaboración del proyecto documentado en este informe, el pasante desempeñó el rol de Desarrollador bajo la dirección del tutor industrial, el ingeniero Pedro García, Líder de soluciones y bajo la supervisión técnica del Ingeniero Juan Bustamante, Líder de Configuración. El proyecto de pasantía se llevó a cabo en el contexto de diferentes procesos de ejecución en el área de Aseguramiento de la Calidad, de acuerdo con los lineamientos metodológicos de DBAccess, razón por la cual el trabajo se desarrolló de la mano de la Unidad de Calidad.

22 11 CAPÍTULO 2 MARCO TEÓRICO Y TECNOLÓGICO En este capítulo se presentan los conceptos, términos y fundamentos teóricos y tecnológicos relacionados con el proyecto, necesarios para la comprensión del mismo, además de las herramientas y técnicas utilizadas para la realización del mismo Conceptos teóricos Pruebas de Desempeño El término desempeño se refiere directamente con el logro de objetivos. Se puede definir la manera como alguien o algo trabaja, juzgado por su efectividad [2]. Cuando enfocamos el término en el área de la computación, el desempeño puede ser analizado desde diferentes puntos de vista. Por ejemplo, la percepción de un usuario se encuentra vinculado con tiempos de respuesta rápido y sin rechazos de conexión. Por otro lado, la percepción de un especialista de la Web se encuentra más orientada hacia un alto rendimiento de la conexión y una alta disponibilidad y accesibilidad. Lo que sí es común para todas las percepciones de desempeño, es la necesidad de métricas cuantitativas que describan el comportamiento de un servicio en la Web [3]. Dentro de las métricas más importantes para la medición del desempeño de sistemas Web, se encuentra el tiempo de respuesta y el rendimiento. Este último es comúnmente conocido en el área por su nombre en inglés: throughput; la velocidad a la cual una solicitud HTTP es servida, representa el rendimiento de la conexión. Esto es usualmente expresado en operaciones HTTP por segundos, debido a la alta variabilidad del tamaño de los objetos

23 12 Web solicitados el rendimiento también es medido en términos de bits por segundo. El tiempo requerido para completar una solicitud es el tiempo de respuesta. En general, las mediciones más comunes para la evaluación del desempeño de un sistema Web son: tiempo de respuesta, bits por segundo, conexiones por segundos y errores por segundo [3]. En este sentido, las pruebas de desempeño son un conjunto de pruebas implementadas y ejecutadas para caracterizar y evaluar las propiedades asociadas al desempeño, a través de las métricas ya mencionadas. Dichas propiedades pueden ser: el flujo de ejecución, confiabilidad operacional y limites operacionales. Existen distintos tipos de pruebas de desempeño, cada uno enfocado en cumplir diferentes objetivos; estos tipos de prueba son comúnmente implementados durante todo el ciclo de vida del desarrollo del software [4]. Para analizar el desempeño, en general, se debe realizar los siguientes tres pasos: [4] 1. Se evalúan los resultados de la ejecución de un escenario de prueba para un actor o un caso de uso, comparándolo con varias ejecuciones de la misma. 2. Se examinan las estadísticas resumidas recaudadas para un actor o caso de uso en busca de indicadores de variabilidad de las respuestas del sistema. 3. Se obtienen conclusiones acerca del desempeño del sistema, comprender sus causas y su importancia Tipos de Pruebas de Desempeño Los diferentes tipos de pruebas de desempeño se pueden clasificar en [4]: Pruebas de benchmark. Comparan el desempeño del sujeto de prueba con el de un sistema y carga de trabajo de referencia. El término benchmark es sinónimo de carga de prueba: programas utilizados para cargar el sistema y medir el rendimiento del sistema o de partes de éste. Cada benchmark se concentra en un aspecto distinto del desempeño y se debe escoger el adecuado a cada caso, por ejemplo, uso intensivo del CPU, uso intensivo de disco, uso intensivo de memoria, representación gráfica, entre otros.

24 Pruebas de estrés. Este tipo de prueba, permite verificar la aceptabilidad del desempeño del sistema ante condiciones anormales o extremas: volumen de usuarios/transacciones extremadamente alto, recursos escasos, poco ancho de banda, memoria reducida o poco espacio en disco. Estas pruebas también permiten documentar las condiciones bajo las cuales el sistema falla: límites Pruebas de perfil de desempeño. Las pruebas de perfil de desempeño están enfocadas a monitorear el comportamiento de una aplicación en ejecución con el fin de conocer dónde invierte su tiempo: acceso a datos, llamadas a un procedimiento y al sistema. Además, permiten identificar cuellos de botella y procesos ineficientes. Una herramienta de perfil de desempeño ejecuta la aplicación en un ambiente controlado, realiza una traza de su flujo de ejecución y retorna un reporte del consumo de tiempo y memoria Pruebas de carga. Las pruebas de carga permiten verificar y validar el desempeño de un elemento de un sistema bajo diferentes condiciones de carga: número de usuarios o de transacciones Estas pruebas son muy importantes cuando los sistemas deberán soportar un gran volumen de usuarios o transacciones concurrentes. Para realizar este tipo de pruebas, se utilizan simulaciones de cargas de trabajo promedio y pico dentro de los niveles normales. Las mismas deben ser realizadas bajo condiciones controladas para asegurar la precisión de las medidas tomadas. El desarrollo de este proyecto de pasantía se basó principalmente en la ejecución de pruebas de desempeño. Debido a las necesidades a partir de las cuales la aplicación fue concebida, se requiere una evaluación en el rendimiento de la capa de servicios, para determinar el comportamiento de la aplicación con la cantidad actual de usuarios que pueden utilizar concurrentemente diferentes funcionalidades de la aplicación, así como

25 14 también evaluar el comportamiento con una cantidad mayor de usuarios concurrentes debido a un posible crecimiento del negocio en el que mayor cantidad de usuarios estarán haciendo uso de la aplicación. Es por esto que para la elaboración de este proyecto, se realizaran pruebas de carga para evaluar el comportamiento de la aplicación con diferentes cantidades de usuarios y poder identificar los puntos en los cuales la aplicación presenta problemas de rendimiento; las pruebas de perfil también servirán de apoyo para determinar lo puntos en los que la aplicación presenta estos problemas y ayudarán a realizar las mejoras necesarias Tecnologías utilizadas REST Transferencia de Estado Representacional o REST por sus siglas en inglés (Representational State Transfer), define un conjunto de principios de arquitectura para el diseño y creación de servicios Web [5]. Debido a su sencillez de uso, se ha convertido en los últimos años en el modelo predominante para el diseño de servicios Web, desplazando a otros estilos anteriormente muy utilizados como el Protocolo Simple de Acceso a Objetos, o SOAP por sus siglas en inglés (Simple Object Access Protocol) [6]. Un servicio Web implantado utilizando REST sigue los siguientes cuatro principios básicos [6]: Utiliza los métodos HTTP (HyperText Transfer Protocol) explícitamente. No conserva el estado, por lo que las peticiones hechas al servidor son independientes unas de otras y deben ser manejadas de manera atómica. Presenta los URI (Universal Resource Identier) con estructura de directorio. La información es transferida utilizando XML, JSON, o ambos. REST no es una arquitectura, es simplemente una guía de cómo hacer las cosas de una manera fácil, práctica y efectiva bajo protocolos y herramientas ya existentes, que al combinarlas trabajan a favor de crear una aplicación bien diseñada y bajo un modelo bien pensado [6].

26 15 La capa de servicios del aplicativo Web de OT, sobre el cual se realizaron las pruebas de desempeño durante el desarrollo de este proyecto de pasantía, está basada en la utilización de servicios Web bajo los principios REST Java Java, es un lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems en El lenguaje en sí mismo toma mucha de su sintaxis de C, Cobol y Visual Basic. La memoria es gestionada mediante un recolector de basura. [7] Los archivos.java son compilados por el compilador de Java (javac) generando archivos.class, los cuales no contienen código del procesador nativo, sino que en su lugar contiene código bytecodes, el cual es un lenguaje que interpreta la máquina virtual de Java. Esto hace de Java un lenguaje portable. Para el desarrollo de la aplicación sobre la cual se ejecutaron las pruebas de desempeño, se utilizó Java 1.6 edición estándar AJAX Asynchronous JavaScript And XML (AJAX), es una técnica de desarrollo Web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano [11]. Entre las tecnologías que AJAX dispone están, la presentación basada en estándares usando XHTML y CCS; permitir XML y JSON para intercambio y manipulación de datos al servidor; usar el objeto HttpRequest para intercambiar datos de forma asíncrona con el servidor Web; utilizar Document Object Model (DOM) para mostrar e interactuar dinámicamente con la información presentada. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, es decir aumenta la interactividad, velocidad y usabilidad en las aplicaciones.

27 Apache JMeter. Apache Jmeter es una aplicación de escritorio de software libre y fue diseñada para probar el comportamiento funcional y medir desempeño sobre distinto tipo de sistemas [9]. Entre sus características, Apache JMeter incluye [9]: La capacidad de realizar pruebas de desempeño sobre diversos tipos de servidores y protocolos: Web HTTP, HTTPS, SOAP, REST, FTP, Bases de Datos vía JDBC, LDAP, Protocolos de correos electrónicos como SMTP(S), POP3(S) e IMAP(S). Comando nativos y Shell Script, TCP y portabilidad completa. Framework totalmente multi-hilo, el cual permite muestreos concurrentes por numerosos hilos y muestreo simultáneo de diferentes funciones por grupos de hilos separados. Posee una interfaz gráfica, cuyo diseño permite realizar rápidos planes de prueba. La herramienta Apache JMeter fue utilizada para la ejecución de las pruebas de desempeño realizadas en el desarrollo de este proyecto de pasantía, aprovechando la capacidad de la herramienta para medir el desempeño de servicios Web estructurados bajo el principio REST Hibernate. Hibernate es una herramienta de correspondencia objeto-relacional (ORM) para la plataforma Java que facilita la correspondencia de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas relaciones. Esta herramienta es totalmente software libre y distribuido bajo los términos de la licencia GNU LGPL [11].

28 17 La herramienta Hibernate, busca relacionar el problema de la diferencia entre el modelo de datos usado en la memoria de la computadora (Orientación a objetos) y el usado en las bases de datos (modelo relacional). Hibernate convierte los datos entre los tipos utilizados de Java y los definidos por SQL. La herramienta evita producir sentencias SQL y facilita la tarea del desarrollador, en cuanto al manejo manual de datos que resultan de la ejecución de dichas sentencias, de manera que se mantiene la portabilidad entre todos los motores de base de datos incrementando el tiempo de ejecución Además fue diseñado para presentar flexibilidad en cuanto al esquema de tablas utilizado [11]. Finalmente, Hibernate ofrece también un lenguaje de consulta de datos llamado HQL (Hibernate Query Language), al igual que una API para construir las consultas programáticamente (conocida como "criteria [11]. La aplicación sobre la cual se desarrollaron las pruebas de desempeño utiliza la herramienta de Hibernate para el manejo de las consultas a la Base de Datos JProfiler Es herramienta usada para realizar pruebas de perfil en aplicaciones basada en Java, desarrollada por Ej-Technologies GmbH, orientado para aplicaciones Java EE y Java SE. La herramienta permite identificar cuellos de botella, fugas de memoria y algún problema con el manejo de hilos en la aplicación. [13] Jprofiler, trabaja como una aplicación autónoma y como un Plug-in para el software Eclipse. Con esta herramienta, se habilitan tanto el perfilado de la memoria para evaluar el uso de la memoria y la ubicación dinámica de fugas de memoria, como el del CPU. Además, esta herramienta provee una representación visual de la máquina virtual, en términos de bytes, hilos, clases y la actividad del recolector de basura [14]. Esta herramienta, fue utilizada en el desarrollo del proyecto para identificar cuellos de botellas y fugas de memoria en la aplicación.

29 18 CAPÍTULO 3 MARCO METODOLÓGICO En el presente capítulo tiene la finalidad de dar a conocer los aspectos metodológicos que guiaron la ejecución del proyecto de pasantía documentado en este informe. Es de gran importancia contar con una metodología de desarrollo que se adapte a las necesidades del proyecto y a la filosofía de la organización. Una correcta metodología permite que los procesos de análisis, diseño, implantación y aseguramiento de la calidad, puedan ser mejor gestionados Metodología DBAccess. DBAccess cuenta con una metodología para el desarrollo de software, una variante muy cercana a Rational Unified Process (RUP). Dicha metodología está certificada CMM (Capability Maturiry Model) nivel 2, indicando esto que está orientada a cubrir las áreas claves del proceso definidas para este nivel de madurez: Gestión de Requerimientos, Planificación Proyectos, Seguimiento y Control de Proyectos, Aseguramiento de la Calidad del Software y Gestión de Configuración de Software. La metodología de DBAccess, propone una variación del desarrollo en cascada con una orientación iterativa e incremental en la fase de construcción.

30 Adaptación de la metodología de DBAccess al desarrollo del proyecto Por tratarse de un proyecto de pasantía, se adaptó la metodología de DBAccess tanto desde el punto de vista de sus fases como de sus áreas claves del proceso para controlar el avance del desarrollo del proyecto y minimizar los riesgos asociados. La adaptación se enmarca dentro de los procesos de ejecución, los cuales, se componen de un conjunto de actividades organizadas en procesos, que tienen por objeto alcanzar el propósito de las distintas fases del ciclo de vida de un proyecto y de ese modo asegurar el alcance de los objetivos de negocio de DBAccess y por ende de la satisfacción de nuestros clientes. Los procesos de ejecución involucrados en la elaboración de este proyecto de pasantía son, el proceso de requerimientos, el proceso de pruebas o validación, el proceso de diseño y desarrollo técnico, y el proceso de implantación; en la Figura 3.2 se muestra cómo interactúan estos procesos. A continuación, se describen los procesos de ejecución adaptados y que son los aplicados para el desarrollo del proyecto. Análisis de Requerimientos Diseño y Desarrollo Técnico Iteración Construcción de la solución Implantación Pruebas y Validación Figura 3.1. Procesos de Ejecución de DBAccess. Elaboración propia Proceso de Análisis de Requerimientos Para el proceso de Análisis de Requerimientos se establecen como metas contar con una visión de los principales retos a ser abordados por la solución, definir de manera general los elementos que la conformarían, delimitar su alcance y acordar sus criterios de aceptación. El entregable a generar en esta fase es un Documento de Análisis donde se plasma una visión general del problema y del cliente que para este caso es DBAccess, esbozando la

31 20 solución planteada. Las actividades a realizar para lograr las metas y cumplir con los entregables son: investigaciones y entrevistas informales, la documentación de sus resultados y su posterior análisis a fin de definir el modelo conceptual de la solución. Este proceso está comprendido dentro de la etapa de conceptualización y pruebas de concepto Proceso de Pruebas y Validación El proceso de pruebas y validación, propone como meta establecer las actividades necesarias para demostrar que un componente del producto satisface su uso especificado cuando es colocado en el ambiente previsto. En este sentido, las actividades que se ejecuten, tienen el fin de asegurar que los componentes de software seleccionados reflejan los requerimientos especificados, confirmar que el sistema o producto de software integrado reúne los requerimientos definidos y asegurar que la implementación de los requerimientos evaluados es aprobada. Este proceso se encuentra dentro de la etapa de pruebas de concepto e implementación del proyecto. Parea la realización de este proyecto se especifican ciertos tipos de requerimientos para ser validados durante la ejecución de este proceso. Las actividades y el alcance del Proceso de Pruebas y Validación son: Planificación del proceso de pruebas, determinar la estrategia de pruebas, selección de la herramienta apropiada y planear las actividades a seguir. Desarrollar y validar los casos de pruebas y listas de chequeo. Establecer el ambiente para las pruebas. Realizar las pruebas y evaluar y analizar los resultados. Dar visibilidad al equipo y stakeholders sobre el desarrollo de las pruebas. Verificar la ejecución del proceso de pruebas. En esta fase se producen los siguientes elementos o artefactos: Plan de Pruebas, Documento de casos de Pruebas e Informe de Pruebas.

32 Proceso de Diseño y Desarrollo Técnico. El proceso de diseño y desarrollo técnico, tiene como propósito diseñar e implementar soluciones de software que reflejen de manera apropiada los requerimientos establecidos. Para la adaptación de este proceso al desarrollo del proyecto, se establece como meta realizar los ajustes necesarios derivados del proceso de pruebas para el cumplimiento de los requerimientos especificados, incluyendo diseño de la arquitectura de solución y la construcción e implementación de dicha solución. El principal entregable de este proceso será un Documento de Diseño Detallado. Este proceso se encuentra dentro de la etapa de implementación del proyecto. Esta fase tiene el siguiente alcance: Selección de la alternativa de solución y diseño de la arquitectura de la solución. Validación y acuerdos sobre los criterios de aceptación. Realización o actualización de los casos de uso. Preparación de ambientes para el desarrollo e integración del software. Planificación detallada del desarrollo e implantación. Codificación de los programas y componentes de software definidos. Implementación de la solución planteada. En esta fase se producen los siguientes elementos o artefactos: Diseño detallado Proceso de Implantación Para la adaptación del proceso de implantación en el desarrollo de este proyecto, se establece como objetivo asegurar que el producto funcione adecuadamente, garantizando el inicio y continuidad de las operaciones del cliente, mediante el uso efectivo de la solución desarrollada. Los entregables de esta fase son: un Informe Final de Pruebas indicando las pruebas realizadas en el ambiente de despliegue y sus resultados. Este proceso se encuentra dentro de la etapa de evaluación del proyecto.

33 22 Esta fase tiene el siguiente alcance: Planificación de la implantación, configuración e instalación del producto. Ejecución de pruebas. En esta fase se producen los siguientes elementos o artefactos: Informe final de pruebas.

34 23 CAPÍTULO 4 DESARROLLO DEL PROYECTO Este capítulo presenta el proceso de desarrollo del proyecto. Se detallan las actividades de los procesos de la metodología involucrados, las dificultades encontradas, las decisiones tomadas y las adaptaciones necesarias a lo largo del desarrollo Proceso de Análisis de Requerimientos En este proceso se realizó el levantamiento de información para gestionar los requerimientos, conceptualización, riesgos y condiciones sobre el desarrollo del proyecto. Este proceso, está soportado por el Documento de Análisis que se encuentra en el Apéndice A Levantamiento de información En la primera fase del proyecto se realizaron reuniones con el Tutor Industrial a fin de conocer las necesidades que motivaron a desarrollar el proyecto, así como, conocer los elementos a solucionar con la implementación de la solución. En primer lugar, es importante resaltar que el proyecto nace como una iniciativa de la empresa ante la necesidad de realizar mejoras en el desempeño en una aplicación Web, haciendo una adaptación del proceso de pruebas de la empresa para lograr una correcta evaluación de la misma, y fomentar este tipo de prácticas en el equipo de pruebas de la empresa. Partiendo del planteamiento del problema explicado en la introducción, el proyecto tiene como meta primordial implementar pruebas de desempeño en la capa de servicios de la aplicación OT del cliente Avon, y en base a los resultados obtenidos en dichas pruebas, elaborar mejoras en el aplicativo.

35 24 Por otra parte, se identificaron los usuarios involucrados en el desarrollo del proyecto y se planificaron una serie de entrevistas orientadas a realizar el levantamiento de requerimientos. Como resultado de estas entrevistas se obtuvo la lista de requerimientos que se describen a continuación: Identificar y definir los criterios de desempeño que debe cumplir la aplicación Order Tracking, y recolectar toda información necesaria para la elaboración de dichas pruebas. Se debe identificar prácticas en el desarrollo de pruebas de desempeño, así como, seleccionar, instalar y configurar alguna herramienta para la automatización de las mismas. Se debe preparar el ambiente necesario para la ejecución de las pruebas y se requiere la planificación y desarrollo del conjunto de pruebas. Se deben consolidar y analizar los datos recolectados de las pruebas; en base a los cuales, se debe diseñar una propuesta técnica de mejora para la aplicación, identificando prácticas de desarrollo orientado al desempeño. Se deben desarrollar las mejoras y elaborar una evaluación final comprando estos resultados con los anteriores. Como resultado final se debe elaborar una guía de prácticas para la elaboración de pruebas de desempeño automatizadas, así como, elaborar una guía de buenas prácticas de desarrollo de software para mejorar el desempeño de los aplicativos Web Análisis Situación actual de la aplicación Avon OT. La aplicación OT de Avon, tiene como idea central, proveer el seguimiento detallado de las órdenes de compra con el fin de hacer seguimiento global a todo el flujo de surtido y

36 25 suministro de órdenes de la empresa Avon en todo el territorio Nacional. Sus funciones principales se centran en: Monitoreo de las órdenes por departamento asociado a un punto deseado de control en la cadena de suministro de las órdenes. Se logra a través de un módulo de monitor de seguimiento de órdenes que se presenta como un grid o cuadro de mando que se actualiza a medida que la información es integrada en la base de datos de Monitor. En este módulo, se cuenta con filtros para facilitar la búsqueda de una orden de acuerdo a diferentes parámetros. Generación y gestión de Controles de Envío de la información. Esto se logra con un módulo de control de envío en donde se registra el seguimiento inicial de las órdenes para poder hacer su seguimiento efectivo. En este módulo, también se cuenta con filtros para listar los documentos de control deseados. Generación de reportes de la aplicación. La aplicación posee un módulo de reportes, en el cual existe una lista de ellos que se generan de acuerdo a los parámetros introducidos. Los atributos de calidad bajo los cuales la aplicación fue desarrollada se muestra en la Tabla 4.1 se muestra la descripción de estos atributos en cuanto al contexto del proyecto, información obtenida del Documento de Arquitectura de la aplicación OT. En este sentido, a pesar que el Desempeño es el atributo de calidad de mayor prioridad bajo el cual la aplicación fue concebida y diseñada, actualmente la aplicación Avon OT presenta problemas de desempeño en producción que han logrado colapsar la aplicación y crear descontento por parte de los usuarios. Los problemas de desempeño que se presentan en OT se encuentran relacionados con el incremento de usuarios de la aplicación; esto produce el descontento del usuario final y la preocupación que genera ese continuo crecimiento.

37 26 Prioridad Atributo Descripción en el Contexto del proyecto 1 Desempeño Se espera que ninguna consulta ni funcionalidad del sistema OT tarde mucho tiempo en realizarse. 2 Tolerancia a Fallos La información que presenta el sistema OT depende de múltiples puntos y sistemas. Un error en algún sistema no debe ocasionar que la aplicación genere información inválida, y debe ser capaz de recuperarse. 3 Mantenibilidad Al depender de otros sistemas que están en mantenimiento, así como la capacidad de crecer hacia nuevas funcionalidades implica que el mantenimiento de la aplicación va a ser constante. 4 Escalabilidad Se espera que el sistema procese 15 mil órdenes al día con su seguimiento detallado y ubicaciones. Pero también se espera que la información histórica no crezca más de 6 campañas de historia. Tabla 4.1. Atributos de Calidad de la aplicación OT Situación actual del proceso de pruebas de desempeño en DBAccess DBAccess, tal como se menciona en el Capítulo 2, rige su metodología de acuerdo al estándar CMMI. A pesar que el proceso de pruebas no compone por completo el área de proceso de aseguramiento de la calidad, es un elemento primordial para el logro de las metas del área.

38 27 Las pruebas de desempeño no son una práctica común en la empresa, ni suelen ser incorporadas en tempranas etapas del desarrollo de software. En este tipo de pruebas no se han identificado prácticas y estrategias para la elaboración de las mismas Identificación de la brecha entre la situación actual y la expectativa. Para poder alcanzar las expectativas, se tiene que hacer una evaluación cuidadosa y eficiente de la aplicación para determinar las causas del problema de desempeño presentes en OT y poder plantear soluciones de optimización que reflejen notoriamente mejoras en su desempeño. Luego de analizar los resultados obtenidos por las pruebas e identificar los problemas que están ocasionando problemas de desempeño, es necesario el diseño y la implementación de una solución para lograr mejorar el desempeño de OT, especialmente en los módulos que más afectan a los usuarios Riesgos identificados. Los riesgos identificados asociados al desarrollo del proyecto de pasantía, son: Tiempo límite de entrega. Como mitigación ante este riesgo se plantea la elaboración de un plan de proyecto que posea fechas límites para la elaboración de las diferentes etapas del proyecto. Desconocimiento en el uso de buenas tecnologías. Como mitigación al problema se plantea la realización de sesiones de inducción sobre las nuevas tecnologías. Luego de la evaluación de la aplicación, no se obtuvieron resultados que ayuden a identificar el problema de desempeño de la aplicación OT. Para la mitigación de este problema se plantea disponer del apoyo del líder de calidad para lograr un correcto proceso de pruebas y obtener resultados adecuados para la identificación de problemas. Falta de recursos de software para desarrollo de las pruebas, lo cual pueden afectar los resultados de las mismas.

39 Proceso de Pruebas y Validación Durante este proceso, se definen y describen las actividades necesarias para validar el desempeño de la aplicación OT en base a los requerimientos y criterios bajo los cuales, la aplicación fue diseñada y elaborada. El proceso se encuentra soportado por los siguientes documentos: Plan de Pruebas, Casos de Prueba y el Informe de Pruebas, los cuales se encuentran en los Apéndices B, C y D correspondientemente. En la Figura 4.1 se muestran las distintas etapas comprendidas en este proceso. Figura 4.1. Proceso de Pruebas y Validación Planificación de Pruebas Durante esta etapa se siguen los pasos necesarios para poder diseñar las pruebas a ejecutar, incluyendo las expectativas de la empresa respecto al estudio. Esta etapa se encuentra apoyada principalmente por el documento de Plan de Pruebas en el Apéndice B. Para la realización de las pruebas, es importante tener en cuenta, los requerimientos del proyecto y las necesidades del cliente para poder determinar el tipo de pruebas que mejor se adapte. En este caso particular, se decide realizar pruebas de carga para evaluar el desempeño de la aplicación con diferentes cantidades de usuarios, incluyendo la cantidad de usuarios actuales, la cantidad que se espera llegar a tener y una cantidad aún mayor, y poder determinar el comportamiento de la misma y poder aplicar las mejoras necesarias en donde sea requerido.

40 Revisión y entendimiento de la arquitectura y funcionalidad de la aplicación La idea general en cuanto a la composición de OT y sus principales funcionalidades, es descrita en la sección de Levantamiento de información del presente capítulo. En este paso, se genera el documento de Plan de Pruebas. El flujo de información clave de acuerdo al comportamiento de la aplicación es: Los usuarios realizan usualmente dos tipos de visitas al servidor: las de lectura y las de escritura. El principal manejo de información se maneja en la capa de Servicios de la aplicación, a través de los Servicios Web Restful. Estos servicios se orientan para el manejo de información que no se actualiza en línea o se genera a partir de transacciones atómicas (Control de envío, principales consultas de Monitor y Reportes). En el módulo de Monitor existe un canal de información por cada juego de filtros seleccionados de tal manera que el número máximo de canales de comunicación dependa de la cantidad de usuarios conectados, existiendo también la posibilidad de reutilizar canales. En el Módulo de Control de Envío, se hace predominante la generación de formularios dinámicos de ingreso de documentos, en los cuales la interacción y usabilidad son claves. En este módulo el volumen de transacciones es de cantidad considerable. La Información que viene por el canal (JSON) es lo suficientemente completa para que el filtro pueda pintar con comodidad la información deseada por el usuario. Las pruebas serán realizadas para la capa de servicios, en la cual se encuentran todos los servicios Web Restful que permiten operaciones genéricas referentes a las órdenes de compra, monitoreo de las órdenes y la generación de reportes. Luego de sesiones realizadas con los involucrados en el desarrollo de este proyecto, se establecieron los servicios que serían objeto de prueba durante este proceso de acuerdo a su importancia y a la frecuencia

41 30 de uso en la aplicación; estos servicios se encuentran listados en el Plan de Pruebas en el Apéndice B. Order Tracking se integra con otros sistemas a través interfaces encargadas del envío y recepción de mensajes. Sin embargo, de acuerdo a los requerimientos de este proyecto, los componentes del sistema fueron aislados de manera que el proceso de pruebas se concentrara únicamente en el desempeño de la capa de Servicios de la aplicación. En la Figura 4.2 se muestra Modelo General de componentes de la aplicación. Figura 4.2. Modelo General de Componentes. En cuanto al modelado de Datos, OT está estructurado bajos los siguientes lineamientos básicos de modelado: El modelo de bases de datos se estructura en 4 regiones independientes en donde toda información a almacenar por el sistema se maneja dentro de estas regiones: Seguimiento de la orden, Configurabilidad, Gestión de Usuarios y Control de Envío.

42 31 Se define una tabla única de órdenes y de cajas para almacenar el estado más actualizado de la orden y de la caja respectivamente. Además, se define una tabla de tracking que mantiene la historia de seguimiento de la orden Evaluación de Usabilidad de la herramienta de medición de Desempeño Para el desarrollo de las pruebas se seleccionó la herramienta JMeter. Esta herramienta fue seleccionada luego de una evaluación de diferentes herramientas; esta evaluación es descrita en el Apéndice E. Se dispuso de diferentes tipos de elementos provistos por la herramienta: Thread Group: Permite identificar la cantidad de usuarios que habrá en cada momento de la prueba y el tiempo total de ejecución de la prueba. Logic controller: Contenedores de acciones y especifican como se van a usar estas acciones en términos de orden, repetición, determinismo, existencia, entre otros. Config Element: Elementos que introducen directivas de configuración, como son, la gestión de cookies, números aleatorios, cabeceras de las solicitudes, etc. Timer: Elementos que administran el tiempo entre una solicitud y otra para un usuario o para todos los usuarios. Listener: Reportes, los cuales permiten indicar los datos que se desean almacenar para su posterior análisis. Los elementos específicos utilizados se encuentran detallados en el Apéndice B y el Apéndice F, corresponde a un tutorial diseñado para el uso de la herramienta JMeter, orientado a la elaboración de pruebas a servicios Web Expectativas de Desempeño Hizo falta determinar la cantidad de conexiones paralelas que pueden realizarse dependiendo de la cantidad de usuarios, teniendo en cuenta los distintos roles que pueden tener. Cada rol, determina el acceso de cada usuario a los distintos módulos. Actualmente la cantidad total de usuarios que utilizan OT son 15 usuarios, los cuales, pueden estar todos

43 32 concurrentemente haciendo solicitudes en la aplicación. Esta es la cantidad mínima de conexiones que se desea que OT sea capaz de soportar, sin presentar problemas de desempeño, tomando en principal consideración tiempos de respuesta y errores. Sin embargo, se espera tener hasta 70 usuarios concurrentemente. Los tiempos de respuestas esperados dependen para cada tipo de solicitud, el detalle de estos tiempos se encuentran registrados en el artefacto de Casos de Prueba en el Apéndice C Métricas de Evaluación de Desempeño. La definición de Métricas de evaluación permitirá determinar los servicios del sistema que presentan mejor y peor comportamiento en cuanto a desempeño, de acuerdo a diferentes condiciones. Para ello, se definieron las siguientes métricas: 1. La duración promedio de espera de un usuario a la aplicación. Esto expresa el Tiempo de respuesta de la aplicación. Para este caso se usará el tiempo de respuesta de cada solicitud a los diferentes servicios individualmente. 2. El porcentaje de fallos de las solicitudes. Esto representa la estabilidad de la aplicación. 3. La cantidad total de respuestas exitosas de llamadas a servicios por segundo. Esta métrica se mide en base a bits por segundo, esto se conoce como el rendimiento o throughput de la aplicación, el cual expresa la capacidad de la misma Enfoque y Estrategia de Evaluación de Pruebas. La herramienta JMeter seleccionada para la ejecución de las pruebas permite evaluar la aplicación en base a pruebas de carga. Lo primero que se hizo fue determinar que las llamadas realizadas por JMeter efectivamente ejecutaban el proceso deseado del lado del servidor y éste devolvía la respuesta. Para esta validación, se hizo uso de diferentes elementos de la herramienta que nos permitieron observar dichas respuestas por parte del servidor.

44 33 Además, se realizó una prueba en cuanto a volumen de carga para determinar si la ejecución de una prueba con un alto número de usuarios, era posible de acuerdo a la capacidad de la computadora en la cual se ejecutarían las pruebas. La especificación de dicha computadora, se encuentra en el Informe de Pruebas en el Apéndice D. Hubo varias configuraciones en la herramienta para el cumplimiento de este objetivo, estas configuraciones están plasmadas en el tutorial elaborado para el uso de JMeter en la sección de Buenas prácticas en el Apéndice F.

45 34 CAPÍTULO 5 CONFIGURACIÓN Y EJECUCIÓN DE PRUEBAS Este capítulo presenta las actividades de los procesos de la metodología involucrados en la configuración y ejecución de las pruebas realizadas, incluyendo las decisiones tomadas, los resultados obtenidos y las dificultades enfrentadas a lo largo del proceso Configuración de las Pruebas. El detalle de la preparación del ambiente, se encuentra en el Plan de Pruebas. Durante esta etapa, se realizan todas las actividades referentes a la elaboración de las pruebas. Se encuentra soportada principalmente por los Casos de pruebas, detallados en el artefacto de Casos de Prueba en el Apéndice C Crear y validar Escenarios de Prueba. Se escogieron 1, 15, 30, 60, 80 y 100 usuarios concurrentes para las distintas cargas. La prueba con 1 usuario es para tener una referencia y validar el guion de prueba, la concurrencia de 100 usuarios es para determinar la capacidad de la aplicación con un número mayor al tope de usuarios dispuestos para la utilización de la aplicación. Los 15 usuarios, representan la cantidad de usuarios actuales de la aplicación. Se aumentaron en 30 y 60 de forma lineal para identificar un punto de quiebre. Y luego se aumentó linealmente hasta probar con 100 usuarios concurrentes. El tiempo de espera entre solicitud y solicitud fue de 5 a 25 segundos con distribución uniforme. El objetivo fue alcanzar un promedio de 15 segundos entre cada solicitud. Las pruebas fueron configuradas para durar un mínimo de 60 minutos.

46 35 Las pruebas fueron generadas para la siguiente combinación: Módulo(s), servicio(s) asociado(s), es decir, los escenarios de pruebas fueron: Probar las distintas cargas de usuarios para los servicios de Módulo de Monitor. Probar las distintas cargas de usuarios para los servicios de Módulo de Control de Envío. Probar las distintas cargas de usuarios para los servicios de Módulo de Monitor y Control de Envió. Probar las distintas cargas de usuarios para los servicios de Módulo de Reportes. Se decide probar los servicios de los módulos de Monitor y Control de Envío por separado y juntos para determinar la interdependencia de los módulos, debido a que son lo más usados por los usuarios. Esto generó un total 4 guiones de pruebas, cada uno configurable para las distintas cantidades de usuarios. Cada usuario con un retraso proporcional, inicia los mismos tipos de solicitudes, y en caso de terminar las solicitudes planificadas, se vuelve a comenzar el ciclo de solicitudes. Las pruebas de 1 y 15 usuarios, almacenaron adicionalmente el cuerpo de la solicitud en caso de error, de esta forma fue posible depurar errores que hubo durante la programación de las pruebas. Las pruebas son repetibles debido a que usan un archivo estático de solicitudes, el cual emplea variables dinámicas para utilizar distintos parámetros para cada solicitud. Además se hace uso de una base de datos modelo que puede cargarse nuevamente al inicio de cada prueba. Se disponen de diferentes usuarios de prueba para lograr simular escenarios reales. En este sentido, las distintas solicitudes se hacen en una proporción adecuada de acuerdo a cada tipo de solicitud y de su objetivo dentro de la aplicación Crear guiones de pruebas y poblar la base de datos Los diferentes guiones de pruebas realizados con la herramienta JMeter, poseen la misma estructura general, sin embargo, las solicitudes realizadas dependerán de los distintos casos

47 36 de pruebas para los cuales son ejecutados. Los valores usados por las variables en los guiones de pruebas, varían de acuerdo al caso de prueba y están almacenados en archivos CSV leídos en cada prueba que se ejecute. Con el procesamiento de estos archivos, se logra que cada usuario ejecute instrucciones distintas para cada tipo de solicitud y evitar problemas en especial con las solicitudes que implican una actualización o escritura en la base de datos, de registros repetidos y que las operaciones repetidas de actualización o eliminación tengan un efecto nulo en la base de datos. Los datos de pruebas presentes en la base de datos dispuesta para la realización de las pruebas, representan datos reales tomados del propio ambiente en el que se encuentra la aplicación, representando entonces un escenario más similar a la realidad. Estos datos fueron exportados y almacenados en un archivo, lo cual permitió ingresarla de nuevo cada vez que hubiera sido modificada y fuera necesario ejecutar la prueba de nuevo Ejecución de los casos de prueba de desempeño y proceso de supervisión La ejecución de este proceso, se conforma únicamente en la llamada del binario de JMeter. La llamada del binario desde un command prompt con ciertos parámetros específicos. La llamada se hace con el siguiente comando: <JMETER_HOME>/bin/jmeter -t <Ruta del jmx> -n -l <Ruta donde se almacenan los resultados>/results.jtl j <ruta del log>, donde: - t, indica la dirección donde está el guion de pruebas a ejecutar - n, indica la forma en que JMeter ejecuta la prueba, que en este caso, representa la forma NON GUI, es decir, sin interfaz de la aplicación. - l, indica la dirección en cual se desea almacenar los resultados. - j, indica la dirección en la cual se guardará el archivo log de la ejecución. Los comandos para la ejecución de las distintas pruebas, son ejecutados desde un archivo batch (archivo de procesamiento por lotes), en el cual también se maneja la restauración de la base de datos.

48 Validar los resultados Para la validación de los resultados, se buscaron posibles fallas durante la ejecución de las pruebas, las cuales quedan registradas en el archivo log de la ejecución de las pruebas. Adicionalmente, dado que cada prueba efectuada con el JMeter se compone de una secuencia de evaluaciones incrementales, fue posible comparar entre ellas para verificar que los valores efectivamente iban incrementando Objetivos de las Pruebas. El principal objetivo de las pruebas ejecutadas, es evaluar las métricas seleccionadas en los escenarios de pruebas. Esta evaluación se realiza comprando los resultados de los diferentes escenarios de prueba para cada métrica: - Comparar los tiempos de respuesta obtenidos de cada Escenario de prueba y obtener el punto de quiebre en el que los tiempos de respuesta aumentan, identificando condiciones de carga y servicios involucrados. - Comparar el porcentaje de errores obtenidos de cada Escenario de prueba y obtener el punto de quiebre en el que la estabilidad del sistema disminuye hasta llegar a un punto de inestabilidad en la aplicación, identificando condiciones de carga y servicios involucrados. - Comparar el número de solicitudes por unidad de tiempo obtenidos de cada escenario de prueba y obtener el punto de quiebre en el que el rendimiento se comienza a mantener constante o disminuye, identificando condiciones de carga y servicios involucrados Análisis y revisión de las pruebas En esta etapa, los datos recolectados de las pruebas de desempeño, son consolidados y analizados. A continuación, se presenta el análisis que incluyen los resultados de la evaluación y un análisis técnico sobre la evaluación. En el Informe de Pruebas que se

49 Segundos 38 encuentra en el Apéndice E, están los resultados obtenidos en las pruebas con un mayor nivel de detalle Revisión de los datos generados Los resultados, serán analizados comparando los distintos escenarios de prueba para cada tipo de métrica. Los resultados para las diferentes métricas de los escenarios de prueba que incluyeron la medición del Módulo de Monitor y Control de Envió individualmente y en conjunto, fueron muy similares por lo que se demostró una independencia de los módulos en cuanto al desempeño. La primera métrica analizada es el Tiempo de Respuesta. Las Figuras reflejan los tiempos de respuesta promedio en segundos por el número de usuarios concurrentes de los servicios de los módulos de Monitor, Control de Envío y Reportes correspondientemente Número de Usuarios

50 Segundos Segundos Informe de Pruebas Figura 5.1. Tiempo de Respuesta de los servicios de Monitor Número de Usuarios Figura 5.2. Tiempo de Respuesta de los servicios de Control de Envío Número de Usuarios Figura 5.3. Tiempo de Respuesta de los servicios de Reportes. Los resultados en líneas generales favorecen a los servicios de Monitor, en comparación con los servicios evaluados en los módulos de Control de Envío y Reportes. Los tiempos de respuestas de estos servicios, en promedio no superan los 7 segundos, alcanzando este valor con la mayor carga de usuarios, hasta llegar a los 30 usuarios, la tasa de incremento de los

51 Porcentaje 40 tiempos de respuesta es baja, variando de 1.3 a 2.4 segundos, mientras que, para más de 30 usuarios hasta 100 usuarios, los tiempos de respuestas incrementan más rápido variando desde 2.4 a 6.5 segundos. Los tiempos de respuestas reflejados en las Figuras 5.2 y 5.3 no son tan favorables en comparación a la primera, sin embargo, para el caso de los servicios del módulo de Control de Envío, las pruebas no se realizaron con una carga mayor a 60 usuarios, debido a las fallas generadas, causando la caída de la aplicación en el servidor de pruebas y originando alteraciones en los resultados. Para este escenario, la velocidad de incremento en las primeras cargas de los tiempos de respuesta no es tan alta, en comparación con la carga de 30 usuarios y 60 usuarios. El tiempo de respuesta promedio varía de 2,8 a 18,8 segundos en comparación de la variación que hay de 30 usuarios a 60 usuarios, que va desde 18,8 a 48,9 segundos. En el caso de la Figura 5.3, se puede identificar un aumento en la velocidad de crecimiento de los tiempos de respuesta a partir de los 30 usuarios, aumentando notoriamente desde los 15 segundos con 30 usuarios hasta los 57 segundos con 100 usuarios. Lo cual da indicio de un posible cuello de botella al aumentar más de 30 de usuarios. La segunda métrica evaluada corresponde a la estabilidad de la aplicación, la cual fue medida de acuerdo al porcentaje de errores de la aplicación. En la Figura 5.4 se muestra el porcentaje de errores en función de las cargas de usuarios del escenario en que estos valores tienen un cambio a lo largo de las pruebas Número de Usuarios

52 Solicitudes por segundo 41 Figura 5.4. Porcentaje de errores de Control de Envío. La aplicación permanece estable durante la utilización de los servicios de Monitor y Reportes, manteniendo el porcentaje de errores en 0%, sin embargo esto no ocurre para el módulo de Control de Envío, en el que el aumento del porcentaje varía de 0 a 17 % con 1 y 30 usuarios respectivamente, mientras que con 30 y 60 usuarios, varía de 17% a 51,25%. Esto refleja la notoria inestabilidad del sistema, en especial con más de 30 usuarios concurrentes realizando solicitudes en este módulo. Finalmente se evaluaran los resultados obtenidos de la métrica de rendimiento o throughput de la aplicación, representado por la cantidad de solicitudes por unidad de tiempo. Estos resultados se ven reflejados en las Figuras Número de Usuarios Figura Tasa de respuestas recibidas en los servicios de Monitor.

53 Solicitudes por Minutos Solicitudes por Minuto Número Usuarios Figura 5.6. Tasa de respuestas recibidas en los servicios de Control de Envío Usuarios Figura 5.7. Tasa de respuestas recibidas en los servicios de Reportes. Nuevamente, los resultados son favorables para los servicios del módulo de Monitor permitiendo inclusive representar los resultados obtenidos en función a solicitudes por segundos, a diferencia del resto de los módulos donde se mostraron en solicitudes por minuto. En la Figura 4.10, el rendimiento de la aplicación se mantiene en aumento con las distintas cargas de usuario, demostrando que inclusive aumentando el número de usuarios, el sistema puede seguir aumentando el número de solicitudes considerablemente.

54 43 La figura 4.11, por otro lado se muestra la cantidad de solicitudes por minuto soportadas por el módulo de Control de Envío a medida que aumentan los usuarios expresando el rendimiento del módulo. En la gráfica, resulta notorio el bajo rendimiento del módulo a medida que aumenta la cantidad de usuarios, las solicitudes por minutos varían desde 12 a 1,7 solicitudes por minutos, aumentando de 1 a 60 usuarios respectivamente. Por último, la Figura 4.12 muestra la cantidad de solicitudes por minuto soportadas por el módulo de Reportes a medida que aumentan los usuarios expresando el rendimiento del módulo. En la gráfica, resulta notorio el punto en que el número de solicitudes disminuye drásticamente la velocidad de crecimiento. Este punto se alcanza con 30 usuarios concurrentes, lo cual indica en concordancia con los resultados anteriores del módulo, un posible cuello de botella en la aplicación, con la utilización de los servicios del módulo de Reportes. Una vez alcanzados los 30 usuarios el rendimiento de la aplicación se mantiene desde las 56,12 solicitudes por minutos hasta 59,3 solicitudes por minuto. Luego del análisis de estos resultados, es posible identificar los puntos críticos de la aplicación en cuanto al desempeño, facilitando la identificación de los posibles cuellos de botellas en donde realizar una optimización es primordial para lograr cumplir con las expectativas de desempeño esperadas de la aplicación.

55 44 CAPÍTULO 6 DESARROLLO Y PRUEBAS DE SOLUCIÓN PROPUESTA El siguiente Capitulo presenta las actividades realizadas para la propuesta y desarrollo de la solución de mejora, así como también, los resultados de las pruebas con la solución implementada realizando una comparación con los resultados anteriores.

56 Identificación de problemas relacionados al sistema o en la infraestructura Luego del análisis de la sección , se pueden identificar los principales problemas de Desempeño presentes en OT, los cuales se encuentran en el módulo de Control de Envío en el cual no fue posible tener más de 60 usuarios concurrentes debido al alto consumo de CPU, el cual llegó a incrementar hasta en un 90%. Inclusive con menos cantidad de usuarios concurrentes, tanto los tiempos de respuesta como la estabilidad del sistema no es la adecuada de acuerdo al comportamiento esperado. El rendimiento de los servicios de este módulo, fue bastante bajo, disminuyendo a mayor cantidad de usuarios, lo cual, indica la presencia de un cuello de botella en la aplicación. Una vez identificado en donde se encuentra el problema, es imprescindible determinar puntualmente la causa del mismo. Para este objetivo, fue necesario realizar un estudio aún más profundo de los datos obtenidos en las pruebas, datos que se encuentran detallados en el Informe de Pruebas. Luego de esta evaluación, se logró identificar los principales servicios que causan dichos resultados, permitiendo el aislamiento y análisis de los mismos. Los servicios identificados son de lectura, los cuales solicitan y procesan gran volumen de información. El aislamiento de estos servicios, permitió demostrar que el resto de los servicios del módulo no impactan en gran magnitud el desempeño de la aplicación. Para el análisis de estos servicios, se hizo uso de la herramienta JProfiler, que permitió identificar los métodos involucrados en la generación del cuello de botella en el módulo, para lo cual se identificaron las partes del servicio en que se consumían mayor número de recursos. Estos servicios fueron getdocumentcontrols y getdocumentsincontrol ; con la herramienta, se puede observar el alto consumo de recursos presente en la implementación de los mismos, además se identifican los métodos específicos en el cual sucede este alto consumo, los cuales pertenecen a la clase Querier. Finalmente luego de detectar e identificar los métodos causante de los cuellos de botella del Módulo Control de Envío, es necesario entender la implementación de dichos métodos

57 46 y evaluar la posibilidad de una re-implementación de los mismos, para eliminar los cuellos de botella Proceso de Diseño y Desarrollo Técnico En este proceso se diseñó e implementó las soluciones de software necesarias para la optimización de la aplicación, de acuerdo a los resultados obtenidos en el proceso de Pruebas y Validación. Las etapas de este proceso se muestran en la Figura 6.1. Este proceso se encuentra soportado por un Documento de Diseño detallado en el Apéndice H. Figura 6.1. Proceso de Diseño y Desarrollo Técnico Diseño de Alto Nivel En esta etapa se diseña una propuesta de solución luego de evaluar la implementación de los servicios identificados en el proceso anterior: getdocumentscontrol y GetDocumentsSinControl Situación Actual Ambos servicios pertenecen al Módulo de Control de Envío, y son utilizados para listar órdenes registradas previamente, los mismos son de lectura y devuelven un JSON con toda la información solicitada. Los servicios getdocumentscontrol y

58 47 GetDocumentsSinControl son invocados por las funcionalidades de Listar Controles de Envío y Listar Ordenes sin Control de Envío respectivamente, las cuales: Listar Controles de Envío o Se muestra el listado que contiene los Controles de Envío previamente registrados. o Los Controles de Envío se muestran según su fecha de creación en el sistema, ordenándolos de forma descendente. o Se podrá filtrar por año, campaña, origen, estado, tipo de control de envío, zona y número de control de envío. Listar Órdenes sin Control de Envío. o Se muestra el listado de órdenes que no poseen un control de envío asociado o El listado de órdenes debe mostrar: la campaña, número de pedido, contrato, nombre de la representante y zona. o Se permitirán reasignar una orden a un control de envío existente. o Se permitirá anular y reactivar una orden sin control de envío que no haya sido facturada. o Se permitirá eliminar una orden sin control de envío que no haya sido facturada. o Las órdenes sin control de envío podrán ser filtradas por: zona, contrato y campaña. Las consultas realizadas por los servicios, se realizan haciendo uso del framework Hibernate para la correspondencia de los atributos de la Base de Datos relacional y el modelo de objetos de la aplicación y hacen uso del Lenguaje de Solicitudes de Hibernate, o HQL por sus siglas en inglés. Ambos servicios solicitan un alto volumen de datos, los cuales son procesados para presentar solo la información necesaria. Además, ambos listados poseen filtros para parametrizar la información que se quiere mostrar, los cuales realizan la clasificación procesando los datos que fueron almacenados en memoria luego de la primera solicitud a la

59 48 Base de Datos. El filtrado, permite generar un atajo al resultado deseado basado en algún valor de atributo especificado Propuesta de Solución. Ante el alto consumo de recursos por parte de los servicios involucrados en el Listado de Controles de Envío y el Listado de Ordenes sin Control de Envío, se propone: Agregar paginación en ambos listados para evitar el alto consumo de recursos. Entendiéndose paginación como la colección de un número definido de registros por página, junto con un mecanismo de navegación para avanzar y retroceder entre las distintas páginas. El filtrado de la información se realizará consultando la información que se desea clasificar directamente en la Base de Datos. Solo se solicitará en la Base de Datos la información requerida para ser mostrada al usuario, evitando solicitar información que no sea necesaria. Hacer el mejor uso del Framework Hibernate para realizar las consultas y técnicas que permitan mejorar el desempeño de la solicitud y disminuir el consumo de recursos. Entre las cuales se plantea el uso del API Criteria de Hibernate y la activación del segundo nivel de caché de Hibernate Diseño Detallado En la sección siguiente se detalla la solución implementada para la optimización y reimplementación de los servicios getdocumentscontrol y GetDocumentsSinControl Decisiones de Diseño Servicios RESTful Ambos servicios consultan una gran cantidad de información, consumiendo un alto nivel de la memoria y procesan toda la información consumiendo además, un gran porcentaje de CPU. Es por esto que se limitará el volumen de información, mostrando ambos listados en

60 49 varias páginas reduciendo así la carga del servidor. La lógica de negocio en ambos servicios será la misma que se tenía, solo cambiará la forma en que la información es presentada. La paginación en ambos casos no solo reducirá el consumo de los recursos y bajará los tiempos de repuesta sino que también, mejorará la experiencia de usuario permitiendo una mejor navegación para conseguir la información que se desea, evitando que el un usuario se deba desplazar por una larga lista de información, así como también se evitará la sobrecarga de información en el explorador, permitiendo una navegación más rápida. Los servicios serán capaces de recibir parámetros de búsqueda para evitar realizar el filtrado de la información del lado del cliente, es decir, si se desea utilizar un filtro para la búsqueda la información será solicitada al servidor con los parámetros de búsqueda correspondiente. En este sentido las consultas serán modificadas para solicitar solo información que será mostrada al usuario, evitando solicitar información que luego de ser procesada quede descartada Para la optimización de estos servicios, también se plantea el uso de otras estructuras de datos que mejoren el desempeño, como por ejemplo el uso de StringBuilder en vez de hacer uso de los objetos tipo String, en aquellos casos que sea posible. El digrama de las clases involucradas en el diseño de la solución, se encuentra en el Diseño Detallado en el Apéndice H Persistencia Las consultas serán realizadas con el API de Hibernate Criteria, el cual ofrece una alternativa para la manipulación de objetos contra una clase persistente en particular. Esta interfaz ofrece métodos para la paginación y para el manejo opcional de parámetros de búsqueda, enfocados a realizar estas acciones con un buen desempeño. Las tablas involucradas en la solución se reflejan en el modelo de datos presentado en el Diseño Detallado en el Apéndice H.

61 50 Otra estrategia planteada para mejorar el desempeño de la aplicación, consiste en activar el Caché de Segundo Nivel de Hibernate, el cual está asociado con el objeto Session Factory. Esto nos permite que todo objeto que sea cacheado pueda ser obtenido en cualquier lugar de la aplicación, por cualquier usuario y en cualquier momento las veces que sean necesarias y sin acceder a la base de datos Interfaz Gráfica Toda la lógica que se realiza para la presentación de la información estará contenida en el archivo JavaScript listar_control_envio.js, la cual se encargará de mostrar la información solicitada para los listados de Controles de Envío y Órdenes sin Control de Envío. El paginador de ambas listas estará acorde con el diseño del resto de la aplicación, y poseerá un mecanismo de navegación para avanzar o retroceder entre las distintas páginas. La cantidad de órdenes que se mostrarán por cada página podrá ser configurable, a través del archivo de propiedades de la aplicación Construcción de la Solución Implementación de los servicios Los servicios getdocumentscontrol y GetDocumentsSinControl fueron reimplementados y como resultados se crearon los servicios getdocumentscontrolpaged y GetDocumentsSinControlpaged los cuales pertenecen a la clase DocumenteControlServices. Estos métodos, retornan un Objeto JSON con la información solicitada, de acuerdo a los parámetros de búsqueda en caso de tenerlos, el número de la página solicitada y el tamaño de la misma. El JSON además de poseer la información de cada orden que será mostrada en esa página, posee el número total de registros que cumplen con la solicitud, el cual es necesario para la distribución del número de páginas totales. Los métodos utilizados por los servicios para consultar la información, serán implementados en la clase Querier y la clase DocumentControlsQuerier. Algunos de los métodos se realizaron de manera genérica para ser utilizados por ambos servicios de

62 51 acuerdo al pase de parámetros. Esto se puede apreciar en el Diagrama de Clases ubicado en el Diseño Detallado en el Apéndice H. Los métodos implementados son: - getbydinamiccriteriapaged y getdocumentscontrolpaged, reciben entre sus parámetros la clase persistente bajo la cual se realizará la consulta, los parámetros por los cuales realizará la búsqueda en caso de tenerlos, el parámetro por el cual se ordenará la consulta, el número y el tamaño de la página. Este método se implementó en la clase Querier y DocumentsControlQuerier respectivamente. - getdocumentscontroltotalcount y getdocumentsincontroltotalcount, los cuales indican la cantidad total de registros que tiene la búsqueda, para poder realizar la distribución del número de páginas en que será dividida la consulta. Este método se encuentra en la clase DocumentsControlQuerier Para la implementación de estos servicios se hizo uso de la clase StringBuilder en lugar de la clase String para aquellos mensajes que sean modificables, tanto para mensajes de error, alertas, mensaje en el log de la aplicación, o mensajes que sean construidos con alguna concatenación. La clase String de Java es inmutable, lo que hace que cuando se modifique el valor de un String, se está creando un nuevo objeto, por lo que el desempeño puede ser afectado considerablemente, en especial cuando se realizan numerosas operaciones sobre el objeto; caso contrario sucede al usar la clase StringBuilder, la cual es mutable y permite guardar cadenas de caracteres que cambiaran en la ejecución del programa sin crear una nueva instancia del objeto y de este modo realizar operaciones de manera más raída y con mejor desempeño Desarrollo de Pruebas Unitarias Se desarrollaron pruebas unitarias para verificar el funcionamiento correcto de los servicios implementados. Para esto se hizo uso del framework de JUnit, el cual está diseñado para realizar pruebas unitarias de aplicaciones Java. Estas pruebas fueron implementadas en la clase DocumentControlServiceTest, y en ellas, se validan que la cantidad de registros esperados de acuerdo a las diferentes solicitudes, coincida con el

63 52 retornado. Se crearon además el conjunto de datos de prueba utilizados para ejecutar los distintos casos de prueba, estos datos se crearon en un archivo XML denominado DocumentControlServiceTest.xml Aspectos de configuración. Se realiza la activación del caché de segundo Nivel de Hibernate, para lo cual es necesario configuraciones en Hibernate y además elegir un implementador de cache. Hibernate soporta 4 implementaciones de software libre como proveedores de cache y se seleccionó EhCahe. Este proveedor se caracteriza en compración con el resto por ser liviano, rápido, fácil de usar, soporta cache en memoria y en disco. La configuración necesaria se realiza en el archivo de configuración de hibernate hibernate.cfg.xml, agregando las siguientes propiedades: - "hibernate.cache.provider_class": org.hibernate.cache.ehcacheprovider. - "hibernate.cache.use_structured_entries" : true Finalmente se hace el mapeo correspondiente de las clases que se desean seleccionar como cacheables Proceso de Implantación En este proceso se describe la configuración del ambiente y los recursos necesarios para desplegar las mejoras realizadas. Está sustentada por el cehcklist de Despliegue en el Anexo Implantación de la aplicación. Para implantar la solución, y ejecutar las pruebas de desempeño para los escenarios determinados y poder realizar una comparación antes de la mejora implementada, fue necesario desinstalar y volver a instalar la aplicación en el ambiente destinado a la elaboración de las pruebas. Esta actividad de preparación del ambiente y despliegue de la aplicación será la misma que se realizó para la preparación del ambiente de pruebas

64 53 explicado en el Plan de Pruebas y en el checklist de Despliegue de la aplicación en el Apéndice B y el Anexo 1, correspondientemente. El proceso general para la instalación de OT, consistió en generar en instalador de la aplicación con los cambios realizados. Para esto se hace uso de la herramienta Apache Maven, el cual permite la compilación, prueba y empaquetamiento de la aplicación a través de comando de consola. La descripción del proyecto de software a construir, los plugins necesarios, la configuración de los perfiles de los usuarios y la especificación los productos resultantes de las diferentes tareas, se realiza en un archivo XML, denominado pom.xml (Project Object Model por sus siglas en ingles). El comando utilizado para generar el instalador de la aplicación es: >> mvn package assembly:single -P =${PROFILE_USER - Dbuild=${BUILD_NUMBER}; En donde P representa el nombre del perfil de usuario a utilizar, y -Dbuild el número del Build que se desea generar. Este comando se ejecuta desde la raíz del proyecto, y genera un.zip que contiene entre otras cosas el instalador de la aplicación. Finalmente se procede a realizar la instalación en el servidor destino. Para esto, se pasa el archivo generado al servidor y se ejecuta el instalador. Una de las actividades programada para este proceso fue la actualización de los documentos asociados a la realización del sistema así como también todos los diagramas asociados Ejecución de Pruebas Posteriormente a la instalación, se procedió a realizar las pruebas de desempeño implementadas en la sección de este Capítulo, las cuales involucran la medición de los servicios que fueron re-implementados, para esto se usaron los mismos guiones de pruebas, sin embargo, debido a la nueva implementación de los servicios, fue necesario realizar cambios para la invocación de los mismos. El detalle de estos resultados junto con

65 Segundos 54 una comparación con los resultados iniciales se pueden visualizar en el Informe de Pruebas Finales en el Apéndice I. En la Figura 4.15 se reflejan los tiempos de respuesta y el porcentaje de errores con la nueva implementación desarrollada. Lo más notorio de este caso de prueba es que se pudo realizar con la carga deseada ya que, con la implementación anterior no se pudo realizar la prueba con más de 60 usuarios por las fallas generadas en el servidor. Los tiempos de respuesta fueron muy favorables para esta nueva implementación siendo menores a 10 segundos con la mayor carga que es 100 usuarios, en comparación con la implementación anterior donde ya con más de 15 usuarios los tiempos de respuesta superan los 10 segundos. Caso similar sucede con el porcentaje de errores, en la nueva implementación en sistema se mantiene estable a lo largo de las diferentes cargas, llegando hasta un máximo de 3 % el porcentaje de errores presentados en el módulo mientras que con la implementación anterior llega hasta más de 50 %. En la Figura 4.16 se refleja una gráfica comparativa de los tiempos de respuestas de la implementación anterior y la implementación con las mejoras realizadas. Demostrando las claras mejoras realizadas en cuanto a los tiempos de respuestas Número de Usuarios Tiempo de respuesta Tiempo de respuesta Anterior Figura 6.2. Tiempos de respuestas de implementación anterior y optimizada.

66 Porcentaje 55 La Figura 6.3 refleja la estabilidad de la aplicación con ambas implementaciones de acuerdo al porcentaje de error presentado en la evaluación del módulo de Control de Envío; mostrando una clara mejora la implementación realizada para la optimización de la aplicación % error anterior % error optimizado Número de Usuarios Figura 6.3.Porcentaje de errores implementación anterior y optimizada. Finalmente la Figura 6.4 muestra las tasas de respuestas recibidas en los servicios de Control de Envío, con la implementación anterior y la implementación de la solución desarrollada para la optimización de los servicios.

67 Solicitudes por segundo Número de Usuarios Rendimiento Optimizado Rendimiento anterior Figura 6.4. Tasa de respuestas recibidas en los servicios de Control de Envío.

68 57 CONCLUSIONES Y RECOMENDACIONES Al finalizar el tiempo de pasantía se obtuvo como resultado una optimización del proyecto de software Order Tracking del cliente. La mejora de este proyecto, se realizó en base a los resultados obtenidos luego de una evaluación desempeño a la aplicación. En la ejecución de este proceso, se identificaron buenas prácticas asociadas tanto a la elaboración de pruebas de desempeño como al desarrollo de aplicaciones orientadas al desempeño, necesarias para todo desarrollo de un software que cumpla con los criterios de calidad esperados y sea aceptado por sus usuarios. La importancia de la realización de pruebas de desempeño, se puede ver reflejada en las gráficas presentadas en el Capítulo 6, las cuales comparan la aplicación desarrollada sin la realización de este tipo de prueba y la aplicación optimizada en base a los resultados de las pruebas de desempeño. Estas mejoras fueron implementadas para los puntos más críticos en cuanto a desempeño, presentes en la aplicación; obteniendo una clara mejora para las diferentes métricas evaluadas: Tiempos de Respuesta, Estabilidad y Rendimiento. Este tipo de prácticas se debe realizar de manera continua y desde tempranas etapas del ciclo de vida de un proyecto de software, para poder asegurar entregar un producto de calidad. Realizar pruebas de desempeño no es una práctica común en muchas empresas y esto se debe muchas veces al esfuerzo y tiempo de dedicación que estas conllevan, sin embargo, la exclusión de pruebas de desempeño en el desarrollo de un proyecto desde tempranas etapas del mismo, y a lo largo de todo el ciclo de vida, evitará la elaboración de un producto de calidad, generando así, descontento y desconfianza por parte del cliente, además de implicar un re-trabajo para poder solventar los problemas de desempeño encontrados luego de la elaboración del producto, los cuales, no existirían si estas pruebas se hubieran elaborado a tiempo. Los avances que existen en la actualidad con respecto a la evaluación de desempeño de aplicaciones Web, se encuentra en un constante crecimiento, lo cual facilitó conocer, entender y poder usar herramientas y técnicas para lograr el objetivo esperado. Es por este

69 58 continuo crecimiento, que la realización de pruebas de desempeño y mejoras en cuanto al rendimiento de una aplicación es un trabajo que se debe realizar constantemente, inclusive cuando las pruebas de desempeño son implementadas desde el comienzo del ciclo de vida de un proyecto. Al trabajar con una metodología como la de DBAccess se pudo apreciar los beneficios que ésta ofrece al desarrollo de software. Fue muy fácil conseguir información sobre la estructura de la organización y documentación de la aplicación evaluada explicados a un nivel bastante profundo y abarcando todo el ciclo del proceso de desarrollo, lo cual facilitó el proceso de elaboración de las pruebas. La metodología utilizada demostró además ser adaptable a diferentes situaciones, para el desarrollo de este proyecto fue posible adaptar la metodología para lograr una correcta evaluación de la aplicación y obtener una mejora en el desempeño de la misma. Al usar esta metodología para el proyecto desarrollado en la pasantía, se ha agregado un alto valor al producto final, ya que, no solo se logró una mejora en la aplicación evaluada sino también se identificaron los siguientes aspectos que deben ser mejorados, así como también se demostró la importancia de este tipo de prácticas, las cuales, pueden ser incluidas y adaptadas para cualquier otro proyecto con características similares. Parte de la experiencia durante el desarrollo de este proyecto, fue entender lo que es ser parte de una empresa, cómo se realiza la gestión de un proyecto, que significa tener las responsabilidades de un trabajador y cómo es la convivencia entre personas del mismo campo laboral. Esta experiencia me preparó para continuar mi carrera después de la universidad. Las siguientes recomendaciones, son producto de esta experiencia y del aprendizaje obtenido: A la empresa se le recomienda fomentar la realización de pruebas de desempeño en todos los proyectos que se encuentren en marcha o que se realicen en el futuro, en cuyo caso se recomienda realizarlas desde tempranas etapas del proyecto. Al cliente CDS AVON, se le recomienda la utilización de los resultados de las pruebas realizadas para seguir aplicando mejoras de desempeño en la aplicación

70 59 OT. Así como también, usar los resultados como referencia para futuras implementaciones. El proyecto en el cual se realizaron las pruebas, así como otro proyectos de la empresa, se encuentran diseñados bajo el enfoque de Entrega Continua, los cuales con un tiempo de dedicación de investigación, se puede incorporar a este enfoque mediciones de desempeño, permitiendo así una mejora continua en el rendimiento del proyecto. La inclusión de pruebas de desempeño para el desarrollo de un software requiere un gran esfuerzo, en especial lograr adaptar las pruebas al tipo de software que se quiera evaluar, ya que depende de diferentes factores como la arquitectura, las reglas de negocio y lo que se espera lograr con la evaluación. Sin embargo es de vital importancia para el aseguramiento de la calidad de un producto y para la satisfacción del cliente al cual se le esté haciendo la entrega del producto. Es por esto que se recomienda la aplicación de este tipo de pruebas durante todo desarrollo de software que se realice.

71 60 BIBLIOGRAFÍA [1] Blog DBAccess. Consultado 06 de Agosto de [2] Vargas Saavedra, Las Mejores Prácticas Empresariales. Evaluación de Desemepeño, Lima, Perú. Consultado 10 de Agosto de [3] Daniel A. Menascé y Virgilio A.F. Almeida. Capacity Plannig for Web Performance. Metrics, models and methods. Recuperado 05 de Agosto de 2013 [4] Bárbara Espinoza, Vanessa Quintas, Alexandra Vega. Pruebas de Desempeño Consultado 10 de Agosto de [5] Transferencia de estado representacional. Consultado 14 de Agosto. [6] Alex Rodriguez. IBM. Restful web services: The basics. developerworks/webservices/library/ws-restful/index.html, Consultado 14 de Agosto de 2013 [7] JAVA. Consultado 14 de Agosto de [8] Oracle. Imagen Proceso de ejecución de un programa en JAVA. Consultado 15 de Agosto de 2013 [9] Sitio Web oficial de la herramienta JMeter. Consultado 15 de Agosto de 2013 [10] J. Pollock: Java script A begginner s Guide, 2 ed. McGraw- Hill, Recuperado 15 de Agosto de 2013

72 61 [11] AJAX. Consultado 15 de Agosto de [12] Pagina web Jquery. Consultado 15 de Agosto de [13] Wikipedia. herramienta de profiling JProfiler. Consultado 15 de Agosto de [14] Página web JProfiler. Consultado 15 de Agosto de 2013.

73 62 Apéndice A-Documento de Análisis

74 63 Proyecto: Diseño e implementación de Pruebas de Desempeño y optimización en Avon OT Cliente: Avon Tabla de Contenido 1 CONTROL DE VERSIONES Y DE CAMBIOS INTRODUCCIÓN GLOSARIO DE TÉRMINOS DESCRIPCIÓN DEL CLIENTE DEFINICIÓN DEL PROBLEMA ALTERNATIVAS DE LA SOLUCIÓN IMPLEMENTAR PRUEBAS DE DESEMPEÑO PARA LA APLICACIÓN AVON OT Y REALIZAR MEJORAS EN SU DESEMPEÑO TABLA DE INVOLUCRADOS EN ESTA SECCIÓN SE PRESENTAN LOS INVOLUCRADOS RELEVANTES PARA EL PROYECTO, Y EN PARTICULAR AQUELLOS DE QUIENES SE OBTIENEN LOS REQUERIMIENTOS DEL MISMO TABLA DE USUARIOS REQUERIMIENTOS RESTRICCIONES RIESGOS IDENTIFICADOS... 71

75 64

76 65 Control de Versiones y de Cambios El versionamiento y los cambios producidos de este documento, así como las fechas y responsables de los mismos, se reflejan en la siguiente tabla: Versión Responsable Fecha Estado Cambios efectuados 0.1 Isaac Rondón 24/07/13 Borrador 0.2 Isaac Rondón 07/09/13 Estable Desarrollo del borrador del documento de análisis del proyecto Actualización de la alternativa de solución. 1.0 Isaac Rondón 07/11/13 Aprobado Aprobada revisión del documento. Introducción Entre los criterios de calidad del software se encuentra la eficiencia, en el cual se relacionan el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas. Durante el desarrollo y a lo largo de la etapa de construcción, los desarrolladores de software deben asegurar que el producto cumpla con estas características acordadas previamente. De aquí la importancia de incorporar prácticas y herramientas que faciliten la evaluación del software, así como identificar prácticas de optimización del código que incidan en un rendimiento óptimo. Este documento analiza los aspectos necesarios para llevar a cabo una evaluación en el desempeño de la aplicación AVON OT (Order tracking), con el fin de identificar causantes en el bajo desempeño de la aplicación y aplicar mejoras en el mismo. El siguiente documento de análisis, provee una visión general del problema y del planteamiento de posibles soluciones. Su principal intención es capturar la información recabada en las primeras etapas del proyecto, teniendo como principal objetivo información concerniente a la identificación de problema, la situación actual, y el planteamiento de diversas soluciones para resolver el problema. Glosario de Términos Desempeño: El término desempeño se refiere directamente con el logro de objetivos, se puede definir la manera como alguien o algo trabaja, juzgado por su efectividad. Pruebas de desempeño: Conjunto de pruebas implementadas y ejecutadas para caracterizar y evaluar las propiedades asociadas al desempeño, a través de diferentes métricas (tiempo de respuesta, rendimiento, indicadores de degradación o errores, conexiones por segundo, etc.), dichas propiedades pueden ser, el flujo de ejecución, confiabilidad operacional y limites operacionales.

77 66 Descripción del Cliente DBAccess es una organización venezolana de proyección global, establecida en 1988 como proveedora de servicios de Tecnología de la Información (TI), y 500 proyectos ejecutados en 15 países de todo el mundo. Es una organización en red con más de 150 colaboradores conectados desde localidades en Venezuela: Barquisimeto, Caracas, Margarita, Mérida, San Cristóbal, Valencia y localidades Internacionales: Chicago (USA), Lima (Perú), Madrid (España), Ciudad de Panamá (Panamá), Bogotá (Colombia), Venecia (Italia). Se dedica al desarrollo de aplicaciones y consultoría en TI. Definición del Problema La elaboración de las especificaciones funcionales y técnicas de un software, está contemplada dentro de las primeras etapas del ciclo de vida del mismo. Desde la fase más temprana, es preciso determinar los criterios de calidad del Software y metas de arquitectura esperadas, siendo el desempeño uno de estos criterios. El desempeño, tiene como finalidad, determinar los límites para que el software sea aceptado por parte de sus usuarios. Durante el desarrollo y en particular a lo largo de la etapa de construcción, los desarrolladores de software deben asegurar que el producto cumpla con estas características acordadas previamente. El Problema de Para desarrollar un software que cumpla con los criterios de calidad, las pruebas son un elemento primordial. La importancia de este elemento radica en los costos asociados a los errores, así como en el descontento de los usuarios finales del software, dicha importancia estimula la definición e implementación de un proceso de pruebas minuciosas y bien planificadas. A diferencia de muchos tipos de prueba, las pruebas de desempeño, comúnmente no se les da el nivel de importancia que requieren, por lo que la realización de estas pruebas no es considerada una práctica común. La no incorporación de este tipo de prácticas de evaluación, repercuta en la disminución de la calidad del software, causado por un empobrecimiento del desempeño. El aplicativo web AVON OT, presenta un bajo desempeño identificado ante el aumento de usuarios de la aplicación. Causando un descontento por parte de los usuarios y disminuyendo la aceptación de la aplicación. Creando además preocupación respecto al comportamiento del desempeño, ante el considerable aumento de usuarios que se desean. afecta el impacto es La capacidad de la empresa de entregar sistemas confiables que cumplan con los criterios de calidad establecidos. Los costos asociados a los errores software. En la actualidad se consume mucho tiempo y esfuerzo en la

78 67 La elaboración de las especificaciones funcionales y técnicas de un software, está contemplada dentro de las primeras etapas del ciclo de vida del mismo. Desde la fase más temprana, es preciso determinar los criterios de calidad del Software y metas de arquitectura esperadas, siendo el desempeño uno de estos criterios. El desempeño, tiene como finalidad, determinar los límites para que el software sea aceptado por parte de sus usuarios. Durante el desarrollo y en particular a lo largo de la etapa de construcción, los desarrolladores de software deben asegurar que el producto cumpla con estas características acordadas previamente. El Problema de Para desarrollar un software que cumpla con los criterios de calidad, las pruebas son un elemento primordial. La importancia de este elemento radica en los costos asociados a los errores, así como en el descontento de los usuarios finales del software, dicha importancia estimula la definición e implementación de un proceso de pruebas minuciosas y bien planificadas. A diferencia de muchos tipos de prueba, las pruebas de desempeño, comúnmente no se les da el nivel de importancia que requieren, por lo que la realización de estas pruebas no es considerada una práctica común. La no incorporación de este tipo de prácticas de evaluación, repercuta en la disminución de la calidad del software, causado por un empobrecimiento del desempeño. El aplicativo web AVON OT, presenta un bajo desempeño identificado ante el aumento de usuarios de la aplicación. Causando un descontento por parte de los usuarios y disminuyendo la aceptación de la aplicación. Creando además preocupación respecto al comportamiento del desempeño, ante el considerable aumento de usuarios que se desean. corrección de aquellos errores o incidencias, que de haber sido identificadas en etapas más tempranas del proceso hubiesen sido mucho más fáciles y rápidas de solventar. Es importante fomentar prácticas para el desarrollo de evaluación de desempeño y de ese modo evitar el descontento de los usuarios finales del software Diseño e Implementación de pruebas de desempeño en el aplicativo AVON OT para la identificación de causantes del bajo desempeño de la aplicación. una solución exitosa seria Identificar buenas prácticas tanto para evaluación del desempeño de aplicativos Web con herramientas de apoyo, como en la optimización del mismo para lograr un desempeño dentro de los parámetros esperados. Planteamiento y elaboración de mejoras en el desempeño de la aplicación.

79 68 Entre las características del proyecto OT las que tienen mayor impacto sobre el proyecto son: Esta es una aplicación desarrollada bajo tecnología Java, usando el framework Spring MVC. El proyecto posee tres módulos: Monitor, Control de Envió y Reportes, los cuales funcionan interdependientemente uno del otro. Las consultas de los datos de los distintos módulos, se realizan a través de servicios RESTful desarrollados con CFX de Apache, una implementación de JAX- WS APIs, y los datos transmitidos son en formato Json. Para la persistencia de los datos, el proyecto hace uso de Hibernate para convertir los datos de los objetos usados por la lógica de negocio, al sistema de tipos usados en una base de datos relacional. El software necesario para el ambiente de producción es: Oracle DataBase Enterprise Server 10g IBM WebSphere Application Server. Alternativas de la Solución Implementación de Pruebas de Desempeño a la capa de servicios de un aplicativo web y Optimización del código de la capa de servicios de la aplicación evaluada con el fin de obtener una mejora en su rendimiento. Implementar Pruebas de Desempeño para la aplicación Avon OT y realizar mejoras en su desempeño. Objetivo General: Implementación de Pruebas de Desempeño a la capa de servicios de la aplicación AVON OT y optimizar el código con el fin de obtener una mejora en su desempeño. Objetivos Específicos: Conceptualización del desarrollo de pruebas de desempeño de aplicativos web. 1. Identificar los criterios de calidad de la aplicación 2. Identificación del contexto funcional o de usuario 3. Identificación de metodología para la ejecución del proyecto y evaluar ajustes necesarios en la misma.

80 69 4. Identificación y selección de herramientas para la implementación de pruebas de desempeño. Pruebas de concepto: 1. Identificar los criterios de desempeño que debe cumplir AVON Order Tracking. 2. Preparación en el uso de la herramienta seleccionada, incluyendo su instalación y configuración. 3. Instalación y configuración de las herramientas de software seleccionadas. Descripción de Involucrados y Usuarios Implementación 1. Definir la estrategia, alcance y plan de las pruebas de desempeño a realizar. 2. Desarrollar casos de prueba, 3. Prepara el ambiente de Pruebas y ejecución de la pruebas. 4. Evaluación de los resultados obtenidos 5. Elaboración de propuestas técnicas para realizar mejoras. 6. Aplicación de las mejoras. 7. Evaluación final. Desarrollo de informe final vs inicial. Evaluación 1. Evaluación final. Desarrollo de informe final vs inicial 2. Elaborar una guía de prácticas para la elaboración de pruebas de desempeño automatizadas. 3. Elaborar una guía de buenas prácticas de desarrollo de software para mejorar el desempeño de los aplicativos Web Tabla de Involucrados En esta sección se presentan los involucrados relevantes para el proyecto, y en particular aquellos de quienes se obtienen los requerimientos del mismo. Nombre Descripción Responsabilidades Pedro García - Tutor de la Pasantía. - Monitorea el progreso del proyecto Juan Bustamante - Líder de Arquitectura. - Indica Necesidades y requerimientos. - Indica prácticas y experiencias

81 70 Nombre Descripción Responsabilidades en el área de desempeño. - Necesidades y requerimientos del proyecto. Isaac Rondón - Analista/ desarrollador - Desarrollar el proyecto. Maribel Gomes -Gerente de proyecto de AVON OT - Indica necesidades y requerimientos. Yadixa Martínez - Lider de Calidad - Indica necesidades y requerimientos. Tabla de Usuarios Nombre Descripción Responsabilidades Involucrado Maribel Gomes Yadixa Martínez Pedro García Gerente de proyecto de la aplicación AVON OT. - Lider de Calidad - Tutor de la Pasantía. - Captura detalles. - Aprobar cambios realizados en la aplicación. - Evaluación de prácticas identificadas. - Inclusión de mejoras identificadas en la metodología. Maribel Gomes Yadixa Martínez - Coordina el trabajo. Pedro García Requerimientos Realizar pruebas de Desempeño a la aplicación AVON OT. o o o o o Establecer los criterios de desempeño que debe cumplir la aplicación. Recolectar información necesaria de aplicación para la elaboración de las pruebas. Identificar, adaptar y ajustar la metodología a seguir para el proceso de pruebas. Selección de herramienta de software para la elaboración de las pruebas. Preparar el ambiente de pruebas.

82 71 o o Ejecutar las pruebas de desempeño. Elaborar informes necesarios de los resultados de las pruebas. Realizar mejoras de desempeño en la aplicación: o o o o o Evaluar el resultado obtenido en base al desempeño del aplicativo. Elaborar propuestas técnicas de atención y solución de las debilidades observadas en el aplicativo. Evaluación de las propuestas técnicas e identificación de los correctivos a ejecutar. Aplicar los correctivos a la aplicación. Evaluación final de la aplicación. Realizar evaluación final: o o o Evaluación final del aplicativo. Elaboración del reporte de desempeño inicial vs. final. Elaborar una guía de prácticas para la elaboración de pruebas de desempeño automatizadas. Elaborar una guía de buenas prácticas de desarrollo de software para mejorar el desempeño de los aplicativos Web Restricciones Por lineamiento del cliente proveniente de su casa matriz y debido a los recursos tecnológicos con el que cuenta la organización, el software que se usa en el ambiente de producción es el siguiente: Oracle DataBase Enterprise Server 10g Websphere Application Server v7.0 Riesgos Identificados Desconocimiento en el uso de las tecnologías y herramientas involucradas. Falta de recursos de software para desarrollo de las pruebas, lo cual pueden afectar los resultados de las mismas. Las mejoras que se planteen pueden depender de recursos de hardware. Las mejoras que se planteen luego de las pruebas, impactara directamente el tiempo y alcance de dichas mejoras.

83 72 Apéndice B-Plan de Pruebas

84 73 Proyecto: Cliente: Order Tracking AVON PLAN DE PRUEBAS

85 74 CONTENIDO 1 Tabla de Control de Versiones y Cambios Introducción Propósito Alcance Definiciones, Acrónimos y Abreviaturas Pruebas de Desempeño REST Objetivos Stakeholders Relevantes de Pruebas Planificación de las Pruebas Revisión y entendimiento de la arquitectura y funcionalidad de la aplicación getdocumentssincontrol: Obtener los documentos de control que no están asociados a una orden Evaluación de Usabilidad de la herramienta de medición de Desempeño Expectativas de Desempeño Métricas... 83

86 75 7. Ambiente de Pruebas Seguimiento Riesgos y contingencia Gestión de defectos Control de cambios Mediciones de Pruebas Riesgos y mitigación Supuestos Tabla de Control de Versiones y Cambios Versión Fecha Responsable Estado Cambios efectuados /08/2013 Isaac Rondón Borrador Desarrollo del borrador del documento /08/2013 Isaac Rondón Actualizado Se realizaron Ajustes /10/2013 Isaac Rondón Actualizado Se realizaron Ajustes.

87 76 Introducción Propósito El propósito de este documento, es el de desarrollar un plan que sirva de base para ejecutar, monitorear y controlar la planificación de las pruebas que se ejecutaran. Las pruebas que se llevaran a cabo, permitirán evaluar el desempeño en la capa de servicios de la aplicación Order Tracking del Cliente AVON. El documento, especificará las distintas actividades que se llevaran a cabo, estimación de tiempo e involucrados para lograr completar el proceso de pruebas. Alcance Este plan tiene su alcance sobre las actividades de los servicios de pruebas a ejecutar en el periodo comprendido entre los meses de Julio y Noviembre.

88 77 Definiciones, Acrónimos y Abreviaturas Pruebas de Desempeño El término desempeño se refiere directamente con el logro de objetivos. Se puede definir la manera como alguien o algo trabaja, juzgado por su efectividad. Cuando enfocamos el término en el área de la computación, el desempeño puede ser analizado desde diferentes puntos de vista. Por ejemplo, la percepción de un usuario se encuentra vinculada con tiempos de respuesta rápido y sin rechazos de conexión. Por otro lado, la percepción de un especialista de la Web se encuentra más orientada hacia un alto rendimiento de la conexión y una alta disponibilidad y accesibilidad. Lo que sí es común para todas las percepciones de desempeño, es la necesidad de métricas cuantitativas que describan el comportamiento de un servicio en la Web. Para analizar el desempeño, en general, se debe realizar los siguientes tres pasos: 4. Se evalúan los resultados de la ejecución de un escenario de prueba para un actor o un caso de uso, comparándolo con varias ejecuciones de la misma. 5. Se examinan las estadísticas resumidas recaudadas para un actor o caso de uso en busca de indicadores de variabilidad de las respuestas del sistema. 6. Se obtienen conclusiones acerca del desempeño del sistema, comprender sus causas y su importancia REST Transferencia de Estado Representacional o REST por sus siglas en inglés (Representational State Transfer), define un conjunto de principios de arquitectura para el diseño y creación de servicios Web [5]. Debido a su sencillez de uso, se ha convertido en los últimos años en el modelo predominante para el diseño de servicios Web, desplazando a otros estilos anteriormente muy utilizados como el Protocolo Simple de Acceso a Objetos, o SOAP por sus siglas en inglés (Simple Object Access Protocol). Un servicio Web implantado utilizando REST sigue los siguientes cuatro principios básicos: Utiliza los métodos HTTP (HyperText Transfer Protocol) explícitamente. No conserva el estado, por lo que las peticiones hechas al servidor son independientes unas de otras y deben ser manejadas de manera atómica. Presenta los URI (Universal Resource Identier) con estructura de directorio. La información es transferida utilizando XML, JSON, o ambos. La capa de servicios de la aplicación, está diseñada bajo este tipo de principios.

89 78 Objetivos El siguiente plan describe los pasos necesarios para poder diseñar las pruebas a ejecutar, incluyendo las expectativas de la empresa respecto al estudio. El mismo está basado en el plan de negocios establecido durante las actividades de Planificación Estratégica y revisado en el tiempo, producto del seguimiento de la estrategia de negocios de la organización y de la Unidad Testing. Stakeholders Relevantes de Pruebas Las personas, que son impactadas y se encuentran involucradas por la ejecución del proceso de pruebas son: Nombre Rol Proyecto Isaac Rondón Analista de Prueba /Desarrollador Order Tracking Maribel Gomes Gerente de proyecto Order Tracking Juan Bustamante Lider de Arquitectura Order Tracking Yadixa Martínez Lider de Calidad Order Tracking Tabla Stakeholders relevantes Planificación de las Pruebas Las actividades a realizar durante el proceso de planificación de las pruebes están comprendidas en: 5.1. Revisión y entendimiento de la arquitectura y funcionalidad de la aplicación El flujo de información clave de acuerdo al comportamiento de la aplicación es: Los usuarios realizan usualmente dos tipos de visitas al servidor: las de lectura y las de escritura. El principal manejo de información se maneja en la capa de Servicios de la aplicación, a través de los Servicios Web Restful. Estos servicios se orientan para el manejo de información que no se actualiza en línea o se genera a partir de transacciones atómicas (Control de envío, principales consultas de Monitor y Reportes). En el módulo de Monitor existe un canal de información por cada juego de filtros seleccionados de tal manera que el número máximo de canales de comunicación dependa de la cantidad de usuarios conectados, existiendo también la posibilidad de reutilizar canales.

90 79 En el Módulo de Control de Envío, se hace predominante la generación de formularios dinámicos de ingreso de documentos, en los cuales la interacción y usabilidad son claves. En este módulo el volumen de transacciones es de cantidad considerable. La Información que viene por el canal (JSON) es lo suficientemente completa para que el filtro pueda pintar con comodidad la información deseada por el usuario. Las pruebas serán realizadas para la capa de servicios, en la cual se encuentran todos los servicios Web Restful que permiten operaciones genéricas referentes a las órdenes de compra, monitoreo de las órdenes y la generación de reportes. Los servicios que serán objetos de estudio en las pruebas realizadas son: - Servicios involucrados para mostrar el Home de la apicaicón: getdepartmentsmetrics: Obtener las métricas de los distintos departamentos. getoperativecampaign: Obetener la campaña actual. getpermissionbymodule: Obtener los permisos de los distintos modulos. haspermission (menu monitor) haspermission (menu document_control) haspermission (menu reportes) haspermission (menu configuración) current: Obtener los permisos del usuario Actual. - Servicios involucrados en el módulo de Monitor filters: Obtener los filtros disponibles. haspermissionscurrentuser: Obtener los permisos del usuario. columns: Calcula la fórmula para cada columna del modulo. getalldepartment: Obtener los diferentes departamentos disponibles. getallcurrentzones: Obtener todas las zonas que se encuentran activas. cleanordersbyzone: Limpiar de Monitor una zona seleccionada. getordersbyanypoints: Obtener las ordenes de todos los puntos de Control. getpurchaseorderbyid: Obtener una Orden. getpurchaseordertrack: Obtener la historia de una orden.

91 80 getcontainersbypurchaseorder: Obtener un contenedor por una orden. - Servicios involucrados en el módulo de Control de Envió. getdocumentcontroltypewithdocumentstype: Obtener un documento de control por tipo de documento. getzonemanager: Obtener la gerente de una zona getdocumentscontrol: Obtener un listado de los documentos de control. registerdocumentcontrol: Registrar un documento de control. getdocumentcontrolreport: Obtener los reportes de un documento de control. getdocumentcontrolvalues: Obtener información asociada a un documento de control. getdocumentcontrolvaluesbybatch: Obtener información asociada a un documento de control por un batch determinado. getbatch: Consultar un Batch getdocumentcontrol: Obtener un documento de control específico. getdocumentssincontrol: Obtener los documentos de control que no están asociados a una orden. - Servicios involucrados en el módulo de Reportes getrecientcampaigns: Obtener las últimas 6 campañas createreceiptrequestreport: Obtener Reporte de Solicitud de Recibos. createprojectionreport: Obtener Reporte de Proyecciones. createsendcontrolreport: Obtener Reporte de Control de Envío. createzonesdailysummaryreport: Obtener Reporte de Zonas Diario. createorderdistributionreport: Obtener Reporte de Orden de Distribución createknappreport: Obtener Reporte de KANAPP.

92 81 getzonesbycalendar: Obtener la zonas que carga por el Calendario createpurchaseordertimereport: Obtener Reporte de Tiempo de la Orden. createorderboxviewreport: Obtener Reporte de Cajas de la Orden. Order Tracking se integra con otros sistemas a traves interfaces encargadas del envío y recepción de mensajes. Sin embargo, de acuerdo a los requerimientos de este proyecto, los componentes del sistema fueron aislados de manera que el proceso de pruebas se concentrara únicamente en el desempeño de la capa de Servicios de la aplicación. A continuación, se presenta el Diagrama de Componentes general de la aplicación. Modelo General de Componentes. En cuanto al modelado de Datos, OT está estructurado bajos los siguientes lineamientos básicos de modelado: El modelo de bases de datos se estructura en 4 regiones independientes en donde toda información a almacenar por el sistema se maneja dentro de estas regiones: Seguimiento de la orden, Configurabilidad, Gestión de Usuarios y Control de Envío. Se define una tabla única de órdenes y de cajas para almacenar el estado más actualizado de la orden y de la caja respectivamente. Además, se define una tabla de tracking que mantiene la historia de seguimiento de la orden.

93 Evaluación de Usabilidad de la herramienta de medición de Desempeño. Para el desarrollo de las pruebas se seleccionó la herramienta JMeter. Esta herramienta fue seleccionada luego de una evaluación de diferentes herramientas. Se dispuso de diferentes tipos de elementos provistos por la herramienta: Thread Group: Permite identificar la cantidad de usuarios que habrá en cada momento de la prueba y el tiempo total de ejecución de la prueba. Logic controller: Contenedores de acciones y especifican como se van a usar estas acciones en términos de orden, repetición, determinismo, existencia, entre otros. Config Element: Elementos que introducen directivas de configuración, como son, la gestión de cookies, números aleatorios, cabeceras de las solicitudes, etc. Timer: Elementos que administran el tiempo entre una solicitud y otra para un usuario o para todos los usuarios. Listener: Reportes, los cuales permiten indicar los datos que se desean almacenar para su posterior análisis. Los elementos Utilizados fueron: jp@gc - Stepping Thread Group: Permite especificar diferentes rangos de tiempos bajo los cuales se ejecutará la prueba, en ellos también se definen la cantidad de usuarios, el Startup Time o tiempo que tardaran todos los usuarios en estar conectados a la vez, el ramp-up, con el cual, se determina en tiempo entre cada inicio de usuario, y el Shutdown tiempo análogo al Startup Time. Only Once Controller: Permite ejecutar las acciones que posea solo una vez. Simple Controller: Permite ejecutar de manera ordenada las acciones que posea. Gestor de cookies HTTP (Config element): permite manejar una cookie distinta para cada usuario. CSV Data Set (Config element): Permite gestionar la información suministrada en un archivo CSV para su uso en la pruebas, como nombres de usuarios, contraseñas y parámetros usados por los servicios objeto de las pruebas. HTTP Request Defaults (Config element): Permite la configuración de las solicitudes HTTP que serán probadas, de manera de hacer las pruebas mantenibles. Constant Timer: Temporizador que ocurre entre una solicitud y otra. Summary Report: Reporte que indica solicitudes enviadas, análisis estadístico básico sobre el tiempo de ejecución, porcentaje de error, solicitudes por segundo, etc. jp@gc Response Time vs Time: Reporte gráfico que muestra los tiempos de respuestas de las distintas solicitudes en el transcurso del tiempo que dure la prueba.

94 83 - Throughput vs Time: Reporte gráfico que muestra el rendimiento de las distintas solicitudes en el transcurso del tiempo que dure la prueba Expectativas de Desempeño. La cantidad de conexiones paralelas que pueden realizarse dependiendo de la cantidad de usuarios, teniendo en cuenta los distintos roles que pueden tener. Cada rol, determina el acceso de cada usuario a los distintos módulos: Modulo de Monitor, Control de Envío y Reportes. Actualmente la cantidad total de usuarios que utilizan OT son 15 usuarios, los cuales, pueden estar todos concurrentemente haciendo solicitudes en la aplicación. Esta es la cantidad mínima de conexiones que se desea que OT sea capaz de soportar, sin presentar problemas de desempeño, tomando en principal consideración tiempos de respuesta y errores. Sin embargo, 15 usuarios en paralelos, es una cantidad de usuarios que, debido al crecimiento del negocio actual, se encuentra en aumento esperando un crecimiento de hasta 70 usuarios. Por lo que, el sistema debería ser capaz de soportar dicha cantidad de usuarios concurrentes. 6. Métricas La métricas definidas que permitieran comparar los servicios involucrados en los distintos módulos son: 1. La duración promedio de una visita de un usuario a la aplicación. Esto expresa el Tiempo de respuesta de la aplicación. Para este caso se usará el tiempo de respuesta de cada solicitud a los diferentes servicios individualmente. 2. El porcentaje de fallos de las solicitudes. Esto representa la estabilidad de la aplicación. 3. La cantidad total de respuestas exitosas de llamadas a servicios por segundo. Esta métrica se mide en base a bits por segundo, esto se conoce como el rendimiento o throughput de la aplicación, el cual expresa la capacidad de la misma. 7. Ambiente de Pruebas Para la realización de las pruebas de desempeño se dispondrá del siguiente ambiente de pruebas: - Servidor de aplicaciones y de Base de Datos: Intel QuadCore 2 Processor. 2 GB de RAM, 2x1 HD DE 20 GB. Windows Server 2008 Enterprise SP1. En este servidor se cuenta con una instancia de Websphere MQ 6.0, que se utiliza como servidor de MQ. - Base de Datos: Oracle 10g, con al menos 4 GB de memoria para el tablespace inicial.

95 84 - Máquina en donde se ejecutaran las pruebas de desempeño: Lenovo, 2GB de RAM. Aquí se tendrá instalada la herramienta seleccionada para la ejecución de las pruebas. La aplicación Order Tracking estará desplegada en el servidor de aplicaciones. 8. Seguimiento Se realiza un seguimiento interno del equipo de pruebas con su Líder, para lo cual se prevee realizar las siguientes reuniones de trabajo: Tipo de Reunión Objetivo Frecuencia Verificar cumplimiento de actividades planificadas. Programar actividades a realizar. Evaluar el estado los servicios de pruebas. Equipo de Involucrado en el proceso de Pruebas. Coordinación Evaluar el grado de cumplimiento y logro de los objetivos. Analizar las métricas recolectadas hasta la fecha. Seguimiento y verificación del proceso. Identificación y análisis de oportunidades de mejoras y lecciones aprendidas durante la ejecución del proceso. Gestionar la oportuna participación de los stakeholders relevantes en el proyecto. Semanal Al comienzo del proceso de Pruebas. Cierre del periodo Gestionar el conocimiento obtenido durante el periodo (lecciones aprendidas y propuestas de mejora) y contribuir a los Activos de Proceso de DBAccess. Al finalizar el proceso de Pruebas. 9. Riesgos y contingencia Se ejecutará el checklist a la aplicación con la finalidad de verificar la estabilidad de la misma antes de pasar a la ejecución del proceso de pruebas. El proceso de pruebas podrá ser suspendido en caso de que el porcentaje mínimo de aceptación no sea alcanzado por la aplicación.

96 85 Se debe planificar la corrección de defectos reportados a la fecha, así como para la reanudación de la ejecución de pruebas sobre una nueva versión que contemple la calidad de la aplicación, y así el proceso de pruebas puede ejecutarse al ritmo esperado Gestión de defectos Los defectos serán identificados y registrados, para su corrección. Los casos deben ser resueltos por el integrante del equipo correspondiente. Una vez resuelto la incidencia, en el próximo proceso de prueba se certificará el defecto y en caso de ser satisfactorio este será aprobado, de lo contrario se reabrirá Control de cambios El ambiente de prueba está bajo el control del equipo de pruebas apoyados por el líder de infraestructura. En caso de que se realice una solicitud de cambio dentro del ambiente de pruebas esta deberá ser canalizada vía correo electrónico y ser dirigido al líder de pruebas del proyecto, el cual debe evaluar el impacto del cambio en el ambiente de prueba y si es necesario aprobarlo ó rechazarlo. Por esta razón, el ambiente de prueba debe ser lo suficientemente estable de manera que los cambios deben ser planificados y aprobados por el líder de pruebas del proyecto Mediciones de Pruebas. Cobertura de las Pruebas (Cantidad de Casos de pruebas a ejecutar y Cantidad de Casos de pruebas ejecutados) Eficiencia y certificación de fallas (Cantidad de fallas cerradas y cantidad de fallas reabiertas) 9.4. Riesgos y mitigación Es posible que el tiempo estimado en el plan actual del proyecto no sea suficiente para cubrir todos los casos de pruebas definidos para las iteraciones. En cuyo caso de realizaran las mejoras asociadas a los casos de pruebas que resultaron insatisfactorios. 10. Supuestos Dentro del proceso de pruebas se supone que, el documento de Análisis y el documento de Casos de Uso constituyen la fuente principal de información para el desarrollo de los casos de pruebas.

97 86 Apéndice C-Artefacto de Casos de Prueba

98 87 Casos de Prueba de Desempeño Cliente: AVON Proyecto: OT Nombre de la Aplicación OT Nombre: Isaac Rondon Departamento IT Fase Producción Iteración: Producción Precondiciones del Caso de Prueba Métricas Fechas de Ejecución Tiempo de Ejecución ID Caso de Prueba ID Requerimiento Objetivo / Descripción del Caso de Prueba (origen) Código de la Aplicación (origen) Módulo/Ruta Precondición 1 Precondición 2 Promedio del Tiempo de Estabilidad o Respuesta (segundos) porcentaje de errores Rendimiento o solicitudes por segundos Observaciones del diseño de Casos de Prueba Fecha de primera Ejecución Tiempo Total de ejecución Estado Observaciones de Ejecución CPI001 Performance Validar el comportamiento del Módulo de Monitor con 1 usuario realizando solicitudes a los servicios involucrados en el módulo por 30 minutos Servicios del Módulo Monitor Monitor El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 1, ,22 02/09/ min Pasó CPI002 Performance Validar el comportamiento del Módulo de Monitor con 15 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo Monitor Monitor El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 2, ,02 4,403 02/09/ min Pasó CPI003 Performance Validar el comportamiento del Módulo de Monitor con 30 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo Monitor Monitor El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 2, ,04 6,02 03/09/ min Pasó CPI004 Performance Validar el comportamiento del Módulo de Monitor con 60 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo Monitor Monitor El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 3,7 0,01 8,3 03/09/ min Pasó CPI005 Performance Validar el comportamiento del Módulo de Monitor con 80 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo Monitor Monitor El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 5,1 0,01 9,5 03/09/ min Pasó CPI006 Performance Validar el comportamiento del Módulo de Monitor con 100 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo Monitor Monitor El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 6,4 0,01 11,6 03/09/ min Pasó CPI007 Performance Validar el comportamiento del Módulo decontrol de Envió con 1 usuario realizando solicitudes a los servicios involucrados en el módulo por 30 minutos Servicios del Módulo de Control de Envío Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 2, /09/ min Pasó CPI008 Performance Validar el comportamiento del Módulo de Control de Envío con 15 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Control de Envío Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 7, /09/ min Pasó CPI009 Performance Validar el comportamiento del Módulo de Control de Envío con 30 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Control de Envío Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 18,867 17, /09/ min Pasó CPI010 Performance Validar el comportamiento del Módulo de Control de Envío con 60 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Control de Envío Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 48,971 51, /09/ min Pasó CPI011 Performance Validar el comportamiento del Módulo de Control de Envío con 80 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Control de Envío Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío N/A N/A N/A Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 05/09/ min Falló No se pudo Concluir la prueba por la caida del servidor CPI012 Performance Validar el comportamiento del Módulo de Control de Envío con 100 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Control de Envío Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío N/A N/A N/A Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 06/09/ min Falló No se pudo Concluir la prueba por la caida del servidor CPI013 Performance Validar el comportamiento de los Módulos de Monitor y Control de Envió con 1 usuario realizando solicitudes a los servicios involucrados en los módulo por 30 minutos Servicios del Módulo de Monitor y Control de Envío Módulo Monitor y Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío y Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 2, /09/ min Pasó CPI014 Performance Validar el comportamiento de los Módulos de Monitor y Control de Envío con 15 usuarios realizando solicitudes a los servicios involucrados en los módulos por 60 minutos Servicios del Módulo de Monitor y Control de Envío Módulo Monitor y Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío y Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 8, /09/ min Pasó CPI015 Performance Validar el comportamiento de los Módulos de Monitor y Control de Envío con 30 usuarios realizando solicitudes a los servicios involucrados en los módulos por 60 minutos Servicios del Módulo de Monitor y Control de Envío Módulo Monitor y Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío y Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 16, /09/ min Pasó CPI016 Performance Validar el comportamiento de los Módulos de Monitor y Control de Envío con 60 usuarios realizando solicitudes a los servicios involucrados en los módulos por 60 minutos Servicios del Módulo de Monitor y Control de Envío Módulo Monitor y Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío y Monitor Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 52,08 50, /09/ min Pasó CPI017 Performance Validar el comportamiento de los Módulos de Monitor y Control de Envío con 80 usuarios realizando solicitudes a los servicios involucrados en los módulos por 60 minutos Servicios del Módulo de Monitor y Control de Envío Módulo Monitor y Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío y Monitor N/A N/A N/A Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 07/09/ min Pasó CPI018 Performance Validar el comportamiento de los Módulos de Monitor y Control de Envío con 100 usuarios realizando solicitudes a los servicios involucrados en los módulos por 60 minutos Servicios del Módulo de Monitor y Control de Envío Módulo Monitor y Control de Envío El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Envío y Monitor N/A N/A N/A Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 07/09/ min Pasó CPI019 Performance Validar el comportamiento del Módulo de Reportes con 1 usuario realizando solicitudes a los servicios involucrados en el módulo por 30 minutos Servicios del Módulo de Reportes Módulo de Reportes El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Reportes Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto ,46 08/09/ min Pasó CPI020 Performance Validar el comportamiento del Módulo dereportes con 15 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Reportes Módulo de Reportes El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Reportes Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 9,24 0,02 0,67 08/09/ min Pasó CPI021 Performance Validar el comportamiento del Módulo dereportes con 30 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Reportes Módulo de Reportes El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Reportes Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 17,3 0,04 0,9 08/09/ min Pasó CPI022 Performance Validar el comportamiento del Módulo dereportes con 60 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Reportes Módulo de Reportes El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Reportes Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 32 0,01 1,01 08/09/ min Pasó CPI023 Performance Validar el comportamiento del Módulo dereportes con 80 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Reportes Módulo de Reportes El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Reportes Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 41,03 0,01 1,03 09/09/ min Pasó CPI024 Performance Validar el comportamiento del Módulo dereportes con 100 usuarios realizando solicitudes a los servicios involucrados en el módulo por 60 minutos Servicios del Módulo de Reportes Módulo de Reportes El usuario tienen permisos Usuario ingresa satisfactoriamente para acceder al Módulo de al sistema Control de Reportes Los resultados obtenido de las distintas métricas sera comparado y analizado con los distintos resultados de los otros casos de pruebas. El caso pasará si se logran ejecutar la spruebas diseñadas en el lapso de tiempo dispuesto. 56,9 0,01 1,04 09/09/ min Pasó

99 88 Apéndice D-Documento Estrategia de Pruebas

100 89 Proyecto: Cliente: Order Tracking AVON ESTRATEGIA DE PRUEBAS

101 90 CONTENIDO 1 Tabla de Control de Versiones y Cambios Introducción Propósito Alcance Definiciones, Acrónimos y Abreviaturas Especificación de pruebas Objetivos Enfoque de las pruebas: técnicas y tipos de pruebas Criterios de aceptación de las pruebas Cobertura de las pruebas Cronograma Gestión de datos Riesgos... 97

102 91 Tabla de Control de Versiones y Cambios Versión Fecha Responsable/Rol Estado Cambios efectuados /08/2013 Isaac Rondón Borrador Desarrollo del borrador del documento /09/2013 Isaac Rondón Actualizado Se realizaron Ajustes /10/2013 Isaac Rondón Aprobado Se realizaron Ajustes. Verificación Final Introducción Propósito El propósito del siguiente documento es el de definir la estrategia que será usada en el proceso de Pruebas para la evaluación de desempeño de la aplicación Order Tracking del Cliente AVON, de acuerdo con la planificación plasmada en el Documento de Plan de Pruebas. Para la definición de la estrategia que será usada, es necesario establecer cuáles son los objetivos de las pruebas y el alcance que tendrá el proceso, así como el enfoque que tendrán las mismas. Alcance El documento tiene su alcance sobre las actividades que conllevan la ejecución de la estrategia definida en el siguiente documento. Definiciones, Acrónimos y Abreviaturas Definiciones - REST: Transferencia de Estado Representacional o REST por sus siglas en inglés (Representational State Transfer), define un conjunto de principios de arquitectura para el diseño y creación de servicios Web [5]. Debido a su sencillez de uso, se ha convertido en los últimos años en el modelo predominante para el diseño de servicios Web, desplazando a otros estilos anteriormente muy utilizados como el Protocolo Simple de Acceso a Objetos, o SOAP por sus siglas en inglés (Simple Object Access Protocol).Un servicio Web implantado utilizando REST sigue los siguientes cuatro principios básicos: Utiliza los métodos HTTP (HyperText Transfer Protocol) explícitamente.

103 92 No conserva el estado, por lo que las peticiones hechas al servidor son independientes unas de otras y deben ser manejadas de manera atómica. Presenta los URI (Universal Resource Identier) con estructura de directorio. La información es transferida utilizando XML, JSON, o ambos. -Pruebas de Desempeño Cuando enfocamos el término en el área de la computación, el desempeño puede ser analizado desde diferentes puntos de vista. Por ejemplo, la percepción de un usuario se encuentra vinculado con tiempos de respuesta rápido y sin rechazos de conexión. Por otro lado, la percepción de un especialista de la Web se encuentra más orientada hacia un alto rendimiento de la conexión y una alta disponibilidad y accesibilidad. Lo que sí es común para todas las percepciones de desempeño, es la necesidad de métricas cuantitativas que describan el comportamiento de un servicio en la Web. Las pruebas de desempeño son un conjunto de pruebas implementadas y ejecutadas para caracterizar y evaluar las propiedades asociadas al desempeño, a través de distintas métricas. Dichas propiedades pueden ser: el flujo de ejecución, confiabilidad operacional y límites operacionales. Existen distintos tipos de pruebas de desempeño, cada uno enfocado en cumplir diferentes objetivos; estos tipos de prueba son comúnmente implementados durante todo el ciclo de vida del desarrollo del software. Para analizar el desempeño, en general, se debe realizar los siguientes tres pasos: [4] 7. Se evalúan los resultados de la ejecución de un escenario de prueba para un actor o un caso de uso, comparándolo con varias ejecuciones de la misma. 8. Se examinan las estadísticas resumidas recaudadas para un actor o caso de uso en busca de indicadores de variabilidad de las respuestas del sistema. 9. Se obtienen conclusiones acerca del desempeño del sistema, comprender sus causas y su importancia. - Pruebas de Carga Las pruebas de carga permiten verificar y validar el desempeño de un elemento de un sistema bajo diferentes condiciones de carga: número de usuarios o de transacciones Estas pruebas son muy importantes cuando los sistemas deberán soportar un gran volumen de usuarios o transacciones concurrentes. Para realizar este tipo de pruebas, se utilizan simulaciones de cargas de trabajo promedio y pico dentro de los niveles normales. Las mismas deben ser realizadas bajo condiciones controladas para asegurar la precisión de las medidas tomadas Acrónimos y Abreviaturas -OT : Order Tracking

104 93 Especificación de pruebas Objetivos El principal objetivo de las pruebas ejecutadas, es evaluar las métricas seleccionadas en los escenarios de pruebas. Esta evaluación se realiza comprando los resultados de los diferentes escenarios de prueba para cada métrica: - Comparar los tiempos de respuesta obtenidos de cada Escenario de prueba y obtener el punto de quiebre en el que los tiempos de respuesta aumentan, identificando condiciones de carga y servicios involucrados. - Comparar el porcentaje de errores obtenidos de cada Escenario de prueba y obtener el punto de quiebre en el que la estabilidad del sistema disminuye hasta llegar a un punto de inestabilidad en la aplicación, identificando condiciones de carga y servicios involucrados. - Comparar el número de solicitudes por unidad de tiempo obtenidos de cada escenario de prueba y obtener el punto de quiebre en el que el rendimiento se comienza a mantener constante o disminuye, identificando condiciones de carga y servicios involucrados. Enfoque de las pruebas: técnicas y tipos de pruebas Entre los distintos tipos de pruebas, el proceso de Pruebas que se llevará a acabo tendrá como objeto la realización de pruebas de carga en la aplicación. Debido a las necesidades a partir de las cuales la aplicación fue concebida, se requiere una evaluación en el rendimiento de la capa de servicios, para determinar el comportamiento de la aplicación con la cantidad actual de usuarios que pueden utilizar concurrentemente diferentes funcionalidades de la aplicación, así como también evaluar el comportamiento con una cantidad mayor de usuarios concurrentes debido a un posible crecimiento del negocio en el que mayor cantidad de usuarios estarán haciendo uso de la aplicación. Las pruebas de perfil también servirán de apoyo para determinar lo puntos en los que la aplicación presenta estos problemas y ayudarán a realizar las mejoras necesarias Crear guiones de pruebas y poblar la base de datos

105 94 Los datos de pruebas presentes en la base de datos dispuesta para la realización de las pruebas, representan datos reales tomados del propio ambiente en el que se encuentra la aplicación, representando entonces un escenario más similar a la realidad. Estos datos fueron exportados y almacenados en un archivo, lo cual permitió ingresarla de nuevo cada vez que hubiera sido modificada y fuera necesario ejecutar la prueba de nuevo. Los diferentes guiones de pruebas realizados con la herramienta JMeter, poseen la misma estructura general, sin embargo, las solicitudes realizadas dependerán de los distintos casos de pruebas para los cuales son ejecutados. Los valores usados por las variables en los guiones de pruebas, varían de acuerdo al caso de prueba y están almacenados en archivos CSV leídos en cada prueba que se ejecute. Con el procesamiento de estos archivos, se logra que cada usuario ejecute instrucciones distintas para cada tipo de solicitud y evitar problemas en especial con las solicitudes que implican una actualización o escritura en la base de datos, de registros repetidos y que las operaciones repetidas de actualización o eliminación tengan un efecto nulo en la base de datos. Criterios de aceptación de las pruebas La aceptación de las distintas pruebas dependerá de cada caso de prueba y métrica que se esté evaluando para las distintas cargas de usuarios presentes en las pruebas. Estas pruebas se basarán en un estudio comparativo entre los resultados obtenidos en los distintos casos de pruebas para detectar puntos crítico de la aplicación en cuanto el Desempeño. Cobertura de las pruebas Cronograma FASE OBJETIVOS ACTIVIDADES DURACIÓN

106 95 Pruebas de Experimentar -Identificar el proyecto y 5,5 SEMANAS Concepto con las aplicativo de software. herramientas de software a utilizar en la implementación de pruebas de desempeño. - Identificar los criterios de desempeño que debe cumplir el aplicativo - Seleccionar la herramienta de software a utilizar para las pruebas de evaluación de desempeño. - Preparación en el uso de la herramienta seleccionada, incluida su instalación y Configuración - Instalación y configuración de las herramientas de software seleccionadas. - Comprobar el uso y aplicación de las herramientas de software seleccionadas demostrando la factibilidad de la implementación de las pruebas de desempeño. Implementaci Llevar a cabo Definir la estrategia y alcance de 4 Semanas ón las pruebas de las pruebas de desempeño a realizar,

107 96 desempeño a la aplicación Web seleccionada. Realizar los correctivos al aplicativo con el fin de garantizar un desempeño acorde con lo esperado por el cliente. así como el plan de pruebas a llevar a cabo para la evaluación del aplicativo Web seleccionado. Desarrollar los casos de pruebas Preparar el ambiente para las pruebas de desempeño a realizar Realizar las pruebas de desempeño apoyado con la herramienta de software Seleccionada Evaluar el resultado obtenido en base al desempeño del aplicativo Gestión de datos Los datos de pruebas serán tomados del propio ambiente en el que se encuentra la aplicación, a través de un DUMP de los datos. Y serán colocados en el ambiente de pruebas cada vez que sea necesario ejecutar las pruebas con la información original. La base de datos a utilizar es Oracle 10g. El host de la Base de Datos corresponde a la dirección: BACANTES-D.dbaccess.com, en la instancia DESA3, en el puerto 1521

108 97 Riesgos Es posible que el tiempo estimado para las distintas actividades del cronograma, no sea suficiente debido a las distintas configuraciones que se deben hacer. En cuyo caso se extenderá el cronograma y realizará una nueva estimación para las actividades acordadas y descritas en este documento. Los recursos dispuestos para la realización de las pruebas determinaran el cumplimiento de las fechas propuestas para el desarrollo del proceso de pruebas. Mientras mas limitantes tengan dichos recursos aumenta la probabilidad de que el uso de la herramienta de JMeter para la realización de las pruebas no se use de manera óptima, ocasionando alteraciones en los resultados. Para mitigar este riesgo, se usarán técnicas para usar la herramienta JMeter de la manera más óptima.

109 98 Apéndice E-Informe de Pruebas

110 99 INFORME DE PRUEBAS AVON Order Tracking

111 100 Control de Cambios del Documento Versió n Fecha Responsable Estado Cambios efectuados /10/201 3 Isaac Rondón / Developer Borrador Versión Inicial /11/201 3 Isaac Rondón / Developer Borrador Creación de Gráficas /12/201 4 Isaac Rondón / Developer Final Ajuste en el análisis de los resultados.

112 101 Contenido 1 Introducción Propósito Objetivos Terminología Lineamientos Generales Establecidos Equipo que realizó las Pruebas Cumplimiento del Plan del Proyecto Pruebas Resultados de la Ejecución de las Pruebas Productos de Pruebas Generados... Error! Bookmark not defined. 7 Identificación de puntos críticos Lecciones Aprendidas

113 102 Introducción Propósito En este documento se expone los resultados luego de la ejecución de las pruebas de desempeño para la aplicación OT de AVON. El documento pretende el estudio y análisis de los resultados obtenidos luego del proceso de pruebas realizado para estudiar el desempeño de la aplicación Order Tracking del cliente AVON. Objetivos El principal objetivo de este informe consiste en el entendimiento y análisis de los resultados que se obtuvieron luego del proceso de pruebas que se desarrolló para la evaluación de desempeño de la aplicación OT. Se muestran los distintos resultados de los casos de pruebas que fueron ejecutados en dicho proceso. En este sentido el análisis se desarrolla para determinar los puntos críticos de la aplicación para luego ser optimizados. Terminología Pruebas: Proceso de ejecución implantado durante el desarrollo de un producto o componente del producto de software, con el objeto de demostrar que éstos satisfacen su uso especificado cuando son colocados en el ambiente previsto, asegurando además, que el producto o componente del producto de software que no esté conforme, se identifique y controle para prevenir su entrega no intencional al cliente. El proceso busca garantizar, la corrección de los defectos identificados en los productos o componentes del producto de software, de manera temprana y eficiente. Caso de prueba: Conjunto de condiciones o variables bajo las cuáles el Líder de Pruebas determinará, si el requerimiento de un producto o componente de producto de software, es parcial o completamente satisfactorio.

114 103 Lineamientos Generales Establecidos Las pruebas tienen el objetivo de evaluar el desempeño de la aplicación Avon OT en la capa de servicios. Los servicios acordados que fueron evaluados, se encuentran plasmados en el Plan de Pruebas, así como el ambiente dispuesto para la realización de las pruebas. Equipo que realizó las Pruebas Nombre Rol Unidad o CDS Isaac Rondón Analista de Prueba Pasante Cumplimiento del Plan del Proyecto Pruebas. Lo planificado en el plan de Pruebas se llevó a cabo, fue necesario realizar distintos ajustes de configuración de ambiente que no se encontraban contemplados inicialmente sin embargo, los tiempos planificados, fueron logrados. Resultados de la Ejecución de las Pruebas En esta sección, se muestran los datos recolectados de las pruebas de desempeño, para ser luego consolidados y analizados. A continuación, se muestran los resultados obtenidos de las distintas métrica para cada servicios evaluado en los distintos casos de pruebas. - CPI001 cou avera medi mi error throughpu Servicio nt ge an n max % t CPI001 /ot/login.jsp ,

115 , auth/current , metrics/getdepartmentsmetrics , auth/getpermissionbymodule auth/haspermission , , campaign/getoperativecampaign , search/filters auth/haspermissionscurrentuser , , search/columns , department/getalldepartment , campaign/getallcurrentzones , orders/cleanordersbyzone orders/getordersbyanypoints ,

116 , orders/getpurchaseorderbyid , tracking/getpurchaseordertrack containers/getcontainersbypurchaseord er , CPI002 cou avera medi error throughp sampler_label nt ge an min max % ut 557 /ot/login.jsp auth/current metrics/getdepartmentsmetrics auth/getpermissionbymodule auth/haspermission campaign/getoperativecampaign

117 106 search/filters auth/haspermissionscurrentuser search/columns department/getalldepartment campaign/getallcurrentzones orders/cleanordersbyzone orders/getordersbyanypoints orders/getpurchaseorderbyid tracking/getpurchaseordertrack containers/getcontainersbypurchaseord er CPI003

118 107 cou avera medi error throughpu sampler_label nt ge an min max % t 197 /ot/login.jsp auth/current metrics/getdepartmentsmetrics auth/getpermissionbymodule auth/haspermission campaign/getoperativecampaign search/filters auth/haspermissionscurrentuser search/columns department/getalldepartment campaign/getallcurrentzones

119 orders/cleanordersbyzone orders/getordersbyanypoints orders/getpurchaseorderbyid tracking/getpurchaseordertrack containers/getcontainersbypurchaseord er CPI004 cou avera medi mi throughpu sampler_label nt ge an n max error% t /ot/login.jsp auth/current metrics/getdepartmentsmetrics

120 auth/getpermissionbymodule auth/haspermission campaign/getoperativecampaign search/filters auth/haspermissionscurrentuser search/columns department/getalldepartment campaign/getallcurrentzones orders/cleanordersbyzone orders/getordersbyanypoints orders/getpurchaseorderbyid tracking/getpurchaseordertrack

121 er containers/getcontainersbypurchaseord CPI005 averag medi mi ma through sampler_label count e an n x error% put 701 /ot/login.jsp auth/current metrics/getdepartmentsmetrics auth/getpermissionbymodule auth/haspermission campaign/getoperativecampaign ,42E+ search/filters auth/haspermissionscurrentuser ,49E

122 search/columns department/getalldepartment campaign/getallcurrentzones orders/cleanordersbyzone orders/getordersbyanypoints orders/getpurchaseorderbyid tracking/getpurchaseordertrack containers/getcontainersbypurchaseo rder CPI006 cou avera medi mi throughp sampler_label nt ge an n max error% ut /ot/login.jsp

123 112 auth/current metrics/getdepartmentsmetrics auth/getpermissionbymodule auth/haspermission campaign/getoperativecampaign search/filters auth/haspermissionscurrentuser search/columns department/getalldepartment campaign/getallcurrentzones orders/cleanordersbyzone orders/getordersbyanypoints

124 113 orders/getpurchaseorderbyid tracking/getpurchaseordertrack containers/getcontainersbypurchaseor der CPI007 cou avera medi error throughp sampler_label nt ge an min max % ut /ot/login.jsp auth/current metrics/getdepartmentsmetrics

125 auth/getpermissionbymodule auth/haspermission campaign/getoperativecampaign documentcontrol/ getdocumentcontrols documentcontrol/ getdocumentcontroltypewith- DocumentsType documentcontrol/ getdocumentcontrol calendar/getzonemanager documentcontrol/getdocument ControlReport documentcontrol/getlistbatchby DocumentControl documentcontrol/getbatch documentcontrol/ getdocumentcontrolvaluesbybat

126 115 ch DocumentControl /getdocumentssincontrol documentcontrol/ registerdocumentcontrol documentcontrol/ getdocumentcontrolvalues CPI008 cou avera medi throughpu sampler_label nt ge an min max error% t /ot/login.jsp auth/current metrics/getdepartmentsmetrics auth/getpermissionbymodule

127 ,23E+1 auth/haspermission campaign/getoperativecampaign documentcontrol/ getdocumentcontrols documentcontrol/ getdocumentcontroltypewith- DocumentsType documentcontrol/ getdocumentcontrol calendar/getzonemanager documentcontrol/getdocument ControlReport documentcontrol/getlistbatchby DocumentControl documentcontrol/getbatch documentcontrol/ getdocumentcontrolvaluesbybat ch DocumentControl

128 117 /getdocumentssincontrol 6 documentcontrol/ registerdocumentcontrol documentcontrol/ getdocumentcontrolvalues CPI009 co aver me ma throughp sampler_label unt age dian min x error% ut /ot/login.jsp auth/current metrics/getdepartmentsm etrics auth/getpermissionbymod ule auth/haspermission campaign/getoperativeca mpaign documentcontrol/

129 118 getdocumentcontrols documentcontrol/ getdocumentcontroltype With-DocumentsType documentcontrol/ getdocumentcontrol calendar/getzonemanager documentcontrol/getdocu ment ControlReport documentcontrol/getlistb atchby DocumentControl documentcontrol/getbatc h documentcontrol/ getdocumentcontrolvalue sbybatch DocumentControl /getdocumentssincontrol documentcontrol/ registerdocumentcontrol

130 119 documentcontrol/ getdocumentcontrolvalue s CPI010 cou avera medi sampler_label nt ge an min max error% throughput 422 /ot/login.jsp auth/current metrics/getdepartmentsmetrics auth/getpermissionbymodule auth/haspermission campaign/getoperativecampaign documentcontrol/ getdocumentcontrols

131 120 documentcontrol/ getdocumentcontroltypewith- DocumentsType documentcontrol/ getdocumentcontrol calendar/getzonemanager documentcontrol/getdocument ControlReport documentcontrol/getlistbatchby DocumentControl documentcontrol/getbatch documentcontrol/ getdocumentcontrolvaluesbybat ch DocumentControl /getdocumentssincontrol documentcontrol/ registerdocumentcontrol documentcontrol/ getdocumentcontrolvalues

132 121 - CPI011 Y CPI012 causaron la caída del servidor por lo que los resultados obtenido no son tomados en cuenta para el análisis - Los siguientes casos: CP013, CPI014, CPI015, CPI016, CPI017, CP018 presentaron resultados muy similares a los anteriores, en este sentido, también hubo una caída por parte del servidor. Esto demostró que la los resultados obtenidos dependen de los módulo de la aplicación al cual el usuario visite. Los resultados, serán analizados comparando los distintos escenarios de prueba para cada tipo de métrica. Los resultados para las diferentes métricas de los escenarios de prueba que incluyeron la medición del Módulo de Monitor y Control de Envió individualmente y en conjunto, fueron muy similares por lo que se demostró una independencia de los módulos en cuanto al desempeño. La primera métrica analizada es el Tiempo de Respuesta. Las siguientes figuras, reflejan los tiempos de respuesta promedio en segundos por el número de usuarios concurrentes de los servicios de los módulos de Monitor, Control de Envío y Reportes correspondientemente.

133 Segundos Segundos Apache JMeter Número de Usuarios Tiempo de Respuesta de los servicios de Monitor Número de Usuarios Tiempo de Respuesta de los servicios de Control de Envío. 122

134 Segundos Número de Usuarios Tiempo de Respuesta de los servicios de Reportes. Los resultados en líneas generales favorecen a los servicios de Monitor, en comparación con los servicios evaluados en los módulos de Control de Envío y Reportes. Los tiempos de respuestas de estos servicios, en promedio no superan los 7 segundos, alcanzando este valor con la mayor carga de usuarios, hasta llegar a los 30 usuarios, la tasa de incremento de los tiempos de respuesta es baja, variando de 1.3 a 2.4 segundos, mientras que, para más de 30 usuarios hasta 100 usuarios, los tiempos de respuestas incrementan más rápido variando desde 2.4 a 6.5 segundos. Para el caso de los servicios del módulo de Control de Envío, las pruebas no se realizaron con una carga mayor a 60 usuarios, debido a las fallas generadas, causando la caída de la aplicación en el servidor de pruebas y originando alteraciones en los resultados. Para este escenario, la velocidad de incremento en las primeras cargas de los tiempos de respuesta no es tan alta, en comparación con la carga de 30 usuarios y 60 usuarios. El tiempo de respuesta promedio varía de 2,8 a 18,8 segundos en comparación de la variación que hay de 30 usuarios a 60 usuarios, que va desde 18,8 a 48,9 segundos. En el caso del Módulo de Reportes, se puede identificar un aumento en la velocidad de crecimiento de los tiempos de respuesta a partir de los 30 usuarios, aumentando notoriamente desde los 15 segundos con 30 usuarios hasta los 57 segundos con 100 usuarios. Lo cual da indicio de un posible cuello de botella al aumentar más de 30 de usuarios. 123

135 Porcentaje La segunda métrica evaluada corresponde a la estabilidad de la aplicación, la cual fue medida de acuerdo al porcentaje de errores de la aplicación. En la siguiente figura se muestra el porcentaje de errores en función de las cargas de usuarios del escenario en que estos valores tienen un cambio a lo largo de las pruebas Número de Usuarios Porcentaje de errores de Control de Envío. La aplicación permanece estable durante la utilización de los servicios de Monitor y Reportes, manteniendo el porcentaje de errores en 0%, sin embargo esto no ocurre para el módulo de Control de Envío, en el que el aumento del porcentaje varía de 0 a 17 % con 1 y 30 usuarios respectivamente, mientras que con 30 y 60 usuarios, varía de 17% a 51,25%. Esto refleja la notoria inestabilidad del sistema, en especial con más de 30 usuarios concurrentes realizando solicitudes en este módulo. Finalmente se evaluaran los resultados obtenidos de la métrica de rendimiento o throughput de la aplicación, representado por la cantidad de solicitudes por unidad de tiempo. Estos resultados se ven reflejados en la siguiente Figura. 124

136 Solicitudes por Minutos Solicitudes por Minuto Solicitudes por segundo Número de Usuarios Tasa de respuestas recibidas en los servicios de Monitor Número Usuarios Tasa de respuestas recibidas en los servicios de Control de Envío Usuarios Tasa de respuestas recibidas en los servicios de Reportes. 125

137 Nuevamente, los resultados son favorables para los servicios del módulo de Monitor permitiendo inclusive representar los resultados obtenidos en función a solicitudes por segundos, a diferencia del resto de los módulos donde se mostraron en solicitudes por minuto. En el Módulo de Monitor, el rendimiento de la aplicación se mantiene en aumento con las distintas cargas de usuario, demostrando que inclusive aumentando el número de usuarios, el sistema puede seguir aumentando el número de solicitudes considerablemente. Por otro lado en la siguiente figura se muestra la cantidad de solicitudes por minuto soportadas por el módulo de Control de Envío a medida que aumentan los usuarios expresando el rendimiento del módulo. En la gráfica, resulta notorio el bajo rendimiento del módulo a medida que aumenta la cantidad de usuarios, las solicitudes por minutos varían desde 12 a 1,7 solicitudes por minutos, aumentando de 1 a 60 usuarios respectivamente. Por último, el módulo de Reportes, muestra la cantidad de solicitudes por minuto soportadas por el módulo de Reportes a medida que aumentan los usuarios expresando el rendimiento del módulo. En la gráfica, resulta notorio el punto en que el número de solicitudes disminuye drásticamente la velocidad de crecimiento. Este punto se alcanza con 30 usuarios concurrentes, lo cual indica en concordancia con los resultados anteriores del módulo, un posible cuello de botella en la aplicación, con la utilización de los servicios del módulo de Reportes. Una vez alcanzados los 30 usuarios el rendimiento de la aplicación se mantiene desde las 56,12 solicitudes por minutos hasta 59,3 solicitudes por minuto. Luego del análisis de estos resultados, es posible identificar los puntos críticos de la aplicación en cuanto al desempeño, facilitando la identificación de los posibles cuellos de botellas en donde realizar una optimización es primordial para lograr cumplir con las expectativas de desempeño esperadas de la aplicación. Identificación de puntos críticos 126

138 Luego de la evaluación anterior, se logró identificar los principales servicios que causan dichos resultados, permitiendo el aislamiento y análisis de los mismos. Los servicios identificados son de lectura, los cuales solicitan y procesan gran volumen de información. El aislamiento de estos servicios, permitió demostrar que el resto de los servicios del módulo no impactan en gran magnitud el desempeño de la aplicación. Para el análisis de estos servicios, se hizo uso de la herramienta JProfiler, que permitió identificar los métodos involucrados en la generación del cuello de botella en el módulo, para lo cual se identificaron las partes del servicio en que se consumían mayor número de recursos. Estos servicios fueron getdocumentcontrols y getdocumentsincontrol ; con la herramienta, se puede observar el alto consumo de recursos presente en la implementación de los mismos, además se identifican los métodos específicos en el cual sucede este alto consumo, los cuales pertenecen a la clase Querier. Finalmente luego de detectar e identificar los métodos causantes de los cuellos de botella del Módulo Control de Envío, es necesario entender la implementación de dichos métodos y evaluar la posibilidad de una re-implementación de los mismos, para eliminar los cuellos de botella. En las siguientes figuras se muestran el porcentaje de consumo de recursos utilizados por dichos servicios, los cuales fueron identificados con la herramienta. 127

139 JProfiler. Servicio con mayor consumo de recursos. JProfiler. Servicio con mayor consumo de recursos. 128

140 Lecciones Aprendidas El entendimiento de negocio y de la arquitectura de la aplicación es de vital importancia para el desarrollo de las pruebas de desempeño, tanto para la correcta elaboración de los scripts de prueba como para determinar las métricas y niveles de carga adecuados que puedan reflejar el verdadero comportamiento de la aplicación. Simular escenarios reales permitirá reflejar en los resultados el comportamiento real esperado en un ambiente de producción. 129

141 Apéndice F-Comparación de Herramientas 130

142 COMPARACIÓN DE HERRAMIENTAS A continuación se presenta una Tabla comparativa entre diferentes herramientas y sus características. Todas las herramientas son de software libre, y son usadas para realizar pruebas de desempeño en aplicaciones Web. Herramienta Característica Plataforma TestMake r Windows / Linux JMter TSung WebLoader Cualquiera que soporte J2EE 1.4 o posterior. 131 Linux Windows GUI Sí Sí No Sí Idioma Servidores/Protocol os que soporta Inglés HTTP, HTTPS, SOAP, POP3, JDBC Español, Inglés, Japonés, Noruego, Alemán Web - HTTP, HTTPS,SOAP, FTP, Database via JDBC, LDAP,RESTful, Mail - SMTP(S), POP3(S) and IMAP(S), MongoDB,Native commands or shell scripts Inglés Web - HTTP, HTTPS,SOAP, FTP, LDAP, WebDAV, Jabber/XMPP, RESTful Inglés HTTP, HTTPS, SOAP, POP3, JDBC, FTP, LDAP Admite Pluggins Sí Sí Sí Sí Tipo de pruebas Desempe Funcionales y ño Desempeño. Desempeño Uso de variables Sí Sí Sí Sí Uso de funciones No Sí No Sí Visualización en tiempo real Monitoreo de Sistema Operativo Monitoreo de Base de Datos Generación de Reportes Funcionales y Desempeño Sí Sí Sí Sí No No No No No No No No Sí Sí Sí Sí

143 Manejador de cookies Sí Sí No No Temporizadores Sí Sí Sí No Prueba de Servicios Web Sí Sí Sí Sí 132

144 Apéndice G Tutorial JMeter 133

145 Apache JMeter Manual del usuario Elaborado por: Isaac Rondón 134

146 Contenido 1 Introducción Conceptos Básicos Funciones Básicas Elementos de un Plan de Pruebas Sub-elementos de las distintas familias Orden de ejecución de los elementos Grabar un Script de Prueba Optimización de la Herramienta Introducción El presente documento describe cuáles son las tareas básicas que se pueden ejecutar en la herramienta Apache JMeter. El contenido del documento integra, los conceptos básicos para el uso de la herramienta, las características elementales de funcionamiento de la aplicación, generalidades y tips para el mejor uso de la herramienta orientados al desempeño de la misma. La elaboración del siguiente instructivo, a pesar de contemplar generalidades de la aplicación, fue enfocada en la realización de pruebas de carga en aplicaciones web basadas en servicios Web de tipo REST. Conceptos Básicos 135

147 La herramienta es un proyecto de Apache, usada como herramienta para pruebas funcionales y de carga para medir y analizar el rendimiento de una variedad de servicios (enfocándose en aplicaciones web). La página de oficial de referencia donde se puede encontrar toda la información sobre la aplicación es: Originalmente, Apache JMeter fue diseñado para realizar pruebas de estrés sobre aplicaciones web (pruebas web clásicas). Sin embargo, hoy en día su arquitectura ha evolucionado, ahora no sólo puede llevar a cabo pruebas en componentes típicos de Internet (HTTP), sino también puede realizar pruebas sobre Bases de Datos, scripts Perl, servlets, objetos java, servidores FTP y prácticamente cualquier medio de los que se pueden encontrar en la red. Para un óptimo desarrollo de pruebas, es necesario tener ciertas nociones funcionales de la aplicación que se va a evaluar. Si esto no es así, las pruebas no serán completas al no saber por ejemplo, si ha devuelto la hoja apropiada a la petición hecha o si nos ha permitido acceder con un login no apropiado. Apache JMeter está diseñado para desarrollar diferentes tipos de pruebas; permitiendo diseñar tanto sencillos teses que soliciten simples páginas web, como complejas secuencias de solicitudes que permitan evaluar el comportamiento de una aplicación o como la capacidad de carga máxima que pueda tener una aplicación en un servidor (pudiendo llegar a satura el servidor). JMeter también permite la ejecución de pruebas distribuidas entre distintos ordenadores, para realizar pruebas de rendimiento. 136

148 Apache JMeter incluye una interfaz gráfica de usuario que facilita el diseño de las pruebas. Esta interfaz gráfica, además de aportar un entorno cómodo de trabajo, también permite guardar y alterar tanto las pruebas desarrolladas como los componentes que lo integran. Gracias a esto se pueden reutilizar las pruebas o módulos de las mismas en el desarrollo de nuevas pruebas. Además de las funcionalidades de prueba antes mencionadas, Apache JMeter también ofrece la posibilidad de activar un Proxy web. Gracias a esto se puede grabar la navegación de un usuario para posteriormente usarla en la generación de una prueba. Entre los servicios y recursos que se pueden probar con la herramienta están: Recursos Dinámicos y estáticos. Protocolos HTTP y HTTPS. Servicios web SOAP y REST. Bases de Datos por JDBC. LDAP. Servidores FTP. JMS (Java Message Service) Protocolos de correo: SMTP(S), POP3(S) y IMAP(S). Conexiones TCP. Entre las ventajas que tiene dicha herramienta, se tienen: Aplicación Open source. Desarrollada en Java. Permite simular fuertes cargas en un servidor. Realizar análisis gráficos de desempeño. Alta documentación en la web. Posee interfaz gráfica: facilita elaboración de planes de prueba. Plugins. Funciones Básicas 137

149 JMeter, permite trabajar en varios modos, pero para trabajar cómodamente la mejor opción es usar el interfaz gráfica. Para iniciar la aplicación, se inicializa en JMeter.bat (situados en el directorio bin de la aplicación) según la plataforma (unix y Windows respectivamente) en la que estemos ejecutando la aplicación. De esta manera accederemos a la interfaz gráfica de JMeter. Todas las incidencias detectadas por el Apache JMeter se escriben en un fichero.log. El nombre del fichero log se define en el fichero jmeter.properties (fichero que se en cuenta en el directorio /bin), por defecto, dicho fichero se llama jmeter.log y se escribe en el directorio desde el que se lanza la aplicación. Una vez se ejecuta el fichero jmeter o el jmeter.bat según la plataforma (unix y Windows respectivamente) en la que se trabaje, la primera pantalla que se presenta es: 138

150 Esta es la pantalla principal de la herramienta. Con una primera visualización, se puede ver que la pantalla tiene un formato similar al típico de las ventanas de Windows y que está dividida en dos partes fácilmente diferenciables. La parte izquierda representa la estructura o representación en árbol del plan de pruebas, mientras que en la parte derecha tendremos la plantilla de edición del elemento que tengamos elegido a la izquierda. La aplicación tiene dos entidades básicas. Por un lado tenemos el Test plan (o plan de pruebas) que representa una prueba y por el otro los elements (o elementos) que representan las diferentes etapas o acciones que usaremos para componer las pruebas. El Apache JMeter basa su funcionamiento en elementos integrados dentro de una estructura de árbol (dentro de un plan de pruebas). Cualquier parte (elemento) del árbol puede ser agregada o guardada de manera independiente, de tal manera que se puede reutilizar elementos en planes de pruebas posteriores. Con esta forma de trabajo el entorno gráfico es apropiado para ver y editar los elementos que componen un plan de prueba (árbol de la izquierda). Otro detalle que se debe tener muy presente, es que el orden en el árbol (orden descendente) determina el orden de ejecución de los elementos dentro de la prueba. En concordancia con esto, para agilizar la configuración del orden de los elementos dentro del árbol, el entrono grafico permite arrastrar (pinchando el elemento oportuno con el botón derecho y no soltando movemos el ratón arrastrando con el elemento) los distintos elementos hasta las posiciones que se consideren oportunas. Al depositar el elemento arrastrado el entorno grafico nos asistirá con un menú para especificar la ubicación exacta. 139

151 Con respecto a los menús del entorno gráfico, decir que cuenta con cinco menús (archivo - file, edición edit, ejecutar -, run, opciones - options y ayuda - help). Los cuales tienen las funcionalidades básicas de manipulación de ficheros y las de funcionalidad de la aplicación. Su uso no entraña ninguna dificultad (las funcionalidades son bastante intuitivas). Para agilizar el manejo de la aplicación, el entorno gráfico incorpora en cada elemento la opción de sacar un menú específico. Para acceder a este menú bastara con posicionarnos sobre el elemento y presionar el botón derecho del ratón. Elementos de un Plan de Pruebas El plan de pruebas es el objeto que representa una prueba, el plan de pruebas se compone de elementos. Estos elementos, según su funcionalidad dentro de las pruebas, los podemos dividir en ocho familias: Thread Group: Número de hilos de ejecución. Samplers: Solicitudes a un servidor. 140

152 Logic Controllers: Comportamiento de las pruebas. Listeners: Datos recopilados por las pruebas. Timers: Controlar los espacios relativos de tiempo. Assertions: Verificación de los datos. Configuration Elements: labores de configuración (en muchos casos valores por defecto). Pre-processor Elements: acción antes de la ejecución de un Sampler. Post-Processor Elements :acción después de la ejecución de un Sampler. Cada una de las familias de elementos está compuesta varios elementos (la única excepción es el grupo de hilos que solo integra un elemento), cada uno de estos elementos realiza una función específica. Los elementos que integran las diferentes familias son los siguientes: Sub-elementos de las distintas familias - Samplers FTP Request HTTP Request JDBC Request Java Request SOAP/XML-RPC Request LDAP Request LDAP Extended Request (ALPHA) WebService(SOAP) Request Access Log Sampler BeanShell Sampler BSF Sampler TCP Sampler JMS Publisher JMS Subscriber JMS Point-to-Point Test Action JUnit Sampler. 141

153 - Configuration Elements HTTP Authorization Manager HTTP Cookie Manager HTTP Proxy Server HTTP Request Defaults FTP Request Defaults JDBC Connection Configuration JDBC SQL Query Defaults Graph Results Spline Visualizer Assertion Results View Results Tree Aggregate Report View Results in Table Simple Data Writer Monitor Results Mail Reader Sampler HTTP Header Manager Login Config Element Simple Config Element LDAP Request Defaults LDAP Extended Request Defaults (ALPHA) Java Request Defaults User Defined Variables TCP Sampler Config CSV Data Set Config JNDI Default Configuration. -Listeners Mailer Visualizer Graph Full Results - Assertions Response Assertion Duration Assertion Size Assertion XML Assertion BeanShell Assertion MD5Hex Assertion HTML Assertion XPath Assertion XML Schema Assertion - Pre Processors HTML Link Parser HTTP URL Re-writing Modifier HTML Parameter Mask 142

154 HTTP User Parameter Modifier User Parameters Counter Gaussian Random Timer Uniform Random Timer Constant Throughput Timer Synchronizing Timer - Logic Controllers Interleave Controller Loop Controller Once Only Controller Simple Controller Post-Processors Regular Expression Extractor Result Status Action Handler Save Responses to a file. Random Controller Recording Controller Module Controller Throughput Controller If Controller Random Order Controller ForEach Controller Transaction Controller Runtime Controller While Controller Switch Controller Include Controller - Timers Constant Timer 143

155 Apache JMeter Para obtener mayor detalle de los mismos, se recomienda hacer uso de la documentación de la aplicación que los describe. Una vez se conocen todos los elementos que se pueden usar en la creación de un plan de pruebas, ya sólo queda empezar a crearlos. Un buen punto de partida, es empezar por los planes descritos en la documentación de la aplicación (Building a Web Test Plan y Building an Advanced Web Test Plan). Orden de ejecución de los elementos La herramienta ejecuta los distintos elementos en el siguiente orden de ejecución: 1. Configuration elements 2. Pre-Processors 3. Timers 4. Sampler 5. Post-Processors 6. Assertions 7. Listeners Grabar un Script de Prueba En la siguiente sección se explicará n los pasos exactos para usar el proxy de JMeter. Cuando se comienza a usar la herramienta, una manera fácil para crear un plan de pruebas es usar el Proxy. Lo que realiza el Proxy es grabar las solicitudes que se envían al servidor Instrucciones para el uso del proxy 1) Iniciar JMter con JMeter.bat en windows y JMeter.sh en unix. 144

156 2) Seleccionar test plan en el árbol. 3) Clic derecho en test plan y añadir un nuevo thread group : add -> thread group. 4) Seleccionar el grupo de hilos creado en el paso anterior. 5) Clic derecho add -> config element -> Http Request Defaults. a. Protocol enter HTTP. b. Server name Introducir el nombre del servidor, por ejemplo: jakarta.apache.org. c. Path Dejar en blanco o colocar el path por defecto de la aplicación. d. Port number introducir el número de Puerto en el que se encuentra la aplicación ejemplo: ) Seleccionar el grupo de hilos creado. 7) Clic derecho add -> logic controller -> Recording controller. 8) Seleccionar workbench. 9) Clic derecho en workbench y añadir el proxy Http: add -> non-test elements -> Http Proxy Server. a. Colocar en target controller la opción Use Recording Controller. b. Select HTTP Request HTTPClient as the sampler type. c. Clic en el botón add en Patterns to include : se creará un espacio en blanco, el cuál será rellenado con la respectiva expresión regular que se desee, la cual indicara que elementos se desean incluir en la grabación. d. Clic en el botón add en Patterns to exclude : se creará un espacio en blanco, el cuál será rellenado con la respectiva expresión regular que se desee, la cual indicara los elementos que se desean excluir en la grabación. Ejemplo: i..*\.png : excluirá los elementos en el formato png. ii..*\.ico : excluirá los elementos en el formato ico. iii..*\.gif : excluirá los elementos en el formato gif. 10) Clic en el botón start : botón que se encuentra al final. 145

157 11) Iniciar el explorador de su preferencia, pero no cerrar JMter. Nota: Asegurarse que los patrones en include y exclude son correctos. A continuación algunos patrones comunes para imagines y tipos de páginas..* - all.*\.png png images.*\.gif gif images.*\.jpg jpeg images.*\.php.*\.jsp.*\.html.*\.htm.*\.js Como un tip general, es una buena idea configurar la página principal para su explorador en una página en blanco, de este modo reducir el número de páginas no deseadas en la grabación. Los siguientes pasos incluyen la configuración del explorador para que use como Proxy el Proxy de JMeter (Los pasos fueron elaborados usando el explorador Mozilla Firefox, sin embargo la configuración de cualquier otro explorador es muy similar). 12) Dela barra de menú, hacer clic en tools -> options. Esto deberá mostrar un conjunto de opciones. 13) Seleccionar la pestaña de Advance. 14) Seleccionar la sub-pestaña Network. 15) Seleccionar el botón settings. a. En la nueva ventana emergente seleccionar Manual proxy configuration. b. Http Proxy Colocar localhost o la dirección ip de su sistema. 146

158 c. Port Colocar 8080 o el puerto deseado. d. Seleccionar la opción Use this proxy server for all protocols. e. Clic en Ok. f. Clic en Ok. 16) Clic en algunos enlaces de la página. 17) Volver la ventana de JMeter y visualizar el resultado de la grabación. Optimización de la Herramienta Para mejorar el rendimiento de la herramienta, se recomienda: Usar la última versión de Jmeter. Usar el modo Non-GUI. <JMETER_HOME>/bin> jmeter -t <Path to Test Plan> -n -l <path to results>/results.jtl Crear reportes DESPUÉS de correr la prueba. Pruebas distribuidas. Usar salidas CSV. Colocar en (jmeter/user).properties la siguientes propiedades: En user.properties # # Summariser - Generate Summary Results configuration. # summariser.name=summary summariser.interval=50 summariser.log=true summariser.out=true 147

159 En jmeter.properties : # # Results file configuration # jmeter.save.saveservice.data_type=false jmeter.save.saveservice.response_message=false jmeter.save.saveservice.subresults=false jmeter.save.saveservice.assertions=false jmeter.save.saveservice.thread_counts=true jmeter.save.saveservice.sample_count=true jmeter.save.saveservice.print_field_names=true Estas propiedades permitirán mejorar el desempeño de la aplicación. 148

160 Apéndice H-Diseños Detallados 149

161 Proyecto: Cliente: Tipo: Order Tracking AVON Mejora Documento Diseño Detallado 150

162 CONTENIDO CONTENIDO Control de Versiones y Cambios Definición Propósito Diseño de Alto Nivel Situación Actual Propuesta de Solución Diseño Detallado Decisiones de Diseño Servicios RESTful Persistencia Interfaz Gráfica Construcción de la Solución Implementación de los servicios Desarrollo de Pruebas Unitarias Aspectos de configuración

163 Control de Versiones y Cambios Versió n Fecha Responsable/Rol Estado Cambios efectuados /10/2013 Isaac Rondón / Developer Borrador Versión Inicial /11/2013 Isaac Rondón / Developer Borrador Agregando Detalle a la solución propuesta para la optimización de los servicios /12/2014 Isaac Rondón / Developer Final Diseño detallado del componente: Zona Descarga Definición Propósito El presente documento engloba las decisiones de diseño tomadas para el desarrollo de una mejora en la implementación de servicios Web; decisiones tanto de alto nivel como diseños detallados de la solución. El documento también expone el comportamiento estático y dinámico de los servicios que se re-implementarán, estos servicios, presentan un nivel crítico en cuanto a desempeño y serán optimizados. Diseño de Alto Nivel En esta etapa se diseña una propuesta de solución luego de evaluar la implementación de los servicios identificados con menor desempeño: getdocumentscontrol y GetDocumentsSinControl. 152

164 4.1 Situación Actual Ambos servicios pertenecen al Módulo de Control de Envío, y son utilizados para listar órdenes registradas previamente, los mismos son de lectura y devuelven un JSON con toda la información solicitada. Los servicios getdocumentscontrol y GetDocumentsSinControl son invocados por las funcionalidades de Listar Controles de Envío y Listar Ordenes sin Control de Envío respectivamente, las cuales: Listar Controles de Envío o Se muestra el listado que contiene los Controles de Envío previamente registrados. o Los Controles de Envío se muestran según su fecha de creación en el sistema, ordenándolos de forma descendente. o Se podrá filtrar por año, campaña, origen, estado, tipo de control de envío, zona y número de control de envío. Listar Órdenes sin Control de Envío. o Se muestra el listado de órdenes que no poseen un control de envío asociado o El listado de órdenes debe mostrar: la campaña, número de pedido, contrato, nombre de la representante y zona. o Se permitirán reasignar una orden a un control de envío existente. o Se permitirá anular y reactivar una orden sin control de envío que no haya sido facturada. o Se permitirá eliminar una orden sin control de envío que no haya sido facturada. o Las órdenes sin control de envío podrán ser filtradas por: zona, contrato y campaña. Las consultas realizadas por los servicios, se realizan haciendo uso del framework Hibernate para la correspondencia de los atributos de la Base de Datos relacional y el modelo de objetos de la aplicación y hacen uso del Lenguaje de Solicitudes de Hibernate, o HQL por sus siglas en inglés. 153

165 Ambos servicios solicitan un alto volumen de datos, los cuales son procesados para presentar solo la información necesaria. Además, ambos listados poseen filtros para parametrizar la información que se quiere mostrar, los cuales realizan la clasificación procesando los datos que fueron almacenados en memoria luego de la primera solicitud a la Base de Datos. El filtrado, permite generar un atajo al resultado deseado basado en algún valor de atributo especificado. Propuesta de Solución. Ante el alto consumo de recursos por parte de los servicios involucrados en el Listado de Controles de Envío y el Listado de Ordenes sin Control de Envío, se propone: Agregar paginación en ambos listados para evitar el alto consumo de recursos. Entendiéndose paginación como la colección de un número definido de registros por página, junto con un mecanismo de navegación para avanzar y retroceder entre las distintas páginas. El filtrado de la información se realizará consultando la información que se desea clasificar directamente en la Base de Datos. Solo se solicitará en la Base de Datos la información requerida para ser mostrada al usuario, evitando solicitar información que no sea necesaria. Hacer el mejor uso del Framework Hibernate para realizar las consultas y técnicas que permitan mejorar el desempeño de la solicitud y disminuir el consumo de recursos. Entre las cuales se plantea el uso del API Criteria de Hibernate y la activación del segundo nivel de caché de Hibernate. Diseño Detallado. En la sección siguiente se detalla la solución implementada para la optimización y reimplementación de los servicios getdocumentscontrol y GetDocumentsSinControl. 154

166 6.1 Decisiones de Diseño Servicios RESTful Ambos servicios consultan una gran cantidad de información, consumiendo un alto nivel de la memoria y procesan toda la información consumiendo además, un gran porcentaje de CPU. Es por esto que se limitará el volumen de información, mostrando ambos listados en varias páginas reduciendo así la carga del servidor. La lógica de negocio en ambos servicios será la misma que se tenía, solo cambiará la forma en que la información es presentada. La paginación en ambos casos no solo reducirá el consumo de los recursos y bajará los tiempos de repuesta sino que también, mejorará la experiencia de usuario permitiendo una mejor navegación para conseguir la información que se desea, evitando que el usuario se deba desplazar por una larga lista de información, así como también se evitará la sobrecarga de información en el explorador, permitiendo una navegación más rápida. Los servicios serán capaces de recibir parámetros de búsqueda para evitar realizar el filtrado de la información del lado del cliente, es decir, si se desea utilizar un filtro para la búsqueda la información será solicitada al servidor con los parámetros de búsqueda correspondiente. En este sentido las consultas serán modificadas para solicitar solo información que será mostrada al usuario, evitando solicitar información que luego de ser procesada quede descartada Para la optimización de estos servicios, también se plantea el uso de otras estructuras de datos que mejoren el desempeño, como por ejemplo el uso de StringBuilder en vez de hacer uso de los objetos tipo String, en aquellos casos que sea posible. El digrama de las clases involucradas en el diseño de la solución, se encuentra acontinuación: 155

167 Persistencia Las consultas serán realizadas con el API de Hibernate Criteria, el cual ofrece una alternativa para la manipulación de objetos contra una clase persistente en particular. Esta interfaz ofrece métodos para la paginación y para el manejo opcional de parámetros de 156

168 búsqueda, enfocados a realizar estas acciones con un buen desempeño. Las tablas involucradas en la solución se reflejan en el modelo de datos presentado a continuación: 157

169 Otra estrategia planteada para mejorar el desempeño de la aplicación, consiste en activar el Caché de Segundo Nivel de Hibernate, el cual está asociado con el objeto Session Factory. Esto nos permite que todo objeto que sea cacheado pueda ser obtenido en 158