Estrategias de prueba del software

Presentación del tema: "Estrategias de prueba del software"— Transcripción de la presentación:

1 Estrategias de prueba del software
Capítulo Pressman

2 Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y realizar sistemáticamente.

3 Enfoque estratégico para las pruebas del software
La documentación de las pruebas incluye: El plan de las pruebas, el diseño de los casos de prueba, la ejecución o procedimiento de las pruebas y los reportes de pruebas

4 Ciclo Completo de las Pruebas
4

5 Enfoque estratégico para las pruebas del software
Toda estrategia de pruebas tiene las siguientes características: Las pruebas comienzan a nivel de módulo y trabajan hacia fuera, hacia las de integración. Según el momento, son apropiadas diferentes técnicas de pruebas. La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba.

6 Quién realiza las pruebas ???
La prueba la lleva a cabo: el responsable del desarrollo del software y un grupo independiente de pruebas.

7 Enfoque estratégico para las pruebas del software
Una estrategia de prueba debe incluir: Pruebas de Bajo Nivel: para verificar que todos los pequeños segmentos o módulos de código se hayan implementado correctamente. Pruebas de Alto Nivel: para validar las principales funciones del sistema frente a los requisitos del cliente. Además una estrategia debe proporcionar una guía al profesional y un conjunto de hitos para el jefe del proyecto.

8 Verificación y Validación
Las pruebas se conocen a menudo como “verificación y validación (V&V)” Verificación: Se refiere al conjunto de actividades que aseguran que el software implementa una función específica. Validación: Se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.

9 Verificación y Validación
La V&V abarca una amplia lista de actividades SQA que incluyen: revisiones técnicas formales, auditorías de calidad y de configuración, monitorización de rendimientos, simulación, estudios de factibilidad, revisión de la documentación, revisión de la BD, análisis algorítmico, pruebas de desarrollo, pruebas de validación y pruebas de instalación. La aplicación de estos métodos y herramientas durante el desarrollo conducen a la calidad, que se confirma durante las pruebas. Las pruebas son el último bastión desde el que se puede evaluar la calidad y descubrir errores.

10 Organización para las pruebas de software
Desde un punto de vista psicológico, el análisis, el diseño del software y la codificación son tareas constructivas. Cuando comienza la prueba, aparece una sutil, aunque firme intención de “romper” lo que el ingeniero del software ha construido. Desde el punto de vista del constructor, la prueba se puede considerar destructiva.

11 Mitos sobre las pruebas de software
El responsable del desarrollo no debería entrar en el proceso de prueba. El software debe ser “puesto a salvo” de extraños que puedan probarlo de forma despiadada. Los encargados de la prueba sólo deben aparecer en el proyecto cuando comienzan la etapa de pruebas.

12 Organización para las pruebas de software
¿Quién debe realizar las pruebas? El responsable del desarrollo debe probar: las unidades individuales del programa, asegurando que cada una lleva a cabo la función para la que fue diseñada. En muchos casos, se encargará también de las pruebas de integración. Solo después de que la Arquitectura de Software esté completa, entra en juego un Grupo Independiente de Prueba (GIP). Su papel es eliminar el conflicto de intereses que se da al permitir al constructor probar lo que ha construido.

13 Organización para las pruebas de software
¿Quién debe realizar las pruebas? (cont.) El desarrollador y el GIP trabajan estrechamente Mientras se realizan las pruebas el desarrollador debe estar disponible para corregir los errores encontrados El GIP es parte el equipo de desarrollo: Ayuda a planificar y especificar los procedimientos de pruebas Además debe informar al SQA sobre el resultado de las pruebas.

14 Niveles de prueba del software
Los niveles de pruebas son: La prueba de unidad se centra en cada módulo individual del software, tal como está implementado en código fuente. La prueba de integración el foco es el diseño y la construcción de la arquitectura del software. La prueba de validación se validan los requisitos establecidos (funcionales, de comportamiento y de rendimiento), comparándolos con lo que se ha construido. La prueba del sistema verifica que cada elemento (software, hardware, gente, BD, documentación al cliente) encaje con la funcionalidad y el rendimiento del sistema total.

