Upload
rocio-camargo-villa
View
22
Download
0
Embed Size (px)
Citation preview
DISEÑOS DE CASOS DE PRUEBA
Presentado por:Rocío Camargo VillaMiguel BarretoCamilo Adarme
DEFINICIÓN
El diseño de casos de prueba, tiene un único objetivo: tener la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo posible.
DEFINICIÓNCualquier producto software puede aprobarse de una las siguientes formas:
Conociendo la función para la que fue diseñado el producto.• Se pueden utilizar pruebas para: comprobar su función operativa y
buscar errores de cada función. 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 BLANCA
Esta prueba se centra en la estructura interna del programa. En este caso la prueba consiste en probar todos los posibles caminos de ejecución a través de las instrucciones del código, que puedan trazarse.
PRUEBA DEL CAMINO BÁSICO
Permite conocer una medida de la complejidad lógica de un diseño procedural y usar esta medida como guía para definir un conjunto básico de rutas de ejecuciónEstas garantizan que se ejecute cada instrucción del programa por lo menos una vez durante la prueba.
Complejidad ciclomáticaEs una métrica que proporciona una medición cuantitativa de la complejidad lógica de un programa.
PRUEBA DEL CAMINO BÁSICOComponentes de la
gráfica de flujo:Aristas : enlacesNodos: instrucción proceduralNodo predicado: nodo del que emanan dos aristas ( if )Región : área que se limitan por aristas y nodos
PRUEBA DEL CAMINO BÁSICOLa complejidad ciclomática se basa en la
teoría gráficay se calcula de tres maneras:1. Número de regiones2. número de aristas, menos el número de
nodos másV(G) = E – N + 2
3. número de nodos predicado más unoV(G) = P + 1
PRUEBA DEL CAMINO BÁSICOComplejidad
ciclomática
V(G) = P + 1V(G) = A – N + 2
V(G) = 3 + 1V(G) = 11 – 9 + 2 = 4
PRUEBA DE CONDICION
Método que ejercita las condiciones lógicas contenidas en un módulo del programa.Esta prueba se concentra en la prueba de cada condición del programa para asegurar que no contiene errores.
Objetivo: probar todos los casos de la relación
PRUEBA DE FLUJO DE DATOS
Método que selecciona rutas de prueba de acuerdo con las ubicaciones de las definiciones y usos de las variables del programa.Asume que cada instrucción se le asigna un numero de instrucción y ninguna función modifica sus parámetros o variables globales.
Objetivo: Objetivo: probar todas las DEF y USO de I
PRUEBA DE BUCLES
Técnica de prueba de caja blanca que se concentra exclusivamente en la validez de la construcción 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 NEGRA
Consiste en estudiar la especificación 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 NEGRA
La prueba de caja negra, también encuentra errores de: • Funciones incorrectas o ausentes• Errores de interfaz• Errores en estructuras de datos o en
accesos a bases de datos externas• Errores de rendimiento• Errores de inicialización y de terminación
PRUEBA DE CAJA NEGRA
Tipos de Prueba:• Prueba basada en fallas• Prueba basada en escenarios• Prueba de arquitectura
cliente/servidoro Pruebas de servidoro Pruebas de base de datoso Pruebas de transaccióno Pruebas de comunicación de red
• Prueba de documentación
PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURAS Y
APLICACIONES
Prueba de interfaces gráficas de usuario
Se utilizan listas de chequeo:Para ventanas:• ¿Se abren las ventanas mediante órdenes
basadas en el teclado o en un menú?• ¿Se puede ajustar el tamaño, mover y
desplegar la ventana?• ¿Se regenera adecuadamente cuando se
escribe y se vuelve a abrir?
Prueba de interfaces gráficas de usuario
Para menús emergentes y operaciones con el ratón:• ¿Se muestra la barra de menú apropiada
en el contexto apropiado?• ¿Es correcto el tipo, tamaño y formato
del texto?• ¿Si el ratón tiene varios botones, están
apropiadamente reconocidos en el contexto?
Prueba de interfaces gráficas de usuario
Entrada de datos:• ¿Se repiten y son introducidos
adecuadamente los datos alfanuméricos?• ¿Funcionan adecuadamente los modos
gráficos de entrada de datos? (p.e. barra deslizante)
• ¿Se reconocen adecuadamente los datos no válidos?
• ¿Son inteligibles los mensajes de entrada de datos?
Prueba de arquitectura cliente/servidor
Debido a la complejidad del sistema, serán necesarias varias fases:• Pruebas de funcionalidad de la aplicación.
Se puede llevar a cabo sobre máquinas de desarrollo y estaciones de trabajo de forma paralela
• Pruebas de carga del servidor• Pruebas de integridad de datos: Son
especialmente importantes en el caso de bases de datos distribuidas
• Pruebas transaccionales• Pruebas de red
Prueba de la documentación y
facilidades de ayudasPrueba de la documentación y facilidades de ayudasSe puede dar en dos sentidos:
• Revisión e inspección: examina la documentación para comprobar la claridad de la misma.
• Prueba en vivo: se utiliza la documentación 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 lógica 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 asíncronas 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…