Tipos de pruebas de Sistema

1. Definicion : Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente. · Determina cómo la base de datos de prueba será cargada. · Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente. · Decide qué acciones tomar cuando se descubren problemas.

2. Pruebas de Regresion

3. Definicion: En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes.

4. Objetivos:La prueba de regresión es una nueva corrida de casos de prueba previos. Se requiere de políticas para ser creada la prueba de regresión y decidir qué casos de prueba incluir, para probar eficientemente. La prueba de regresión es un buen candidato para automatización. Desde que estas pruebas se repiten una y otra vez, las herramientas para minimizar el esfuerzo del trabajo son útiles. La prueba de viejas funcionalidades es más importante que la de nuevas funcionalidades. Aquellos casos de uso (y los casos de prueba asociados) que descubren defectos tempranamente deben ser incluidos en la prueba de regresión.

5. Principios :Determinar si los cambios recientes en una parte de la aplicación tienen efecto adverso en otras partes.

6. Pruebas de Humo

7. Definicion:Toma éste nombre debido a que su objetivo es probar el sistema constantemente buscando que saque “humo” o falle. En algunos proyectos este tipo de prueba va junto con las pruebas funcionales. Permite detectar problemas que por lo regular no son detectados en las pruebas normales. Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo está será una forma de garantizar el buen desarrollo. Las pruebas de humo NO SON exhaustivas, pero van de extremo a extremo de la aplicación.

8. Objetivos :Detectar los errores en realeases tempranos y de manera fácil Probar el sistema constantemente Garantizar poco esfuerzo en la integración final del sistema Asegurar los resultados de las pruebas unitarias Se reducen los riesgos y a baja calidad

9. Principios :1. Realizar una integración de todo el sistema cada cierto periodo (se recomienda un día, máximo una semana) 2. Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los realizados en días anteriores 3. Buscar eficientemente errores

10. Cuando se encuentre un error en el release correspondiente al periodo elegido para hacer las integraciones del sistema, se detiente el desarrollo hasta que el error es corregido. Este tipo de pruebas es útil en la programación extrema (extremme programming) y de sistemas complejos. Es útil el uso de programas de prueba automáticas que se encarguen de probar os casos de prueba ya ejecutados en realeases anteriores.

11. Pruebas unitarias

12. Definicion:Se focaliza en ejecutar cada módulo (o unidad minima a ser probada, ej = una clase) lo que provee un mejor modo de manejar la integración de las unidades en componentes mayores.

13. objetivos:Particionar los módulos en pruebas en unidades lógicas fáciles de probar. Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca). Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los caminos de ejecución posibles dentro del código bajo prueba; por lo tanto el diseñador debe construirlos con acceso al código fuente de la unidad a probar. Los aspectos a considerar son los siguientes: Rutinas de excepción, Rutinas de error, Manejo de parámetros, Validaciones, Valores válidos, Valores límites, Rangos, Mensajes posibles.

14. Principios: Comparar el resultado esperado con el resultado obtenido. Si existen errores, reportarlos.

15. Entorno:Todas las pruebas planeadas han sido ejecutadas. Todos los defectos que se identificaron han sido tenidos en cuenta.

16. Pruebas de Integracion

17. Identificar errores introducidos por la combinación de programas probados unitariamente. Determina cómo la base de datos de prueba será cargada. Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente. Verificar que las especificaciones de diseño sean alcanzadas. Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.

18. Principios:Comparar el resultado esperado con el resultado obtenido. Técnica: Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parámetros correctos. Utilizar la técnica down-top. Se empieza con los módulos de nivel inferior, y se verifica que los módulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros correctos.