4.2.5. Evaluar resultados. (Depuración y Análisis de errores.

) La depuración es el proceso de analizar y corregir los defectos que se sospecha que contiene el software.

Figura 4.4 Relación entre las pruebas y la depuración Consejos para la depuración: Localización del error  Analizar la información y pensar (analizar bien, en lugar de aplicar un enfoque aleatorio de búsqueda del defecto)  Al llegar a un punto muerto, pasar a otra cosa (refresca la mente)  Al llegar a un punto muerto, describir el problema a otra persona (el simple hecho de describir el problema a alguien puede ayudar)  Usar herramientas de depuración sólo como recurso secundario (no sustituir el análisis mental)  No experimentar cambiando el programa (no sé qué está mal, así que cambiaré esto y veré lo que sucede)  Se deben atacar los errores individualmente  Se debe fijar la atención también en los datos (no sólo en la lógica del programa) Corrección del error  Donde hay un defecto, suele haber más (lo dice la experiencia).  Debe fijarse el defecto, no sus síntomas (no debemos enmascarar síntomas, sino corregir el defecto).  La probabilidad de corregir perfectamente un defecto no es del 100% (cuando se corrige, hay que probarlo).  Cuidado con crear nuevos defectos (al corregir defectos se producen otros nuevos).  La corrección debe situarnos temporalmente en la fase de diseño (hay que retocar desde el comienzo, no sólo el código).  Cambiar el código fuente, no el código objeto.

El objetivo del análisis causal es proporcionar información sobre la naturaleza de los defectos. Para ello es fundamental recoger para cada defecto detectado esta información:  ¿Cuándo se cometió?

3. Las pruebas requieren que el desarrollador descarte nociones preconcebidas de lo que es correcto en el software y entonces diseñe diferentes casos de prueba para romperlo. Controlabilidad: Cuanto mejor se controle el software. La prueba de caja blanca. con mayor eficiencia podrá probarse. es un método de diseño que usa la estructura de control descrita como parte del diseño al nivel de componentes para derivar los caso de prueba: 1) Garanticen que todos las rutas independientes dentro del modulo se han ejercitado por lo menos una vez. con mayor inteligencia se aplicara la prueba. También se utiliza para predecir futuros fallos software. 6) Estabilidad: cuanto menos cambios haya. en ocasiones llamada prueba de caja de cristal. Fundamentos de las pruebas del software La facilidad de prueba de software indica simplemente si es fácil o no probar un programa de software (J. Pruebas de caja negra y caja blanca A.2.  Simplicidad estructural: la arquitectura aparece en módulos para limitar la propagación de fallas.      ¿Quién lo hizo ¿Qué se hizo mal? ¿Cómo se podría haber prevenido? ¿Por qué no se detectó antes? ¿Cómo se podría haber detectado antes? ¿Cómo se encontró el error? Esta información no debería ser usada para evaluar al personal.3. 2) Ejerciten los lados verdadero y falso de todas las decisiones lógicas . Técnicas de diseño de casos de pruebas. 5) Simplicidad: el programa debe mostrar:  Simplicidad funcional: el menor número de características para satisfacer los requisitos. Bach 1994). menos alteraciones habrá en la prueba. 4. sino para la formación del mismo sobre cómo prevenir los errores. Capacidad para descomponer: controlar el alcance de la prueba.1. 4. 7) Facilidad de comprensión: cuando mayor información se tenga.  Simplicidad de código: codificación estándar para facilitar inspección y mantenimiento. mejor se automatizan las pruebas. para aislar los problemas y así realizar nuevamente las pruebas con mayor inteligencia. 4. Las siguientes características proporcionan la creación de software que tenga facilidad de prueba: 1) 2) 3) 4) Operatividad: Cuanto mejor funcione.3. Observabilidad: Lo que se ve es lo que se prueba.

