MTODOS DE PRUEBA DEL SOFTWARE

Departamento de Informtica y Sistemas

Mtodos de Prueba del Software

CONTENIDO: Fundamentos de la Prueba de software Objetivos de la prueba Principios de la Prueba

Facilidad de Prueba
Caractersticas de una buena prueba Diseo de casos de Prueba Pruebas de Caja Blanca

Prueba del Camino Bsico

Pruebas de Estructuras de Control Pruebas de Caja Negra Particin Equivalente

Anlisis de Valores Lmite

Uso de herramientas CASE

Objetivo del tema

Identificar y analizar los conceptos fundamentales de las pruebas de software.

Fundamentos
El desarrollo de sistemas de software implica una serie de actividades de produccin en las que las posibilidades de que aparezca el fallo humano son enormes. Debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo de software ha de ir acompaado de una actividad que garantice la calidad

Fundamentos

La prueba del software es uno de los puntos crticos para la garanta de calidad de software y representa una revisin final de las especificaciones, del diseo y de la codificacin.

Fundamentos
Objetivos de las pruebas:

Ejecutar un programa con la intencin de descubrir un error. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error. Descubrir un error antes de la entrega del producto al cliente. (xito)

Fundamentos
Entonces Nuestro objetivo es disear pruebas que sistemticamente saquen a la luz diferentes clases de errores, en el menor tiempo posible y con el mnimo esfuerzo.

Qu muestran las pruebas?

errores cumplimiento de requerimientos desempeo

una indicacin de calidad

Fundamentos
Si la prueba se lleva a cabo con xito descubrir errores en el software. Como ventajas secundarias la prueba demuestra hasta qu punto las funciones del software funcionan, adems una indicacin de fiabilidad del software y de alguna manera la calidad del software.

Fundamentos
La prueba no puede asegurar la ausencia de defectos, slo puede demostrar que existen defectos en el software.

Fundamentos - Principios de la Prueba

Los principios bsicos que guan a una prueba son:
A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente.
Las pruebas deben planificarse.

Fundamentos - Principios de la Prueba

Los principios bsicos que guan a una prueba son:
El 80 % de todos los errores descubiertos durante las pruebas surgen al hacer un seguimiento de solo el 20 % de todos los mdulos del programa.

Fundamentos - Principios de la Prueba

Los principios bsicos que guan a una prueba son:
Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande. No son posibles las pruebas exhaustivas. Las pruebas deberan ser realizadas por un equipo

independiente al equipo de desarrollo.

Facilidad de Prueba
En circunstancias ideales un Ingeniero de Software disea un sistema con la facilidad de prueba en mente.

Como la prueba es tan profundamente difcil, merece la pena saber qu se puede hacer para hacerlo ms sencillo.
Entre las caractersticas del software que facilitan la prueba estn: arquitectura modularizada, simplicidad, estabilidad, etc.

Caractersticas de una buena prueba

Alta probabilidad de encontrar un error

Debe realizarse de forma separada

No debe ser redundante

No debe ser ni simple ni compleja

Quin prueba el software?

desarrollador
Entiende el sistema pero, es condescendiente y, es dirigido por el entregable

probador independiente
Debe entender el sistema, pero, intentar provocar fallas, y, es dirigido por la calidad

Prueba exhaustiva

Prueba Selectiva
Ruta Seleccionada

iteracin < 20 X

Pruebas de Software
mtodos de caja blanca mtodos de caja negra

Mtodos
Estrategias

Disear casos de prueba

Los bugs se esconden en las esquinas y se congregan en los lmites Boris Beizer

OBJETIVO CRITERIO

descubrir errores en forma completa

RESTRICCIN con el mnimo de esfuerzo y tiempo

Pruebas de Caja Blanca

... el objetivo es asegurarse que todas las sentencias y condiciones han sido ejecutados por lo menos una vez ...

Pruebas de Caja Blanca

La prueba de caja blanca usa la estructura de control del diseo procedural para derivar los casos de prueba

La idea es confeccionar casos de prueba que garanticen que se verifican todos los caminos independientes
Verificaciones para cada camino independiente: Probar sus dos facetas desde el punto de vista lgico, es decir, verdadera y falsa Ejecutar todos los bucles en sus lmites operacionales Ejercitar las estructuras internas de datos

... Pruebas de Caja Blanca

Observaciones:
Los

errores lgicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa.

A veces creemos que un camino lgico tiene pocas posibilidades

de ejecutarse cuando, de hecho, se puede ejecutar de forma regular.

... Pruebas de Caja Blanca

Prueba del Camino Bsico

Tom McCabe (1976)

La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes

Camino independiente es aquel que introduce por lo menos una sentencia de procesamiento (o valor de condicin) que no estaba considerada Para obtener un conjunto de caminos independientes se construir el Grafo de Flujo asociado y se calcular su Complejidad Ciclomtica

