Diseño caso de pruebas

2. 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.

3. Cualquier 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.

5. 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.

6. 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ón
Estas garantizan que se ejecute cada instrucción del programa
por lo menos una vez durante la prueba.
Complejidad ciclomática
Es una métrica que proporciona una medición cuantitativa de la
complejidad lógica de un programa.

7. PRUEBA DEL CAMINO BÁSICO
Componentes de la gráfica de
flujo:
Aristas : enlaces
Nodos: instrucción procedural
Nodo predicado: nodo del
que emanan dos aristas ( if )
Región : área que se limitan
por aristas y nodos

8. PRUEBA DEL CAMINO BÁSICO
La complejidad ciclomática se basa en la teoría gráfica
y se calcula de tres maneras:
1. Número de regiones
2. número de aristas, menos el número de nodos más
V(G) = E – N + 2
3. número de nodos predicado más uno
V(G) = P + 1

9. PRUEBA DEL CAMINO BÁSICO
Complejidad ciclomática
V(G) = P + 1
V(G) = A – N + 2
V(G) = 3 + 1
V(G) = 11 – 9 + 2 = 4

10. 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

11. 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

12. 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, no
Estructurado.

13. PRUEBA DE BUCLES

14. PRUEBA DE BUCLES

15. PRUEBA DE BUCLES

16. PRUEBA DE BUCLES

18. 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.

19. 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

20. PRUEBA DE CAJA NEGRA
Tipos de Prueba:
• Prueba basada en fallas
• Prueba basada en escenarios
• Prueba de arquitectura cliente/servidor
o Pruebas de servidor
o Pruebas de base de datos
o Pruebas de transacción
o Pruebas de comunicación de red
• Prueba de documentación

21. PRUEBA DE ENTORNOS
ESPECIALIZADOS,
ARQUITECTURAS Y
APLICACIONES

22. 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?

23. 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?

24. 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?

25. 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

26. Prueba de la documentación y
facilidades de ayudas
Prueba 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.

27. Prueba de sistemas de tiempo real
Se 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.

28. …GRACIAS…