Prueba de RUP
| ||||
Las pruebas. Es una actividad en la cual un sistema o componente es ejecutado bajo unas condiciones o requerimientos específicos, los resultados son observados y registrados, y una evaluación es hecha de algún aspecto del sistema o componente.
Sumario
Objetivos del Flujo Trabajo de Prueba
- Encontrar y documentar los defectos que puedan afectar la calidad del software.
- Validar que el software trabaje como fue diseñado.
- Validar y probar los requisitos que debe cumplir el software.
- Validar que los requisitos fueron implementados correctamente.
Aspectos a recordar
- La prueba no puede asegurar la ausencia de defectos; solo pueden demostrar que existen defectos en el software.
- Cada prototipo que se quiera entregar al final de una iteración debe ser probado y evaluado.
- Un prototipo = 1 .. N pedazos, llamados “Build”, donde cada uno debe pasar por el ciclo de prueba.
- Un ciclo de prueba incluye 4 actividades.
Niveles de Prueba
Nivel de Unidad
- Enfocada al código fuente de los componentes.
- Para verificar todos los flujos de control.
- Primero pasa por la revisión del programador
Nivel de Integración
- Prueba los componentes combinados para ejecutar un CU
- Para verificar descubrir errores o incompletitud en las especificaciones de las interfaces de las clases.
Nivel de Sistema
- Prueba el software funcionando como un todo.
- Aceptable para cuando el software se encuentra en la Fase de Construcción.
Nivel de Aceptación
- Prueba final antes del despliegue del sistema.
- Generalmente lo realizan los usuarios finales.
- A veces se llama “Prueba Piloto”
Tipo de Prueba adecuada al Nivel de Unidad
La prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. O sea, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa se mantiene. La prueba de la caja blanca del software se comprueba los caminos lógicos del software proponiendo casos de prueba que se ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coinciden con el esperado o mencionado.
Pruebas de la caja negra:
- Verifican las especificaciones funcionales y no consideran la estructura interna del programa.
- Es hecha sin el conocimiento interno del producto.
- No validan funciones ocultas (por ejemplo funciones implementadas pero no descritas en las especificaciones funcionales del diseño) por tanto los errores asociados a ellas no serán encontrados.
- En otras palabras, la prueba de la caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. O sea los casos de prueba pretenden:
1) Demostrar las funciones del software son operativas.
2) Que las entradas se aceptan de la forma adecuada y que se produce el resultado correcto.
3) Así como la integrada de la información externa (por ejemplo archivos de datos) se mantiene. Pruebas de la caja blanca: Requieren del conocimiento de la estructura interna del programa y son derivadas a partir de las especificaciones internas de diseño o el código. Mediante los métodos de prueba de la caja blanca, el ingeniero de software puede obtener casos de prueba que garanticen que
1) Se ejerciten por lo menos una vez todos los caminos independientes para cada módulo.
2) Se ejerciten todas las decisiones lógicas en sus vertientes verdaderas y falsa.
3) Ejecuten todos los bucles en sus límites y con sus límites operacionales.
4) Se ejerciten las estructuras internas de datos para asegurar su validez. Dado las alternativas de la caja negra y la caja blanca; y de la necesidad de que las pruebas abarquen los requerimientos, las funciones y la lógica interna del programa entonces
- Las pruebas para los requerimientos deben emplear la estrategia de la caja negra.
- Las pruebas para las funciones deben emplear la estrategia de la caja negra.
- Las pruebas para la lógica interna tiene que necesariamente emplear la estrategia de la caja blanca.
Métodos de Prueba Basados en Caja Blanca
La prueba del camino básico: Esta prueba permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Los casos de prueba obtenidos del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.
La prueba de condición: Es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa.
La prueba de flujo de datos: Se selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.
La prueba de bucles: Es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Los métodos de caja blanca pueden aplicarse a las operaciones que se definen para una clase. Sin embargo, la concisa estructura de muchas operaciones de la clase provoca que algunos argumenten que el esfuerzo aplicado en la prueba de tipo caja blanca pudiera redirigirse mejor hacia pruebas a nivel de clase. Los métodos de prueba de caja negra son apropiados para los sistemas OO. Los casos de uso brindan datos de entrada muy útiles en el diseño de pruebas de caja negra y basada en estados.
Tipo de Prueba adecuada al Nivel de Integración
- Prueba basada en hilos: integrar las clases necesarias para cumplir eventos sistema.
- Prueba basada en uso: Integrar las clases independientes primero, y luego las dependientes. Puntos Claves
- Los niveles de prueba son: Unidad, Integración, Sistema, y Aceptación.
- El nivel de prueba que se escoja esta en dependencia de la etapa de construcción que nos encontremos.
- Las pruebas de caja blanca son las más usadas cuando a nivel de unidad.
- Para la fase de elaboración lo más recomendable es utilizar las pruebas de caja blanca.
Tipo de Prueba adecuada al Nivel de sistema
El software ya validado se integra con el resto del sistema donde algunos tipos de pruebas a considerar son:
- Rendimiento: determinan los tiempos de respuesta, el espacio que ocupa el módulo en disco o en memoria, el flujo de datos que genera a través de un canal de comunicaciones, etc.
- Resistencia: determinan hasta donde puede soportar el programa determinadas condiciones extremas.
- Robustez: determinan la capacidad del programa para soportar entradas incorrectas.
- Seguridad: se determinan los niveles de permiso de usuarios, las operaciones de acceso al sistema y acceso a datos.
- Usabilidad: se determina la calidad de la experiencia de un usuario en la forma en la que éste interactúa con el sistema, se considera la facilidad de uso y el grado de satisfacción del usuario.
- Instalación: se determinan las operaciones de arranque y actualización del software.
Enlace Externo
Patrones de diseño, una buena práctica
Fuente
- ISO/IEC 29119 Pruebas de Software (Grupo de Trabajo de AENOR AEN/CTN71/SC7/GT26)
- MÉTRICA v3 en el CSAE
- Tutoriales de Testing