15 Niveles de prueba del software
Los niveles de pruebas se puede ver en el contexto de una espiral. Prueba del Sistema Prueba de Unidad Prueba de Validación Prueba de Integración Código Diseño Ingeniería del sistema Requisitos

16 Una estrategia de prueba del software
Pruebas de Alto Nivel Pruebas de Validación Pruebas de Caja Negra Requisitos Diseño Pruebas de Integración Prueba de Caja Negra y algunas pruebas de Caja Blanca Pruebas de Unidad Codificación Incluir figura 18.2 y agregar al dibujo la técnica a utilizar en cada fase Pruebas de Caja Blanca Dirección de la Prueba Etapas de la Prueba de Software

17 Criterios para completar la prueba
¿Cuando hemos terminado las pruebas? “La prueba nunca termina, ya que el responsable del software le pasa el problema al cliente.” Respuesta cínica. “Se termina la prueba cuando se agota el tiempo o el dinero disponible para tal efecto.” Respuesta correcta: basada en modelo estadístico y teoría de fiabilidad. No podemos tener la absoluta certeza de que el software nunca falla. Mediante un modelo estadístico y teórico de fiabilidad podemos determinar la probabilidad de funcionamiento libre de fallos.

18 Aspectos Estratégicos
Tom Gilb establece los siguientes aspectos estratégicos para implementar una prueba exitosamente: Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas. Además de encontrar errores se evalúan características como portabilidad, facilidad de mantenimiento y facilidad de uso Establecer los objetivos de la prueba de manera explícita. Efectividad de la prueba, cobertura, tiempo promedio de fallo, costo para encontrar y corregir errores, frecuencia de ocurrencia, horas de trabajo

19 Aspectos Estratégicos (Cont.)
Comprender qué usuarios van a manejar el software y desarrollar un perfil para cada categoría de usuario. Desarrollar un plan de prueba que haga hincapié en la “prueba de ciclo rápido” Construir un software robusto, diseñado para probarse a sí mismo, que diagnostique cierta clase de errores. Usar revisiones técnicas formales efectivas como filtro antes de la prueba. Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Desarrollar un proceso de mejora continua al proceso de prueba.

20 Mapa conceptual típico de las pruebas de Unidad [Braude pág. 396-397]
IEEE Tomado de [2] Está basado en el estándar IEEE

21 Planeación y ejecución de las pruebas de Unidad
La salida del proceso de planeación de pruebas es un plan de pruebas de unidad. Por ejemplo: 1. Probar método 84. 2. probar método 14, m. probar clase 26,… El siguiente paso es adquirir datos de entrada y salida asociados con cada prueba, pueden venir de pruebas anteriores. Esto se conoce como conjunto de pruebas. Por último, se ejecutan las pruebas

22 Planeación y ejecución de las pruebas de Unidad
Pasos que requiere el estándar IEEE para las pruebas de Unidad: Planear el enfoque general, recursos y tiempos. Determinar características con base en los requerimientos que deben probarse. Refinar el plan general Diseñar un conjunto de pruebas Implementar el plan y diseño refinados Ejecutar los procedimientos de pruebas Verificar que terminen Evaluar el esfuerzo y la unidad de pruebas

23 Planeación de pruebas de unidad [Braude pág. 406-407]
Decida la filosofía Qué se va a probar y quién lo hará? Métodos, clases, paquetes, .. Ideal: que el plan y la ejecución no sea el desarrollador, sino SQA Decida cómo documentarlas Definir procedimientos de prueba, datos de entrada, código, datos de salida