Prueba del Camino Bsico - Grafo de Flujo

Pruebas de Caja Blanca

Secuencia
no opcin1

if

no opcin2

no opcinN

if

CASE
then else end opcin1

...
opcin2

While

END CASE

Prueba del Camino Bsico - ... Grafo de Flujo

Pruebas de Caja Blanca

Aristas Nodos

Regin

Pruebas de Caja Blanca

Prueba del Camino Bsico - Complejidad Ciclomtica

Complejidad ciclomtica de un grafo de flujo V(G) establece el nmero de caminos independientes Puede calcularse de tres formas alternativas:
El nmero de regiones del grafo de flujo
V(G) = A - N + 2, donde A es el nmero de aristas y N es el nmero de nodos

V(G) = P + 1, donde P es el nmero de nodos predicado

Complejidad Ciclomtica
Mientras V(G) sea ms alto, hay mayor probabilidad de
errores

mdulos

V(G) Mdulos en este rango son ms propensos a errores

Pruebas de Caja Blanca

Prueba del Camino Bsico - ... Complejidad Ciclomtica
1

V(G) = 4
2, 3

4, 5

El grafo de la figura tiene cuatro regiones. 11 aristas - 9 nodos + 2 = 4

9 10

3 nodos predicado + 1 = 4

11

Pruebas de Caja Blanca

Prueba del Camino Bsico
1

2, 3

Un conjunto de caminos independientes Camino 1: 1-11 Camino 2: 1-2-3-4-5-10-1-11 Camino 3: 1-2-3-6-8-9-10-1-11 Camino 4: 1-2-3-6-7-9-10-1-11
El camino 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 No se considera un camino independiente, ya que es simplemente una combinacin de caminos ya especificados
10

4, 5

Los cuatro caminos anteriores constituyen un conjunto bsico para el grafo

11

Pruebas de Caja Blanca

Prueba del camino bsico

Tratamiento de Condiciones Compuestas Ejemplo :

IF a OR b THEN procedimiento x ELSE procedimiento y ENDIF

Nodos Predicado a
False True

b
False True

Prueba del camino bsico - Derivacin de casos de prueba

Pruebas de Caja Blanca

Pasos para realizar las pruebas:

1. A partir del diseo o del cdigo fuente, dibujar el

grafo de flujo asociado 2. Se calcula la complejidad ciclomtica del grafo 3. Se determina un conjunto bsico de caminos independientes 4. Se preparan los casos de prueba que obliguen a la ejecucin de cada camino del conjunto bsico

Prueba del camino bsico - ... Derivacin de casos de prueba

1

Pruebas de Caja Blanca

V(G) = 2+1 = 3. Por lo tanto, hay que determinar tres caminos independientes.
x<0
False

2
True

y<0
False

3
True

Por ejemplo: Camino 1: 1-2-3-5-6 Camino 2: 1-2-4-6 Camino 3: 1-2-3-4-6 Casos de prueba para cada camino:
Camino 1: Escoger algn x e y tales que se cumpla x >= 0 AND y >= 0 Camino 2: Escoger algn x tal que se cumpla x < 0

Camino 3: Escoger algn x e y tales que se cumpla x >= 0 AND y < 0

Pruebas de Caja Blanca

Otras Pruebas de Caja Blanca Prueba de Condiciones

Prueba de condiciones. Tipos de errores que pueden aparecer en una condicin:

Existe un error en un operador lgico Existe un error en un parntesis lgico

Existe un error en un operador relacional Existe un error en una expresin aritmtica

Otras Pruebas de Caja Blanca Prueba de Bucles

Pruebas de Caja Blanca

Bucles anidados Bucles simples Bucles concatenados Bucles no estructurados

Otras Pruebas de Caja Blanca ... Prueba de Bucles

Pruebas de Caja Blanca

Pruebas para Bucles simples (n es el nmero mximo de iteraciones permitidos por el bucle)
Pasar por alto totalmente el bucle Pasar una sola vez por el bucle Pasar dos veces por el bucle Hacer m pasos por el bucle con m < n

Hacer n-1, n y n + 1 pasos por el bucle

Otras Pruebas de Caja Blanca ... Prueba de Bucles Pruebas para Bucles Anidados Comenzar en el bucle interior estableciendo los dems bucles en sus valores mnimos
Realizar las pruebas de bucle simple para el (ms) interior

Pruebas de Caja Blanca

manteniendo los dems en sus valores mnimos

Avanzar hacia fuera confeccionando pruebas para el siguiente bucle

manteniendo todos los externos en los valores mnimos y los dems bucles anidados en sus valores tpicos
Continuar el proceso hasta haber comprobado todos los bucles

