Pruebas de Software
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia Introducción
Views 139 Downloads 0 File size 583KB
Recommend stories
- Author / Uploaded
- Christian Camilo Gomez Paez
Citation preview
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Introducción .................................................................................................................................. 5 1. Marco teorico ............................................................................................................................ 6
2
1.1
Pruebas de software .................................................................................................... 6
1.2
Taxonomía de las pruebas en aplicaciones de software. ............................................ 7
1.3
Limitaciones de las pruebas de software..................................................................... 9
1.4
Bases teóricas sobre pruebas de software ................................................................ 10
1.5
Trabajos relacionados y debilidades asociadas ......................................................... 13
1.6
Estándar de evaluación del producto de software: ISO/IEC 9126 ............................. 14
1.7
Modelo de calidad para calidad interna y externa .................................................... 15
Metodología de Pruebas ..................................................................................................... 19 2.4
Logística y planeación. ............................................................................................... 21
2.4.1
Alcance .................................................................................................................. 22
2.4.2
Productos generados............................................................................................. 23
2.5
Diseño. ....................................................................................................................... 23
1.2.1
Alcance .................................................................................................................. 24
1.2.2
Productos generados............................................................................................. 24
2.6
Ejecución. ................................................................................................................... 25
1.2.3
Alcance .................................................................................................................. 25
1.2.4
Productos generados............................................................................................. 26
2.7 1.2.5
Evaluación y seguimiento. ......................................................................................... 26 Alcance .................................................................................................................. 27 Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
1.2.6 2.8
3
Productos generados............................................................................................. 27 Cierre.......................................................................................................................... 27
1.2.7
Alcance .................................................................................................................. 27
1.2.8
Productos generados............................................................................................. 28
Equipo de pruebas .............................................................................................................. 28 3.4
Roles........................................................................................................................... 28
3.5
Responsabilidades por roles ...................................................................................... 28
3.5.1
Líder de proyecto de pruebas del proveedor QA para el IDEAM .......................... 28
3.5.2
Coordinador de pruebas del IDEAM ...................................................................... 29
3.5.3
Ingeniero de desarrollo de aplicativos del IDEAM o terceros. .............................. 29
3.5.4
Lider técnico de aplicativos del IDEAM ................................................................. 29
3.5.5
Ingeniero de pruebas funcionales, técnicas y de seguridad. ................................ 29
3.5.6
Participación de los roles en las etapas de la metodología IDEAM....................... 30
3.5.7
Participación de los roles en la totalidad del proyecto de pruebas. ..................... 31
4 Aplicando la metodología de pruebas IDEAM para la ejecución de factores de carga y stress en aplicaciones Web. .................................................................................................................. 32 3.1
Aplicación de pruebas de carga en aplicaciones Web ............................................... 32
3.1.1
Objetivos................................................................................................................ 32
3.1.2
Descripción general ............................................................................................... 32
3.2
Enfoque de la Prueba de carga .................................................................................. 34
Paso 1 - Identificar los criterios de aceptación de rendimiento ......................................... 35 Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Paso 2 - Identificar los escenarios claves. ........................................................................... 36 Paso 3 - Crear un modelo de carga de trabajo .................................................................... 37 Paso 4 - Identificar los niveles de carga del aplicativo. ....................................................... 38 Paso 5 - Identificar las métricas. ......................................................................................... 38 Paso 6 - Diseño de pruebas específicas............................................................................... 40 Paso 7 - Ejecutar pruebas .................................................................................................... 41 Paso 8 - Analizar los resultados ........................................................................................... 42 3.1.3 3.2
Resumen ................................................................................................................ 42 Aplicación de pruebas de estrés en aplicaciones Web .............................................. 42
3.2.1
Objetivos................................................................................................................ 43
3.2.2
Descripción general ............................................................................................... 43
3.2.3
Ejemplos de condiciones de estrés ....................................................................... 43
3.2.4
Cómo usar este apartado ...................................................................................... 44
3.2.5
Enfoque para la prueba de estrés ......................................................................... 45
Paso 1 - Identificar los Objetivos de la prueba (objetivos identificados) ............................ 47 Paso 2 - Identificar los Escenarios claves ............................................................................ 47 Paso 3 - Identificar la carga de trabajo ................................................................................ 48 Paso 4 - Identificar las métricas .......................................................................................... 49 Paso 5 - Crear Casos de Prueba ........................................................................................... 50 Paso 6 - Simular Carga ......................................................................................................... 51 Paso 7 - Analizar los resultados ........................................................................................... 52 Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
3.2.5
Escenarios usados para la prueba de stress .......................................................... 52
3.2.6
Pruebas de estrés exploratorio ............................................................................. 53
3.2.7
Resumen ................................................................................................................ 54
Glosario ............................................................................................................................... 54
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Introducción Las pruebas de software como parte de los planes de aseguramiento de la calidad ofrecen a los productos de software la posibilidad de identificar y remover los defectos que surgen dentro del proceso productivo. La estandarización por parte de diferentes organismos ofrece diferentes formas de implementar los procesos de pruebas, todos ellos con la característica común de ser genéricos y basados en ciclos de madurez que permiten la medición y optimización del mismo. Los estándares y técnicas de pruebas de software, en general, no presentan un grado de acoplamiento y especificidad mediante el cual el aseguramiento de la calidad del producto sea tenido en cuenta en todas las etapas de desarrollo del software. La metodología adoptada por el IDEAM es un método que permite integrar el área de pruebas al ciclo de desarrollo de software, este hecho permite mejorar el tiempo de pruebas y los costos asociados. Adicionalmente, esta metodología pretende hacer uso de una variedad de tipos de pruebas que le permiten obtener un gran cubrimiento del software bajo prueba con un impacto pequeño en el desarrollo del mismo. Las pruebas de los productos de software enmarcadas en la tendencia competitiva del mercado que en la actualidad se centra en brindar soluciones informáticas con altos estándares de calidad, se han convertido en un mecanismo vital para lograr la satisfacción del cliente. La utilización de herramientas de carga y por ende el aseguramiento de la calidad de los productos de software en términos de fiabilidad y eficiencia marcan las pautas actuales en la construcción de aplicaciones web y por ende en las capacidades de éstas para responder a las necesidades del mundo actual. Las pruebas de carga específicamente, realizadas mediante herramientas que simulan conexiones de usuarios virtuales en un mismo instante del tiempo, permiten encontrar los puntos de quiebre de los aplicativos revelando así problemas de arquitectura o configuración en condiciones de carga de usuarios y de procesos excesivos; las herramientas que permiten realizar las pruebas de carga, sus características y las ventajas comparativas que llevan a una división de las mismas en varias categorías hacen parte del objetivo principal del presente documento. Finalmente se demuestra una tendencia marcada de las empresas productoras de dichas herramientas, que va dirigida a producir aplicaciones integrales que permitan no solo realizar pruebas de carga, si no también a ejecutar monitoreos globales y a aplicar automatización de pruebas funcionales en un mismo entorno, siendo éste último tipo de soluciones de gran ayuda en el ámbito de análisis de resultados y de toma de decisiones justo después de terminar la ejecución de las pruebas. Las pruebas de carga, permiten evaluar el comportamiento de una aplicación de software bajo la influencia transaccional de determinado número de usuarios. En la industria, predecir cómo se comportará una aplicación con niveles de concurrencia específicos es de suma importancia y es por esto que existen herramientas para realizar dichas predicciones. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
1. Marco teórico 1.1
Pruebas de software
La definición de pruebas en el contexto del software tiene diferentes connotaciones que en algunos casos llevan a malas interpretaciones. La definición de pruebas de software de Myers es: “Las pruebas son el proceso de ejecución de un programa con la intensión de encontrar errores” [3]; además, ésta es una parte fundamental del aseguramiento de la calidad del software (QA, por sus siglas en ingles), ya que ayuda a asegurar que el producto cumpla con los requisitos [4][5]; sin embargo las pruebas de software no son QA, tan solo son una parte de ella. La industria del software a través de su historia ha encontrado la necesidad de refinar tres aspectos fundamentales vinculados directamente a su proceso productivo:
Los costos y el tiempo: la dificultad de planear proyectos de software trae consigo problemas en la estimación de tiempos y por ende altos costos asociados; la creación de métricas de software y procesos de planeación eficientes han ayudado a amortiguar el peso de éstos factores en el desarrollo del software.
La calidad: debido a la competitividad del mercado de software la calidad se convierte en un factor determinante a la hora de comercializar los productos. Igualmente, permite disminuir los tiempos de mantenimiento al obtener productos con menor cantidad de errores inyectados y por ende más confiables.
La importancia de las pruebas de software se puede visualizar teniendo como referencia algunos autores:
o
o
o
Las pruebas de software permiten pasar de forma confiable del cómodo ambiente de la ingeniería de software, es decir del controlado ambiente de análisis, diseño y construcción, al exigente mundo real en el cual los entornos de producción someten los productos a todo tipo de fatiga o estrés [6]. Las pruebas de software basadas en componentes permite la reutilización y por ende la reducción de los ciclos de pruebas, lo cual se ve reflejado en la disminución de costos y tiempos [7]. La necesidad de productos de software de alta calidad ha obligado a identificar y cuantificar factores de calidad como: capacidad de uso, capacidad de prueba, capacidad de mantenimiento, capacidad de ser medible, capacidad de ser confiable y a desarrollar practicas de ingeniería que contribuyen a la obtención de productos de alta calidad
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Es importante aclarar la diferencia entre Software QA (Software Quality Assurance) y las pruebas de software (Software Testing); QA se enfoca exclusivamente por todo el proceso de desarrollo de software, las pruebas (testing) se enfocan en el producto. QA presenta los parámetros para pruebas. Las Pruebas apoyan a QA en la consecución de la calidad. Esta diferencia se Grafica como se ve:
1.2
Taxonomía de las pruebas en aplicaciones de software.
Las pruebas de software se tipifican de acuerdo a los aspectos específicos que se van a probar en el software. En la literatura existen diversos autores que proponen taxonomías caracterizadas por su grado de profundidad o expansión. La clasificación propuesta por Burnstein [8] se caracteriza por ser una taxonomía generalizada, enfocada en tipos de pruebas típicos en la industria del software. La clasificación incluye pruebas de: funcionalidad, de rendimiento, de fatiga (estrés), de configuración, de seguridad y de recuperación. Por otro lado existen taxonomías que buscan abarcar un conjunto de aspectos más amplio en las pruebas, lo cual conduce a que éstas contengan una expansión notable en la cantidad de tipos, ofreciendo una visión mas detallada del horizonte de pruebas e influyendo positivamente en todo el proceso de pruebas. Myers [3] clasifica los tipos de pruebas en: de locación, de volumen, de fatiga (estrés), de capacidad de uso, de seguridad, de rendimiento, de almacenamiento, de configuración, de compatibilidad y conversión, de instalación, de capacidad de ser confiable, de recuperación, de utilidad, de documentación, de procedimientos y de aceptación.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Las técnicas de pruebas de software constituyen un mecanismo conceptual mediante el cual se pueden detectar defectos en el software. Si nos remitimos a la taxonomía citada por Young y Taylor [9], se puede observar que se tipifican las técnicas de pruebas de software teniendo en cuenta el ciclo de desarrollo del mismo y su estado (característica estáticas o dinámicas). En la tabla 1 se muestra dicha taxonomía. Estáticas
Dinámicas
Listas de chequeo
Pruebas funcionales
Informales
Pruebas por clases de
Requisitos
datos de entrada Modelamiento Formal Pruebas por clases de datos de salida Análisis estático de diseño
Pruebas basadas en
Diseño
de documentos
diseño
Programación
Información general
Pruebas estructurales
Análisis estático de errores
Pruebas de expresiones
Ejecución simbólica
Pruebas de flujo de datos
Tabla 1 - Clasificación de pruebas de software vs ciclo de desarrollo Existen otras técnicas no clasificadas según su estado; es el caso de las citadas por Burnstein [8] así:
Pruebas de tipo aleatorio: se generan los valores correspondientes a los casos de pruebas de forma aleatoria teniendo en cuenta la especificación de las entradas y en algunos casos las salidas – de forma menos frecuente-. Algunos autores proponen técnicas de muestreo aleatorio Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
con restricciones [10][11] que permiten reducir la población objetivo sin afectar los hallazgos de defectos.
Pruebas de partición de clases equivalentes: La población de entrada se generan a partir del muestreo de conjuntos de valores llamados clases. Las clases seleccionadas deben cubrir todo el dominio de valores de entrada o salida y no deben traslaparse. Aunque existe una dificultad asociada en el diseño de pruebas usando esta técnica, la probabilidad de hallar defectos es bastante alta además elimina la necesidad de realizar pruebas exhaustivas.
Pruebas de valores límite: Partiendo de la prueba de partición de clases equivalentes se puede incorporar en los datos de pruebas, valores limites de las clases particionadas, es decir, valores que se encuentran en el borde de una u otra clase. Cuando se prueban los valores limites, la probabilidad de encontrar defectos aumenta, dado que estos puntos son los más susceptibles de contener errores.
Pruebas de suposición de error: La forma más intuitiva de seleccionar valores de prueba es a través de la suposición de errores la cual se basa en la experiencia del diseñador de pruebas. Esta técnica pretende revelar defectos cuando se elijen valores del dominio de entrada que producen determinados valores del dominio de salida.
Pruebas de transición de estados: Esta técnica se basa en el diagrama de transición de estados construido para los objetos relevantes del sistema. El diagrama de transición de estados presenta los diferentes estados de un objeto y los eventos que generan las transiciones.
Cuando un diseñador de casos de prueba utiliza una técnica de transición de estados tabula las combinaciones posibles que deben ocurrir para que un objeto pase de un estado a otro. Esta información de secuencia de eventos es utilizada por el probador para buscar falencias en los estados y sus transiciones. 1.3
Limitaciones de las pruebas de software
Son diversos los problemas que se encuentran en un proceso de pruebas, algunos de ellos son:
Los probadores desconocen el dominio o los tipos y técnicas a utilizar cuando se requieren pruebas de alto nivel, en general este problema se da al tener personal poco capacitado para la labor.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Los proveedores de pruebas generalmente posponen la labor de pruebas a las etapas finales del ciclo de vida del software, lo que ocasiona problemas por retrasos. Estos retrasos se dan generalmente por que el equipo de pruebas debe adquirir el conocimiento del dominio necesario y diseñar las pruebas, tareas que se pueden realizar de forma transversal al proceso de desarrollo optimizando los recursos disponibles.
En ocasiones los probadores no cuentan con los insumos necesarios para realizar un proceso de pruebas maduro y completo. Estos insumos corresponden a una buena documentación y a un completo y correcto levantamiento de requisitos, que orienten al probador, tanto en la ejecución y desarrollo de las pruebas como en el aprendizaje del dominio.
Muchas organizaciones contemplan su proceso de QA basado en las pruebas de software lo cual trae perjuicios en la calidad de los productos al no incluir procesos como medición, análisis, verificación y validación, todos ellos componentes esenciales de QA.
1.4 Bases teóricas sobre pruebas de software Las pruebas de software constituyen un universo en el mundo de la ingeniería de software y su tarea principal es la de asegurar la calidad de los productos de software. Los casos de prueba constituyen una de las herramientas principales en las pruebas de software, ya que mediante ellos, se formalizan las pruebas, describiendo todo lo que puede implicar llevarlas a cabo y sugiriendo los resultados que ésta debería arrojar. Los casos de prueba y su reutilización juegan un papel fundamental a la hora de hacer que un proceso de pruebas sea eficiente y cumpla con los tiempos que el mercado demanda. Para el diseño de casos de prueba, se deben tener en cuenta técnicas [8] como: de tipo aleatorio, de división de clases equivalentes, de valores límite, de suposición de error y de transición de estados; todas ellas buscan encontrar errores en el aplicativo mediante la elección de un conjunto de datos de entrada que en algunos casos puede ser más eficiente para tal fin que en otros. En las pruebas de software existen diversos enfoques, los cuales son denominados tipos de pruebas; éstos determinan qué características del software se probarán. Cada tipo de prueba en general tiene diferentes niveles de dificultad y en alguna medida los errores que mediante ellas se detectan están relacionados con dicha complejidad; por ejemplo, se esperaría que en un tipo de prueba de capacidad de datos, los errores reportados no sean básicos, debido a que ésta prueba tiende a ser aplicada en instancias muy avanzadas del proceso y por ende dichos errores básicos no deberían existir en la pieza de
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
software en tal momento. Algunas de los tipos de pruebas más comunes son pruebas de: funcionalidad, rendimiento, fatiga, seguridad, configuración, y recuperación. Los tipos de pruebas además de enfocarse a probar cierta funcionalidad del software, tienen una tipificación según la capa en la cual se realiza determinada prueba, veamos las mas importantes en el mercado : •
Pruebas de caja negra: Su objetivo de prueba se enfoca en la parte externa del aplicativo, es decir en las interfaces.
•
Pruebas de caja blanca: Su objetivo de prueba se enfoca en la arquitectura interna del software, es decir en el código fuente y su estructura,
•
Pruebas de caja gris: Tipo de prueba que combina características de niveles externos e internos, es decir, pruebas en donde no solo se tiene en cuenta la interfaz del aplicativo, sino también el código fuente del mismo.
•
Pruebas Funcionales: El objetivo principal de estas en cuento al diseño es comprobar que el software cumpla con lo que el cliente quiere obtener de ella, es decir que lo establecido en los requerimientos se refleje correctamente en la funcionalidad del aplicativo. En cuanto a la construcción del software el objetivo de estas cambian en el sentido que comprueben que las especificaciones del diseño se cumplan, basados en la documentación correspondiente. Aplicando análisis de caja negra observando el comportamiento del aplicativo.
•
Pruebas de rendimiento (performace testing): Su objetivo principal es desarrollar estrategias eficaces para la mejorar el rendimiento del sistema, es decir ddeterminan si la aplicación cumple con las expectativas de tiempo de respuesta bajo las condiciones de operación esperadas, cuantifica los usuarios reales que pueden acceder al sistema y apoyan la detección de los elementos que impiden que se cumplan esas expectativas.. En las pruebas de rendimiento se recopila y analiza información mediante un proceso de medición en el que se recogen datos para predecir cuando los niveles de carga agotará los recursos del sistema. Estas pruebas pueden ser de tres tipos de carga, estrés y escalabilidad, las cuales pueden realizarse en forma conjunta o independiente.
•
Pruebas de carga (load testing): Evalúan el rendimiento del sistema con una carga predefinida. La prueba de carga mide cuánto se tarda un sistema para realizar diversas tareas y funciones del programa bajo condiciones normales o predefinidas. Debido a que el objetivo de las pruebas de carga es determinar si el rendimiento del sistema satisface los requisitos no funcionales de carga del sistema, es pertinente que la configuración mínima y máxima y los niveles de actividad se determine antes de comenzar las pruebas. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
•
Pruebas de estrés (stress testing): Evalúan el comportamiento de los sistemas cuando éstos son llevados más allá de sus límites operacionales (esto puede ser muy por encima de los requisitos no funcionales). Se evalúa las respuestas del sistema y de la aplicación a periodos de mayor volumen de actividad que superen las limitaciones del sistema. El objetivo principal de las pruebas de estrés es determinar si un sistema se bloquea o se recupera en dichas condiciones. Las pruebas de estrés deben ser diseñadas para llevar los límites
•
Pruebas Preventivas: El objetivo principal de estas es comprobar en la fase de definición de los requerimientos tópicos relacionados a estos como la verificación de aspectos a alto nivel de Performance, Seguridad y la eliminación de ambigüedades de artefactos
•
Pruebas de Seguridad: su objetivo principal es minimizar riesgos que generan costos innecesarios en producción por defectos de seguridad en el acceso no detectados en el software durante el proceso de desarrollo, excluyendo el entorno de operaciones (procesos organizacionales, conectividad (funcionalidad de los dispositivos activos de red), servicios complementarios (como servidor web, correo etc) independientes al aplicativo).
El universo de tipos de pruebas está ligado al momento en el ciclo de desarrollo de software en las cuales éstas se aplican y debido a esto y a prácticas generalmente aplicadas para el aseguramiento de la calidad de los productos de software, el flujo de aplicación de pruebas se conforma así: las pruebas de caja blanca son realizadas generalmente en etapas finales de codificación usualmente por el mismo programador y son llamadas pruebas unitarias, posteriormente existen pruebas de caja gris o caja negra que son ejecutadas mediante el concepto de pruebas por pares, estas prueba también son llamadas pruebas de integración; finalmente existen pruebas de caja negra que son realizadas por el equipo de pruebas; en éste último caso, se pueden ejecutar cualquier tipo de prueba dependiendo de las características propias de la pieza de software bajo prueba. Los errores detectados constituyen la salida primaria de las pruebas de software y por esto deben ser analizados con el fin de definir el momento en el cual se inyectaron al producto de software (etapa de requisitos, análisis y diseño, codificación) y determinar su criticidad y complejidad (alta, media, baja y mínima). De ésta manera la solución de los mismos se hace de una forma prioritaria y permite realizar procesos de retroalimentación al interior del equipo de producción con el fin de que el proceso en general madure. La estandarización a nivel internacional hace parte fundamental de las pruebas de software, ya que permite no solo contar con procesos definidos altamente eficientes, sino que también hace que las Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
pruebas cuenten con el apoyo de las técnicas que organismos internacionales han investigado y depurado por años con el fin de mejorar los procesos de aseguramiento de la calidad. Organismos como ISO, IEEE, SEI entre otros han desarrollado modelos de madurez y metodologías que permiten que la calidad de software sea controlada y asegurada; algunos de los más importantes estándares y normativas existentes relacionados con el aseguramiento de la calidad y las pruebas de software son:
1.5
CMMI [1]: con áreas de proceso como QA, verificación y validación directamente orientadas a pruebas de software y aseguramiento de la calidad del producto de software.
ISO/FDIS 9126 [14]: modelo de calidad del producto.
ISO 14598[19]: Evaluación del producto de software.
ISO/IEC 15504[25]: Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.
IEEE [36][12]: Estándar de verificación y validación.
IEEE [38]: Clasificación de errores.
Trabajos relacionados y debilidades asociadas
Los antecedentes en pruebas de software implican organizaciones de renombre internacional como IEEE e ISO, algunos otros modelos de pruebas han sido desarrollados por instituciones y universidades, siendo uno de los pioneros la Universidad de Illinois con su modelo de madurez TMM [43][12]. ISO ha desarrollado una serie de directivas alrededor de la norma ISO/FDIS 9126 e ISO/IEC 14598 que permiten abordar de manera metodológica la recolección de métricas a través de un proceso de pruebas completo que incluye las fases de especificación, diseño y construcción de pruebas de software. Uno de los problemas más generalizados dentro las pruebas de software es la falta de estandarización tanto en metodologías como en terminología y en este aspecto IEEE ha definido glosarios de pruebas, estándares y taxonomías de defectos, además ha incursionado dentro de las metodologías Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
proponiendo buenas prácticas y sugerencias útiles a la hora de implantar o mejorar un proceso de pruebas. De otra parte los resultados de investigaciones dentro del área de calidad han arrojado modelos de pruebas con prácticas genéricas. Tal es el caso de los procesos descritos en CMMI Nivel 3 como Verificación y Validación, los cuales se constituyen como aspectos de apoyo al área de Aseguramiento de la Calidad del proceso y del producto, adicionalmente modelos como TMM permiten enmarcar exclusivamente el proceso de pruebas dentro de un modelo de madurez similar a CMMI y a la vez congruente con este. Estas diferentes metodologías, sugerencias, prácticas y normas, tienen asociadas algunas desventajas inherentes a su constitución, entre ellas se encuentran:
Falta de estandarización a nivel global entre unas y otras. Material escaso o de difícil consecución. Tópicos generales que no contemplan aspectos específicos como ciclo de vida del software. Falta de madurez y de refinamiento en los procesos.
A estas dificultades se suman los obstáculos propios de las compañías desarrolladoras como son:
1.6
Falta de compromiso organizacional. Costos asociados a los procesos de calidad en general.
Estándar de evaluación del producto de software: ISO/IEC 9126
La norma internacional ISO/IEC 9126 proporciona las guías de un modelo de calidad para un producto de software. Esta norma sigue el esquema propuesto por los modelos (McCall, Boehm, etc.) además, retoma alguna de las características planteadas por dichos modelos, pero puntualiza las seis características fundamentales en la evaluación de calidad de un producto de software : Confiabilidad, Funcionalidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad. (Ver Figura 1).
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Figura 1. Modelo de calidad interna y externa NORMA ISO 9126: Las características propuestas por la norma ISO/IEC 9126 indican los aspectos que se deben observar al evaluar un producto de software. 1.7
Modelo de calidad para calidad interna y externa
Esta cláusula define el modelo de calidad para la calidad interna y externa.Este categoriza los atributos de calidad del software en seis características (funcionalidad, confiabilidad, facilidad de uso, eficiencia, mantenibilidad y portabilidad), las cuales se subdividen en subcaracterísticas (Figura 2). Las subcaracterísticas pueden ser medidas por métricas internas o externas.
cal ida d ex terna e interna
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 fu nc ional idad
fiabili da d
A p rop iabilidad
www.ideam.gov.co u sabil idad [email protected] e fi cie nc ia m ant en ibi lida d
A nalizab ilid ad
Co mpr ens ib ilid ad M adu rez
por tab ilid a d
Ad aptab ilid ad Co mpo rtamien to
F acilidad d e
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Figura 2. Modelo de calidad para calidad interna y externa.
A cada una de las características de calidad y subcaracterísticas se le atribuye una definición. Para todas las características y subcaracterísticas, la capacidad del software es determinada por un conjunto de atributos internos, los cuales pueden ser medidos. Ejemplos de métricas internas se pueden consultar en la norma ISO/IEC 9126-3. Las características y subcaracterísticas pueden ser medidas externamente de acuerdo al alcance al que puedan llegar a conseguir las capacidades que provee el software del sistema. Ejemplos de métricas externas se pueden consultar en la norma ISO/IEC 9126-2. •
FUNCIONALIDAD: La capacidad que tiene un producto de software para proveer funciones que satisfacen necesidades establecidas e implícitas, cuando el software es usado bajo condiciones específicas, de manera segura y precisa.
Apropiabilidad: La capacidad que tiene un producto de software para proveer un conjunto de funciones que cumplan tareas específicas y objetivos de usuario.
Exactitud: La capacidad que tiene un producto de software para proveer resultados o efectos correctos o acordados con el grado de precisión requerido.
Interoperabilidad : La capacidad que tiene un producto de software para interactuar con uno o más sistemas específicos.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
•
•
Seguridad: La capacidad que tiene un producto de software para proteger información y datos de tal forma que sistemas o personas no autorizadas no puedan leerlos o modificarlos, y personas o sistemas autorizadas si puedan acceder a ellos.
Cumplimiento: La capacidad que tiene un producto de software para adherir las normas, regulaciones o convenciones a las leyes y prescripciones similares relacionadas al funcionamiento.
CONFIABILIDAD: La capacidad que tiene un producto de software para mantener su nivel de desempeño cuando éste es usado en condiciones específicas.
Madurez : La capacidad que tiene un producto de software para evitar errores como resultado de fallas en el software.
Tolerancia a fallas: La capacidad que tiene un producto de software para mantener un nivel de desempeño especificado en caso de fallas en el software o de que se infrinjan sus enlaces especificados.
Recuperabilidad: La capacidad que tiene un producto de software para restablecer su nivel de desempeño y recuperar los datos directamente afectados en caso de falla.
Cumplimiento: La capacidad que tiene un producto de software para adherir las normas, regulaciones o convenciones a las leyes y prescripciones similares relacionadas a la confiabilidad.
FACILIDAD DE USO: La capacidad que tiene un producto de software para ser entendible, aprendido, utilizable y atractivo al usuario cuando éste es usado en condiciones específicas, además de que tenga facilidad en el aprendizaje de las operaciones de entrada y salida de datos.
Comprensibilidad: La capacidad que tiene un producto de software para hacer que el usuario pueda entender si el software es satisfactorio y adaptable, y cómo éste puede ser usado bajo condiciones de uso y funciones en particular.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
•
•
Facilidad de Aprendizaje: La capacidad que tiene un producto de software para hacer que el usuario aprenda su aplicación.
Operabilidad: La capacidad que tiene un producto de software para hacer que el usuario opere y controle su operación.
Atractividad: La capacidad que tiene un producto de software para ser atractivo al usuario.
Conformidad: Es el cumplimiento de todos los estándares aplicados a lo pertinente de la usabilidad.
Cumplimiento: La capacidad que tiene un producto de software para adherir las normas, regulaciones o convenciones a las leyes y prescripciones similares relacionadas a la facilidad de uso.
EFICIENCIA: La capacidad que tiene un producto de software para proveer el desempeño apropiado relacionado a la cantidad de recursos usados, tanto técnicos como humanos, bajo condiciones determinadas.
Comportamiento en el tiempo: La capacidad que tiene un producto de software para proveer los tiempos de respuesta y procesamiento apropiados, y las tasas de rendimiento en el desempeño de su función, bajo condiciones específicas.
Utilización de Recursos: La capacidad que tiene un producto de software para usar cantidades y tipos de recursos apropiados, cuando el software ejecuta su función en condiciones determinadas.
Cumplimiento: La capacidad que tiene un producto de software para adherir las normas o convenciones relacionadas a la eficiencia.
MANTENIBILIDAD: La capacidad que tiene un producto de software para ser modificado. Modificaciones pueden incluir correcciones, mejoras o adaptación del software a los cambios de entorno, requerimientos y especificaciones funcionales. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
•
2
Analizabilidad: La capacidad que tiene un producto de software para diagnosticar deficiencias o causas de falla, o para identificar partes que se deben modificar.
Facilidad de cambio: La capacidad que tiene un producto de software para hacer que una modificación específica sea implementada.
Estabilidad: La capacidad que tiene un producto de software para evitar efectos inesperados a las modificaciones del software.
Cumplimiento: La capacidad que tiene un producto de software para adherir las normas o convenciones relacionadas a la mantenibilidad.
PORTABILIDAD: La capacidad que tiene un producto de software para ser transferido de un entorno a otro.
Adaptabilidad: La capacidad que tiene un producto de software para adaptarse a diferentes ambientes específicos sin aplicar acciones o medios distintos a los ofrecidos para éste propósito por el software analizado.
Instalabilidad: La capacidad que tiene un producto de software para ser instalado en un ambiente específico.
Coexistencia: La capacidad que tiene un producto de software para coexistir con otro software independiente, en un ambiente común compartiendo recursos comunes.
Reemplazabilidad: La capacidad que tiene un producto de software para ser usado en lugar de otro producto de software específico con el mismo propósito y en el mismo ambiente (de dicho software).
Cumplimiento: La capacidad que tiene un producto de software para adherir las normas o convenciones relacionadas a la portabilidad.
Metodología de Pruebas
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
El IDEAM ha definido una metodología basada en las mejores prácticas y en los estándares establecidos por institutos internacionalmente reconocidos como ISTQB, ISO entre otros. La metodología comprende un proceso de pruebas que contempla cinco etapas a saber: Logística y planeación, Diseño, Ejecución, evaluación y seguimiento y la última fase denominada Cierre a su vez cada una de ellas están conformada por una serie de actividades, el desarrollo de las cuales generan un número determinado de artefactos o entregables (documentos) como productos del cumplimiento total de la etapa ejecutada. El objetivo de la metodología consiste en lograr que los procesos de aseguramiento y control de calidad aplicados transversalmente a cada una de las fases del ciclo de vida del desarrollo de software de los aplicativos misionales del IDEAM, permitan implementar y desarrollar buenas prácticas de ingeniería que contribuyen a la obtención de productos de alta calidad y la satisfacción plena de los usuarios al ver reflejados el cumplimiento de los requerimientos funcionales y no funcionales para los cuales se desarrollo el software, logrando el incremento de la productividad en áreas de Tecnologías de Información (TI) y Comunicaciones (T.I.C). La metodología mediante la aplicación de su estrategia de pruebas busca validar y verificar aspectos claves que permita detectar inconsistencias tempranas que garanticen obtener un proceso no redundante, confiable y efectivo, asegurando la obtención de productos maduros que garantizan la confiabilidad, funcionalidad, usabilidad, eficiencia, mantenibilidad y portabilidad permanente de los mismos, reduciendo los tiempos de desarrollo y los altos costos que le causan a la institución al poner en producción aplicativos con defectos y que no cumplan con los estándares de calidad y con los requerimientos exigidos por el IDEAM. Gráficamente la metodología propuesta se observa como un circuito lógico, que permite aplicar cada una de sus etapas en las fases del ciclo de desarrollo de software de manera iterativa, obteniendo una retroalimentación en cada una de ellas al lograr la corrección continua de sus procesos dadas las modificaciones relacionadas con las validaciones que se desprenden de la ejecución de sus propias actividades.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Figu ra 1 . Metodología de pruebas IDEAM En resumen la metodología IDEAM permite obtener como resultado final: • • • • •
Informe final del resultado del seguimiento de la validación realizada a los aplicativos probados y su entorno tanto para las pruebas técnicas como para las funcionales. Entrega formal de los casos de pruebas para las funcionales y de los scripts para la verificación de las pruebas no funcionales. Identificación de los aspectos que permitan optimizar y/o mejorar el desempeño, mediante la aplicación de buenas prácticas. Documento que certifique que el aplicativo o software tiene una funcionalidad idónea y coherente con las especificaciones funcionales establecidas en el documento de requerimientos. Documento que certifique que el aplicativo o software tiene un buen rendimiento bajo condiciones reales aceptable.
A continuación se detallan cada una de las etapas con sus actividades asociadas . 2.4 Logística y planeación. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
El propósito primordial de esta fase se distribuye en dos objetivos fundamentales, el primero de ellos se relaciona con la infraestructura y/o organización de los recursos involucrados en el proyecto de pruebas, y consiste en que se planee el método y las directrices para llevar a cabo la preparación inicial del proceso de prueba, incluyendo todos los tipos de pruebas (técnicas, funcionales, seguridad) que conformarán el proyecto. En resumen este primer objetivo nos permite la preparación de cada tipo de prueba a efectuarse, de tal manera que contempla el desarrollo de las actividades tales como: • • • • •
Configuración de la herramienta de gestión de las pruebas para el registro, control y seguimiento de las mismas. Configuración mínima de los equipos. Configuración del ambiente de pruebas relacionado con el sistema operativo, herramientas, canales, dispositivos, usuarios, permisos de acceso, aplicativos, etc. Documentos oportunos y actualizados. Recurso humano involucrado en el proyecto de pruebas.
El segundo objetivo prevé la planeación del proyecto de pruebas en el cual se expone el método, las actividades, estructuras y las directrices para desarrollar el proceso de planeación de pruebas de software, permitiendo la obtención de una adecuada planeación de la estrategia y la gestión del proyecto de pruebas que se vaya a ejecutar. Este segundo objetivo contempla el desarrollo de las actividades tales como: • • • • •
2.4.1
Determinar el alcance y los riesgos de la prueba. Identificar los objetivos de las pruebas y el criterio de finalización de pruebas. Determinar el enfoque: Técnicas de pruebas, cobertura de pruebas, equipo de pruebas. Implementar el método de pruebas/estrategia de pruebas, planificación del tiempo disponible para las actividades a seguir. Adquirir/obtener y programar recursos requeridos por las pruebas: personal, entorno de pruebas, herramientas, presupuesto de pruebas.
Alcance
El alcance de la etapa de logística y planeación va desde el inicio del proyecto de pruebas hasta asegurar la disponibilidad de todo recurso tanto humano como de equipamiento para dar inicio al proyecto de pruebas que pretende implementarse. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
2.4.2
Productos generados.
La finalización del proceso de planeación, se obtiene cuando se genere el plan de pruebas y el cronograma de aseguramiento de calidad y cuando se hayan aprobado por el comité de cambios. •
• • • • • • •
Documento de la ficha técnica describiendo las características de software, hardware, comunicaciones, arquitectura de software y arquitectura de red especificas para las pruebas no funcionales. Documento de solicitud de creación del proyecto en la herramienta de gestión para el mismo. Documento de estimación de tiempos. Documento del plan de pruebas específico para cada tipo de Prueba, en este se contempla la lógica del negocio del aplicativo. Documento de estrategia de las pruebas para cada tipo de prueba: Básicamente se constituye en el documento maestro de casos. Cronograma del proyecto por tipo de prueba. Informe de cierre. Documento carta de entrega formal del proyecto.
2.5 Diseño. El propósito primordial de esta etapa consiste en identificar, describir, generar y afinar los test definidos para cada tipo de prueba sea esta funcional, técnica (no funcional) y de seguridad, siguiendo los lineamientos dados en la etapa de Logística y Planeación y por la metodología de pruebas. Es en esta etapa donde se afina y aprueba la cantidad final de los recursos para el proceso de pruebas, relacionados con tiempos, fechas pactadas, tipo y número de recursos humanos, validación y construcción de scripts de automatización, escenarios críticos de la prueba y con base a los cuales se define el diseño de la estructura de los test y scripts y su cobertura, de tal manera que cubra todos los requisitos validando si el producto los satisface en su totalidad. Esta etapa comprende el desarrollo de las siguientes actividades: •
Revisión de las bases de las pruebas tales como arquitectura del sistema (análisis), diseño e interfaces. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
• •
• • •
Identificar las condiciones de prueba específicas y los datos de pruebas necesarios, evaluando la disponibilidad de los datos de pruebas y/o la viabilidad de generarlos. Diseño de pruebas / casos de pruebas, donde se crean los casos de pruebas lógicos (con datos de pruebas sin valores específicos) y establecer un orden de prioridad para los mismos. Definición de los casos de pruebas positivos que permitan comprobar la funcionalidad y los caos de pruebas negativos que permitan comprobar situaciones en las que se debe realizar un tratamiento de errores. Realizar análisis de la testabilidad. Ajuste del cronograma según el afinamiento de los recursos y del ajuste del diseño. Organización del entorno de pruebas, en la que se contempla: o o o o
•
Infraestructura de pruebas y herramientas de pruebas (si fuera necesario) o o
1.2.1
La disponibilidad (exclusiva) del entorno de pruebas, Ventanas de tiempo, etc. Definición del modo de operación del entorno de pruebas, incluida la administración de los usuarios. Carga de datos de pruebas y parámetros del sistema. Conexión del entorno de pruebas con los sistemas adyacentes.
Procesos, procedimientos y responsabilidades. Elección, suministro, instalación y operación de herramientas de pruebas.
Alcance
Se aplica a todos los proyectos de pruebas que se implementen, comienza posterior a la aprobación del plan de pruebas generado en la etapa de Logística y planeación y culmina al diseñarse los test y los scripts que se decidió implementar para el proyecto determinado.
1.2.2
Productos generados.
Cuando al menos un requisito este cubierto por los scripts y test de pruebas planeados y estos se encuentren completos y tengan definidos sus procedimientos de prueba y Sets de dato, se dice que entonces la etapa de diseño de los casos de prueba se ha completado. Con la culminación del proceso del diseño se generan los siguientes entregables: • •
Documento de casos de pruebas. Documento de Informe de avance. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
• • • •
Documento del diseño y construcción de matrices de requerimientos. Documento de Identificación de herramientas automáticas apropiadas. Scripts específicamente para las pruebas no funcionales o técnicas. Documento de cobertura de los casos de pruebas del proyecto.
2.6 Ejecución. El propósito primordial de esta etapa consiste en garantizar un adecuado cumplimiento de la estrategia de pruebas acorde al alcance establecido en la etapa de logística y planeación y a los test (casos de prueba) diseñados para cada tipo de servicio asociada a un proyecto de pruebas. Específicamente en lo relacionado con las pruebas no funcionales, posterior a establecer el ambiente se pruebas, comienza la ejecución de los scripts bajo los parámetros establecidos para los tipos. En ésta etapa se lanzan las diferentes iteraciones de prueba tantas como el testeador lo considere para medir el comportamiento del aplicativo, se registran los datos obtenidos tras la ejecución de cada iteración, se analiza la información y se genera un informe o registro de defectos en la herramienta de gestión del proyecto de pruebas, estos serán tenidos en cuenta en la última etapa de seguimiento. Esta etapa comprende el desarrollo de las siguientes actividades: • • • •
• • •
Desarrollo y asignación de un orden de prioridades a los casos de pruebas tomando en cuenta la planificación. Creación de guiones o scripts de automatización de pruebas si fuera necesario. Configuración del entorno de pruebas. Ejecutar la prueba de humo (Smok test), consiste en un grupo de casos de prueba para establecer la estabilidad del sistema y que todas las funcionalidades mayores están presentes y trabajan bajo condiciones normales y verificando que la versión o release es estable para continuar con el resto de las pruebas. Ejecución de pruebas (manual o automática - scripts) : seguimiento de secuencia de pruebas establecidas en el plan de pruebas. Registro y análisis de los resultados de pruebas. Reiteración de pruebas (“retest”)/Pruebas de regresión parcial y total.
1.2.3
Alcance
El ciclo de esta etapa inicia desde la primera liberación del software para ser sometido a pruebas, hasta lograr que el producto sea estable en sus características no funcionales y funcionales, recomendándose realizar un proyecto piloto antes de ser plenamente puesto en ambiente de producción. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
1.2.4
Productos generados.
Con la culminación del proceso del diseño se generan los siguientes entregables: • • • • • • •
Documento de Casos de pruebas. Documento de Informe de avance. Reporte de defectos detectados. Registro de las pruebas en la herramienta para la gestión del proyecto de pruebas. Documento de ejecución de los casos de pruebas. Carta de finalización o certificación del producto. Informe de Cierre
2.7 Evaluación y seguimiento. El propósito primordial de esta etapa consiste en el análisis de defectos y la evaluación de los criterios de salida y los resultados de las pruebas ejecutadas posibilitando la comprensión de la optima calidad del producto en sus características funcionales y técnicas y del proceso mismo, para lo cual facilita una herramienta detallada de seguimiento que define las tareas que han de realizarse para retroalimentar el proceso de pruebas con posibles problemas que se detecten, al usar el software. Dentro de los eventos considerados para la evaluación y seguimientos se tienen en cuenta las pruebas de aceptación, pilotos de pruebas, y cualquier otro suceso que se presente en el cliente con el software que se ha probado. Lo anterior permite obtener indicadores de calidad, medir si los criterios de completitud de los test se culminaron exitosamente o si por el contrario se detectaron defectos o se canceló la ejecución de casos de pruebas de tal manera que se pueda concluir si hubo una culminación normal o anormal de la ejecución de pruebas funcionales o técnicas. Para ello se evalúa toda la información recolectada con el objetivo de encontrar las causas de las fallas o por el contrario dar las recomendaciones para proyectos futuros. Esta etapa comprende el desarrollo de las siguientes actividades: • • •
Evaluación de la ejecución de pruebas con respecto a los objetivos establecidos. Evaluación de los registros de pruebas mediante la realización detallada de un resumen de actividades de pruebas, resultados de las mismas, y la comunicación de los criterios de salida. Proporcionar información con el objeto de permitir la decisión de si se han de realizar pruebas adicionales.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
1.2.5
Alcance
Esta etapa comienza una vez se culmine con la ejecución de todos los test planeados y diseñados y termina cunado se da el visto bueno del producto por parte del probador.
1.2.6
Productos generados.
Con la culminación del proceso del diseño se generan los siguientes entregables: • • •
Documento de registro de resultado de pruebas. Documento de evaluación y resumen de pruebas. Documento de certificación del producto probado.
2.8 Cierre. El propósito primordial de esta etapa consiste en la aplicación y desarrollo de todas las actividades que se deben tener en cuenta para cumplir con los requisitos de entrega formal del proyecto, se entiende que un proyecto de prueba se da por finalizado cuando cada uno de los tipos de pruebas que le constituyen se han culminado satisfactoriamente. Esta etapa comprende el desarrollo de las siguientes actividades: • • • • • •
Recolectar datos de las actividades del proceso de pruebas finalizadas con el objetivo de consolidar la experiencia, producto de las pruebas, hechos y resultados (valores). Cierre de los informes de incidencia o la generación de solicitudes e cambios para cualquier punto que permaneciera abierto. Comprobar que entregables planificados han sido entregados y probados. Documentar la aceptación del sistema. Finalizar y archivar los productos de las pruebas, el entorno de las pruebas y la infraestructura de las pruebas para posteriores usos, transferencia al entorno de operaciones. Analizar las lecciones aprendidas de las experiencias para los proyectos futuros.
1.2.7
Alcance
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Esta etapa comienza una vez se culmine con la ejecución del proyecto de pruebas y termina cuando se entrega toda la documentación relacionada con el proyecto y se convoca para ello una reunión de cierre con los stakeholders (interesados).
1.2.8
Productos generados.
Con la culminación del proceso del diseño se generan los siguientes entregables: • 3
Documento de cierre o de entrega formal del producto.
Equipo de pruebas Este apartado detalla el rol de cada integrante del equipo de pruebas y define las responsabilidades de cada uno así como la carga de participación de cada uno de ellos por cada etapa contemplada en la metodología de pruebas del IDEAM.
3.4 Roles • • • • •
Líder de proyecto de pruebas del proveedor QA para el IDEAM Coordinador de pruebas del IDEAM Casa de desarrollo o desarrollador de aplicativos del IDEAM. Lider técnico de aplicativos del IDEAM Ingeniero de pruebas funcionales, técnicas y de seguridad.
3.5 Responsabilidades por roles
3.5.1
Líder de proyecto de pruebas del proveedor QA para el IDEAM Es el canal formal de comunicación entre el coordinador de pruebas del IDEAM y los analistas del proyecto. Es quien realiza reuniones de seguimiento, nivelaciones, revisa documentación y asesora con respeto al ensamble de la metodología propia del IDEAM con la de su compañía de QA para sincronizar los procesos de pruebas procurando el éxito en el logro y cumplimiento de los requerimientos dados por el IDEAM, y trata los temas complejos del proyecto. Otras actividades propias de su quehacer son: o o o o
Realizar la coordinación administrativa y técnica del equipo de Ingenieros de Pruebas. Definir los criterios de aceptación para las pruebas. Retroalimentar al IDEAM, del estado de avance del proceso de pruebas de software. Incorporación de las técnicas de diseño de pruebas que permita mejorar la eficiencia y confiabilidad del proceso y el reporte de las no conformidades del sistema.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
3.5.2
Coordinador de pruebas del IDEAM Profesional encargado de ejecutar actividades propias a los interese del IDEAM con el objeto de satisfacer los objetivos definido por el instituto para mejorar la productividad y la calidad de los productos misionales, entre sus tareas específicas se distinguen las siguientes: o o o
3.5.3
Hacer seguimiento del proyecto verificando que la empresa proveedora del servicio de pruebas cumpla con los acuerdos de niveles de servicio pactados al inicio del proyecto. Sugerir cambios o mejoras a la forma en la cual se está llevando el proyecto. Garantizar la disponibilidad de los recursos técnicos y tecnológicos que serán requeridos por el equipo de la compañía proveedora de QA para ejecutar exitosamente el proceso de aseguramiento de calidad.
Ingeniero de desarrollo de aplicativos del IDEAM o terceros. Es el profesional que se encarga de crear un producto de software que implemente todos los requisitos (funcionales y técnicos) establecidos por el IDEAM, además de corregir oportunamente las incidencias o defectos reportadas por el equipo de pruebas técnicas y su pronta implementación poniendo a disposición nuevas versiones del software que las contemplen para ser sometidas nuevamente al proceso de pruebas, entre otras actividades se destacan : o o o o o o
3.5.4
Implementar requisitos. Desarrollar estructuras. Desarrollar el software y crear un producto a satisfacción. Resolver cualquier duda o inquietud funcional generada por el equipo de pruebas técnicas. Implementar nuevas mejoras solicitadas. Crear la documentación técnica y de manejo del producto.
Lider técnico de aplicativos del IDEAM
Profesional con sólidos conocimientos en las características técnicas y tecnológicas del aplicativo misional del IDEAM, el cual asesora a los usuarios finales del aplicativo en su optimización y traduce las necesidades de estos últimos en requerimientos funcionales y técnicos, los cuales son transmitidos al grupo de desarrollo para su implementación o mejora. Entre las actividades realcionadas con el proceso de pruebas se ocupa de : o o o
3.5.5
Facilitar y proveer a la compañía de QA la información técnica necesaria para realizar una ejecución exitosa del proceso de pruebas. Garantizar la disponibilidad de la infraestructura requerida para la ejecución del proceso. Resolver cualquier duda o inquietud técnica relacionada con el aplicativo y que sea formulada por el equipo de pruebas de la compañía de QA.
Ingeniero de pruebas funcionales, técnicas y de seguridad. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Profesionales expertos en las metodologías de los diferentes tipos de pruebas definidos por la compañía proveedora de QA, con experiencia en planeación, diseño y ejecución de pruebas con el objetivo de encontrar defectos y dar si es posible recomendaciones de mejoras al aplicativo. Entre otras actividades a realizar se encuentran: o o o o o o o o
Planificar actividades de pruebas. Definir la estrategia de pruebas adecuada para los diferentes componentes del sistema de información. Construir los casos de pruebas (test) según el tipo de pueba a implementar. Construir los scripts para las pruebas técnicas. Ejecutar las pruebas. Encontrar errores y registrarlos para su evaluación y seguimiento. Recolectar los resultados de las pruebas. Conocer herramientas de gestión, como para la realización de las pruebas
Dentro de los probadores o tester existe una especie de subespecialización como son los ingenieros de pruebas, ingeniero de automatización de pruebas, ingeniero de performance, ingeniero experto en pruebas de la etapa de diseño. 3.5.6
Participación de los roles en las etapas de la metodología IDEAM. ROL
ETAPAS METODOLOGIA DE PRUEBAS IDEAM Lógística y planeaci ón
Diseño
Ejecución.
Evaluación y seguimiento
Cierre
Líder de proyecto de pruebas del proveedor QA para el IDEAM
40%
10%
10%
10%
10%
Ingeniero de pruebas funcionales, técnicas y de seguridad
100%
100%
100%
100%
100%
Coordinador de pruebas del IDEAM
70%
20%
10%
40%
10%
Ingeniero de desarrollo de aplicativos del IDEAM o
30%
20%
10%
10%
5%
%
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
terceros Lider técnico de aplicativos del IDEAM
3.5.7
70%
20%
10%
10%
5%
Participación de los roles en la totalidad del proyecto de pruebas.
RECURSOS
OBLIGACIONES CONTRACTUALES QUE APOYA
DEDICACIÓN
Líder de proyecto de pruebas del proveedor QA para el IDEAM.
Es el canal formal de comunicación entre el coordinador de pruebas del IDEAM y los analistas del proyecto. Es quien realiza reuniones de seguimiento, nivelaciones, revisa documentación y asesora con respeto al ensamble de la metodología propia del IDEAM con la de su compañía de QA para sincronizar los procesos de pruebas procurando el éxito en el logro y cumplimiento de los requerimientos dados por el IDEAM, y trata los temas complejos del proyecto.
El Líder de proyecto de pruebas del proveedor QA para el IDEAM deberá contar con una dedicación del 10 % de tiempo.
Ingeniero de pruebas funcionales, técnicas y de seguridad
Profesionales expertos en las metodologías de los diferentes tipos de pruebas definidos por la compañía proveedora de QA, con experiencia en planeación, diseño y ejecución de pruebas con el objetivo de encontrar defectos y dar si es posible recomendaciones de mejoras al aplicativo.
El Ingeniero de pruebas funcionales, técnicas y de seguridad deberá contar con una dedicación del 100 % de tiempo.
Coordinador de pruebas del IDEAM
Profesional encargado de ejecutar actividades propias a los interese del IDEAM con el objeto de satisfacer los objetivos definido por el instituto para mejorar la productividad y la calidad de los productos misionales.
El Ingeniero de pruebas funcionales, técnicas y de seguridad deberá contar con una dedicación del 70 % de tiempo.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Ingeniero de desarrollo de aplicativos del IDEAM o terceros
Es el profesional que se encarga de crear un producto de software que implemente todos los requisitos (funcionales y técnicos) establecidos por el IDEAM, además de corregir oportunamente las incidencias o defectos reportadas por el equipo de pruebas técnicas y su pronta implementación poniendo a disposición nuevas versiones del software que las contemplen para ser sometidas nuevamente al proceso de pruebas.
El Ingeniero de pruebas funcionales, técnicas y de seguridad deberá contar con una dedicación del 70 % de tiempo.
Lider técnico de aplicativos del IDEAM
Profesional con sólidos conocimientos en las características técnicas y tecnológicas del aplicativo misional del IDEAM, el cual asesora a los usuarios finales del aplicativo en su optimización y traduce las necesidades de estos últimos en requerimientos funcionales y técnicos, los cuales son transmitidos al grupo de desarrollo para su implementación o mejora.
El Ingeniero de pruebas funcionales, técnicas y de seguridad deberá contar con una dedicación del 70 % de tiempo.
4
Aplicando la metodología de pruebas IDEAM para la ejecución de factores de carga y stress en aplicaciones Web.
3.1 Aplicación de pruebas de carga en aplicaciones Web 3.1.1
3.1.2
Objetivos Comprender los conceptos claves de las pruebas de carga. Aprender como es una prueba de carga de una aplicación Web.
Descripción general
En esta sección se pretende plantear y explicar la aplicación de la metodología del IDEAM para hacer una prueba de carga de una aplicación Web. Las Pruebas de carga ayudan a identificar la capacidad máxima de funcionamiento de una aplicación y los cuellos de botella que podrían interferir con su funcionamiento a plena capacidad. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
El enfoque básico de la metodología IDEAM anteriormente descrita para la realización de pruebas de carga en una aplicación Web es: 1. Identificar los escenarios de desempeño o rendimiento crítico. 2. Identificar el perfil de carga de trabajo para la distribución de toda la carga entre los escenarios clave. 3. Identificar y ordenar las métricas que desea reunir a fin de verificarlas contra sus objetivos de rendimiento. 4. Diseñar pruebas para simular la carga. 5. Utilice las herramientas para implementar la carga de acuerdo a las pruebas diseñadas, y la captura de las métricas. 6.
Analizar
los
datos
de
las
métricas
capturadas
durante
las
pruebas.
Mediante un proceso iterativo de prueba, estos pasos ayudan a alcanzar los objetivos de rendimiento. Hay muchas razones para la prueba de carga en la aplicación Web. El tipo más básico de la prueba de carga se utiliza para determinar el comportamiento de la aplicación Web en circunstancias normales y prevé las condiciones de carga máxima. Al comenzar las pruebas de carga, se recomienda comenzar con un pequeño número de usuarios virtuales y luego aumentar gradualmente la carga de normal a alta. A continuación, puede observar cómo la aplicación se ejecuta durante esta condición aumentando gradualmente la carga. Finalmente, fije un límite para los objetivos de rendimiento establecidos. Por ejemplo, continuar aumentando la carga hasta que la utilización del procesador del servidor alcance el 75%, o cuando el tiempo de respuesta del usuario final es superior a 8 segundos. 3.1.2
Cómo usar esta sección
Utilice esta sección para entender los conceptos claves de las pruebas de carga y los pasos implicados en la prueba de carga de aplicaciones Web. Para obtener el máximo beneficio de este apartado: • Utilizar las secciones de "entrada" y "Salida" para comprender los elementos fundamentales de la prueba de carga de Aplicaciones Web y los resultados clave de hacerlo. • Utilice la sección "Enfoque de la Prueba de carga" para obtener una visión general del enfoque de la prueba de carga de una aplicación Web, y como guía de referencia rápida para usted y su equipo. • Utilice los distintos pasos de las secciones para entender los detalles de cada paso que participan en la prueba de carga de una aplicación Web. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
3.1.2.1 Entrada (Input) Los siguientes son insumos útiles para la prueba de carga de una aplicación Web: •Rendimiento de los escenarios de uso crítico. •Los modelos de carga de trabajo. •los criterios de aceptación de rendimiento. •Las métricas de rendimiento asociadas con los criterios de aceptación. •Entrevista de retroalimentación con el diseñador o desarrollador de la aplicación Web. •Entrevista de retroalimentación con los usuarios finales de la aplicación. •Entrevista de retroalimentación con el personal de operaciones que van a mantener y administrar la aplicación. 3.1.2.2 Salida (Output) Los principales resultados que las pruebas de carga ayudan a obtener son: • Actualización de los planes de prueba y los diseños de casos de prueba para las pruebas de carga y rendimiento (performance). • Diversas medidas de desempeño (performance), tales como rendimiento, tiempo de respuesta, y la utilización de recursos. • Posibles cuellos de botella que deben ser analizadas en la fase de pruebas de caja blanca. • El comportamiento de la aplicación en diferentes niveles de carga. 3.2 Enfoque de la Prueba de carga Los siguientes pasos están involucrados en la prueba de carga de una aplicación Web: 1. 2. 3. 4. 5. 6. 7. 8.
Paso1-Identificar los criterios de aceptación de rendimiento. Paso2-Identificar los escenarios claves. Paso3-Crear un modelo de carga de trabajo Paso4-Identificar los niveles de carga del aplicativo. Paso5-Identificar las métricas. Paso6-Diseño de pruebas específicas. Paso7-Ejecutar las pruebas. Paso8-Analizar los resultados.
Estos pasos se representan gráficamente a continuación. Las secciones siguientes discuten cada paso en Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
detalle.
Figura 1 Pasos de las Pruebas de carga.
Paso 1 - Identificar los criterios de aceptación de rendimiento Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Identificar los criterios de aceptación de rendimiento es muy valioso cuando se inicia en la etapa temprana del ciclo de vida de desarrollo de la aplicación. Con frecuencia es útil registrar los criterios de aceptación para su aplicación y guardarlos en un lugar y un formato que estén disponibles como entradas para todo el equipo (de pruebas y de informática) para su revisión y comentarios. Los criterios suelen ser determinados por el equilibrio de su negocio, industria, tecnología, competencia y necesidades o requerimientos de los usuarios. Los objetivos de la prueba con frecuencia incluyen lo siguiente: • Tiempo de respuesta. Por ejemplo, el catálogo de productos debe ser exhibido en menos de 3 segundos. • Producción. Por ejemplo, el sistema debe soportar 100 transacciones por segundo. • Utilización de los recursos. Un aspecto que frecuentemente se pasa por alto es la cantidad de recursos que su aplicación está consumiendo, en términos de procesador, memoria, entrada y salida (I/O) de disco, y redes de I/O. • Carga máxima del usuario. Este objetivo de prueba determina cuántos usuarios pueden funcionar en una configuración de hardware específico. • Métricas de negocios relacionados. Este objetivo se mapea al volumen del negocio en los valores normales y máximos, por ejemplo, el número de pedidos o llamadas de asistencia manejados en un momento dado.
Paso 2 - Identificar los escenarios claves. Los escenarios son las trayectorias anticipadas del usuario que incorporan generalmente actividades de uso múltiple. Los escenarios clave son aquellos para los cuales se tienen objetivos específicos de rendimiento, los considerados de alto riesgo, los utilizados con más frecuencia, o los que tienen un impacto significativo en el rendimiento. Pasos
básicos
para
la
identificación
de
los
escenarios
clave.
1. Identificar todos los escenarios para una aplicación Web. Por ejemplo, incluso la aplicación más básica de comercio electrónico debe soportar los siguientes escenarios de usuario:
Ver (browser) el catálogo. Búsqueda de un producto. Ubicar una orden. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
2. Identificar las actividades involucradas en cada uno de los escenarios. Por ejemplo, "Ubicar una Orden " un escenario incluirá las siguientes actividades:
Inicie la sesión en la aplicación (Log on). navegar por el catálogo de productos. Búsqueda de un producto específico. Añadir elementos a la cesta de la compra. Validar datos de la tarjeta de crédito y realizar un pedido.
3. Identificar los escenarios que se ejecutan con mayor frecuencia o con mayor consumo de recursos; Estos serán los escenarios claves utilizados para las pruebas de carga. Por ejemplo, en una aplicación de comercio electrónico, navegar en un catálogo puede ser el escenario que se ejecuta con mayor frecuencia, mientras que la ubicación de un pedido puede ser el escenario que consume más recursos, ya que accede a la base de datos.
Los escenarios ejecutados con mayor frecuencia por una aplicación Web existente, pueden ser determinados mediante el examen de los archivos de registro (Log). Los escenarios con mayor frecuencia para una nueva aplicación Web, se pueden obtener de la investigación de mercado, de datos históricos, de las tendencias del mercado, y así sucesivamente. Los escenarios que consumen más recursos se pueden identificar mediante el uso de documentos de diseño o la implementación del código actual. Los recursos principales son: o Procesador o Memoria o DiskI/O o Red I/O
Una vez que han sido identificados, se usarán estos escenarios claves para crear perfiles de carga de trabajo y diseñar pruebas de carga. Paso 3 - Crear un modelo de carga de trabajo Al momento de definir la distribución de la carga de trabajo, considere los siguientes puntos claves para determinar las características de los escenarios de usuario: • Un escenario de usuario se define como una ruta de navegación, incluidos los pasos intermedios o actividades, adoptadas por el usuario para completar una tarea. Esto también puede ser pensado como una sesión de usuario. • Un usuario normalmente pausa entre páginas durante una sesión. Esto se conoce como retraso de usuario o tiempo de reflexión. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
• Una sesión tendrá una duración promedio cuando es vista por múltiples usuarios. Es importante tener esto en cuenta a la hora de definir los niveles de carga que se traducirán en uso simultáneo o concurrente, en usuarios traslapados, o las sesiones de usuario por unidad de tiempo. • No todos los escenarios pueden ser ejecutados por un nuevo usuario, un usuario recurrente, o cualquiera, hay que saber que usuarios principales espera y someterlos a prueba en consecuencia.
Paso 4 - Identificar los niveles de carga del aplicativo. Identificar los niveles de carga que se aplicarán a las distribuciones de la carga de trabajo identificadas en el paso anterior. El propósito de identificar los niveles de carga del aplicativo es garantizar que las pruebas pueden utilizarse para predecir o comparar una variedad de condiciones de carga en producción. Las siguientes son entradas comunes utilizadas para determinar los niveles de carga del aplicativo: • El volumen de negocio (actual y proyectado) como se relaciona con sus objetivos de rendimiento. • • •
Escenarios clave Distribución de trabajo. Características de sesión (ruta de navegación, la duración, el porcentaje de nuevos usuarios)
Combinando los elementos anteriores, se puede determinar los detalles restantes necesarios para implementar el modelo de carga de trabajo bajo un objetivo de carga en particular. Paso 5 - Identificar las métricas. Hay un número virtualmente ilimitado de métricas que pueden ser recolectadas durante la ejecución de una prueba de rendimiento (performance). Sin embargo, recolectar demasiadas métricas puede dificultar el análisis así como impactar negativamente en el desempeño real de la aplicación. Por estas razones, es importante identificar las métricas más relevantes para sus objetivos de rendimiento y las que usted prevé le ayudarán a identificar los cuellos de botella. Sólo las métricas seleccionadas y que se analizan correctamente y contextualmente proporcionan información de valor. Las siguientes son algunas sugerencias para la identificación de las métricas que proporcionan información de valor para su proyecto: • Defina las preguntas relacionadas con el funcionamiento de la aplicación que puedan ser fácilmente probadas. Por ejemplo, ¿cuál es el tiempo de respuesta al hacer un pedido? ¿Cuántos pedidos se colocan en un minuto? Estas preguntas tienen respuestas definitivas. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
• Con las respuestas a estas preguntas, determinar los objetivos de calidad para compararlos con las expectativas externas. Por ejemplo, el tiempo de respuesta deberá ser de 30 segundos, y un máximo de 10 órdenes deben ser colocados en un minuto. Las respuestas se basan en estudios de mercado, datos históricos, las tendencias del mercado, y así sucesivamente. • Identificar las métricas. Usando su lista de preguntas y de respuestas relacionadas con el funcionamiento, identificar las métricas que proveen información relacionada para esas preguntas y respuestas. • Identificar métricas de apoyo. Utilizando el mismo enfoque, se puede identificar métricas de nivel inferior que se centran en la medición del desempeño y la identificación de los cuellos de botella en el sistema. Cuando identifica métricas de bajo nivel, la mayoría de los equipos lo consideran muy útil para determinar una línea base para las métricas en virtud de un solo usuario y/o condiciones de carga normales. Esto ayuda a determinar los niveles de carga aceptable para su aplicación. Los valores de referencia ayudarán a analizar el rendimiento de su aplicación a diferentes niveles de carga y servir como punto de partida para el análisis de tendencias a través de estructuras o de revisiones. • Reevaluar las métricas para ser recolectadas periódicamente. Objetivos, prioridades, riesgos y problemas actuales están obligados a cambiar en el curso de un proyecto. Con cada uno de estos cambios, las diferentes métricas pueden proporcionar más valor que las que han sido previamente identificadas. Además, para evaluar el rendimiento de su aplicación con más detalle y para identificar posibles cuellos de botella, con frecuencia es útil monitorear las métricas en las siguientes categorías: • Métricas de red específica (Network-specific metrics). Este conjunto de métricas proporcionan información sobre el estado general y la eficiencia de su red, incluyendo routers, switches y gateways. • Métricas de Sistema relacionados (System-related metrics). Este conjunto de métricas ayudan a identificar la utilización de los recursos en su servidor. Los recursos que se utilizan son el procesador, memoria, E/S de disco e I/O de red. • Métricas de Plataforma específica (Platform-specific metrics). Las métricas de Plataforma específica están relacionadas con el software que se utiliza para alojar su aplicación, como el de Microsoft.NET Framework Common Language Runtime (CLR) y métricas relacionadas con ASP.NET. • Métricas de Aplicación específica (Application-specific metrics). Estos incluyen los contadores de rendimiento personalizados incluidos en el código de la aplicación para controlar su buen estado y determinar el rendimiento. Puede utilizar los contadores de costumbre para determinar el número de Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
procesos simultáneos esperando obtener una vista particular, o el número de solicitudes en cola para realizar una llamada saliente a un servicio Web. • Métricas de Nivel de Servicio (Service-level metrics). Estas métricas pueden ayudar a medir el rendimiento global de la aplicación y la latencia, o pueden estar vinculados a los escenarios de negocio específicos. • Métricas de Negocio (Business metrics). Estas métricas son indicadores de la información relacionada con negocios, tales como el número de pedidos en un plazo determinado.
Paso 6 - Diseño de pruebas específicas Usando sus escenarios, métricas claves, y el análisis de la carga de trabajo, ahora puede diseñar pruebas específicas para llevarlas a cabo. Cada prueba generalmente tendrá un propósito diferente, recoger datos diferentes, incluir escenarios diferentes, y tener diferentes niveles de carga del aplicativo. La clave está en diseñar las pruebas que ayudarán al equipo a recoger la información que necesita para comprender, evaluar o ajustar la aplicación. Los puntos a considerar cuando diseñe las pruebas, incluyen: • No cambiar el diseño de la prueba porque el diseño es difícil de implementar en su herramienta. • Si usted no puede implementar la prueba como la diseñó, asegúrese de registrar los detalles referentes a la prueba a implementar. • Asegúrese de que el modelo contiene todos los datos complementarios necesarios para crear la prueba actual.
• Considere la inclusión de datos inválidos en sus pruebas de rendimiento (performance). Por ejemplo, algunos usuarios se equivocan al escribir su contraseña en el primer intento, pero lo hacen correctamente en un segundo intento. • Usualmente los usuarios nuevos suelen pasar más tiempo en cada página o actividad que los usuarios experimentados. • Los mejores datos de prueba son los datos de prueba recogidos en una base de datos de producción o de un archivo de registro (log).
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
• Piense en los usuarios de sistemas no humanos y de procesos por lotes, así como en los usuarios finales. Por ejemplo, puede haber un proceso por lotes que se ejecuta para actualizar el estado de los pedidos, mientras que los usuarios están realizando actividades en el sitio. En esta situación, usted tendría que dar cuenta de esos procesos, ya que podría consumir recursos. • No pierda tiempo buscando la perfección, y no caiga en la trampa de la simplificación. En general, es una buena idea comenzar a ejecutar las pruebas cuando se tiene un diseño de prueba razonable y luego mejorar el diseño de forma incremental mientras recolecta los resultados. Paso 7 - Ejecutar pruebas Las simulaciones pobres de la carga pueden hacer inútil todo el trabajo de las actividades anteriores. Para entender los datos recogidos desde una ejecución de pruebas, la simulación de carga debe reflejar el diseño de la prueba. Cuando la simulación no refleja el diseño de la prueba, los resultados son propensos a ser malinterpretados. Considere los siguientes pasos en la preparación para simular la carga: 1. Configure el ambiente de pruebas de tal manera que refleje el ambiente de producción lo más cerca posible, observando y explicando las diferencias entre los dos. 2. Asegúrese de que los contadores relevantes de rendimiento (performance) para las métricas identificadas y la utilización de los recursos se están midiendo y no interfieren con la precisión de la simulación. 3. Utilice las herramientas apropiadas para la generación de la carga, para crear una carga con las características especificadas en la prueba diseñada. 4. Utilizando las herramientas de generación de carga, ejecute las pruebas aumentando la carga hasta el límite especificado en el diseño de la prueba, a fin de validar la exactitud de la simulación. Algunas cosas a considerar durante la ejecución de la prueba son:
Comience las pruebas de carga con un pequeño número de usuarios distribuidos contra su perfil de usuario, y luego aumente gradualmente la carga. Es importante dar tiempo al sistema para estabilizarse entre los aumentos de carga, mientras que evalúa la corrección de la simulación. Considere la posibilidad de continuar incrementando la carga y registre el comportamiento hasta llegar al umbral de los recursos identificados en sus objetivos de rendimiento (performance), incluso si la carga está más allá de la carga límite especificada en la prueba diseñada. La información sobre cuando el sistema cruza los umbrales identificados es tan importante como el valor de la métrica en la carga límite de la prueba. De igual manera, con frecuencia es valioso continuar aumentando el número de usuarios hasta que se ejecute mas allá de los límites de nivel de servicio, del cual estaría violando los SLA (service level agreements : Acuerdos del nivel de servicio o de disponibilidad) de rendimiento, tiempo de respuesta, y la utilización de recursos. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Nota: Asegúrese de que los equipos cliente (agentes) que se utilizan para generar una carga no están demasiado estresados. La utilización de recursos tales como el procesador y la memoria debe permanecer muy por debajo del umbral de utilización de valores para asegurar resultados precisos.
Paso 8 - Analizar los resultados Usted puede analizar los resultados de las pruebas para encontrar los cuellos de botella de rendimiento (performance) entre cada prueba o después de que todas las pruebas se ha completado. El análisis correcto de los resultados requiere capacitación y experiencia con la representación gráfica correlacionada de los tiempos de respuesta y los datos del sistema. Los siguientes son los pasos para el análisis de los datos: 1. Analizar los datos capturados y comparar los resultados con el nivel de métricas aceptadas para determinar si se está probando el rendimiento de la aplicación mostrando una tendencia próxima o lejana a los objetivos de rendimiento. 2. Análisis de las métricas de medida para diagnosticar posibles cuellos de botella. Basándose en el análisis, si se requiere, capture métricas adicionales en los ciclos de pruebas posteriores. Por ejemplo, supongamos que durante la primera iteración de pruebas de carga, el proceso muestra un marcado aumento en el consumo de memoria, indicando una posible pérdida de memoria. En las iteraciones posteriores, los contadores de memoria adicional relacionados para la generación pueden ser capturados para estudiar el patrón de asignación de memoria para la aplicación 3.1.3
Resumen
Las pruebas de carga ayudan a identificar la capacidad máxima de funcionamiento de la aplicación y los cuellos de botella que podrían degradar el rendimiento. La metodología básica para la realización de pruebas de carga en una aplicación Web es determinar el rendimiento crítico de los escenarios clave, identificar el perfil de carga de trabajo para distribuir la carga entre todos los escenarios clave, identificar la métrica que desea recoger para verificarla contra los objetivos de rendimiento, crear los casos de prueba que serán utilizados para simular la prueba de carga, utilizar herramientas para simular la carga de acuerdo a los casos de prueba y captura de las métricas y, finalmente, analizar los datos capturados de la métricas durante las pruebas.
3.2 Aplicación de pruebas de estrés en aplicaciones Web Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
3.2.1
3.2.2
Objetivos Comprender los conceptos clave de la prueba de Stress. Aprender a realizar pruebas de Stress de una aplicación Web.
Descripción general
La prueba de Stress es un tipo de prueba de rendimiento (performance) centrada en determinar la robustez de una aplicación, la disponibilidad y fiabilidad bajo condiciones extremas. El objetivo de la prueba de Stress es identificar los problemas de la aplicación que se manifiestan bajo condiciones extremas. Estas condiciones pueden incluir cargas pesadas, alto nivel de concurrencia, o recursos de cómputo limitados. Una adecuada prueba de Stress es útil para encontrar errores de sincronización y temporización, los problemas de bloqueo, los problemas prioritarios, y los Bugs de pérdida de recursos. La idea es estresar un sistema al punto de su ruptura con el fin de encontrar Bugs (errores) que harán a esa ruptura potencialmente dañina. No se espera que el sistema procese la sobrecarga sin los recursos adecuados, pero se comporta (e.g, falla) de una manera aceptable (por ejemplo, sin corrupción y sin pérdida de datos). Las pruebas de stress o de esfuerzo suelen incluir la simulación de uno o más escenarios claves de producción bajo una variedad de condiciones estresantes. Por ejemplo, puede implementar su aplicación en un servidor que está ejecutando un proceso de aplicación intensiva, de esta manera, su aplicación inmediatamente esta "ávida" de recursos de procesador y deben competir con otra aplicación por los ciclos del procesador. También puede realizar pruebas de stress en una sencilla página Web, o incluso un solo elemento, como un procedimiento almacenado o una clase. Esta sección presenta una introducción de alto nivel de pruebas de estrés de una aplicación Web. Las pruebas de estrés pueden ayudar a identificar los errores de la aplicación que emergen solamente bajo condiciones extremas. 3.2.3
Ejemplos
de
condiciones
de
Los ejemplos de las condiciones de estrés incluyen:
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
estrés
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
• Volumen excesivo en términos de usuarios o datos, los ejemplos pueden incluir un ataque de la negación del servicio (DoS) o una situación donde una noticia extensamente vista incita a una gran cantidad de usuarios a visitar un Web site durante un periodo de tres minutos. • La reducción de recursos como un fallo de la unidad de disco. •Secuencia inesperada. •Interrupciones
inesperadas/recuperación
de
interrupciones.
Ejemplos de síntomas relacionados con el estrés Ejemplos de síntomas relacionados con el estrés incluyen: •Se pierden o se dañan los datos. •La utilización de los recursos sigue siendo inaceptablemente alta después de eliminar el estrés. •Los •Las
3.2.4
componentes excepciones
de no
controladas
la
aplicación se
presentan
no al
responden. usuario
final.
Cómo usar este apartado
En esta apartado se pretende dar a entender los conceptos claves de la prueba de stress y los pasos involucrados en las pruebas de estrés de una aplicación Web. Para obtener el máximo beneficio de esta sección siga las siguientes recomendaciones: • Utilice las secciones de "entradas" y "Salidas" para entender los elementos fundamentales de las pruebas de estrés, de una aplicación Web y los principales resultados de este tipo de pruebas. • Use la sección "enfoque de la prueba de estrés" para conseguir una descripción del enfoque de la prueba de estrés de una aplicación Web, y como guía de referencia rápida para usted y su equipo. • Utilice las distintas secciones para entender los detalles de cada paso que participan en pruebas de estrés de una aplicación Web. • Use la sección "escenario de uso para la prueba de estrés" para entender diversos escenarios del mundo real en que se emplea las pruebas de estrés. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
3.2.4.1
Entradas
Para llevar a cabo pruebas de estrés, es probable que utilice como referencia uno o más de los siguientes elementos: •Los resultados de las anteriores pruebas de estrés. •las características de uso de aplicaciones (escenarios) •Preocupación acerca de los escenarios en condiciones extremas. •Las características del perfil de carga de trabajo •La actual capacidad de carga máxima (obtenida a partir de pruebas de carga) •Hardware y la arquitectura de red y datos. •Evaluación de la relación desastre - riesgo (por ejemplo, la probabilidad de apagones, terremotos, etc.). 3.2.4.2
Salidas
La salida de una prueba de estrés puede incluir: •Medidas de la aplicación bajo condiciones de estrés •Síntomas de la aplicación bajo estrés. •La información del equipo se puede usar para dirigir la robustez, disponibilidad y fiabilidad. 3.2.5
Enfoque para la prueba de estrés
Los siguientes pasos están involucrados en las pruebas de estrés de una aplicación Web: 1. Paso 1 - Identificar los objetivos de la prueba. Identificar los objetivos de la prueba de esfuerzo en términos de los resultados deseados de la actividad de la prueba. 2. Paso 2 - Identificar el escenario clave (s). Determinar el escenario de aplicación o los casos que hay que probar bajo estrés para identificar los problemas potenciales. 3. Paso 3 - Identificar la carga de trabajo. Determinar la carga de trabajo que desea aplicar a los escenarios identificados durante el paso "objetivos identificados". Esto se basa en las entradas de la capacidad de la carga de trabajo y de carga máxima. 4. Paso 4 - Identificar las métricas. Identifique las métricas que se quiere recolectar sobre el rendimiento de la aplicación. Basen estas métricas en los problemas potenciales para los escenarios o situaciones identificados durante el paso "objetivos identificados”. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
5. Paso 5 - Crear casos de prueba. Cree los casos de prueba en los cuales usted define los pasos a ejecutar con una sola prueba, así como los resultados esperados. 6. Paso 6 - Simular carga. Use herramientas de prueba para simular la carga necesaria para cada caso de prueba y capturar los resultados de datos métricos. 7. Paso 7 - Analizar los resultados. Analizar los datos de las métricas capturadas durante la prueba. Estos pasos se representan gráficamente a continuación, las secciones siguientes se explica con detalle cada paso.
Figure 2 Pasos de las pruebas de stres. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Paso 1 - Identificar los Objetivos de la prueba (objetivos identificados) Pregúntese a si mismo o a otros las siguientes dudas que pueden ayudar a identificar los resultados deseados de su prueba de estrés: 1. Es el propósito de la prueba, determinar cómo el sistema puede fallar catastróficamente, posiblemente en producción..? 2. ¿Es para proporcionar la información al equipo para construir defensas contra fracasos catastróficos? 3. ¿Se trata de identificar cómo la aplicación se comporta cuando se agotan los recursos del sistema como la memoria, espacio en disco, ancho de banda de red, o se agotan los ciclos de procesador? 4. ¿Es para asegurar que la funcionalidad no se rompe con el estrés..? Por ejemplo, puede haber casos donde las métricas de rendimiento operativo del funcionamiento cumplen los objetivos, pero la funcionalidad de la aplicación no está cumpliendo con ellos - los pedidos no son insertados en la base de datos, la aplicación no devuelve la información completa del producto en las búsquedas, los controles de formulario no se completan correctamente, la redirecciona a páginas de error personalizadas se producen durante la prueba de estrés, y así sucesivamente. Paso 2 - Identificar los Escenarios claves Para obtener el máximo valor de una prueba de estrés, la prueba debe centrarse en el comportamiento del uso del escenario o escenarios de mayor importancia para el éxito global de la aplicación. Para identificar estos escenarios, en general, comience por definir un escenario único en el que desea realizar pruebas de estrés con el fin de identificar un problema de rendimiento potencial. Tener en cuenta estas recomendaciones al elegir escenarios apropiados: • Seleccione los escenarios basados como críticos en el rendimiento o ejecución general de las aplicaciones. • Trate de poner a prueba las operaciones que tienen más probabilidades de afectar el rendimiento. Estas podrían incluir las operaciones que realizan bloqueos y sincronización intensiva, largas transacciones, y operaciones intensas de I/O del disco. • Base su selección de escenario en las áreas específicas de su aplicación identificadas como posibles cuellos de botella en las pruebas de carga de datos. A pesar de que debería haber afinado y eliminado los cuellos de botella después de las pruebas de carga, todavía debe realizar pruebas de estrés del sistema en estas zonas para verificar qué tan bien los cambios manejan niveles de estrés extremo. Ejemplos de situaciones que pueden ser sometidos por separado a pruebas de estrés desde otros escenarios de uso de una típica aplicación de comercio electrónico, incluyen los siguientes: Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
• Un escenario de procesamiento de órdenes que actualiza el inventario de un producto en particular. Esta funcionalidad tiene el potencial para exhibir problemas de bloqueo y sincronización. • Un escenario de páginas de resultados de búsqueda basados en las consultas del usuario. Si un usuario especifica una consulta amplia en particular, podría haber un gran impacto en la utilización de la memoria. Por ejemplo, la utilización de la memoria puede verse afectada si una consulta devuelve una tabla de datos completa.
Paso 3 - Identificar la carga de trabajo La carga que aplica a un escenario en particular debería estresar el sistema lo suficientemente, incluso más allá de los límites de umbral establecido que le permita observar las consecuencias de la situación de estrés. Un método para determinar la carga a la que una aplicación comienza a mostrar signos de estrés es aumentar gradualmente la carga y observar el comportamiento de las aplicaciones bajo condiciones de carga diferentes. La clave está en probar sistemáticamente la prueba con diversas cargas de trabajo hasta que se cree una falla importante. Estas variaciones se pueden lograr mediante la adición de más usuarios, reduciendo los tiempos de retardo, añadir o reducir el número y tipo de actividades de los usuarios representados, o ajustando los datos de prueba. Por ejemplo, una prueba de estrés puede ser diseñada para simular todos los usuarios registrados en la aplicación que intentan iniciar sesión durante un período de 30 segundos. Esto simula una situación donde la aplicación de repente se pone nuevamente a disposición después de un período de tiempo de inactividad y todos los usuarios se encontraban ansiosos refrescando sus navegadores, en espera de que la aplicación volviera a estar en línea o a disposición. Aunque esta situación no se produce con frecuencia en el mundo real, sucede a menudo para que haya un valor real en el aprendizaje de cómo la aplicación responderá si lo hace. Recuerde representar la carga de trabajo con los datos reales y exactos de la prueba - el tipo y el volumen, diferentes logins de usuario, ID de producto, categorías de producto, y así sucesivamente - lo que le permite simular fallos importantes, tales como bloqueos o el consumo de recursos. Las siguientes actividades generalmente son útiles en la identificación de cargas de trabajo adecuadas para las pruebas de estrés:
• Identificar la distribución del trabajo. Para cada escenario clave, identifique la distribución del trabajo a ser Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
simulado. La distribución se basa en el número y tipo de usuarios que ejecutan el escenario durante la prueba de esfuerzo. • Estimación carga máxima de usuario. Identifique el número máximo esperado de usuarios en condiciones de carga máxima para la aplicación. Use la distribución del trabajo que ha identificado para cada caso, calcular el porcentaje de carga de usuarios por escenario clave. • Identificar el anti-perfil. Como alternativa, usted puede comenzar por la aplicación de un anti-perfil a la carga de trabajo normal. En un anti-perfil, la distribución de la carga normal de trabajo se invierte para el escenario considerado. Por ejemplo, si la carga normal para el escenario de procesamiento de órdenes es de 10 por ciento de la carga total de trabajo, el anti perfil sería de 90 por ciento de la carga de trabajo total. La carga restante se distribuye entre los otros escenarios. El uso de un anti-perfil puede servir como un valioso punto de partida para sus pruebas de estrés, ya que asegura que los escenarios críticos están sometidos a cargas más allá de las condiciones de carga normales establecidas.
Paso 4 - Identificar las métricas Cuando están identificadas y capturadas correctamente, las métricas proporcionan la información acerca de cuán bien o mal su aplicación se está ejecutando con respecto a sus objetivos de rendimiento. Además, las métricas pueden ayudar a identificar áreas con problemas y cuellos de botella en su aplicación. Usando las características de funcionamiento deseadas identificadas durante el paso "Identificación de objetivos", identifique las métricas que se capturaran y que se centran en los peligros potenciales para cada escenario. La métrica puede estar relacionada con los objetivos de rendimiento y funcionamiento del procesamiento, así como el suministro de información sobre problemas potenciales, por ejemplo, contadores de rendimiento personalizados que se han incrustado en la aplicación. Al identificar las métricas, utilizará los objetivos directos o las métricas que se relacionan directamente o indirectamente con esos objetivos. La siguiente tabla describe los parámetros de rendimiento en términos de objetivos de rendimiento relacionados. Métricas de rendimiento Conjunto básico de métricas Procesador.
Categoría •
Utilización del procesador.
Procesos.
•
Consumo de la memoria.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
•
Utilización del procesador.
•
Procesos de reciclaje.
•
Memoria disponible.
•
Utilización de memoria.
Disco
•
Utilización de disco.
Red.
•
Utilización de red.
Transacciones/Métricas de negocios
•
Transacciones/seg.
•
Transacciones satisfactorias.
•
Transacciones fallidas.
• •
Ordenes satisfactorias. Argumentos por Segundo.
•
Interbloqueos (Deadlocks)
• •
Asignación de subprocesos. Tiempo de Transacciones.
Memoria.
Procesamiento (Threading).
Tiempos de respuesta.
Paso 5 - Crear Casos de Prueba La identificación de los perfiles de carga de trabajo y escenarios clave en general no proporcionan toda la información necesaria para aplicar y ejecutar los casos de prueba. Las entradas adicionales para diseñar completamente una prueba de estrés incluyen los objetivos de rendimiento, las características de la carga de trabajo, datos de prueba, los entornos de prueba, y las métricas identificadas. Cada diseño de prueba debe mencionar los resultados esperados y/o los datos clave de interés para ser recolectados, de tal forma que cada caso de prueba se puede marcar como un "pass pasó", "fail fallo" o "inconcluso" después de su ejecución. El siguiente es un ejemplo de un caso de prueba basado en el escenario de la solicitud de un pedido: Test 1 – Escenario Solicitud de Pedido Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Carga de trabajo: 1.000 usuarios simultáneos. Tiempo estimado: Piense en usar tiempo al azar entre 1 y 10 segundos en el script después de cada operación. Duración
de
la
prueba:
Ejecute
la
prueba
durante
dos
días.
Resultados esperados: • La aplicación de procesos de hosting podrían no reciclarse por el bloqueo o el consumo de memoria. •
El
rendimiento
no
debe
caer
por
debajo
de
35
solicitudes
por
segundo.
• Tiempo de respuesta no debe ser mayor de 7 segundos para el 95 por ciento del total de transacciones completadas. • Errores de "Servidor ocupado" no deben ser más de 10 por ciento de la respuesta total a causa de los errores relacionados con los conflictos. • Las transacciones no deben fallar durante la ejecución de la prueba. Las entradas de la base de datos deben coincidir con la cuenta de "Transacciones con éxito". Paso 6 - Simular Carga
Después de haber completado los pasos anteriores adecuadamente, debe estar listo para simular la carga ejecutando la prueba de estrés. Por lo general, la ejecución de la prueba sigue estos pasos: 1. Validar que el entorno de prueba coincide con la configuración que usted esperaba y/o diseñó para la prueba. 2. Asegurarse que tanto la prueba y el entorno de prueba están configurados correctamente para la recolección de métricas. 3. Antes de ejecutar la prueba, ejecutar rápidamente una "prueba de humo - smoke test " para asegurarse de que el script de prueba y contadores de rendimiento remoto están funcionando correctamente. 4. Restablecer el sistema (a menos que su escenario haga lo contrario) y comenzar la ejecución de una prueba formal.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Nota: Asegúrese de que los computadores clientes (también conocido como generador de carga) que se utilizan para generar una carga no están demasiados estresados. La utilización de los recursos tales como el procesador y la memoria deben permanecer lo suficientemente bajos como para garantizar que la carga del entorno de generación no es en sí un cuello de botella. Paso 7 - Analizar los resultados Analizar los datos capturados y comparar los resultados contra el nivel aceptado de la métrica. Si los resultados indican que sus niveles de rendimiento requeridos no se han alcanzado, analizar y solucionar la causa del cuello de botella. Para abordar los problemas observados, es posible que tenga que hacer una o más de los siguientes aspectos: • Realizar una revisión del diseño. • Realice una revisión de código. • Ejecutar las pruebas de estrés en entornos donde es posible depurar las posibles causas de las fallas, durante la ejecución de la prueba. En situaciones en las que se observan problemas de rendimiento, pero sólo bajo condiciones que se consideran poco probables como para justificar la afinación en el momento actual, se puede considerar la realización de pruebas adicionales para identificar un indicador temprano del problema a fin de evitar sorpresas no deseadas. 3.2.5
Escenarios usados para la prueba de stress
Los siguientes son ejemplos de cómo la prueba de estrés se aplica en la práctica: • Aplicación de las Pruebas de estrés. Este tipo de prueba normalmente se centra en más de una transacción en el sistema bajo estrés, sin el aislamiento de componentes. Con la aplicación de las pruebas de estrés, es probable que descubra defectos relacionados con los datos de cierre y bloqueo, la congestión de la red, y los cuellos de botella de rendimiento en los diferentes componentes o los métodos a través de toda la aplicación. Porque el alcance de la prueba es una sola aplicación, es común el uso de este tipo de pruebas de estrés después de un esfuerzo robusto de la prueba de carga en la aplicación, o como la última fase de la prueba para la planificación de la capacidad. También es común encontrar defectos relacionados con condiciones de tiempo y pérdida general de memoria desde el código compartido o de componentes. • Pruebas de estrés transaccional. Las pruebas de estrés transaccional tienen como objetivo trabajar a un nivel de transacciones con los volúmenes de carga que van más allá de las operaciones de producción Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
previsto. Estas pruebas se centran en la validación de comportamientos bajo condiciones de estrés, así como una alta carga con las mismas limitaciones de recursos, al comprobar toda la aplicación. Debido a la prueba aislada de una transacción individual o grupo de transacciones, permite un conocimiento muy concreto de capacidades de rendimiento y otras características de los componentes individuales, sin la complicación adicional de las interacciones de componentes que se produce en las pruebas a nivel de aplicación. Estas pruebas son útiles para la puesta a punto, optimización, y la búsqueda de las condiciones de error a nivel de componente específico. • Pruebas de estrés sistémico. En este tipo de prueba, el estrés o las condiciones extremas de carga se generan a través de múltiples aplicaciones que se ejecutan en el mismo sistema, de tal modo que presionan en extremo los límites de la capacidad de espera de las aplicaciones. El objetivo de la prueba de estrés sistémico es descubrir defectos en situaciones donde diferentes aplicaciones se bloquean entre sí y compiten por los recursos del sistema como la memoria, los ciclos de procesador, espacio en disco y ancho de banda de la red. Este tipo de prueba también se conoce como pruebas de integración de estrés o consolidación de pruebas de estrés. En pruebas de estrés sistémicas a gran escala, usted estresa todas las aplicaciones juntas en el mismo entorno consolidado. Algunas organizaciones eligen realizar este tipo de pruebas en la facilidad de un gran laboratorio de pruebas, a veces con la ayuda del hardware o del proveedor del software. 3.2.6
Pruebas de estrés exploratorio
Las pruebas de estrés exploratorias son un acercamiento a someter a un sistema, aplicación o componente a un conjunto de parámetros inusuales o condiciones que son poco probables que ocurra en el mundo real pero que no obstante es posible de darse. En general, las pruebas exploratorias se pueden ver como un proceso interactivo de aprendizaje simultáneo, el diseño de la prueba, la ejecución de la prueba. A menudo, las pruebas de estrés exploratorias han sido diseñadas para modificar las pruebas existentes y/o trabajar con administradores de aplicaciones/sistema para crear las condiciones poco probables pero posibles en el sistema. Este tipo de pruebas de estrés rara vez se desarrollan aisladamente, porque normalmente se llevan a cabo para determinar si es más sistemático relacionar la prueba de estrés con un modo de fallo en particular. Los siguientes son algunos ejemplos de pruebas de estrés exploratorias para determinar la respuesta a "¿Cómo el sistema responderá si ...?" •Todos los usuarios estan conectados al mismo tiempo. •El balanceador de carga falla de repente. • Todos los servidores comenzaron su análisis programado de virus, al mismo tiempo durante un período de carga máxima. • La base de datos quedo fuera de línea durante los topes altos de uso. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
3.2.7
Resumen
Las pruebas de stress permiten identificar problemas potenciales de la aplicación que surgen solamente bajo condiciones extremas. Estas condiciones van desde el agotamiento de los recursos del sistema como la memoria, los ciclos del procesador, ancho de banda de red y la capacidad del disco en el exceso de carga debido a los patrones de uso impredecible, común en aplicaciones Web. Los objetivos y escenarios claves del usuario se centran en las pruebas de estrés con un énfasis sobre la robustez, confiabilidad y estabilidad de la aplicación. La eficacia de la prueba de estrés se basa en la aplicación de la metodología correcta y en la capacidad de analizar de forma eficaz los resultados de la prueba. La aplicación de la metodología correcta depende de la capacidad de reproducir las condiciones de la carga de trabajo tanto para la carga de usuarios y el volumen de datos, reproducción de escenarios clave, y la interpretación de las métricas de funcionamiento clave. Glosario Adaptabilidad: Capacidad del producto de software para adaptarse a diferentes ambientes, sin aplicar acciones o medios diferentes a los ofrecidos para este propósito por el software considerado. Amenaza: Probabilidad de un ataque de tipo cualquiera que ocurra en un tiempo determinado (se puede deducir de evidencia empírica ). Analizabilidad: Capacidad del producto de software para ser diagnosticado por deficiencias o causas de fallas en el software o para identificar las partes que se deben modificar. Api: (Application Program Interface): Interfaz para programas de aplicación. Conjunto de convenciones de programación que definen cómo se invoca un servicio desde un programa. Apropiabilidad: Capacidad del producto de software para proporcionar un apropiado conjunto de funciones para las tareas específicas y los objetivos de los usuarios. Aseguramiento de la calidad: Gestión de la calidad orientada proporcionar confianza en que se cumplirán los requisitos de la calidad. Asset: Es una parte del contenido digital que se puede ver en un browser, un asset puede ser un video, una imagen, un documento, una pagina Web, funciones JavaScript. Atractividad: Capacidad del producto de software para ser atractivo al usuario.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Calidad de software: Grado de cumplimiento de los requisitos del usuario, a la profundidad de las pruebas realizadas y a la cobertura de la documentación. Calidad externa: Perspectiva del usuario con relación a la calidad del producto cuando este es utilizado en un ambiente simulado usando datos de prueba. Calidad interna: Determinada por el grado de cumplimiento de los requisitos del usuario, como por la profundidad de las pruebas y la cobertura de la documentación. Calidad total: Sistema de gestión relacionado con la mejora contínua de los procesos y productos, que involucra a todos los miembros de la organización y se centra en la satisfacción del cliente interno y externo. Calidad: Característica de una entidad, actividad, proceso, producto u organización que le otorgan su aptitud para satisfacer necesidades establecidas e implícitas. Se define más específicamente como el grado en el cual un componente, sistema o proceso satisface los requisitos especificados y/o necesidades del usuario/cliente y sus expectativas. Cms: (Content Management System): Sistema de gestión de contenidos. Aplicación de software que simplifica la creación y administración de contenidos por medio de páginas Web. Co-existencia: Capacidad del producto de software para coexistir con otros software`s independientes en un ambiente común en el que comparten recursos comunes a ambos. Comportamiento en el tiempo: Capacidad del producto de software para proporcionar adecuados tiempos de respuesta, de procesamiento y tasas de eficiencia en el desempeño de su función, bajo condiciones especificas. Comprensibilidad: Capacidad del producto de software para permitirle al usuario entender si este es conveniente, cómo lo puede usar y cuáles son sus condiciones de uso. Concurrencia: Medida de los usuarios independientes que una aplicación puede soportar ejecutando acciones coincidentes - Conjunto de actividades dentro de una aplicación que se desarrollan en forma coincidente - N procesos son concurrentes cuando se ejecutan (acción por acción) en el mismo intervalo de tiempo; es decir, para ejecutarlos concurrentemente se requiere tan solo "repartir" el procesador entre ellos a una velocidad tal que, por unidad o intervalo de tiempo, todos reciban su atención (aunque sea sólo parcial). Confiabilidad: Capacidad del producto de software para mantener su nivel de desempeño cuando es usado bajo condiciones especificas en un periodo de tiempo. Confidencialidad: Es la capacidad de proporcionar acceso a usuarios autorizados, y negarlo a no autorizados. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Conformidad: Capacidad del producto de software para adherirse a estándares, normas, convenciones o regulaciones en legislaciones relacionadas con la funcionalidad. Consumo de los recursos: Capacidad del producto de software para usar una apropiada cantidad y tipos de recursos, cuando el software desempeña su función bajo condiciones especificas. Control de calidad: Aplicación de técnicas de inspección en la producción de bienes y servicios para evitar la salida de bienes defectuosos. Cuello de botella: Cualquier recurso (hardware, software o ancho de banda) que definen límites en cuanto al flujo de datos o velocidad de un proceso. Defecto: Se define como el desperfecto en un componente o sistema que puede ser la causa por la cual el sistema o componente no logre llevar a cabo su función específica, por ejemplo una sentencia o definición de datos incorrectas. Disponibilidad: Es la capacidad de acceder a información o utilizar un servicio siempre que lo necesitemos. Capacidad del producto de software de estar en un estado para realizar una función requerida en un punto dado en el tiempo, bajo condiciones establecidas de uso. Efectividad: Capacidad del producto de software para brindar la posibilidad a los usuarios de alcanzar metas y objetivos especificados con exactitud y completitud en un contexto de uso particular. Eficiencia: Capacidad del producto de software para proporcionar un desempeño apropiado, en relación con la cantidad de recurso utilizado, bajo condiciones especificas. Error: Según la norma 610 de la IEEE, se define el error como una acción humana que produce un resultado incorrecto, por ejemplo un error de programación. Estabilidad: Capacidad del producto de software para evitar efectos no esperados debido a modificaciones en el software. Estimación: Identificar cuánto tiempo y esfuerzo se consume un recurso en la ejecución de las pruebas de estrés. Estrés (Performance): Medida de la disponibilidad, velocidad y capacidad que tiene la aplicación. Facilidad de aprendizaje: Capacidad del producto de software para permitir al usuario aprender la aplicación (control de operación, entradas, salidas).
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Fallo: Se define como la manifestación física o funcional de un defecto. Si un defecto es encontrado durante la ejecución de una aplicación puede producir un fallo. Se define también como la desviación de un componente o sistema respecto de la prestación, el servicio o resultado esperado. Integridad: Es la capacidad de garantizar que una información o mensaje no han sido manipulados. Iteración: Es la secuencia total de pasos que un usuario ejecuta hasta terminar su labor en la aplicación. Metadato: Información sobre el contenido, que permite almacenarlo y recuperarlo desde una base de datos. Pruebas de confirmación: Conocidas como pruebas de reiteración – Retest – las cuales se definen como la repetición de una prueba tras la corrección de un defecto con el objeto de confirmar que el defecto ha sido eliminado con éxito. Prueba de regresión: Consiste en la repetición de pruebas después de una modificación - por ejemplo la corrección de un defecto – Con el objeto de comprobar que no se han introducido o descubierto defectos en mascarados como resultado de la modificación. Esta se realizan previo a la aceptación del producto y siempre que el software y su entorno hayan sido modificados. Punto de quiebra: Cantidad máxima de usuarios concurrentes que la aplicación puede soportar antes de no entregar una respuesta efectiva. Requisito: Un requisito describe un atributo funcional o no funcional deseado o considerado obligatorio. Revisión (Reviews): Según el estándar 1028 de la IEEE, se define como la evaluación de un producto o estado de un proyecto con el objeto de detectar discrepancias con respecto a los resultados esperados (planificados) y para recomendar mejoras. Script de prueba: Es el archivo o fracción de código que almacena la secuencia de pruebas de estrés y la configuración de la misma. Secuencia de prueba: Es la orden que se debe seguir entre URLs para ejecutar una prueba de estrés. Simultaneidad: Dos procesos son simultáneos cuando se ejecutan en el mismo instante; es decir, para que exista simultaneidad entre n procesos se debe contar forzosamente con n procesadores. Sniffer: Programa para monitorear y analizar el trafico en una red de computadoras, detectando los cuellos de botellas y problemas que existan en ella. Think time: Tiempo aproximado que un usuario se tardaría realizando una operación habitual. Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]
Instituto de Hidrología, Meteorología y Estudios Ambientales Oficina de Informática República de Colombia
Throughput: Medida (megabits/segundo).
del
flujo
de
datos,
por
ejemplo
hits/segundo,paginas/segundo,
Mbps
Tic: Tecnologías de Información y Comunicaciones. Tiempo de respuesta: Es el tiempo que tarda una página en ser cargada con todos sus elementos. Validación: Según ISO 9000 se define como la comprobación de la idoneidad para el uso esperado. Como ejemplo se puede tomar la cuestión clave …Se ha construido el software correcto..?. Verificación: Según ISO 9000 se define como la comprobación de la conformidad con los requisitos establecidos. Como ejemplo se puede tomar la cuestión clave …Se ha procedido correctamente en la construcción del sistema..?. Xml (Extensible Markup Language): Lenguaje de codificación de última generación, que permite a los diseñadores Web programar sus propios comandos de marcación. Estos comandos podrán ser usados posteriormente como si fueran comandos HTML estándares.
Carrera 10 No. 20-30 Piso 8º Bogotá D. C. PBX. 3527160 Ext. 2151-2150-1830-1831 Fax: EXT. 1826 www.ideam.gov.co [email protected]