Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Tecnicas Disenar Casos de Prueba Del Software Carlos Nunez
Tecnicas Disenar Casos de Prueba Del Software Carlos Nunez
INTRODUCCIN
2.
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
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
Clases de
equivalencia vlidas
Clases de
equivalencia
invlidas
ABC123
AB*123
CE2
CE4
ABCDEF123456
CE5
123ABC
CE7
Valores lmite
AB1
AB12
ABCD1234
ABCD12345
Si C1 y C2, entonces E2
Si C1 y no C2, entonces E3
Si no C1, entonces E1
Prueba 2
Prueba 3
C1
C2
E1
E2
E3
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
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
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.
CONCLUSIONES
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