24 Planeación de pruebas de unidad
Determine el alcance de las pruebas unitarias Como es imposible probar todo hay que definir un alcance Todos los métodos se van a probar con igual cantidad de datos ilegales, de frontera y legales? Los métodos que cambian el estado se van a probar más que otros? Cuándo termina el proceso de pruebas? Prioridad de las pruebas de acuerdo a posibilidad de producir defectos?

25 Planeación de pruebas de unidad
Decida cómo y dónde obtener datos para las pruebas Si es posible usar herramientas automatizadas que generen datos de entrada analizando el código fuente y detectando fronteras y ramificaciones de los datos. Además pueden usarse datos de versiones anteriores.

26 Planeación de pruebas de unidad
Estime los recursos requeridos Use datos históricos si están disponibles para estimar personas/mes y la duración requerida Registre tiempo, cuenta de defectos, tipo y fuente Registrar tiempo dedicado a pruebas, cuenta de defectos y tipo de defectos Los resultados se usan para evaluar estado y pronosticar calidad que tendrá el producto

27 Lista de verificación para pruebas de métodos [Braude, pág. 407]
Verificar operación con valores normales (pruebas de caja negra basadas en requerimientos) Verificar operación en valores límite (caja negra) Verificar operación para valores fuera de límite (caja negra) Asegurar que se ejecuten todas las instrucciones (cubrimiento de declaraciones)

28 Lista de verificación para pruebas de métodos [Braude, pág. 407]
Verificar que todas las ramas se ejecuten (cubrimiento de decisiones) Verificar uso de todos los objetos llamados Verificar manejo de todas las estructuras de datos Verificar manejo de todos los archivos Verificar terminación normal/anormal de todos los ciclos

29 Lista de verificación para pruebas de métodos [Braude, pág. 407]
Verificar terminación normal/anormal de todas las recursiones Verificar manejo de todas las condiciones de error Verificar el tiempo y la sincronización Verificar todas las dependencias de hardware

30 Prueba de Unidad Centra el proceso de verificación en la menor unidad.
Se prueban los siguientes elementos: Interfaz (asegurar flujo de información) Estructura de datos locales (asegurar integridad en datos temporales) Condiciones Límite (asegurar que funciona en los límites establecidos) Caminos independientes (asegurar que todas las sentencias se ejecutan al menos una vez) Caminos de manejo de errores Módulo Casos de Prueba

31 Prueba de Unidad (Cont.)
Antes de iniciar otra prueba es p necesario probar el flujo de datos de la interfaz del módulo. Si los datos no entran correctamente las otras pruebas no tienen sentido Durante las pruebas de Unidad es esencial comprobar caminos específicos de ejecución Se deben diseñar casos de prueba para detectar: errores debido a cálculos incorrectos, comparaciones incorrectas o flujos de control inapropiados. La técnica apropiada es la de caja blanca, específicamente camino básico y de bucles

32 Prueba de Unidad (Cont.)
Un buen diseño exige que las condiciones de error sean prevista de antemano y se disponga de caminos de manejos de errores para que redirijan o hagan terminar el proceso cuando se de un error. Pero hay una tendencia a manipular los errores. Descripción ininteligible del error Error señalado no corresponde con el encontrado Condición de error hace que intervenga el sistema antes que el mecanismo de manejo de errores Procesamiento de la condición excepcional es incorrecto Descripción del error no es suficiente para localizarlo

33 Procedimientos de Prueba de Unidad Entorno para la prueba de unidad
Controlador Interfaz Estructuras de datos locales Modulo A probar Condiciones límite Caminos independientes Caminos de manejo de errores Resguardo Resguardo Casos de prueba RESULTADOS

34 Procedimientos de Prueba de Unidad Controladores y Resguardos
Como un componente no es un programa independiente, se debe desarrollar para cada prueba un software que controle y/o resguarde Controlador es un programa principal que acepta los datos, pasa estos datos al módulo e imprime los resultados importantes, es decir simula al módulo que llama y quizás el ambiente completo bajo el cual se prueba el módulo. Resguardo sirve para reemplazar los módulos que están subordinados al componente que hay que probar, lleva a cabo una mínima manipulación de datos.

