Capítulo 18 Pressman

*Prueba de aplicaciones convencionales

*Tabla de Contenido

*Fundamentos de las pruebas de software.

*Pruebas de caja negra y caja blanca.

*Pruebas de caja blanca.

*Prueba de la ruta básica.

*Prueba de estructura de control

*Prueba de caja negra.

*Métodos de pruebas orientadas a objetos.

*Métodos de prueba aplicables al nivel de clase.

*Diseño de caso de prueba de interclase.

*Pruebas de entornos especializados: arquitectura y aplicaciones.

*Patrones de prueba.

*Importancia de las pruebas

*Las pruebas del software son un elemento crítico para la garantía de calidad del software.

*El costo asociado a un fallo del sistema es el principal aliciente para realizar pruebas.

*Antes de iniciar las pruebas se deben establecer los criterios de aceptación, para demostrar que se satisfacen las necesidades de la organización. *Si no se tienen, la evaluación puede ser subjetiva y el

resultado puede fallar

*Definiciones

*Probar NO ES demostrar que no existen errores en un programa.

*Prueba ES el proceso de ejecutar un programa con el fin de encontrar errores. (√)

*Caso de prueba (test case): «es un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular»

*Objetivos de las pruebas

1. El principal es sacar a la luz diferentes clases de errores, minimizando la cantidad de tiempo y esfuerzo invertido

2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

*Principios de las pruebas

A todas las pruebas se les debe poder dar seguimiento hasta los requerimientos

Las pruebas se deben planificar mucho antes de que empiecen (antes de generar código)

El principio de Pareto (80/20) es aplicable a las pruebas (80% de los errores se encuentra en un 20% de todos los módulos del programa)

Deben comenzar por lo pequeño y progresar hacia lo grande.

No son posibles pruebas exhaustivasPara ser más eficaces, deben ser realizadas por un

equipo independiente

*Fundamentos de las pruebas de software

* Comprobabilidad es la facilidad con que se puede probar un software. Las siguientes características conducen a que el software sea comprobable:

1. Operatividad: “Mientras mejor funcione, más eficientemente se puede probar” Esto permite trabajar sin interrupciones

2. Observabilidad: “Lo que ves es lo que pruebas”. Los estados y variables son visibles, se pueden consultar durante la ejecución. La salida incorrecta se identifica fácilmente.

3. Controlabilidad: “Mientras más se pueda controlar, más se puede automatizar y optimizar las pruebas “ Se pueden generar posibles salidas a través de combinaciones de entradas y los formatos de entrada/salida son consistentes. Las pruebas se pueden reproducir y automatizar

*Fundamentos de las pruebas(cont)

4. Descomponibilidad: El sistema se construye a partir de módulos independientes que se pueden probar de manera independiente

5. Simplicidad: El software debe tener simplicidad funcional ( características mínimas necesarias para satisfacer los requerimientos), simplicidad estructural (arquitectura modular para evitar propagación de fallos), simplicidad de código (adoptar estándar de codificación para facilitar inspección y mantenimiento)

6. Estabilidad: Pocos cambios deben solicitarse durante las pruebas. “Cuanto menos cambios, menos interrupciones a las pruebas”

7. Comprensibilidad: “Cuanto más información tengamos, más inteligentes serán las pruebas” Comprensión y acceso a la documentación del diseño.

* Probando el software

Métodos

Estrategias

MétodoCaja blanca

(visión interna)

MétodoCaja negra(visión externa)

Visión interna

*Diseño de casos de prueba

*“Existe una sola regla para el diseño de casos de prueba, cubrir todas las posibilidades, sin hacer demasiados casos de prueba.” Tsuneo Yamaura

*Hay dos enfoques:

*Caja Blanca : Centrarse en la estructura de control del programa.

*Caja Negra: Centrarse en el comportamiento del programa.

Diseño de casos de prueba: enfoques

Funcional

Estructural Tomado de [2]

* Diseño de casos de prueba: enfoques

*Caja negra*Se conoce la función específica para la que fue

diseñado el producto

*Se llevan a cabo pruebas que demuestran que cada función es completamente operativa y al mismo tiempo busca errores en cada función

