Fase de Pruebas Introduccin.

El desarrollo de sistemas de software implica una serie de actividades de produccin en las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el inicio del proceso, en el que los objetivos pueden estar especificados de forma errnea o imperfecta, as como dentro de pasos de diseo y desarrollo posteriores..

Introduccin.
Debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo de software ha de ir acompaado de una actividad que garantice la calidad
La prueba del software es un elemento crtico para la garanta de calidad del software y representa una revisin final de las especificaciones, del diseo y de la codificacin.

Objetivos de la prueba
Los objetivos principales de realizar una prueba son: Detectar un error. Tener un buen caso de prueba, es decir que tenga ms probabilidad de mostrar un error no descubierto antes. Descubrir un error no descubierto antes (xito de la prueba).

Un software fcil de probar tiene las siguientes caractersticas:

Operatividad

Observatividad
Controlabilidad

Capacidad

de descomposicin

Simplicidad Estabilidad Facilidad

de comprensin.

Principios de la prueba

Hacer un seguimiento de las pruebas hasta los requisitos del cliente. Plantear y disear las pruebas antes de generar ningn cdigo.
El 80% de todos los errores se centran slo en el 20% de los mdulos.

Diseo de casos de prueba

Un producto puede probarse siguiendo dos criterios: 1. Conocimiento del funcionamiento del producto (Caja blanca). 2. El conocimiento de la funcin especfica para la que fue diseado el producto (Caja negra).

Criterios de realizacin de pruebas

Para llevar a cabo la verificacin del comportamiento de un sistema pueden servirse 2 criterios:

Descendente Ascendente

Criterios de realizacin de pruebas

Prueba Descendente empieza a nivel de sistema, prueba los mdulos y por ultimo las funciones que conforman. Utiliza un programa esclavo. Prueba Ascendente da inicio la verificacin de funciones hasta llegar al nivel superior del sistema. Utiliza un programa conductor para cada modulo a probar.

Clase de pruebas
Datos de prueba: Representativos (datos comunes) Incorrectos, incompletos e incongruentes

Diseo de casos de prueba

Prueba de Caja Negra Se realiza con el fin de asegurar que el producto es operativo. Prueba de Caja Blanca Se desarrolla con el fin de asegurar que todas las piezas del sistema tienen una operacin interna que se ajusta a las especificaciones y que todos sus componentes internos se han aprobado en forma adecuada.

Pruebas de caja blanca

Este mtodo de casos de prueba usa los detalles procedimentales del programa. Se busca obtener casos de prueba que: Garanticen que se ejecuta por lo menos una vez todos los caminos independientes de cada mdulo. Verificar las decisiones lgicas (V/F). Ejecutar las condiciones en sus lmites. Ejecutar las estructuras internas de datos para asegurar su validez.

Pruebas de caja blanca

Prueba de camino bsico

Notacin de grafo de flujo Complejidad ciclomtica Obtencin de casos de prueba Matrices de grafos Prueba de condicin Prueba de flujo de datos Prueba de bucles

Prueba de la estructura de control

Pruebas de la estructura de control

Existen tres pruebas de estructura de condicin, que son:
1. 2. 3.

Prueba de condicin, Prueba de estructura de datos y Pruebas de estructuras de control (bucles).

Pruebas de la estructura de control

La prueba de condicin se centra en encontrar errores en condiciones lgicas en un mdulo, aunque tambin puede detectar errores adicionales en el programa. En una condicin se pueden dar los siguientes errores:
1. 2. 3. 4. 5.

Error de operador lgico Error en una variable lgica. Error en una condicin simple o compuesta. Error en un operador relacional. Error en una expresin aritmtica.

Pruebas de la estructura de control

La prueba de flujo de datos selecciona caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa.
La prueba de bucles es una tcnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de condiciones. Hay cuatro tipos de estructuras de control: simples, concatenadas, anidadas y no estructuradas. De acuerdo al tipo de estructura es la prueba que se aplicar.

Pruebas de caja negra

Este tipo de prueba se centra en los requisitos funcionales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa. Con este tipo de pruebas se intenta encontrar:
1. 2. 3.

4.

5.

Funciones incorrectas o ausentes. Errores de interfaz Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin.

Prueba de comparacin

Esta tcnica consiste en la comparacion de salidas de un mismo software pero de sus diferentes versiones.
Cuando se han producido mltiples implementaciones de la misma especificacin, a cada versin del software se le proporciona como entrada los casos de prueba diseados para la otra. Si las salidas de distintas versiones son idnticas entonces todas las implementaciones son correctas. Si la salida es diferente, se revisan las aplicaciones para determinar el defecto. Esta prueba no es infalible.

Estrategias de prueba del software

Estrategias de prueba del software: Prueba de unidad, Prueba de integracin, Prueba de validacin, Prueba del sistema.

Estrategias de prueba del software

Proporcionan un plano o gua para el desarrollador del software, para la organizacin de control de calidad y para el cliente . Es una gua que describe los pasos a llevar a cabo como parte de la prueba, cundo se deben planificar y realizar esos pasos, y cunto esfuerzo, tiempo y recursos se van a requerir. Por lo tanto, cualquier estrategia de prueba debe incorporar la planificacin de la prueba, el diseo de los casos de prueba, la ejecucin de las pruebas y la agrupacin y evaluacin de los datos resultantes.

Etapas de un plan de pruebas

