PPSS

Planicacin y Pruebas de Sistemas So5ware

Curso 2014-15

Sesin 2: Pruebas de caja blanca

Diseo de casos de pruebas estructurales
Mtodo del camino bsico

Mara Isabel Alfonso Galipienso

Universidad de Alicante eli@ua.es
1

S Diseo de casos de prueba

S
P
P
Ya conocemos lo que es una Tabla de casos de prueba:
En el laboratorio hemos confeccionado una tabla de este tipo, con casos de
prueba que os hemos proporcionado, e incluso habis aadido alguna la

COMO RELLENAMOS LAS FILAS DE LA TABLA?

CUNTAS FILAS ES NECESARIO AADIR?

Sesin 2: Pruebas de caja blanca

Utilizando un MTODO de DISEO

de casos de prueba!!!!!

S Formas de idenPcar los casos de prueba

S
P
P

DISEAR

Fundamentalmente hay dos formas de proceder:

Functional testing: aproximacin basada en la ESPECIFICACIN

Cualquier programa puede considerarse como una funcin que mapea valores desde

un dominio de entrada a valores en un dominio de salida. El elemento a probar se

considera como una caja negra
Los casos de prueba obtenidos son independientes de la implementacin
El diseo de los casos de prueba puede realizarse en paralelo o antes de la
implementacin

Structural testing: aproximacin basada en la IMPLEMENTACIN

Utilizamos EL CDIGO para determinar el conjunto de casos de prueba. Esta

aproximacin tambin se conoce con el nombre de caja blanca

Es esencial conocer conceptos de teora de grafos para entender bien esta
aproximacin

Mtodos de
caja
BLANCA
Sesin 2: Pruebas de caja blanca

B
S

P
A
3

S Mtodos de diseo de caja blanca

S
P
P
Existen mltiples mtodos de diseo de pruebas de caja blanca:
Control-ow testing (ujo de control entre instrucciones)
La idea principal es seleccionar convenientemente un conjunto de caminos en un

programa y observar si la ejecucin de dichos caminos seleccionados producen el

resultado esperado
Para seleccionar los caminos necesitamos:
- generar un CFG (Control Flow Graph)
- establecer un criterio para seleccionar dichos caminos (p.ej. seleccionar los caminos
de forma que cada sentencia se ejecute al menos una vez)
Ejemplo de mtodo de diseo: McCabe's basis path method

Data ow testing (propagacin de valores entre variables)

A partir de una representacin del flujo de valores de datos de las variables, podemos:

- detectar de forma ESTTICA potenciales defectos del programa (anomala de

datos), identificando situaciones "anormales" que deben revisarse. Por ejemplo:
variables definidas dos veces consecutivas
- detectar de forma DINMICA defectos en el programa identificando caminos en los
que se manipula las variables. Por ejemplo: ejecutar todos los caminos en los que
una variable es definida y usada

Sesin 2: Pruebas de caja blanca

S Mtodos estructurales. Observaciones

S
P
P
Los mtodos estructurales:
Analizan el cdigo y obtienen una representacin en forma de grafo
A continuacin seleccionan un conjunto de caminos segn algn criterio
Obtienen un conjunto de casos de prueba que ejercitan dichos caminos
Dependiendo del mtodo utilizado, obtendremos conjuntos DIFERENTES de
casos de prueba:
Pero el conjunto obtenido ser EFECTIVO y EFICIENTE!!!!
Las tcnicas o mtodos estructurales suelen aplicarse slo a nivel de
UNIDADES de programa
Los mtodos estructurales no pueden detectar todos los defectos en el
programa (faults, bugs)
Aunque seleccionemos todas las posibles entradas, no podremos detectar
todos los defectos si "faltan caminos" en el programa. De forma intuitiva,
diremos que falta un camino en el programa si no existe el cdigo para
manejar una determinada condicin de entrada.
P.ej. si la implementacin no prev que un divisor pueda tener un valor cero, entonces

no se incluir el cdigo necesario para manejar esta situacin

Sesin 2: Pruebas de caja blanca

S Control ow tesPng
S
P
P
Los dos tipos de sentencias bsicas en un programa son:
Sentencias de asignacin
Por defecto se ejecutan de forma secuencial

