prueba de aplicaciones convencionales
TRANSCRIPT
PRUEBA DE APLICACIONES CONVENCIONALES.INGENIERÍA DE SOFTWARE UN ENFOQUE
PRÁCTICO
ROGER S. PRESSMAN.
CAPÍTULO 18
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
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
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.
COMPROBABILIDAD DEL SOFTWARE.
• Mientras más información se tenga, se probará con más inteligencia.Comprensibilidad
ATRIBUTOS DE UNA BUENA PRUEBA
Alta probabilidad de encontrar un error
No ser redundante
No debe ser demasiado simple o demasiado compleja
18.3 - PRUEBAS DE CAJA BLANCA
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.
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.
18.4 - PRUEBA DE RUTA BÁSICA
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.
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.
NOTACIÓN DE GRÁFICO O GRAFO DE FLUJO
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
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
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.
EJEMPLO (ALGORITMO)
EJEMPLO (GRAFO)
EJEMPLO (COMPLEJIDAD CICLOMÁTICA)
• 6 regiones
• 17 aristas -13 nodos + 2 = 6
• 5 nodos predicado + 1 = 6
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
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.
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
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.
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
BUCLES
18.6 - PRUEBAS DE CAJA NEGRA
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.
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
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.
PRUEBA BASADA EN MODELO
EN MUCHOS CASOS, USA DIAGRAMAS DE ESTADO UML
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.
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.
PASOS
4• Ejecutar los casos de prueba
5
• Comparar los resultados reales y esperados y adoptar una acción correctiva según se requiera
PRUEBA PARA ENTORNOS, ARQUITECTURASY APLICACIONES ESPECIALIZADAS
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
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.
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.
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
GRACIAS.By: Carlos Yoong.