• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Calidad del software   cap3
 

Calidad del software cap3

on

  • 2,821 views

 

Statistics

Views

Total Views
2,821
Views on SlideShare
2,821
Embed Views
0

Actions

Likes
2
Downloads
166
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Calidad del software   cap3 Calidad del software cap3 Presentation Transcript

    • CAPITULO 3
      • Un enfoque estratégico para las pruebas del software
      ESTRATEGIAS DE PRUEBA DEL SOFTWARE Por Julio C. Alsina
    • Un Enfoque Estratégico para Pruebas
      • Propuestas :
      • Para realizar pruebas efectivas un equipo de Sw.debe efectuar RTF y efectivas. Esto eliminará muchos errores antes de las pruebas.
      • La prueba comienza a nivel de componentes y trabaja “ hacia fuera ”, hacia la integración de todo el sistema de computo.
      • Diferentes técnicas de prueba son apropiadas en diferentes momentos
      • La prueba la dirige el desarrollador del software y un grupo independiente de pruebas (proyectos grandes)
      • La prueba y la depuración son actividades diferentes, pero la depuración debe incluirse en cualquier estrategia de prueba.
      • Una estrategia de prueba debe incluir “pruebas de bajo nivel”(a nivel de código) y de “alto nivel” (funciones del sistema)
    • Quien prueba el Software? Desarrollador Pruebas independientes Entiende el sistema pero probará “suavemente” y está guiado por la “entrega” Debe aprender acerca del sistema, pero intentará romperlo y está guiado por la calidad Si el Ing.Sw. no encuentra los errores ¡ El cliente si lo hará !...
    • Afirmaciones Incorrectas
      • El responsable del desarrollo no debería participar en el proceso de pruebas
      • El software debe ponerse a salvo de extraños que lo prueben
      • Quienes aplican las pruebas sólo deben participar en el proyecto cuando vayan a darse los primeros pasos de esas pruebas
    • Estrategia de Pruebas Pruebas de Unidad Pruebas de Integración Pruebas de Validación Pruebas de Sistema Codigo Diseño Ing.de Sistema Requisitos
    • Estrategia de Prueba de Sw Orientadas a Objetos CLASE 1 Atributos Operaciones … Por último se prueba el sistema como un todo para asegurarse de que se descubran errores en los requisitos ...… Atributos Operaciones CLASE 2 Atributos Operaciones CLASE 3 + Pruebas … Pruebas de Regresión
    • Criterios para Completar la Prueba … Cada vez que el cliente o el usuario ejecutan el programa de computadora, este se esta probando. Cuando terminamos las pruebas ? “… Nunca se termina de aplicar una prueba”
    • Pruebas de Unidad Módulo a ser probado Casos de Prueba Resultados Ingeniero de Software
    • Pruebas de Unidad Interfase (flujo de informacion hacia adentro/afuera del programa) Estructuras locales de datos (datos locales mantíenen integridad durante la ejecucion del programa) Condiciones de límites (modulo opera ok en los limites establecidos p/restrigir procesamiento) Caminos independientes (asegurar que todos los caminos se ejecutan por lo menos una vez) Caminos de manejo de errores (los errores probables tienen buen tratamiento y finalizacion adecuada) Casos de prueba Módulo a ser probado
    • Que deben descubrir los casos de prueba?
      • Comparaciones entre diferentes tipos de datos.
      • Operadores lógicos o precedencia de estos aplicada
      • incorrectamente.
      • Expectativa de igualdad cuando los errores de
      • precisión son improbables
      • Comparación incorrecta de variables.
      • Terminación inapropiada de o inexistente de bucles.
      • Falla de salida en iteración divergente
      • Variables de bucle modificadas de manera inapropiada
    • Manejo Correcto de Errores
      • Debe tener cuidado de no cometer las sigtes. fallas :
      • La descripción del error es ininteligible.
      • El error indicado no corresponde al encontrado.
      • La condición de error causa la intervención del S.O.
      • antes de que se dispare el manejo de errores.
      • El procesamiento de la condición de excepción es
      • incorrecto.
      • La descripción del error no proporciona información
      • suficiente para ayudar a localizar la causa del error.
    • Ambiente de Pruebas de Unidad Módulo Resguardo Controlador Resultados Casos de Prueba Interfase Estructuras locales de datos Condiciones de límites Caminos independientes Caminos de manejo de errores Resguardo
    • Controladores y Resguardos
      • Un Controlador no es más que un “programa principal” que acepta los datos del caso de prueba, pasa estos datos al componente que se está probando e imprime los resultados.
      • Los Resguardos sirven para reemplazar módulos subordinados al componente que habrá de probarse (o llamados por éste). Los resguardos usan la interfaz del modulo subordinado, realizan una mínima manipulación de datos, proporcionan verificación de la entrada y devuelven el control al módulo en prueba.
      • “ Representan sobrecarga de trabajo pues requieren construirse para realizar las pruebas, pero no se entregan con el producto final”
    • Estrategias de Pruebas de Integración
      • Opciones:
        • • el enfoque “big bang”
        • • una estrategia de construcción incremental
    • Pruebas de Integración
      • Enfoque “ big bang ” implica combinar todos los componentes, probando el programa como un todo, lo cual puede generar caos al detectar múltiples errores que dificultan la corrección, debido a su extensión.
      • La “ integración incremental ” sugiere construir y probar en pequeños incrementos, en los cuales resulta más fácil aislar y corregir errores, llegandose finalmente a probar la totalidad de los componentes y sus interfaces.
    • Integración de Arriba-Abajo El módulo mas alto es probado con resguardos A B C D E F G Los resguardos son reemplazados uno a la vez, “primero en profundidad” o “primero en anchura” A medida que nuevos módulos se integran, algunos sub-grupos de pruebas se realizan nuevamente
    • Integración de Abajo-Arriba A B C D E F G Grupo Los controladores son reemplazados una a la vez, “el mas profundo primero” Los módulos de trabajo están integrados y agrupados
    • Pruebas de Sandwich A B C D E F G Los módulos más altos son probados con resguardos Los módulos de trabajo están integrados y agrupados Grupo
    • Prueba de Regresion
      • “ Cada vez que se agrega un nuevo modulo como parte de una prueba de integración, el software cambia”
      • “… ejecutar nuevamente el mismo subconjunto de pruebas que ya se han aplicado para asegurarse de que los cambios no han propagado efectos indeseables”
      • El conjunto de pruebas de regresión contiene 3 casos dif. de prueba:
      • Muestra representativa de pruebas que ejercerán todas las func.del Sw
      • Pruebas adicionales centradas en las funciones afectadas por el cambio
      • Pruebas centradas en los componentes del Sw.que cambiaron
      A medida que avanza la prueba de integración, la cantidad de pruebas de regresión llega a volverse muy grande!!
    • Estrategias de Prueba para Software OO
      • Al pensar en el Sw.OO cambia el concepto de unidad. Cada clase e instancia de una clase (objeto) empaqueta atributos y operaciones.
      • Sin embargo las unidades de prueba mas pequeñas son las operaciones dentro de la clase . Una clase puede contener varias operaciones y una operación puede existir en varias clases dif.
      • No es posible probar una sola operación en forma aislada, sino como parte de una clase.
      • A diferencia de la prueba de unidad del Sw. Convencional que se centra en el detalle algoritmico de un modulo, la prueba de clase para Sw.OO se orienta a las operaciones que encapsula y en el comportamiento de estado de la clase .
    • Prueba de Integracion en el Contexto OO
      • El Sw.OO no tiene una estrategia de control jerárquico. Por tanto no tiene sentido estrategias de integr.Ascend/Descend.
      • Hay dos estrategias dif. para la prueba de Integr. de Sist.OO:
        • Prueba basada en subprocesos : conjunto de clases requerido para responder a una entrada o un evento del sistema. Cada subproceso se integra y valida individualmente.
        • Prueba basada en el uso : se empieza la construcción del sistema con las pruebas de clases independientes. Luego se prueba la siguiente capa de clases llamadas dependientes, usadas por las clases independientes. Se sigue esta secuencia de capas de prueba de clases dependientes hasta construir todo el sistema.
    • Pruebas de Alto Orden Prueba de Validación Prueba Alfa y Beta Pruebas de Sistema Otras pruebas especializadas
    • Pruebas de Validacion
      • Empiezan al culminar las pruebas de integración. En este nivel desaparece la distinción entre Sw. convencional y orientado a objetos.
      • La validación del Sw.se logra mediante una serie de pruebas que demuestran que se cumple con los requisitos.
      • Luego de dirigir cada caso de prueba de validación, existirá una de dos condiciones posibles:
        • La característica de funcionamiento o desempeño cumple con la especificación y se le acepta
        • Se descubre una desviación de la especificación y se crea una lista de deficiencias. La corrección de las deficiencias debe ser negociada con el cliente.
    • Pruebas Alfa y Beta
      • Son conducidas por el usuario final, no por los Ing.Sw.
      • Pueden ir desde una prueba de manejo informal hasta una serie de pruebas planeadas y ejecutadas sistemáticamente.
        • Pruebas Alfa : se aplican en el lugar de trabajo del desarrollador. Se realizan en un entorno controlado. El desarrollador “mira sobre el hombro” de los usuarios y registra los errores y los problemas de uso.
        • Pruebas Beta : se aplican en el lugar de trabajo de los usuarios finales. Por lo general el desarrollador no esta. Es una aplicación en vivo del Sw. en un entorno no controlado por el desarrollador. El usuario registra todos los problemas encontrados y los informa al desarrollador.
    • Pruebas de Sistema
      • Su propósito principal es ejercitar profundamente el sistema.
        • Pruebas de Recuperación : obliga al Sw. A fallar de varias maneras y a verificar que la recuperacion se realice apropiadamente . Considerar Re-inicializacion, Respaldo, Recup.Datos, NuevoArranque .
        • Pruebas de Seguridad : prueba que los mecanismos de proteccion integrados en el sistema realmente lo protejan de irrupciones inapropiadas (hackers por razones de diversión, empleados disgustados por venganza o busqueda ilícita de ganancias) .
        • Pruebas de Resistencia : ejecuta un sistema de tal manera que requiera una cantidad , una frecuencia o un volumen anormal de recursos. En esencia, se tratará de sobrecargar el programa . Se propone confrontar el programa con situaciones anormales.
        • Pruebas de Desempeño : esta diseñada para probar el desempeño del Sw.en tiempo de ejecución dentro del contexto de un sistema integrado. Solamente cuando estén totalmente integrados todos los elementos del sistema, será posible asegurar el verdadero desempeño del sistema. Con frecuencia suelen integrarse con pruebas de resistencia y suelen requerir instrumentación de Sw y Hw.
    • Depuración: un proceso de diagnóstico Cuando un caso de prueba descubre un error, la depuración es la acción que lo elimina!!
    • El proceso de depuración Casos de prueba Resultados Depuración Sospechas de Causas Causas Identificadas Correcciones Pruebas de Regresión Pruebas Adicionales Ejecución de Casos
    • Esfuerzo de Depuración Tiempo requerido para diagnosticar el síntoma y determinar la causa Tiempo requerido para corregir el error y conducir pruebas de regresión
    • Síntomas y Causas Síntoma y causa pueden estar separados geográficamente El síntoma puede desaparecer cuando se arregla otro problema El sintoma podria deberse a un error humano dificil de localizar La causa puede deberse a un error de sistema o de compilador La causa puede deberse a supuestos que todos creen El síntoma puede ser intermitente Síntoma Causa
    • Consecuencias de los Errores Daño suave leve disturbios serio extremo catastrófico infeccioso Tipo de Bug Categorías de errores: errores de función, errores de sistema, errores de datos, errores de código, errores de diseño, de documentación, violaciones estándar, etc.
    • Técnicas de Depuración Fuerza bruta / pruebas Volver atrás Eliminación de Causa - Inducción o Deducción
    • Técnicas de Depuración
      • Fuerza Bruta : método mas común y menos eficiente para aislar la causa de un error. Se hace descarga de memoria, se invocan señales en tiempo de ejecución, etc. En algún lugar del pantano de información producida se espera encontrar una pista que pueda conducir a la causa del error.
      • Rastreo hacia Atrás : empezando en el lugar donde se descubre el síntoma, se recorre hacia atrás el código fuente hasta hallar el sitio de la causa. Al aumentar las líneas de código, este método se vuelve inmanejable.
      • Eliminación de Causa : los datos relacionados con el error se organizan p/ aislar las causas posibles. Elabora una hipótesis de causa y se aprovechan los datos mencionados para probar o desechar la hipótesis. Se elabora una lista de causas posibles y con pruebas se busca eliminar cada una de ellas.
      • Depuración Automatizada : se cuenta con una amplia variedad de compiladores de depuración, ayudas dinámicas para la depuración (trazadores), generadores automáticos de casos de prueba y herramientas de correlación de referencias cruzadas. Sin embargo, las herramientas no son un sustituto de la evaluación cuidadosa basada en un modelo de diseño completo y un código fuente claro.
      • ¡Cuando todo lo demás falle, pida ayuda!
    • Depuración: Conclusiones
      • Piense acerca del síntoma que está viendo
      • Utilice herramientas (por ej. Depurador dinámico) para tener mayor detalle
      • Si está perdido, consiga ayuda
      • Esté absolutamente seguro de realizar pruebas de regresión cuando se “arregla” el bug.