GET HOME

DISEOS DE CASOS DE PRUEBA Presentado por:Roco Camargo VillaMiguel BarretoCamilo Adarme

DEFINICINEl diseo de casos de prueba, tiene un nico objetivo: tener la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo posible.

DEFINICINCualquier producto software puede aprobarse de una las siguientes formas:

Conociendo la funcin para la que fue diseado el producto.Se pueden utilizar pruebas para: comprobar su funcin operativa y buscar errores de cada funcin. Conociendo el funcionamiento del producto.Se pueden utilizar pruebas para: comprobar que las operaciones esta de acuerdo con las especificaciones y para comprobar que los componentes internos funcionan de forma adecuada.

PRUEBAS DE CAJA BLANCA

PRUEBAS DE CAJA BLANCAEsta prueba se centra en la estructura interna del programa. En este caso la prueba consiste en probar todos los posibles caminos de ejecucin a travs de las instrucciones del cdigo, que puedan trazarse.

PRUEBA DEL CAMINO BSICOPermite conocer una medida de la complejidad lgica de un diseo procedural y usar esta medida como gua para definir un conjunto bsico de rutas de ejecucinEstas garantizan que se ejecute cada instruccin del programa por lo menos una vez durante la prueba.

Complejidad ciclomticaEs una mtrica que proporciona una medicin cuantitativa de la complejidad lgica de un programa.

PRUEBA DEL CAMINO BSICOComponentes de la grfica de flujo:Aristas : enlacesNodos: instruccin proceduralNodo predicado: nodo del que emanan dos aristas ( if )Regin : rea que se limitan por aristas y nodos

PRUEBA DEL CAMINO BSICOLa complejidad ciclomtica se basa en la teora grficay se calcula de tres maneras:Nmero de regionesnmero de aristas, menos el nmero de nodos msV(G) = E N + 23. nmero de nodos predicado ms unoV(G) = P + 1

PRUEBA DEL CAMINO BSICOComplejidad ciclomtica

V(G) = P + 1V(G) = A N + 2

V(G) = 3 + 1V(G) = 11 9 + 2 = 4

PRUEBA DE CONDICIONMtodo que ejercita las condiciones lgicas contenidas en un mdulo del programa.Esta prueba se concentra en la prueba de cada condicin del programa para asegurar que no contiene errores.

Objetivo: probar todos los casos de la relacin

PRUEBA DE FLUJO DE DATOSMtodo que selecciona rutas de prueba de acuerdo con las ubicaciones de las definiciones y usos de las variables del programa.Asume que cada instruccin se le asigna un numero de instruccin y ninguna funcin modifica sus parmetros o variables globales.

Objetivo: Objetivo: probar todas las DEF y USO de I

PRUEBA DE BUCLESTcnica de prueba de caja blanca que se concentra exclusivamente en la validez de la construccin de bucles.Tipos de bucles: simple, anidado, concatenado, noEstructurado.

PRUEBA DE BUCLES

PRUEBA DE BUCLES

PRUEBA DE BUCLES

PRUEBA DE BUCLES

PRUEBAS DE CAJA NEGRA

PRUEBA DE CAJA NEGRAConsiste en estudiar la especificacin de las funciones, la entrada y la salida para derivar los casos. Aqu, la prueba ideal del software consiste en probar todas las posibles entradas y salidas del programa.

PRUEBA DE CAJA NEGRALa prueba de caja negra, tambin encuentra errores de:Funciones incorrectas o ausentesErrores de interfazErrores en estructuras de datos o en accesos a bases de datos externasErrores de rendimientoErrores de inicializacin y de terminacin

PRUEBA DE CAJA NEGRATipos de Prueba: Prueba basada en fallas Prueba basada en escenarios Prueba de arquitectura cliente/servidor Pruebas de servidor Pruebas de base de datos Pruebas de transaccin Pruebas de comunicacin de red Prueba de documentacin

PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURAS Y APLICACIONES

Prueba de interfaces grficas de usuarioSe utilizan listas de chequeo:Para ventanas:Se abren las ventanas mediante rdenes basadas en el teclado o en un men?Se puede ajustar el tamao, mover y desplegar la ventana?Se regenera adecuadamente cuando se escribe y se vuelve a abrir?

Prueba de interfaces grficas de usuarioPara mens emergentes y operaciones con el ratn:Se muestra la barra de men apropiada en el contexto apropiado?Es correcto el tipo, tamao y formato del texto?Si el ratn tiene varios botones, estn apropiadamente reconocidos en el contexto?

Prueba de interfaces grficas de usuarioEntrada de datos:Se repiten y son introducidos adecuadamente los datos alfanumricos?Funcionan adecuadamente los modos grficos de entrada de datos? (p.e. barra deslizante)Se reconocen adecuadamente los datos no vlidos?Son inteligibles los mensajes de entrada de datos?

Prueba de arquitectura cliente/servidorDebido a la complejidad del sistema, sern necesarias varias fases:Pruebas de funcionalidad de la aplicacin. Se puede llevar a cabo sobre mquinas de desarrollo y estaciones de trabajo de forma paralelaPruebas de carga del servidorPruebas de integridad de datos: Son especialmente importantes en el caso de bases de datos distribuidasPruebas transaccionalesPruebas de red

Prueba de la documentacin y facilidades de ayudasPrueba de la documentacin y facilidades de ayudasSe puede dar en dos sentidos:

Revisin e inspeccin: examina la documentacin para comprobar la claridad de la misma.Prueba en vivo: se utiliza la documentacin junto al uso del software.

Prueba de sistemas de tiempo realSe puede aplicar los siguientes pasos:Prueba de tareas: Se aplican pruebas de caja blanca y caja negra a cada tarea. Pretende descubrir errores en la lgica y en el funcionamiento.Prueba de comportamiento: Se simula el comportamiento del sistema en tiempo real y se examina el comportamiento como consecuencia de sucesos externos.Prueba intertareas: Se prueban las tareas asncronas que se comunican con otras, para determinar si se producen errores de sincronismo entre las tareas.Prueba del sistema: Se realizan pruebas completas al sistema para descubrir errores en la interfaz software/hardware.

GRACIAS