Tcnicas para disear casos de prueba del software

Carlos Nez Lay

RESUMEN
Dada la actual ubicuidad del software, un mal funcionamiento del mismo puede
ocasionar desde la molestia por un mensaje inapropiado, hasta la prdida de
cuantiosas sumas de dinero o, peor an, de vidas humanas. Por ello, el
software, a semejanza de cualquier artefacto tangible, debe ser sometido a
pruebas para evaluar si cumple adecuadamente con lo que se espera de l.
Aunque el desarrollador de software realiza pruebas del mismo, estas an en
empresas con personal dedicado a esta actividad especfica- se efectan de
manera intuitiva e informal. Dada la creciente demanda de software de calidad,
la prueba o testeo del software en una actividad que ha evolucionado con el
uso de diversas tcnicas y herramientas que la alejan del arte y la acercan a la
ingeniera.
En las siguientes secciones se presentan los conceptos fundamentales de la
prueba del software y se revisan algunas tcnicas para disear casos de
pruebas. Dentro del conjunto de estas tcnicas se han escogido las referidas a
las pruebas unitarias del cdigo ejecutable, tanto desde un enfoque funcional
(caja negra), como desde un enfoque estructural (caja transparente o caja
blanca). Aunque tambin son importantes para la calidad del software, no son
motivo de este artculo las pruebas estticas, tales como las inspecciones
grupales del cdigo, o la revisin de programas por los colegas.
1.

INTRODUCCIN

Segn la IEEE, probar el software es analizarlo para detectar diferencias entre

las condiciones existentes y las requeridas, y para evaluar las caractersticas
del mismo.
Obsrvese que -segn esta definicin- probar el software no consiste en
mostrar que el software realiza las funciones requeridas (que funcione). Por el
contrario, se debe partir de la suposicin de que el software contiene defectos y
de que la prueba se realiza para detectar la mayor cantidad posible de estos y
en consecuencia aumentar su confiabilidad y su calidad. El trabajo de
probar software consiste entonces- en disear casos de prueba, llevarlos a
cabo en un entorno controlado, detectar defectos, documentarlos y reportarlos.
Dado que usualmente se tienen limitaciones de tiempo y recursos, el nmero
de casos de prueba debe ser finito y, por tanto, lo ms eficientes posibles, es
decir, que tenga una alta probabilidad de encontrar defectos. Probar todos los
casos posibles puede resultar imposible, mientras que hacerlo con casos
elegidos aleatoriamente encierra una alta probabilidad de no detectar defectos.
En este artculo se describen algunas tcnicas para disear casos de prueba
del cdigo ejecutable a nivel unitario. En la secciones siguientes se enumeran
los principios que deben guiar este tipo de pruebas y las dos clases de tcnicas
que nos permiten disear casos de prueba eficientes: de caja negra o
funcionales y de caja transparente (o blanca) o estructurales.

2.

PRINCIPIOS DE LA PRUEBA DEL SOFTWARE

Estos principios son importantes porque guiarn el accionar del profesional que
prueba del software. Ilene Burstein seala los siguientes, reformulando los
establecidos originalmente por Glenford J. Myers:
Principio 1
Probar es el proceso que consiste en ejecutar un componente de
software utilizando un conjunto de casos de prueba previamente
seleccionados con la intencin de detectar defectos y de evaluar su
calidad.
Esto supone separar las pruebas de la depuracin o debugging,
actividad esta que se refiere a reparar el software eliminando los
defectos.
Principio 2
Un buen caso de prueba es aquel que tiene una alta probabilidad de
hallar defectos an no detectados.
Partiendo de la hiptesis de la presencia de un determinado tipo de
defecto, se escogen las condiciones de entrada, se determinan los
resultados esperados y se realiza la prueba para determinar si el defecto
est o no presente.
Principio 3
Los resultados de cada prueba deben ser revisados meticulosamente.
Si un defecto es pasado por alto o si se declara equivocadamente- la
existencia de un defecto que no es tal, las consecuencias pueden ser
muy costosas.
Principio 4
Cada caso de prueba debe incluir el resultado esperado.
El resultado esperado es lo que permitir determinar si existen o no
defectos.
Principio 5
Los casos de prueba deben incluir condiciones de entrada vlidas e
invlidas.
La robustez del software se puede evaluar probando su funcionamiento
con entradas invlidas.
Principio 6
La probabilidad de que existan defectos adicionales en un componente
de software es directamente proporcional al nmero de defectos ya
detectados en ese componente.
Este principio se basa en la evidencia emprica. Las razones pueden ser
el nivel de complejidad o algunos defectos de diseo.
Principio 7