*Caja blanca*Conociendo el funcionamiento del producto se

desarrollan pruebas que aseguren que todo encaja, que la operación interna se ajusta a las operaciones y que todos los componentes internos se han probado adecuadamente

*Enfoque: Pruebas de Caja-Blanca

…la meta es asegurar que todas las sentencias y condiciones se hayan ejecutado al menos una vez

• Se examinan los detalles procedimentales

• Se comprueban los caminos lógicos

proponiendo casos de pruebas que ejerciten conjuntos específicos de condiciones y/o bucles

* Enfoque: Pruebas tipo Caja Blanca (cont.)

Mediante los casos de prueba de Caja Blanca se logra:1. Garantizar que todos los caminos independientes de

cada módulo se revisaron al menos una vez.2. Ejercitar todas las decisiones lógicas en sus lados

verdaderos y falsos.3. Ejecutar todos los ciclos en sus límites y dentro de sus

límites operativos.4. Revisar las estructuras internas de datos para asegurar

su validez.

* Enfoque: Pruebas de Caja-Blanca Pruebas Exhaustivas

Hay 10 posibles caminos! Si ejecutamos un caso de prueba por milisegundo, podría tomar 3,170 años probar este programa!!

14

Loop < 20 X

* Enfoque: Pruebas de Caja-Blanca Pruebas Selectivas

Loop < 20 X

Camino seleccionado

Las pruebas de caja blanca no se deben desechar como poco prácticas. Se pueden elegir y ejercitar una serie de caminos lógicos importantes

1. Crear grafo de flujo a partir del código a probar:

Cada nodo representa una o más sentencias procedimentales. Las aristas representan el flujo de control y deben terminar siempre en un nodo.

2. Determinar la complejidad ciclomática V(G) utilizando la siguiente fórmula:

V(G)= A-N+2. El resultado es el número de caminos independientes de la estructura de control del programa.

A = # de aristas del grafo de flujoN = # de nodos del grafo de flujo

Notación de gráfico o grafo de flujo: Pasos a seguir

Ejemplo de Creación deGrafo tomandocomo base el procedimientoMedia

Notación de gráfico o grafo de flujo: Pasos a seguir

1

2

3

4

5

6

7

8

9

10

1112

13

Grafo correspondiente al código del procedimientoMedia

i = 1;total, entrada = total, valido=0;Do while

Valor[i] <> -999

total entrada < 100

Incrementar totalentrada en 1

If valor[i] >= minimo

Valor[i] <= maximo

Then incrementar total.valido en 1

suma=suma+valor[i]

Else ignorarEndif

Incrementar I en 1

ENDDO

If total valido > 0

Then media = suma/total.valido;

Else media = -999

endif

Notación de gráfico o grafo de flujo: Pasos a seguir

Paso 3:Determinar un conjunto básico de caminos independientes:

Camino 1: 1-2-10-11-13Camino 2: 1-2-10-12-13Camino 3: 1-2-3-10-11-13Camino 4: 1-2-3-4-5-8-2-2…Camino 5: 1-2-3-4-5-6-8-9-2…Camino 6: 1-2-3-4-5-6-7-8-9-2…

Notación de gráfico o grafo de flujo: Pasos a seguir

*Paso 4:

*Preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto básico:

*Camino 1:

*Valor (k) = entrada válida, donde k < i definida a continuación: Valor (i) = -999, donde 2 <= i <= 100

*Resultados esperado: media correcta sobre los k valores y totales adecuados.

Notación de gráfico o grafo de flujo: Pasos a seguir

*Matrices de gráficas

*El procedimiento para determina r el gráfico de flujo o determinar las rutas básicas es sensible a la automatización