35 Prueba de Integración Es una técnica sistemática para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción entre módulos. Objetivo: tomar los módulos probados mediante la prueba de unidad y construir una estructura de programa que este de acuerdo con lo que dicta el diseño. Técnicas recomendadas: caja negra, aunque se pueden realizar algunas de caja blanca para asegurar que se cubren los principales caminos de control

36 Prueba de Integración (Cont.)
Hay una tendencia a intentar una integración no incremental: mediante un enfoque bing bang, en donde se combinan todos los módulos por anticipado probando todo el programa en conjunto. Pero esto nos lleva a un caos porque es difícil aislar las causas al tener todo el programa. La integración incremental es lo contrario del bing bang. El programa se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y corregir. Para realizar las pruebas de integración existen diferentes estrategias de integración incremental: Integración descendente Integración ascendente

37 Pruebas de Integración: descendente
Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal. Las pruebas comienzan con el módulo superior y continua con cualquier módulo que puede ser llamado por el módulo superior o un módulo subordinado que ya ha sido probado. Al menos el módulo que llama (al módulo bajo prueba) debe haber sido probado previamente Los módulos subordinados al módulo de control principal se van incorporando en la estructura, de forma primero en profundidad o primero en anchura.

38 Pruebas de Integración: descendente (Cont.)
Primero en anchura: Incorpora todos los módulos directamente subordinados a cada nivel, moviéndose por la estructura en forma horizontal. Primero en profundidad: integra todos los módulos de un camino de control principal de la estructura. M1 M2 M3 M4 Profundidad M5 M6 M7 M8 Anchura

39 Pruebas de Integración: descendente
Ventaja: Verifica los puntos de decisión y de control que se dan al principio del proceso de prueba, y en una estructura descendente la toma de decisiones se da en los niveles altos de la jerarquía y por lo tanto, los problemas y errores se encuentran antes. Desventaja: se da un problema cuando se requiere un proceso de los niveles más bajos de la jerarquía para poder probar adecuadamente los niveles superiores. Al inicio de la prueba descendente, los módulo de bajo nivel se reemplazan por resguardos, lo que impide que fluyan datos significativos hacia arriba. El responsable de la prueba tiene tres opciones: retrasar muchas de las pruebas hasta que los resguardos sean reemplazados por los módulos reales (se pierde el control); desarrollar resguardos que realicen funciones limitadas que simulen los módulos reales (requiere mucho esfuerzo); integrar el software desde el fondo de la jerarquía hacia arriba es decir integración descendente.

40 Pruebas de Integración: descendente (Cont.)
Otros módulos Reales, ya probados Módulo en pruebas resguardos Otros módulos Otros módulos

41 Pruebas de Integración: Ascendente
Empieza con la prueba de uno o más módulos terminales (módulos en los niveles más bajos de la estructura del programa que no llama a otros módulos) y continua con cualquier módulo cuyo módulo subordinado ya ha sido probado. Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados siempre está disponible y se elimina la necesidad de resguardos. Desventaja: El programa como entidad no existe hasta que se ha añadido el último módulo. Ventaja: Mayor facilidad de diseño de casos de prueba y no son necesarios los resguardos.

42 Pruebas de Integración: Ascendente (Cont.)
MC Ma Mb D1 D2 D3 Grupo 3 Grupo 1 Grupo 2 Figura 18.7 de Pressman

43 Pruebas de Integración: Ascendente (Cont.)
Se puede implementar una estrategia mediante los siguientes pasos: Se combinan los módulos de bajo nivel en grupos que realizan una subfunción especial. Se escribe un controlador para coordinar la entrada y la salida de los casos de prueba Se prueba el grupo Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura de control. Refiérase a la figura 18.7 de Pressman

44 Pruebas de Integración: Pruebas de regresión
Hay dos tipos de pruebas de Regresión: Pulgas generadas después de solucionar una pulga: Pulga mal o no corregida Pulgas relacionadas que puedan existir Corrección desencadena otras pulgas Es necesario repetir las pruebas!

45 Pruebas de Integración: Pruebas de regresión (Cont.)
Cada vez que se añade un módulo nuevo como parte de una prueba de integración, el software cambia. Se establecen nuevos caminos del flujo de datos, pueden ocurrir nuevas E/S y se invoca una nueva lógica de control. Esto puede causar problemas con funciones que antes trabajaban bien La prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurar que los cambios no han propagado efectos colaterales no deseados.

46 Integración. Prueba de regresión (Cont.)
Contiene tres clases diferentes de casos de prueba: Una muestra representativa de prueba que ejercite todas las funciones del software. Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio. Pruebas que se centran en los componentes del software que han cambiado.

47 Integración: Prueba de Humo
Es diseñada como un mecanismo para proyectos críticos por tiempo, permitiendo que el equipo de software valore su proyecto sobre una base sólida. Se caracteriza por una estrategia de integración continua. El software es reconfigurado (con la incorporación de nuevos componentes) y utilizado continuamente. Beneficios Se minimizan los riesgos de integración. Se perfecciona la calidad del producto final. Se simplifica el diagnóstico y la corrección de errores. El progreso es fácil de observar.

48 Prueba de Humo Abarca las siguientes actividades: Los componentes de software traducidos a código se integran en una “construcción”. Se diseñan pruebas para exponer errores “paralizantes” que impedirán que la construcción realice apropiadamente su función. La construcción se integra con otras construcciones y diariamente se aplica una prueba de humo a todo el producto.

49 Prueba de Humo No debe ser exhaustiva, pero debe ser capaz de encontrar errores importantes. Debe ser tan completa que si la construcción se aprueba, puede suponerse que es suficientemente estable como para probarla de forma más completa.

50 Opciones Estratégicas
Las ventajas del enfoque descendente tienden a convertirse en desventajas del enfoque ascendente, y viceversa. La mejor opción es un enfoque combinado llamado “prueba sandwich”: usa pruebas descendentes para los niveles superiores, junto con pruebas ascendentes para niveles subordinados.

51 Estrategias de prueba para Software Orientado a Objetos
El objetivo de probar es encontrar la mayor cantidad de errores aplicando una cantidad manejable de esfuerzo en un periodo realista. El objetivo fundamental sigue sin cambio , pero la naturaleza del software orientado a objetos cambia la estrategia y la táctica de las pruebas.

52 Estrategia de prueba de software para arquitecturas orientadas a objetos
La estrategia general para el software orientado a objetos es similar a la que se aplica a las arquitecturas convencionales, pero presenta diferencias en el enfoque. Se empieza “probando lo pequeño” y se trabaja hacia el exterior “probando lo grande”. A medida que se integran clases, se haces pruebas de regresión para descubrir errores por comunicación y colaboración entre las clases (componentes). Por último, se prueba el sistema como un todo para asegurarse de que se descubran errores en los requisitos.

53 Pruebas de unidad y sus relaciones en un contexto OO
Tomado de Braude pág. 395

54 Prueba de unidad en el contexto O.O.
Una clase encapsulada suele ser el eje de las pruebas de unidad. Las unidades de prueba más pequeñas son las operaciones dentro de la clase. No es posible probar una sola operación de manera aislada, sino como parte de una clase. La prueba de clase para el software O.O. se orienta mediante las operaciones que encapsula la clase y en el comportamiento de estado de la clase.

55 Prueba de integración en el contexto Orientado a Objetos
El software O.O. no tiene estrategia obvia de control jerárquico, las estrategias ascendentes y descendentes tradicionales no son muy útiles. Hay dos estrategias para la prueba de integración de los sistemas O.O.: Prueba basada en subprocesos. Prueba basada en el uso.