Las pruebas deben ser conducidas por personas independientes a las

que hicieron el desarrollo.
El desarrollador est squicamente preparado para que su obra funcione
bien, de modo que le ser muy difcil asumir el principio 1: detectar
defectos.
Principio 8
Las pruebas deben ser repetibles y reutilizables.
Las pruebas deben ser repetidas luego de haberse reparado el defecto.
Adems tambin sern muy tiles para las pruebas de regresin, es
decir, las que se realizarn cuando, por razones de evolucin o mejora,
el software tenga que ser modificado.
3.

TCNICAS DE CAJA NEGRA

El trmino Caja Negra se refiere a que con este enfoque se deja de lado la
estructura interna del software, es decir, solo se toma en cuenta qu hace (o
debe hacer) el software, mas no el cmo lo hace. La materia prima para estas
tcnicas puede ser la descripcin funcional del software, las condiciones de
entrada y de salida, o un diagrama Entrada-Proceso-Salida bien especificado.
Las tcnicas de Caja Negra permiten revelar defectos y/o ambigedades en los
requerimientos y en las especificaciones del software.
3.1. Particiones de Equivalencia
En esta tcnica, el dominio de datos de entrada es particionado en una
cantidad finita de clases de equivalencia (vlidas e invlidas). Cualquier dato
miembro de una clase de equivalencia ser un elemento representativo de
dicha clase y permitir obtener informacin (revelar defectos) acerca del
comportamiento del software con los datos de esa clase de equivalencia.
Realizar pruebas para todas y cada una de estas clases de equivalencia
permite superar la necesidad de probar exhaustivamente todos los posibles
datos de entrada, lo cual generalmente es imposible.
Cmo se identifican las clases de equivalencia?
El proceso de identificacin de las clases de equivalencia es un proceso
heurstico que se basa usualmente- en la descripcin de los datos de entrada
que encontramos en las especificaciones del software.
Glenford J. Myers menciona algunas pautas para identificar clases de
equivalencia:
1. Si una condicin especifica un rango de valores, se identifican
una clase de equivalencia vlida y dos clases de equivalencia
invlidas
Por ejemplo: CANTIDAD puede ser un valor entre 1 y 999. La clase
de equivalencia vlida ser 1 CANTIDAD 999. Una clase invlida
ser CANTIDAD < 1, y otra clase invlida: CANTIDAD > 999.
2. Si una condicin especifica una cantidad de valores, se
identifican una clase de equivalencia vlida y dos invlidas

Por ejemplo: se pueden listar de 1 a 6 propietarios de un bien. La

clase de equivalencia vlida ser de 1 a 6 propietarios, mientras que
las dos invlidas sern: sin propietario y ms de 6 propietarios.
3. Si una condicin especifica un conjunto de valores vlidos, se
identifican una clase de equivalencia vlida y una clase invlida
Por ejemplo: el tipo de vehculo puede ser BUS, MICROBUS,
CAMIN, o AUTO. Se tendrn cuatro clases de equivalencia vlidas
(los cuatro valores vlidos) y una invlida (cualquier valor no
especificado, digamos VOLQUETE)
4. Si una condicin se especifica como debe ser, se identifican una
clase de equivalencia vlida y una invlida.
Por ejemplo: el primer carcter de un cdigo debe ser una letra. La
clase de equivalencia vlida ser: es una letra; y la clase invlida: no
es una letra.
5. Si tiene motivos para pensar que el software no manipula de
manera similar a todos los elementos de una clase de equivalencia,
entonces particinela en clases de equivalencia ms pequeas
Luego de identificar las clases de equivalencia, se deber proceder a escribir
cada caso de prueba tratando que este cubra la mayor cantidad de clases de
equivalencia vlidas, hasta que todas hayan sido consideradas. Por el contrario,
cada clase de equivalencia invlida deber ser cubierta por un caso de prueba
de manera individual, hasta que todas sean cubiertas.
Consideremos el ejemplo del ingreso a una base de datos de un cdigo de
artculo con las caractersticas siguientes:
o Est compuesto por caracteres alfanumricos
o El nmero de caracteres vara entre 4 y 8
o El primer carcter debe ser una letra
Las clases de equivalencia (CE) podran ser:
o CE1 - El cdigo ingresado es alfanumrico
o CE2 - El cdigo ingresado NO es alfanumrico
o CE3 - El cdigo ingresado tiene entre 4 y 8 caracteres
o CE4 - El cdigo ingresado tienen menos de 4 caracteres
o CE5 - El cdigo ingresado tiene ms de 8 caracteres
o CE6 - El primer carcter es una letra
o CE7 - El primer carcter NO es una letra
Los casos de prueba para cubrir las clases de equivalencia identificadas
podran ser:
Dato de prueba

