Escolar Documentos
Profissional Documentos
Cultura Documentos
1. INTRODUCCIÓN
Según la IEEE, probar el software es analizarlo para detectar diferencias entre
las condiciones existentes y las requeridas, y para evaluar las características
del mismo.
Obsérvese que -según esta definición- probar el software no consiste en
mostrar que el software realiza las funciones requeridas (“que funcione”). Por el
contrario, se debe partir de la suposición 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 diseñar 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 número
de casos de prueba debe ser finito y, por tanto, lo más 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 artículo se describen algunas técnicas para diseñar casos de prueba
del código ejecutable a nivel unitario. En la secciones siguientes se enumeran
los principios que deben guiar este tipo de pruebas y las dos clases de técnicas
que nos permiten diseñar 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 guiarán el accionar del profesional que
prueba del software. Ilene Burstein señala 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 intención de detectar defectos y de evaluar su
calidad.
Esto supone separar las pruebas de la depuración 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 aún no detectados.
Partiendo de la hipótesis 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 válidas e
inválidas.
La robustez del software se puede evaluar probando su funcionamiento
con entradas inválidas.
Principio 6
La probabilidad de que existan defectos adicionales en un componente
de software es directamente proporcional al número de defectos ya
detectados en ese componente.
Este principio se basa en la evidencia empírica. Las razones pueden ser
el nivel de complejidad o algunos defectos de diseño.
Principio 7
Las pruebas deben ser conducidas por personas independientes a las
que hicieron el desarrollo.
El desarrollador está síquicamente preparado para que su obra funcione
“bien”, de modo que le será muy difícil 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.
Además también serán muy útiles para las pruebas de regresión, es
decir, las que se realizarán cuando, por razones de evolución o mejora,
el software tenga que ser modificado.
3. TÉCNICAS DE CAJA NEGRA
El término “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 cómo lo hace. La materia prima para estas
técnicas puede ser la descripción funcional del software, las condiciones de
entrada y de salida, o un diagrama Entrada-Proceso-Salida bien especificado.
Las técnicas de Caja Negra permiten revelar defectos y/o ambigüedades en los
requerimientos y en las especificaciones del software.
3.1. Particiones de Equivalencia
En esta técnica, el dominio de datos de entrada es particionado en una
cantidad finita de clases de equivalencia (válidas e inválidas). Cualquier dato
miembro de una clase de equivalencia será un elemento representativo de
dicha clase y permitirá obtener información (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.
¿Cómo se identifican las clases de equivalencia?
El proceso de identificación de las clases de equivalencia es un proceso
heurístico que se basa –usualmente- en la descripción 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 condición especifica un rango de valores, se identifican
una clase de equivalencia válida y dos clases de equivalencia
inválidas”
Por ejemplo: CANTIDAD puede ser un valor entre 1 y 999. La clase
de equivalencia válida será 1 ≤ CANTIDAD ≤ 999. Una clase inválida
será CANTIDAD < 1, y otra clase inválida: CANTIDAD > 999.
2. ‘‘Si una condición especifica una cantidad de valores, se
identifican una clase de equivalencia válida y dos inválidas”
Por ejemplo: se pueden listar de 1 a 6 propietarios de un bien. La
clase de equivalencia válida será de 1 a 6 propietarios, mientras que
las dos inválidas serán: sin propietario y más de 6 propietarios.
3. ‘‘Si una condición especifica un conjunto de valores válidos, se
identifican una clase de equivalencia válida y una clase inválida”
Por ejemplo: el tipo de vehículo puede ser BUS, MICROBUS,
CAMIÓN, o AUTO. Se tendrán cuatro clases de equivalencia válidas
(los cuatro valores válidos) y una inválida (cualquier valor no
especificado, digamos “VOLQUETE”)
4. ‘‘Si una condición se especifica como debe ser, se identifican una
clase de equivalencia válida y una inválida”.
Por ejemplo: el primer carácter de un código debe ser una letra. La
clase de equivalencia válida será: es una letra; y la clase inválida: 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 particiónela en clases de equivalencia más pequeñas’’
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 válidas, hasta que todas hayan sido consideradas. Por el contrario,
cada clase de equivalencia inválida 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 código de
artículo con las características siguientes:
o Está compuesto por caracteres alfanuméricos
o El número de caracteres varía entre 4 y 8
o El primer carácter debe ser una letra
Las clases de equivalencia (CE) podrían ser:
o CE1 - El código ingresado es alfanumérico
o CE2 - El código ingresado NO es alfanumérico
o CE3 - El código ingresado tiene entre 4 y 8 caracteres
o CE4 - El código ingresado tienen menos de 4 caracteres
o CE5 - El código ingresado tiene más de 8 caracteres
o CE6 - El primer carácter es una letra
o CE7 - El primer carácter NO es una letra
Los casos de prueba para cubrir las clases de equivalencia identificadas
podrían ser:
Clases de
Clases de
Dato de prueba equivalencia
equivalencia válidas
inválidas
ABC123 CE1, CE3, CE6
AB*123 CE2
A CE4
ABCDEF123456 CE5
123ABC CE7
AB1 3
AB12 4
ABCD1234 8
ABCD12345 9
• Si C1 y C2, entonces E2
• Si C1 y no C2, entonces E3
• Si no C1, entonces E1
C1 1 1 0
C2 1 0 -
E1 0 0 1
E2 1 0 0
E3 0 1 0
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 podrían 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
cuenta i n numero
def uso def uso def uso def uso
1 1 6 5 3 4 9 2 4 10 5 6
2 1 9 6 3 7
3 6 5 7 7 7
4 6 9 8 7 4
Luego deben generarse los datos de prueba para ejecutar todos los flujos
tabulados. Para este ejemplo bastarían dos casos de prueba: