METODOS DE PRUEBA DEL SOFTWARE

Introduccin
Qu es probar software? Algunas definiciones incorrectas:
Probar es demostrar que no hay errores presentes en un programa. El propsito de probar es mostrar que el programa realiza correctamente las funciones esperadas.

La definicin Correcta
Probar es el proceso ejecucin de un programa con el fin de encontrar errores.

Por qu Probar Software?

Pruebas del Software

Otras Definiciones
Verificar. Validar. Pruebas. Caso de Prueba. Defecto. Fallo. Error.

Relacin entre error, defecto y fallo

Objetivos de la Prueba.
La prueba es el proceso de ejecucin de 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 no descubierto hasta entonces. Una prueba tiene xito si descubre un error no detectado hasta entonces.

Principios de las pruebas

A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente. Las pruebas deberan planificarse mucho antes de que empiecen. Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande.

Principios de las pruebas

No son posibles las pruebas exhaustivas. Para ser ms eficaces (pruebas con la ms alta probabilidad de encontrar errores), las pruebas deberan ser realizadas por un equipo independiente.

Principios de las pruebas

Se debe inspeccionar a conciencia el resultado de cada prueba para, as, poder descubrir posibles sntomas de defectos. Cada caso de prueba debe definir el resultado de salida esperado. Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados.

Principios de las pruebas

Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo)
Probar si el software no hace lo que debe hacer Probar si el software hace lo que no debe hacer, es decir si provoca efectos secundarios

Se deben evitar los casos desechables.

Principios de las pruebas

No deben hacerse planes de prueba suponiendo que, prcticamente, no hay defectos en los programas, y dedicando pocos recursos a las pruebas. La experiencia indica que donde hay un defecto hay otros. Las pruebas son una tarea creativa como el desarrollo de software.

Facilidad de Prueba
Operatividad Observabilidad Controlabilidad Capacidad de descomposicin Simplicidad Estabilidad Facilidad de comprensin

Bondad de una Prueba

Debe tener una alta probabilidad de encontrar un error. No debe ser redundante. Debe ser la mejor de todas las posibles. No debe ser ni demasiado sencilla ni demasiado compleja.

El proceso de Prueba
La depuracin (localizacin y correccin de defectos). El anlisis de la estadstica de errores.

Ciclo completo de las Pruebas

Enfoque de Diseo de Casos de Prueba

Enfoque estructural o de caja blanca.

Enfoque funcional o de caja negra.

Enfoque Aleatorio.

Pruebas de Caja Blanca

Garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada mdulo. Ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa. Ejecuten todos los bucles en sus lmites y con sus lmites operacionales. Ejerciten las estructuras internas de datos para asegurar su validez.

Criterios de Cobertura lgica

Cobertura de Sentencias. Cobertura de decisiones. Cobertura de Condiciones. Criterios de decisin/Condicin. Criterio de Condicin Mltiple. Criterio de Cobertura de Caminos (impracticable)
Menos Riguroso (Mas Barato)

Ms Riguroso (Ms Caros)

Grafo de Flujo de las Estructuras Bsicas de programa

X
X

Secuencia

Si x Entonces (If x Then Else)

Hacer hasta x (Do Until x) Repetir

Mientras x Hacer (While x Do )

Separar todas las condiciones Agrupar sentencias simples en bloques Numerar todos los bloques y tambien las condiciones

Grafo de Flujo de un programa (Pseudocodigo)

Abrir Archivos; Leer archivo ventas, al final indicar no mas registros Limpiar linea de impresin WHILE (Haya registros ventas) DO

1 2 3

Total Nacional = 0 Total Extranjero = 0

WHILE (haya reg. ventas) y (mismo producto) DO

IF (Nacional) THEN Sumar venta Nacional a Total Nacional ELSE Sumar venta extranjero a total extranjero END IF Leer Archivo ventas, al final indicar no mas registros END WHILE Escribir lnea de listado Limpiar rea de impresin END WHILE Cerrar Archivos

4 5 6 7 9 10 11
a12

Variantes de Prueba de Caja Blanca

a) Prueba del Camino Bsico. b) Prueba de Condicin. c) Prueba de Flujo de Datos. d) Prueba de Bucles.

Prueba del camino Bsico

Complejidad Ciclomatica(La complejidad de McCabe V (G))
La mtrica de McCabe ha sido muy popular en el diseo de pruebas. Es un indicador del nmero de caminos independientes que existen en un grafo.

Formas de Calcular la Complejidad Ciclomtica V(G)

V (G) = a n + 2 V (G) = r V (G) = c + 1 Donde
a : # de arcos o aristas del grafo. n : # de nodos. r : # de regiones cerradas del grafo. c : # de nodos de condicin.