también denominadas. En todos los casos. además requiere comunicación y colaboración. 1) Funciones incorrectas o faltantes 2) Errores de interfaz 3) Errores en estructuras de datos o en accesos a bases de datos externas 4) Errores de comportamiento o desempeño 5) Errores de inicialización y termino Estas se realizan durante las últimas etapas de las pruebas. Métodos de pruebas orientadas a objetos Esta estrategia empieza probando lo pequeño y se trabaja hacia el exterior probando lo grande. 3. 4. Se realizan pruebas de regresión para descubrir errores debidos a la comunicación y colaboración entre clases (componentes) y a los efectos colaterales que origina la adicción de nuevas clases.3. La prueba de caja negra. se concentran en los requerimientos de software. Por último se prueba el sistema como un todo para asegurar que se descubran errores en los requisitos.3) Ejecuten todos los bucles en sus límites y dentro de sus límites operacionales 4) Ejerciten estructuras de datos internos para asegurar su validez B.3. centrándose en el dominio de la información. permiten derivar conjuntos de condiciones de entrada que ejercitarán por completo todos los requisitos funcionales de un programa. 2. trata de encontrar errores en las siguientes categorías. 4.3. Enfoque práctico recomendado para el diseño de casos.4. Se propone un uso más apropiado de cada técnica (caja blanca y negra) para obtener un conjunto de casos útiles:   Si la especificación contiene combinaciones de condiciones de entrada. Debido a que desatiende va propósito las estructuras de control. Pruebas de interfaces graficas de usuario (GUI): Pruebas de arquitectura cliente/servidor: Prueba de la documentación y las funciones de ayuda: Prueba de sistema de tiempo real: 4. Pruebas de entornos especializados: arquitecturas y aplicaciones Esta se basa en las pruebas de los entornos. 4. cambiando el concepto de modulo individual de la prueba convencional a una clase que abarca atributos y operaciones y que. arquitecturas y las aplicaciones específicas que suelen encontrarse. .4. usar el análisis de valores límites para añadir casos de prueba: elegir límites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase de equivalencia. Es decir. pruebas de comportamiento. comenzar formando sus grafos de causa-efecto (ayuda a la comprensión de dichas combinaciones). 1.

Un enfoque estratégico para la prueba de software 4. 4. 3. así como los elementos a probar. las características. 14.4. Culminar con la aceptación del producto por parte del cliente. y añadir los casos no incluidos anteriormente. Estructura fijada en el estándar: 1. 13. Utilizar la técnica de conjetura de errores para añadir nuevos casos.    Identificar las clases válidas y no válidas de equivalencia para la entrada y la salida.4. Continuar hacia la integración del sistema completo y a su instalación. 6. 9. .1 Señalar el enfoque.5. 12. 10. referidos a valores especiales. 11. La estrategia de pruebas suele seguir estas etapas:    Comenzar pruebas a nivel de módulo.2 Identificador único del documento Introducción y resumen de elementos y características a probar Elementos software a probar Características a probar Características que no se probarán Enfoque general de la prueba Criterios de paso/fallo para cada elemento Criterios de suspensión y requisitos de reanudación Documentos a entregar Actividades de preparación y ejecución de pruebas Necesidades de entorno Responsabilidades en la organización y realización de las pruebas Necesidades de personal y formación Esquema de tiempos Riesgos asumidos por el plan y planes de contingencias Aprobaciones y firmas con nombre y puesto desempeñado Aspectos Estratégicos 4. 4.1. 16. 15. Estrategias de aplicación de las pruebas.5. 8. Examinar la lógica del programa para añadir los casos precisos (de caja blanca) para cumplir el criterio de obertura elegido si los resultados de la ejecución del punto anterior indican que no se ha satisfecho el criterio de cobertura elegido. 4. el personal responsable y los riesgos asociados. 5. 7. los recursos y el esquema de actividades de prueba. De unidad. Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida. 2. las actividades de prueba.

