La prueba de unidad se concentra en cada unidad (componente) del software, tal como se implementó en el código fuente.
En la prueba de integración se atiende el diseño y la construcción de la arquitectura del software.
En la prueba de validación se validan los requisitos, comparándolos con el software construido.
En la prueba de sistema se prueba como un todo el software y otros elementos del sistema.
Para implementar con éxito una estrategia de prueba de software, según Tom Gilb, se deben atender los siguientes temas:
Especificar los requisitos del producto de manera cuantificable mucho antes de que empiecen las pruebas.
Establecer explícitamente (cuantificables) los objetivos de la prueba.
Comprender cuáles son los usuarios del software y desarrollar un perfil para cada categoría de usuario.
Desarrollar un plan de prueba que destaque la “prueba de ciclo rápido”.
Construir un software robusto diseñado para probarse a sí mismo.
Usar revisiones técnicas formales y efectivas como filtro previo a la prueba.
Realizar revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba.
Desarrollar un enfoque de mejora continua para el proceso de prueba
Pruebas de Unidad:
aquellas que verifican la unidad más pequeña del diseño del software.
La interfaz del módulo se prueba para asegurar que la información fluye apropiadamente hacia dentro y hacia fuera de la unidad de programa sujeta a prueba.
Se examinan las estructuras de datos para asegurar que los datos temporales mantienen la integridad durante todos los pasos de ejecución de un algoritmo.
Se recorren todos los caminos independientes en toda la estructura para asegurar que todas las instrucciones de un módulo se ejecuten por lo menos una vez.
Se prueban las condiciones límites para asegurar que el módulo opera apropiadamente en los límites establecidos para restringir el procesamiento.
Se prueban todos los caminos de manejo de errores.
Un controlador es un programa principal que acepta los datos del caso de prueba, los pasa al componente especifico e imprime los resultados importantes. Los resguardos sirven para reemplazar módulos subordinados al componente que habrá de probarse. Estos últimos usan la interfaz del módulo subordinado, realiza una mínima manipulación de datos, proporciona verificación de la entrada y devuelve el control al módulo de prueba.
Prueba de Integración:
técnica sistemática para construir la arquitectura del software mientras se aplican las pruebas para descubrir errores asociados con 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.
En la integración no incremental se combinan todos los componentes y se prueba todo el programa como un todo, encontrando una gran cantidad de errores.
En la integración incremental el programa se construye y prueba en pequeños incrementos, en donde resulta más fácil aislar y corregir errores.
Prueba de regresión:
consiste en ejecutar nuevamente el mismo subconjunto de pruebas que se han aplicado, para asegurar que los cambios no han propagado efectos colaterales indeseables.
Prueba de humo:
enfoque diseñado 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 Depuración
La prueba del software es un proceso que puede planearse y especificarse sistemáticamente. Se diseña el caso de prueba, se define una estrategia y se evalúan los resultados frente a las expectativas prescritas.
Fundamentos
Facilidad de la prueba:
indica simplemente so es fácil o no probar un software.Operatividad:
Cuanto mejor funcione, con mayor eficiencia podrá probarse.Observabilidad:
Lo que se ve es lo que se prueba- Controlabildiad:
Cuanto mejor se controle el software, mejor se automatizaran y mejoraran las pruebas. Capacidad para descomponer:
Al controlar el alcance de la preuba, se ailaran los problemas mas rápidamente y se aplicaran las prueba nuevamente con mayor inteligencia- Simplicidad:
Cuanto menos haya que probar, mas rápido se hará - Estabilidad:
Cuanto menos cambios haya, menores alteraciones habrá en las pruebas - Facilidad de comprensión:
Cuanta mayor información tenga, con mayor inteligencia se paplicara la prueba. Carasteristicas de las pruebas (fundamentos)
Una buena prueba tiene una elevada probabilidad de encontrar un error
Una buena prueba no es redundante
Una buena prueba debe ser “la mejor de su clase”
Una buena prueba mo debe ser ni muy simple ni demasiado compleja
Fundamentos
Facilidad de la prueba:
indica simplemente so es fácil o no probar un software.Operatividad:
Cuanto mejor funcione, con mayor eficiencia podrá probarse.Observabilidad:
Lo que se ve es lo que se prueba- Controlabildiad:
Cuanto mejor se controle el software, mejor se automatizaran y mejoraran las pruebas. Capacidad para descomponer:
Al controlar el alcance de la preuba, se ailaran los problemas mas rápidamente y se aplicaran las prueba nuevamente con mayor inteligencia- Simplicidad:
Cuanto menos haya que probar, mas rápido se hará - Estabilidad:
Cuanto menos cambios haya, menores alteraciones habrá en las pruebas - Facilidad de comprensión:
Cuanta mayor información tenga, con mayor inteligencia se paplicara la prueba. Carasteristicas de las pruebas (fundamentos)
Una buena prueba tiene una elevada probabilidad de encontrar un error
Una buena prueba no es redundante
Una buena prueba debe ser “la mejor de su clase”
Una buena prueba mo debe ser ni muy simple ni demasiado compleja
Caja negra:
Son las que se aplican a la interfaz del software, examina algún aspecto funcional de un sistema que tiene poca relación con la estructura lógica interna del software
Busca los siguientes errores:
Funciones incorrectas o faltantes
Errores de interfaz
Errores de estructuras de datos o en acceso a bases de datos externas
Errores de comportamiento o desempeño
Errores de inicialización y termino
Diferencia con caja blanca y negra: la caja blanca se realizan en el inicio del proceso de pruebas, la caja negra tiende a aplicarse durante las últimas etapas del proceso.
La prueba de caja negra responde las siguientes preguntas:
¿Cómo se prueba la validez funcional=
¿Cómo se prueban el comportamiento y desempeño del sistema?
¿Cuáles clases de entrada serán bueno casos de prueba?
¿El sistema es particularmente sensible a ciertos valores de entrada?
¿Cómo se aíslan los límites de una clase de datos?
¿Cuáles tasas de datos y cual volumen tolera el sistema?
¿Qué efecto tienen combinaciones específicas de datos sobre la operación del sistema?
Tipos de prueba de caja negra
Modelado del flujo de transacción: representan pasos de alguna transacción
Modelado de estado finito: los nodos representa los diferentes estados que el usuario observa el software
Modelado del flujo de datos
Modelado relacionado con el tiempo