Otras Pruebas de Caja Blanca ... Prueba de Bucles

Pruebas de Caja Blanca

Pruebas para Bucles concatenados

Siempre que los bucles concatenados sean

independientes se puede aplicar lo relativo a bucles simples/anidados. En caso de ser dependientes se evaluarn como bucles anidados

Pruebas para Bucles no estructurados

Siempre que se usen los mecanismos que aporta la programacin estructurada, este tipo de bucles no

estarn presentes

Pruebas de Caja Negra

requerimientos

salida

entrada

eventos

Pruebas de Caja Negra

Las pruebas de caja negra se centran en los requisitos funcionales del software

Intenta encontrar errores de los siguientes tipos:

Funciones incorrectas o inexistentes Errores relativos a las interfaces Errores en estructuras de datos o en accesos a bases de datos externas Errores debido al rendimiento Errores de inicializacin o terminacin

Pruebas de Caja Negra

Particin Equivalente
La particin equivalente es un mtodo que divide el campo de entrada de un programa en clases de datos

Una condicin de entrada es un: Valor Numrico especfico Rango de valores Un miembro de un conjunto de valores Lgica

Pruebas de Caja Negra

Particin Equivalente
Una clase de equivalencia representa un conjunto de estados vlidos y no vlidos para una condicin de entrada La prueba de particin equivalente se basa en evaluar las clases de equivalencia para una condicin de entrada

Particin Equivalente Paso 1: Identificar Clases de Equivalencia

Se examina cada condicin de entrada y se divide en

Pruebas de Caja Negra

dos o ms grupos.

Se identifican dos tipos de clases:

Clases de equivalencia vlidas Clases de equivalencia no vlidas

Pruebas de Caja Negra

Paso 1: Identificar Clases de Equivalencia
Dependiendo de la condicin de entrada, se define de la siguiente forma:
Rango - una clase de equivalencia vlida y dos no vlidas Valor especfico - una clase de equivalencia vlida y dos no vlidas Miembro de conjunto - una clase de equivalencia vlida y otra no vlida Lgica - una clase vlida y otra no vlida

... Particin Equivalente

Paso 1: Identificar Clases de Equivalencia

Asignar un nmero nico a cada clase de

Pruebas de Caja Negra Particin Equivalente

equivalencia

Escribir casos de prueba que cubran tantas clases

vlidas no incorporadas como sea posible hasta que se cubran todas las clases de equivalencia vlidas no vlida no incorporada hasta que se cubran todas las clases de equivalencia no vlidas.

Escribir casos de prueba que cubran una sola clase

Pruebas de Caja Negra

Anlisis de Valores Lmite
La tcnica de Anlisis de Valores Lmites selecciona casos de prueba que ejerciten los valores lmite

Complementa la prueba de particin equivalente. En lugar de realizar la prueba con cualquier elemento de la particin equivalente, se escogen los valores en los bordes de la clase

Pruebas de Caja Negra Ejemplo

a) Derivar casos de prueba para el ejemplo b) Complementar con casos de prueba segn anlisis de valores lmite.
Datos de Prueba Nmero Clases de Equivalencia Propsito del Caso Condicin de Entrada1 Condicin de Entrada2 Condicin de Entradan

Herramientas para Pruebas

Herramientas para Pruebas Record/Playback Analizadores de Cdigo Analizadores de Cobertura (coverage analyzers) Analizadores de Memoria Herramientas de Carga/Desempeo Herramientas para probar sitios Web Otras para administracin de pruebas, documentacin de errores y control de configuracin

CASOS DE ESTUDIO
Herramientas: Junit Findbugs ..

BIBLIOGRAFIA
[1].[2].[3].Cardoso, R. (2001). Pruebas del Software. Mrida, Venezuela. Craig Larman (2002). Applying UML and Patterns 2nd Edition. Prentice Hall. Gonzales, J. (2002). Las normas de la calidad del software. Addison-Wesley. Iberoamericana. Espaa.

[4].Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide. AddisonWesley. 2000. [5].[6].[7].Ian Sommerville. Software Engineering, Addison-Wesley, 2000. Captulos 8, 9 y 10. Kruchten, P. (2000). The Rational Unified Process as Introduction. 2 nd Edition. Addison Wesley. Larman, C. UML y Patrones, Segunda Edicin, Pearson Educacin, 2002.

[8].Ortega, M. Prez, M. & Rojas, T. (2003). Construction of a Sistemic Quality Model for Evaluating a Software Product. [9].Pressman, R. (2002). Ingeniera del Software: Un enfoque Prctico. 5 Edicin. McGraw Hill.

[10].- Sommerville, I. (2002) Ingeniera de Software, Sexta Edicin, Addison Wesley, Mxico, 2002