Clases de
equivalencia vlidas

Clases de
equivalencia
invlidas

ABC123

CE1, CE3, CE6

AB*123

CE2

CE4

ABCDEF123456

CE5

123ABC

CE7

3.2. Anlisis de Valores Lmites

Esta tcnica es un complemento de la anterior. Los valores lmite son aquellos
que se encuentran en los bordes de las clases de equivalencia. La
experiencia muestra que muchos errores ocurren en el tratamiento a estos
valores lmite.
Nuevamente Glenford J. Myers aporta algunos lineamientos para hacer este
anlisis:
1. Si una condicin especifica un rango de valores, desarrolle casos
de prueba para los extremos del rango y para valores que estn
inmediatamente debajo y encima de los extremos inferior y superior
del rango
Para el antes mencionado ejemplo de la CANTIDAD -que puede ser
un valor entre 1 y 999- deberan considerarse casos de prueba para
los valores 1 y 999, as como para 0 y 1000.
Si se tratara de una LONGITUD con un rango entre 5.0000 y
10.0000, tendramos que considerar casos de prueba para los
valores 5.0000, 10.0000, 4.9999 y 10.0001.
2. Si se especifica un conjunto ordenado, tal como una lista o una
tabla, se debe tener especial cuidado en el primer elemento del
conjunto, y en el ltimo
Si consideramos el ejemplo del ingreso de un cdigo de artculo, encontramos
valores lmites en la longitud del cdigo (de 4 a 8 caracteres). En base a ello
podramos aadir los casos de prueba siguientes:
Dato de prueba

Valores lmite

AB1

AB12

ABCD1234

ABCD12345

3.3. Grficos causa-efecto

Una debilidad de la tcnica de las tcnicas de particiones de equivalencia y
anlisis de valores lmite es que no facilita la combinacin de condiciones. Los

grficos causa-efecto permiten combinar condiciones, lo cual tambin ayuda en

el hallazgo de ambigedades y/o inconsistencias en las especificaciones.
Esta tcnica es una adaptacin de aquella utilizada para probar circuitos
lgicos digitales. En esta tcnica las especificaciones del software -dadas en un
lenguaje natural- se modelan en un lenguaje formal: los grficos causa-efecto.
Para ello, a partir de cada especificacin del software deben identificarse:
o las causas condiciones de entrada o clases de equivalencia de entrada
o los efectos condiciones de salida o transformaciones observables
o las restricciones limitaciones externas del software
Con estos elementos se construye un grfico booleano:
o las causas y los efectos son los nodos del grfico
o las causas se ubican a la izquierda del grfico, y los efectos a la derecha
o las relaciones lgicas entre causas y efectos se grafican con vectores y
utilizando los operadores lgicos AND, OR y NOT
Los smbolos bsicos para los grficos causa efecto son los siguientes:

Luego, el grfico es vaciado a una tabla de decisin que servir para

desarrollar los casos de prueba necesarios. Cada causa y cada efecto tendrn
una fila en la tabla. Cada columna de la tabla representar una combinacin de
causas y corresponder a un caso de prueba.
Tomemos como ejemplo la especificacin de un mdulo para buscar un
carcter en una cadena: se debe ingresar la longitud de la cadena y el carcter
a buscar. Si la longitud de la cadena es mayor a 80 debe mostrarse un mensaje
de error. Si el carcter se encuentra en la cadena, debe mostrarse su posicin,
de lo contrario debe mostrarse el mensaje No encontrado.

Las causas o condiciones de entrada seran:

C1: entero positivo entre 1 y 80
C2: carcter a buscar
Los efectos o condiciones de salida seran:
E1: Longitud fuera de rango
E2: Posicin del carcter
E3: Carcter no encontrado
El grfico causa-efecto para esta especificacin, y las proposiciones que
representa sera las siguientes:

Si C1 y C2, entonces E2
Si C1 y no C2, entonces E3
Si no C1, entonces E1