56 Prueba de integración en el contexto O.O.(cont.)
Prueba basada en hilos: Integra el conjunto de clases requerido para responder a una entrada o un evento del sistema. Cada hilo se integra y prueba individualmente. La prueba de regresión se aplica para asegurar que no se presenten efectos colaterales.

57 Prueba de integración en el contexto O.O.(cont.)
Prueba basada en el uso: Empieza la construcción del sistema con la prueba de esas clases (llamadas clases independientes) que usan muy pocas clases de servidor (o ninguna). Después de que se prueban las clases independientes, se prueba la siguiente capa de clases, llamadas clases dependientes, que usan las clases independientes.

58 Prueba de integración en el contexto O.O.(cont.)
El uso de controladores y resguardos también cambia en este contexto. Controladores: se prueban operaciones al nivel más bajo y grupos completos de clases. También se utiliza para reemplazar la interfaz del usuario. Resguardos: se usan cuando la colaboración entre clases es necesaria, pero aún no se han implementado por completo.

59 Prueba de validación La validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente, las cuales están descritas en la Especificación de requerimientos. Técnica recomendada: caja negra. Para asegurar que se satisfacen los requisitos funcionales, de rendimiento y otros como (portablidad, facilidad de mantenimiento, etc.) es necesario: un plan de prueba (define las clases de prueba que se van a llevar a cabo) y un procedimiento de prueba (define los casos de prueba específicos para descubrir errores de acuerdo a los requisitos).

60 Prueba de validación Como resultado de la prueba de validación se pueden dar dos condiciones: Características de funcionamiento o rendimiento están de acuerdo a lo especificado y el resultado es aceptable Se descubre desviación de las especificaciones y se crea lista de deficiencias Estas desviaciones rara vez se pueden corregir antes de la fecha de terminación planificada A menudo hay que negociar con el cliente para resolver deficiencias

61 Prueba de validación La revisión de la configuración:
Busca que todos los elementos de la configuración del software se hayan desarrollado apropiadamente, estén catalogados y tengan el detalle suficiente para reforzar la fase de soporte del ciclo de vida del software.

62 Pruebas de validación: Pruebas alfa y beta
Se deben realizar una serie de pruebas de aceptación para permitir que el cliente valide todos los requisitos. Las realiza el usuario final. Si el software va a ser usado por muchos clientes no son convenientes pruebas formales sino: PRUEBAS ALFA: se lleva a cabo, por un cliente, en el lugar de desarrollo, en un entorno controlado. El desarrollador registra los errores y problemas de uso. PRUEBAS BETA: se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes, entorno no es controlado, el cliente registra todos los problemas e informa en intervalos regulares al desarrollador.

63 Pruebas del sistema Propósito: ejercitar profundamente el sistema, verificar que se han integrado adecuadamente todos los elementos del sistema. Hay 4 tipos: Recuperación: fuerza el fallo de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente Seguridad: verifica que los mecanismos de protección lo protegerán de accesos impropios

64 Pruebas del sistema(Cont.)
Esfuerzo: ejecuta el sistema de manera que demande recursos en cantidad, frecuencia o volúmenes anormales Rendimiento: prueba el rendimiento en tiempos de ejecución. Se da durante todo el proceso de prueba Despliegue: ejercita software en c/entorno, examina procedimientos y software de instalación

65 El Arte de la Depuración
La depuración ocurre como consecuencia de una prueba efectiva. Cuando se descubre un error, la depuración es el proceso que provoca la eliminación del error. Por medio de la depuración se conecta el síntoma (manifestación externa del error) con una causa. Se consigue mediante una combinación de una evaluación sistemática, de intuición y de suerte.

