PLANIFICACIN DE TESTING

Prof. A/S: Diego Gutirrez

Gerenciamiento y Direccin de TI

INTRODUCCIN La prueba del software o tambin llamada prueba de testing es un elemento crtico para la garanta de calidad del software y representa una revisin final de los requerimientos, del diseo y de la codificacin.

OBJETIVOS La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar errores. Una buena prueba tiene xito si descubre un error.

PRINCIPIOS DE PRUEBAS A todas las pruebas se les debera poder hacer un seguimiento hasta los requerimientos del cliente/usuario Los errores ms graves desde el punto de vista del cliente son aquellos que impiden al programa cumplir con sus requerimientos. Las pruebas deberan planificarse antes de que empiecen. La planificacin de las pruebas puede empezar cuando est completo el modelo de requerimientos. (antes de generar cdigo). Las pruebas deberan empezar de lo individual a lo general. Mdulos individuales, Grupos de mdulos integrados y Sistema total. Para ser ms efectiva las pruebas deberan ser conducidas por un equipo independiente. El equipo que cre el sistema no es el ms adecuado para llevar a cabo las pruebas.

DISEO DE CASOS DE PRUEBA

Existen dos tipos de casos de pruebas llamados caja blanca o de cristal y caja negra.

Prueba de Caja Blanca:

Mediante los mtodos de prueba de caja blanca se obtienen casos de prueba que: 1. Garantice que se ejercite por lo menos una vez todos los caminos independientes de cada mdulo. 2. Ejercitan todas las decisiones lgicas en sus caminos verdadero y falso. 3. Ejecucin de todos los datos en sus lmites. 4. Ejecutar las estructuras internas de datos para asegurar su validez

Pruebas de Caja Negra:

Las pruebas de caja negra se centran en los requerimientos funcionales. Permiten al ingeniero del software obtener un conjunto de entradas que prueben completamente los requerimientos funcionales de un programa. Estas pruebas intentan encontrar errores de las siguientes categoras: 1- Funciones incorrectas o ausentes 2- Errores de interfaz 3- Errores en estructuras de datos o en el acceso de bases de datos 4- Errores de rendimiento 5- Errores de iniciacin y terminacin

Pruebas de Valores Lmites:

Si una condicin de entrada est en un rango de valores

entre A y B, se deben de disear pruebas para los lmites A y B; y por lo tanto debemos establecer para estos valores dentro de los lmites y por encima de estos. Si en una condicin de entrada especifica, tenemos un nmero especifico de valores, debemos de disear pruebas que ejerciten los valores mximos y mnimos, y los valores prximos por encima y prximos por debajo del mximo y del mnimo de estos valores . Si las estructuras de datos internas tienen un lmite preestablecido, disear un caso de prueba que verifique la estructura de datos en sus lmites.

Prueba de comprobacin: Cuando se realiza un desarrollo de software se verifica si la confiabilidad es critica. La disponibilidad es importante que el sistema est disponible para suministrar insulina cuando lo requiera. Fiabilidad, es importante que el sistema suministre la cantidad correcta de insulina. Seguridad, La cada del sistema podra provocar un suministro de insulina excesiva. Se deben de desarrollar por separados versiones independientes, usando las mismas especificaciones Se prueban las diferentes versiones con los mismos datos de pruebas.

Pruebas de intereses del Usuario: De forma ideal, una evaluacin se compara con la especificacin de sus usos que se basa en los siguientes atributos. 1- Aprendizaje, cunto tiempo tarda un usuario nuevo en ser productivo con el sistema? 2- Velocidad de operacin, Qu tan bien responde el sistema a las operaciones de trabajo del usuario? 3- Robustez, Qu tan tolerante es el sistema a los errores del sistema? 4- Recuperacin, Qu tan bien se recupera el sistema a los errores del usuario? 5- Adaptacin, Que tan atado esta el sistema a un solo modelo de trabajo?

Prueba de Unidad: Se centra el proceso de verificacin en la menor unidad del diseo del software. A tener en cuenta: 1- Se debe probar la interfaz del modulo para asegurar que la informacin fluye de forma adecuada hacia y desde la unidad que se esta probando. 2- Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservando su integridad durante todos los pasos de ejecucin del algoritmo 3- Se prueban las condiciones limites, para asegurar que el modulo est funcionando correctamente en los limites establecidos como restricciones

Prueba de Integracin: Se prueban todos los mdulos asociados. Prueba Top Down: Comienza con los altos niveles del sistema y sigue hacia los niveles inferiores Es una estrategia de pruebas que es usada junto con el desarrollo top-down Descubre errores de arquitectura Puede requerir cierta infraestructura de sistema antes de llevar a cabo las pruebas Prueba Bottom Up: Son necesarias para componentes crticos Comienza con los niveles inferiores y se mueven hacia los niveles superiores del sistema. requiere drivers de prueba a implementarse. Solo encuentra problemas de diseo hasta muy avanzado el proceso. Es apropiado para sistemas orientados a objetos.

Prueba de Validacin: Son pruebas que el usuario debera realizar para verificar que el software tiene los requisitos que el usuario espera. Pruebas ALFA: se llevan acabo en el lugar de desarrollo por un cliente, con el desarrollador como observador, registrando los errores encontrados y los problemas de uso. Pruebas BETA: el usuario hace uso del sistema en el lugar de trabajo, y es el usuario quien anota los errores encontrados.