prueba de aplicaciones convencionales

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.