Qu es lo que se logra con la complejidad ciclomtica?

V (G) marca el lmite mnimo de casos de prueba para un programa. Cuando V (G) >10 la probabilidad de defectos en el mdulo o programa crece mucho entonces quizs sea interesante dividir el mdulo.

Ejemplo de calculo de V (G)

1
a2 a1

2
a4

a3

3
a6 Regin 2 a9 a5

Regin 1 a7

a) V (G) =14-11+2=5 b) V (G) = 5 Regiones Cerradas. c) V (G) = 4+1= 5 Condiciones

4
a8

5
a10 a11

Regin 3

a12

7
a13

Regin 4

9 10

a14

Regin 5

11

Prueba de Condicin
Ventajas
La cobertura de la prueba de una condicin es sencilla. La cobertura de la prueba de las condiciones de un programa da una orientacin para generar pruebas adicionales del programa.

Estrategias de prueba de Condiciones

Prueba de Ramificaciones.

Prueba de Dominio. E1<operador-relacional>E2

Se necesitan 2n (n>0) pruebas como mximo para encontrar errores.

Prueba de flujo de datos

Esta tcnica selecciona caminos de un programa de acuerdo a las definiciones y uso de las variables. El enfoque de prueba de flujo de datos es efectivo para la proteccin contra errores.

Prueba de bucles
Tipos de pruebas:
Bucles simples. Bucles Anidados. Bucles Concatenados. Bucles no estructurados.

Pruebas de Caja Negra.

Intenta encontrar errores de las siguientes categoras:
Funciones Incorrectas o Ausentes. Errores de Interfaz. Errores en estructuras de datos o acceso a bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin.

Pruebas de Caja Negra.

Variantes de pruebas de caja negra.
a) Mtodos de prueba basados en grafos. b) Particin Equivalente. c) Anlisis de valores lmite. d) Prueba de Comparacin. e) Conjetura de Errores.

Mtodos de prueba basados en grafos

Pasos a seguir para una prueba de caja Negra:
1. Entender los objetos que se van a modelar y las relaciones que conectan a estos. 2. Definir una serie de pruebas que verifique que todos los objetos tienen entre ellos la relacines esperadas

Particin equivalente
Pasos para identificar clases de equivalencia.
1. Identificacin de las condiciones de entrada del programa. 2. Identificar las clases de equivalencia:
a) Datos vlidos. b) Datos no vlidos.

Particin equivalente
Pasos para identificar casos de prueba.
1. Asignar un nmero nico para cada clase de equivalencia. 2. Escribir casos de pruebas para todas las clases vlidas. 3. Escribir casos de pruebas para todas las clases no vlidas.

Ejemplo de clases de equivalencia

Aplicacin bancaria en la que el operador debe proporcionar un cdigo, un nombre y una operacin.

Condicin de Entrada
Cdigo de rea # de 3 dgitos que no empieza con 0 ni 1:

Clases Vlidas
1) 200 cdigo 999

Clases Invlidas
2) Cdigo < 200. 3) Cdigo > 999. 4) No es nmero.

Nombre Para identificar la operacin

5) Seis caracteres.

6) Menos de 6 caracteres. 7) Ms de 6 caracteres.

12) Ninguna orden vlida

8) Cheque 9) Depsito Orden Una de las Siguientes 10) Pago factura 11)Retiro de fondos

Anlisis de valores limite

Las reglas para identificar las clases son:
1. Si una condicin de entrada especifica un rango que deben generar casos para los extremos. 2. Si la condicin de entrada especifica un nmero finito y consecutivo de valores, escribir casos para los nmeros mximo, mnimo, uno ms del mximo y uno menos del mnimo de valores 3. Usar la regla 1 para la condicin de salida. 4. Usar la regla 2 para cada condicin de salida.

Prueba de Comparacin
Se desarrollan versiones independientes de una aplicacin con las mismas especificaciones. Probar todas las versiones con los mismos datos de prueba. Luego se ejecutan las versiones en paralelo y se hace una comparacin en tiempo real de los resultados.

Conjetura de Errores
Enumerar una lista de equivocaciones que pueden cometer los desarrolladores. Generar casos de prueba en base a dicha lista. La generacin de casos se obtiene en base a la intuicin o la experiencia.

Pruebas Aleatorias
Se simula los posibles datos de entrada en la secuencia y frecuencia que pueden aparecer en la practica. Si el proceso de generacin se ha realizado correctamente, se crearn eventualmente todas las posibles entradas del programa en todas las posibles combinaciones y permutaciones. Baja probabilidad de encontrar errores.

BIBLIOGRAFIA
Fairley R. Ingeniera de Software. Pressman, R.S. Ingeniera del Software. Un enfoque prctico.