Habitualmente las pruebas de unidad y de integración se solapan y mezclan en el tiempo.3. Descendente. Se prueba cada módulo por separado y luego se integran todos de una vez y se prueba el programa completo. Del sistema. pero evitando quesea el propio programador del módulo. Se combina el siguiente módulo que se debe probar con el conjunto de módulos que ya han sido probados. . considerando el producto software final al completo en un entorno de sistema. Implican una progresión ordenada de pruebas que van desde los componentes o módulos y que culminan en el sistema completo. 1986a]: • Todos son del mismo programa • Al menos uno de ellos no ha sido probado • El conjunto de módulos es el objeto de un proceso de prueba La prueba de unidad puede abarcar desde un módulo hasta un grupo de módulos (incluso un programa completo).5.Se trata de las pruebas formales que permiten declarar que un módulo está listo y terminado (no las informales que se realizan mientras se desarrollan los módulos). Se comienza por los módulos hoja. Estas pruebas suelen realizarlas el propio personal de desarrollo.5. De integración. Integración no incremental. 4. 4. El orden de integración elegido afecta a diversos factores. o o Ascendente.2. como lo siguientes:      La forma de preparar casos Las herramientas necesarias El orden de codificar y probar los módulos El costo de la depuración El costo de preparación de casos Tipos de Pruebas de integración:   Integración incremental. Es el proceso de prueba de un sistema integrado de hardware y software para comprobar lo siguiente:  Cumplimiento de todos los requisitos funcionales. Hablamos de una unidad de prueba para referirnos a uno o más módulos que cumplen las siguientes condiciones [IEEE. Se comienza por el módulo raíz.

Sus características principales son las siguientes:  Participación del usuario. Fuentes de diseño de casos de prueba del sistema     Casos basados en los requisitos gracias a técnicas de caja negra aplicadas a las especificaciones.   El funcionamiento y rendimiento en las interfaces hardware. software. De aceptación. Adecuación de la documentación de usuario. Casos necesarios para probar el rendimiento del sistema y de su capacidad funcional (pruebas de volumen de datos. Ejecución y rendimiento en condiciones límite y de sobrecarga.  Está enfocada hacia la prueba de los requisitos de usuario especificados. Está considerada como la fase final del proceso para crear una confianza en que el producto es el apropiado para su uso en explotación .). Casos basados en el diseño de alto nivel aplicando técnicas de caja blanca a los flujos de datos de alto nivel (por ejemplo.4. de usuario y de operador. etc. Es la prueba planificada y organizada formalmente para determinar si se cumplen los requisitos de aceptación marcados por el cliente. de límites de procesamiento. 4. de los diagramas de flujo de datos).5. Este tipo de pruebas suelen llamarse pruebas de sobrecarga (stress testing).

. 57:0-./05705.7.70  8419..4/1.830.4254303908 4 2O/:48  6:0 .7.2O/:4547805.O3   25.303090254      088902.7 4 8:0390  O :2520394/094/4848706:89481:3.8/0:3/..7. /0 :3/..078481.43 0 .-9:..42-3.   8 0 574.4894/05705.:84 :3 5747.8/4574-./4 34.38/4574-.05747./47/02O/:4      03907.81472.7482O/:48 O ..O3 3.2.8 6:0 .9. :3/.086:08070..2./.42509403:30394734/088902.9.7.1472.9.948419.086:05072903/0.857:0-.... :3 7:54 /0 2O/:48 3. .O3343..8/03907.  4 08.3 /08/0 48 ...03/0390 $0.O3/0.7 .7.43:394/02O/:480804-094/0:3574.  . .7013.2039.42448:03908  O ./. $057:0-.  $0 .7574-. 5./..547482O/:484.774.-.848 O .2.O300/4./0./ /0 57:0-..425094   47/03/03907.08057:0-.O3  O 3907.  .10.4308 .084 /0 57:0-..2.394/48 /0:3.425094   89.3482O/:48   ..76:0:32O/:4089E89490723. 0 57454 5747./4 W. 0 8:0390 2O/:4 6:0 80 /0-0 574-..42574-..7. W20348:34/004834.857:0-.08.//03907.7744  5074 0.(  W%4/48843/028245747.425094   4 8.8 8:03908.J   .O3 O ..4894/0./ 5:0/0 .8 57:0-.43/...43:394/02O/:486:0.3/4 6:080. /0 57:0-.8 8:003 70.. /0 :3 88902. 701077348 .-...43.89.320.03/0390 $0.880/08.7 /08/0 :3 2O/:4 .8077.8 0 57454 507843.O38084..702039.8 31472./48  O 3907. 3907. /0 /08.5.7.7..320397.702039.3 :3.084/057:0-.20390.303088902.248 /0 :3.94708 .7./4 /0 .7./05:7.70 5.438/07.08 .54702O/:47.7/.4203.8 O 47/03/0.3/40574/:. :34 4 2E8 2O/:48 6:0 .:23. 574708O3 47/03..:2503 .848  %548/0!7:0-.4203.$097./4:04803907.

7.4308J290/084-70./..78057:0-.O3703/2039403.036:00574/:.70./.8../47  O /0. .059..7880.8/01:4/0/..0390   $:8.943..08.5.3.74  O 0.O3 .0 54700254 /048/...438/07..2.. ./048706:8948/0:8:./088902.O3   8.7/. 57:0-.8/084-70./.47.   :03908/0/80N4/0.1.94 3.203905.0./485470.08 .74  /0 4507.31.3.8 /0 .1./090723.88:03908  O !.08843.7.7./...7.5..7:3../..907J89.8::84030549.  /0 8: ..848 30.8 ../ 1:3.-.948 /0J2908/0574..948      0.948/0.8.5745.O32./45..79. 307..7 0 703/20394 /0 88902.5.1. 574-./48 03 0 /80N4 /0..748 5.059.5.2.0845.:.7.8 39071./48  89E.7..  O 890954/057:0-.43. 9F.5..481:48 /0 /..43/.1472.848 -.5. 89708890893  O ...8 .43.88:003.424.8573.7...8/0./0574.3...8/0 ./48 03 48 706:8948 7.20394  703/20394 03 ..848/057:0-.:250348706:8948/0 .57:0-...57:0-.70  8419.O3/0..08..3/49F.8013./.4:203/0/.:2039...:.7...94080 ..4308  O .20394 09.740850.3.74  O 89E0314.8 0850.848-./4.431.O3/0:8:.O  1:3.  O ...3.70  /0 :8:..7.O3/0:8:.