PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

Transcripción

1 VI PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

2 6.1 PRUEBAS DEL SOFTWARE Una vez generado el código el software debe ser probado para descubrir el máximo de errores posibles antes de su entrega al cliente. Es probado para descubrir errores cometidos sin darse cuenta al realizar su diseño y construcción La prueba requiere una mayor cantidad del esfuerzo dedicado al proyecto que cualquier otra actividad de ingeniería del software

3 6.1 PRUEBAS DEL SOFTWARE OBJETIVOS El ingeniero crea una serie de casos de prueba que intentan "demoler" el software que ha sido construido. Tiene como objetivos: (1) La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. (2) Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. (3) Una prueba tiene éxito si descubre un error no detectado hasta entonces.

4 6.1 PRUEBAS DEL SOFTWARE OBJETIVOS Por lo tanto hay que diseñar pruebas que saque a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo. Inclusive tiene como ventaja ver hasta qué punto las funciones parecen funcionar de acuerdo con las especificaciones y cumplir así los requisitos de rendimiento

5 6.1 PRUEBAS DEL SOFTWARE PRINCIPIOS Para realizar pruebas efectivas un equipo de software debe efectuar revisiones técnicas formales y efectivas. Esto elimina muchos errores antes de empezar las pruebas. La prueba comienza al nivel de componentes y trabaja hacia fuera, hacia la integración de todo el sistema de cómputo. Las pruebas deberían empezar por lo "pequeño" y progresar hacia "lo grande" ( módulos )

6 6.1 PRUEBAS DEL SOFTWARE PRINCIPIOS Diferentes técnicas de prueba son apropiadas en diferentes momentos. La prueba la dirige el desarrollador del software y en proyectos grandes un grupo independiente de pruebas. Las pruebas deberían planificarse mucho antes de que empiecen La prueba y la depuración son actividades diferentes, pero ambas se incluyen en la estrategia de pruebas.

7 6.1 PRUEBAS DEL SOFTWARE PRINCIPIOS A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente No son posibles las pruebas exhaustivas ( imposible ejecutar todas las combinaciones de caminos ) Pasa ser mas eficaces, las pruebas deberían ser realizadas por un equipo independiente

8 6.1 PRUEBAS DEL SOFTWARE PRINCIPIOS Psicologicamente el analisis y diseno son tareas constructivas. El ingeniero se siente orgulloso de lo que acaba de construir. Un error es disenar y ejecutar pruebas que solamente demuestren el buen funcionamiento del programa en lugar de descubrir errores.

9 6.2 FACILIDAD DE PRUEBA La facilidad de prueba es la facilidad con que se puede probar un programa de computadora.

10 6.2 FACILIDAD DE PRUEBA CARACTERISTICAS Operatividad: cuanto mejor funcione, con mayor eficiencia podra probarse, si el sistema tiene pocos errores al disenarse con calidad, ningún error bloqueara la ejecución de pruebas Observabilidad: lo que se ve es lo que se prueba, se genera una salida distinta para cada entrada, los estados y variables están visibles y se pueden consultar durante la ejecucion, un resultado incorrecto se identifica fácilmente, se informa de los errores internos, el código fuente es accesible

11 6.2 FACILIDAD DE PRUEBA CARACTERISTICAS Controlabilidad: cuanto mejor se controle el software, mejor se automatizaran y mejoraran las pruebas, se controlan directamente los estados y variables de software y hardware. Todos los resultados posibles se generan con alguna combinación de entrada, los formatos de entrada y resultados son consistentes y estructurados; las pruebas se pueden especificar, automatizar y reproducir.

12 6.2 FACILIDAD DE PRUEBA CARACTERISTICAS Capacidad de descomposición : controlando el ámbito de las pruebas podemos aislar los problemas y llevar a cabo mejores pruebas, al usar modularidad, se pueden probar independientemente. Simplicidad : cuanto menos haya que probar, mas rápido se hara, ( tipos: funcional, estructural y de código ) ej: mínimo de características para cumplir con los requisitos, arquitectura modular, estandar para facil inspeccion y mantenimiento.

