M.C. Juan Carlos Olivares Rojas Actividad 17. Pruebas para software convencional y software orientado a objetos M.C. Juan Carlos Olivares Rojas Syllabus jcolivares@itesm.edu.mx June, 2009

Introducción En la prueba del software es posible aplicar muchas estrategias. En un extremo, un equipo de software podría esperar hasta que el sistema esté totalmente construido y luego aplicar pruebas al sistema general esperando encontrar errores. Este enfoque, aunque atractivo, simplemente no funciona. Arrojará un software plagado de errores, molesto para el cliente y usuario final.

Introducción En el otro extremo, un ingeniero de software podría aplicar pruebas diariamente, sin importar la parte del sistema que se construya. Este enfoque, aunque menos atractivo para muchos, es muy efectivo. Por desgracia, la mayoría de los desarrolladores de software dudan en usarlo.

Introducción La estrategia de prueba que elige la mayor parte de los equipos de software se ubica entre estos dos extremos. Toma un enfoque incremental de las pruebas; inicia con la prueba de unidades individuales del programa, pasa a pruebas diseñadas para facilitar la integración de las unidades y culmina con pruebas que realizan sobre el sistema construido.

Introducción La prueba de unidad se concentra en el esfuerzo de verificación de la unidad más pequeña del diseño del software: el componente o módulo de software. Las pruebas de unidad se concentran en la lógica del procesamiento interno y en las estructuras de datos dentro de los límites de un componente.

Introducción Durante la prueba de unidad, una tarea esencial es la prueba selectiva de las rutas de ejecución. Se deben diseñar casos de prueba para descubrir errores debidos a cálculos incorrectos, comparaciones erróneas o flujos de control inapropiados.

Introducción La prueba de integración es una técnica sistemática para construir la arquitectura del software mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados en la interfaz. El objetivo es tomar componentes a los que se aplicó una prueba de unidad y construir una estructura de programa que determine el diseño.

Introducción Si las pruebas (de cualquier tipo) tienen éxito, el resultado es el descubrimiento de errores y estos deben corregirse. Cada vez que el software se corrige también cambia algún aspecto de la configuración del software. La prueba de regresión es una actividad que ayuda a asegurar que los cambios no introduzcan un comportamiento indeseable o errores adicionales.

Introducción La prueba de humo está diseñada como mecanismo para marcar el ritmo en proyectos en los cuales el tiempo es crítico, lo que permite que el equipo de software evalúe su proyecto con frecuencia. La prueba de regresión y la prueba de humo son parte de las pruebas de integración.

Introducción El plan de prueba describe la estrategia general de integración.

Referencias Curso de Proyecto Integrador de Software Básico, Universidad TecMilenio, 2009

Questions?