El paso siguiente es vaciar el grfico en la tabla de decisin siguiendo el

procedimiento siguiente para cada efecto (1 representa la presencia de la
causa o efecto, 0 representa su ausencia, y - indica que no se considera):
o Seleccione un efecto
o Retroceda a travs del grfico y encuentre todas las combinaciones de
causas que hagan que el efecto ocurra
o Cree una columna en la tabla de decisin para cada combinacin de
causas
o Determine, para cada combinacin, los estados de los dems efectos y
colquelos en la columna
Para este sencillo ejemplo, la tabla de decisin sera la siguiente:
Prueba 1

Prueba 2

Prueba 3

C1

C2

E1

E2

E3

3.4. Conjetura de errores

Esta tcnica consiste en que la(s) persona(s) que disean los casos de prueba
enumere posibles errores, en base a su experiencia e incluso- su intuicin. Es
un proceso ad-hoc, por lo que no hay un procedimiento establecido para hacer
conjeturas. Sin embargo, si se tienen documentados los defectos de las
versiones anteriores, o de programas similares, esta documentacin ser una
fuente muy valiosa para enriquecer la conjetura de errores.
Ejemplos tpicos son los casos en que puede ocurrir una divisin entre cero, la
manipulacin de arreglos y de punteros ms all de sus lmites, o las
condiciones del entorno del software.
4.

TECNICAS DE CAJA TRANSPARENTE

Al contrario del enfoque de Caja Negra, en este caso las tcnicas se basan en
el conocimiento de la estructura interna del software. El objetivo es asegurar
que los componentes del programa estn trabajando adecuadamente, por lo
que se debe conocer el cdigo o el seudo cdigo del software para forzar la
ejecucin de alternativas especficas del software (bifurcaciones, por ejemplo),
stas tcnicas son tiles para revelar defectos de lgica, control de condiciones,
secuenciacin e inicializaciones.
4.1. Cobertura lgica
Al analizar la estructura lgica interna an de programas relativamente
sencillos- nos damos cuenta que el nmero de las posibles secuencias lgicas
de ejecucin es muy grande, lo cual hace nuevamente- materialmente
imposible realizar pruebas exhaustivas que cubran todas las posibilidades. Por
ello, se requiere un criterio para determinar cuntos casos de prueba sern
necesarios para considerar que el software ha sido suficientemente probado.
Este criterio se le conoce como criterio de cobertura.
El criterio de cobertura ms simple e intuitivo podra ser: disear los casos de
prueba necesarios para que se ejecute por lo menos una vez cada sentencia
del programa. Pero para un programa como el del cdigo mostrado, este
criterio es muy dbil. Basara con hacer a = 2, b = 0 y x = 3 para cumplir con este
criterio. Sin embargo, podran pasarse por alto defectos en el sentido de los
operadores lgicos al codificar x < 1 en vez de x > 1, por ejemplo.
public void foo (int a, int b, int x) {
if (a > 1 && b == 0) {
x = x / a;
}
if (a == 2 || x > 1) {
x = x + 1;
}
}
Un criterio de cobertura bastante completo es el denominado Cobertura de
Condicin Mltiple que seala que deben disearse los casos de prueba
necesarios para que se invoquen por lo menos una vez cada una de las

combinaciones posibles de los resultados de condicin en cada decisin. Y si

se trata de programas con mltiples puntos de entrada, habra que agregar y
que se invoquen por lo menos una vez cada uno de los puntos de entrada.
Por ejemplo, para probar el programa anterior de manera adecuada se
deberan considerar ocho combinaciones:

1. a > 1, b = 0

5. a = 2, x > 1

2. a > 1, b 0

6. a = 2, x 1

3. a 1, b = 0

7. a 2, x > 1

4. a 1, b 0

8. a 2, x 1

