Aseguramiento de la calidad y pruebas de software 5- Pruebas del software Caja Negra/Caja Blanca Blanca A. Vargas Govea

Transcripción

1 Aseguramiento de la calidad y pruebas de software 5- Pruebas del software Caja Negra/Caja Blanca Blanca A. Vargas Govea vargasgovea@itesm.mx Marzo 12, 2013

2 Contenido Pruebas de caja negra Causa-efecto Tabla de decisión Reporte de pruebas de caja negra Introducción a pruebas de caja blanca 2

3 Causa y efecto: tabla de decisión Se usan para registrar reglas de negocio que deban ser implementadas y probadas. Las condiciones representan posibles entradas. Cada columna de la tabla representa una regla que origina una acción. Cada regla debe ser un caso de prueba. 3

4 Ejemplo Especificación de un juego: si una persona A se establece en una propiedad cuyo dueño es una persona B, A debe pagar renta a B. Si A no tiene dinero suficiente para pagar a B, A debe desalojar la propiedad y queda fuera del juego. Condiciones R1 R2 R3 A se establece en la propiedad de B Si Si No A tiene suficiente dinero para pagar la renta Si No -- Si No Si Acciones A permanece en el juego Caso de prueba 1 Idea básica: Identificar condiciones y acciones y definir las reglas. Caso de prueba 2 Caso de prueba 3 4

5 Tabla de decisión Ventaja Prueba combinaciones de condiciones. Desventajas Puede haber muchas causas y efectos. 5

6 Cómo reportar resultados de prueba? 6

7 Anatomía de un caso de prueba: Formato Test ID Descripción Pasos Result Resultados ados actuales espera dos Status 1 2 Test ID. Identificador, se puede asociar al requerimiento o especificación que cubre. Descripción. Descripción de la prueba. Pasos. Entradas que se prueban, pasos necesarios, lo que se necesite para ejecutar la prueba. Resultados esperados. Lo que se espera con base en la entrada descrita. Resultados actuales. Si la prueba fué pasada o no. Si no, describir la falla. Status. Posibles valores: Pass/Fail. 7

8 Anatomía de un caso de prueba: Ejemplo Test ID Descripción Pasos Resultados esperados T1 Probar el botón Save con entradas válidas en los campos correspondientes. 1- Introducir valores válidos en Nombre. 2- Introducir valores válidos en Oprimir el botón Save. La información se guarda. T2 Probar el botón Save con entradas válidas en los campos correspondientes. 1- Introducir valores inválidos en Nombre. 2- Introducir valores inválidos en Oprimir el botón Save. La información no se guarda. El sistema debe pedir valores válidos. Resultados actuales --- Status Pass El sistema Fail guardó la información. Solicitó valores válidos, sin embargo, guardó la información 8

9 Tips Caja Negra Probar lo que el cliente quiere que el programa haga, no lo que el programador hizo. Usar el formato de pruebas. Especificar lo que el tester debe hacer para ejecutar la prueba. 9 Photo Credit: <a href=" mad LOLscientist</a> via <a href=" <a href="

10 Tips Caja Negra Probar pronto y a menudo. Escribir los casos más simples que puedan revelar falla. Usar la técnica de partición de equivalencia para evitar pruebas redundantes. Photo Credit: <a href=" via <a href=" <a href=" 10

11 Tips Caja Negra Usar análisis de límites para encontrar fallas comunes. Usar tablas de decisión para registrar reglas complicadas que deben probarse. Ejecutar primero las pruebas de partición de equivalencia. Photo Credit: <a via <a href=" <a href=" 11

12 Tips Caja Negra Evitar casos de prueba dependientes de otros. Si hay muchos y el último no pasa se tienen que repetir los anteriores. Pensar siempre en lo peor que puede ocurrir y escribir un caso de prueba para eso. 12

13 Introducción: Caja Blanca 13

14 Caja Blanca Caja Transparente Clear Box. Caja de vidrio - Glass Box. El tester tiene como meta asegurarse de que los componentes internos de un programa están funcionando adecuadamente. Photo Credit: <a href=" um</a> via <a href=" <a href=" 14

15 Caja Blanca Mientras que el diseño de pruebas de Caja Negra pueden usarse para componentes de SW grandes y pequeños, el diseño de pruebas de Caja Blanca es más útil para componentes pequeños. Caja Negra Caja Blanca 15 Photo Credit: <a href=" via <a href=" <a href="

16 Caja Blanca El nivel de detalle en la técnica de caja blanca es alto. Enfoque común considerar elementos estructurales tales como ramas, instrucciones, ciclos. El tester debe desarrollar casos de prueba que cubran los elementos estructurales para determinar si existen defectos en la estructura del programa. 16

17 Criterios de cobertura Se puede especificar un criterio de cobertura Ramas: condiciones TRUE/FALSE. Cubrir ramas. Cubrir segmentos específicos, combinaciones y variables. Los casos de prueba deben asegurar que todas las ramas son cubiertas al menos una vez Porcentaje planeado de cobertura: 100% 17

18 Criterios de cobertura Se pueden derivar casos de prueba que Garanticen que todos los caminos independientes dentro de un módulo se cubran al menos 1 vez. Cubrir todas las decisiones lógicas. Cubrir todos los ciclos y sus límintes. Cubrir estructuras de datos para asegurar su validez. 18

19 Cómo? Se debe correr el código con entradas predeterminadas y asegurarse de que produce las salidas esperadas. A menudo se escriben drivers y stubs para estas pruebas. También existen herramientas automáticas. 19

20 Driver Es un módulo de SW usado para invocar un módulo para prueba. Le proporciona entradas, controla, monitorea la ejecución y reporta resultados de prueba. muevejugador(jugador1,2) Un caso de prueba ejecutaría ésta línea y verificaría la posición resultante para asegurarse de que el jugador está en la celda esperada. 20

21 Stubs Componente dummy para simular el comportamiento del componente real. public void muevejugador(jugador jugadorn, int valor){ jugador.colocaposicion(1); } 21

22 Métodos Existen diversos métodos para diseñar casos de prueba. Veremos: Prueba de caminos Flujo de control/prueba de cobertura Herramientas automáticas. 22

23 Actividad y tarea 23

24 Actividad 14 - individual Tomando los casos de prueba resultantes de tu tarea 13 (análisis de partición de equivalencias y de límites). Elaborar un diseño de pruebas usando el formato para Caja Negra. Ejecutar las pruebas sobre el programa de bubble sort realizado. En caso de haber incluido un módulo generador de entradas, agrega resultados de las pruebas sin ese módulo. Entrega tu tabla de pruebas con los resultados obtenidos. 24

25 Tarea 14 Equipo Tomando las particiones de equivalencia que hicieron para su proyecto en la actividad 12. Realiza el análisis de límites Elaborar un diseño de pruebas usando el formato para Caja Negra. Enviar en formato pdf el Viernes 15 de Marzo 25