doo 13-testing

El Testing

Contexto

Agenda Objetivos e Introducción La Calidad Tipos de Prueba. Ciclo de Vida y Mediciones. Escenarios en las Pruebas. Tácticas de Prueba Técnicas de Prueba

Objetivos del Testing Verificar la correcta interacción entre los

objetos Verificar la apropiada integración de los

componentes del software. Verificar que todos los requerimientos se han

implantado correctamente. Identificar y asegurar que los defectos y su

tratamiento se han priorizado sobre el desarrollo del software.

Introducción En muchas organizaciones la prueba del

software significa el 30 o 50 % de los costos de desarrollo del software, no obstante mucha gente sostiene que la mayoría del software no se prueba lo suficiente antes de ser distribuido.

Introducción Factores:

La prueba del software es tremendamente difícil. Las interrelaciones son tantas que probar todo el comportamiento es incuantificable.

La pruebas no se hacen con una clara metodología y sin la automatización requerida.

Introducción Pruebas bien hechas y planificadas desde el

comienzo del ciclo de vida del software reducen significativamente los costos de terminar y mantener el software.

También reducen los riesgos asociados con una pobre calidad del software: productividad deficiente, errores de ingreso y cálculo de datos, comportamiento funcional inaceptable, entre otros.

Calidad Alcanzar la calidad no consiste solamente en

lograr conformidad en la “satisfacción de requerimientos” o de cumplir con las expectativas de los usuarios....

...Radica en identificar las medidas y criterios que demuestren que se ha alcanzado en implantar un proceso que asegure que cualquier producto realizado siempre alcance el mismo nivel de calidad.

Calidad del producto. Es la calidad del resultado tangible o producto

del proceso que lo llevó a cabo. En el desarrollo del software el producto es la

suma de muchos artefactos, como: El ejecutable y su código (sistemas de

aplicación) que es el producto primario objeto o motivo de un proyecto de desarrollo.

Artefactos no ejecutables como manuales de usuario y materiales de curso.

Calidad del producto. .....

Ejecutables no implementados como la especificación de pruebas y herramientas de desarrollo.

Artefactos no ejecutables ni implementados como los planes de implementación, de prueba y modelos.

Calidad del producto. Como muchos artefactos se basan en

otros, la calidad de los mismos está relacionada en cierto grado.

Por esta razón todos los artefactos deben ser sometidos a métricas de calidad.

Dimensiones de la Calidad

Dimensiones propuestas por el RUP: Confiabil idad: Consiste en la

fiabilidad y robustez del software (resistencia a fallas, interrupciones, caidas y falta de memoria) uso adecuado de recursos e integridad del código.

Dimensiones de la Calidad

Funcionalidad: Es la habilidad de implementar los casos de uso tal como se han requerido.

Dimensiones de la Calidad (cont.)

Rendimiento: Es el perfil de tiempo de operación del software y sus características operacionales. El perfil incluye el flujo de ejecución del

código, el acceso a los datos, las llamadas a funciones y las llamadas del sistema.

Las características operacionales incluyen: el tiempo de respuesta, la recuperación y límites en horas pico y estrés.

Niveles de Calidad

Existen 4 niveles de calidad: prueba, verificación, validación y certificación:

Prueba Las pruebas se llevan a cabo para

demostrar que no hay errores en un programa. Esto es prácticamente imposible cuando se ejecuta por primera vez.

Las pruebas involucran la ejecución de procesos con la intención explícita de hallar errores, hacer que el proceso falle.

Niveles de Calidad Verificación (Alpha test)

La verificación (alpha test) involucra la ejecución de partes o todo el sistema en ambientes simulados, con el fin de encontrar errores.

La retroalimentación de esta fase produce cambios en el software para resolver los errores y fallas que se descubren.

Los Alpha test se llevan a cabo en un ambiente controlado, en el cual el desarrollador está presente.

Niveles de Calidad Validación (Beta Test)

La validación (beta test) involucra el uso del software en un ambiente real.

Las transacciones y personas que usan el sistema son reales y trabajan en su área de trabajo real.

El desarrollador no está presente. Los usuarios están advertidos de que

están usando un sistema que puede fallar.

Niveles de Calidad Certificación

Es una garantía de un programa o sistema.