Sentencias condicionales
Alteran el flujo de control secuencial en un programa

Las llamadas a "funciones" son un mecanismo para proporcionar

abstraccin en el diseo de un programa
Una llamada a una "funcin" cede el control a dicha funcin
Podemos considerar que una unidad de programa tiene un punto de
entrada y de salida bien definidos
La ejecucin de una secuencia de instrucciones desde el punto de entrada al
de salida de una unidad de programa se denomina CAMINO (path)
Puede haber un nmero potencialmente grande de caminos, incluso innito,
en una unidad de programa
Un valor especco de entrada provoca que se ejecute un camino especco
en el programa
Sesin 2: Pruebas de caja blanca

S Grafo de ujo de control (CFG)

S
P
P
Un CFG es una representacin grfica de una unidad de programa
Podemos utilizar diferentes notaciones para representar el CFG:
Utilizaremos una representacin en forma de GRAFO DIRIGIDO:

- Los nodos representan una o ms sentencias secuencias y/o una nica CONDICIN
(as como los puntos de entrada y de salida de la unidad de programa)
- Cada nodo estar etiquetado con un entero cuyo valor ser nico
- Si un nodo contiene una condicin anotaremos a su derecha dicha condicin
- Las aristas representan el flujo de ejecucin entre dos conjuntos de sentencias
(representadas en los nodos)
- Si uno nodo contiene una condicin etiquetaremos las aristas que salen del nodo
con "T" o "F" dependiendo de si el valor de la condicin que representan es
cierto o falso.

Sesin 2: Pruebas de caja blanca

S Construccin de un CFG (I)

S
P
P
Representa los grafos de flujo asociados a los siguientes cdigos java:
if ((a <1) && (a > 200)) {
...
}

Intntalo!
1. if ((a != b) && (a!= c) && (b!= c)) {
2.
...
3. } else {
4.
if (a==b) {
5.
if (a==c) {
6.
...
7.
}
8.
} else {
9.
...
10.
}
11. }

Sesin 2: Pruebas de caja blanca

S Construccin de un CFG (II)

S
P
P
Fjate que poder crear correctamente el grafo necesitamos conocer BIEN el
funcionamiento del subconjunto de sentencias de CONTROL del lenguaje
de programacin utilizado
Por ejemplo, en Java se utilizan sentencias try..catch, para capturar y tratar
las excepciones:
1.
2.
3.
4.
5.
6.
7.
8.
9.

try {
s1; //puede lanzar Exception1;
s2; //no lanza ninguna excepcin
...
} catch (Exception1 e) {
...
} finally {
...
}

Intntalo!
Sesin 2: Pruebas de caja blanca

S Criterios de seleccin de caminos

S
P
P
Estructuralmente un camino es una secuencia de instrucciones en una
unidad de programa
Semnticamente un camino es una instancia de una ejecucin de una
unidad de programa
Es necesario escoger un conjunto de caminos con algn criterio de
seleccin, de forma que:
Todas las construcciones del programa se ejerciten al menos una vez
No generaremos estradas para los tests de forma que se ejecute el mismo
camino varias veces. Aunque, si cada ejecucin del camino actualiza el estado
del sistema, entonces mltiples ejecuciones del mismo camino pueden no ser
idnticas
Algunos criterios de seleccin utilizados son:
todos los caminos,
el conjunto mnimo de caminos para conseguir ejecutar todas las sentencias
el conjunto mnimo de caminos para conseguir ejecutar todas las
condiciones....
Sesin 2: Pruebas de caja blanca

10

S McCabe's Basis path method

S
P
P
Es un mtodo de diseo de pruebas de caja blanca cuyo OBJETIVO es
ejercitar (ejecutar) cada camino independiente en el programa
Fue propuesto inicialmente por Tom McCabe en 1976. Este mtodo permite
al diseador de casos de prueba obtener una medida de la complejidad
lgica de un diseo procedimental y usar esta medida como gua para la
denicin de un conjunto bsico de caminos de ejecucin
El mtodo tambin se conoce como "Mtodo del camino bsico"
Si ejecutamos TODOS los caminos independientes, estaremos ejecutando
TODAS las sentencias del programa, al menos una vez
Adems estaremos garantizando que TODAS las condiciones se ejecutan en
sus vertientes verdadero/falso
Qu es un camino independiente?
Es un camino en un grafo de ujo (CFG) que diere de otros caminos en al
menos un nuevo conjunto de sentencias y/o una nueva condicin (Pressman,
2001)
Sesin 2: Pruebas de caja blanca

