Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
ios
'O 10IC 0100 10101
lOOlC 010101010 '
10010J 11011101
10K 01 101.01 C
1 01C
lO O li
U01U0
n icot
Ra-Ma
INDICE
AUTORES...........................................................................................................................11
PREFACIO..........................................................................................................................13
PRLOGO..........................................................................................................................15
CAPTULO 1. CONCEPTOS FUNDAMENTALES...................................................... 19
1.1 IMPOSIBILIDAD DE LAS PRUEBAS EXHAUSTIVAS........................................ 19
1.2 ERROR, DEFECTO O FALTA Y FALLO................................................................20
1.3 CASO DE PRUEBA.................................................................................................. 21
1.4 OBJETIVO DE LAS PRUEBAS............................................................................... 21
CAPTULO 2. NIVELES DE PRUEBA...........................................................................23
2.1 PRUEBAS DE CAJA NEGRA.................................................................................. 23
2.2 PRUEBAS ESTRUCTURALES O DE CAJA BLANCA..........................................25
2.3 PRUEBAS UNITARIAS........................................................................................... 27
2.4 PRUEBAS DE INTEGRACIN............................................................................... 27
2.5 PRUEBAS DE SISTEMA......................................................................................... 28
2.6 EJERCICIOS............................................................................................................. 28
CAPTULO 3. CRITERIOS DE COBERTURA PARA ARTEFACTOS
SOFTWARE........................................................................................................................ 31
3.1 CRITERIOS DE COBERTURA.................................................................................31
3.2 UTILIDAD DE LOS CRITERIOS DE COBERTURA..............................................32
3.3 UN POSIBLE MODELO DE TRABAJO...................................................................32
3.4 CRITERIOS DE COBERTURA PARA CDIGO FUENTE.....................................34
3.4.1 Cobertura de sentencias...................................................................................... 34
3.4.2 Cobertura de decisiones, de ramas o de todos los arcos.....................................36
8 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
Dios mo, Dios mo: todo lo hiciste perfecto, pero conmigo te pasaste.
Contenidos
Este libro presenta una serie de tcnicas y buenas prcticas para la prueba
de software: tras el repaso de algunos conceptos importantes (captulos uno y dos),
se describen, en el captulo tres, algunos criterios de cobertura para diferentes tipos
de artefactos software. Si bien los criterios de cobertura no son la panacea con la
que asegurar la ausencia de errores, s que permiten estimar cuantitativamente, por
ejemplo, en qu grado se ha probado un programa.
Puesto que los criterios de cobertura tambin sirven al tester para proponer
nuevos casos de prueba del sistema, el captulo cuatro describe algunas tcnicas
para la propuesta de buenos valores de prueba que permitan incrementar la
cobertura que se alcance en el sistema. Una vez se han identificado esos valores
interesantes, el tester los combina para obtener buenos casos de prueba, a lo que
se dedica el captulo cinco.
Los captulos seis y siete constituyen la segunda parte del libro, dedicada a
las pruebas basadas en mutacin: el primero de ellos detalla la tcnica en
profundidad, presentando su terminologa, sus problemas de coste, las soluciones
que se han propuesto para reducirlos y para hacerla aplicable a nivel industrial y un
anlisis extenso de algunas herramientas. En el captulo sptimo se presenta la
herramienta Bacterio, que facilita el testing basado en mutacin.
Pero parece que algo est cambiando; si durante las dcadas de los setenta,
ochenta y noventa se conseguan pocos avances en las pruebas -el clsico libro de
G. J. Myers The art o f software testing segua (y en muchos aspectos todava sigue)
siendo el libro que explicaba casi todo lo que haba que saber para probar
software-, a partir de principios del siglo XXI, se sientan las bases para una nueva
era del testing.
CONCEPTOS FUNDAMENTALES
La prueba puede revelar fallos, pero son los defectos los que pueden y
deben ser detectados por el tester y eliminados por el desarrollador3. No obstante, a
lo largo de este libro utilizaremos indistintamente cualesquiera de estos trminos.
1 Myers, G.J., 2004, The art o f software testing, 2nd edition, John Wiley & Sons.
2 Pfleeger, S., 2001, Software engineering, 2nd edition, Prentice Hall.
3 Bourque, P. y Dupuis, R., 2004, Guide to the software engineering body o f knowledge, SWEBOK,
IEEE Computer Society, disponible en (18 de octubre de 2010) www.swebok.org.
RA-MA CAPTULO 1. CONCEPTOS FUNDAMENTALES 21
Los datos de prueba (test data) son los datos que existen (por ejemplo, en
una base de datos) antes de que una prueba sea ejecutada, que se le suministran al
sistema como entrada a travs de los casos de prueba y que afectan al
funcionamiento del sistema bajo prueba5.
4 IEEE, 1990, IEEE standard glossary of software engineering terminology. Institute of Electrical
and Electronics Engineers.
5 International Software Testing Qualifications Board, Certified Tester Foundation Level Syllabus,
2005.
6 Beizer, B., 1990, Software testing techniques, 2nd edition. Van Nostrand Reinhold Co.
22 TECNICAS COMBINATORIAS Y DE MUTACION PARA TESTING DE SISTEMAS... RA-MA
Por tanto, la actitud del tester debe ser destructiva respecto al sistema que
est probando: debe querer que falle, debe esperar que falle y debe concentrarse en
encontrar casos de prueba que muestren sus fallos7.
7 Kaner, C., Falk, J. y Nguyen, H., 1999, Testing computer software, 2nd edition, Wiley.
Captulo 2
NIVELES DE PRUEBA
Myers, G.J., 1979, The art o f software testing, John Wiley & Sons.
24 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
tringulo segn las longitudes de los lados. Esta operacin devuelve un entero que
representa si el tringulo es equiltero, issceles, escaleno o si no es un tringulo
(porque tenga lados de longitud cero o negativa o porque la suma de dos lados sea
menor o igual a la suma del tercero). En la Figura 2.1 se muestra la estructura de la
clase tringulo, que consta de un constructor, tres operaciones set, que asignan
una longitud a cada uno de los lados del tringulo, y un mtodo getTipo, que
devuelve un entero que representa el tipo del tringulo.
Tringulo Tringulo
Tringulo() TringuloQ
( 2 ,2 ,2 ) setl(int x) ----------EQ (2,2,3) ---------* setl(int x) IS
setJ(int y) setJ(int y)
setK(int z) setK(int z)
getTipo():int getTipo():int
Tringulo Tringulo
Tringulo() Tringulo()
(2,3,4) setl(intx) ES (2,2,4) setl(int x) NT
setJ(int y) setJ(int y)
setK(int z) setK(int z)
getTipo():int getTipo():int
Las pruebas de caja negra pueden aplicarse no solo a una clase o pequeo
programa, sino que son aplicables tambin a un subsistema o, incluso, al sistema
completo mediante pruebas funcionales o testing exploratorio:
9 Bach, J., 2001, What is exploratory testing? And how it differs from scripted testing, disponible en
(18 de octubre de 2010): www.satisfice.com/articles/what_is_et.shtml.
26 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
y observar, para cada tema de entradas, el recorrido seguido por los casos de
prueba en la implementacin de la clase (Figura 2.2).
Figura 2.2. El problema del tringulo, desde un punto de vista de la caja blanca
10 Cornett, S., 2002, Code coverage analysis, disponible en (18 de octubre de 2010):
www. bullseye. com/coverage. html.
RA-MA CAPTULO 2. NIVELES DE PRUEBA 27
2.6 EJERCICIOS
1. Uno de los requisitos fundamentales de los casos de prueba es la
posibilidad de que sean reejecutados tantas veces como se necesite.
Cuando el sistema utiliza una base de datos, esto puede suponer algunos
problemas, ya que los casos de prueba pueden alterar el estado de la base
de datos y dificultar la replicacin de las pruebas. Qu soluciones tiene
para ello?
13 Gallagher, L., Offutt, J. y Cincotta, A., 2006), Integration testing of object-oriented components
using finite state machines. Software Testing, Verification and Reliability, 16.
RA-MA CAPTULO 2. NIVELES DE PRUEBA 29
Adems, alcanzar una cobertura alta en un sistema con un test suite que no
encuentra errores permite disponer de una garanta ms o menos alta acerca de la
calidad de dicho sistema .
Esta afirmacin es solo relativamente cierta, pues depende del criterio o criterios que se utilicen para
medir la cobertura.
RA-MA CAPTULO 3. CRITERIOS DE COBERTURA PARA ARTEFACTOS SOFTWARE 33
Seleccionar S (SUT)
Determinar umbral de
cobertura para S
________ ________
Construir un conjunto de
casos TC para probar S
Buscar errores en S
mediante TC C
han sido alcanzadas. As, si establecemos como valor umbral el recorrer el 100%
de las sentencias del programa, el tester, de acuerdo con el proceso propuesto en la
Figura 3.2, debera aadir nuevos casos de prueba al test suite.
Figura 3.2. Cdigo recorrido (izquierda) por los casos de prueba de la derecha
36 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
if (i == k) {
trityp = trityp + 2;
if (j == k) {
trityp = trityp + 3;
}
if (i <= 0 || j <= 0 || k <= 0) { ***
trityp = 4;
return;
if (trityp == 0) {
if (i + j <= k || j + k <= i || i + k <= j) {
trityp = 4;
return;
} else {
trityp = 1;
return;
A and (B o r C )
Condiciones Decisin
A B C A and (B or C)
true true false true
false false false false
Tabla 3.1. Se verifica el criterio de decisiones, pero no el de condiciones
38 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
A xor B
Condiciones Decisin
A B A xor B
true true false
false false false
Tabla 3.2. Se verifica el criterio de condiciones, pero no el de decisiones
A xor B
Condiciones Decisin
A B A xor B
true true false
true false true
false true true
Tabla 3.3. Se verifican condiciones, decisiones y condiciones/decisiones
Para la misma decisin de la Tabla 3.1 se necesitaran los 23=8 casos que
se muestran en la Tabla 3.4. Este criterio de cobertura es, sin duda, el ms
completo, pero requiere un nmero de casos muy grande para cubrir cada decisin.
A and (B orC)
Condiciones Decisin
A B C A and (B or C)
truc true true true
truc true false true
true false true true
true false false false
false true true false
false true false false
false false true false
false false false false
Tabla 3.4. Cobertura de condiciones
Los casos se resumen en la Tabla 3.5: obsrvese que la decisin toma los
valores true y false gracias a los valores true y false que van tomando las
condiciones que, en la tabla, hemos denominado dominantes.
A and (B or C)
Condiciones Decisin
Condicin
A B C A and (B or C)
dominante
tme tme false tme A, B
false tme true false A
false false tme false B
tme false true tme C
false true false false C
Tabla 3.5. Casos de prueba para conseguir cobertura modificada de condicin/decisin
40 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS...______ RA-MA
Los casos se resumen en la Tabla 3.5: obsrvese que la decisin toma los
valores true y false gracias a los valores true y false que van tomando las
condiciones que, en la tabla, hemos denominado dominantes.
A and (B or C)
Condiciones Decisin
Condicin
A B C A and (B or C)
dominante
truc truc false true A, B
false truc true false A
false false true false B
truc false true true C
false true false false C
Tabla 3.5. Casos de prueba para conseguir cobertura modificada de condicin/decisin
RA-MA CAPITULO 3. CRITERIOS DE COBERTURA PARA ARTEFACTOS SOFTWARE 41
2. Hay que tomar las ramas true y fa lse gracias a B, para lo que
construimos el caso (false, true).
A xor B
Condiciones Decisin
A B A xor B
Tabla 3.6. Casos de prueba para conseguir cobertura modificada de condicin/decisin en A xor B
1. Para irnos a la rama true gracias a A, A debe valer true y B debe valer
false, con lo que tenemos el caso (true, false).
2. Para irnos a la rama fa lse gracias a A, A debe valer fa lse y B false, con
lo que el caso es (false, false), o bien A=true y B=true, siendo el caso
(true, true), pudindonos quedar con cualquiera de los dos. Por obtener
el mismo resultado que en la Tabla 3.6, nos quedamos con el primero.
Para la mquina de la Figura 3.4, un test suite que satisface este criterio
necesitara al menos dos casos de prueba, como por ejemplo: (mi, m2, m3, m3, m4,
m4, m3) y (mi, m2, m4).
14 Offutt, A.J., Liu, S., Abdurazik, A. y Amman, P., 2003, Generating test data from state-based
specifications, Software Testing, Verification and Reliability (13), 25-53.
44 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS...______ RA-MA
3.6 EJERCICIOS
1. La autenticacin de los usuarios ante un sistema se lleva a cabo mediante
la serie de pasos que se describe en la Figura 3.6. Como se observa,
cuando un usuario se ha tratado de identificar tres veces de manera
errnea, el sistema de autenticacin le bloquea la cuenta. Igualmente, si el
usuario se identifica correctamente y ya tena una sesin abierta, se le
cierra la sesin antigua y se le crea una nueva. Se pide que proponga casos
de prueba para lograr cobertura de estados, de transiciones, de pares de
transiciones y de secuencia completa. Indicacin: considere que la
mquina posee algunos caminos infactibles, como el que consiste en las
transiciones 1-2-3-11-13-14, ya que para alcanzar 13 es necesario que la
variable contador sea 3. Este ejercicio se soluciona parcialmente en el
captulo 5.
o
Comprobar login',
[contador<3] y contrasea
2
*
~-3 [error]<^y
4 [correcto]
........
: Comprobarsiya
'tiestconectadop
I5
Cerrarsesin W X
7
6 [no]
Crearsesinjp
14
9
!
tinalistadesesiones
10
Figura 3.6. Descripcin del comportamiento de un caso de uso para identificarse ante un sistema
46 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
<18 No conceder
package dominio;
public class Prstamo {
public Prstamo!) {
}
public boolean conceder(int edad, double ingresosMes, int antigedad,
int mesesAmortizacion, double tasa) {
if (edad<18)
return false;
if (edad>70 && ingresosMes>3*tasa && mesesAmortizacion<=24)
return true;
if (edad>70 && mesesAmortizacion<24)
return true;
if (edad>70 && mesesAmortizacion>24)
return false;
if (edad>=25 && edad<=50) {
if (ingresosMes>4*tasa)
return true ,-
if (ingresosMes<=3*tasa && antiguedad>10 &&
mesesAmortizacion<=60)
return true;
}
if (edad>50 && ingresosMes>=3*tasa && antiguedad>15 &&
mesesAmortizacion<=60)
return true;
return false;
}
}_____________________________________________________________________
Figura 3.7. Cdigo al que se ha traducido la tabla de decisin anterior
VALORES DE PRUEBA
Cadena de ms de 255
caracteres **
Tabla 4.2. Valores de prueba seleccionados, a los que se han aadido los procedentes de la conjetura
de errores
Para valores de otros tipos, como los numricos, suele utilizarse el valor 0
(ya que, por ejemplo, puede que se utilice como denominador en alguna divisin),
algn nmero negativo, etc.
construyan (que sern las entradas del programa bajo prueba) debern ser capaces
de generar las salidas en cada una de las clases de equivalencia de salida.
(4, 7) 1
Tabla 4.3. Tablas de pares y nmero de visitas para los parmetros A, B y C
4.6 EJERCICIOS
1. Aplicando las tcnicas enumeradas en este captulo, proponga valores de
prueba para probar suficientemente la funcin conceder de los ejercicios del
captulo anterior.
2. Utilice los valores propuestos en el ejercicio anterior para obtener dos test
suites que alcancen respectivamente cobertura each use y pairwise.
3. A primera vista, parece evidente que los casos de prueba que cumplan each
use alcanzarn menos cobertura de cdigo que los que cumplan pairwise.
Utilice la funcin conceder y los dos test suites obtenidos en el ejercicio
anterior para comprobar esa supuesta evidencia.
Captulo 5
Una vez que se han propuesto los valores ms adecuados para probar el
sistema, el tester debe combinarlos con objeto de obtener buenos casos de prueba
que lo ayuden a encontrar errores en el sistema. En general, los casos de prueba
ejecutan servicios del sistema bajo prueba. Tras cada ejecucin, el caso debe ser
capaz de determinar, mediante lo que se llama un orculo, si el sistema se ha
comportado de forma correcta (no ha encontrado error) o de forma incorrecta (s
lo ha encontrado).
5.1.1 Ejemplo
Supongamos que el sistema bancario que venimos utilizando manipula una
base de datos relacional cuyo esquema entidad-interrelacin es el que aparece en la
Figura 5.1, la base de datos almacena informacin de Clientes, cada uno de los
cuales puede tener varias Cuentas-, cada Cuenta tiene una serie de Movimientos
(ingresos y retiradas de fondos) y puede tener varias taijetas asociadas, que pueden
ser de Dbito o de Crdito. Ambos tipos de taijetas tienen tambin una serie de
Movimientos de tarjeta asociados. Las tarjetas de Dbito no aportan nada respecto
de la definicin de Tarjeta, mientras que las de Crdito tienen una columna
adicional (crdito) que denota el crdito concedido a esa tarjeta. Hay, adems, una
tabla aislada (UltimosNmeros) en la que se almacena un contador para asignar el
nmero de cuenta a las cuentas nuevas que se van creando.
_ J Cuenta 3 Movimiento
i NIF
N VARCHAFU5G) f Numero VARCHARI50) : ktevtmnto INT
: > Fecha Apertura DATETIME . O N um w oD a*o3 VARCHAR50)
# NIFTituter VARCHAR( 50) V importe DOUBLE
^ Focha DAT ETfMF
V Concepto VARCHAR{50)
de ella. En la ltima instruccin del bloque try, se comprueba que el nuevo saldo de
la cuenta sea el anterior menos los 500 euros que se han retirado. Si el sistema bajo
prueba se comporta adecuadamente con este caso de prueba (es decir, el saldo se
decrementa efectivamente en 500 euros), el framework JUnit mostrar, para este
caso, una barra verde; en otro caso, mostrar una barra roja.
}
_}_______________________________________________________________________
Figura 5.2. Un caso de prueba para probar la operacin retirar de la clase Cuenta
Como tal vez se recuerde, el primer ejercicio del captulo 2 nos planteaba
lo siguiente:
try {
cuentaPepe=new Cuenta(pepe);
cu e n t aAn a=n ew Cuenta (ana) ;
cuentaPepe.insert();
cuentaAna.insert();
} catch (Exception e) { f a i l (e.toString()); }
try {
cuentaPepe.ingresar(1000, "Ingreso a Pepe");
cuentaAna.ingresar(2000, "Ingreso a Ana");
} catch (Exception e) { fail (e.toStringO ) ; }
)_________________________________________________________________________
Figura 5.3. Cdigo del mtodo setUp para los casos de prueba del banco
package bancoupm.dominio.tests;
5.2 EL ORCULO
Como se ha comentado, el orculo es el mecanismo de que se dota a los
casos de prueba para determinar si el propio caso ha encontrado o no un error en el
sistema bajo prueba. El orculo debe ser lo suficientemente fino como para
comprobar adecuadamente el comportamiento obtenido por el sistema. En el
ejemplo de la Figura 5.2, el orculo viene dado por la instruccin
assertTrue(this.cuentaPepe.getSaldoQ==saldoPepePre-500), que comprueba, para
una retirada de 500 euros de la cuenta de Pepe, que el saldo, en efecto, disminuye
en esa cantidad. Un orculo menos riguroso podra comprobar, sencillamente, que
el saldo de la cuenta, despus de la retirada, es menor que el saldo antes de ejecutar
la operacin: assertTrue(this.cuentaPepe.getSaldoQ<saldoPepePre). Como se
observa, este orculo tiene una granularidad mucho ms gruesa que el anterior, y
tiene una probabilidad ms alta de pasar por alto errores en el sistema.
obtenido) pueden expresarse como una funcin de los valores de los campos de los
objetos involucrados. En el ejemplo del orculo escrito para la operacin retirar, se
toma el estado del objeto cuentaPepe que, en este caso, es el nico objeto que
interviene en el escenario de ejecucin. El estado de cuentaPepe viene dado por
una llamada a su mtodo getSaldo, el cual, como se ve en la Figura 5.5, devuelve
la suma de los importes de los movimientos asociados a la cuenta: en la
determinacin del valor del estado de la instancia, entonces, intervienen los estados
de otros objetos, que son los movimientos, pero que forman parte de la definicin
de la Cuenta.
Adems, puesto que cada transicin conecta dos estados, la definicin del
estado origen puede utilizarse como precondicin del caso de prueba, y la
definicin del estado destino, como poscondicin.
Figura 5.6. Una posible mquina de estados para una clase Cuenta
Estado Descripcin
Recin creada movimientos.size()=0
Cero o positivo getSaldo()>=0
Negativo getSaldo()<0
Tabla 5.1. Descripcin de los estados de una clase Cuenta
Por otro lado, las mquinas de estado se utilizan tambin para describir
casos de uso: los estados representan pasos en la ejecucin del caso de uso, y las
transiciones representan que el paso o actividad anterior se ha terminado de
ejecutar y se pasa a ejecutar la siguiente actividad que corresponda. Puesto que los
casos de uso se corresponden de forma muy aproximada con los requisitos
funcionales del sistema, pueden utilizarse las mquinas de estado que describen
casos de uso para preparar, desde la captura de requisitos, casos de prueba
funcionales, que quizs se ejecuten en un momento mucho ms tardo (cuando, por
ejemplo, el sistema est completamente terminado).
[contador<3] j
12
2
11
[contador=3] Incrementar
contador [error]
4 [correcto]
( Cerrar sesin - ^
f y
6 [no]
Crear sesin
14
Aadir la sesin a
' .una lista de sesiones
Figura 5.8. Una mquina de estados que representa el caso de uso Identificar
RA-MA CAPTULO 5. ESTRATEGIAS DE COMBINACIN PARA LA OBTENCIN DE... 69
Puesto que los casos de prueba deben ser mantenidos y ejecutados, lo cual
tiene un coste asociado, por lo general es deseable obtener test suites que no sean
demasiado grandes (es decir, que no tengan demasiados casos de prueba) y que, a
la vez, sean capaces de encontrar tantos errores como sea posible.
16 3 7 8 {2, 2, 0}
17 3 7 9 {2,2,1}
18 4 5 8 {3, 0, 0}
19 4 5 9 {3,0,1}
20 4 6 8 {3,1,0}
21 4 6 9 {3,1,1}
22 4 7 8 {3,2,0}
23 4 7 9 {3,2,1}
Tabla 5.5. La Tabla 5.4, ampliada con una columna que representa la posicin de los elementos
(valores) en cada conjunto (parmetros)
De manera general, si hay n conjuntos {S, S2, ... S}, cada elemento de S
aparece |S,2 |-|&|-...-|/S'B| veces seguidas (donde \S\ es el cardinal del conjunto S); los
elementos de S2, |5?|-,Sj... jS| veces seguidas; etc. Los elementos de S aparecen
una vez cada uno, alternndose. Ya que el nmero de combinaciones es conocido a
n n
priori ( n '^ 'X dado un ndice arbitrario i, o < i < r n es posible conocer la
i=1 =1
combinacin o caso de prueba correspondiente a ese i. A continuacin, explicamos
cmo.
i
posicinDelValor(J, i) %\Sj
divisoresj
Figura 5.10. Clculo del valor del conjunto j-simo para la combinacin i-sima.
i
p o sic i n D e lV a lo r(j,i ) =
divisoresj %1-S/l
Figura 5.10. Clculo del valor del conjunto j-simo para la combinacin i-sima.
la combinacin; en otro caso, se toma otro valor (puede ser aleatoriamente, el que
menos veces se haya utilizado, el que el tester considere ms oportuno, etc.).
15 Cohen, D.M., Dalai, S.R., Kajla, A. y Patton, G.C., 1994, The automatic efficient test generator
(AETG) system, proceedings of Fifth International Symposium on Software Reliability Engineering
(ISSRE94), IEEE Computer Society Press, Los Alamitos, California, 303-309.
76 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
Aadir c al resultado.
Actualizar tablasDePares con los pares visitados por c.
Mientras haya pares no visitados en tablasDePares:
Inicializar c, colocando el valor que visita ms pares no visitados en
pairTables.
Completar c con valores compatibles de los restantes parmetros, de manera
que se visite el mayor nmero de pares.
Aadir c al resultado.
Actualizar tablasDePares con los pares visitados por c.
Figura 5.14. Versin determinista de AETG
RA-MA CAPTULO 5. ESTRATEGIAS DE COMBINACIN PARA LA OBTENCIN DE... 77
5. Finalmente, resultado={(l, 5,8), (1, 6, 9), (1, 7, 8), (2,5, 9), (3, 5, 8),
(4, 5, 8), (2, 6, 8), (2, 7, 9), (3, 6,9), (4, 6, 9), (3, 7,8),(4, 7, 8)}
Iteraciones 1 2 3 4 5 6 7 8 9
0 3 5 5 5 4 6 6 5 7
1 1 5 5 5 4 4 6 5 5
2 0 5 5 5 4 4 4 3 5
3 0 3 5 5 2 4 4 3 3
4 0 3 3 5 1 4 4 3 3
5 0 3 3 3 0 4 4 2 3
6 0 1 3 3 0 2 4 0 3
7 0 0 3 3 0 2 2 0 2
8 0 0 1 3 0 1 2 0 1
9 0 0 1 1 0 0 2 0 0
10 0 0 0 1 0 0 1 0 0
11 0 0 0 0 0 0 0 0 0
Tabla 5.7. Pares visitados por cada valor en las distintas iteraciones de la versin determinista
deAETG
RA-MA CAPTULO 5. ESTRATEGIAS DE COMBINACIN PARA LA OBTENCIN DE... 79
0 ,6 ) 1 (1,9) 1 (5,9) 3
(3,5) 4 (4, 8) 5, 11
(3,6) 8 (4, 9) 9
(3, 7) 10
(4, 5) 5
(4, 6) 9
(4, 7) 11
Tabla 5.8. Tablas de pares e iteraciones en que son visitados los pares de los parmetros A, B y C
{(1, 5, 8), (1, 6, 9), (1, 7, 8), (2, 5, 9), (3, 5, 8), (4, 5, 8), (2, 6, 8), (2, 7, 9),
(3, 6, 9), (4, 6, 9), (3, 7, 8), (4, 7, 8)}
80 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
El algoritmo PROW ha sido ideado por los autores de este libro y da una
solucin a este problema. Las principales caractersticas de este algoritmo son:
La Figura 5.15 muestra los pares generados para el ejemplo. Las tablas de
pares contienen dos columnas extras: Remove y Sel Factor. La columna Remove
indica si dicho par debe ser borrado antes de que el algoritmo genere los casos de
prueba; la columna Sel Factor permite asignarle un peso a dicho par. Una de las
propiedades de pairwise es que, cuando los parmetros tienen distinto nmero de
valores, los valores de los parmetros con menos valores se incluyen ms veces
para obtener la cobertura pairwise. En el ejemplo, ese es el caso del parmetro
RA-MA CAPTULO 5. ESTRATEGIAS DE COMBINACIN PARA LA OBTENCIN DE... 81
Sistema Operativo. Cubrir todos los pares al menos una vez requiere incluir los
valores de Sistema Operativo, que solo tiene tres valores. Pero como no todos los
pares tienen la misma prioridad para las pruebas, el tester puede estar interesado en
darle ms prioridad a los pares que, por ejemplo, vayan a tener ms frecuencia de
aparicin o uso en el entorno de produccin. En nuestro ejemplo, al par (Linux,
Firefox) se le ha asignado un peso de 1, mientras que al par (Linux, Chrome) un
peso de 0,3. Con esto, el tester quiere expresar que es ms importante probar la
combinacin de Linux con Firefox que con el navegador Chrome. En el algoritmo
PROW, el peso de los pares se utiliza en el momento de visitar ms de una vez un
par.
La Tabla 5.11 muestra, paso a paso, la forma en que se obtienen los casos
de prueba mediante PROW. Al igual que en AETG, PROW construye los casos de
prueba por iteraciones. Cada caso de prueba se inicializa con el valor que visite
ms pares an no visitados. Cada fila de la Tabla 5.11 muestra los pares an no
visitados de cada valor al comenzar la iteracin. Para la primera iteracin, Linux y
Mac OS aparecen en 6 pares y Windows en 7. El algoritmo selecciona el valor
Windows y completa el caso de prueba seleccionando los valores Firefox y Open
Office, ya que son los que visitan ms pares an no visitados y maximizan el peso
de la combinacin, que es 1.3: selFactor (Windows, Firefox) + selFactor
(Windows, Open Office) + selFactor (Firefox, OpenOffice) = 0.8 + 0.5 + 0 = 1.3.
16 pairs in (1, 2)
Elements Remove Sel. factor
12 pairs ib (0,1) 12 pairs in (0. 2) (Frefox. Microsoft Word) m 00
Elements Remove SeL factor Elements Remove SeL factor (Firefox Google Docs) 00
|(L*wx, Firefox) H 1 (Linax. Microsoft Word) m 00 (Firefox, Open Office) 00
(L*hk , Chrome) n 03 (Linux. Google Docs) 02 (Firefox, Feng Office) 00
:(Linux. Explorer) a 00 {Linux, Open Office) 1 (Chrome Microsoft Word) 00
(Lian, Opera) B 08 (Linux, Feng Office) 08 (Chrome. Google Docs) 00
(Windows, Fkefox) B 08 (Windows, Microsoft Word) m 1 (Chrome Open Office) 00
(Windows, Chrome) e? 03 (Windows, Google Docs) o 04 (Chrome, Feng Office) E 00
(Windows, Explorer) m 1 (Windows. Open Office) o 05 (Explorer Microsoft Word) D 1
(Windows, Opera) m 00 (Windows, Feng Office) O 02 (Explorer, Google Docs) B 00
(Ma: OS, Firefox) E 11 (Mac OS, Microsoft Word) m 00 (Explora Open Office) 00
(Mac OS, Chrome) B 08 (Mac OS, Google Docs) o 06 (Explora. Feng Office) B 00
(Mac OS, Explorer) * 00 (Mac OS, Open Office) 1 (Opera, Microsoft Word) E 00
(Mac OS, Opera) a 03 (Mac OS, Feng Office) 02 (Opera. Google Docs) B 00
(Opera, Open Office) 00
(Opera Feng Office) 00
visitado hasta el final del algoritmo. En el paso 16 del algoritmo ( Tabla 5.11),
solamente quedan dos valores con pares por visitar: Opera y Word. Se selecciona
Opera. Para el Sistema Operativo puede seleccionarse Linux o Mac. Se selecciona
Linux. Para el Procesador de Texto no puede seleccionarse Word debido a que el
par (Linux, Word) fue borrado. PROW, entonces, selecciona OpenOffice otro valor.
El caso de prueba resultante es {Linux, Opera, OpenOffice}. Sin embargo, como
todos los pares visitados por este caso de prueba se han visitado previamente, el
algoritmo termina.
S.O. Navegador Procesador de Texto Peso
Paso Caso d e Prueba
i intu Windows Mac Firefox texpforer Opera Chrome Word Open Feng Google Total
1 6 7 6 7 5 6 7 5 7 7 7 {Windows.Freox,OpenOffice} 0.8
2 6 5 6 5 5 6 7 5 5 7 7 {Linux, Chrome, FengOffice] 1.1
3 4 5 6 5 5 6 5 5 5 5 7 {Mac. Opera. Google} 0.9
4 4 5 4 5 5 4 5 5 5 5 5 {Windows, i Explorer,Word} 2
5 4 3 4 5 3 4 5 3 5 5 5 (Linux, Firefox, Google} 1.2
6 2 3 4 3 3 4 5 3 5 5 3 {Mac, Chrome, OpenOffice} 18
7 2 3 2 3 3 4 3 3 3 5 3 {Windows, iExplorer, Feng} 1.2
8 2 2 2 3 2 4 3 3 3 3 3 {Linux, Opera, OpenOffice} 1.8
9 0 2 2 3 2 2 3 3 1 3 3 (Mac, Firefox, Feng} 1.2
10 0 2 0 1 2 2 3 3 1 1 3 {Windows, Chrome, Google} 07
11 0 0 0 1 2 2 1 3 1 1 1 {Windows, Firefox, Word] 18
12 0 0 0 0 2 2 1 2 1 1 1 {Windows, lExpSorer, OpenOffice} 1
13 0 0 C 0 1 2 1 2 0 1 1 (Linux, Opera. Feng} 1.6
14 0 0 0 0 1 1 1 2 0 0 1 {Windows, Chrome, Word} 1.3
15 0 0 0 0 1 1 0 1 0 0 1 {Windows, Explorer. Googie} 1.4
16 0 0 0 0 0 1 0 1 0 0 0
Una vez obtenidos los casos de prueba, el algoritmo PROW los ordena
segn el peso. El resultado final del algoritmo puede verse en la Tabla 5.12. En
caso de que no se cuente con el tiempo suficiente para ejecutar todos los casos de
prueba, el tester puede ejecutarlos segn el orden establecido por el algoritmo, ya
que estar ejecutando primero los que ms importancia tienen para las pruebas.
C aso s d e P ru eb a P eso
{ W in d o w s, E x p lo re r, M ic ro s o ft W o rd } 2 .0
{M ac OS, C h r o m e , O p e n O ffice} 1 .8
{ W in d o w s, F ire fo x , M ic ro s o ft W ord} 1 .8
{Linux, O p e r a , O p e n O ffic e } 1.8
{Linux, O p e r a , F e n g O ffice} 1.6
{ W in d o w s, (E x p lo re r, G o o g le Docs} 1.4
{ W in d o w s, C h r o m e , M ic ro s o ft W ord} 1.3
{M ac OS, F ire fo x , F e n g O ffice} 1.2
{ W in d o w s, E x p lo re r, F e n g O ffic e } 1.2
{Linux, F ire fo x , G o o g le Docs} 1 .2
{Linux, C h r o m e , F e n g O ffic e } 1.1
{ W in d o w s , E x p lo re r, O p e n O ffice} 1 .0
{M ac OS, O p e r a , G o o g le Docs} 0 .9
{ W in d o w s, F ire fo x , O p e n O ffice} 0 .8
{ W in d o w s, C h r o m e , G o o g le Docs} 0 .7
Tabla 5.12. Casos de Prueba obtenidos con el algoritmo PROW y el peso asociado
84 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS...______ RA-MA
5.3.5 Antirandom
Antirandom es una estrategia de combinacin propuesta por Malayia16:
partiendo de un caso de prueba te en el test suite, el siguiente en ser elegido (sea
te2) es aquel que resulte ms diferente de tc. El tercer caso (sea teA es el que sea
simultneamente ms diferente de tc y tc2. El siguiente, el ms diferente de los
tres ya seleccionados.
A |J c
Valor Bits Valor Bits Valor Bits
1 00 5 00 8 0
2 01 6 01 9 1
3 10 7 10
4 11 7 11
Tabla 5.13. Codificacin binaria de los elementos de A, B y C
16 Malaiya, Y.K., 1995, Antirandom testing: getting the most out o f black-box testing, proceedings of
the International Symposium on Software Reliability Engineering (1SSRE95), Toulouse, Francia,
IEEE Computer Society Press: Los Alamitos, California, 86-95.
RA-MA CAPTULO 5. ESTRATEGIAS DE COMBINACIN PARA LA OBTENCIN DE... 85
ltima columna de la tabla: ahora s, se toma, por ejemplo, el primer caso con
distancia 3,15, que es la palabra 01001 y que corresponde al caso (2, 5, 9).
Distancias Hamming
Distancia
Caso Al caso 00000 Al caso 11111 Total
cartesiana
00001 1 4 5 3
01000 1 4 5 3
01001 2 3 5 3,15
01010 2 3 5 3,15
01011 3 2 5 3,15
01100 2 3 5 3,15
01101 3 2 5 3,15
01110 3 2 5 3,15
01111 4 1 5 3
10000 1 4 5 3
10001 2 3 5 3,15
10010 2 3 5 3,15
10011 3 2 5 3,15
10110 3 2 5 3,15
10111 4 1 5 3
11000 2 3 5 3,15
11001 3 2 5 3,15
11010 3 2 5 3,15
11011 4 1 5 3
11100 3 2 5 3,15
11101 4 1 5 3
lino 4 1 5 3,15
Tabla 5.14. Distancias Hamming en la primera iteracin del algoritmo Antirandom
86 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
(que representa el juego) toma los valores Ludo, Trivial, Checkers y Chess
(respectivamente: parchs. Trivial Pursuit, damas y ajedrez); B toma Dice cuando el
juego requiere dados, y nuil en otro caso; C denota al jugador oponente que puede
ser una persona o el ordenador; D indica el nmero de jugadores (2 o 3); E
representa el mtodo de pago (tarjeta Visa, Master Card o American Express) y F
denota si el juego lleva un sistema de preguntas o no, lo cual es aplicable para el
caso del Trivial Pursuit.
Figura 5.16. Pgina principal del sistema CTWeb, cargada con datos de ejemplo
Figura 5.17. Cdigo de ejemplo para generar casos de prueba con cdigo
Algorithm netgn
I Results fur 192 combinations
{Trivial .null.Computer 3 -Master Game g=new TriviaiQ; g.setDice(null); Opponent opp=new Computed); g.setOpponent(opp); g.setPlayers(3);
; jord.-} jg.setPaymentMcthod(Master card); g.setQuiz(-);
. {Trivial .nullPerson .3 American Game g=new TrivialO: g.setDice(null); Opponent opp=new PersonO; g.setOpponent(opp); g.setPlayenf3);
|{Chcckcrs,null,Computer3 American Game g=ncw CheckersO; g.sctDicc(null); Opponent opp=new ComputcrO; g.setOpponcnttopp);
' Sexpress, } g.setPiayers(3): g.setPaymentMethod(American express); g.setQuiz();
{CheckersT)icePerson3 American Game g=new CheckersO; g.setDice(Dice); Opponent opp=new PersonO: g.setOpponent(opp); g.setPlayers(2);
iexpress.Quiz} g.setPaymentMethod(Amcricac express); g.setQuiz(Quiz);
Computed in 15 milliseconds
Pairs visited: 100.0%
Figura 5.18. Resultados de aplicar AETG a los datos de los juegos de mesa con el cdigo
de la Figura 5.17
RA-MA CAPTULO 5. ESTRATEGIAS DE COMBINACIN PARA LA OBTENCIN DE... 89
5.5 EJERCICIOS
1. Se dispone de un sistema que permite realizar conversiones entre diferentes
unidades de medida:
- De temperatura, entre grados Celsius, Fahrenheit y Kelvin.
- De longitud, entre metros, yardas, pulgadas, kilmetros y millas.
- De masa, entre kilogramos, libras y onzas.
Figura 5.19. Dos comandos (izquierda) para convertir de kilmetros a metros y viceversa
Captulo 6
todos los errores sembrados, entonces se dice que el test suite es adecuado para la
mutacin (mutation adequate). Para detectar los fallos, los casos de prueba se
ejecutan contra el programa original (sin fallos artificiales, con lo que se presume
que es correcto) y contra los mutantes: si, con un caso de prueba tc, se observa que
el mutante se comporta de manera diferente al programa original, entonces tc ha
encontrado el fallo introducido (o fallos introducidos) en el mutante y se dice que
el mutante est muerto; en otro caso (el comportamiento observado es el mismo),
se dice que el mutante est vivo. El primer objetivo de las pruebas mediante
mutacin consiste, precisamente, en evaluar la calidad de los test suites midiendo el
porcentaje de mutantes que se matan: en efecto, si nuestro test suite encuentra
todos los errores sembrados en los mutantes, entonces tenemos una garanta muy
alta respecto de la buena calidad del test suite. Adems, si el mismo test suite (que
detecta todos los fallos introducidos artificialmente) pasa por el programa original
(es decir, el programa que se est probando) sin encontrar ningn error, entonces
hay una garanta muy alta respecto de la buena calidad del programa bajo prueba.
Insistiendo en el smil del corrector ortotipogrfico, si este no encuentra ninguna
errata en un texto que se le pasa es porque el texto, probablemente, no tiene
ninguna.
Versin Cdigo
P (original) int su m (int a, int b)
{ Datos de prueba
return a + b;
} (1,1) (0,0) (-1,0) (-1,-1)
Mutante 1 int s u m (int a, int b)
p 2 0 -1 -2
{
return a - b;
Mutante 1 0 0 -1 0
}
Mutante 2 int su m (int a, int b) 1
Mutante 2 1 0 0
{
return a * b;
Mutante 3 1 Error Error 1
}
Mutante 3 int s u m (int a, int b) -1 -2
Mutante 4 2 0
{
return a / b;
i
Mutante 4 int s u m (int a, int b)
{
return a + b++;
J _______________________
Tabla 6.1. Un programa original (P), cuatro mutantes y los resultados de cada mutante con algunos
casos de prueba
94 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
Para medir la calidad del test suite, por tanto, se necesita conocer el
nmero de mutantes generados, el nmero de imitantes muertos y el nmero de
mutantes equivalentes. La calidad se mide con el mutation score, que viene dado
por la expresin de la Figura 6.2.
T : test suite
Los fallos que introducen los operadores de mutacin deben ser parecidos a
los que cometen involuntariamente los programadores. Han de ser fallos buenos;
es decir, fallos de buena calidad. Existen operadores de mutacin tradicionales
(que son aplicables prcticamente a cualquier lenguaje de programacin, como los
mostrados en la Tabla 6.2), otros que son dependientes del paradigma (Tabla6.3)
y otros que se disean para algn lenguaje de programacin especfico (para C17,
por ejemplo).
17 Barbosa, E.F., Maldonado, J.C. y Rizzo Vincenzi, A.M., 2001, Toward the determination of
sufficient mutant operators for C, Software Testing, Verification and Reliability, 11(2), 113-136.
RA-MA CAPTULO 6. PRUEBAS MEDIANTE MUTACIN 95
Operadores tradicionales
Sustitucin de una variable por el valor absoluto
ABS (absolute value)
de dicha variable.
ACR (array reference for constant Sustitucin de una referencia variable a un array
replacement) por una constante.
AOR (arithmetic operator
Sustitucin de un operador aritmtico.
replacement)
CRP (constant replacement) Sustitucin del valor de una constante.
ROR (relational operator
Sustitucin de un operador relacional.
replacement)
RSR (return statement
Sustitucin de la instruccin return.
replacement)
SDL (statement deletion) Eliminacin de una sentencia.
Insercin de operador unario (por ejemplo: en
UOI (unary operator insertion)
lugar de x, poner -x).
AMC (access modifier Reemplazo del modificador de acceso (por ejemplo: ponemos
change) private en lugar de public).
Cambio del orden de los argumentos pasados en la llamada a
AOC (argument order un mtodo (por ejemplo: en lugar de Personap=new
change) Persona(Paco , Pil ), poner Persona p=new
Persona(Pil , Paco ).
Sustitucin de una referencia a una instancia de una clase por
CRT (compatible
una referencia a una instancia de una clase compatible (por
reference type
ejemplo: en vez de poner Persona p=new EmpleadoQ, poner
replacement)
Persona p=new EstudianteQ).
Cambio de una instruccin de manejo de excepciones (try...
EHC (exception handling
catch) por un sentencia que propague la excepcin {throw), y
change)
viceversa.
18 DeMillo, R.A. y Spafford, E.H., 1986, The Mothra software testing environment, proceedings of
the 11th NASA Software Engineering Laboratory Workshop, Goddard Space Center, EE. UU.
96 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
HFA (hiding field Adicin en la subclase una variable con el mismo nombre que
variable addition) una variable de su superclase.
MIR (method invocation Reemplazo de una llamada a un mtodo por una llamada a
replacement) otra versin del mismo mtodo.
OMR (overriding method Eliminacin en la subclase la redefinicin de un mtodo
removal) definido en una superclase.
19 Aeree, A.T., Budd, T.A., De Millo, R.A., Lipton, R.J. y Sayward, F.G., 1979, Mutation analysis,
technical report GIT-ICS-79/08, School of Information and Computer Science, Georgia Institute of
Technology, Atlanta, Georgia, EE. UU.
20 De Millo, R.A., Lipton, R.J. y Sayward, F.G., 1978, Hints on test data selection. Help for the
practicing programmer, IEEE Computer, 11 (4), 34-41.
RA-MA CAPTULO 6. PRUEBAS MEDIANTE MUTACIN 97
21 Polo, M. y Reales, P., 2010, Mutation testing cost reduction techniques: a survey, IEEE
Software, 27(3), 80-86.
98 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
Corregir P
Programa bajo
prueba (P)
A
Aadir casos de
prueba a T Crear mutantes
A
Ejecutar T sobre
I
cada mutante vivo
correcta), con lo que P debe ser corregido y sus mutantes regenerados (dejan de ser
vlidos los que tenamos de antes, pues procedan de una versin anterior del
programa). Por ello, para evitar esta segunda regeneracin de mutantes, es preciso
tener una cierta garanta de que el test suite que ejecutamos inicialmente alcanzar
una cobertura amplia sobre P, para lo que es recomendable utilizar buenos valores
de prueba y combinarlos adecuadamente con una buena estrategia de combinacin.
1. Generacin de mutantes.
2. Ejecucin de casos de prueba contra el programa original y contra los
mutantes.
3. Anlisis de resultados.
introducido); tcs se ejecuta tambin solamente contra m7, que no llega a morir
(obsrvese que tc5 no llega a ejecutarse contra m2, ya que este mutante fue muerto
por tc, por lo que tc tambin se considera ahora inefectivo). Finalmente, tc6 se
ejecuta y mata a m7. Con este proceso, en lugar de 42 ejecuciones de casos de
prueba, hay 7 + 5 + 4 + 1 + 1 + 1 = 19, lo que reduce ostensiblemente el coste de
las pruebas.
Casos de prueba
tcl tc2 tc3 tc4 tc5 tc
mi X X
m2 X X X
m3 X X
Mutantes
m4 X X
m5 X X
m6 X X
mi X
Tabla 6.4. Matriz de mulantes muertos
No obstante, ejecutar todos los casos contra todos los mulantes puede ser
conveniente en algunas ocasiones: si tenemos en cuenta las futuras etapas de
mantenimiento y modificacin del software, con las consiguientes pruebas de
regresin, puede ser conveniente priorizar los casos de prueba con el objeto de
abaratar las pruebas en un futuro. As, a partir de la matriz completa de muertos del
ejemplo, podra obtenerse un test suite reducido formado por los casos tc6 y tc, que
conseguira un mutation score idntico al del test suite original.
Para reducir los costes en esta etapa, se realizan dos tipos de selecciones:
seleccin aleatoria de mutantes (es decir, utilizacin de un conjunto aleatorio de los
imitantes generados) y seleccin de los mejores operadores de mutacin (lo que se
llama mutacin selectiva).
22 DeMillo, R.A. y Spafford, E.H., 1986, The Mothra software testing environment, 11* NASA
Software Engineering Laboratory Workshop, Goddard Space Center, EE. UU.
23 Aeree, A.T., 1980, On mutation, PhD Thesis, School of Information and Computer Science,
Georgia Institute of Technology, Atlanta, Georgia, EE. UU.
24 DeMillo, R.A., Guindi, D.S., King, K.N., McCracken, W.M. y Offutt, A.J., 1988, An extended
overview of the Mothra software testing environment, Second Workshop on Software Testing,
Verification and Analysis, Banff, Alberta, Canada, 142-151, IEEE Computer Society Press.
25 King, K.N. y Offutt, A.J., 1991, A fortran language system for mutation based software testing.
Software: Practice and Experience, 21(7), 685-718.
26 Mresa, E.S. y Bottaci, L., 1991, Efficiency of mutation operators and selective mutation strategies:
an empirical study, Software Testing, Verification and Reliability, 9(4), 205-232.
102 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
Para reducir costes de compilacin, tambin existen otras dos tcnicas que
pueden ser aplicadas a sistemas que se basen en cdigo interpretado (o
semiinterpretado, como Java). La primera consiste en integrar operadores de
27 Offutt, A.J., Rothermel, G., Untch, R.H. y Zapf, C., 1996 An experimental determination of
sufficient mutant operators, ACM Transactions on Software Engineering and Methodology, 5(2), 99-
118.
28 Ji, C., Chen, Z., Xu, B. y Zhao, Z., 2009, A novel method of mutation clustering based on domain
analysis, 21st International Conference on Software Engineering and Knowledge Engineering
(SEKE'09), Boston, Massachusetts.
29Ma, Y.S., Offutt, J. y Kwon, Y.R., 2005, MuJava: an automated class mutation system, Software
Testing, Verification and Reliability, 15(2), 97-133.
RA-MA CAPITULO 6. PRUEBAS MEDIANTE MUTACION 103
30 Untch, R., O (fut, A.J. y Harrold, M.J., 1993, Mutation analysis using program schemata.
International Symposium on Software Testing and Analysis, Cambridge, Massachusetts, ACM Press.
104 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
caso de prueba puede ejecutarse bien con la herramienta MuJava31 o bien con
testooj32. Estas dos herramientas ejecutan el caso contra el programa original (que,
por ejemplo, devolvera la cadena 4,1,5.4, correspondiendo el 4 a un no tringulo,
pues esta instancia corresponde a una lnea recta, ya que la suma de los dos
primeros lados es igual a la longitud del segundo) y, luego, contra cada mutante.
Supongamos que uno de los mutantes incrementa el valor del lado J en el mtodo
setJ (que pasa a valer 2), con lo que el tringulo pasa a ser escaleno: ahora, la
cadena devuelta por el caso de prueba sera 4,2,5,3 (suponiendo que el valor 3
corresponda al tipo escaleno), y el caso de prueba habra matado el mutante.
En efecto, ese caso de prueba consigue las tres condiciones RIP necesarias
para la mutacin fuerte: la instruccin mutada (en setJ) se alcanza; se produce un
estado intermedio errneo (el propio incremento del lado); y el estado errneo es
observable al finalizar la ejecucin del caso de prueba.
31 Ma, Y.S., Offutt, J. y Kwon, Y.R., 2005, MuJava: an automated class mutation system. Software
Testing, Verification and Reliability, 15(2), 97-133. MuJava est disponible en (18 de octubre de
2010): es.gmu.edu/~offutt/mujava/.
32 Polo, M., Tendero, S. y Piattini, M., 2007, Integrating techniques and tools for testing
automation. Software Testing, Verification and Reliability, 17(1), 3-39. Testooj est disponible en
(18 de octubre de 2010): alarcos.esi.uclm.es/testooj3/.
RA-MA CAPITULO 6. PRUEBAS MEDIANTE MUTACION 105
33 Howden, W.E., 1982, Weak mutation testing and completeness of test sets, IEEE Transactions
on Software Engineering, 8(4), 371-379.
j4 Offutt, A.J. y Lee, S.D., 1994, An empirical evaluation of weak mutation, IEEE Transactions on
Software Engineering, 20(5), 337-344.
106 TECNICAS COMBINATORIAS Y DE MUTACION PARA TESTING DE SISTEMAS... RA-MA
33 Reales, P., Polo, M. y OfTutt, A.J., 2010., Mutation at system and functional levels, proceedings
of the 2010 Third International Conference on Software Testing, Verification and Validation
Workshops, 110-119, IEEE Computer Society.
RA-MA CAPTULO 6. PRUEBAS MEDIANTE MUTACIN 107
j application |
-l ^
-| c la s s e s
|^A1 .class j
S te p 1. A2. c la ss ] j B 2 .class |
M utant generation
GZ] I
j Z .c la s s |
O riginal a p p lic a tio n
A nivel intraclase, una versin de orden 2 contendr una clase con dos
fallos. Por ejemplo, la clase A del sistema que mencionbamos arriba
podra ser sustituida por A j , que contiene los fallos introducidos en
los mutantes A , y A 2 de A. Esta versin defectuosa del sistema, por
tanto, quedara compuesta por las clases (A .class, B .cla ss... Z .class).
36 Frankl, P.G., Weiss, S.N. y Hu, C., 1997, All-uses vs mutation testing: an experimental
comparison of effectiveness, Journal o f Systems and Software, 38(3), 235-253.
37 Griin, B.J.M., Schuler, D. y Zeller, A., 2009, The impact of equivalent mutants, IEEE
International Conference on Software Testing, Verification, and Validation Workshops, Denver,
Colorado, EE. UU 192-199.
38 Polo, M , Piattini, M. y Garca-Rodrguez, I., 2008, Decreasing the cost of mutation testing with
second-order mutants, Software Testing, Verification and Reliability, 19(2), 111-131.
RA-MA CAPTULO 6. PRUEBAS MEDIANTE MUTACIN 109
39 Schuler, D. y Zeller, A., 2010, (Un-) Covering equivalent mutants, proceedings of the 3rd
International Conference on Software Testing Verification and Validation (ICSTTO), Pars, Francia.
110 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
Caractersticas generales
Nombre
Operadores
Tipo de test Disponible Ao Web
de mutacin
Tradicionales
Unitarios y de
JavaMut y a nivel de No 2002 -
clase
clase
Tradicionales
Unitarios y de
MuJava y a nivel de S 2004 cs.gmu.edu/~offutt/mujava/
clase
clase
De
A nivel de faculty.uoit.ca/bradbury/conman/
ExMan concurrencia/c S 2006
concurrencia
ualquiera**
Generacin de
test de
Mugamma Ninguno*** No 2006 -
regresin
unitarios
112 TECNICAS COMBINATORIAS Y DE MUTACION PARA TESTING DE SISTEMAS... RA-MA
Tradicionales
Unitarios y de
Muclipse y a nivel de S 2007 mucl ipse.sourceforge.net/
clase
clase
Nivel www.javalanche.org/
Javalanche Unitarios S 2009
tradicional
A nivel de www.irisa.ir/triskell/Softwares
Aj Mutator Para aspectos S 2009 / protos/Aj Mutator/
aspectos
Tradicionales
Unitarios y de
Judy y a nivel de No 2010 -
clase
clase
* J e s t e r implementa sus operadores de mutacin mediante sustitucin de cadenas de texto que pueden ser
configuradas.
* * E x M a n tiene una arquitectura basada en p lu g in s la cual permite aplicar cualquier operador de mutacin usando
el p lu g in adecuado.
* * * T e sto o j y M u g a m m a usan MuJava para generar mutantes.
Bytecode translation
Selective mutation
Parallel execution
Mutant clustering
Mutant schemata
Mutant sampling
Compiler-Based
Strong mutation
Weak mutation
Flexible weak
Higher order
integration
Compiler-
mutation
mutation
Jester Si S No Si No No No No No No No No
JavaMut S S No Si No No S No No No No No
MuJava S S No Si No No No Si Si No No No
ExMan S S No Si No No No No No No No No
Mugamma** S No - - - - No Si No No Si No
Muclipse S S No Si No No No No No No No No
Jumble No S No Si No No No No Si No No No
Testooj** S S - - Si - No No No No No No
Javalanche No S No Si No No No Si Si Si No No
AjMutator S S No Si No No No No No No No No
Judy S S No Si No No No Si* No No No No
Bacterio No S Si Si Si No No No Si Si Si Si
* Judy usa una optimizacin de mutant schemata basada en programacin orientada a aspectos.
** Mugamma y testooj usan MuJava para generar mutantes.
Tabla 6.6. Tcnicas de reduccin de costes implementadas por cada herramienta de mutacin Java
tcnicas. Sin embargo, el hecho de que el resto de las tcnicas estn implementadas
en una o dos herramientas puede ser un indicador de que el coste de
implementacin es alto. Estos costes suponen que todas estas tcnicas no han sido
implementadas juntas. Como muestra la Figura 6.7, la mayora de las herramientas
de mutacin solo implementan una o dos tcnicas de reduccin de costes. Solo la
herramienta Bacterio y, en menor medida, MuJava y Javalanche incluyen un
conjunto grande de tcnicas de reduccin de costes.
pode
mutMiR
T c n ic a s de
generacin y
eecuoon
T c n ic a s *
reduccin de
m utantes
Figura 6.7. Nmero de tcnicas para reducir costes implementadas en cada herramienta
Otro punto de vista interesante est relacionado con las caractersticas que
permite probar cada herramienta de mutacin. La Figura 6.8 muestra las
caractersticas del sistema que cada herramienta permite.
Figura 6.8. Caractersticas que pueden ser probadas con cada herramienta
RA-MA CAPTULO 6. PRUEBAS MEDIANTE MUTACIN 115
7.1 LICENCIA
La herramienta ha sido desarrollada por Pedro Reales y Macario Polo
(investigadores del Grupo Alarcos, Universidad de Castilla-La Mancha). La
empresa Alarcos Quality Center la comercializa y distribuye. No obstante, las
instituciones docentes y de investigacin pueden solicitar una licencia gratuita y
completa de Bacterio. En www.alarcosqualitycenter.com/index.php/productos/
bacterio puede solicitarse una licencia as como descargar el manual de usuario.
118 TECNICAS COMBINATORIAS Y DE MUTACION PARA TESTING DE SISTEMAS... RA-MA
7.2.1 ASM
ASM es un framework para analizar y manipular bytecode de Java. Permite
modificar clases existentes o generar clases de forma dinmica directamente en
formato binario. Permite realizar operaciones similares a las de otros frameworks
pero, en opinin de los desarrolladores de Bacterio, de forma ms sencilla.
You can redistribute some of the packages under the terms of the of
the GNU Lesser General Public License as published by the Free Software
Foundation. See the copyright headers in the source code.
This program is distributed in the hope that it will be useful, but without
any warranty; without even the implied warranty of merchantability or fitness
for a particular purpose. See the GNU General Public License for more details.
lado izquierdo de la Figura 7.3 muestra estos conjuntos de mutantes agrupados por
su correspondiente clase original; en el lado derecho se muestran todos los
mutantes de clase agrupados.
Sistema o rig in a l- A. B. C. D j
M{A], A 2, ... A P}
Mb={B, B 2, ... Bq},
M - { A h A 2, ... Ap,B/, B2, ... Bq, C i , C2, ... Cr, D, D 2, ... D s}
Mc={ch c2, . . . cy
M d = { D , , D 2, ... D s}
Figura 7.3. Mutantes que genera Bacterio para una supuesta aplicacin
Sistema original = { A, B, C, D}
Mutantes de orden 1 Mutantes de orden 2 Mutantes de orden 3 Mutantes de orden 4
M I ={A, B, C, Dj M1={A, Bj, C, D M1={A, Bh Cu Dj Ml={Ah B,, Ch D ,j
M2={A2, B, C, D} M2={A B2, C, D} M2={A|, B,, C2, D} M2={A|, B|, C|, D2}
Una vez que se dispone de las versiones mutadas, el tester puede lanzar la
ejecucin de los casos de prueba contra ellas. A continuacin, tras esta ejecucin.
Bacterio muestra los resultados: matriz de muertos, mutation score y otros datos de
inters.
KA Configuration
V e r s io n f o ld e r : c :/d o m in io / ( Select")
T e s t c a s e s f o ld e r . c :/d o m in io /o r ig in a l/ S e le c t
T im e o u t ; | 20000 Q
A v a n c e d O p t io n s )
( * )
V e r s io n fo ld e r : /U s e r s /M a c o /D e s k to p /v e r s io n s ( S e le c t
T e s t c a s e s fo ld e r : / U s e r s /M a c o /D e s k t o p / S u d o k u S o lv e r /b in S e le c t
T im e o u t. 20000 ?
( OK ) C C a n c e l ~)
Original Mutante
public void testl0 { public void testl () {
for (int i=0; i<100; i++) for (int i=0; i<100; i++)
System.out.println(i); System.out.println ( i- - ) ; (*)
} }
Figura 7.9. Un operador de mutacin que produce un bucle infinito
Los casos de prueba que tenemos disponibles en Testi. class son casos de
prueba JUnit, y pueden ejecutarse con la tcnica de cualifcacin funcional
(Functional Qualification). Si pulsamos el botn Advanced options, podemos
seleccionar Functional Qualification como el tipo de mutacin (Kind o f mutation)
seleccionado {Figura 7.10).
i* ...................... C o n f ig u ra tio n
J S y te C o d e m o d if ic a tio n in r u n tim e
O F ield s i n s p e c tio n
0 to S tr in g if d e fin e d , o t h e r w i s e fie ld s i n s p e c tio n
Q H a s h c o d e fie ld s in s p e c t io n
0 to S tr in g if d e fin e d , o t h e r w i s e H a s h c o d e f ie ld s in s p e c t io n
D e p th in f ie ld in s p e c t io n
L ocal IP J 27.0.0.1
L ocal P o r t . 3650
S e rv e r IP: 1 2 7 .0 .0 .1
S e rv er P ort; 36S1
C a p tu re d T e s ts F o ld e r: c :/c a p iu r e d T e s ts / S e | < )
P arallel e x e c u t i o n ( n / p r o c ... i 0
G S t o p t h e e x e c u t i o n b e tw e e n t e s t c a s e s
^ B asic o p t io n s }
1 C ancel ;
CE3
Figura 7.12. Seleccin de la ubicacin del sistema bajo prueba (izquierda) y de los ficheros .class
que deben mutarse (derecha)
RA-MA___________ CAPTULO 7. HERRAMIENTA BACTERIO: MANUAL DE UTILIZACIN 125
40 Ghosh, S. y Mathur, A.P., 2001, Interface mutation, Software Testing, Verification and
Reliability, (11), 227-247.
126 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
Cdigo original
int div(int a, int b) throws NaNException, ByZeroException {
if (a==0 && b==0) throw new NANException();
if (b==0) throw new ByZeroException();
return a/b;
}
Operador Cambios introducidos
Swap int div(int b, int a)
INC int div(int a, int b) int div(int a, int b) throws ... {
throws... { b++;
a++; if ...
if . if ~
if ~ return a/b;
return a/b;
}
}
DEC int div(int a, int b) int divtint a, int b) throws _ {
throws { b--;
a- - ; if _
if ... if _
if return a/b;
return a/b;
}
}
Nullif ier int div(int a, int b) int div(int a, int b) throws _ {
throws {
a=null; b=null; /* Not
if _. applicable to int type.
if if // It is just an
example.
return a/b;
if _ */
} return a/b;
i
Throw int div(int a, int b) nt div(int a, int b) throws ~ {
exceptions throws _ { throw new ByZeroException ();
throw new
NaNException(); }
}
AOR int div(int a, int int div(int a, int int div(int a, int
b) throws...{ b) throws... { b) throws... {
if ~ if if _
if _. if if ~
return a+b; return a-b; return a*b;
i } }
RA-MA CAPTULO 7. HERRAMIENTA BACTERIO: MANUAL DE UTILIZACIN 127
ABS int div(int a, int b) throws ... { int div(int a, int b) throws ...
if (Math.abs(a) ==0 && {
b==0) throw ... if (a==0 &&Math.abs (b) ==0)
if (b==0) throw new throw _
B y Z e r o E x c e p t i o n (); if (b==0) throw new
B y Z e r o E x c e p t i o n ();
return a/b;
return a/b;
i
}
UOI int div(int a, int b) throws ._{ int div(int a, int b) throws {
if (-a==0 && b==0) throw if (a==0 &&-b==0) throw
Tabla 7.1. Representacin en cdigo fuente de algunos cambios introducidos en una funcin Java
Traditionalmutationoperators
I AOR f ROR gf ASS Si UOt e LCR
( G et v e r s io n s
Sistema original={A, B, C, D}
Mutantes de clase=
{Ai, A2, A3, A4 , A5,
B|, B2 , B3, B4,
Ci, C2, C3, C4, C5, c 6.
Di, D2, D3 }
Figura 7.16. Seis versiones generadas con each choice: cada una contiene cuatro fallos
Figura 7.17. Tablas de pares de (A, B) y de (A, D) y todas las versiones mutantes generadas
High order mutacin: |_j Do not join mutants of the same operator
Mutant sampling:
%Size 25%
( Mount versions )
Figura 7.18. Algoritmos y opciones para la combinacin de los mutantes de las clases en versiones
mutadas
*osa
0 sudokusoher.flui
( f o T ) ( Cancel )
M u ta n ts
V e r s io n s
V e rs io n M u ta n t 1
veijtuu.*! tu t .su u u d k u su iv e i . u w n i w i x i i M . j T ^ r j n / "
v e rs io n s 4 2 ro r.su d o k u so lv e r.d o m in io .C a sflla .5 4 _ 4 _ 4 2 G
versfcm 543 ro r.s u d o k u so lv e r.d o m in io . C asilla.5 8 _ 3 _ 4 2 4
v e rs io n 5 4 4 ro r.s u d o k u so lv e r.d o m in io .C a s illa .7 _ 2 _ 3 7 3
v e rsio n S 4 5 uoi.su d o k u so lv er .dom m io.C asilla. 1 1 _ 0 _ 1 7 9 2
v e rs io n 5 4 6 u o i.s u d o k u s o lv e r.d o m in io .C a silla .l2 _ 0 _ 1 7 9 3
T o ta l m u ta n ts
Tot roe inc uoi dec swa aor nuf tex abs
2199 997 47 418 47 32 216 23 1 418
M u ta n ts
M utant!
IW.iUUU&UWIVCI..U U IIIH !IU .C <l>llld.J Li t X /
versionS 42 ror.sudokusolver dom into.C asdia. 54_4_4 2 0
verston543 ror. sudokusolver .dom im o.Ca sdla. 5 8_3_4 24
versio n 5 4 4 ror sudokusolver dom irao.C asilia.7_2_373
versionS4S uoi. sudokusolver . dom fnio.Casilla. 1 i _ 0 _ i 792
versio n 5 4 6 uoi. sudokusolver .dominio. Casilla. 12_G_1793
iversion547 uoi.sudokusolver dom inio.C asdla. 1 9_0_ 1 8 0 0
v ersio n s 4 6 uoi.sudokusolver..domink>.CasHla.3_G_1784
versk>n549 uoi.sudokusolver .dominio. C asilla.4_G_l 785
versionSSO uoi. sudokusolver dom tnio.C asilla.9_G _1790
M
inclass l L^ 1
_____l22d8 y toad *)
Alive versions
(^Select all Unselect all >
Itarstont *'
/versionlO )
/version 100
/version 101
/versionl02 t
f c C V v, versions. SSO
Figura 7.24. Lista de versiones vivas
^ xx T e s t C a s e s s e le c tio n
3 All th e te s ts
* S t e s t s .T e s tI
3 testG o F o rw ard
3 testG oB ack
0 F ull T e s t s 0 E x e c u te f i r s t w ith J U n it
@ V e r s io n o r ie n t e d
O T e s t C a s e o r ie n te d OK ( C ancel
E x e c u ti n g m u t a n t v e r s i o n s
16%
( C ancel )
que un muante est herido cuando un caso de prueba ha pasado por l pero no ha
conseguido matarlo), matriz de tiempos de ejecucin y alguna informacin
adicional.
m
Total killed m utants
versions mutants ror uoi Inc idee swa i aor
2 0 8 /5 SO 208/550 87/236 74/106 8/12 8/10 8/11 18/56
-
Percentage
versions mutants ror uoi Inc idee sva i aor
37.818 37.818 36.868 69.818 66.668 80.08 72.728 32.14
IS
Killing matrix
Version tests.Testl _te*tGoFemrard tests.Testl_tstCoBack
version249 X rj
version248 X 1
verstor247 O O *
version246 X ii;
Time execution matrix (milliseconds)
Version tests.Testl_testCoForward tests.Testl testCoBack
verskm249 831 nr
vetston248 168 i? i
versfcm247 231 242 W-
versk>n246 67
E xtra n fo m ato n
Figura 7.28. Resultados de la ejecucin. De izquierda a derecha: versiones vivas (alive), heridas
(alive covered) y muertas (died)
versiones mutantes. Bacterio detecta esta aleatoriedad ejecutando dos veces los
casos de prueba contra el sistema original; entonces, deja de comparar, para
detectar los mutantes muertos, las porciones del sistema afectadas por el azar. Pero,
por otro lado, existen casos de prueba que pueden incluir valores aleatorios, que
tambin mataran fcilmente a todos los mutantes, sin que ello signifique que la
calidad del test suite sea alta. En estas situaciones. Bacterio calcula el riesgo de los
casos de prueba aleatorios e informa de ellos al usuario, preguntndole si desea
ejecutarlos en una ventana como la mostrada en la Figura 7.29.
T h e n e x t t e s t c a s e s h a v e b e e n f o u n d w ith r a n d o m n e s s .
P le a s e , d e s e le c t t h e t e s t c a s e s th a t y o u d o n n o t w a n t t o e x e c u te
T h e r a n d o m n e s s in t e s t s c a n p r o d u c e v a ria tio n in t h e m u ta tio n s c o re , s o tw o e x e c t i o n s o f t h e s a m e
m u ta n t s w ith t h e s a m e t e s t s c a n p r o d u c e tw o d iff e re n t m u ta t io n s c o r e s . A ls o , r a n d o m l e s s c a n
p r o d u c e t h a t a t e s t k ills all t h e m u ta n t s .
<$,% r a n d o m ie s s . Low ris k .
S% - 10% r a n d o m le s s . A c c e p ta b le ris k .
> 5 0 % r a n d o m n e s s . N o a c c e p t a b le ris k .
0 AB th e a c ce p ta b le risk tests
CKD
Figura 7.29. Bacterio informa de la aleatoriedad encontrada en los casos de prueba
* S o u rc e c o m p a r is o n
O r i g in a l s o u r c e c o d e M u ta n t s o u r c e c o d e
p a c k a g e s u d o k u so fv er.g u i; p a c k a g e su d o k u so lv e r.g u t;
im p o rt ja v a .a w t.R e a a n g le . w npoft j a v a .a w t R ectan g le
im p o rt ja v a .a w t.e v e n tK e y A d a p te r; im p o rt jav a .a w t.e v e n t.K e y A d a p te r;
im p o rt java.aw t.ev en E K ey E v ertt; im p o rt jav a.aw t.ev em .K ey E v ertf
p u b lic c la s s jTFC asilla e x te n d s JT extF ietd p u b lic c la s s JTFC asilla e x te n d s JT extF ieid
{ i
pu b lic JTFCasiBaO (
p u b lic JTFC aslllaO {
initialized; initialized;
) | >
p riv a te void initialized { p riv a te void initialized {
se tB o u n d sn e w R e c tan g le (0 , 0 , 2 4 , 25)); se tB o u n d s(n e w R e c tan g le (0 , 0 . 2 4 . 2 5
a d d K e y 5 te n e r(n e w K eyA dapter) { a d d K e y s te n e r tn e w K eyA dapterO {
final JTFC asilla ihisSO = JTFC asilla.this. final JTFC asilla thisSO = jT F C asilla.this;
s u p e r0 ; super e
s e tT e x tT ) ; s e tT e x tO :
if (getT extO .lengthO > 1) if g etT e x tj.le n g th O > 1)
setTextT*); s e tT e x tC ) ;
}
p u b lic String toStringO { p u b lic String toStringO I
r e tu r n g etT extf); r e tu rn getT extO ;
}
j M ark a s e q u i v a l e n t
Percentage
versions mutants ro r uo< Inc dec swa aot nut abs
1.46% 1.46% 2.01% 3.12% 0.0% 0.0% 0.0% 0.0% 14.28% 0.0%
Killing matrix
Version rest* Test! tesrtivelnput
version95 O
ve(sior>94 X
version'll 0
version92 X
versions] X
Time execu tio n m atrix (m illiseconds)
Version tests Test l_t.tFivtnput
vers 0095 32 4
versions 4 73
versions 3 21 t
versions? 24
versions 3 20
Extra infom ation
luego puede ser reproducida y lanzada contra los mutantes. Cada escenario de
ejecucin, entonces, conforma de este modo un caso de prueba.
^ E x e c u ti n g a v e r s i o n / o r i g i n a d
lava O ptions
A p p l i c a t io n A r g u m e n t s
f Run v e rs io n ;
Java O ptions
El Local node es el que utiliza el tester para crear los mutantes, lanzar
la ejecucin y mostrar los resultados.
RA-MA CAPTULO 7. HERRAMIENTA BACTERIO: MANUAL DE UTILIZACIN 141
Una vez que los nodos remotos estn en ejecucin, se lanza el nodo
fachada, contenido en el fichero facadeNode.jar, que muestra la interfaz que
aparece en la Figura 7.37. Los dos primeros parmetros se refieren,
respectivamente, a la direccin IP y al puerto de escucha de este nodo. El siguiente
parmetro se refiere al algoritmo de distribucin que se utilizar para repartir el
trabajo en los nodos remotos; la zona inferior se utiliza para dar de alta nodos
remotos en el nodo fachada. Respecto de los algoritmos de distribucin. Bacterio
implementa cinco:
D i s tr i b u to r S e rv e r A d d r e s s IP D i s t r i b u t o r S e rv e r A d d r e s s P o rt
A lg o r ith m s
[PEDRO Algorithm - ft
D istribute versio n s - 1
D i s tr i b u ti o n A l g o r ith m s D istribute t e s t c a s e s - 2
Give v ersions o n d e m a n d - 3
Give te s t c a s e s on d e m a n d - A
P arallel N o d e s :
U n used a d d re s s e s U sed a d d re s s e s
{_ < R em ove ;
R e m o v e S e le c te d A d d r e s s e s R e m o v e S e le c te d A d d r e s s e s
IP A d d r e s s ..................................
A dd A d d r e s s
P o rt A d d r e s s
'v S ta rt D i s tr i b u to r S erv er
Una vez que se han lanzado los nodos remotos y que en el nodo fachada se
ha seleccionado el algoritmo de distribucin y se han configurado adecuadamente
el resto de los parmetros, se pulsa Start Distributor Server y se comienza el
reparto del trabajo entre los nodos remotos. Cuando todos los nodos remotos han
terminado las ejecuciones que les han sido encomendadas, los resultados son
devueltos al nodo local (Figura 7.36), de modo que el tester pueda ver los
resultados de la ejecucin.
Captulo 8
AUTOEVALUACIN
8.1 PREGUNTAS
1/24
Un caso de prueba:
2/24
3/24
4/24
a) Each choice.
b) Pairwise.
c) Sentencias.
d) All combinations.
RA-MA CAPITULO 8. AUTOEVALUACION 147
5/24
a) 0-18-36-54-72-90-108-126.
b) 0-18-37-56-75-93-112-149.
c) 0-24-49-83-98-121-147-149.
6/24
7/24
a) R (reachability, alcance).
b) I (infection, infeccin).
c) P {propagation, propagacin).
8/24
a) Una decisin.
b) Una condicin.
c) Un punto de prueba.
d) Una condicin/decisin modificada.
9/24
endif
10/24
11/24
a) 2.
b) 3.
c) 4.
d) 5.
150 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
12/24
a) 4.
b) 6.
c) 7.
d) 8.
e) 9.
RA-MA CAPTULO 8. AUTOEVALUACIN 151
13/24
Considere que una clase Cuenta referida a una cuenta bancaria tiene las
siguientes operaciones: Cuenta (constructor), retirar, ingresar, transferir. Para
generar casos de prueba, el tester ha escrito la siguiente expresin regular:
a) 1.
b) 3.
c) 33= 27.
d) 9.
e) 52.
14/24
Suponga un caso de prueba que maneja una cuenta con un saldo de 300 .
Cules de las siguientes son clases de equivalencia correctas para el importel
15/24
a) 19,20,21,99,100,101.
b) 19,21,99,101.
c) 19,20,100,101.
d) 20,21,99,100.
16/24
De entre las operaciones de una clase, cules son las ms adecuadas para
escribir el orculo de un caso de prueba?
a) Constructores.
b) Mtodos get.
c) Mtodos set.
d) En general, los mtodos que cambian el estado del objeto.
17/24
a) La generacin de mutantes.
b) La ejecucin de los casos de prueba contra los mutantes.
c) El anlisis de resultados.
d) La mutacin de orden superior (high-order mutation) o mutacin de
orden N, siempre que N>1.
RA-MA CAPTULO 8. AUTOEVALUACIN 153
18/24
Original Mutante
if ((A && (B || C)) || !A) if ( (A && (B && C) ) II !A)
x: = z ; x: = z ;
endif endif
19/24
20/24
a) Decisiones.
b) Condiciones.
c) Condiciones/decisiones.
d) Condicin/decisin modificada.
21/24
1 (1, 1, a, false}
2 {1, 2, d, true}
3 {1, 2, b, false}
4 (3, 1, d, false}
5 {3, 1, b, false}
6 {3, 2, a, true}
7 {2, 1, d, false}
8 {2, 1, b, true}
RA-MA CAPTULO 8. AUTOEVALUAC1N 155
a) (2, 2, a, false).
b) (2, 2, d, false).
c) (2, 3, f, true).
d) (3, 1, d, true).
22/24
23/24
a) 8/10.
b) 8/9.
c) 10/10.
d) 8/8.
e) 9/9.
24/24
8.2 SOLUCIONES
1/24
Los casos de prueba deben ser tambin reproducibles, para que se pueda
obtener siempre el mismo resultado, de xito o de fallo, siempre que se ejecute.
Del mismo modo, debe poder ejecutarse tan rpido como sea posible, con
el objeto de minimizar el tiempo y los recursos dedicados al testing. Por ello, entre
otras cosas, se minimizan los test suites con algoritmos voraces o similares: para
conseguir test suites con menos casos de prueba que alcancen los mismos
resultados que el test suite original, respecto a algn criterio de cobertura (vase,
por ejemplo, la seccin 6.5).
2/24
3/24
4/24
D. All combinations.
5/24
B. (0-18-37-56-75-93-112-149).
6/24
7/24
C. P (propagation, propagacin).
8/24
A. Una decisin.
9/24
10/24
11/24
C. 4.
12/24
A. 4.
13/24
D. 9.
14/24
15/24
16/24
B. Mtodos get.
17/24
Por otro lado, la respuesta que se ofrece como opcin D no tiene ningn
sentido en esta pregunta.
18/24
19/24
D. (tc2, tc4).
20/24
D. Condicin/decisin modificada.
21/24
Como se ve en la tabla de pares que nos muestran, falta por visitar el par
(2, 2) de la tabla de los parmetros A y B. Por tanto, podemos descartar las
opciones C y D: la C porque el par (2, 3) no existe (el 3 no es un valor del segundo
parmetro); el (3, 1, d, true) porque vemos enseguida que visita tres pares ya
visitados: (3, 1), (3, d) y (1, d) por el caso 4; (3, true) por el caso 6; y (d, true) por
el caso 2.
Los pares visitados por B ya son visitados por los otros casos de prueba: en
el caso 7 se visitan los pares (2, d) de (A, C) y (2, false) de (A, D) y de (B, D); (2,
d) de (B, C) se visita en el caso 3.
De entre las opciones A y B nos quedamos con la A, que visita el par (2, a)
de la tabla (A, C) y el (2, 2) de (A, B).
22/24
23/24
B. 8/9.
24/24
Por tanto, son ciertas las respuestas B y C, con lo que la respuesta correcta
es la F.
INDICE ALFABETICO
Clases de equivalencia.................................. 49
A Clustering......................................................102
Adecuado para la mutacin.........................92 Cobertura...........................................26, 31, 42
AETG........................................................ 75,88 De sentencias............................................. 34
Algoritmo del peine.....................................86 U m bral.......................................................32
Algoritmos aleatorios..................................86 Cobertura de condiciones..............................36
All combinations........................................70,74 Cobertura de condiciones/decisiones.......... 37
Anlisis de cobertura...................................26 Cobertura de decisiones................................ 36
Anlisis de resultados..................................97 Cobertura de estados..................................... 43
Antirandom.................................................84 Cobertura de pares de transiciones...............44
Arcos...........................................................36 Cobertura de secuencia completa.................45
ASM.......................................................... 118 Cobertura de sentencias................................ 34
Automatic Efficient Test Generator............75 Cobertura de transiciones..............................43
Cobertura modificada de
condiciones/decisiones.............................39
B Cobertura mltiple de condiciones...............39
Cobertura pairwise.........................................88
Boundary values..........................................51
Combinacin.................................................. 74
Branches......................................................36
Compiler based............................................ 112
Bytecode........................................... 102,113
Compiler-integration....................................103
Condiciones................................................... 36
c Condiciones R1P.......................................... 103
Condiciones/decisiones................................. 37
Cada eleccin..............................................74 Conjetura de errores...................................... 52
Cada uso......................................................55 Conjunto de prueba....................................... 21
Caja blanca..................................................25 Criterios de cobertura.................................... 31
Caja negra...................................................23 U tilidad......................................................32
Caso de prueba..21, 49, 59, 61,69, 88, 92, 93 Para mquinas de estado......................... 42
Estructura...............................................59 Para valores de prueba.............................54
Exitoso....................................................22 Ctweb.............................................................. 86
Inefectivo................................................99 C U T ................................................................ 24
166 TCNICAS COMBINATORIAS Y DE MUTACIN PARA TESTING DE SISTEMAS... RA-MA
D J
Datos de prueba.................................... 21,93 JODE 119
Datos de salida............................................53
DCC............................................................37
Decision/Condition coverage......................37 L
Decisiones...................................................36 Lasttofirst 109
Defecto........................................................20
Differentoperators..................................... 109
Distancia Hamming.....................................84 M
Dominio de entrada.....................................49
Mquina de estados.........................66, 67, 68
DOOM2.................................................... 119
Mquinas de estado................................... 42,65
Matriz de muertos.................................... 100
E Matriz de mutantes muertos...................... 100
MC/DC........................................................39
Each choice.................................................74 Modelo de trabajo.......................................32
Each use..........................................55, 69, 74 Modified Condition/Decision Coverage.... 39
Efecto acoplamiento....................................97 Multiple Condition Coverage......................39
Ejecucin de casos de prueba......................97 Mutacin
Entidad-interrelacin...................................60 Proceso...................................................97
Equivalente Reduccin de costes...............................99
Mutante..................................................93 Mutacin de orden n ................................. 108
Error............................................................20 Mutacin de orden superior...................... 102
Error-guessing.............................................52 Mutacin selectiva.................................... 101
Esquema entidad-interrelacin....................60 Mutant schemata............................... 103, 113
Estado..........................................................66 Mutante.......................................................92
Vivo...................................................... 106
F Mutante equivalente....................................93
Mutante muerto...........................................92
Fallos artificiales.........................................92 Mutante vivo..............................................92,99
Fixtures........................................................63 Mutantes equivalentes.................................93
Flexible weak mutation............................. 106 Mutation adequate.......................................92
Mutation score................94, 97, 98, 100, 108
Mutation-adequate...................................102
G Myers, B......................................................23
Generacin de mutantes..............................97
N
H N-wise 56, 69
Hamming
Distancia.................................................84
Herramientas de mutacin......................... 111
o
High-order mutants................................... 102 Objetivo de las pruebas
Hiptesis del programador competente...... 97 Objetivo..................................................21
HOM (high-order mutants)....................... 102 Operadores de mutacin..............................94
Orculo........................................... 21,64, 65
Orden n ..................................................... 108
I
Integracin .27
RA-MA NDICE ALFABETICO 167
Setup........................................................... 63
P Strong mutation................................. 104, 112
Pairwise...............................55, 69, 74, 75, 88 SUT............................................................. 19
Pairwise with Restrictions, Order and
Weight................................................... 79 T
Pares de transiciones............................. 44, 69
Particiones de equivalencia........................49 Tabla de pares................ ....................... 81
Peine........................................................... 86 Teardown....................... ........................63
Pesos.......................................................... 81 Test case......................... ....................... 21
Postcondicin............................................. 66 Test data......................... ..................... 21
Problema del tringulo............................... 23 Test suite........................ 21,55, 92, 93,98
Proceso de pruebas......................................34 Test suite reducido......... .......................100
Proceso destructivo.....................................21 Testing exploratorio....... ........................25
Producto cartesiano......................... 71,72, 74 Time-to-market.............. ...................... 115
Programa original.................................. 92, 97 TMAP............................ ........................33
Programador competente............................97 Todas las combinaciones ........................70
PROW........................................................ 79 Todas las tupias.............. ........................56
Pruebas caja blanca.....................................25 Todos los pares.............. ........................55
Pruebas de caja negra................................. 23 Transicin...................... .........................66
Pruebas de integracin................................27 Tringulo........................ ......... 24, 34, 103
Pruebas de recuperacin............................. 28
Pruebas de rendimiento...............................28
Pruebas de resistencia................................ 28 U
Pruebas de seguridad...................................28 Umbral........................................................98
Pruebas de sistema......................................28 Umbral para la cobertura.............................32
Pruebas de unidad...................................... 27 Unidad de prueba........................................27
Pruebas estructurales.................................. 25
Pruebas exhaustivas.................................... 19
Pruebas funcionales.....................................25 V
Pruebas unitarias........................................ 27
PUT............................................................19 Valores de prueba.......................................54
Criterios de cobertura.............................54
Valores lmite.............................................. 51
R Veredicto..................................................... 21
Vivo.......................................................... 106
Ramas..........................................................36
Randommix...............................................109
Reachability.............................................. 103 VY
Reduccin de costes....................................99
R1P............................................................103 Weak mutation.......................................... 104
Web............................................................. 86
s
Secuencia completa .45
Tcnicas combinatorias y de mutacin
para testing de sistemas software
Las pruebas de software son un elemento fundamental para garantizar la calidad de
los sistemas que se construyen. Sin embargo, es frecuente que tanto los gestores como los
desarrolladores, presionados por los plazos de entrega, no las ejecuten con la suficiente
profundidad y no se detecten errores que, a la hora de pasar el sistema a produccin,
evidencien problemas con los usuarios.
En una segunda parte del libro se describen las pruebas mediante mutacin que,
durante aos, han sido objeto de investigacin pero que, ahora, se revelan ya como una
tcnica muy til aplicable a nivel industrial.