La garantía identifica que el software hace apropiadamente lo que el vendedor afirma que realiza.

Tipos de Prueba. Como ya se mencionó antes hay mucho mas

en la prueba del software que solamente probar las funciones, interfaces y tiempos de respuesta. Algunos criterios adicionales de prueba son: Integridad (resistencia a fallas) Habilidad para ser instalado / ejecutado en

diferentes plataformas. Habilidad de manejar diferentes requerimientos de

manera simultánea (concurrencia) Y otros mas....

Tipos de Prueba (cont.) Para cada dimensión existe un

conjunto de pruebas....... Confiabil idad

Prueba de Integridad: Se concentra en determinar la robustez del sistema (resistencia a fallas) y las facilidades técnicas del lenguaje, sintaxis y uso de recursos.

Tipos de Prueba (cont.) Confiabil idad

Prueba de Estructura: Se enfoca en asegurar la adherencia del objeto de prueba a su diseño y concepción. Típicamente se realiza para aplicaciones WEB enable asegurando que todos los enlaces estén conectados, el contenido sea apropiado y no existan contenidos huérfanos.

Tipos de Prueba (cont.) Funcionalidad

Prueba de Configuración: Pruebas enfocadas a asegurar la calidad de resolución de las funciones del sistema. Están encaminadas a probar diferentes configuraciones de hardware y software.

Tipos de Prueba (cont.) Funcionalidad

Pruebas de Función: Se concentran en la funcionalidad propiamente dicha; si tiene los servicios requeridos, métodos o casos de uso. Se implementan y ejecutan en diferentes objetos de prueba como: unidades funcionales, unidades integradas, subsistemas, aplicaciones y sistemas completos.

Tipos de Prueba (cont.) Funcionalidad

Pruebas de instalación: Concentradas en las diferentes instalaciones del hardware y software en distintas configuraciones y condiciones tales como: espacio de disco insuficiente o cortes de energía.

Tipos de Prueba (cont.) Funcionalidad

Pruebas de Seguridad: Focalizadas en asegurar que la disponibilidad de los datos esté solamente para aquellas personas o usuarios autorizados.

Tipos de Prueba (cont.) Funcionalidad

Pruebas de Volumen: Focalizadas en verificar el comportamiento del sistema en la administración de grandes volúmenes de datos, tanto en la entrada, salida como en la comunicación con la base de datos. Estas pruebas se concentran en la elaboración de queries que recuperen el contenido completo de la base de datos o manejen variadas restricciones.

Tipos de Prueba (cont.) Rendimiento

Prueba de Benchmark: Compara el comportamiento de una nueva funcionalidad u objeto de prueba versus otro que se comporta de manera óptima.

Tipos de Prueba (cont.) Rendimiento

Prueba de Contención: Concentrada en verificar la concurrencia esto es muchas demandas a un mismo recurso (registros de datos, memoria, etc.)

Tipos de Prueba (cont.) Rendimiento

Prueba de Carga: Es un tipo de prueba que verifica y asegura los límites aceptables de operación del sistema bajo variadas cargas de trabajo. Las métricas incluyen las características de la carga de trabajo y los tiempos de respuesta. Cuando los sistemas incluyen arquitecturas distribuidas o balance de carga, se deben hacer pruebas especiales que aseguren que los métodos de distribución y carga balanceada funcionen apropiadamente.

Tipos de Prueba (cont.) Rendimiento

Perfi l de Rendimiento: Es una prueba en donde el rendimiento es probado y monitoreado en la ejecución de flujos de trabajo, acceso a los datos, llamadas a funciones y al sistema con el propósito de encontrar cuellos de botella y procesos ineficientes.

Tipos de Prueba (cont.) Rendimiento

Pruebas de Estrés: Es un tipo de prueba que se efectúa como consecuencia de haber encontrado un comportamiento anormal en el sistema. Se concentra en probar las funciones implicadas en situaciones extremas como sobrecarga del sistema, memoria insuficiente, no disponibilidad de servicios de software y/o hardware o disminución de los recursos compartidos.

El ciclo de Vida de la Prueba. Durante su Ciclo de Vida, el Software se

refina en cada iteración. Bajo este contexto el ciclo de vida de la prueba debe tener la misma aproximación.