66 El Proceso de Depuración
Todo comienza con la ejecución de un caso de prueba, se evalúan resultados y se encuentra una falla Se trata de relacionar la falla con la causa y así corregir el error Siempre se obtiene uno de dos posibles resultados: se encuentra y localiza la causa, o no. Si esto último ocurre debemos sospechar la causa y diseñar pruebas para validar esa sospecha. Esto se realiza iterativamente hasta lograr la corrección.

67

68 ¿Por qué es tan difícil depurar?
El síntoma y la causa pueden estar separados. El primero ocurre en una parte del programa, mientras que la causa en un sitio distante. Es posible que el síntoma desaparezca al corregir otro error. El síntoma no lo causa un error (ej.Inexactitudes al redondear cifras). El síntoma se debe a un error humano difícil de localizar.

69 ¿Por qué es tan difícil depurar?
El síntoma se debe a problemas de tiempo, no de procesamiento. Tal vez sea difícil reproducir las condiciones de entrada (aplicación en tiempo real). El síntoma podría presentarse intermitentemente (común en sistemas empotrados que acoplan hardware y software de forma muy complicada).

70 Estrategias de Depuración
Existen diferentes enfoques para “aprender a depurar” pero el objetivo es el mismo: encontrar y corregir la causa de un error de software. Tácticas de depuración: Fuerza Bruta Seguimiento hacia atrás Eliminación de la causa

71 Estrategias de Depuración
Fuerza Bruta: Método mas común y menos eficiente. Solo se aplica cuando todo lo demás falla. Se invocan señales en tiempo de ejecución, se carga el programa con instrucciones de salida. Lo que se espera es encontrar una pista que pueda conducir a la causa de un error. Con este método, aunque se pueda corregir el error, lo mas frecuente es que haga desperdiciar tiempo y esfuerzo.

72 Estrategias de Depuración
Seguimiento hacia atrás: Muy común. Éxito en programas pequeños. Se empieza en el sitio donde se ha descubierto un síntoma, se recorre hacia atrás el código fuente de forma manual, hasta hallar el sitio de la causa. Al aumentar las LDC, la cantidad de caminos hacia atrás aumenta tanto que resulta muy difícil.

73 Estrategias de Depuración
Eliminación de Causas: Se utiliza la deducción y el concepto de partición binaria. Los datos relacionados con el error se organizan para aislar las causas posibles. Con estos datos se prueba o desecha una “hipótesis de la causa”. Si las pruebas indican que esta hipótesis es prometedora se refinan los datos para aislar el error. Se puede hacer una lista de todas las causas posibles y realizar pruebas para eliminar cada una de ellas.

74 Relación entre las Pruebas y la Depuración

75 Corrección del Error Preguntas simples que debe hacerse antes de realizar la corrección: ¿Se repite la causa del error en otra parte del programa? Al tratar de corregir el error ¿qué nuevo error podríamos introducir si no tenemos cuidado? ¿Qué había que hacer desde el principio para evitar este error?

76 Depuración Automatizada
Existen herramientas que ayudan de forma automatizada a depurar problemas de software. Su objetivo es proporcionar información difícil de obtener, si se realiza la depuración manualmente. La mayoría de estas herramientas dependen del lenguaje de programación y el entorno. Estas no son un sustituto de la evaluación cuidadosa basada en un buen modelo de diseño y un código fuente claro. Nota: investigar y exponer alguna herramienta

77 El Factor Humano Ninguno de los enfoques, ni las herramientas de depuración estarían completos sin mencionar un poderoso aliado: los demás. Un último consejo a la hora de depurar: “Cuando todo lo demás falle, pida ayuda!”

78 Bibliografía Braude, Eric. Ingenieria de Software: Una Perspectiva Orientada a Objetos. Ra-Ma, 2003 Kaner, Cem. Falk, Jack. Quoc Nguyen, Hung. Testing Computer Software. Wiley Computer Publishing. Second Edition,1999 Pressman, Roger. Ingeniería del Software; Un Enfoque Práctico. Mc Graw Hill, 2002