El ingeniero intenta construirel software partiendo de un

concepto Abstracto y llegando a una implementación

Tangible

Objetivos de las pruebas

La prueba es el proceso de

ejecución de un programa

con la intención de descubrir un

error.

Nuestro objetivo es diseñar pruebas que sistemáticamentesaquen a la luz diferentes clases de errores, haciéndolocon la menor cantidad de tiempo y de esfuerzo.

Nuestro objetivo es diseñar pruebas que sistemáticamentesaquen a la luz diferentes clases de errores, haciéndolocon la menor cantidad de tiempo y de esfuerzo.

Una prueba tiene éxito si descubre

un error no detectado

hasta entonces.

Nos quitan la idea que, normalmente,tenemos de que una prueba tiene

éxito si nodescubre errores..

Un buen caso de prueba es aquel que tiene una

altaprobabilidad de mostrar un error no descubierto

hastaentonces.

El ingeniero crea una serie de casos de pruebaque intentan «demoler» el software construido

Las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente)como destructivo en lugar de constructivo.

Operatividad. «Cuanto mejor funcione, más eficientementese puede probar.»

Controlabilidad. «Cuanto mejor podamos controlar

el software, más se puede automatizar y optimizar.»

Capacidad de descomposición. «Controlando el

ámbito de las pruebas, podemos aislar más rápidamente

los problemas y llevar a cabo mejores pruebas de regresión.»

Observabilidad. «Lo que ves es lo que pruebas.»

Simplicidad. «Cuanto menos haya que probar, más

rápidamente podremos probarlo.»Estabilidad. «Cuanto menos cambios,

menos interrupcionesa las pruebas.»

Facilidad de comprensión.

«Cuanta más informacióntengamos, más inteligentes serán las pruebas.»

Una buena prueba tiene una alta probabilidad deencontrar un error.

Una buena prueba no debe ser redundante. El tiempoy los recursos para las pruebas son limitados.

El diseño se ha entendido perfectamente

Una buena prueba debería ser «la mejor de la cosecha »

Las dependencias entre los componentes internos,externos

Una buena prueba no debería ser ni demasiado sencillani demasiado compleja.

Se han comunicado los cambias del diseño.

LAS PRUEBAS

comprueban los caminos lógicos del software proponiendo

casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el

«estado del programa» en varios puntos para determinar si el estado real coincide con el esperado o mencionado.

DE LA CAJA BLANCA

DE LA CAJA NEGRA Se basa las pruebas sobre la interfaz del software

operatividad del sistemaSe basa Es el minucioso examen de los detalles procedimentales

(Código Fuente). Es diseñada después de tener el

código fuente

LA PRUEBA DEL CAMINO BÁSICOPermite al

diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución

Construcciones estructurales en forma de grafo de flujo:Según-sea(Case)

Secuencia Si-si-no Mientras Repetir-hasta- Según Sea ‘ (If) (While) (Untii) (Case)

Donde cada círculo representa una o más sentencias, sin bifurcaciones,en LDP o código fuente

Diagramas de FlujoDiagrama de Flujo

Representa la estructura y control del programa

Grafo de FlujoRepresenta el Flujo de control lógico mediante

notación ilustradaCada circula es un Nodo y

corresponde a una secuencia de cuadros de proceso y a un rombo de

decisión

camino 1: 1-11camino 2: 1-2-3-4-5-10-1-11camino 3: 1-2-3-6-8-9-10-1-11camino 4: 1-2-3-6-7-9-10-1-11Fíjese que cada nuevo camino introduce una nuevaarista. Cual es el nuevo camino?

Complejidad ciclomáticaLa complejidad ciclomática es

una métrica del software que proporciona una

medición cuantitativa de la complejidad lógica de

un programa

Definición: El número de caminos

independientes del conjunto básico

de un programa y nos da un límite

superior para elnúmero de pruebas

que se deben realizar para

asegurarque se ejecuta cada

sentencia al menos una vez

Un camino independiente es cualquier camino del programa que introduce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva

condición

Determinamos la complejidad ciclomática delgrafo de flujo resultante.

Se determina aplicando uno de los algoritmos descritos en la Sección Se debe tener en cuenta que se puede determinar V(G) sin desarrollar el grafo de flujo, contando todas las sentencias condicionales del LDP

V(G) = 6 regionesV(G) = 17 aristas - 13 nodos +2 = 6V(G) = 5 nodos predicado + 1 = 6

Determinamos un conjunto básico de caminoslinealmente independientes.

camino 1: 1-2-10-11-13camino 2: 1-2-10-12-13

camino 3: 1-2-3-10-11-13camino 4: 1 -2-3-4-5-8-9-2-...

camino 5: 1 -2-3-4-5-6-8-9-2-...camino 6: 1-2-3-4-5-6-7-8-9-2- ...

Los puntos suspensivos (...) que siguen a los

caminos 4,5 y 6 indican que cualquier camino del

resto de la estructura de control es aceptable

Matrices de grafosEs una matriz cuadrada cuyo tamaño (es decir, el número de filas y de columnas) es igual al número de nodos del grafo de flujo. Cada fila y cada columna

corresponde a un nodo especifico y la

entradas de la matriz corresponden a las

conexiones (aristas) entre los nodos

Matrices de grafos

Conexiones 1- 1 = 0

Cada fila y cada columna corresponde a un nodo específico y las entradas de la matriz corresponden a las conexiones (aristas) entre los nodos

2- 1 = 1

2- 1 = 1

2- 1 = 1/3 +1 =4