Este ciclo de vida debe ser integrado con el enfoque iterativo, lo que significa que cada iteración va a tener un ciclo de pruebas siguiendo ese mismo patrón.

El ciclo de Vida de la Prueba.

El ciclo de Vida de la Prueba. Este enfoque iterativo permite las

pruebas de regresión. Muchas de las pruebas efectuadas en la iteración X se usan como pruebas de regresión en la iteración X +1 y así sucesivamente.

Debido a que la misma prueba se repite varias veces es necesario un esfuerzo adicional para automatizarla.

El ciclo de Vida de la Prueba.

Mediciones clave en las Pruebas. Las mediciones clave en la

prueba incluyen: cobertura y calidad.

Mediciones clave en las Pruebas.

La cobertura es la medición de cuan completo está el software en su funcionalidad.

Mediciones clave en las Pruebas. La calidad es la medición de la

confiabilidad, estabilidad y rendimiento del objeto de prueba. La calidad se basa en los resultados de las pruebas de evaluación y el análisis de los defectos identificados durante la prueba.

Mediciones clave en las Pruebas.

La métricas de Cobertura responden a la pregunta: ¿Cuan completa está la prueba? Estas pruebas se miden respecto a los requerimientos y casos de uso, o al código desarrollado versus el diseñado (ejecución del código).

Mediciones clave en las Pruebas. Calidad es un indicativo de que el

software también cumple con los requerimientos. Aquí los defectos son identificados como requerimientos de cambio.

Escenarios en las Pruebas.

Unidad de Prueba

Las unidades de prueba se deben definir en la fase inicial de una iteración y se debe concentrar en probar elementos pequeños. Usualmente estos elementos son componentes y como estos participan en la ejecución de un caso de uso.

Escenarios en las Pruebas.

Prueba de Integración o Integral Esta prueba está orientada a asegurar

que los componentes implementados operan apropiadamente cuando combinan esfuerzos en la ejecución de un use case.

Escenarios en las Pruebas.

Prueba del Sistema Se realiza cuando el software está

funcionando como un todo o cuando se esta probando todo un subsistema completo.

Escenarios en las Pruebas.

Prueba de Aceptación Esta prueba es el test final antes de

distribuir el software para su operación y uso.

Tácticas en las Pruebas. Una Táctica busca reducir la

posibilidad de que un riesgo específico tenga lugar.

Se enfatizará en dos tipos de tácticas: Inspecciones. Pruebas dinámicas.

Inspección Las inspecciones son aplicables en

todas las etapas de desarrollo del producto (no sólo para código).

No requieren herramientas sofisticadas.

Inspección Inspecciones: Roles y

responsabilidades Autor: Desarrollador del producto que será

inspeccionado. Inspectores:

Colegas del autor. Uno de otro proyecto.

Moderador: Miembro del grupo de aseguramiento de calidad.

Inspección Preparación de la Inspección: Proceso

Autor prepara el producto para revisar, lista de chequeo y material de soporte.

Moderador selecciona 2 inspectores y elabora cronograma.

Autor distribuye material. Autor presenta el producto a los

participantes en la inspección.

Inspección Revisión individual: Proceso:

Inspectores y moderador revisan individualmente, según lista de chequeo.

Inspectores registran defectos. Inspectores registran tiempo invertido

en revisión.

InspecciónPreparación Rev. Individual Reunión de Ins.

An. Causal de errs.

Verif. De corr. Congelar versión

Corr. De errs.Cambios?

Pruebas dinámicas Consiste en la ejecución de programas para

detectar errores. Son menos efectivas que inspecciones. Los defectos se manifiestan como

discrepancias en el comportamiento esperado.

La corrección de un error puede ser difícil, porque: Puede ser difícil aislar errores. Los problemas pueden ser intermitentes, difíciles

de repetir.

Técnicas de Prueba Caja blanca o Pruebas estructurales

El conocimiento del diseño interno del software se usa para construir casos de prueba.

Caja negra o Pruebas funcionales Casos de prueba basados en la especificación del

software. Pruebas basadas en escenarios o casos de

uso Actuar como usuario final. Crear escenarios para detección de errores.

Técnicas de Prueba Pruebas selectivas

Más casos de prueba para componentes más usados.

Más rigor en prueba de componentes críticos.

Más casos de prueba para componentes más complejos.

Técnicas de Prueba