Download - prueba de aplicaciones convencionales
![Page 1: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/1.jpg)
PRUEBA DE APLICACIONES CONVENCIONALES.INGENIERÍA DE SOFTWARE UN ENFOQUE
PRÁCTICO
ROGER S. PRESSMAN.
CAPÍTULO 18
![Page 2: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/2.jpg)
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
![Page 3: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/3.jpg)
COMPROBABILIDAD DEL SOFTWARE.
• Mientras mejor funcione, más eficientemente puede probarse.Operatividad
• Lo que ve es lo que prueba.Observabilidad
• Mientras mejor pueda controlar el software, más podrá automatizar y optimizar las pruebas.
Controlabilidad
![Page 4: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/4.jpg)
COMPROBABILIDAD DEL SOFTWARE.
• Al controlar el ámbito de las pruebas, es posible aislar más rápidamente los problemas y realizar pruebas nuevas y más inteligentes.
Descomponibilidad
• Mientras haya menos que probar, más rápidamente se le puede probar.Simplicidad.
• Mientras menos cambios, menos perturbaciones para probar.Estabilidad.
![Page 5: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/5.jpg)
COMPROBABILIDAD DEL SOFTWARE.
• Mientras más información se tenga, se probará con más inteligencia.Comprensibilidad
![Page 6: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/6.jpg)
ATRIBUTOS DE UNA BUENA PRUEBA
Alta probabilidad de encontrar un error
No ser redundante
No debe ser demasiado simple o demasiado compleja
![Page 7: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/7.jpg)
18.3 - PRUEBAS DE CAJA BLANCA
![Page 8: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/8.jpg)
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.
![Page 9: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/9.jpg)
CARACTERÍSTICAS
Garantizar que todas las rutas independientes
dentro de un módulo se revisaron al menos una
vez.
Revisar todas las decisiones lógicas en sus lado verdadero y
falso.
Ejecutar todos los bucles en sus fronteras y dentro
de sus fronteras operativas.
Revisar estructuras de datos internas para garantizar su validez.
![Page 10: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/10.jpg)
18.4 - PRUEBA DE RUTA BÁSICA
![Page 11: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/11.jpg)
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.
![Page 12: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/12.jpg)
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.
![Page 13: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/13.jpg)
NOTACIÓN DE GRÁFICO O GRAFO DE FLUJO
![Page 14: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/14.jpg)
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
![Page 15: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/15.jpg)
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
![Page 16: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/16.jpg)
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.
![Page 17: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/17.jpg)
EJEMPLO (ALGORITMO)
![Page 18: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/18.jpg)
EJEMPLO (GRAFO)
![Page 19: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/19.jpg)
EJEMPLO (COMPLEJIDAD CICLOMÁTICA)
• 6 regiones
• 17 aristas -13 nodos + 2 = 6
• 5 nodos predicado + 1 = 6
![Page 20: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/20.jpg)
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
![Page 21: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/21.jpg)
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.
![Page 22: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/22.jpg)
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
![Page 23: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/23.jpg)
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.
![Page 24: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/24.jpg)
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
![Page 25: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/25.jpg)
BUCLES
![Page 26: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/26.jpg)
18.6 - PRUEBAS DE CAJA NEGRA
![Page 27: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/27.jpg)
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.
![Page 28: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/28.jpg)
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
![Page 29: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/29.jpg)
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.
![Page 30: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/30.jpg)
PRUEBA BASADA EN MODELO
EN MUCHOS CASOS, USA DIAGRAMAS DE ESTADO UML
![Page 31: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/31.jpg)
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.
![Page 32: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/32.jpg)
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.
![Page 33: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/33.jpg)
PASOS
4• Ejecutar los casos de prueba
5
• Comparar los resultados reales y esperados y adoptar una acción correctiva según se requiera
![Page 34: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/34.jpg)
PRUEBA PARA ENTORNOS, ARQUITECTURASY APLICACIONES ESPECIALIZADAS
![Page 35: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/35.jpg)
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
![Page 36: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/36.jpg)
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.
![Page 37: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/37.jpg)
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.
![Page 38: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/38.jpg)
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
![Page 39: prueba de aplicaciones convencionales](https://reader034.vdocuments.net/reader034/viewer/2022042500/559c45f81a28ab94218b467c/html5/thumbnails/39.jpg)
GRACIAS.By: Carlos Yoong.