TECNICAS DE PRUEBA
DEL SOFTWARE
CLAVE
Te, quienes por naturaleza son personas constructivas. Las pruebas reas
Ten que el desarrollador descarte nociones preconcebidas de lo que
“cortecto” en el software y entonces disene dificiles casos de prueba para “=
perlo’. Beizer [BEI90] describe bien esta situacion cuando afirma
Conceptos z: as pruebas representan un interesante reto para los ingenieros de sof
Es un mito que si realmente fteramos buenos para programar no tendriamos que
Purar errores. Si tan s6lo pudiéramos concentramos, si todos usaran programacsa
estructurada, diseRo descendente o tablas de decision, si los programas se escritie
ran en SQUISH, si tuviéramos las balas plateadas correctas, entonces no habria em
res. Ese es el mito. Hay errores, dice e! mito, porque somos malos en lo que hacema|
¥ Si somos malos en ¢so, debemos sentimes culpables. Por tanto, el disefio de pes
trones. «8
* me bas y de casos de prueba ¢s una admision de la falla, que instila una buena dosis:
ius culpa. ¥ el tedio de probar s6lo es un castigo por nuesttos errores, «Castigo por gu
faorten . a @Por ser seres humanos? 14.4.1 Notacién de gr&tica de flujo
Antes de tratar el método de la ruta basica, debe presentarse una notacién simple
para la representacién del flujo de control, llamado grifica de flujo (0 grifica del pro
‘grama).. La grafica de flujo describe un flujo de control logico empleando la notacion
ilustrada en la figura 14.1. Cada construccién estructurada (capitulo 11) tiene su sim-
ienperente sey bolo correspondiente en la gréifica de flujo
° El uso de una grdfica de flujo se ilustra considerando la representaci6n del dise
fo procedimental de la figura 14.2a. Aqui se describe la estructura de control del pro-
de pogroms de tama mediante un diagrama de flujo. En la figura 14.2b se correlaciona (0 mapea)
coms bgt _€l diagrama de flujo con su grafica de flujo correspondiente (suponiendo que no exis.
ten condiciones compuestas en los diamantes de decision del diagrama de flujo). To-
3. En realidad, el método de la ruta basica se aplica sin el uso de
ven como notacién ail para comprender el flujo de control e
Aujo. Sin embargo, sit
lustrar el enfoque. PARTE DOS PRACTICA DE LA INGENIERIA DEL SOFTWARE
mando como referencia la figura 14.2b, cada circulo, Hamado nodo de griifica de fic
jo, tepresenta una o més instrucciones procedimentales. Una secuencia de recus
dros de proceso y un diamante de decisién se correlaciona con un solo nodo. Las fie
chas en la grafica de flujo, llamadas aristas o enlaces, representan el flujo de contrat
y son analogos a las flechas de los diagramas de flujo. Una arista debe terminar e
un nodo, aunque el nodo no represente ninguna instruccion procedimental (par
ejemplo, véase el simbolo en la grafica de flujo para la construcci6n if-then-else det
figura 14.1). Las areas que limitan aristas y nodos se denominan regiones. Cuande
se cuentan las regiones se incluyen las areas ubicadas fuera de la grafica.*
Notacien de Las constucciones estructuradas en forma de grética de flujo:
a LA
Donde code circulo representa una 0 més
instruceiénen LDP sin ramificaciones 0 de cédigo fuente
‘@ Diagrama de flujo y b) grética de flujo.
4 Unandlisis mas detallado de las gréficas y su aplicacién se presentara en la seccion 14.6.1 CAPITULO 14 thcwicas De PRUEBA DEL SOFTWARE A265
‘Cuando se encuentran condiciones compuestas en un disefio procedimental, la
generacion de una grafica de flujo se vuelve ligeramente mas complicada. Una con-
dicién compuesta ocurre cuando hay uno o mas operadores booleanos (OR, AND,
NAND, NOR) en una instruccién condicional. Tomando como referencia la figura
14.3, el segmento en LDP se traduce a la grafica de flujo mostrada. Obsérvese que se
crea un nodo separado para cada una de las condiciones a yb en la instruccién IF a
OR b. Cada nodo que contiene una condicién es un nodo predicado y se caracteriza
porque de él emanan dos o més aristas.
14.4.2 Rutas independientes del programa
Una ruta independiente es cualquier ruta del programa que ingresa por lo menos un
nuevo conjunto de instrucciones de procesamiento o una nueva condicién, Cuando
se explica desde el punto de vista de una grafica de flujo, una ruta independiente de-
be recorrer por lo menos una arista que no se haya recorrido antes. Por ejemplo, a
continuacion se presenta un conjunto de rutas independientes en la grafica de flujo
de la figura 14.2b:
ruta 1: 1-11
ruta 2: 1-2-3-4-5-10-1-11
Tuta 3: 1-2-3-6-8-9-10-1-11
Tuta 4: 1-2-3-6-7-9-10-1-11
Obsérvese que cada nuevo camino ingresa una nueva arista. El camino
1-2-3-4-5-10-1-2-3-6-8-9-10-1-1]
no se considera una ruta independiente porque se trata simplemente de una combi
nacion de rutas ya especificadas y no recorre ninguna arista nueva.
Los caminos 1, 2, 3 y 4 constituyen un conjunto basico para la grifica de flujo de
Ja figura 14.2b. Es decir, si se disefian pruebas para forzar la ejecucion de esas rutas
Nodo
eae
FoORb
then procedimiento x
else procedimiento y
ENDIF 426
Sonu
to conplojdsd
odoandtica es uno
ite ue results
‘i pa prees
cules moduios tienen
‘ms probabil de
contener erores, Se
empleo pora fo plo-
eoctin de pruebas
cademés del disefio de
casos de poeta.
2 Como 50
‘alela la
| complejidad ciclo-
matica?
”
CLAVE
Lo complied
= mins AND wi 0. 90
tg WO pedi = eae tts:
Rot pomede 900:
210 promedio
nales en el PDL (para el procedimiento promedio, las condiciones comp:
cuentan como dos) y se suma | al resultado, Tomando como referencia la
gura 14.5,
VG) = 6 regiones
V(G) = 17 aristas ~ 13 nodos + 2 = 6
V(G) = 5 nodos predicado + 1 = 6
Determinese un conjunto basico de rutas linealmente indepen:
El valor de V(G) indica el namero de rutas linealmente independientes de l=
estructura de control del programa. En el caso del procedimiento promedis
espera especificar seis caminos:
tuta I: 1-2-10-11-13
futa 2: 1-2-10-12-13,
Tuta 3: 1-2-3-10-11-13,
Tuta 4: 1-2-3-4-5-8-9-2-.
Tuta 5: 1-2-3-4-5-6-8-9-2-
Tula 6: 1-2-3-4-5-6- aL]
CAPITULO 14 TECINCAS DE PRUEBA DEL SOFTWARE 429
Los puntos suspensivos (...) que siguen a las rutas 4, 5y 6 indican que es
aceptable cualquier ruta que se recorra en el resto de la estructura de control
‘A menudo vale la pena identificar nodos predicado como apoyo para derivar
los casos de prueba. En este caso, los nodos 2, 3, 5, 6 y 10 son nodos predicado.
4, Preparense los casos de prueba que forzaran la ejecucion de cada ru-
ta en el conjunto basico. Es necesario seleccionar los datos de manera tal
que se establezcan apropiadamente las condiciones de los nodos predicado, a
medida que se prueba cada ruta, Cada caso de prueba se ejecuta y compara
con los resultados esperados. Una vez completados todos los casos, la perso-
na que aplica la prueba puede estar segura de que todas las instrucciones del
programa se han ejecutado por lo menos una vez
Es importante observar que es imposible probar algunas rutas independientes
(como la ruta | en nuestro ejemplo) por separado. Es decir, en el flujo normal del
programa no puede obtenerse la combinacién de los datos requeridos para recorrer
la ruta, En tales casos, estas rutas se ejercitan como parte de otra prueba del camino.
ia
F
a is on
3 s
4 (Ete
2 g
Motriz de grética
Gréfica de flujo PARTE DOS PRAcTicA De LA INGENIERIA DEL SOFTWARE
14.4.4 Matrices de gréticas
El procedimiento para derivar la grafica de flujo e incluso determinar un conjunto de
tutas basicas es sensible a la mecanizaciOn. Una estructura de datos denominad
matriz de gréfica resulta muy «til para desarrollar una herramienta de software que
ayude en la prueba de la ruta basica.
Una matriz de grafica es una matriz cuadrada cuyo tamano (es decir, el nimess
de filas y columnas) es igual al ntimero de nodos en la grafica de flujo. Cada fil
columna corresponde a un nodo identificado, y las entradas de la matriz correspom
den a las conexiones (una arista) entre nodos. En la figura 14.6 se muestra un ejem
plo simple de una grafica de flujo y su matriz de grafica correspondiente [BEI90}.
Tomando como referencia la figura, cada nodo en la grafica esté identificado com:
numeros, mientras que cada arista se identifica con letras. Una conexién entre dae
nodos se indica creando una entrada de letra en la matriz. Por ejemplo, el nodo 3
conecta al nodo 4 con la arista b.
Hasta este punto, la matriz de gréfica no es mas que una representaciOn tabull
de una grafica de flujo. Sin embargo, al agregar un peso de enlace a cada una de
entradas, la matriz de grafica se convierte en una herramienta poderosa para ©
luar la estructura de control del programa durante la prueba. El peso de enlace
porciona informacién adicional acerca del flujo de control..En su forma mas simi
el peso de enlace es | (existe una conexidn) o 0 (no existe una conexi6n). Pero 2!
pesos de enlace también se le asignan otras propiedades, mas interesantes:
* La probabilidad de que se ejecute un enlace (arista)
* El tiempo de procesamiento gastado durante el recorrido a un enlace.
* Lamemoria requerida durante el recorrido de un enlace.
* Los recursos requeridos durante el recorrido de un enlace.
Beizer [BEI90} proporciona un tratamiento completo de algoritmos mates
adicionales que son aplicables a una matriz de grafica. El empleo de estas técx
permite automatizar parcial o totalmente el andlisis requerido para disefar ca
prueba.
La técnica de prueba de la ruta bésica descrita en la seccién 14.4 es una de ws
técnicas para la prueba de estructuras de control. Aunque la prueba de la ruta
caes simple y efectiva, no es suficiente por si misma. En esta seccion se ana
brevemente variaciones sobre la prueba de estructuras de control. Estas e
la cobertura de las pruebas y mejoran la calidad de la prueba de caja blanca Vv
son micho
so as
eas
gins qua
so mismo de
CAPITULO 140 TicNicas DE PRUEBA DEL SOFTWARE 431
14.5.1 Prueba de condicién
La prueba de condicién (TAI89| es un método de disefio de casos de prueba que ejer-
cita las condiciones légicas contenidas en un médulo del programa. Una condicién
simple es una variable booleana o una expresion relacional, tal vez precedida con un
operador NOT (-), Una expresién relacional toma la forma
E, Ey
donde E, y E, son expresiones aritméticas y es uno de los si
guientes: <, <, =, # (desigual), > 0 =. Una condicién compuesta la integran dos 0
mas condiciones simples, operadores booleanos y paréntesis. Se supone que entre
los operadores booleanos permitidos en una condicion compuesta se incluyen OR (),
AND (&) y NOT (-). Una condici6n sin expresiones relacionales se considera una ex-
presién booleana. Por tanto, los posibles tipos de elementos en una condicién inclu
yen un operador booleano, una variable booleana, un par de paréntesis (que encie
fran una condicion booleana simple o compuesta), un operador relacional 0 una ex-
presién aritmética.
Si una condici6n es incorrecta, entonces por lo menos un componente de la con.
dici6n es incorrecto. Por tanto, entre los tipos de errores en una condicion se inclu
yen los presentes en el operador booleano {operadores booleanos incorrectos/fal-
tantes/adicionales), en la variable booleana, en los paréntesis booleanos, en los
operadores relacionales y en la expresion aritmética. E] método de prueba de candi
cién se concentra en la prueba de cada condicién del programa p.
no contiene errores.
asegurar que
14.5.2 Prueba del flujo de datos
EI método de prueba del flujo de datos selecciona rutas de prueba en un programa de
acuerdo con las ubicaciones de las definiciones y los usos de las variables en el pro-
grama. El enfoque de prueba del flujo de datos se ilustra suponiendo que a cada ins-
truccién de un programa se le asigna un néimero de instrucci6n, y que ninguna fun
cién modifica sus parametros o variables globales. En el caso de una instruccién con
I como ntimero de instruccién
DEF()
USO(I) = {X | instruccién J contiene un uso de X)
(X/| instrucci6n / contiene una definicion de X)
Sila instrucci6n / es una instruccién if (si) 0 Joop (bucle), su conjunto DEF esta vacio
y Su conjunto USO se basa en la condicion de la instruccién J, Se dice que la defi
cidn de la variable x en la instrucci6n J esta viva en la instruccién 1’ si existe una ru
ta de la instruccion fa {a I’ que no contiene otra definicion de X
Una cadena definicién-uso (DU) de la variable X es de la forma [X, I", donde /e
I’ son nuimeros de instrucci6n, x esta en DEF(l) y USO(I’), y la definicién de X en la
instruccion / esta viva en la I 432 PARTE DOS PRACTICA DE LA INGENIRIA DEL SOFTWARE
@ > Una estrategia simple de prueba de flujo de datos consiste en solicitar que cai
eer adena DU sea cubierta por lo menos una vez, Esta estrategia se denomina estrat=
Noes alta gia de prueba DU. Se ha mostrado que ésta no garantiza la cobertura de todas las m=
osagurar que ks mas de un programa. Sin embargo, s6lo en raras situaciones no se garantiza que wm
ae, - rama esté cubierta por una prueba DU, como en las construcciones if-then-else
vee onee entonces-si_no) en que la parte then no tiene definicion de alguna variable y la
anniose pustown te else no existe. En esta situacion, la rama else de la instruccin jfno est neces
sistemo gronde. riamente cubierta por la prueba DU. Se han estudiado y comparado varias e:
Saentows weit gias de prueba de flujo de datos (por ejemplo, (FRABS], [NTA], [FRA93). los i
shade gun bone vores interesados se les recomienda que consideren consultar esas referencias
en dies de softwue —_bliograficas.
‘que estin boo
sospcta
14.5.3 Prueba de bucles
Los bucles son la piedra de toque para la gran mayoria de los algoritmos imp
tados en software. Y aun asi, a menudo se les presta poca atencion mientras se
lizan pruebas de software
La prueba de bucles es una técnica de prueba de caja blanca que se concentra!
clusivamente en la validez de la construccién de bucles. Es posible definir cuats
ferentes clases de bucles [BEI90]: bucles simples, concatenados, anidados y ne
tructurados (figura 14.7).
URC es
baa E i
: Bucles anidados
Bucles simples
Bucles
concatenados
Bucles
no estructurados CAPITULO 14 Técwicas DE PRUEHA DEL SOFTWARE 433
Bucles simples. El siguiente conjunto de pruebas se aplica a bucles simples, don
de'n es el nlimero maximo de pasos que permite el bucle,
1, Omitir por completo el bucle
2. Solo un paso por el bucle
3. Dos pasos por el bucle
4. m pasos por el bucle, donde m <
5. n= 1,n,n +1 pasos por el bucle
Bucles anidados. i se fuese a extender el enfoque de prueba de los bucles sim-
ples a los anidados, el ntimero de pruebas posibles creceria geométricamente a me-
dida que aumente el nivel de anidamiento. Esto generaria un ntimero poco practico
de pruebas. Beizer (BEI90] sugiere un enfoque que ayudard a reducir el mimero de
pruebas:
1. Iniciar en el bucle mas interno, Asignar a todos los bucles los valores mini
mos.
2. Aplicar pruebas de bucle simple al mas interno mientras se mantienen los ex-
ternos en los valores minimos del parametro de iteracién (como el contador
de bucles). Agregar otras pruebas para los valores fuera de rango o excluidos,
3. Trabajar hacia fuera, conduciendo pruebas para el siguiente bucle, pero man
teniendo todos los demds bucles externos en valores minimos y otros bucles
anidados en valores “tipicos”.
4. Seguir mientras no se hayan probado todos los bucles.
Bucles concatenados. Los bucles concatenados se prueban empleando el enfo
que definido para los bucles simples, si cada uno de los bucles es independiente. Sin
embargo, si dos bucles estait concatenados y el contador del bucle | se emplea como
roustio valor inicial para el bucle 2, entonces los bucles no son independientes. Cuando los
sepodéprobar _-bucles no lo son, entonces se recomienda el enfoque aplicado a los bucles anidados
wéxaih bs tks Buctes no estructurados. Siempre que sea posible, esta clase de bucles debe di-
yesructurodos. oo
voherg _Seflarse nuevamente para reflejar el uso de las construcciones de programacién es:
ors tructurada (capitulo 11)
eS ea eee
Las pruebas de caja negra, también denominadas, pruebas de comportamiento, se
concentran en los requisitos funcionales del software. Es decir, permiten al ingenie-
ro de software derivar conjuntos de condiciones de entrada que ejercitaran por com
pleto todos los requisitos funcionales de un programa. La prueba de caja negra no
€s una opci6n frente a las técnicas de caja blanca. Es, en cambio, un enfoque com-
plementario que tiene probabilidades de descubrir una clase diferente errores di
que se descubririan con los métodos de caja blanca. ® eCuiles
preguntas
responden las
pruebas de caja
negra?
%,
CLAVE
‘Una giéfca representa
{os elaine entre os
objets de datos y los
de rogoa, lo que
peste deo casos
do pruetn ve
tusque eres
‘sociadas con estas
rlociones
a
PARTE DOS PRACTICA DE LA INGEMERIA DEL SOFTWARE
Las pruebas de caja negra tratan de encontrar errores en las siguientes cat:
rias: 1) funciones incorrectas o faltantes, 2) errores de interfaz, 3) errores en estru
turas de datos 0 en acceso a bases de datos externas, 4) errores de comportamics
to 0 desempefio, y 5)-errores de inicializacion y término.
A diferencia de las pruebas de caja blanca, que se realizan al inicio del proceso a
prueba, las de caja negra tienden a aplicarse durante las tltimas etapas de la prae
ba (constiltese el capitulo 13). Debido a que éstas desatienden a propésito la estras
tura de control, la atencién se concentra en el dominio de la informacion. Las prae
bas estan disefiadas para responder las siguientes preguntas:
* gComo se prueba la validez funcional?
+ Como se prueban el comportamiento y el désempenio del sistema?
* eCudles clases de entrada seran buenos casos de prueba?
* gl sistema es particularmente sensible a ciertos valores de entrada?
* Como se aislan los limites de una clase de datos?
* eCuéles tasas de datos y cual volumen tolera el sistema?
* Qué efecto tienen combinaciones especificas de datos sobre la operacion
sistema?
Al aplicar técnicas de caja negra se deriva un conjunto de casos de prueba que
tisfacen los siguientes criterios [MYE79]: 1) casos de prueba que reducen, medi
una cuenta mayor que uno, el numero de casos de prueba adicionales que deben
sefiarse para alcanzar una prueba razonable, y 2) casos de prueba que indican
acerca de la presencia o ausencia de clases de errores, en lugar de un error as
do sélo con la prueba especifica a la mano.
14.6.1 Métodos gréticos de prueba
El primer paso en la prueba de caja negra es comprender los objetos® modela
el software y la relacién entre ellos. Una vez que se ha logrado, el siguiente
consiste en definir la serie de pruebas que verifican que “todas los objetos ti
relacién esperada entre si" [BEI95]. Explicado de otra manera, la prueba de so
re empieza al crear una grafica de objetos importantes y sus relaciones y lue;
una serie de pruebas que cubran la grafica de tal manera que se ejercite cada
toy relacién y que se descubran los errores.
Para dar estos pasos, el ingeniero de software empieza creando una gréfice
coleccién de nodos que representan objetos, enlaces que representan la relaciém
tre objetos, pesos de nodo que describen las propiedades de un nodo (como un
de datos o un comportamiento de estado especifico) y pesos de enlace que de:
algunas caracteristicas de un enlace.
5. Eneste caso el término “objetos” se considera en el contexto mas amplio posible. Abarca cbjetos
tos, componentes (médulos) tradicionales y elementos orientados a objetos del software de c CAPITULO 14. TECNICAS DE PRUEBA DEL SOFTWARE 438
Enlace dirigido
yb)
Peso de! node
{valor}
Enlaces paralelos
Enlace no dirigido
4)
Permite la edicién de
Atributos:
Contiene Dimensién inicial: valor 0
preferencias
predeterminados
Color de fondo: blanco
Color de texto: color o
preferencias
Es representada como
6)
En la figura 14.8a se muestra una representaci6n simbolica de una grafica. Los
nodos se representan como circulos conectados por enlaces que toman un ntimero
diferente de formas. Un enlace directo (representado por una flecha) indica que una
relacion se mueve en una sola direccion. Un enlace bidireccional, también denomi-
nado enlace simétrico, indica que la relacién se aplica en ambas direcciones. Los en-
laces paralelos se emplean cuando se establece un nimero diferente de relaciones
entre los nodos de la grafica.
Como ejemplo simple, considérese una parte de la grafica para una aplicacion de
procesamiento de palabras (figura 14.8b) donde
Objeto #1 = nuevoArchivo (ment seleccién)
Objeto #2 = ventanaDocumento
Objeto #3 = textoDocumento
Si se toma como referencia la figura, una seleccién del ment en nuevoArchivo ge-
nera una ventana de documento, El peso del nodo de ventanaDocumento propor-
ciona una lista de los atributos de la ventana que se esperaban cuando ésta se ge
neré. El peso del enlace indica que la ventana debe generarse en menos de 1.0 se-
gundos. Un enlace indirecto establece una relacién simétrica entre la seleccién del
menti nuevoArchivo y textoDocumento, y los enlaces paralelos indican las rela-
ciones entre ventanaDocumento y textoDocumento. En realidad, tendria que ge
nerarse una grafica mucho mas detallada como precursora del disefio de casos de
prueba. El ingeniero de software deriva entonces los casos de prueba al recorrer la ensue
os condones de
toda son conoid
en um ehpa reve
mente aro det
proceso de softwere.
Pest, debe emp
zane o pers en kt
portctn equivalent
rents sooo dt
sto.
PARTE DOS PRACTICA DE LA INGENTERIA DEL SOPTWARE
grafica y cubrir cada una de las relaciones mostradas. Estos casos de prueba se @&
sefaran en un intento de encontrar errores en cualquiera de las relaciones.
Beizer [BEI95] describe varios métodos de prueba de comportamiento que us2=
graficas:
Modelado del flujo de transacci6n. Los nodos representan pasos de alguna tram
sacci6n (por ejemplo, los pasos requeridos para hacer una reservacion en una acer
linea empleando un servicio en linea) y los enlaces representan la conexion logics
entre los pasos. El diagrama de flujo de datos (capitulo 8) se utiliza para ayudar
la creacion de graficas de este tipo.
Modelado de estado finito. Los nodos representan los diferentes estados que =
usuario observa en el software (por ejemplo, cada una de las “pantallas” que apar=
cen cuando un empleado toma un pedido por teléfono) y los enlaces representan las
transiciones que ocurren para ir de un estado a otro. El diagrama de estado (capita
lo 8) ayuda a crear graficas de este tipo
Modelado del flujo de datos. Los nodos son objetos de datos, y los enlaces sam
las transformaciones que ocurren para traducir un objeto de datos en otro. Por €}
plo, el nodo impuesto retenido por FICA (IRF) se calcula a partir de salario
to (SN) empleando la relacion IRF = 0.62 x SN.
Modelado relacionado con el tiempo. Los nodos son objetos de programa,
enlaces son las conexiones secuenciales entre esos objetos. Con los pesos de ent
ce se especifican los tiempos de ejecucién requeridos mientras el programa se
cuta.
Un anilisis detallado de cada uno de estos métodos graficos de prueba se encu
tra mas alld del alcance de este libro. El lector interesado debe consultar [BEI95]
ra tener una cobertura completa.
14.6.2 Particién equivalente
La particién equivalente es un método de prueba de caja negra que divide el do
nio de entrada de un programa en clases de datos a partir de las cuales pueden
rivarse casos de prueba. Un caso de prueba ideal de manejo simple descubre
clase de errores (por ejemplo, procesamiento incorrecto de todos los datos de car
teres) que, de otra manera, requeriria la ejecucién de muchos casos antes de que
observe el error general. La particién equivalente se esfuerza por definir un caso
prueba que descubra ciertas clases de errores, reduciendo asi el nuimero total de
sos de prueba que deben desarrollarse.
El disefio de casos de prueba para particion equivalente se basa en una ev
cién de las clases de equivalencia para una condicién de entrada. Con el uso de
conceptos introducidos en la seccién anterior, si es posible enlazar un conjun'
objetos mediante relaciones simétricas, transitivas y reflexivas, entonces existe
clase de equivalencia [BEI95]. Una clase de equivalencia representa un conjunte
estados validos y no validos para las condiciones de entrada. Por lo general CAPITULO 140 técwicas DE PRUEBA DEL SOPTWARE 437
condicién de entrada es un valor numérico especifico, un rango de valores, un con
junto de valores relacionados 0 una condici6n booleana. Las clases de equivalencia
se definen de acuerdo con las siguientes directrices:
1. Si una condici6n de entrada especifica un rango, se definen una clase de equi-
valencia valida y dos no validas.
ties es 2. Si una condicién de entrada requiere un valor especifico, se definen una clase
te de equivalencia valida y dos no validas.
Fara 3. Siuna condicién de entrada especifica un miembro de un conjunto, se definen
una clase de equivalencia vélida y otra no valida
. Si una condicién de entrada es booleana, se definen una clase de equivalen.
cia valida y otra no valida
Al aplicar estas directrices para la derivacion de clases de equivalencia, se desa-
rrollaran y ejecutaran los casos de prueba para cada objeto de los datos del dominio
de entrada. Los casos de prueba se seleccionan de modo que el mayor numero de
atributos de clase de equivalencia se ejercita una vez.
14.6.3 Anélisis de valores limite
Es mayor el numero de errores que se presenta en los limites del dominio de entra-
da que en el "centro"; por ello se ha desarrollado el andlisis de valores limite (AVL) co-
mo técnica de prueba. El AVL lleva a una seleccién de casos que prueba los valores
limite.
El andlisis de valores limite es una técnica de disefto de casos de prueba que com
plementa la particion equivalente. En lugar de seleccionar cualquier elemento de
una clase de equivalencia, el AVL lleva a la seleccidn de casos de prueba en las “aris
tas” de la clase. En lugar de concentrase exclusivamente en las condiciones de en.
trada, el AVL también deriva casos de prueba del dominio de salida (MYE79].
Las directrices para el AVL son muy similares a las proporcionadas para la patti-
cién equivalente:
CLAVE _ * Siva condicion de entrada especitica un rango timitado por los valoresa y b,
los casos de prueba deben disefiarse con esos valores, ademas de los que se
ts aqdciete encuentran apenas arriba y abajo de ellos
sacertrarse en los . Si una condici6n de entrada especifica diversos valores, deben desarrollarse
pes des “ots casos de prueba que ejerciten los ntimeros maximo y minimo. También se
imo thse de
silencio prueban los valores ubicados apenas arriba y abajo de estos maximos y mini
mos,
3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ejemplo, supénga
‘sé que una tabla que compara presion y temperatura se requiere como salida
Cor
en de un programa de andllisis de ingenieria. Los casos de prueba deben diseniar-
puedo crear
eases de prueba se para crear un informe de salida que produzca el ntimero maximo (y mini-
a? mo) permisible para las entradas de la tabla ”
CLAVE
lo peta de bia
rtogonel pete
dian cass de
‘pruebo que
ropoonan fa
xine coat de
prueba con un mero
‘ororble de cas de
prueba,
PARTE DOS PRACTICA DE LA INGEMERIA DEL SOFTWARE
4. Sila estructura interna de datos del programa tiene limites prescritos (por
ejemplo, una matriz que tiene un limite definido de cien entradas) debe dise
arse un caso de prueba para ejercitar los limites de la estructura de datos
La mayoria de los ingenieros de software realizan intuitivamente el AVL, hasta
to grado. Al aplicar estas directrices, la prueba de limites estaré mas completa:
tanto, tendrd una mayor probabilidad de detectar errores.
14.6.4 Prueba de tabla ortogonal
Hay muchas aplicaciones en las cuales el dominio de entrada es relativamente fi
ado. Es decir, el numero de parametros es pequeno y los valores que cada p:
tro puede tomar estan claramente limitados. Cuando estos nimeros son muy
hos (por ejemplo, tres parémetros de entrada toman tres valores discretos cada
es posible considerar cada permutacién de entrada y probar exhaustivamente &
cesamiento del dominio de entrada, Sin embargo, a medida que crece el nti
valores de entrada, junto con el ntimero de valores discretos para cada element
prueba exhaustiva se vuelve poco practica o imposible.
La prueba de tabla ortogona! se aplica en problemas en los cuales el domin
entrada es relativamente pequefio, pero demasiado grande para una prueba ext
tiva. El método de prueba de tabla ortogonal resulta titil sobre todo para enc
errores asociados con las falas de region (una categoria de error asociada con i
fectos de la logica en un componente de software)
ilustrar la diferencia entre la prueba de tabla ortogonal y los enfoques mas
cionales de “un elemento de entrada a la vez” requiere imaginar un sistema co
elementos de entrada, X, Y y Z. Cada uno de estos elementos tiene tres valorest
cretos asociados. Hay 3° = 27 casos de prueba posibles. Phadke [PHA97] sug
concepto geométrico, que se ilustra en la figura 14.9, para los posibles cas
prueba asociados con X, ¥ y Z. Si toma como referencia la figura, s6lo un el
de entrada podria variar a un mismo tiempo en la secuencia que sigue cada 3
entrada. Esto da como resultado un cobertura relativamente limitada del dominio.
trada (que representa el cubo de la izquierda de la figura)
Cuando se presenta una prueba de tabla ortogonal se crea una tabla ortoga
de casos de prueba, la cual tiene una “propiedad de equilibrio” (PHA97]. Es 4
casos de prueba (representados con puntos azules en la figura) estan “uniform
te dispersos por todo el dominio de la prueba”, como se ilustra en el cubo de la
de la figura 14.9. La cobertura de prueba en el dominio de entrada es mas cot CAPITULO 14 técwICAS DE PRUEBA DEL SOFTWARE
a
Y
a) x—
Un elemento de entrada a la vez Tabla ortegonal LO
Para ilustrar el uso de la tabla ortogonal L9, considérese la funcién enviar de una
aplicacién de fax. Se pasan cuatro pardmetros, P1, P2, P3 y P4 a la funcion enviar.
Cada uno toma tres valores discretas, Por ejemplo, P1 toma los valores:
Pi = 1, enviarlo ahora
PI = 2, enviarlo en una hora
PI =3, enviarlo a medianoche
P2, P3 y P4 también podrian tomar los valores 1, 2 y 3, representando otras funcio-
nes de enviar.
Si se eligiera una estrategia de prueba “un elemento de entrada a la vez", se es-
pecificarian las siguientes secuencias de prueba (P1, P2, P3, P4): (I, 1, 1, 1), 2, 1, 1
H,81 10, 0,2,1,0, 3,10, 0,12, 1,0, 1,30, , by, 1, 1 3)
Phadke [PHA97] evaliia estos casos de prueba al afirmar:
Estos casos de prueba sélo son titiles cuando se esta seguro de que los parémetros de
prueba no interactiian, Detectaran fallas de logica donde un solo valor de parametro ha
ce que el software funcione mal. Se trata de fatllas de madalidad simple, Este método no de-
tecta fallas de légica que provoquen un mal funcionamiento cuando dos o mas parametros
toman ciertos valores simulténeamente; es decir, no detecta interacciones. Por tanto, su
capacidad pata detectar fallas esta limitada
Dado el numero relativamente pequefio de parametros de entrada y valores discre
tos es posible aplicar una prueba exhaustiva. El niimero de pruebas requeridas es 3°
81 (grande, pero manejable). Se encontrarian todas las fallas asociadas con permu-
tacion de elementos de datos, pero el esfurerzo requerido es relativamente alto.
El enfoque de prueba de tabla ortogonal permite proporcionar buena cobertura de
prueba con un nuimero considerablemente menor de casos de prueba que la estra-
tegia exhaustiva. En la figura 14.10 se muestra una tabla ortogonal L9 para la fun-
cién enviar de fax
A continuacién se presenta la evaluacién de Phadke [PHA97] acerca de las prue-
bas aplicadas con la tabla ortogonal. PARTE DOS PRACTICA De LA INGENERIA DEL SOFTWARE
Detecta y aisla todas las fallas de modalidad simple. Una falla de modalidad =~
ple es un problema consistente con cualquier nivel de cualquier pardmetro simple. Par
ejemplo, si todos los casos de prueba del factor PI = 1 causan una condicién de error se
trata de una falla de modalidad simple. En este ejemplo, las pruebas 1, 2 y3 (figura 14 0)
‘mostrarén errores, Al analizar la informacién acerca de cuales pruebas muestran errores:
se identifican cuales valores de parémetros causan la falla. En este ejemplo, al notar que
las pruebas 1,2 y 3 causan errores, se aisla [el procesamiento logico asociado con “enviae=
lo ahora” (PI = 1)] como la fuente del error. Este aislamiento de la falla es important
ra corregirla.
Detecta todas las fallas de modalidad doble. Si existe un problema consistexte
cuando se presentan niveles especificos de dos parametros al mismo tiempo, se le dene
mina falla de modatidad doble. Por supuesto, se trata de una indicacién de incompatisl
dad de un par de valores o de interacciones daftinas entre dos parametros de prueba
Fallas multimodales. Las tablas ortogonales (del tipo mostrado) s6lo aseguran la de
teccién de fallas de modalidad simple y doble. Sin embargo, estas pruebas también detec
tan muchas fallas multimodales.
Un analisis detallado de las pruebas de tabla ortogonal se encontrara en [PHAS
Disetio de casos de prueba
Objetive: Ayudar al equipo de software © de- pos diferentes de herromientas de prueba estitica en ex
sarrollar un conjunio completo de casos de _herramientas de pruebo basodes en edi, lenguaiee
prucba de caja blanca y negra. prueba especializades y herramientas de pruebo
‘Mecénica: Estas herramientas coen en dos amplias cate- 9 Fequisitos. Las herramientas de prueba basados en
gorias: pruebas estaticas y dinémicas. Se emplean tres ti- digo aceptan eédigo fuente como entrada y reclizan w=
rios andlisis que llevan a lo generacién de casos de ba. Los lenguojes de prueba especializados (como
ppermiten gue un ingeniero de software escriba es-
iones detolladas que describen cada caso de
be y le logistica para su ejecucién. Las herramientas
jervebo basadas en requistos asdan requisits expect
You might also like
- El Proceso Unificado de Desarrollo de Software - Jacobson - Booch - RumbaughDocument458 pagesEl Proceso Unificado de Desarrollo de Software - Jacobson - Booch - RumbaughEfrain Cortez86% (43)
- Ingenieria de Software Un Enfoque Practico.6th - Edicion-.Roger - Pressman.4Document198 pagesIngenieria de Software Un Enfoque Practico.6th - Edicion-.Roger - Pressman.4huesped100% (3)
- Ingenieria de Software Un Enfoque Practico.6th - Edicion-.Roger - Pressman.2Document220 pagesIngenieria de Software Un Enfoque Practico.6th - Edicion-.Roger - Pressman.2huesped100% (2)
- Ingenieria de Software Un Enfoque Practico.6th - Edicion-.Roger - Pressman.1Document219 pagesIngenieria de Software Un Enfoque Practico.6th - Edicion-.Roger - Pressman.1huesped82% (28)