13 6.2 FACILIDAD DE PRUEBA CARACTERISTICAS Estabilidad: cuanto menos cambios haya, menores alteraciones habra en la prueba, los cambios son infrecuentes, controlados y no invalidan las pruebas existentes, el software se recupera bien de las fallas. Facilidad de comprensión : cuanta mas información tengamos, mas inteligentes serán las pruebas, se entiende el diseño, las dependencias y la documentación, si son especificas, detalladas y exactos.

14 6.2 FACILIDAD DE PRUEBA BUENA PRUEBA si tiene una elevada probabilidad de encontrar un error si no es redundante ( sin repetir ) debe ser la mejor de su clase ( altas probabilidades encontrar errores ) no debe ser ni muy simple ni demasiado compleja

15 6.3 CASOS DE PRUEBA CAJA BLANCA Y CAJA NEGRA Hay dos maneras de probar cualquier producto: 1) Si se conoce la funcion especifica para la que se diseno el producto se aplican pruebas que demuestren que cada funcion es plenamente operacional, mientras se buscan los errores de cada funcion. 2) Si se conoce el funcionamiento interno el producto, se aplican pruebas para asegurar que todas las piezas encajen, es decir, que las operaciones internas se realicen de acuerdo con las especificaciones.

16 6.3 CASOS DE PRUEBA CAJA BLANCA Y CAJA NEGRA El software debe probarse desde dos perspectivas diferentes: la lógica interna del programa utilizando técnicas de diseño de casos de prueba de "caja blanca" los requisitos del software utilizando técnicas de diseño de casos de prueba de "caja negra"

17 6.3 CASOS DE PRUEBA CAJA BLANCA Y CAJA NEGRA Las pruebas de caja blanca se basan en un examen cercano al detalle procedural, examinando condiciones y ciclos. La pruebas de caja negra se aplican a la interfaz del software, examinando el aspecto funcional del sistema.

18 6.3 CASOS DE PRUEBA CAJA BLANCA Este método obtiene casos de prueba que: * garanticen que se ejercitan por lo menos una vez todos los caminos independientes de cada módulo. * ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa. * ejecuten todos los bucles en sus límites y con sus límites operacionales. * y ejerciten las estructuras internas de datos para asegurar su validez.

19 6.3 CASOS DE PRUEBA Tipos de Prueba: CAJA BLANCA Prueba de la Ruta Basica Pruebas de la estructura de control Prueba de condicion Prueba del flujo de datos Prueba de bucles

20 6.3 CASOS DE PRUEBA CAJA NEGRA Es un complemento que intenta descubrir diferentes errores que la otra prueba realiza, tales como: funciones incorrectas ó ausentes errores de interfaz errores en estructuras de datos ó en accesos a bases de datos externas errores de rendimiento errores de inicialización y de terminación.

21 6.3 CASOS DE PRUEBA Tipos de Prueba: CAJA NEGRA Metodos graficos de prueba Particion Equivalente Analisis de valores limite Prueba de tabla ortogonal Pruebas de interfaces graficas Prueba de arquitectura cliente/servidor Pruebas de servidor Pruebas de base de datos Preubas de transaccion Pruebas de comunicación de red Pruebas de documentacion Pruebas de sistemas de tiempo real

22 6.4 ESTRATEGIAS DE PRUEBA Prueba del sistema Prueba de validacion Prueba de integracion Prueba de Unidad Codigo Diseno Requisitos Ingenieria del Sitema

23 6.4 ESTRATEGIAS DE PRUEBA 1. Nasa s The Voyager bug (sent the probe into the sun). 2. The AT&T bug that took out 1/3 of US telephones. 3. The DCS bug that took out the other 1/3 a few months later. 4. The Intel Pentium chip bug (it was software, not hardware). 5. The Ariane V bug. Cómo fué? Por qué? Cuánto costó? Qué se hizo?