11

S Descripcin del mtodo

S
P
P
1.Construir el grafo de flujo del programa a partir del cdigo a probar
2.Calcular la complejidad ciclomtica del grafo de flujo
3.Obtener los caminos independientes del grafo
4.Determinar los datos de prueba de entrada de forma que se ejerciten todos
los caminos independientes
5.Determinar el resultado esperado para cada camino, en funcin de la
especificacin de la unidad a probar

Tabla resultante del diseo de las pruebas:

Camino Datos Entrada Resultado Esperado
C1

d1, d2, ...dn

r1

C2

d1, d2, ...dn

r2

Sesin 2: Pruebas de caja blanca

Resultado Real

12

S Complejidad ciclomPca (I)

S
P
P
Es una mtrica que proporciona una medida de la complejidad lgica de un
componente software
Se calcula a partir del grafo de flujo:
CC = nmero de arcos - nmero de nodos +2
El valor de CC indica el MXIMO nmero de caminos independientes en el
grafo
A mayor CC, mayor complejidad lgica, por
Ejemplo:
lo tanto, mayor esfuerzo de mantenimiento,

1
2

y tambin mayor esfuerzo de pruebas!!!

3
4

CC = 4 - 4 + 2 = 2
El valor mximo de CC comnmente
aceptado como "tolerable" es 10

Sesin 2: Pruebas de caja blanca

13

S Complejidad ciclomPca (II)

S
P
P
Formas alternativas de obtener la complejidad ciclomtica:
CC = nmero de arcos - nmero de nodos +2
CC = nmero de regiones
CC = nmero de condiciones +1

CUIDADO!: Las dos lPmas formas

de clculo son aplicables SOLO si el
cdigo es totalmente estructurado
(no saltos incondicionales)

...
i=1;
total.input=total.valid=0;
sum=0;
do while ((value[i] <> -999) && (total.input<100))
{
total.input+=1;
if ((value[i]>= minimum) && (value[i]<= maximum))
{
total.valid+=1;
sum= sum + value[i];
}
i+=1;
}
if (total.valid >0) {
average= sum/total.valid;
} else average = -999;
return average;

CC = 5 + 1 = 6

Sesin 2: Pruebas de caja blanca

14

S Caminos independientes
S
P
P
Buscamos (como mximo) tantos caminos independientes como valor
obtenido de CC
Cada camino independiente contiene un nodo, o bien una arista, que no
aparece en el resto de caminos independientes
Con ellos recorreremos TODOS los nodos y TODAS las aristas del grafo
Ejemplo:

1
2

Camino 1-3-4
3

Camino 1-2-4
4

Es posible que con un nmero inferior a CC recorramos todos los nodos y

1
CC=3
todas las aristas if (a>=20) {
opcin 1:
opcin 2:
result=0;
Ejemplo:
2
3

Sesin 2: Pruebas de caja blanca

} else {
result=10;
}
if (b>=20) {
result=0;
} else {
result=10;
}

4
5

7
8

C1 = 1-3-4-7-8
C2 = 1-3-4-5-8
C3 = 1-2-4-5-8

C1 = 1-3-4-7-8
C2 = 1-2-4-5-8

Ambas opciones son vlidas

15

S Ejemplo de aplicacin del mtodo

S
P
P
Mtodo que compara dos enteros a y b, y devuelve 10 en caso de que el
valor a sea mayor que b, y cero en caso contrario:

if (a > b) {
result = 20
} else {
result = 0
}

CFG

(paso 1)

(paso 3)
Caminos independientes

a > b
T

C1 = 1-3-4
C2 = 1-2-4

CC = 4 - 4 + 2 = 2
(paso 2)

Tabla resultante del diseo de casos de prueba

Camino

Datos Entrada

Resultado Esperado

C1

a = 20; b = 10

result = 20

C2

a = 10; b = 20

result = 0