a. especificar los objetivos de las pruebas. b. determinar con precisin los criterios a seguir en su realizacin. c. Integrar al personal y los elementos necesarios para el desarrollo de las pruebas. d. Aplicacin de la prueba o pruebas segn los criterios seleccionados. e. evaluacin de los resultados y consideraciones para llevar a cabo una nueva serie de pruebas.

Verificacin y validacin
La verificacin se refiere al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. La validacin se refiere a un conjunto diferente de actividades que aseguran que el software construdo se ajusta a los requisitos del cliente. La verificacin y la validacin comprenden un amplio rango de actividades de SQA que incluyen :

Revisiones tcnicas formales, Auditorias de configuracin y calidad, Supervisin del rendimiento, Revisin de la base de datos, Anlisis de los algoritmos, Prueba de desarrollo, Prueba de calificacin, Prueba de instalacin.

Prueba de unidad
La prueba de unidad Centra el proceso de verificacin en la menor unidad del diseo del software - el mdulo. Usando la descripcin del diseo detallado como gua, se prueban caminos de control importantes, con el fin de descubrir errores dentro del mbito del mdulo. Est orientada a la caja blanca Puede llevarse a cabo en paralelo para mltiples mdulos.

Consideraciones sobre la prueba de unidad

Las pruebas que se dan como parte de la prueba de unidad son: Se prueba la interfaz del mdulo . Se examinan las estructuras de datos locales. Se prueban las condiciones lmites . Se ejercitan todos los caminos independientes de la estructura de control. Y finalmente, se prueban todos los caminos de manejo de errores. Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del mdulo.

Prueba de integracin
Es una tcnica sistemtica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es tomar los mdulos probados en unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo.

Prueba de integracin
La integracin incremental, El programa se construye y se prueba en pequeos segmentos en los que los errores son ms fciles de aislar y de corregir, de esta forma es ms probable que se puedan probar completamente los interfaces y se puede aplicar un enfoque de prueba sistemtica. Hay estrategias de integracin incremental denominadas: Integracin descendente, Integracin ascendente.

Documentacin de la prueba de integracin

La especificacin de prueba incluye un plan general para la integracin del software y una descripcin de las pruebas especficas. Es un resultado del proceso de ingeniera del software y forma parte de la configuracin del software. El alcance de la prueba resume las caractersticas funcionales, de rendimiento y de diseo interno especficas que van a a ser probadas. Se limita el esfuerzo de prueba, se describen los criterios de terminacin de cada fase de prueba y se documentan las limitaciones del plan.

Documentacin de la prueba de integracin

El plan de prueba describe la estrategia general para la integracin. La prueba se divide en fases y subfases dirigidas a especficas caractersticas funcionales y del mbito de informacin del software.

En todas las fases de prueba se siguen los siguientes criterios con sus correspondientes pruebas:

Integridad de interfaz, Validez funcional, Contenido de la informacin, Rendimiento.

Prueba de validacin

Tras la culminacin de la prueba de la integracin, el software est completamente ensamblado como un paquete, se han encontrado y corregido los errores de interfaz y puede comenzar una serie final de pruebas del software La prueba de validacin.

Criterios para la prueba de validacin

La validacin del software se consigue mediante una serie de pruebas de la caja negra que demuestran la conformidad con los requisitos. Un plan de prueba traza las pruebas que se han de llevar a cabo y un procedimiento de prueba define los casos de prueba especficos que se usarn para demostrar la conformidad con los requisitos.

Repaso de la configuracin
Un elemento importante del proceso de validacin es el repaso de la configuracin. Tal repaso intenta asegurar que todos los elementos de la configuracin del software se han desarrollado de forma adecuada, estn catalogados y tienen el suficiente detalle para facilitar la fase de mantenimiento dentro del ciclo de vida del software.

Pruebas alfa y beta

La prueba alfa es conducida por un cliente en el lugar de desarrollo. La prueba beta se lleva a cabo en uno o ms lugares de cliente por los usuarios finales del software.

Prueba del sistema

La prueba del sistema, realmente est constituida por una serie de pruebas diferentes cuyo propsito principal es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propsito distinto, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

Prueba de recuperacin
La prueba de recuperacin es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Si la recuperacin es automtica hay que evaluar la correcin de reinicializacin, de los mecanismos de recuperacin del estado del sistema, de la recuperacin de datos y del rearranque. Si la recuperacin requiere la intervencin humana, hay que evaluar los tiempos medios de reparacin para determinar si estn dentro de unos lmites aceptables.

Prueba de seguridad
La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el sistema lo protegern.

Prueba de resistencia o de carga maxima

Las pruebas de resistencia estn diseadas para enfrentar a los programas con situaciones anormales. En esencia, el sujeto que realiza la prueba de resistencia se pregunta: "A qu potencia puedo ponerlo a
funcionar antes de que falle ?"

Prueba de rendimiento
La prueba de rendimiento est diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proceso de prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los mdulos individuales a medida que se llevan a cabo las pruebas
de la caja blanca.

El arte de la depuracin
El proceso de depuracin siempre tiene uno de dos resultados: (1) se encuentra la causa, se corrige y se elimina; o (2) no se encuentra la causa.
En este ltimo caso, la persona que realiza la depuracin debe sospechar la causa, disear un caso de prueba que ayude a validar sus sospechas y el trabajo vuelve hacia atrs a la correccin del error de una forma iterativa.

Bibliografia

Anlisis y diseo de sistemas de informacin

(James A. Senn)

Anlisis y diseo de sistemas (Kendall&Kendall)

Ingenieria de Software (Roger S. Pressman)

Diseo de sistemas de informacion Teoria y

Practica (John G. Burch)