Diseño caso de pruebas

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

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.


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


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?


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?


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…

Diseño caso de pruebas

Software

Transcript of Diseño caso de pruebas