VI PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

6.1 PRUEBAS DEL SOFTWARE

Una vez generado el cdigo el software debe ser probado para descubrir el mximo de errores posibles antes de su entrega al cliente. Es probado para descubrir errores cometidos sin darse cuenta al realizar su diseo y construccin La prueba requiere una mayor cantidad del esfuerzo dedicado al proyecto que cualquier otra actividad de ingeniera del software

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 ejecucin de un programa con la intencin 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.

6.1 PRUEBAS DEL SOFTWARE

OBJETIVOS Por lo tanto hay que disear pruebas que saque a la luz diferentes clases de errores, hacindolo 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

6.1 PRUEBAS DEL SOFTWARE

PRINCIPIOS Para realizar pruebas efectivas un equipo de software debe efectuar revisiones tcnicas 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 integracin de todo el sistema de cmputo. Las pruebas deberan empezar por lo "pequeo" y progresar hacia "lo grande" ( mdulos )

6.1 PRUEBAS DEL SOFTWARE

PRINCIPIOS Diferentes tcnicas 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 deberan planificarse mucho antes de que empiecen La prueba y la depuracin son actividades diferentes, pero ambas se incluyen en la estrategia de pruebas.

6.1 PRUEBAS DEL SOFTWARE

PRINCIPIOS A todas las pruebas se les debera 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 deberan ser realizadas por un equipo independiente

6.1 PRUEBAS DEL SOFTWARE

PRINCIPIOS Psicologicamente constructivas. el analisis y diseno son tareas

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.

6.2 FACILIDAD DE PRUEBA

La facilidad de prueba es la facilidad con que se puede probar un programa de computadora.

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, ningn error bloqueara la ejecucin de pruebas Observabilidad: lo que se ve es lo que se prueba, se genera una salida distinta para cada entrada, los estados y variables estn visibles y se pueden consultar durante la ejecucion, un resultado incorrecto se identifica fcilmente, se informa de los errores internos, el cdigo fuente es accesible

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 combinacin de entrada, los formatos de entrada y resultados son consistentes y estructurados; las pruebas se pueden especificar, automatizar y reproducir.

6.2 FACILIDAD DE PRUEBA

CARACTERISTICAS Capacidad de descomposicin : 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 rpido se hara, ( tipos: funcional, estructural y de cdigo ) ej: mnimo de caractersticas para cumplir con los requisitos, arquitectura modular, estandar para facil inspeccion y mantenimiento.

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 comprensin : cuanta mas informacin tengamos, mas inteligentes sern las pruebas, se entiende el diseo, las dependencias y la documentacin, si son especificas, detalladas y exactos.

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

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.

6.3 CASOS DE PRUEBA

CAJA BLANCA Y CAJA NEGRA El software debe probarse desde dos perspectivas diferentes: la lgica interna del programa utilizando tcnicas de diseo de casos de prueba de "caja blanca" los requisitos del software utilizando tcnicas de diseo de casos de prueba de "caja negra"

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.

6.3 CASOS DE PRUEBA

CAJA BLANCA Este mtodo obtiene casos de prueba que: * garanticen que se ejercitan por lo menos una vez todos los caminos independientes de cada mdulo. * ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa. * ejecuten todos los bucles en sus lmites y con sus lmites operacionales. * y ejerciten las estructuras internas de datos para asegurar su validez.

6.3 CASOS DE PRUEBA

CAJA BLANCA Tipos de Prueba: Prueba de la Ruta Basica Pruebas de la estructura de control Prueba de condicion Prueba del flujo de datos Prueba de bucles

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 inicializacin y de terminacin.

6.3 CASOS DE PRUEBA

CAJA NEGRA Tipos de Prueba: 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 comunicacin de red Pruebas de documentacion Pruebas de sistemas de tiempo real

6.4 ESTRATEGIAS DE PRUEBA

Prueba del sistema

Prueba de validacion

Prueba de integracion

Prueba de Unidad

Codigo

Diseno Requisitos

Ingenieria del Sitema

6.4 ESTRATEGIAS DE PRUEBA

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

Cmo fu ? Por qu ? Cunto cost ? Qu se hizo ?