usaremos la forma más simple de peso, que indica la existencia de conexiones ( O ó 1). La matriz de grafo de la Figura 17.6 se rehace tal y comose muestra en la Figura 17.7. Se ha reemplazado cadaletra por un 1, indicando la existencia de una conexión(se han excluido los ceros por claridad). Cuando serepresenta de esta forma, la matriz se denomina matrizde conexiones.

Usando el diseño o el código como base, dibujamosel correspondiente grafo de flujo.

PROCEDURE media; * Este procedimiento calcula la media de 100 o menos números que se encuentren entre unos limites; también calcula el total de entradas y el total de números válidos. INFERFACE RETURNS media, total. entrada, total. válido; INTERFACE ACEPTS valor, mínimo, máximo; TYPE valor [1:1001 IS SCALAR ARRAY; TYPE media, total. entrada, total. válido; Mínimo, máximo, suma IS SCALAR: , EF'E i IS INTEGER; ., total, entrada =total, válido = O; / 2 suma =O; J DO WHILE VALOR [il< > -999 and total entrada < 100 3 4 -Incrementar total entrada en 1; IF valor (11 > = mínimo AND valor [il < = maximo 6 THEN incrementar total.valido en 1; suma = suma +valor lil; 9 ENODO If total valido > O 10 l2-ELSE media = -999, END media THEN media = suma/total valido, 13 ENDiF END media

Actividades de prueba de softwareActividades de desarrollo

Análisis

Diseño

Codificación

Integración

Mantenimiento

Doc. Requisitos

PRUEBA DE BUCLES:Los bucles son la piedra angular de la inmensa mayoríade los algoritmos implementados en software.

BUCLES CONCATENADOS:Los bucles concatenados sepueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto.

BUCLES SIMPLES:1. pasar por alto totalmente el bucle2. pasar una sola vez por el bucle3. pasar dos veces por el nucle4. hacer m pasos por el bucle con m < n5. hacer n - 1, n y n+l pasos por el bucle

BUCLES ANIDADOS:Si extendiéramos el enfoque de pruebade los bucles simples a los bucles anidados, el númerode posibles pruebas aumentm’a geométricamente a medidaque aumenta el nivel de anidamiento.

BUCLES NO ESTRUCTURADOS:Siempre que sea posible,esta clase de bucles se deben rediseñar para que se ajusten a las construcciones de programación estructurada

PRUEBA D FLUJO DE DATOS:DEF(S) = { X I la entencia S contiene una definición de X }USO(S) = { X I la sentencia S contiene un uso de X)

MÉTODOS DE PRUEBA BASADOS EN GRAFOS

El primer paso en la prueba de caja negra es entender los objetos6 que se modelan en el software y las relaciones que conectan a estos objetos.•Modelado del flujo de transacción.•Modelado de estado finito.•Modelado del flujo de datos.•Modelado de planificación.

Métodos de prueba basados en grafos:

MÉTODOS DE PRUEBA

BASADOS EN GRAFOS

PARTICIÓN EQUIVALENTE:La partición equivalente es un método de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.

ANÁLISIS DE VALORES LÍMITE: Por razones que no están del todo claras, los errores tienden a darse más en los límites del campo de entrada que en el «centro».

PRUEBA DE LA TABLA ORTOGONAL: el número de parámetros de entrada es pequeño y los valores de cada unode los parámetros está claramente delimitado. En cualquier caso, cuando el número de valores de entrada crece y el número de valores diferentes para cada elemento de dato se incrementa, la prueba exhaustiva se hace impracticable o imposible.

PRUEBA DE COMPARACIÓN: En la mayoría de loscasos, la comparación de las salidas se puede llevar a cabo mediante una herramienta automática.

LA PRUEBA DE LA TABLA ORTOGONAL

Para ilu

strar l

a dife

rencia entre

la

prueba d

e la ta

bla orto

gonal y u

na

aproxim

ación m

ás convencional «

un

elemento

de entra

da distin

to cada

vez», c

onsidera

r un siste

ma q

ue tiene

tres elem

entos d

e entrada, X

, Y y Z

.

Cada uno d

e estos elem

entos d

e

entrada ti

ene tres valo

res d

ifere

ntes.

Hay 33 = 27 posib

les casos de

prueba.P

hadke sugiere u

na visión

geométri

ca de lo

s posib

les casos de

prueba asociados con X

, Y y Z

,

Observando c

ada elemento

de entra

da

en un m

omento

dado

puede modifi

carse secuencialm

ente en

cada eje de entra

da. X-,

Xun elemento

de entrada a la

vez.

Detecta y aísla todos los fallos de modalidad simple.Un fallo de modalidad simple es un problema queafecta a un solo parámetro.

Fallos multimodales. Las tablas ortogonales [del tipoindicado] pueden asegurar la detección Únicamente de fallosde modalidad simple o doble.

TABLA ORTOGONAL SE UTILISA

DE LA SIGUIENTEMANERA:

Detecta todos los fallos de modalidad doble. Si existeun problema donde están afectados dos parámetros que intervienen conjuntamente, se llama fallo de modalidad doble

PRUEBA

DE

ENTRONOS

ESPECIALIZADOS

A medida que el software de computadora se ha hecho más complejo, ha

crecido también la necesidad de enfoques de pruebas

especializados.

•Prueba de interfaces gráficas de

usuario

•Prueba de arquitectura

cliente/servidor

•Prueba de la documentación

y facilidades

de ayuda

•Prueba de sistemas de

tiempo-real

A medida que el software de computadora se ha hecho más complejo, ha

crecido también la necesidad de enfoques de pruebas

especializados.

•Prueba de interfaces gráficas de

usuario

•Prueba de arquitectura

cliente/servidor

•Prueba de la documentación

y facilidades

de ayuda

•Prueba de sistemas de

tiempo-real