*Una matriz cuadrada cuyo tamaño (# de filas y columnas) es igual al número de nodos en la gráfica de flujo. *Cada fila y columna corresponde a un nodo identificado, y las entradas de

la matriz corresponden a las conexiones (una arista) entre nodos.

*La matriz es solo una representación tabular de un gráfico, pero al agregar un enlace ponderado a cada entrada de matriz, la matriz se convierte en una herramienta poderosa para evaluar la estructura de control del programa durante las pruebas.

*En su forma más simple el enlace puede ser 1 o 0 (si existe o no) pero se les puede asignar valores más interesantes como:* Probabilidad de que un enlace se ejecutará, tiempo de procesamiento que

se emplea durante el recorrido de un enlace, memoria requerida durante el recorrido de un enlace, recursos requeridos durante el recorrido de un enlace

*Matrices de gráficas (cont.)

a

d b

c f

g e

Matriz de gráficaGráfica de flujo

1

a

Conectado al nodo

Nodo 1 2 3 4 5

1

2

3

4

5

3

4

2

5

b

c

d

e

f

g

* Otras pruebas tipo Caja Blanca

Prueba de condición◦Ejercita cada una de las condiciones lógicas del programa.

Los tipos de errores de una condición pueden ser: Error en operador, Error en variable, Error en paréntesis, Error

en expresión aritmética

◦Se han propuesto una serie de estrategias de pruebas de condiciones: Prueba de ramificaciones Prueba del dominio Prueba del operador relacional y de ramificación

* Otras pruebas tipo Caja Blanca

*Prueba del flujo de datos

*Selecciona caminos de prueba de acuerdo a la ubicación de las definiciones y los usos de las variables.

*Prueba de bucles

*Se centra en la validez de las construcciones de bucles: simples, anidados, concatenados y no estructurados

* Prueba de Bucles

BucleAnidado

BucleConcatenado Bucle

No estructurado

Bucle Simple

* Prueba de Bucles (cont.)Bucle simple (donde n es el número máximo de pasos

permitidos por el bucle)1. Pasar por alto totalmente el bucle2. Pasar una sola vez por el bucle3. Pasar dos veces por el bucle4. Hacer m pasos por el bucle, con m < n5. Hacer n-1, n, y n+1 pasos por el bucle

Bucles anidados:6. Comenzar por el bucle más interior7. Realizar pruebas de bucles simples para el bucle más

interno mientras mantiene los bucles externos en sus valores mínimos de parámetro de iteración

8. Procesar hacia fuera, manteniendo los bucles externos en sus valores mínimos, y probar los valores min+1, min-1, y los valores típicos.

.

*Prueba de Bucles (cont.)

*Bucles concatenados:

*Si los bucles son independientes se utiliza el enfoque de los bucles simples, sino se usa el enfoque de los bucles anidados.

*Bucles no estructurados:

*Se deben de evitar, y en caso de que aparezcan es necesario rediseñarlos.

* Pruebas de Caja Negra

Requerimientos

EventosEntradas

Salidas

*Pruebas Caja Negra*No son una alternativa, complementan las de Caja

Blanca *Intenta encontrar errores en:

1. Funciones incorrectas o faltantes2. Errores de interfaz3. Errores en las estructuras de datos o en el acceso a BD

externas4. Errores de comportamiento o rendimiento5. Errores de inicialización y terminación

*Pruebas Caja Negra

*Las pruebas se diseñan para responder a preguntas como:*Cómo se prueba la validez funcional?*Cómo se prueba el comportamiento y

rendimiento?*Qué clases de entrada harán buenos casos de

prueba?*El sistema es particularmente sensible a ciertos

valores de entrada?*Cómo se aislan las fronteras de una clase de

datos?*Qué tasas y volúmen de datos puede tolerar el

sistema?*Qué efecto tendrá sobre la operación algunas

combinaciones de datos?

*Pruebas tipo Caja Negra (cont.)

* Hay diversas técnicas:1. Métodos gráficos de prueba

2. Partición de equivalencia

3. Análisis de valores de límite

4. Prueba de la tabla ortogonal

*1. Métodos gráficos de prueba

1. Se modelan los objetos del sistema y las relaciones entre ellos mediante un grafo.

2. El siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen las relaciones esperadas entre ellos

3. Se ejercitan todos los objetos y sus relaciones para descubrir errores

*1. Métodos gráficos de prueba (cont.)

Objeto 1

Objeto 3

Enlace dirigido

Peso del enlace

Enlace no dirigido Enlaces paralelos

Peso del nodoObjeto 2

Representación del grafo

Ejemplo: Creación de un nuevo archivo en un procesador de texto.

1. Métodos gráficos de prueba(cont.)

Nuevo Archivo

Texto de documento

La selección del menú genera

(tiempo de generación <1.0 seg)

Se reperesenta como Contiene

Atributos:

Dimensiones de inicio:

Configuración o preferencias predeterminadas.

Color de fondo: blanco

Color de texto: color o preferencias predeterminadas

Ventana Documento

Permite la edición de

Una selección del menú en Nuevo Archivo genera una ventana del documento. El peso del nodo de Ventana Documento proporciona una lista de atributos de la Ventana, que se esperan cuando se genera una ventana. El peso del enlace indica que la ventana se tiene que generar en menos de 1.0 segundos.

*1. Métodos gráficos de prueba(cont.)

*Métodos de prueba de comportamiento que usan gráficas: *Modelado del flujo de transacción: nodos

representan pasos y los enlaces conexiones lógicas

*Modelado de estado finito: nodos representan estados y los enlaces transiciones.

*Modelado de flujo de datos: nodos representan objetos de datos y los enlaces transformaciones

*Modelado relacionado con el tiempo: nodos representan objetos del programa y los enlaces conexiones secuenciales

* 2. Método de Partición equivalente

*Divide las entradas de un programa en clases de datos (clases equivalentes) de los que se pueden derivar casos de prueba y en donde cada caso de prueba permite descubrir una clase de errores, lo que reduce el número total de casos de prueba que hay que desarrollar.

*Las clases equivalentes representan un conjunto de estados válidos o no válidos para la condición de entrada.

* 2. Ejemplo de particiones equivalentes

Tomado de [2]

* 2. Ejemplo de particiones equivalentes

“Estimación de inflación entre 15% Y 20%”, “capital entre $65M y $100M” y “tasa de interés entre 0% y 5%”

Tomado de [2]

*3. Método de Análisis de valores límite

*Es un complemento de la técnica de partición equivalente.

*En general se llega a Particiones equivalentes mediante la investigación de Valores límite que limitan las variables dentro de la aplicación

*Toma el conjunto de datos de entrada y examina solo en los límites, ya que ahí es donde es más probable que se produzcan los errores*Es decir, se eligen casos de prueba para

ejercitar los valores límite.

*En lugar de centrarse solo en las condiciones de entrada, se obtienen también casos de prueba para el campo de salida

41

*3. Método de Análisis de valores límite

Tomado de Braude pág. 400

Intervalo

Dentro del intervalo

En lo límites del intervalo

Fuera del intervalo

*3. Directrices Análisis de valores límite (cont.)

1.Si una entrada tiene un rango entre a y b, se diseñan casos de prueba para lo valores a y b, y para los que están por debajo y por encima de a y b.

2.Si una entrada especifica un número de valores, diseñar casos de prueba que ejerciten los valores máximo y mínimo y para los que están por debajo y por encima de ellos.

3.Aplicar las directrices 1 y 2 a los datos de salida.

4.Si hay estructuras de datos con límites preestablecidos diseñar casos de prueba que ejerciten la estructura de datos en sus límites

*4. Método de Prueba de Tabla Ortogonal

*Se aplica en problemas donde el dominio de entrada (número de parámetros) y la cantidad de valores que pueden tomar dichas entradas es relativamente pequeño, pero demasiado grande para posibilitar pruebas exhaustivas. *Detecta:

*Fallas de Modalidad Simple

*Fallas de Modalidad Doble

*Fallas Multimodales

*Es útil para encontrar errores asociados a fallos localizados (errores asociados con defectos de lógica dentro de un componente de software) causado por un parámetro o la interacción de 2 o más.

* 4. Método de Prueba de Tabla Ortogonal

*Por ej:*Programa con 3 parámetros de entrada tomando 4 valores diferentes. Se pueden considerar todas las permutaciones

(34 = 81) pero el esfuerzo requerido es relativamente alto.

*Solución: Crear tabla ortogonal L9*Los casos de prueba están uniformemente

dispersos por todo el dominio de prueba.

*4. Método de Prueba de Tabla Ortogonal (Cont.)

Caso de prueba

Parámetros de prueba

P1 P2 P3 P4

1 1 1 1 12 1 2 2 23 1 3 3 34 2 1 2 35 2 2 3 16 2 3 1 27 3 1 3 28 3 2 1 39 3 3 2 1

Tabla ortogonal L9

*Pruebas basadas en modelo

*Técnica de caja negra que usa la información del modelo de requerimientos (diagramas de estados) para generar casos de pruebas:1. Analiza un modelo de comportamiento existente

(evalúa casos de uso para entender interacción, identifica eventos, crea una secuencia y construye diagrama de estados)

2. Recorre el modelo de comportamiento y especifica entradas que forzarán a realizar la transición de estados

3. Revisa el modelo y observa las salidas esperadas

4. Ejecuta los casos de pruebas

5. Compara resultados

*Prueba de Entornos Especializados:

Arquitecturas y Aplicaciones

*Pruebas de interfaces gráficas de usuario

*Como los componente reutilizables son parte del desarrollo GUI el trabajo de diseño es más fáciles, pero la complejidad de las GUI ha crecido lo que conduce a más dificultad en el diseño y la ejecución de los casos de prueba

*Debido a que muchas GUI tienen la misma apariencia pueden derivarse una serie de pruebas estándar. Es posible usar gráficas de modelado de estado finito (ver filmina anterior)

*En la actualidad se hacen por medio de herramientas automatizadas

*Prueba de Entornos Especializados: Arquitecturas

y Aplicaciones (cont.)* Prueba de arquitectura cliente/servidor

* Desempeño durante la transacción, presencia de distintas plataformas, complejidad de comunicación en red, entre otras, complica probar el software

* La prueba se da en 3 niveles:

1. Cliente se prueba en modalidad “desconectada”

2. Cliente y servidor se prueban juntas, pero operaciones de red no se ejercitan de manera explícita

3. Se prueba todo, incluso operación y desempeño de la red

*Prueba de Entornos Especializados: Arquitecturas

y Aplicaciones (cont.)

* Suelen usarse los siguientes enfoques de prueba:* Pruebas de funcionalidad de la

aplicación

* Pruebas de servidor

* Pruebas de base de datos

* Pruebas de transacción

* Pruebas de comunicación de red

*Prueba de Entornos Especializados: Arquitecturas y

Aplicaciones (cont.)

*Prueba de la documentación y las funciones de ayuda

*Se aborda en 2 fases:

* revisión e inspección: examina claridad del documento

*Prueba en vivo: se emplea la documentación junto al programa

*Prueba de Entornos Especializados: Arquitecturas y

Aplicaciones (cont.)* Prueba de sistemas de tiempo real* Se deben tomar en cuenta casos de prueba de

manejo de eventos (procesamiento de interrupciones), temporización de datos y paralelismo entre tareas

* Se recomienda seguir los siguientes pasos:1. Prueba de tareas: Se prueba cada tarea de manera

independiente.

2. Prueba de comportamiento: Simula el comportamiento del sistema en tiempo real

3. Prueba de intertareas: Se prueban las tareas asíncrónicas, las que se comunican por medio de la cola de mensajes o el almacén de datos.

4. Prueba del sistema: Trata de descubrir errores en la interfaz software/hardware aplicando un rango completo de pruebas del sistema.

*Patrones de Prueba

*Describen bloques de construcción o situaciones frecuentes y que los responsables de probar el software pueden reutilizar al afrontar la prueba de un sistema nuevo o revisado

*Proporcionan además:*Terminología a los encargados de la resolución

de problemas

*Concentran la atención en las fuerzas que se encuentran detrás del problema

*Estimulan el razonamiento iterativo

*Referencias

[1] Pressman, Roger S. “Ingeniería de Software: Un enfoque práctico”, sexta edición, McGraw-Hill, 2005.

[2] Braud, Eric.”Ingeniería de Software – Una perspectiva Orientada a Objetos”, Alfaomega, 2003.