(paso 4)
Valores de entrada
Sesin 2: Pruebas de caja blanca

Resultado Real

(paso 5)
Resultado esperado
16

S Concrecin de los casos de prueba

S
P
P
Recuerda que los datos de prueba y la
salida esperada deben ser SIEMPRE
valores CONCRETOS:
Los casos de prueba tienen que poder
REPETIRSE, y por lo tanto, dos
ejecuciones del mismo test, tienen que
tener estar formados por valores
IDNTICOS
Por ejemplo:
D1= "cualquier dni vlido" es INCORRECTO
D1= "12345678" es CORRECTO

Por qu repetir los tests?

Piensa en razones por las que va a ser
necesario repetir los tests
Qu ocurre si un test no puede
repetirse?
Sesin 2: Pruebas de caja blanca

17

S Observaciones sobre los datos de prueba

S
P
P
Normalmente los datos de entrada y/o salida podremos identificarlos como
parmetros del elemento a probar, (y/o valores de retorno). Pero esto NO
siempre es as:
Por ejemplo, supongamos que queremos probar el siguiente mtodo:
add_a_new_client_to_store aade un nuevo cliente a lista de clientes de nuestra

tienda virtual. Si el cliente que se pasa como entrada ya pertenece a la tienda,

entonces el mtodo no har nada. Supongamos que el prototipo del mtodo es:
public void add_a_new_client_to_store(Client cli), cules son las entradas y salidas?
En este caso, el estado de la lista de clientes "antes" de llamar al mtodo es una
entrada, y el estado de la lista de clientes "despus" de llamar al mtodo es una salida

Si utilizamos un lenguaje orientado a objetos, como Java, consideraremos

valores concretos cada "atributo" del objeto
Por ejemplo, supongamos que la clase Cliente est formada por los campos
dni, nombre, direccin, y telfonos. Un ejemplo de caso de prueba podra ser
ste:
dni=12345678, nombre= pepe, direccin=calle del mar, telfonos=(12345,99999)

Sesin 2: Pruebas de caja blanca

18

S Ejemplo: Bsqueda binaria

S
P
P
//Asumimos que la lista de elementos est ordenada de forma ascendente
class BinSearch
public static void search (int key, int [ ] elemArray, Result r) {
int bottom = 0; int top = elemArray.length -1;
int mid; r.found= false; r.index= -1;
while (bottom <= top) {
mid = (top+bottom)/2;
if (elemArray [mid] == key) {
r.index = mid;
r.found = true;
return;
} else {
if (elemArray [mid] < key)
bottom = mid + 1;
else top = mid -1;
}
} //while loop
} //search
} //class

Sesin 2: Pruebas de caja blanca

19

S Vamos a idenPcar los nodos del grafo

S
P
P
//Asumimos que la lista de elementos est ordenada de forma ascendente

class BinSearch

public static void search (int key, int [ ] elemArray, Result r)

{ int bottom = 0;
int top = elemArray.length -1;

1
int mid;
r.found= false; r.index= -1;

2
while (bottom <= top) {

mid = (top+bottom)/2;

3
if (elemArray [mid] == key) {

r.index = mid;

8
r.found = true;

return;

} else {

4
if (elemArray [mid] < key)

bottom = mid + 1;

5
else top = mid -1;

6
}

7
} //while loop

} //search

9
} //class
Sesin 2: Pruebas de caja blanca

20

S Grafo asociado y valor de CC

S
P
P

CC = 11 - 9 + 2 = 4

1
boiom <= top

2
T

F
T

elemArray[mid] == key
F
elemArray < key

4
T

9
7
Sesin 2: Pruebas de caja blanca

21

S Caminos independientes
S
P
P
Posible conjunto de caminos independientes
C1: 1, 2, 3, 4, 6, 7, 2, 9
C2: 1, 2, 3, 4, 5, 7, 2, 9
C3: 1, 2, 3, 8, 9
Ejercicio: Calcula la tabla resultante:

Camino

Datos Entrada

En este ejemplo, con tres

caminos podemos recorrer
todos los nodos y todas las
aristas

Resultado Esperado

C1

key=
elemArray=

r.found=
r.index=

C2

key=
elemArray=

r.found=
r.index=

C3

key=
elemArray=

