1. PRUEBA DE
APLICACIONES
CONVENCIONALES.
INGENIERÍA DE SOFTWARE UN ENFOQUE
PRÁCTICO
ROGER S. PRESSMAN.
CAPÍTULO 18

2. PRUEBAS EN EL SOFTWARE
• Se requiere que el desarrollador deseche nociones
preconcebidas sobre lo “correcto” para diseñar
casos de prueba a fin de “romper” el software.
• La meta de probar es encontrar errores

3. COMPROBABILIDAD DEL
SOFTWARE.
Operatividad
• Mientras mejor funcione, más
eficientemente puede probarse.
Observabilidad
• Lo que ve es lo que prueba.
Controlabilidad
• Mientras mejor pueda controlar el
software, más podrá automatizar y
optimizar las pruebas.

4. COMPROBABILIDAD DEL
SOFTWARE.
Descomponibilidad
• Al controlar el ámbito de las pruebas, es
posible aislar más rápidamente los problemas
y realizar pruebas nuevas y más inteligentes.
Simplicidad.
• Mientras haya menos que probar, más
rápidamente se le puede probar.
Estabilidad.
• Mientras menos cambios, menos
perturbaciones para probar.

5. COMPROBABILIDAD DEL
SOFTWARE.
Comprensibilidad
• Mientras más información se tenga, se
probará con más inteligencia.

6. ATRIBUTOS DE UNA BUENA
PRUEBA
Alta probabilidad de encontrar
un error
No ser redundante
No debe ser demasiado simple
o demasiado compleja

7. 18.3 - PRUEBAS DE CAJA
BLANCA

8. PRUEBAS DE CAJA BLANCA
• La
prueba de caja blanca del software se basa en
el examen cercano de los detalles de
procedimiento. Las rutas lógicas a través del
software y las colaboraciones entre componentes.

9. CARACTERÍSTICAS
Garantizar que todas las
rutas independientes
dentro de un módulo se
revisaron al menos una
vez.
Ejecutar todos los bucles
en sus fronteras y dentro
de sus fronteras
operativas.
Revisar todas las
decisiones lógicas en
sus lado verdadero y
falso.
Revisar estructuras de
datos internas para
garantizar su validez.

10. 18.4 - PRUEBA DE RUTA BÁSICA

11. PRUEBA DE RUTA BÁSICA
• Permite al diseñador de casos de prueba definir un
conjunto básico de rutas de ejecución.
• Los
casos de prueba obtenidos tienen la garantía
de ejecutar todo enunciado en el programa, al
menos una vez durante la prueba.

12. NOTACIÓN DE GRÁFICO O
GRAFO DE FLUJO
• Es una forma de representar los procesos y el flujo
de control lógico, dentro de la ejecución de un
programa.

13. NOTACIÓN DE GRÁFICO O
GRAFO DE FLUJO

14. RUTAS DE PROGRAMA
INDEPENDIENTES
• Una ruta independiente es cualquiera que introduce
al menos un nuevo conjunto de enunciados de
procesamiento o una nueva condición en el
programa
• ruta 1: 1-11
• ruta 2: 1-2-3-4-5-10-1-11
• ruta 3: 1-2-3-6-8-9-10-1-11
• ruta 4: 1-2-3-6-7-9-10-1-11
• Ruta no independiente: 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

15. COMPLEJIDAD CICLOMÁTICA
• Es
una medición de software que proporciona una
evaluación cuantitativa de la complejidad lógica de
un programa.
• Define el número de rutas independientes

16. MEDIR COMPLEJIDAD
CICLOMÁTICA
1.
Por el número de regiones
•4
2.
Aristas – Nodos + 2
• 11 – 9 + 2 = 4
3.
NodosPredicado + 1
• 3+1=4
• // NodoPredicado.- De los cuales emanan dos o más
aristas.

17. EJEMPLO (ALGORITMO)

18. EJEMPLO (GRAFO)

19. EJEMPLO (COMPLEJIDAD
CICLOMÁTICA)
• 6 regiones
• 17 aristas -13 nodos + 2 = 6
• 5 nodos predicado + 1 = 6

20. EJEMPLO (RUTA BÁSICA)
•
•
•
•
•
•
ruta 1: 1-2-10-11-13
ruta 2: 1-2-10-12-13
ruta 3: 1-2-3-10-11-13
ruta 4: 1-2-3-4-5-8-9-2-...
ruta 5: 1-2-3-4-5-6-8-9-2-...
ruta 6: 1-2-3-4-5-6-7-8-9-2-...
• Preparar casos de prueba que fuercen la ejecución
de cada ruta