En este ejemplo, las ocho combinaciones podran ser cubiertas con cuatro
casos de prueba:
1. a = 2, b = 0, x = 4
2. a = 2, b = 1, x= 1
3. a = 1, b = 0, x = 2
4. a = 1, b = 1, x = 1
4.2. Flujo de datos
Esta tcnica se basa en el rol de las variables dentro del programa y es til
para detectar defectos debido a la definicin, inicializacin y/o uso de las
mismas. Por su naturaleza, la eficacia de esta tcnica decae conforme el
tamao del programa aumenta, por lo que se recomienda para programas
pequeos y complejos.
Las variables de un programa pueden jugar diferentes roles en determinadas
sentencias: se les puede asignar un valor como en read x, o en x = y + 10; pueden
usarse como un predicado como en if x > 100; o para hacer un clculo como en y
= 25 * x. A las sentencias de asignacin se les denominar de definicin (def),
mientras que a las otras se les denominar de uso (uso)
Esta tcnica trata de analizar el flujo de datos desde las sentencias de
asignacin hasta aquellas donde se usan las variables. Para ello se debe
identificar y clasificar las ocurrencias de cada variable, ya que durante las
pruebas se deben ejecutar todas las asignaciones y todos los usos.
En el ejemplo siguiente se tienen cuatro variables cuenta, i, n y numero.
1
2
3
4
5
6

cuenta = 0
read (n)
i=1
while (i <= n)
read (numero)
cuenta = cuenta + 1

i=i+1
end while
print (cuenta)

7
8
9

El siguiente paso es tabular las ocurrencias de definicin y uso de cada

variable. En las tablas siguientes se especifica la lnea de cdigo en la que
aparece la variable y un nmero secuencial para cada flujo. Las variables
podran ser definidas y usadas en la misma sentencia.
cuenta
1
2
3
4

def uso
1
6
1
9
6
5
6
9

5
6
7
8

def uso
3
4
3
7
7
7
7
4

n
9

numero

def uso
2
4

10

def uso
5
6

Luego deben generarse los datos de prueba para ejecutar todos los flujos
tabulados. Para este ejemplo bastaran dos casos de prueba:
Datos de prueba

Flujos

n=0
2, 5, 9
n = 3; numero =1,2,3 1, 3, 4, 5, 6, 7, 8, 9, 10
4.3. Prueba de lazos (loops)
Los lazos o loops son estructuras de programacin a las que frecuentemente
estn asociados diversos defectos del software, por lo que merecen una
especial atencin.
Para un lazo simple que puede variar de cero a n iteraciones, se deben
considerar casos de prueba para:
o Cero iteraciones (el lazo no se ejecuta)
o Una iteracin
o Dos iteraciones
o k iteraciones (k < n)
o n 1 iteraciones
o n + 1 iteraciones (si es posible)
o Valor negativo para la variable de control del lazo
Si el mnimo de iteraciones fuera mayor a cero, pruebe con un nmero de
iteraciones menor al mnimo.
Para los lazos anidados los casos de prueba pueden crecer exponencialmente.
Para limitar este nmero de casos considere lo siguiente:
o Empiece con el nivel ms interno, poniendo los niveles externos en sus
valores mnimos.
o Pruebe el mnimo, el mnimo + 1, un nmero tpico, el mximo 1 y el
mximo nmero de iteraciones para el nivel ms interno.

o Suba un nivel, establezca un nmero tpico de iteraciones para el nivel

interno, repita el paso anterior para el presente nivel, manteniendo los
niveles externos en sus valores mnimos.
o Contine con este proceso hasta probar todos los niveles del lazo
anidado.
5.

CONCLUSIONES

La prueba de software tiene el objetivo de encontrar defectos, por lo que

deben ser realizadas por una persona, o un equipo de personas,
independiente del desarrollador del software.

Realizar todas las pruebas posibles generalmente es imposible, por

limitaciones de tiempo y de recursos materiales. La prueba de software
consistir en disear y ejecutar un nmero limitado de casos de prueba
que permita encontrar el mximo nmero de defectos.

La prueba de software usualmente requiere utilizar una combinacin de

tcnicas de caja negra y de caja transparente para lograr un conjunto de
casos de prueba consistente, combinacin que depender de las
caractersticas del software y de las limitaciones del entorno

6.

REFERENCIAS BIBLIOGRFICAS
Beizer, Boris; Software Testing Techniques - Second Edition; The
Coriolis Group; 1990
Black, Rex; Pragmatic Software Testing; John Wiley & Sons; 2007
Burnstein, Ilene; Practical software testing; Springer-Verlag New York
Inc.; 2003
Harinath P. V. y otros; Software Testing Guide Book; Software Testing
Research Lab; 2004
Myers, Glenford J.; The Art of Software Testing-Second Edition; John
Wiley & Sons, Inc.; 2004
Rojas, Johanna y Barrios, Emilio; Investigacin sorbe el estado del arte
en diseo y aplicacin de pruebas de software; Universidad Francisco
Jos de Caldas - Bogot; 2007