r.found=
r.index=

Sesin 2: Pruebas de caja blanca

Resultado Real

22

S Ejercicios propuestos (I)

S
P
P
Calcula la CC para cada uno de estos cdigos Java:
public void divide(int numberToDivide, int numberToDivideBy) throws BadNumberException{
if(numberToDivideBy == 0){
throw new BadNumberException("Cannot divide by 0");
}
return numberToDivide / numberToDivideBy;
}

Cdigo 1

Cdigo 2

public void callDivide(){

try {
int result = divide(2,1);
System.out.println(result);
} catch (BadNumberException e) {
//do something clever with the exception
System.out.println(e.getMessage());
}
System.out.println("Division attempt done");
}

Sesin 2: Pruebas de caja blanca

Cdigo 3

public void openFile(){

try {
// constructor may throw FileNotFoundException
FileReader reader = new FileReader("someFile");
int i=0;
while(i != -1){
//reader.read() may throw IOException
i = reader.read();
System.out.println((char) i );
}
reader.close();
System.out.println("--- File End ---");
} catch (FileNotFoundException e) {
//do something clever with the exception
} catch (IOException e) {
//do something clever with the exception
}
}
23

S Ejercicios propuestos (II)

S
P
P
Disear los casos de prueba para el mtodo validar_PIN(), cuyo cdigo es
el siguiente: 1. public class Cajero {
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.

Sesin 2: Pruebas de caja blanca

...
public boolean validar_PIN (Pin pin_number) {
boolean pin_valido= false;
String codigo_respuesta=GOOD;
int contador_pin= 0;

while ((!pin_valido) && (contador_pin <= 2) &&

!codigo_respuesta.equals(CANCEL)) {
codigo_respuesta = obtener_pin(pin_number);
if (!codigo_respuesta.equals(CANCEL)) {
pin_valido = comprobar_pin(pin_number);
if (!pin_valido) {
System.out.println(PIN invlido, repita);
contador_pin=contador_pin+1;
}
}
}
return pin_valido;

}
...
}

la especificacin la tenis a continuacin

24

S Ejercicio propuesto 2
S
P
P
Especificacin del mtodo validar_PIN():
El mtodo validar_PIN() anterior valida un cdigo numrico de cuatro cifras
(objeto de la clase Pin) introducido a travs de un teclado (asumimos que en
el teclado solamente hay teclas numricas (0..9), y una tecla para cancelar).
El mtodo obtener_pin() lee el cdigo introducido por teclado creando
una nueva instancia de un objeto Pin, y devuelve GOOD si no se pulsa la
tecla para cancelar, o CANCEL si se ha pulsado la tecla para cancelar
(carcter \). El mtodo comprobar_pin() verica que el cdigo introducido
tiene cuatro cifras y se corresponde con la contrasea almacenada en el
sistema para dicho usuario, devolviendo cierto o falso, en funcin de ello. El
usuario dispone de tres intentos para introducir un pin vlido, en cuyo caso el
mtodo validar_PIN() devuelve cierto, y en caso contrario devuelve falso.

Sesin 2: Pruebas de caja blanca

25

S Y ahora vamos al laboratorio

S
P
P
No vamos a usar ninguna herramienta software

Identificaremos casos de prueba utilizando el mtodo del CAMINO BSICO

CFG

CC
CC =

pruebas

tabla de casos de prueba

caminos independientes
C1: 1-2-4- -14
C2: 1-3-6- -14

CM: 1-2-7- -14

(M CC)
Sesin 2: Pruebas de caja blanca

Camino
C1

Datos
Entrada

Resultado
Esperado

d1=
d2=

r1

d1=
d2=

rM

Resultado
Real

..
CM

La utilizaremos en la siguiente prctica!!!

26

S Referencias bibliogrcas
S
P
P
A practitioners guide to software test design. Lee Copeland. Artech House
Publishers. 2004
Captulo 10: Control Flow Testing
Pragmatic software testing. Rex Black. Wiley. 2007
Captulo 21: Control Flow Testing
Software testing and quality assurance. Kshirasagar Naik & Priyadarshi
Tripathy. Wiley. 2008
Captulo 4: Control Flow Testing

Sesin 2: Pruebas de caja blanca

27