21. 18.5 - PRUEBA DE LA
ESTRUCTURA DE CONTROL
ESTA PRUEBA ES MÁS AMPLIA, CUBRE Y MEJORA LA CALIDAD
DE LA PRUEBA DE CAJA BLANCA.

22. PRUEBA DE CONDICIÓN
• Es
un método de diseño de casos de prueba que
revisa las condiciones lógicas contenidas en un
módulo de programa
• Se
enfoca en la prueba de cada condición del
programa para asegurar que no contiene errores

23. PRUEBA DE FLUJO DE DATOS
• Selecciona
rutas de prueba de un programa de
acuerdo con las ubicaciones de las definiciones y
con el uso de variables en el programa.

24. PRUEBA DE BUCLE
• Es
una técnica de prueba de caja blanca que se
enfoca exclusivamente en la validez de los
constructos bucle.
• Bucles:
•
•
•
•
Simples
Concatenados
Anidados
No estructurados

25. BUCLES

26. 18.6 - PRUEBAS DE CAJA
NEGRA

27. PRUEBAS DE CAJA NEGRA
•
También llamadas pruebas de comportamiento, se
enfocan en los requerimientos funcionales del software;
es decir, revisarán por completo todos los
requerimientos funcionales para un programa
•
No son una alternativa para las técnicas de caja blanca
sino un complemento, es probable que se descubra una
clase de errores diferente.
•
Tienden a aplicarse durante las últimas etapas de las
pruebas.

28. TIPOS DE ERRORES PARA CAJA
NEGRA
• Las
pruebas de caja negra están orientadas a
descubrir el siguiente tipo de errores
• Funciones incorrectas o faltantes
• Errores de interfaz
• Errores en las estructuras de datos o en el acceso a
datos.
• Errores de comportamiento o rendimiento
• Errores de inicialización y terminación

29. ANÁLISIS DE VALOR DE
FRONTERA
• Un
mayor número de errores ocurre en las
fronteras del dominio de entrada y no en el
“centro”. Por esta razón es que el análisis de valor
de frontera se desarrolló como una técnica de
prueba.
• Si
una condición de entrada/salida especifica un
rango de valores entre a y b, los casos de prueba
deben designarse con valores a y b, justo arriba y
justo abajo de a y b.

30. PRUEBA BASADA EN MODELO
EN MUCHOS CASOS, USA DIAGRAMAS DE ESTADO UML

31. PRUEBA BASADA EN MODELO
• Es una técnica de prueba de caja negra que usa la
información contenida en el modelo de
requerimientos como la base para la generación de
casos de prueba.

32. PASOS
1
• Analizar un modelo de comportamiento existente para el
software.
2
• Recorrer el modelo de comportamiento y especificar las
entradas que forzarán al software a realizar la transición de
estado a estado
3
• Revisar el modelo de comportamiento y observar las salidas
esperadas, conforme el software realiza la transición de
estado a estado.

33. PASOS
4
5
• Ejecutar los casos de prueba
• Comparar los resultados reales y
esperados y adoptar una acción
correctiva según se requiera

34. PRUEBA PARA
ENTORNOS, ARQUITECTURAS
Y APLICACIONES
ESPECIALIZADAS

35. PRUEBAS DE INTERFACES
GRÁFICAS DE USUARIO
• La
complejidad de las GUI ha crecido, lo que
conduce a más dificultad en el diseño y ejecución
de los casos de prueba.
• Debido
a que muchas GUI modernas tienen la
misma apariencia y ambiente, puede derivarse una
serie de pruebas estándar

36. PRUEBA DE ARQUITECTURAS
CLIENTE-SERVIDOR
• Pruebas de función de aplicación.
• Pruebas de servidor.
• Pruebas de base de datos.
• Pruebas de transacción.
• Pruebas de comunicación de red.

37. PRUEBA DE ARQUITECTURAS
CLIENTE-SERVIDOR
• Se
recomienda el desarrollo de perfiles operativos
derivados de escenarios de uso cliente-servidor.
• Un
perfil operativo indica cómo interactúan con el
sistema cliente-servidor diferentes tipos de
usuarios.
• Es
decir, los perfiles proporcionan un “patrón de
uso” que puede aplicarse cuando las pruebas se
diseñan y ejecutan.

38. PRUEBAS A LA
DOCUMENTACIÓN
• Los
errores en la documentación pueden ser tan
devastadores para la aceptación del programa
como los errores en los datos o en el código fuente.
• Por
esta razón, las pruebas de documentación
deben ser parte significativa de todo plan de
prueba de software

39. GRACIAS.
By: Carlos Yoong.