PLANIFICACIÓN DE TESTING Prof. A/S: Diego Gutiérrez Gerenciamiento y Dirección de TI

INTRODUCCIÓN La prueba del software o también llamada prueba de testing es un elemento crítico para la garantía de calidad del software y representa una revisión final de los requerimientos, del diseño y de la codificación.

OBJETIVOS La prueba es un proceso de ejecución de un programa con la intención 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 debería poder hacer un seguimiento hasta los requerimientos del cliente/usuario Los errores más graves desde el punto de vista del cliente son aquellos que impiden al programa cumplir con sus requerimientos. Las pruebas deberían planificarse antes de que empiecen. La planificación de las pruebas puede empezar cuando esté completo el modelo de requerimientos. (antes de generar código). Las pruebas deberían empezar de lo individual a lo general. Módulos individuales, Grupos de módulos integrados y Sistema total. Para ser más efectiva las pruebas deberían ser conducidas por un equipo independiente. El equipo que creó el sistema no es el más adecuado para llevar a cabo las pruebas.

DISEÑO 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 métodos 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 módulo. 2. Ejercitan todas las decisiones lógicas en sus caminos verdadero y falso. 3. Ejecución de todos los datos en sus límites. 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 categorías: 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 iniciación y terminación

Pruebas de Valores Límites: •Si una condición de entrada está en un rango de valores entre A y B, se deben de diseñar pruebas para los límites A y B; y por lo tanto debemos establecer para estos valores dentro de los límites y por encima de estos. •Si en una condición de entrada especifica, tenemos un número especifico de valores, debemos de diseñar pruebas que ejerciten los valores máximos y mínimos, y los valores próximos por encima y próximos por debajo del máximo y del mínimo de estos valores . •Si las estructuras de datos internas tienen un límite preestablecido, diseñar un caso de prueba que verifique la estructura de datos en sus límites.

Prueba de comprobación: 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 caída del sistema podría 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 evaluación se compara con la especificación de sus usos que se basa en los siguientes atributos. 1- Aprendizaje, ¿cuánto tiempo tarda un usuario nuevo en ser productivo con el sistema? 2- Velocidad de operación, ¿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- Recuperación, ¿Qué tan bien se recupera el sistema a los errores del usuario? 5- Adaptación, ¿Que tan atado esta el sistema a un solo modelo de trabajo?

Prueba de Unidad: Se centra el proceso de verificación en la menor unidad del diseño del software. A tener en cuenta: 1- Se debe probar la interfaz del modulo para asegurar que la información 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 ejecución del algoritmo 3- Se prueban las condiciones limites, para asegurar que el modulo está funcionando correctamente en los limites establecidos como restricciones

Prueba de Integración: Se prueban todos los módulos 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 críticos •Comienza con los niveles inferiores y se mueven hacia los niveles superiores del sistema. •requiere drivers de prueba a implementarse. •Solo encuentra problemas de diseño hasta muy avanzado el proceso. •Es apropiado para sistemas orientados a objetos.

Prueba de Validación: Son pruebas que el usuario debería 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.