8/7/2019 Pruebas de Sw - avanzado
1/38
Mantenimiento Avanzado de Sistemas deInformacin
Pruebas del Software
Dr. Macario Polo UsaolaDepartamento de InformticaPaseo de la Universidad, 413071-Ciudad [email protected]
8/7/2019 Pruebas de Sw - avanzado
2/38
1
ndice1. Introduccin..........................................................................................3
1.01 El proceso de pruebas en el ciclo de vida.....................................3
1.01.1 Pruebas de requisitos ............................................................4 1.01.2 Pruebas del diseo ................................................................5
1.01.3 Revisiones e inspecciones del cdigo fuente.........................6
1.02 Automatizacin de las pruebas .....................................................7
2. Pruebas estructurales o de caja blanca ...............................................8
2.01 Criterios de cobertura....................................................................8
2.01.1 Cobertura de sentencias ........................................................8
2.01.2 Cobertura de decisiones ........................................................9 2.01.3 Cobertura de condiciones ......................................................9
2.01.4 Cobertura de condiciones mltiples .......................................9
2.01.5 Cobertura de condiciones/decisiones ....................................9
2.01.6 Cobertura de caminos............................................................9
2.01.7 Cobertura de funciones..........................................................9
2.01.8 Cobertura de llamadas...........................................................9
2.01.9 Cubrimiento de bucles .........................................................10
2.01.10 Cubrimiento de carrera ........................................................10
2.01.11 Cobertura de operadores relacionales.................................10
2.01.12 Cobertura de tablas..............................................................10
2.02 Mutacin......................................................................................10
2.02.1 Proceso de pruebas basado en mutacin............................11
2.02.2 Operadores de mutacin......................................................12
2.03 Generacin de casos de prueba con algoritmos de minimizacin
14
2.03.1 Bsqueda Tab.................................................................... 14
2.03.2 Algoritmos Genticos (I).......................................................16
2.03.3 Algoritmos Genticos (II)......................................................17
3. Pruebas funcionales o de caja negra .................................................17
3.01 Generacin de casos de prueba .................................................17
3.01.1 Secuencias de mtodos.......................................................17
3.01.2 Especificaciones formales o semiformales ..........................18
8/7/2019 Pruebas de Sw - avanzado
3/38
2
3.01.3 Mtodo ASTOOT .................................................................21
3.01.4 Obtencin automtica de especificaciones algebraicas.......24
3.02 Pruebas a partir de modelos .......................................................25
3.02.1 Diagramas de clases UML ...................................................25
3.02.2 Criterios de cobertura de pruebas para diseos UML..........28
3.02.3 Diagramas de estados ......................................................... 29
3.02.4 En otros diagramas..............................................................29
3.03 Pruebas de componentes ...........................................................31
3.03.1 Uso de BIT wrappers ...........................................................31
3.03.2 Mutacin de interfaces ......................................................... 33
4. Resultados experimentales ................................................................34
5. Referencias ........................................................................................36
8/7/2019 Pruebas de Sw - avanzado
4/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
3
1. INTRODUCCIN La fase de pruebas es una de las ms costosas del ciclo de vida software.
En sentido estricto, deben realizarse pruebas de todos los artefactos generados
durante la construccin de un producto, lo que incluye especificaciones de re-
quisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el cdigo
fuente y el resto de productos que forman parte de la aplicacin (p.ej., la base
de datos). Obviamente, se aplican diferentes tcnicas de prueba a cada tipo de
producto software.
1.01 El proceso de pruebas en el ciclo de vida
El estndar ISO/IEC 12207 (ISO/IEC 1995) identifica tres grupos de proce-sos en el ciclo de vida software:
- Procesos principales, grupo en el que incluye los procesos de Adquisi-
cin, Suministro, Desarrollo, Operacin y Mantenimiento.
- Procesos de la organizacin, en donde se encuentran los procesos de
Gestin, Mejora, Infraestructura y Formacin.
- Procesos de soporte o auxiliares, en donde estn los procesos de Do-
cumentacin, Gestin de la Configuracin, Auditora, Resolucin deProblemas, Revisin Conjunta, Aseguramiento de la Calidad, Verifica-
cin, Validacin,
No define, como vemos, un proceso de Pruebas como tal, sino que aconse-
ja, durante la ejecucin de los procesos principales o de la organizacin, utilizar
los procesos de soporte. Entre stos se encuentran los procesos de Validacin
y de Verificacin:
- El proceso de Validacin tiene como objetivo determinar si los requisi-tos y el sistema final cumplen los objetivos para los que se construy
el producto, respondiendo as a la pregunta el producto es correcto?
- El proceso de Verificacin intenta determinar si los productos software
de una actividad se ajustan a los requisitos o a las condiciones im-
puestas en actividades anteriores. De este modo, la pregunta a la que
responde este proceso es se est construyendo el producto correc-
tamente?
8/7/2019 Pruebas de Sw - avanzado
5/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
4
Del proceso de Verificacin se observa la importancia de verificar cada uno
de los productos que se van construyendo, bajo la asuncin de que si lo que se
va construyendo es todo ello correcto, tambin lo ser el producto final. Igual-
mente, se observa que el proceso de Validacin resalta la importancia de com-probar el cumplimiento de los objetivos de los requisitos y del sistema final, de
suerte que podra construirse un Plan de pruebas de aceptacin desde el mo-
mento mismo de tener los requisitos, que sera comprobado al finalizar el pro-
yecto. Si tras la fase de requisitos viniese una segunda de diseo a alto nivel
del sistema, tambin podra prepararse un Plan de pruebas de integracin, que
sera comprobado tras tener codificados los diferentes mdulos del sistema.
Esta correspondencia entre fases del desarrollo y tipos de pruebas produce elllamado modelo en V, del que se muestra un ejemplo en la Figura 1.
Requisitos
Diseo dealto nivel
Diseo debajo nivel
Cdigo Pruebasunitarias
Pruebas deintegracin
Pruebas desistema
Pruebas deaceptacin
Figura 1. Modelo en V
1.01.1 Pruebas de requisitos
La prueba de requisitos pretende comprobar los tres principales atributos
de calidad de los requisitos, con el fin de detectar tantos errores como sea po-
sible y cuanto antes: correccin (carencia de ambigedad), complecin (especi-
ficacin completa y clara del problema) y consistencia (que no haya requisitos
contradictorios).
8/7/2019 Pruebas de Sw - avanzado
6/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
5
(Bashir and Goel 2000) proponen la utilizacin de una Matriz de Prueba de
Requisitos ( RTM: Requirements Testing Matrix ), en la que se lista cada requisi-
to junto a sus casos de uso y casos de prueba:
Requisito Casos de uso Casos de prueba Id del prototipoen que se incluye
Validado con elusuario?
Tabla 1. Tabla RTM (Matriz de Tabla de Requisitos)
1.01.2 Pruebas del diseo
La fase de diseo tiene como objetivo generar un conjunto de especifica-
ciones completas del sistema que se va a implementar, transformando los re-
quisitos en un Plan de implementacin.
La prueba del diseo debe comprobar su consistencia, complecin, correc-
cin, factibilidad (es decir, que el diseo sea realizable) y trazabilidad (es decir,
que podamos navegar desde un requisito hasta el fragmento del diseo en
que ste se encuentra).
Las actividades que proponen (Bashir and Goel 2000) para este tipo de
pruebas se muestran en la Figura 2.
8/7/2019 Pruebas de Sw - avanzado
7/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
6
Particionarrequisitos
Seleccionarsiguiente conjunto
de requisitos
Revisardiagramas
Construirprototipo
Probar cumplimientode requisitos de
recursos
Probar cumplimientode requisitosfuncionales
Probar cumplimientode requisitos de
rendimiento
Figura 2. Actividades para la prueba del diseo
1.01.3 Revisiones e inspecciones del cdigo fuente
Las revisiones e inspecciones de cdigo fuente son una tcnica para la de-
teccin manual de errores en el cdigo (Bashir and Goel 2000). Se trabaja bajo
el principio de que cuatro ojos ven ms que dos, de tal manera que el mtodo
de trabajo consistir, bsicamente, en pasar el cdigo escrito por un programa-
dor a un tercero o grupo de terceros, que tratar de encontrar posibles errores,
faltas de adecuacin al estilo de codificacin utilizado por la organizacin, etc.
Para ello suelen utilizarse listas de comprobacin ( checklists) , que enume-
ran defectos y en los que el revisor anota su presencia o ausencia. En (Fox
1998) puede consultarse una lista de comprobacin de errores tpicos del len-
guaje Java, entre los que se incluyen el control de overflows y underflows, res-
triccin adecuada del acceso a los miembros de las clases, control de apertura
y cierre de ficheros, etc.
8/7/2019 Pruebas de Sw - avanzado
8/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
7
1.02 Automatizacin de las pruebas(Rice 2002) enumera y explica los diez retos ms importantes en la
automatizacin del proceso de pruebas. De acuerdo con este autor, stos son
los siguientes:
- Falta de herramientas, debida fundamentalmente a su elevado precio
o a que las existentes no se ajusten al propsito o entorno para el que
se necesitan. La primera razn parece deberse a la no mucha impor-
tancia que habitualmente se le da a la fase de pruebas, y eso que el
costo de corregir un error puede, en muchos casos, superar al de la li-
cencia de uso. Sera conveniente evaluar el coste de correccin de de-
fectos del software entregado y compararlo con el de la licencia de la
herramienta de pruebas.
- Falta de compatibilidad e interoperabilidad entre herramientas.
- Falta de proceso de gestin de la configuracin. Igual que las diferen-
tes versiones del cdigo fuente, las pruebas, especialmente las de re-
gresin, deben someterse a un control de versiones. Recurdese que
el proceso de Gestin de la Configuracin es uno de los procesos de
soporte del estndar ISO/IEC 12207 (ISO/IEC 1995), que debera utili-
zarse en la ejecucin de los procesos principales, y muy especialmen-
te en los de Desarrollo y Mantenimiento.
- Falta de un proceso bsico de pruebas y de conocimiento de qu es lo
que se debe probar.
- Falta de uso de las herramientas de prueba que ya se poseen, bien
por su dificultad de uso, por falta de tiempo para aprender a manejarla,
por falta de soporte tcnico, obsolescencia, etc.- Formacin inadecuada en el uso de la herramienta.
- La herramienta no cubre todos los tipos de prueba que se desean (co-
rreccin, fiabilidad, seguridad, rendimiento, etc.). Obviamente, a la
hora de elegir la herramienta, deberan tenerse priorizados los tipos de
pruebas, y entonces hacer la eleccin de la herramienta basados en
esto. A veces tambin es necesario utilizar no una, sino varias herra-
8/7/2019 Pruebas de Sw - avanzado
9/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
8
mientas de prueba, as como tener en cuenta que es imposible auto-
matizar el 100% de las pruebas.
- Falta de soporte o comprensin por parte de los jefes, debido otra vez
a la escasa importancia que habitualmente se le da a la fase de prue-bas.
- Organizacin inadecuada del equipo de pruebas.
- Adquisicin de una herramienta inadecuada.
2. PRUEBAS ESTRUCTURALES O DE CAJA BLANCA Las pruebas de caja blanca realizan un seguimiento del cdigo fuente se-
gn va ejecutando los casos de prueba, de manera que se determinan de ma-
nera concreta las instrucciones, bloques, etc. en los que existen errores.
Cuando se pasan casos de prueba al programa que se est probando, es
conveniente conocer qu porcentaje del programa se ha ejecutado, de manera
que estemos prximos a asegurar que todo l es correcto (evidentemente, es
imposible alcanzar una certeza del 100%). Existen varias formas de medir la
cobertura lograda en el programa por los casos de prueba, algunas de las cua-
les se presentan en el siguiente epgrafe.
2.01 Criterios de coberturaDe acuerdo con (Cornett 2002), el anlisis de cobertura del cdigo es el
proceso de:
- Encontrar fragmentos del programa que no son ejecutados por los ca-
sos de prueba.
- Crear casos de prueba adicionales que incrementen la cobertura.
- Determinar un valor cuantitativo de la cobertura (que es, de maneraindirecta, una medida de la calidad del programa).
Adicionalmente, el anlisis de cobertura tambin permite la identificacin de
casos de prueba redundantes, que no incrementan la cobertura.
2.01.1 Cobertura de sentencias
Comprueba el nmero de sentencias ejecutables que se han ejecutado.
8/7/2019 Pruebas de Sw - avanzado
10/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
9
2.01.2 Cobertura de decisiones
Comprueba el nmero de decisiones ejecutadas, considerando que se ha
ejecutado una decisin cuando se han recorrido todas sus posible ramas (la
que la hace true y la que la hace false , pero tambin todas las posibles ramas
de un switch ).
2.01.3 Cobertura de condiciones
Comprueba el nmero de condiciones ejecutadas, entendiendo que se ha
ejecutado una condicin cuando se han ejecutado todas sus posibles ramas.
2.01.4 Cobertura de condiciones mltiples
Comprueba el nmero de condiciones mltiples ejecutadas, considerando
que se ha ejecutado una condicin mltiple cuando se han ejecutado todas sus
correspondientes ramas con todas las posibles variantes de la instruccin con-
dicional.
2.01.5 Cobertura de condiciones/decisiones
Comprueba el nmero de condiciones y decisiones que se han ejecutado.
2.01.6 Cobertura de caminos
Comprueba el nmero de caminos linealmente independientes que se han
ejecutado en el grafo de flujo de la unidad que se est probando. El nmero de
caminos linealmente independientes coincide con la complejidad ciclomtica de
McCabe.
2.01.7 Cobertura de funciones
Comprueba el nmero de funciones y procedimientos que han sido llama-
dos.
2.01.8 Cobertura de llamadas
Comprueba el nmero de llamadas a funciones y procedimientos que se
han ejecutado. No debe confundirse con la cobertura de funciones: en la cober-
tura de funciones contamos cuntas funciones de las que hay en nuestro pro-
8/7/2019 Pruebas de Sw - avanzado
11/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
10
grama han sido llamadas, mientras que la cobertura de llamadas cuenta cun-
tas de las llamadas a funciones que hay en el programa se han ejecutado.
2.01.9 Cubrimiento de bucles
Comprueba el nmero de bucles que han sido ejecutados cero veces (ex-
cepto para bucles do..while ), una vez y ms de una vez.
2.01.10 Cubrimiento de carrera
Comprueba el nmero de tareas o hilos que han ejecutado simultneamen-
te el mismo bloque de cdigo.
2.01.11 Cobertura de operadores relacionalesComprueba si se han ejecutado los valores lmite en los operadores rela-
cionales (>, =,
8/7/2019 Pruebas de Sw - avanzado
12/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
11
tantes consigamos matar, estaremos logrando mayor cobertura del programa
original, lo que de manera indirecta es una medida de la calidad del programa.
2.02.1 Proceso de pruebas basado en mutacin
La Figura 3 muestra el proceso de mutacin propuesto por (Offut 1995).
Las lneas punteadas indican tareas manuales, mientras que las de trazo conti-
nuo son tareas automatizables. Inicialmente se genera el conjunto de mutantes,
el conjunto de casos de prueba y se define un umbral que representa el
porcentaje mnimo de mutantes muertos que debe alcanzarse. Entonces se
ejecutan los casos de prueba sobre el programa original y sobre los mutantes,
y se calcula el porcentaje de mutantes muertos. Si no se ha alcanzado el
umbral previamente definido, se eliminan los casos de prueba que no han
matado mutantes y se generan casos de prueba nuevos, especialmente
dirigidos a matar los mutantes que han permanecido vivos.
Tradicionalmente, se considera que para matar a un mutante deben produ-
cirse tres condiciones:
- Alcance: la sentencia mutada debe ser ejecutada por el caso de prue-
ba.- Necesidad: entre la entrada y la salida del programa debe crearse un
estado intermedio errneo.
- Suficiencia: el estado incorrecto debe propagarse hasta la salida del
programa.
La condicin de suficiencia puede ser difcil de conseguir en muchas oca-
siones, lo que puede dificultar la obtencin de casos de prueba a un coste ra-
zonable. La mutacin dbil se queda en la condicin de necesidad para deter-minar que un caso de prueba ha matado a un mutante: compara el estado in-
termedio del mutante y el del programa original inmediatamente despus de
haber ejecutado la instruccin mutada, marcando el mutante como muerto si
los estados son diferentes. Se ha comprobado experimentalmente que esta
tcnica puede ahorrar hasta el 50% del coste de las pruebas sin degradar ex-
cesivamente su calidad.
8/7/2019 Pruebas de Sw - avanzado
13/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
12
Progamaoriginal P
Crearmutantes M
Crear casosde prueba T
Se alcanzel umbral ? Corregir P
Ejecutar T sobreP
P(T) escorrecta?
Fin
Eliminar loscasos de prueba
ineficientes
No
S
S
No
Ejecutar T sobrecada mutante
vivoDefinir umbral
Figura 3. Proceso de mutacin propuesto por (Offut 1995)
2.02.2 Operadores de mutacin
La generacin de mutantes se consigue aplicando operadores de mutacin
al cdigo fuente del programa que queremos probar. La Tabla 2 muestra algu-
nos de los operadores de mutacin citados en (Offut, Rothermel et al. 1996).
Operador Descripcin
ABS Sustituir una variable por el valor absoluto de dicha variableACR Sustituir una referencia variable a un array por una constanteAOR Sustitucin de un operador aritmticoCRP Sustitucin del valor de una constanteROR Sustitucin de un operador relacionalRSR Sustitucin de la instruccin ReturnSDL Eliminacin de una sentenciaUOI Insercin de operador unario (p.ej.: en lugar de x , poner x )
Tabla 2. Algunos operadores de mutacin clsicos
El nmero de mutantes que puede generarse a partir de un programa sen-
cillo, de pocas lneas de cdigo, es muy grande (pinsese que el operador
8/7/2019 Pruebas de Sw - avanzado
14/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
13
AOR , por ejemplo, puede aplicarse a cada aparicin de un operador aritmtico
en el programa original), resultando tambin muy costosas tanto la ejecucin
de los casos de prueba con cada mutante como la comprobacin de la salida
del programa. Por ello, se han realizado algunos estudios encaminados a dis-minuir los costes de este tipo de pruebas, evidencindose que, aplicando pocos
operadores, se pueden conseguirse los mismos resultados que si se aplicaran
muchos. Los operadores ms efectivos son el ABS, 0 (sustitucin de una varia-
ble por el valor 0) , 0
(sustitucin de una variable por un valor mayor que 0), AOR, ROR y UOI.
Adems, tambin se han propuesto operadores especficos para programas
escritos en lenguajes orientados a objeto, algunos de los cuales se muestran
en la Tabla 3 (Kim, Clark et al. 2000).
Operador DescripcinAMC (Access ModifierChange)
Reemplazo del modificador de acceso (por ejemplo: ponemos private en lugar de public )
AOC (Argument OrderChange)
Cambio del orden de los argumentos pasados en la llamada a un m-todo (p.ej.: en lugar de Persona p=new Persona(Paco, Pil) ponerPersona p=new Persona(Pil, Paco)
CRT (Compatible Ref-erence Type Replace-ment)
Sustituir una referencia a una instancia de una clase por una referen-cia a una instancia de una clase compatible (p.ej.: en vez de ponerPersona p=new Empleado() , poner Persona p=new Estudiante() ).
EHC (Exception Han-dling Change)
Cambiar una instruccin de manejo de excepciones (try...catch) por unsentencia que propague la excepcin (throw), y viceversa
EHR (ExceptionHandgling Removal)
Eliminacin de una instruccin de manejo de excepciones
HFA (Hiding Field vari-able Addition)
Aadir en la subclase una variable con el mismo nombre que unavariable de su superclase
MIR (Method Invoca-tion Replacement)
Reemplazar una llamada a un mtodo por una llamada a otra versindel mismo mtodo
OMR (OverridingMethod Removal)
Eliminar en la subclase la redefinicin de un mtodo definido en unasuperclase
POC (Parameter OrderChange)
Cambiar el orden de los parmetros en la declaracin de un mtodo(p.ej.: poner Persona(String apellidos, String nombre) en vez de Per- sona(String nombre, String apellidos)
SMC (Static ModifierChange)
Aadir o eliminar el modificador static
Tabla 3. Algunos operadores de mutacin para orientacin a objetos
Los operadores de mutacin deben ser aplicados segn el contexto del lu-
gar del cdigo fuente en el que se vaya a realizar la mutacin. Si esto no se
hiciera as, podran generarse multitud de mutantes funcionalmente equivalen-
tes al programa original, otros que ni siquiera compilaran, etc.
8/7/2019 Pruebas de Sw - avanzado
15/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
14
2.03 Generacin de casos de prueba con algoritmos deminimizacin
De entre los criterios de cobertura enumerados en la seccin 2.01, es de
destacar la dificultad de conseguir valores aceptables para la cobertura de de-
cisiones, condiciones y condiciones/decisiones. Pinsese, por ejemplo, en la
dificultad de encontrar valores que satisfagan una condicin tan simple como if
(a
8/7/2019 Pruebas de Sw - avanzado
16/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
15
Generar una solucin aleatoria como solucin actual
Calcular coste de la solucin actual y almacenarlo como mejor coste
Aadir la solucin actual como nueva solucin
Aadir la nueva solucin a la lista tab
do Calcular los vecinos candidatos
Calcular el coste de los candidatos
Almacenar el mejor candidato como nueva solucin
Aadir la nueva solucin a la lista tab
if coste de nueva solucin < mejor coste Almacenar nueva solucin como mejor solucin
Almacenar coste de la nueva solucin como mejor coste
end_if Almacenar nueva solucin como solucin actual
while no se alcance el criterio de parada
Figura 4. Algoritmo de bsqueda tab
Puesto que el objetivo de estos autores es alcanzar la mayor cobertura po-
sible, utilizan un grafo que representa el flujo de control del programa, en cuyos
nodos se anota si el propio nodo ha sido alcanzado, cuntas veces lo ha sido y
cul es el mejor caso de prueba que lo ha alcanzado. Cuando no hay ramasinalcanzables, el mximo valor posible para la cobertura es el 100%, mientras
que ser desconocido en caso de que las haya. Por este motivo establecen
como criterio de parada o haber alcanzado todas las ramas, o que el algoritmo
haya superado un nmero de iteraciones prefijado. Adems, cada solucin se
caracteriza por su conjunto de valores de entrada. El coste de una solucin,
fundamental para que el algoritmo funcione eficazmente, se calcula conside-
rando que el mejor caso de prueba es aquel que tiene ms posibilidades de
que sus vecinos permuten entre ramas o, lo que es lo mismo, aquel que alcan-
za el nodo con valores lmite. Por ejemplo, si la condicin es x!=y , la funcin de
coste ser |x-y| (vase la referencia para conocer el resto de detalles de clculo
de la funcin de coste).
Para calcular los vecinos candidatos, los autores se basan en que, si un
caso de prueba cubre al padre de un nodo pero no a su hijo, entonces puede
encontrarse un vecino que alcance al hijo utilizando el caso que cubre al padre
8/7/2019 Pruebas de Sw - avanzado
17/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
16
a partir de la mejor solucin. A partir de sta generan 2n vecinos cercanos y
2n vecinos lejanos (donde n es el nmero de variables de entrada del pro-
grama). Los candidatos se comprueban frente a la lista tab, rechazndose
aquellos que ya existen. En la siguiente iteracin se repite el proceso, con ladiferencia de que el nodo objetivo puede haber cambiado si alguno de los can-
didatos alcanz el entonces nodo objetivo.
2.03.2 Algoritmos Genticos (I)
(Pargas, Harrold et al. 1999) utilizan el algoritmo mostrado en la Figura 5
para lograr criterios de cobertura altos.
En la primera lnea se calcula CDGPaths , que representa el grafo de de-pendencias de control del programa que se va a probar. Un grafo de depen-
dencia de control es un grafo dirigido acclico cuyos nodos representan senten-
cias y cuyos arcos representan dependencias de control entre sentencias. Un
nodo Y depende por control de otro X si y slo si: (1) cualquier nodo intermedio
en el camino de X a Y est postdominado por Y ; y (2) X no est postdominado
por Y. Se dice adems que un nodo X est postdominado por otro Y si para
llegar desde X a la salida es preciso pasar siempre por Y. A continuacin se inicializa Scoreboard , que guarda el registro de los requi-
sitos de prueba (TestReq ) satisfechos. Scoreboard puede ser un vector de bits
si se desea lograr cobertura de sentencias, un vector de enteros si deseamos
conocer la frecuencia de ejecucin de cada sentencia o, en general, una
estructura de datos adecuada al criterio de obertura considerado.
El siguiente paso es la generacin de la poblacin inicial (conjunto inicial de
los valores de entrada). A continuacin (bucle de las lneas 4 a 14), comienza
el proceso de generacin de los casos de prueba, bastante legible sin mayor
explicacin. Como excepcin, hay que resaltar que el clculo del fitness se
hace en funcin del nmero de nodos de CDGPaths alcanzados por el caso de
prueba teniendo en cuenta el requisito de prueba actual (variable r en el algo-
ritmo).
8/7/2019 Pruebas de Sw - avanzado
18/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
17
1. Crear CDGPaths
2. Crear e inicializar Scoreboard
3. Generar CurPopulation
4. while haya requisitos de prueba no marcados and se est en tiempo5. seleccionar un requisito de prueba r del conjunto TestReq
6. while r no est marcado and no se supere el mximo de intentos7. calcular el fitness de de CurPopulation usando CDGPaths
8. ordenar CurPopulation segn su fitness
9. seleccionar los padres para crear la NewPopulation
10. generar NewPopulation
11. ejecutar el programa con cada elemento de NewPopulation
12. actualizar Scoreboard y marcar aquellos requisitos que se hayan satisfecho
13. endwhile 14. endwhile 15. final = conjunto de casos de prueba que satisfacen TestReq
16. devolver (TestReq, final)
Figura 5. Algoritmo de generacin de casos de prueba de (Pargas, Harrold et al.1999)
2.03.3 Algoritmos Genticos (II)
El trabajo de (Michael, McGaw et al. 2001) es sustancialmente bastante pa-recido al presentado en la seccin anterior, lo que no es de extraar al estar
ambos apoyados en algoritmos genticos: utilizan una poblacin inicial, un con-
junto de requisitos de prueba (cobertura de decisiones/condiciones, en este
caso), una funcin de fitness , un mtodo de cruce de individuos, etc. En este
trabajo, sin embargo, no utilizan grafo de dependencias de control, por lo que el
valor del fitness se calcula de una manera ms parecida al trabajo antes men-
cionado de la Bsqueda Tab (Daz, Tuya et al. 2003).
3. PRUEBAS FUNCIONALES O DE CAJA NEGRA 3.01 Generacin de casos de prueba
3.01.1 Secuencias de mtodos
En el contexto de las pruebas de sistemas orientados a objetos, (Kirani and
Tsai 1994) consideran la secuencia como un concepto fundamental para la
prueba de clases. Una secuencia representa el orden correcto en el que los
8/7/2019 Pruebas de Sw - avanzado
19/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
18
mtodos pblicos de una clase pueden ser invocados. De acuerdo con estos
autores, una de las aplicaciones de las secuencias es la prueba de clases a
partir de su especificacin como una mquina de estados.
As, puede utilizarse la especificacin del comportamiento de una cierta
clase en forma de mquina de estados para generar casos de prueba, ejecutar-
los y medir nuevos criterios de cobertura. En el ejemplo de la Figura 6, se con-
seguira una cobertura completa de estados con la secuencia m1.m2.m3.m4 ,
mientras que deberan ejecutarse otras secuencias para lograr cobertura de
transiciones o cobertura de caminos. A partir de aqu surgen con facilidad otros
criterios de cobertura, como la ejecucin de cada camino cero veces, una vez y
ms de una vez, cobertura de guardas, de acciones, etc.
s0
s4
s3
s2s1m1
m4
m3
m2
m3
m3m4
m4
Figura 6. Mquina de estados para una cierta clase
3.01.2 Especificaciones formales o semiformales
Lo ms interesante del trabajo de (Tse and Xu 1996) es, por un lado, la ex-
plicacin que ofrecen acerca de la especificacin formal de una clase y, por
otro, la utilizacin de esta especificacin para obtener el espacio de estados de
la clase y generar casos de prueba.
De manera general, una clase puede especificarse utilizando combinada-
mente dos formas de representacin: una capa funcional , en la que se repre-
sentan los valores abstractos de los objetos de la clase, y una capa de objeto ,
en la que se anotan la clase y sus operaciones con precondiciones, postcondi-
ciones e invariantes.
8/7/2019 Pruebas de Sw - avanzado
20/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
19
La Figura 7 muestra las dos capas de una clase Account , que podra repre-
sentar una cuenta bancaria, con un determinado lenguaje de especificacin
(aunque lo cierto es que existen muchos ms para representar lo mismo, como
se ver ms adelante en, por ejemplo, la Figura 9).Capa funcional de una clase
module ACCOUNT isincluding MONEY .sort AccountSort .
var X : AccountSort .var M : Money .var N : Money .
let creditLimit = 1000 .
op empty : -> AccountSort .op creditS : AccountSort Money -> AccountSort .
op balance : AccountSort -> Money .eq balance(empty) = 0 .eq balance(creditS(X, M)) = M + balance(X) .
op charge : AccountSort Money -> Money .eq charge(empty, N) = 0 .ceq charge(creditS(X, M), N) = N * 0.05
if N < 200 and balance(creditS(X, M)) < 0 .ceq charge(creditS(X, M), N) = 10
if N >= 200 and balance(creditS(X, M)) < 0 .
ceq charge(creditS(X, M), N) = 0if balance(creditS(X, M)) >= 0 .
op debitS : AccountSort Money -> AccountSort .eq debitS(empty, N) = creditS(empty, - N) .eq debitS(creditS(X, M), N) =
creditS(X, (M - N - charge(creditS(X, M), N))) .endmodule
Capa de objeto de la misma claseclass Account is
based on sort AccountSort .
invariant {balance(self) >= - creditLimit} .
constructor Account()ensure {balance(result) == balance(empty)} .
method credit(M : Money)require {M > 0} .
ensure {balance(post-self) ==balance(creditS(pre-self, M))} .
method debit(M : Money)require {M > 0 and balance(debitS(pre-self, M)) >= -
creditLimit} .ensure {balance(post-self) ==
balance(debitS(pre-self, M))} .
method findBalance() : Moneyensure {result == balance(pre-self)
and balance(post-self) == balance(pre-self)} .endclass
Figura 7. Capas funcional y de objeto de una clase. Figura tomada de (Tse and Xu1996)
La capa funcional incluye la descripcin de los tipos importados ( including
MONEY) , el nombre del tipo ( sort AccountSort ), las posibles variables que se
utilicen a continuacin ( var X, M, N) y un conjunto de clusulas que especifican
los resultados de las operaciones:
- op representa la signatura de la operacin. Por ejemplo: op charge :
AccountSort Money -> Money indica que la operacin charge toma un
parmetro de tipo AccountSort y otro de tipo Money y que devuelve un
Money .
8/7/2019 Pruebas de Sw - avanzado
21/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
20
- eq representa propiedades de las operaciones descritas mediante
ecuaciones. Por ejemplo, eq balance(empty) = 0 indica que el resulta-
do de ejecutar la operacin balance (en ingls, saldo) sobre una
cuenta creada con la operacin empty (en ingls, vaca), es cero; eq debitS(empty, N) = creditS(empty, - N) indica que sacar N euros de
una cuenta vaca (cuyo saldo es cero) es lo mismo que sacar los mis-
mos N euros a crdito.
- ceq representa propiedades de las operaciones descritas mediante
ecuaciones condicionales. Por ejemplo, ceq charge(creditS(X, M), N) =
N * 0.05 if N < 200 and balance(creditS(X, M)) < 0 indica que sacar
N euros de una cuenta X de la que se han sacado a crdito M eurossupone el cobro de un 5% de comisin sobre el importe sacado, si s-
te es menor que 200 euros y el saldo de la cuenta es negativo.
En la capa de objeto del caso de la figura incluye, por ejemplo, una inva-
riante que indica que el saldo de la cuenta debe ser superar siempre al crdito
concedido ( invariant {balance(self) >= - creditLimit} ); una postcondicin sobre el
constructor Account que denota que el saldo de una cuenta recin creada es
cero ( constructor Account() ensure {balance(result) == balance(empty)} ), y unaprecondicin para la operacin credit(M : Money) que expresa que el importe
que se saca a crdito debe ser positivo ( require { M>0 }).
A partir de estas consideraciones, los autores realizan una particin del es-
pacio de estados de la clase, obteniendo estados abstractos por cada trmino
booleano de la capa funcional. A partir, por ejemplo, de la propiedad eq balan-
ce(empty)=0 podran obtenerse los estados en que la cuenta tiene saldo nega-
tivo, saldo cero y saldo positivo. Combinando adems estos estados con la in-
variante de la capa de objeto ( invariant {balance(self) >= - creditLimit} ), se po-
dran obtener los siguientes cinco subestados:
- balance(self) < -creditLimit inalcanzable debido a la invariante
- balance(self) = -creditLimit
- 0> balance(self) > -creditLimit
- balance(self) = 0
- balance(self) > 0
8/7/2019 Pruebas de Sw - avanzado
22/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
21
Puesto que el valor de creditLimit es 1000, los estados concretos son los
siguientes (ntese la adicin de un estado inicial adicional, en el que el objeto
se encuentra antes de ser creado; igualmente podran crearse estados finales
si la clase tuviera destructores):S 0 = { no creado }; S 1= { b==1000 }; S 2 = { -1000
8/7/2019 Pruebas de Sw - avanzado
23/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
22
- La semntica incluye una lista de axiomas que describen la relacin
entre funciones, utilizndose en muchos casos axiomas de reescritura
para esta descripcin. As, dos secuencias de operaciones S 1 y S 2 son
equivalentes si se pueden usar los axiomas como reglas de reescriturapara transformar S 1 en S 2 .
La siguiente figura, tomada de (Doong and Frankl 1994), muestra la especi-
ficacin algebraica de una cola de prioridad. De acuerdo con esta figura, la se-
cuencia create.add(5).delete(3) es equivalente a la secuencia create.add(5) ,
pues puede aplicarse dos veces el sexto axioma.
Figura 9. Especificacin algebraica de una cola de prioridad, tomada de (Doong andFrankl 1994)
Para estos autores, dos objetos O 1 y O 2 de clase C son observacionalmen-
te equivalentes si y slo si:
8/7/2019 Pruebas de Sw - avanzado
24/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
23
(1) C es una clase primitiva (entero, real...), O 1 y O 2 tienen valo-
res idnticos.
(2) C no es una clase primitiva y, para cualquier secuencia S de
operaciones de C que devuelven un objeto de clase C , O 1.S es observacionalmente equivalente a O 2 .S como objeto de
clase C.
En otras palabras, cuando es imposible distinguir O 1 de O 2 usando las ope-
raciones de C. Si se dispusiera de una cantidad de tiempo infinita para com-
probar si dos objetos son observacionalmente equivalentes, podra utilizarse el
siguiente procedimiento para comprobar la correccin de la clase C :
- Sea U el conjunto de tuplas (S 1, S 2 , etiqueta) , donde S 1 y S 2 sonsecuencias de mensajes, y etiqueta es un texto que vale equivalente
o no equivalente.
- Para cada tupla de U , enviar las secuencias S 1 y S 2 a O 1 y O 2 y com-
probar si ambos objetos son observacionalmente equivalentes.
- Si todas las equivalencias observacionales se comprueban de acuerdo
con las etiquetas, entonces la implementacin de C es correcta, e in-
correcta en caso contrario.La equivalencia observacional de dos objetos puede resolverse con un
mtodo tipo equals; sin embargo, la finitud del tiempo para realizar las prue-
bas es irresoluble, por lo que sus autores la han adaptado en la familia de
herramientas ASTOOT. El componente de generacin de casos de prueba to-
ma la descripcin sintctica y semntica de la clase que se va a probar (Figura
9) y la traduce a una representacin arborescente. Con esta representacin,
lee una secuencia de operaciones suministrada por el usuario y le aplica una
serie de transformaciones para obtener secuencias de operaciones equivalen-
tes. Las operaciones incluidas en las secuencias son simblicas, en el sentido
de que carecen de parmetros reales. Por ltimo, y teniendo en cuenta la
asuncin explicada ms arriba, la comprobacin de la correccin de la clase la
realizan pasando valores reales a los parmetros de los mensajes contenidos
en las secuencias de cada tupla.
8/7/2019 Pruebas de Sw - avanzado
25/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
24
3.01.4 Obtencin automtica de especificaciones algebraicas
(Henkel and Diwan 2003) han desarrollado una herramienta que obtiene de
manera automtica especificaciones algebraicas a partir de clases Java. Co-
mienzan obteniendo una lista de secuencias vlidas mediante llamadas sucesi-
vas a los constructores de la clase y a algunos de sus mtodos, pasando valo-
res adecuados a los parmetros de estas operaciones. Si alguna de las se-
cuencias lanza una excepcin, se deshace la ltima operacin o se prueba con
un nuevo valor del argumento (Figura 10).
Figura 10. Generacin incremental de trminos aplicada a la clase IntStack (Pila deenteros), tomada de (Henkel and Diwan 2003)
Generadas las secuencias, obtienen ecuaciones de igualdad del estilo de
las mostradas en la Figura 7 y en la Figura 9, pero que incluyen valores reales
en lugar de simblicos:
- Ecuaciones de igualdad de secuencias diferentes, como por ejemplo:
pop(push(IntStack().state, 4).state).state=IntStack().state - Ecuaciones de igualdad de secuencias con constantes, como:
pop(push(IntStack().state, 4).state).retval=4
A partir de las ecuaciones se generan los axiomas, que constan de dos se-
cuencias y una serie de variables cuantificadas. As, de la ecuacin de la iz-
quierda, se obtiene el axioma de la derecha:
IntAdd(size(IntStack().state).retval,1).retval =
size(push(IntStack().state, 3).state).retval
s:IntStack, i:int
IntAdd(size(s).retval,1).retval =
size(push(s, I).state).retval
8/7/2019 Pruebas de Sw - avanzado
26/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
25
Figura 11. Ejemplo de obtencin de un axioma a partir de una ecuacin
Muchos de los axiomas generados son redundantes, por lo que con poste-
rioridad se detectan y se eliminan aplicando reglas de reescritura, para lo que
primero deben identificarse stas de entre el conjunto de axiomas. Se conside-
ra que un axioma es una regla de reescritura si: (1) el lado izquierdo y el dere-
cho tienen diferente longitud; y (2) las variables libres que aparecen en lado
ms corto son un subconjunto de las variables libres que aparecen en el lado
derecho.
3.02 Pruebas a partir de modelos
3.02.1 Diagramas de clases UML(Baudry, Traon et al. 2002) analizan la complejidad de diagramas de clases
UML con respecto a su facilidad de prueba, con el objetivo de proponer una
serie de guas de diseo que permitan disear sistemas orientados a objeto
fciles de probar o, al menos, probables en tiempo finito. El estudio se basa
fundamentalmente en medidas de acoplamiento, que viene a ser el grado en
que unos elementos dependen de otros; as, se asume que a mayor acopla-
miento (tanto directo como indirecto), mayor dificultad para probar el diseo.As, los autores dan las siguientes definiciones:
Relacin de uso directa: la clase A usa la clase B cuando existe una aso-ciacin desde A hacia B , o bien cuando hay una dependencia con el estereoti-
po desde A hacia B. Este conjunto de relaciones se llama SDU (Set of
Direct Usage relationship). Ntese que una asociacin no dirigida representa
realmente dos relaciones de este conjunto.
Relacin de uso transitiva: es el conjunto formado por la clausura transiti-va de SDU.
Relacin de uso transitiva real: si existe una relacin transitiva entre lasclases A, B y, adems, el cdigo fuente obtenido del diagrama de clases permi-
te la interaccin entre dos instancias de A y de B, entonces se dice que dicha
relacin transitiva es real.
Interaccin de clases (interaccin potencial): siendo A, B dos clases,ocurre si y slo si A R i B y B R i A, siendo i distinto de j . [La interaccin es poten-
8/7/2019 Pruebas de Sw - avanzado
27/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
26
cial porque tal vez no llegue fsicamente a producirse en la ejecucin del siste-
ma].
Interaccin entre objetos (interaccin real): siendo A, B dos clases, ocu-
rre si y slo si (1) A R i B y B R i A, siendo i distinto de j , y (2) R i y R j son relacio-nes transitivas reales. [La interaccin es real porque se produce la interaccin
entre ambos objetos en la ejecucin del sistema obtenido del diseo].
El criterio de prueba propuesto es el siguiente: para cada interaccin entre clases, o bien se obtiene un caso que prueba la interaccin entre objetos, o
bien se obtiene un informe mostrando que tal interaccin no es factible.
Puesto que la tarea de producir casos de prueba o informes es imposible si
el nmero de interacciones es muy alto, es preciso obtener diseos que dismi-nuyan el nmero de interacciones, de modo que se haga factible as la prueba
completa del diseo de clases.
Antes de someterlo al criterio de pruebas, el diseo de clases debe ser eva-
luado para conocer el nmero de interacciones entre clases, modificndolo si
es muy alto y tal mejora es posible, o rechazndolo directamente en otro caso.
La mejora del diseo puede lograrse reduciendo el acoplamiento o anotndolo
con restricciones que eviten la codificacin de interacciones entre objetos pro-pensas a error. Los autores proponen la anotacin utilizando los estereotipos
(para indicar que la clase A crea instancias de la clase B ),
(para indicar que la clase A slo utiliza mtodos tipo get de B )
y ( para indicar que la clase A modifica el estado de las instancias
de B ). Estos estereotipos se utilizan en el proceso de construccin del Grafo de
Dependencias de Clases (en ingls Class Dependency Graph, o CDG) , que
representa las relaciones transitivas entre clases junto a las relaciones de
herencia e implementacin. La siguiente figura muestra algunos ejemplos sobre
la obtencin del CDG , en la que aparecen algunas etiquetas aadidas a los
nodos del CDG para representar el tipo de relacin existente.
8/7/2019 Pruebas de Sw - avanzado
28/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
27
Figura 12. Algunos ejemplos de obtencin del CDG, tomada de (Baudry, Traon et al.2002)
A partir del CDG pueden calcularse medidas como la complejidad de unainteraccin, definida en funcin de la complejidad de los diferentes caminospor los que puede irse desde un objeto hasta otro:
= >
=nbPaths
i ijji Pd complejidaPd complejidaCI d complejida
1
))()((()(
Ecuacin 1. Complejidad de una interaccin
La complejidad de un camino en una interaccin es necesaria para cal-cular el valor de la Ecuacin 1, y se define como el productorio de la compleji-
dad asociada a cada jerarqua cruzada por la interaccin (parmetro IH):
=
=nbCrossed
i
PIH d complejidaPd complejida1
),()(
Ecuacin 2. Complejidad de un camino en una interaccin
Obviamente, es preciso poder calcular la complejidad de un camino que
pasa por una jerarqua de herencia:
=
=nbDP
iidpd complejidaPIH d complejida
1
)(),(
Ecuacin 3. Complejidad de un camino que pasa por una jerarqua de herencia
Por ltimo, la complejidad de un camino de descendientes es el nmerode interacciones potenciales entre las clases que hay en ese camino. El caso
peor se dara cuando todas las clases estuvieran relacionadas con todas las
clases, lo que supone un valor mximo de n(n-1). De manera general, la com-
8/7/2019 Pruebas de Sw - avanzado
29/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
28
plejidad de un camino se corresponde con la Ecuacin 4, en donde h represen-
ta la altura del camino:
)1()( = hhdpcomlejidad
Ecuacin 4. Complejidad de un camino de descendientes
En la siguiente figura, tomada de (Baudry, Traon et al. 2002), la compleji-
dad del camino que va desde client hasta b1 pasando por la relacin de heren-
cia de la clase d es 1+3*(3-1)+1: 1 por la relacin de uso de client con respecto
a d; 3*(3-1) por el camino de descendientes de la jerarqua d , y otra vez 1 por la
relacin de uso desde d22 a b1.
Ecuacin 5. Ejemplo para el clculo
3.02.2 Criterios de cobertura de pruebas para diseos UML
(Andrews, France et al. 2003) proponen varios criterios de cobertura para
las pruebas de diferentes diagramas UML.
Para diagramas de clases , proponen los siguientes:- AEM (Association-end multiplicity): dado un conjunto de pruebas T y
un modelo SM, T debe causar que se cree cada par de multiplicidades
representativo en las asociaciones de SM. As, si existe una asocia-
cin cuya multiplicidad es, en un extremo, p..n, debera instanciarse la
asociacin con p elementos (valor mnimo), n elementos (valor mxi-
mo) y con uno o ms valores en el intervalo (p+1, n-1).
- GN (Generalization): dado un conjunto de pruebas T y un modelo SM,
T debe conseguir que se cree cada relacin de generalizacin de SM.
- CA (Class attribute): dado un conjunto de pruebas T, un modelo SM y
una clase C, T debe conseguir que se creen conjuntos de valores re-
presentativos de los diferentes atributos de la clase C. El conjunto de
8/7/2019 Pruebas de Sw - avanzado
30/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
29
valores representativos se consigue en tres pasos: (1) crear valores
representativos para cada atributo, para lo que pueden usarse clases
de equivalencia; (2) calcular el producto cartesiano de estos valores;
(3) eliminar los conjuntos de valores invlidos, considerando el domi-nio del problema, posibles restricciones que anoten el diagrama, etc.
Para diagramas de interaccin , los criterios propuestos son:- Cobertura de condiciones : dado un conjunto de casos de prueba T y
un diagrama de interaccin D , T debe conseguir que cada condicin
del diagrama se evale a true y a false.
- Cobertura completa de predicados ( FP : full predicate coverage ): cada
clusula de cada condicin debe evaluarse a true y a false. - Cobertura de mensajes (EML: each message on link): cada mensaje
del diagrama debe ejecutarse al menos una vez.
- Cobertura de caminos ( AMP: all message paths): todos los posibles
caminos de ejecucin deben ejecutarse.
- Cobertura de colecciones ( Coll: Collection coverage): el conjunto de
casos de prueba debe probar cada interaccin con colecciones al me-
nos una vez.
3.02.3 Diagramas de estados
(Burton, Clark et al. 2001; Hong, Lee et al. 2001)
3.02.4 En otros diagramas
(Basanieri, Bertolino et al. 2002) utilizan diagramas de casos de uso y de
secuencia para derivar casos de prueba desde las etapas iniciales del desarro-
llo de un sistema orientado a objetos. Tras realizar una serie de anlisis y adap-taciones de los diagramas, aplican los siguientes pasos:
- Definir el conjunto de secuencias de mensajes MS a partir de los dia-
gramas de secuencia. Cada secuencia comienza con un mensaje m
sin predecesor (habitualmente, un mensaje enviado al sistema por un
actor) y el conjunto de mensajes cuya ejecucin dispara m (aquellos
cuyo inicio est en el foco de control en que termina m ).
8/7/2019 Pruebas de Sw - avanzado
31/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
30
- Analizar de subcasos, que bsicamente consiste en construir varias
secuencias a partir de las posibles instrucciones condicionales que
anotan los diagramas de secuencia.
- Identificar de los conjuntos de valores de prueba, que se construyen apartir de los tipos de los parmetros de los mtodos y del anlisis de
los diagramas de clases del sistema.
- Seleccionar, para cada mensaje de la secuencia, las situaciones rele-
vantes en que el mensaje puede ocurrir y, para cada valor de prueba,
valores vlidos que puedan incluirse en el mensaje.
- Eliminar valores contradictorios o poco significativos, para lo que los
autores sugieren utilizar clases de equivalencia.- Obtener procedimientos de prueba, que puede hacerse automtica-
mente con los datos obtenidos en los pasos anteriores.
As, a partir del diagrama de secuencia mostrado en la Figura 13, se identi-
fican las siguientes secuencias de mensajes:MS_1: 1.start(), 1.1.open()
MS_2: 2.enterUserName(String)
MS_3: 3.enterPassword(String)
MS_4: 4.loginUser(), 4.1.validateuserIDPassword(String, String)
4.2.setupSecurityContext(), 4.2.1.new UserID()
4.3.closeLoginSelection()
8/7/2019 Pruebas de Sw - avanzado
32/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
31
Figura 13. Diagrama de secuencia de ejemplo, tomado de (Basanieri, Bertolino et al.2002)
El diagrama incluye sin embargo una instruccin condicional, por lo que la
secuencia MS_4 puede dividirse en dos:
MS_4.1: 4.loginUser(), 4.1.validateuserIDPassword(String, String)
4.2.setupSecurityContext(), 4.2.1.new UserID()
MS_4.2: 4.loginUser(), 4.1.validateuserIDPassword(String, String)
4.3.closeLoginSelection() 3.03 Pruebas de componentes
3.03.1 Uso de BIT wrappers
(Edwards 2001) propone la utilizacin de BIT wrappers (Built-In-Test wrap-
pers, o adaptadores construidos durante las pruebas) para la prueba de com-
ponentes. Esencialmente, un BIT wrapper es una clase que ofrece la misma
interfaz que el componente para el que se ha construido. En la fase de pruebas
8/7/2019 Pruebas de Sw - avanzado
33/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
32
del componente, se ejecutan las operaciones de ste a travs del BIT wrapper,
que posee funcionalidades como la comprobacin de las precondiciones de la
operacin antes de llamar a la operacin real, y la comprobacin de las post-
condiciones tras su ejecucin. Adems, el BIT wrapper puede mantenerse paraque capture las llamadas que los clientes hacen a las operaciones del compo-
nente (Figura 14).
Figura 14. Ubicacin del BIT wrapper alrededor del componente. Figura tomada de(Edwards 2001)
Algunas caractersticas de los BIT wrappers son las siguientes:
- Son transparentes al componente y a los posibles clientes.
- La adicin o supresin de BIT wrappers slo requiere la modificacin
de las declaraciones en el cdigo de los clientes.
- Se aaden nuevas capacidades de comprobacin de restricciones a
las que ya realiza el propio componente.
- La violacin de las restricciones se detectan en el momento en que
ocurren, de manera que se evita su propagacin a otros componentes.
- Si se posee una especificacin formal del componente, el BIT wrapper
se puede generar automticamente.
8/7/2019 Pruebas de Sw - avanzado
34/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
33
Para la fase de pruebas del componente, (Edwards 2001) propone el pro-
ceso que se muestra esquemticamente en la Figura 15: el conjunto de casos
de prueba contenido en el Test suite (que se ha podido generar automtica-
mente) se pasa a un ejecutor de pruebas (Test driver ), que prueba el compo-nente a travs del BIT wrapper. El resultado es, por un lado, los resultados ob-
tenidos de la ejecucin de cada caso de prueba y, por otro, un informe con los
errores encontrados.
Figura 15. Proceso de pruebas con BIT wappers
Tanto el BIT wrapper como el Test driver pueden generarse automtica-
mente: para el primero es preciso disponer de una descripcin formal del com-
ponente (el autor utiliza el lenguaje Resolve, aunque podra emplearse cual-
quier otro); para la generacin del segundo podran usarse generadores aleato-rios, de valores lmite, etc.
3.03.2 Mutacin de interfaces
(Ghosh and Mathur 2001) proponen aplicar ciertos operadores de mutacin
a las interfaces de componentes para la realizacin de pruebas, as como cier-
tos criterios de cobertura para validar las pruebas realizadas.
Los autores proponen los siguientes operadores de mutacin para CORBA-
IDL son los siguientes:
8/7/2019 Pruebas de Sw - avanzado
35/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
34
- Reemplazar inout por out.
- Reemplazar out por inout.
- Intercambiar parmetros de tipos compatibles.
- Jugar con un parmetro (operador twiddle): por ejemplo, sumarle unosi es entero, aadirle un carcter si es una cadena, etc.
- Poner a cero los valores numricos.
- Sustituir por null.
Los criterios de cobertura que proponen son los siguientes:
- Cobertura de llamadas a mtodos de la interfaz del componente.
- Cobertura de excepciones lanzadas por la interfaz del componente.
- Cobertura de llamadas a mtodos y de excepciones lanzadas.La mutacin se consigue sustituyendo la interfaz por una nueva versin,
como muestra esta figura:
Cliente Interfaz Servidor
Cliente Interfazmutada Servidor
Figura 16. Mutacin de interfaces
4. RESULTADOS EXPERIMENTALES (Juristo, Moreno et al. 2002) han analizado los resultados experimentales
de diferentes tcnicas de prueba extradas de la literatura, de acuerdo con lasiguiente clasificacin:
- Familia de tcnicas aleatorias , en las que los casos de prueba songenerados aleatoriamente, sin seguir ninguna pauta preestablecida.
- Familia de tcnicas funcionales , que utilizan la especificacin delprograma para generar casos de prueba de caja negra.
- Familia de tcnicas de flujo de control , que requieren el conoci-miento del cdigo fuente para seleccionar una serie de caminos a lo
largo del programa, de modo que se ejecute su modelo de control.
8/7/2019 Pruebas de Sw - avanzado
36/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
35
- Familia de tcnicas de flujo de datos , que requieren tambin el co-nocimiento del cdigo fuente para seleccionar secuencias de eventos
relacionados con el estado de los datos.
- Familia de tcnicas de mutacin , que modelan mediante operadoresde mutacin los errores tpicos que se cometen al hacer un programa,
y lo ejecutan mediante casos de prueba que detecten dichos errores.
Los resultados de cada familia los ubican en una de las tres siguientes ca-
tegoras:
(1) Nivel 1: afirmaciones no contrastadas de manera empricamente formal.(2) Nivel 2: afirmaciones contrastadas empricamente pero no con situacio-
nes reales; es decir, con programas no reales o con fallos lo reales.(3) Nivel 3: afirmaciones contrastadas empricamente en situaciones re-
ales.
Respecto de la Familia de tcnicas de flujo de datos , las autoras analizan
dos trabajos que sitan a esta familia en los niveles 2 y 3.
Respecto de la Familia de tcnicas de mutacin, se analizan tres trabajos
que sitan a esta familia en nivel 2.
Igualmente, realizan un estudio comparativo entre las familias de flujo dedatos, flujo de control y aleatoria. Las autoras afirman que, ante restricciones
de tiempo se pueden usar tcnicas aleatorias confiando en que en el 50% de
los casos nos dar una efectividad similar a la de all-uses y all-edges [...]. Si se
necesita un testing exhaustivo, entonces se puede asegurar aplicando all-
uses . No obstante, esta afirmacin la sustentan a nivel 2 y no a nivel 3.
Tambin comparan la familia de mutacin y la de flujo de datos, indicando
que si se busca conseguir cobertura alta y no se dispone de mucho tiempo, es
preferible usar all-uses frente a mutacin, ya que en aproximadamente la mitad
de los casos ser igual de efectiva que la mutacin, sustentando esta afirma-
cin en un nivel 2.
Comparan tambin la familia funcional con la de flujo de control, lo que vie-
ne a significar una comparacin entre pruebas de caja negra y de caja blanca.
Afirman que, si se est trabajando con sujetos con experiencia, en caso de
disponer de tiempo suficiente, es mejor utilizar la tcnica de anlisis de valores
lmite frente a cobertura de sentencias ya que se encontrarn ms fallos, aun-
8/7/2019 Pruebas de Sw - avanzado
37/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
36
que les llevar ms tiempo. Por el contrario, si se est trabajando con sujetos
sin experiencia y no se tiene tiempo, es mejor usar cobertura de sentencias.
Otras conclusiones son que es preferible usar anlisis de valores lmite frente
a cobertura de condicin. Todas estas conclusiones se encuentran a nivel 2.De manera general, las autoras destacan la ubicacin en nivel 2 de la ma-
yora de las tcnicas, lo que indica que hay an mucha investigacin que reali-
zar.
5. REFERENCIAS Andrews, A., R. France, et al. (2003). "Test adequacy criteria for UML design
models." Software Testing, Verification and Reliability(13): 95-127.
Basanieri, F., A. Bertolino, et al. (2002). The Cow_Suite Approach to Planningand Deriving Test Suites in UML Projects. 5th International Conferenceon The Unified Modeling Language, Springer-Verlag. LNCS.
Bashir, I. and A. L. Goel (2000). Testing Object-Oriented Software. Life CycleSolutions. New-York, Springer-Verlag.
Baudry, B., Y. L. Traon, et al. (2002). Testability Analysis of a UML Class Dia-gram. 8th IEEE Symposium on Software Metrics.
Burton, S., J. Clark, et al. (2001). Automatic generation of tests from statechartsspecifications. Formal Approaches to Testing of Software, Aalborg,Denmark, BRICS.
Cornett, S. (2002). Code Coverage Analysis.
Daz, E., J. Tuya, et al. (2003). Pruebas automticas de cobertura de softwaremediante una herramienta basada en Bsqueda Tab. VIII Jornadas deIngeniera del Software y Bases de Datos, Alicante, Spain.
Doong, R. K. and P. G. Frankl (1994). "The ASTOOT approach to testing ob-ject-oriented programs." ACM Transactions on Software Engineering andMethodology 3(2): 101-130.
Edwards, S. H. (2001). "A framework for practical, automated black-box testingof component-based software." Software Testing, Verification and Reli-ability(11): 97-111.
Edwards, S. H. (2001). "A framework for practiucal, automated black-box testingof component-based software." Software Testing, Verification and Reli-ability(11): 97-111.
Fox, C. (1998). Java Code Inspection Checklist.Ghosh, S. and A. P. Mathur (2001). "Interface mutation." Software Testing, Veri-
fication and Reliability(11): 227-247.Henkel, J. and A. Diwan (2003). Discovering Algebraic Specifications from Java
Classes. 17th European Conference on Object-Oriented Programming(ECOOP), Springer.
Hong, H. S., I. Lee, et al. (2001). Automatic test generation from statechartsusing model checking. Formal Approaches to Testing of Software, Aal-borg, Denmark, BRICS.
8/7/2019 Pruebas de Sw - avanzado
38/38
Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software
ISO/IEC (1995). ISO/IEC 12207. International Standard. Software Life CycleProcesses. Geneve, International Standard Organziation/InternationalElectrotechnical Committee.
Juristo, N., A. M. Moreno, et al. (2002). A Survey on Testing Technique Empiri-
cal Studies: How Limited is our Knowledge. International Symposium onEmpirical Software Engineering (ISESE'02), Nara, Japan.Kim, S., J. A. Clark, et al. (2000). Class Mutation: Mutation Testing for Object-
Oriented Programs. International Conference on Object-Oriented andInternet-based Technologies, Concepts, and Applications for a Net-worked World,
Net.ObjectDays'2000, Germany.Kirani, S. and W. T. Tsai (1994). "Method sequence specification and verifica-
tion of classes." Journal of Object-Oriented Programming 7(6): 28-38.Lapierre, S., E. Merlo, et al. (1999). Automatic Unit Test Data Generation Using
Mixed-Integer Linear Programming and Execution Trees. International
Conference on Software Maintenance, Oxford, England.Michael, McGaw, et al. (2001). "Generating Software Test Data by Evolution."IEEE Transactions on Software Engineering 27(12): 1085-1110.
Offut, A. J. (1995). A practical system for mutation testing: help for the commonprogrammer. 12th International Conference on Testing Computer Soft-ware.
Offut, A. J., G. Rothermel, et al. (1996). "An experimental determination of suffi-cient mutant operators." ACM Transactions on Software Engineering andMethodology 5(2): 99-118.
Pargas, R. P., M. J. Harrold, et al. (1999). "Test-Data Generation Using GeneticAlgorithms." Software Testing, Verification and Reliability(9): 263-282.
Rice, R. W. (2002). "Surviving the top 10 challenges of software test automa-tion." CrossTalk: The Journal of Defense Software Engineering(Mayo):26-29.
Tracey, N., J. Clark, et al. (1998). Automated program flaw finding using simu-lated annealing. International Symposium on Software Testing andAnalysis, Clearwater Beach, Florida, USA, ACM/SIGSOFT.
Tse, T. and Z. Xu (1996). Test Case Generation for Class-Level Object-Oriented Testing. 9th International Software Quality Week, San Fran-cisco, CA.
Top Related