1 Capítulo 17 Pressman. Las pruebas son un conjunto de actividades que se pueden planificar por...

Estrategias de prueba del

software

1

Capítulo 17 Pressman

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


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.

La prueba la lleva a cabo: el responsable

del desarrollo del software y

un grupo independiente de pruebas.

*Quién realiza las pruebas ???

7


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

o El responsable del desarrollo no debería entrar en el proceso de prueba.

o El software debe ser “puesto a salvo” de extraños que puedan probarlo de forma despiadada.

o Los encargados de la prueba sólo deben aparecer en el proyecto cuando comienzan la etapa de pruebas.

12


¿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


¿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

Ingeniería del sistema Requisitos

Diseño

Código

Prueba del Sistema

Prueba de ValidaciónPrueba de Integración

Prueba de Unidad

Los niveles de pruebas se puede ver en el contexto de una espiral.

16

Una estrategia de prueba del software

Pruebas de Alto NivelPruebas de Validación

Pruebas de Alto NivelPruebas de Validación

Pruebas de Unidad

Pruebas de Unidad

Pruebas de Integración

Pruebas de Integración

Dirección de la Prueba

Codificación

Diseño

Requisitos

Etapas de la Prueba de Software

Pruebas de Caja Blanca

Prueba de Caja Negra y algunas pruebas de Caja Blanca

Pruebas de Caja Negra

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.

Mapa conceptual típico de las pruebas de Unidad [Braude pág. 396-397]

IEEE 1008-1987

Tomado de [2]

Está basado en el estándar IEEE 1008-1987

*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

*Planeación y ejecución de las pruebas de Unidad

•Pasos que requiere el estándar IEEE 1008-1987 para las pruebas de Unidad:

1. Planear el enfoque general, recursos y tiempos.

2. Determinar características con base en los requerimientos que deben probarse.

3. Refinar el plan general

4. Diseñar un conjunto de pruebas

5. Implementar el plan y diseño refinados

6. Ejecutar los procedimientos de pruebas

7. Verificar que terminen

8. Evaluar el esfuerzo y la unidad de pruebas

* Planeación de pruebas de unidad [Braude pág. 406-407]

1. 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

2. Decida cómo documentarlas

• Definir procedimientos de prueba, datos de entrada, código, datos de salida

* Planeación de pruebas de unidad

3. 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?


4. 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.


5. Estime los recursos requeridos

• Use datos históricos si están disponibles para estimar personas/mes y la duración requerida

6. 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

* Lista de verificación para pruebas de métodos [Braude, pág.

407]

1. Verificar operación con valores normales (pruebas de caja negra basadas en requerimientos)

2. Verificar operación en valores límite (caja negra)

3. Verificar operación para valores fuera de límite (caja negra)

4. Asegurar que se ejecuten todas las instrucciones (cubrimiento de declaraciones)


407]

5. Verificar que todas las ramas se ejecuten (cubrimiento de decisiones)

6. Verificar uso de todos los objetos llamados

7. Verificar manejo de todas las estructuras de datos

8. Verificar manejo de todos los archivos

9. Verificar terminación normal/anormal de todos los ciclos


407]

10.Verificar terminación normal/anormal de todas las recursiones

11.Verificar manejo de todas las condiciones de error

12.Verificar el tiempo y la sincronización

13.Verificar todas las dependencias de hardware

Prueba de Unidad

• Centra el proceso de verificación en la menor unidad.

• Se prueban los siguientes elementos:

30

MóduloInterfaz (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 erroresCasos 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

Modulo A probar

Resguardo Resguardo

Controlador

RESULTADOS

Interfaz

Estructuras de datos locales

Condiciones límite

Caminos independientes

Caminos de manejo de errores

Casos de prueba

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.

M4M3M2

M1

M5 M6

M8

M7

Anchura

Pro

fund

idad

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

Módulo en pruebas

Otros módulos

Otros módulos

Reales,ya probados

Otros módulos

resguardos

Pruebas de Integración: descendente (Cont.)

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.)

Ma

MC

D1 D2 D3

Mb

Gru

po 1

Grupo 2

Grupo 3

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

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.

Integración. Prueba de regresión (Cont.)

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 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


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

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


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

*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.

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


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


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

1 Capítulo 17 Pressman. Las pruebas son un conjunto de actividades que se pueden planificar por...

Documents

Transcript of 1 Capítulo 17 Pressman. Las pruebas son un conjunto de actividades que se pueden planificar por...