Análisis del valor límite en caja blanca automática Generación de prueba

Zhang Zhiqiang* †, Tianyong Wu* † y Zhang Jian*

{zhangzq, wuty, ZJ}@ ios.ac.cn
*Estado clave Laboratorio de Ciencias de la Computación,

Instituto de Software, Academia China de Ciencias

†Universidad de Academia China de Ciencias

Abstracto
La prueba de caja blanca es una técnica efectiva para
generar casos de prueba para proporcionar una alta
cobertura para los programas. Generalmente
seleccionamos varias rutas de ejecución utilizando
alguna estrategia, y generamos un caso de prueba
correspondiente que sigue cada ruta.
Cada ruta de ejecución corresponde a un sub espacio
de entrada limitado por restricciones. Es muy probable
que los valores extremos en estos sub espacios
desencadenen fallas, ya que las restricciones que
limitan los sub espacios de entrada pueden ser
defectuosas. En este artículo, proponemos una nueva
forma de definir los límites de los predicados de
comparación en pruebas de caja blanca, y aplicar
pruebas combinatorias restringidas para cubrir estos
límites con un número reducido de casos de prueba.
Nuestro enfoque puede garantizar que cubra todos los
límites posibles para cada ruta de ejecución
seleccionada, logrando así una cobertura de fallas de
límite alta, mientras que la cobertura estructural original
aún se conserva.
KLEE [6], etc. ) Suele utilizar declaración o cobertura
de sucursales como criterio elemental. Sin embargo, los
resultados experimentales recientes muestran que la
declaración o cobertura de sucursales no pueden ser
tratados como el único criterio para la prueba efectiva,
ya que tienen la capacidad de detección de baja falla en
algunas situaciones [13].
El espacio de entrada de un programa se divide en
varios subespacios por las condiciones de ruta. Cada
subespacio está delimitada por una serie de limitaciones
en su condición de trayecto. Los casos de prueba en el
mismo subespacio tener la misma traza de ejecución,
mientras que los casos de prueba en diferentes
subespacios tienen diferentes trazas de ejecución. Un
tipo frecuente de los problemas es en los límites de
subespacios. El desarrollador puede cometer errores en
las limitaciones, por lo tanto haciendo entradas

Términos del índice: generación de pruebas de caja

blanca, análisis del valor límite
mutación, prueba combinatoria restringida.

I. INTRODUCCIÓN
Las pruebas de software es uno de los enfoques más
adoptadas para garantizar la calidad y la fiabilidad del
software. Especialmente, las pruebas de caja blanca es
una técnica eficaz para generar casos de prueba
basados en estructuras de programas. En los últimos
años, se han propuesto varias técnicas automáticas
para resolver este problema, entre los cuales Ejecución
simbólico (SE) [35] y la ejecución simbólica dinámica
(DSE) [20] son dos enfoques del estado de la técnica.
Por lo general, que atraviesan diferentes rutas de
programa de acuerdo con un criterio de cobertura
estructural dado, y luego recogen las restricciones
simbólicas a lo largo de cada ruta de ejecución. Las
limitaciones de una ruta de acceso corresponden a un
subespacio de entrada, que se resuelve mediante un
solucionador de restricciones para generar un nuevo
caso de prueba. las herramientas existentes de
generación de prueba (como SIMC [33], lindo [30],
 Fig. 2: El espacio de entrada para is_inside_rect

1 bool is_inside_rect (int x, int y) {2

si (x <= 0 || x> = 10) { que debe estar en un subespacio ser dividido en un
3 falso retorno; subespacio mal. Un ejemplo de motivación se muestra
4 }
5 si (y <= 0 || y> 10 / * debe ser> = * /) { en la Figura 1. La función comprueba si un punto 2D (x,
6 falso retorno; y) está en una región rectangular. El programa tiene un
7 }
8 return true; fallo en restricción y> 10, que debería ser y> = 10.
9 } El espacio de entrada de la función se muestra en la
Figura 2. Las líneas continuas son los límites correctos
para el área de rectángulo, y la línea de trazos es el
límite equivocado para y> 10 tal como se aplica en el
s programa. Supongamos que estamos seleccionando de
e entrada dentro del rectángulo. Típicamente en SE o
g DSE, se selecciona una única entrada para cada
u trayectoria generada (subespacio), y cualquier valor
n arbitrario dentro del rectángulo puede ser elegido. Si el
d r valor elegido es el punto e, entonces no se detectará el
o e re fallo. Por esta razón, tenemos que generar casos de
y10=
prueba que cubren los valores límite para detectar los
y= defectos de contorno.
9 análisis de Límites-valor (BVA) es una técnica de
u prueba para la detección de estos defectos de contorno.
n segundo
m La técnica fue utilizada originalmente en las pruebas de
i
y= recuadro negro, y por lo general se asume que las
1 variables de entrada son independientes. Por lo tanto
u d hay algunas dificultades para aplicar BVA a pruebas de
n o do
caja blanca, ya que las condiciones de la trayectoria
X=1 X=9

, (((
por lo general hacer depender las variables entre sí. dirigidos entre dos nodos y cada nodo representa
varios enfoques recientemente, los investigadores han un bloque básico, que es una pieza de línea recta
propuesto aplicar BVA en la generación de pruebas de de código sin ningún tipo de saltos y destinos de
caja blanca [29], [22]. salto.
Volvamos a la figura 2. Al considerar BVA, queremos • generación de la trayectoria: Este paso es un paso
comprobar cada límite del rectángulo. Una forma de iterativo. Se selecciona una ruta del programa de
hacerlo es seleccionar una entrada en cada uno de los CFG en una iteración, y termina hasta que el
límites. Por ejemplo, elegimos puntos a, b, c y d, criterio de cobertura dada es satisfecho.
entonces la salida de d será defectuoso. Sin embargo, • Ruta de viabilidad corrientes y de generación de
el coste de la selección de un punto de datos para cada datos de prueba: Después de extraer una ruta de
límite es relativamente grande. En realidad, la cobertura ejecución de la CFG, tenemos que comprobar su
de todos los cuatro límites se puede lograr mediante el viabilidad, y generar datos de prueba para activar la
uso de sólo dos puntos de datos, ya sea {a, d} o {b, c}, ruta, si es un camino viable. Un método utilizado
ya que un caso de prueba puede cubrir múltiples límites comúnmente para resolver este problema se basa
al mismo tiempo. en la ejecución simbólica y resolución de
En este trabajo, se propone una prueba de caja restricciones [35].
blanca técnica de Gen-ración BVA-conscientes. En B. pruebas combinatorias restringida
primer lugar, se da una nueva definición de las
pruebas combinatorias (CT) tiene como objetivo
condiciones de contorno de predicados de comparación.
A continuación, se utiliza una técnica llamada prueba probar los sistemas parametrizados. El sistema bajo
combinatoria para cubrir estas condiciones de contorno prueba (SUT) se modela como un recuadro negro,
con un número reducido de casos de prueba, al mismo teniendo varios parámetros como entrada, y cada
tiempo conservar la cobertura estructural inicial. parámetro
El resto de este trabajo se organiza como sigue: Sec-
ción II se describen los conceptos y técnicas básicas
utilizadas en nuestro enfoque, incluida la introducción
de generación de pruebas de caja blanca y la prueba
combinatoria limitado. Sección III habla de BVA en las
pruebas de caja blanca. La sección IV describe nuestra
caja blanca técnica de generación de pruebas BVA-
conscientes. Sección V discute temas relacionados con
nuestro enfoque. Sección VI se presentan los resultados
experimentales, y la Sección VII discute el trabajo
relacionado. Por último, llegamos a la conclusión de
nuestro trabajo en la Sección VIII.
II. PRELIMINARES
A. generación de pruebas de caja blanca
generación de pruebas de caja blanca toma el código
fuente como entrada y genera automáticamente una
serie de entradas para poner a prueba el software.
Debido al espacio infinito de la ejecución del software,
se requiere generalmente un criterio de cobertura para
evaluar la calidad de los conjuntos de pruebas.
Generalmente, el procedimiento de generación de la
prueba se puede resumir como la Fig. 3, y contiene tres
pasos clave.
• Conversión: Convertir el código fuente en una
estructura intermedia, como gráfico de flujo de
control (CFG). A CFG se puede tratar como un
gráfico dirigido que consta de nodos y bordes
 2 2 2 2
2 3 3 3
n 3 3 2 1
2 1 1 1
o 3 1 3 2
r 1 2 3 1
3 3 1 2
t 3 1 2 3
e 1 2 2 2
Cober 1 2 1 3
tura
C Camino
Conver F criteri Otra extensión útil para la TC es la siembra. Siembra
sión G o permite al probador para especificar los requisitos de
Generaci
on ¿satis cobertura adicionales como com-plemento a la fuerza
fecho universal, dado t. Esto se realiza dando a varias
? combinaciones de parámetros críticos (también
conocido como semillas), los cuales deben ser
Y probados. El algoritmo de generación de prueba va a
viabilidad ruta generar una matriz de recubrimiento lo más pequeño
Fuente posible para cubrir todas las combinaciones de t-
la comprobación y la prueba
Casos de camino, así como las combinaciones de semillas.
prueba
código III. PRUEBAS EN BLANCO BVA-BOX
generación de los datos BVA se utiliza originalmente como una técnica de
Fig. 3: Un procedimiento común para la generación de prueba de recuadro negro, que normalmente se
la prueba de caja blanca combina con la partición clase de equivalencia (ECP).
ECP se centra principalmente en la partición de los
insumos del programa de acuerdo a sus
tiene varias opciones posibles de valor. Dada la fuerza t,
CT es capaz de generar una matriz que abarca, que comportamientos, mientras BVA se centra en los
cubre todas las combinaciones posibles entre los valores extremos de diferentes particiones.
parámetros t. Típicamente, cuando se utiliza BVA en las pruebas de
CT tradicional asume que todos los parámetros son recuadro negro, para cada límite (por ejemplo, x = 10),
independientes. Sin embargo, en escenarios reales, por necesitamos
lo general hay restricciones sobre los parámetros. Un
caso de prueba violar las restricciones de parámetros
no será válida y no puede ser ejecutado. Al generar
casos de prueba con la presencia de las limitaciones de
los parámetros, el algoritmo de generación de pruebas
CT debe generar casos de prueba solamente válidos y
cubrir tantas combinaciones de parámetros t-manera
como sea posible. Este tipo de limitación consciente de
la TC se llama la prueba limitada combinato-rial.
Aquí damos un ejemplo. Supongamos que estamos
generando una matriz que cubre por un modelo SUT,
que tiene 4 de entrada param-etros p1, pag2, pag3, pag4,
Cada uno tomando valores en {1, 2, 3}. Supongamos
que hay una restricción: “p1 = 1 → p2= 2” . La Tabla I
muestra una matriz que cubre de la fuerza 2. La matriz
cubre todos los posibles pares de valores de los
parámetros, excepto para “p1 = 1 ∧ pag2 = 1” y “p1 = 1 ∧
pag2 = 3” , que viola la restricción.
TABLA I: Un ejemplo que cubre array
pag pag pag
1 pag2 3 4

3 2 1 3
un valor muy por debajo del límite (x =-100), un valor la restricción 2* x <2, el valor límite es x = 0, sin
justo por debajo del límite (x = 9), un valor justo en el embargo, haciendo la diferencia entre las dos partes ser
límite x = 10, un valor justo por encima del límite (x = 2.
11), y un valor muy por encima del límite (x = 100). Un ejemplo más complejo se muestra en la Figura 4.
En pruebas de caja blanca, BVA y ECP tienen sus Hay dos subespacios resaltados (lleno de puntos y
respectivos homólogos. La estrategia de selección de líneas, respectivamente). Estamos seleccionando
ruta lleva a cabo funciones similares con ECP. El valores de límite para 2x + 3y restricción <18. Para el
espacio de entrada de programa puede ser con-sidered subespacio lleno de puntos, el valor límite es el punto A
para ser dividido en varios subespacios, donde todas = (2, 4), haciendo que la diferencia entre las dos partes
las entradas de cada subespacio tienen la misma ruta sea 2. Para el subespacio lleno de líneas, el valor límite
de ejecución. es el punto B = (4, 3), haciendo que la diferencia entre
Sin embargo, el método de selección de entrada BVA las dos partes ser 1.
utilizado en las pruebas de recuadro negro no se puede En general, para limitar la entrada cerca del límite,
utilizar directamente en pruebas de caja blanca. Esto se podemos
debe a BVA en las pruebas de recuadro negro por lo seleccion
ar una apropiado y restringir la diferencia absoluta
general asume las variables de entrada son
Entre los dos lados para ser más pequeño que o igual a.
independientes, por lo que sólo tiene que concentrarse Sin e
en las variables individuales. En cuanto a BVA en embargo, tal s a veces difícil de encontrar, y el
pruebas de caja blanca, cada subespacio de entrada
está delimitado por varias restricciones, que pueden
hacer las variables de entrada dependiente. Además,
tenemos que generar entradas de contorno para todas
las restricciones de delimitación.
En nuestro trabajo, sólo generan entradas de
contorno dentro de cada subespacio. Esto puede hacer
que ser probada solamente un lado de un borde. Pero el
otro lado se pondrá a prueba al generar entradas de
contorno para otros subespacios. Además, en el
recuadro negro de BVA, un valor muy lejos de los
límites normalmente se necesita. En nuestro enfoque, la
selección de entradas lejos de las fronteras es opcional.
Si tenemos que seleccionar estos valores no límite, el
número de casos de prueba se incrementará.
Aquí nos llamamos expresión booleana atómica en el
camino acondicionar un predicado. Predicados podría
ser variables booleanas, predicados de comparación
(>,≥, <, ≤, =, =), Etc., y no deben contener ningún
operador booleano (como ∧, ∨, ¬, Etc.). En caja blanca
BVA, queremos cubrir los valores límite para los
predicados de comparación.
Un problema con BVA en las pruebas de caja blanca
es cómo definir los límites. Puede que no sea tan fácil
como parece.
A. ¿Qué tan cerca de frontera deben ser los valores
hasta el borde?
El primer reto es que los valores límite pueden tener
diferentes distancias del borde si las variables son
números enteros. Medimos la distancia de una entrada
al borde de un predicado de comparación mediante el
cálculo de la diferencia entre el lado izquierdo y el lado
derecho del predicado. Por ejemplo, para la restricción x
<2, el valor límite es x = 1, por lo que la diferencia entre
los dos lados de la inecuación ser 1; Sin embargo para
 y condición ruta se evaluará como falsa. Kosmatov et al.
2x + 3y = 18 [24] introdujeron varias formas de definir y encontrar los
y=X límites físicos. Los límites físicos pueden tener un
+3
y=x problema cuando se trata de las condiciones del
un
se recorrido con disyunciones. Por ejemplo, supongamos
gu que tenemos condición de trayecto (a> 0) ∨(un≤ 0),
nd y = X - entonces no habrá ningún límite físico.
o 3 2) La determinación de los límites: En nuestro
X trabajo, utilizamos una entrada que está cerca del borde
de un predicado dado y hace que el predicado
Fig. 4: Una ilustración de valores de límite determinar el resultado de la evaluación de la condición
de ruta como un valor límite. El término “determinar” se
segundo origina en el criterio de cobertura GACC [2], que es una
cierto versión de MC / DC (cobertura condición / decisión
fals modificado). Esto significa que
(15) o

segundo = 1
0un
(1, -1)

un = 1
Fig. 5: límite y no de contorno valores de a> 0 ∨ b> 0

solución resultante podría no ser el más cercano a la

frontera. Kosmatov et al. [24] discuten cómo definir los
valores límite mediante el uso vecindario. Sin embargo,
este problema todavía necesita más investigación.
En nuestro trabajo, nos fijamos a 1 para las
comparaciones de números enteros, o un número muy
pequeño de bienes para las comparaciones en coma
flotante. Esto es razonable ya que la mayoría de las
fallas de borde son off-by-one errores (OBOB), que es
un tipo de faltas cuando algún proceso de cálculo utiliza
un valor incorrecto que es 1 más o 1 menos que el valor
correcto.
B. límites o fronteras físicas que determinan
Aunque algunos de entrada puede estar cerca del
borde de un predicado, todavía no puede ser un valor
límite de toda la condición de trayecto. Ver Figura 5.
Supongamos que tenemos condición de trayecto (a>
0)∨(B> 0). Aunque de entrada (a, b) = (1, 5) está cerca
del borde de predicado a> 0, no es un valor límite. Un
valor límite correcto para predicado a> 0 es (a, b) = (1,-
1). Hay dos enfoques posibles: los límites físicos y los
límites que determinan.
1) Los límites físicos: Una forma de encontrar este
tipo de valores límite es la búsqueda de los límites
físicos. Si alguna entrada haciendo que la condición se
evalúa como verdadera ruta, y si se mueve una
pequeña distancia hacia el borde del predicado, la
 TABLA II: determinar una entrada (a> 0) ∨ (B> 0) Definición 2. Para cada off-by-one c mutante de cada
predicado c, definimos la siguiente condición como una
a> 0 b> 0 a> 0 b> 0
(A, b) = (1, -1) cierto falso cierto condición límite:
sustituir a> 0 con
falsa falso falso falso PAG ∧ ¬Pc, c.
TABLA III: Mutantes para predicados de Esta condición límite constriñe la entrada para hacer
comparación P evaluar a verdadero, y también limita c y c para
evaluar a diferentes valores, lo que hace la entrada
Predic 1 2
justo cerca del borde de c, y permite c determinar P.
ado mutante mutante
A <B A <B - A <B + Desde otra perspectiva, esta condición significa que la
A≤B A≤B- A≤B+ entrada debe seguir el camino de la corriente, y seguirá
A> B A> B - A> B +
A≥B A≥B- A≥B+ una trayectoria diferente si predicado c se implementa
UN B como c. Si c es defectuoso y el predicado correcto debe
= UN = B - UN = B +
UN B ser c, un camino defectuoso será detectado por el caso
= UN = B - UN = B +
de prueba correspondiente.
IV. CUBIERTA DE VALORES LÍMITE EN BLANCO-
la evaluación del predicado afecta directamente a la BOX
decisión de la condición de trayecto. Se puede definir PRUEBAS
formalmente como sigue:
En esta sección, describimos nuestro enfoque de la
Definición 1. Supongamos que tenemos una condición aplicación de BVA, preservando el criterio de cobertura
de la trayectoria P, hav-
ING predicados c1, c2,. . . , cnorte. Un τ de entrada hace original. Normal
que los predicados
do1, c2,. . . , cnorte evaluar a bτc1 , bτc2,. . . , bτcnorte Y
permite evaluar P abτP. c predicadoyo se dice para
determinar P bajo τ si conmutación
solamente bτci a ¬bτci afectará a la evaluación de P, es
decir,
segundoτ , bτ,. . . , bτ,. .
. , bτ do do segundoτ
τ do1 τ τrte ⇒
no
do2 τyo PAG
τ .
segundodo1 , bdo2,. . . ,
¬Bdoyo,. . . , bdonorte ⇒ ¬BPAG
Una definición equivalente
para “ci determina P bajo τ”se
que τ debe satisfacer P ⊕ Pci, ¬ci, donde ⊕ es lógica
XOR, y Pa, b es la restricción de la sustitución de todas
las ocurrencias de una en P con b.
Por ejemplo, (a, b) = (1, -1) es un valor de límite de
(a> 0) ∨(B> 0) wrt predicado a> 0. Como se muestra en
la Tabla II, a> 0 se evalúa como verdadera y b> 0 se
evalúa como falsa, y todo el camino condición se evalúa
como verdadera. Si sustituimos a> 0 con datos falsos,
toda la trayectoria de la condición se evaluará como
falsa.
Para generar una entrada de valor de frontera
determinar, utilizamos una restricción para restringir la
entrada en la frontera, y utilizar un solucionador de
restricciones para resolverlo. Supongamos que la
condición de trayecto es P, y c es una de sus
predicados de comparación. c tiene dos off-by-one
mutantes (como se muestra en la Tabla III). Queremos
generar insumos para probar si P tiene un fallo de límite
en c. Proponemos la siguiente definición:
 A. Construcción del Modelo CT
generación de
pruebas de caja Prueba Supongamos que obtenemos una condición de la
blanca combinatoria trayectoria P durante la generación de la prueba de caja
blanca. Cada predicado comparación de P tiene dos off-
Fuente/ Selecci Factible by-one mutantes, como se muestra en la Tabla III.
ón de modela modelo Aquí se requiere cada mutante de cada predicado a
camino do CT CT ser cubierta si es posible. Para ello, para cada c
camino
modelo s mutante de la comparación predicado c, construimos un
parámetro p CTdo que tiene dos valores
Restric
{0, 1}:
ción
Solver • Si pc toma el valor de 0, el límite no necesita ser
cubierto;
• Si pc toma el valor de 1, el valor límite de
necesidad a cubrir, y una restricción ¬Pc, c se
Hormig genera prueba prueba añade al conjunto de restricciones.
ón dora de TC de TC es decir, para cada c mutante de compar-Ison
prueba
Casos s predicado c, se añade el requisito de cobertura de una
de concret Gener
prueba as casos acion combinación de semillas 1-modo que requiera “pdo: 1”
para estar cubierto si es posible. La fuerza que cubre no
necesita ser especificada - todos los requisitos de
Fig. 6: Vista general de nuestro enfoque
cobertura ya se han especificado por las semillas.
Hay limitaciones en este modelo. En primer lugar,
técnicas de generación de prueba de caja blanca toman
todos los casos de prueba deben seguir la trayectoria
la fuente o el modelo de programa como entrada, tratan
de explorar rutas de ejecución para lograr un cierto de la corriente, por lo tanto P está en el conjunto de
criterio de cobertura, y generar un caso de prueba
correspondiente para cada trayectoria. Una forma restricciones.
sencilla de hacer que el conjunto de pruebas también
cubre los valores límite es generar un caso de prueba
para cada condición de contorno para cada ruta,
también conocido como el uso de la estrategia de
elección de base (BC) [1]. Sin embargo, de esta manera
el número de casos de prueba puede ser demasiado
grande.
Un hecho notable es que algunas condiciones de
contorno pueden ser satisfechos al mismo tiempo, lo
que significa un caso de prueba puede cubrir múltiples
límites al mismo tiempo. Para reducir el número de
casos de prueba para BVA, aplicamos una técnica
combinatoria generación prueba llamada AETG-SAT [9].
La visión general de nuestro enfoque se ilustra en la
Figura 6. Nuestro enfoque añade procesos adicionales
después de cada ruta se selecciona en la generación
normal de la prueba de caja blanca. Para cada ruta,
construimos un modelo CT para la condición de ruta, y
el uso de una herramienta de generación de pruebas
CT para generar varios conjuntos de condiciones de
contorno compatibles que pueden ser satisfechas al
mismo tiempo. Por último, estos conjuntos de
restricciones se convierten en los casos de prueba de
hormigón utilizando el solucionador de restricciones. De
esta manera, BVA se puede lograr sin afectar a la
estrategia de selección de la ruta original para el criterio
de cobertura estructural.
Además, para cada c mutante de predicado c, si pc combinaciones de semillas en nuestro trabajo. A
toma el valor de 1, entonces ¬Pc, c debe ser verdad. continuación, el algoritmo trata de generar casos de
A diferencia de que las restricciones CT tradicional,
donde los estafadores straints son estáticas, nuestro prueba para cubrir todas las combinaciones objetivo
trabajo utiliza de forma incremental del manejo de como sea posible. Para la generación de cada caso de
restricción. Mantenemos un conjunto de restricciones, prueba, el algoritmo continúa de una manera codicioso.
que es inicializado como {P}. Cuando alguna asignación
“pc: 1” se hace, una limitación correspondiente ¬Pc, c Se genera casos de prueba candidato M (denotado por
se añadirá a la conjunto de restricciones. τ*) Mediante la asignación de valores a los parámetros
Un hecho importante es que, en muchos casos, las de tiempo que maximiza el número de combinaciones
condiciones de contorno de numerosas limitaciones de destino recién cubiertos. A continuación, se
diferentes pueden ser cubiertos al mismo tiempo. Por lo selecciona el mejor candidato como el siguiente caso
tanto, mediante la aplicación de la TC en este modelo,
de prueba (denotado por τ), lo agrega al conjunto de
podemos cubrir todas estas condiciones de contorno
con un pequeño número de casos de prueba. pruebas T, y elimina todas las combinaciones de
destino recién cubiertos de Π. En nuestro trabajo, el
número
generación de pruebas B. Combinatoria
Después se construye el modelo, el siguiente paso es
generar una matriz que cubre cubre todas las
combinaciones de semillas. Aquí, nosotros usamos una
técnica de generación de pruebas ampliamente usado
CT llama el algoritmo AETG [8]. Cohen et al. propuesto
una versión modificada de AETG llama AETG-SAT [9],
que puede manejar restricciones. El proceso general del
algoritmo AETG-SAT se muestra en el Algoritmo 1.

Entrada: Parámetros de entrada, sus dominios de

valor, limitaciones y requisitos de cobertura
Salida: Prueba reunión de baño T el requisito de
cobertura
1 Inicializar Π como el conjunto de todas las
combinaciones de parámetros especificados
en el requisito de cobertura;
2 mientras que Π = ∅ hacer
3 τ * = Caso de prueba vacía;
4 para i ∈ {1,. . . , M} hacer
5 Generar un nuevo caso de prueba τ,
que satisface las restricciones y cubre
todas las combinaciones descubiertas
en Π como sea posible;
Si τ cubre las combinaciones más al descubierto
6 que τ * entonces
7 τ * = τ;
8 fin
9 fin
10 T T =∪ {τ *};
11 Retire las combinaciones cubiertos por τ * de Π;
12fin
13volver T;
Algoritmo 1: Un algoritmo simplificado AETG-SAT

Durante el proceso de generación de prueba, el

algoritmo de primeros ini-tializes Π como el conjunto de
todas las combinaciones de parámetros necesarios que
se deben tratar como se especifica por el requisito de
cobertura. Llamamos a estas combinaciones
combinaciones de destino, que se especifican por las
 una vez usando P para generar una entrada en el
1 función int (bool w, int x, int y, int z) {2 si subespacio.
(w!) {Return 0; }
C. Un Ejemplo
3 si (x> 1) { Aquí damos un ejemplo para ilustrar cómo funciona
4 si (x <10) { nuestro método. Ver el fragmento de código se muestra
5 si (y> = z) {
en la Figura 7.
6 volver 1;
Supongamos que uno trayectoria generada en la
7 }
8 } generación de la prueba de caja blanca alcanza la línea
9 } 6. La condición de la trayectoria P es
10 volver 2;
11 } w ∧ x> 1∧ x < 10∧ y ≥ z,
y tiene los siguientes predicados:
Fig. 7: Un fragmento de código ejemplo
{W, x>1, x <10, y ≥ z}
TABLA IV: generada modelo CT
El modelo CT generada es como se muestra en la
Predicad Tabla IV. Tenga en cuenta que en las condiciones de
o parámetros Condiciones para trayecto contorno, los predicados subrayados son reemplazados
d
o pagdo Valores mutado PAGc, c por sus mutantes.
w N/A N/A N/A
x> 1 pagx>2 {0, 1} w ∧ x> 2 ∧ x < 10∧ y ≥ z 1El algoritmo original utiliza M = 50, lo que hace que
pagx>0 {0, 1} w ∧ x> 0 ∧ x < 10∧ y ≥ z sea más posible encontrar mejores casos de prueba,
pagx <11 con el fin de reducir el tamaño final de pruebas. Dado
x < 10 {0, 1} w ∧ x> 1∧ x < 11 ∧ y ≥ z que nuestro modelo TC es muy simple, usamos 5 para
pagx <9 {0, 1} w ∧ x> 1∧ x < 9 ∧ y ≥ z reducir el coste computacional.
pagy≥z1
w ∧ x> 1∧ x < 10∧ y ≥ z +
y z {0, 1} 1
≥
pagy≥z-1 {0, 1} w ∧ x> 1∧ x < 10∧ y ≥ z - 1

de casos de prueba M se fija a 51. Cuando se realiza

alguna asignación, es posible que tenga que comprobar
si una cesión parcial / completa satisface las
restricciones. Por lo tanto, se pasa la cesión parcial /
completa a la restricción utilizado solucionador en la
generación de la prueba de caja blanca, y el
solucionador volveremos si la asignación satisface las
restricciones. Si el resultado no es factible, entonces la
tarea es rechazada, y el algoritmo intenta otro valor para
la asignación. Por favor tome nota de nuestra limitación
gradual pro-cessing como se describe en la Sección IV-
A. Además, algunas combinaciones de objetivo
(condiciones de contorno) nunca pueden estar
cubiertos, ya que entran en conflicto con las
restricciones. generación de pruebas CT garantizará a
cubrir todas las posibles combinaciones de destino.
Después de que los casos de prueba (elección de las
condiciones de contorno) se generan mediante TAC, se
utiliza el solucionador de restricciones para generar una
entrada válida para cada caso de prueba CT. Si no hay
casos de prueba generados CT, significa que todos los
límites no pueden ser cubiertos. En este caso, que
llamamos directamente la restricción solucionador de
 Hay 6 de semillas (destino) combinaciones en total: La generación del segundo caso de prueba es similar,
pagx
pagx>0 : 1, <9 : 1, py≥ z 1 : 1 . por lo que no muestran los detalles. El segundo caso de
pagx prueba es: pagx
pagx>2 pagx>0 : 0, <9 : 1, py≥ z 1 : 0 .
: 1, <11 : 1, z py + 1 : 1, pagx
≥-
pagx>2 : 0, pagyz1 : 0,
El conjunto de restricciones inicial es {PAG}: : 0, <11
≥-
{w ∧ x> 1 ∧ x < 10 ∧ y ≥ z} La combinación cubierto por este caso de prueba se
Aquí establecemos el número de candidatos para retira, por lo que el conjunto de combinaciones
cada caso de prueba como M 1 por simplicidad. restantes de destino es: pagx pagy≥ z
Supongamos que cuando se genera el primer caso de pagx>0 : 1, <9 : 1, 1 :1 .
prueba, la asignación parcial actual es: pagx

px>2 : 1, px> 0: 0. pagx>2

: 1, <11 : 1, pagyz1
: 1,
El conjunto de restricciones actual es: ≥-
No hay más casos de prueba ya que todas las
w ∧ x> 1∧ x < 10∧ y ≥ z, combinaciones de destino restantes no pueden ser
. (1)
¬(w ∧ x> 2 ∧ x < 10 ∧ y ≥ z) cubiertos. Al final, convertimos toda la

Supongamos que el siguiente intento de asignación

es px <9: 1. El algoritmo añade la restricción
correspondiente en el conjunto de restricciones, y
comprueba el satisfacibilidad:
(w∧ x> 2∧ x < 10∧ y≥ z), . (2)
w x> 1 x < 10 y z,
¬ ∧ ∧ ∧ ≥
¬(w ∧ x> 1 ∧ x < 9 ∧ y ≥ z)
Sin embargo, este conjunto de restricciones es
inviable, ya que los dos primeros fuerza de ligadura w ∧
x = 2 ∧ x <10 ∧ y ≥z, que entra en conflicto con la nueva
restricción. Por lo tanto, este intento falla, y px <9 debe
tener valor 0. El conjunto de restricciones se enrolla de
nuevo a (1).
El proceso de asignación restante es como sigue:
• Trate de asignación de px <11 : 1, el conjunto de
restricciones no es factible, por lo que esta
asignación se deshace, y px <11 toma el valor 0;
• Trate de asignación py≥z + 1: 1, el conjunto de
restricciones es factible, por lo que se acepta esta
asignación.
• Trate de asignación de py≥z-1 : 1, el conjunto de
restricciones es-infeasi ble, por lo que esta
asignación se deshace, y py≥z-1 toma el valor
0.
Por último, el caso de prueba TC generado es:
pagx
pagx>0 : 0, <9 : 0, py≥ z 1 : 0 .
pagx

pagx>2
: 1, <11 : 0, z py + 1 : 1,
≥-
Las combinaciones cubiertos por este caso de prueba
se eliminan, por lo que el conjunto de combinaciones
restantes de destino es:
pagx pagy≥ z
pagx>0 : 1, <9 : 1, 1 :1 .
pagx

pagx>2 pagyz1
: 1, <11 : 1, : 1,
≥-
casos de prueba TC en los casos de prueba de mismos predicados. Consideramos que estos
hormigón llamando a la restricción solucionador de predicados compartidos deben tener las mismas
nuevo. intenciones. Por lo tanto, cada límite sólo necesita ser
El primer caso de prueba: probado una vez. Si algún límite de un predicado se
pa z
pagx>0 : 0, px <9 : 0, gy≥ 1 : 0 cubre una vez, lo marcamos como cubiertos, y este
pagx>
límite no necesita ser cubierto por otros caminos.
2 : 1, px <11 : 0, pyz1
: 1, Además, si algún predicado aparece en una condición
≥- de ruta varias veces, todas sus ocurrencias deben ser
⇓ ∧ y≥
(w∧ x> 2∧ x <10 z), considerados en conjunto, y sus mutantes deben
w x> 1 x < 10 y z,
aplicarse simultáneamente.
¬ ∧ ∧ ∧ ≥
¬(w ∧ x> 2 ∧ x < 10 ∧ y ≥ z + 1), C. Sobre solucionadores SMT
⇓ SMT (teorías de satisfacibilidad módulo)
w ∧ X = 2∧ y = 1∧ z = 1; solucionadores se utilizan en la generación de la prueba
El segundo caso de de caja blanca para comprobar camino condición
prueba: satisfacibilidad y generar soluciones factibles. Debido a
z
pagx>0 : 0, px <9 : 1, py≥ 1 : 0
pagx>
sus diferentes estrategias inter-nal, diferentes
solucionadores SMT pueden producir diferentes
2 : 0, px <11 : 0, z py + 1 : 0,
soluciones factibles. Algunos solucionadores SMT son
≥-
más propensos a
¬(w ∧ x> 1 ∧ ⇓x < 9 ∧ y ≥ z,
w ∧ x> 1 ∧ x < 10 ∧ y ≥ z,
⇓
w ∧ X = 9∧ y = 2∧ z = 1.
V. DISCUSIÓN
A. Fallo capacidad de detección
Después de aplicar nuestro enfoque BVA a las
técnicas de generación tradicional prueba de caja
blanca, podemos detectar con eficacia los fallos de
frontera, pero ¿cómo la capacidad de detección de otro
tipo de fallas verse afectada? La respuesta es la
capacidad de detección de fallos para un tipo de fallo
específico aumentará o permanecer sin cambios. La
razón es que si aplicamos nuestro enfoque de la caja
blanca técnica de generación de prueba para cumplir
con un cierto criterio de cobertura estructural, la
estrategia de selección de ruta no se ha modificado, y
que se derivan al menos un caso de prueba para cada
ruta seleccionada. Por lo tanto, nuestra serie de
pruebas también cumple con la cobertura estructural
inicial. Nuestra serie de pruebas puede detectar los
tipos de fallo, que la suite original de prueba puede
detectar. Esto será estudiado en la Sección VI.
B. reducir aún más el costo BVA
El propósito de aplicar a BVA generación de pruebas
de caja blanca es para cubrir los valores de límite con el
menor coste adicional como sea posible. Hemos
utilizado la TC para reducir el número de casos de
prueba. Sin embargo, todavía hay posibles reducciones.
Por lo general, algunos caminos pueden compartir los
producir soluciones cercanas a las fronteras, mientras DC es un criterio de cobertura de los límites lógicos, y
que otros son más propensos a producir soluciones muy ha sido ampliamente investigado [2 ], [7], [17], [19], [21],
lejos de los límites. Mediante la aplicación de nuestra [22], [29], [32]. Los límites para los predicados de
técnica, la cobertura límite se puede aumentar con comparación discutidos en este documento son muy
similares con los límites lógicos. Nuestra definición de
eficacia, independientemente de los cuales solucionador
las condiciones de contorno utiliza el concepto de
SMT se utiliza.
“disuadir-minación”, que está tomada de GACC, que es
D. Complejidad una versión de MC / DC. MC / DC requiere para cada
El cálculo de AETG-SAT es muy ligero, mientras que cláusula en una decisión, existe un par de entradas que
la mayor parte del tiempo se dedica a la comprobación tienen valores diferentes en la cláusula y los mismos
de la viabilidad de las asignaciones de parámetros. Aquí valores para todas las demás cláusulas y tomar la
medimos la complejidad mediante la estimación de la decisión se evalúan a diferentes resultados. En el
cantidad de llamadas solucionador para cada ruta. trabajo futuro, vamos a buscar posibles extensiones
Supongamos que el número de predicados de para MC / DC.
comparación en P es n. El número de mutantes será 2n.
Así, el número máximo de casos de prueba es 2n, y el VI. EVALUACIÓN
número máximo de solucionador de llama para cada Para evaluar nuestro enfoque, se seleccionaron
caso de prueba es 2 M n (aquí M es el número de varios programas utilizados en la literatura existente.
candidatos en el algoritmo 1). Por lo tanto, el peor caso Las descripciones de estos programas sujetos se
de complejidad para cada ruta es 4M n2llamadas Solver. muestran en la Tabla V.
En el mejor de los casos, no hay condiciones de
contorno pueden ser cubiertos. El costo de la
determinación de la inviabilidad de todas las
condiciones de contorno es 2n, y luego el solucionador
se llama de nuevo para generar una prueba para la ruta,
por lo que el número total de
solucionador llamadas sean 2n + 1. En una palabra, el
número de llamadas solucionador de cada ruta es 2n +
1 ~ n2 4M.
fallas múltiples límites E. ON
En nuestro trabajo, asumimos que las fallas de borde
son inde-pendiente. Sin embargo, es posible que
múltiples fallos de contorno se correlacionan entre sí.
Supongamos que tenemos condición de trayecto (a>
0)∨(A> 0), y los dos predicados no se consideran como
el mismo, a continuación, la mutación de cualquiera de
los dos predicados para a> 1 no va a cambiar la
semántica. Por lo tanto ningún valor límite puede ser
generada por un mutante> 1. Sólo mediante la mutación
de los dos al mismo tiempo va a cambiar la semántica, y
el valor límite se puede generar. Sin embargo, cuando
la condición camino tiene muchos predicados, es
extremadamente difícil determinar qué predicados de
mutar de forma simultánea, ya que debemos tener en
cuenta todas las combinaciones de mutaciones
simultáneas.
F. Relación con límites lógicos
Hay un montón de trabajos centrados en la cobertura
de lógica, como la cobertura condición, la cobertura de
decisiones y la condición modificada / cobertura de
decisión (MC / DC), entre las cuales la cobertura MC /
 TABLA V: programas experimentales encontrado que la mayor parte del tiempo adicional se
destina a la resolución de restricciones. Las mejoras
Nombre Descripción
abdominales Valor absoluto que se describen en [9] AETG-SAT se pueden utilizar
Convertir la fecha especial en una para reducir el número de solucionador de llama de
calDate [18] fecha juliana
complexCheck Un programa personalizado con una manera significativa.
[18] lógica compleja
Encuentra el número del medio entre Utilizamos pruebas de mutación para estudiar la tasa
findMiddle [18] los tres números de detección de fallos de equipos de prueba. En primer
ESAÑOBISIEST
O Determinar si un año es un año bisiesto lugar, se inyectan varios fallos (sembrado) en cada
triType [31] El tipo de un triángulo
Un programa de aviones programa. Cada falla sin semillas produce una versión
spaceManage proporcionado por nuestro socio de la defectuosa. Para cada programa y equipo de prueba, se
[32] industria
Calcular la siguiente fecha del día corre todo el equipo de prueba en cada versión
nextDate [3] dado
Una tarjeta popular juego Mostrar defectuosa, y contar el número de mutaciones muertos.
showHand [32] mano Aquí se inyectan dos conjuntos de mutaciones: el primer
sistema de evitación de colisión
ATC [11] Aircraft grupo se compone de off-by-one errores (OBOB, en el
que / menos 1 al lado derecho de los predicados de
comparación) y off-by-muchos errores (OBMB, donde
Para estudiar la eficacia de nuestro enfoque BVA, que
añadimos / restar un valor al azar de 2 a 1000 al lado
Gener-ATED 4 series de casos de prueba, con el fin de
derecho de los predicados de comparación) que son
comparar su tasa de detección de fallos límite. El caso 4
generados por el uso de un awk elaborado
de prueba conjuntos son:
manualmente2guión; el segundo conjunto es generado
• C1: Sólo cobertura de sucursales;
por la herramienta de generación de mutación Milu
• C2: aplicar el método BVA por Jamrozik et al. [22]
de cobertura de sucursales. Aquí un caso de 2 http://www.gnu.org/software/gawk/
prueba individual es
generado para cada condición de contorno, es
decir, usando la base
elección estrategia (BC) [1];
• C3: aplicar nuestro método BVA cobertura de
sucursales, pero no use CT para reducir el número
de casos de prueba. Aquí se utiliza la estrategia de
elección de base (BC);
• C4: aplicar nuestro método BVA cobertura de
sucursales, y el uso de la TC para reducir el
número de casos de prueba.
En nuestra evaluación, el solucionador SMT tiene
varias opciones: Z3 [27], Yices [12], Boolector [5], CVC4
[4], STP [14]. Nos encapsulados estos solucionadores
en una interfaz uniforme, por lo que podemos utilizar de
forma transparente. La elección del SMT solucionador
no afecta el número de casos de prueba y el número de
llamadas solucionador, pero puede afectar a los límites
cubiertos para C1 y C2, así como el tiempo de
ejecución.
Algunas mediciones de las 4 series de ensayo se
muestran en la Tabla VI. Podemos ver que el número
de casos de prueba para los 4 conjuntos de prueba
sigue C1 <C4 <C2 ≈ C3. C2 y C3 tiene alrededor de 3 a
10 horas de las llamadas solucionador comparación con
C1 y C4 tiene alrededor de 10 a 50 horas de las
llamadas solucionador en comparación con C1, es
decir, C1 <C2 ≈ C3 <C4. El tiempo de generación de
prueba sigue C1 <C2 ≈ C3 <C4. Aunque C4 requiere
relativamente más llamadas solucionador y el tiempo de
ejecución más largo, pero todavía es aceptable. Hemos
 TABLA VI: Las mediciones para diferentes métodos de generación de
prueba
#
# Casos llamadas
de soluciona Tiempo (en segundos,
ab prueba dor utilizando Z3)
Programa # P |
#B C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4
abdominales 1 | 1 2 2 2 2 2 5 5 25 0.34 0,361 0,356 0,416
sesen
ta y
calDate 10 | 6 7 20 20 14 19 55 cinco 1029 0,614 0,723 0,759 4.159
complexChe dieci
ck 13 | 4 5 26 26 séis 8 45 52 1512 0,496 0,619 0.63 5,779
findMiddle 14 | 5 6 28 28 12 10 77 77 1341 0,528 0,749 0,752 5.288
ESAÑOBISIE
STO 4|2 3 8 7 5 4 15 17 230 0,408 0,452 0,454 1.26
triType 17 | 8 8 31 30 14 54 138 142 1316 0,968 1,203 1,208 5,084
dieci
spaceManage 16 | 8 7 31 30 séis 56 121 126 2212 0,948 1.166 1.19 8,963
proxima 13.52
fecha 24 | 10 9 42 42 23 48 162 173 3719 0,893 1,267 1.28 4
mostrar la 14.04
mano 36 | 12 13 74 72 32 24 203 232 3722 0,791 1,443 1,567 1
ATC 37 | 21 10 61 55 13 136 266 325 2918 1,826 2,282 2,466 12.5
un #P: número de predicados;
segundo #B: número de instrucciones de salto condicional.

OBOB, la tasa de detección de fallos es relativamente

mayor que la Tabla VIII.
[23], y contiene varios tipos de fallos. En nuestros
Al comparar diferentes solucionadores, podemos ver
experimentos, 8 tipos de fallos se inyectan por Milu,
que diferentes tienen diferentes solucionadores de
como se muestra en la Tabla VII (otros tipos de fallos en
Milu no son aplicables a los programas sujetos). salida / ruta mata en C1. Los casos de prueba
Utilizamos dos maneras de determinar si un fallo se generados por Boolector y STP son menos propensos a
mató: ser valores límite. Para C2, C3 y C4, que son BVA-
• kill de salida: al menos un caso de prueba tiene una conscientes, los casos de prueba generados por
salida diferente con la versión correcta; diferentes solucionadores tienen casi la misma
• Sendero de muertes: al menos un caso de prueba probabilidad de ser valores de límite.
tiene una ruta de ejecución diferente con la versión Tabla X y en la Tabla XI muestran el grado de
correcta. eliminación de las faltas inyectadas por Milu, que se
Los resultados se muestran en la Tabla VIII-XI. Tabla clasifica por diferentes tipos de fallos. Cada celda
VIII y Tabla IX muestran el número de muertes de salida muestra la tasa de detección de fallos media de los
y la ruta de mata por OBOB y OBMB respectivamente. cinco solucionadores (a excepción de los casos en que
Por favor, comparar los resultados entre las columnas. el programa ha Modulo operadores que Yices y
Por ejemplo, en la Tabla VIII, la entrada en triType: C1: Boolector no soportan).
Boolector es “15 | 17”, y la entrada en triType: C4: A partir de la Tabla X y XI tabla, podemos ver que el
Boolector es “28 | 31”. Esto significa que el conjunto de grado de eliminación de salida / ruta de acceso para
pruebas en C4 tienen 13 (28-15) más mata de salida y diferentes tipos de fallos varía. Los siguientes factores
pueden afectar a la tasa de muerte de salida /
14 (31-17) más camino mata de C1. Para Yices y
trayectoria.
Boolector, los resultados para ESAÑOBISIESTO y
A: Algunos fallos de este tipo son irrelevantes para
nextDate no están disponibles, ya que han modulo
los fallos de contorno. En este caso, el número y la
operadores de los cuales los dos solucionadores no son
diversidad de
compatibles.
A partir de la Tabla VIII se puede observar que C1
tiene la peor tasa de muerte / ruta fuera puesto. C2 es
relativamente mejor. C3 y C4 tienen la mejor tasa de
muerte de salida / ruta. En una palabra, la tasa de
detección de fallos de OBOB sigue C1 <C2 <C3 ≈ C4.
Los resultados de la Tabla IX también muestran que la
tasa de detección de fallos para OBMB sigue C1 <C2
<C3 ≈ C4. Desde OBMB es más fácil de detectar que
 software, mientras que el código fuente está disponible.
TABLA VII: fallo de tipos inyectadas por Milu y factores En concreto, la forma de generar los datos de prueba
que afectan el grado de eliminación de salida / con alta cobertura y alta capacidad de detección de
trayectoria fallas es una de las cuestiones más importantes de las
Nombre Descripción factores pruebas de caja blanca. la generación manual de los
abdom conjuntos de pruebas difícilmente puede lograr una alta
inales función abs insersion UN
segun cobertura y es a menudo mucho tiempo. Por lo tanto,
CRCR el reemplazo constante do
OAAN reemplazo de operador aritmético A, B automatizado
si /, mientras que la expresión de la
OCNG negación do
OLLn y / o sustitución A, D
DISCO
S
COMP
y / o la negación del operador y y / o ACTO
OLNG negación del operando S
ORRN reemplazo de operador relacional A, B
operador unario (incremento /
UOI decremento) de inserción A, B

casos de prueba dominan. Sabemos que C2, C3 y

C4 también satisfacen cobertura de sucursales tal
como lo hace C1. Además, tienen más casos de
prueba, así como su diversidad de casos de
prueba es mejor, ya que cada uno de los casos de
prueba cubre específico consolidado-aries. Por lo
tanto, la capacidad de detección de fallos debe
seguir
do1 <C2 ≈ C3 ≈ C4;
B: Algunos fallos de este tipo son relevantes para los
fallos de contorno. En este caso, la capacidad de
detección de fallos debería seguir C1 <C2 <C3 ≈
C4, tal como hemos comentado;
C: El tipo de fallo es grave, y es muy fácil de detectar.
En este caso, la capacidad de detección de fallos
para todos los cuatro conjuntos de pruebas debe
ser muy grande (cerca del 100%), por lo que la
diferencia es insignificante;
D: El tipo de fallo es relevante para fallos lógicos.
Desde nuestra definición de condición de contorno
utiliza el concepto de “determinación” de GACC,
implica unos límites lógicos, por lo tanto la
capacidad de detección de fallos de este tipo de
fallas siga C1 <C2 <C3 ≈ C4;
El grado de eliminación de salida / ruta de acceso
para diferentes tipos de fallos puede verse afectado por
uno o más factores descritos anteriormente, que
también se muestra en la Tabla VII. En general, el grado
de eliminación de salida / trayectoria para C2, C3 y C4
es mayor que C1. Tenga en cuenta que sólo hay 8 tipos
de mutantes en nuestros experimentos. Los efectos
sobre la capacidad de detección de fallos de otros tipos
de fallo necesitan más estudios.
VII. TRABAJO RELACIONADO
pruebas de caja blanca es una técnica de pruebas de
software de uso común para asegurar la alta calidad de
 TABLA VIII: Fallo capacidad de detección de OBOBs inyectados por nosotros
*
# De
Programa mutantes C1 C2
(versiones
defectuosa Yice Boolec Yice Boole
s) Z3 s tor CVC4 STP Z3 s ctor CVC4 STP
abdominales 2 1|2 1|2 0|0 1|2 0|1 1|2 1|2 1|2 1|2 1|2
calDate 20 9 | 10 8 | 10 9 | 9 9 | 10 10 | 10 13 | 14 12 | 14 13 | 15 13 | 14 14 | 15
complexCh
eck 26 12 | 12 10 | 10 8 | 8 10 | 10 9 | 9 24 | 24 21 | 21 14 | 14 16 | 16 17 | 17
findMiddle 28 14 | 16 14 | 16 11 | 11 12 | 14 8 | 10 20 | 24 20 | 24 24 | 28 16 | 20 18 | 22
ESAÑOBIS
IESTO 8 6|6 -|- -|- 4|4 4|4 7|7 -|- -|- 7|7 7|7
triType 34 25 | 25 23 | 25 15 | 17 22 | 22 18 | 18 28 | 28 28 | 29 22 | 24 23 | 24 21 | 21
spaceMana
ge 32 14 | 20 13 | 19 10 | 10 14 | 19 13 | 17 25 | 31 23 | 28 22 | 24 24 | 28 25 | 31
proxima
fecha 48 18 | 28 -|- -|- 13 | 25 14 | 24 26 | 48 -|- -|- 20 | 45 21 | 46
mostrar la
mano 72 55 | 55 53 | 53 43 | 43 55 | 55 56 | 56 65 | 65 57 | 57 60 | 60 59 | 59 60 | 60
ATC 74 41 | 55 38 | 54 25 | 31 40 | 54 30 | 40 41 | 58 40 | 56 47 | 58 40 | 55 38 | 54
# De
Programa mutantes C3 C4
(versiones
defectuosa Yice Boolec Yice Boole
s) Z3 s tor CVC4 STP Z3 s ctor CVC4 STP
abdominales 2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2
calDate 20 19 | 20 18 | 20 18 | 20 19 | 20 19 | 20 19 | 20 18 | 20 18 | 20 19 | 20 19 | 20
complexCh
eck 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26
findMiddle 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28
ESAÑOBIS
IESTO 8 8|8 -|- -|- 8|8 8|8 8|8 -|- -|- 8|8 8|8
triType 34 31 | 31 30 | 31 28 | 31 29 | 31 31 | 31 31 | 31 28 | 31 28 | 31 28 | 31 31 | 31
spaceMana
ge 32 25 | 32 26 | 32 25 | 32 25 | 32 25 | 32 25 | 32 26 | 32 25 | 32 25 | 32 25 | 32
proxima
fecha 48 26 | 48 - | - - | - 20 | 48 21 | 48 26 | 48 - | - - | - 20 | 48 21 | 48
mostrar la
mano 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72
ATC 74 41 | 58 41 | 58 44 | 58 41 | 58 41 | 58 41 | 58 41 | 58 41 | 58 41 | 58 41 | 58
* Cada celda de esta tabla es en forma de “a | b”, donde A es el número de muertes de salida y

b es el número de ruta mata.

TABLA IX: la capacidad de detección de fallos de OBMBs inyectados por
nosotros *
# De
Programa mutantes C1 C2
(versiones
defectuosa Yice Boolec Yice Boole
s) Z3 s tor CVC4 STP Z3 s ctor CVC4 STP
abdominales 2 1|2 1|2 0|0 1|2 0|1 1|2 1|2 1|2 1|2 1|2
calDate 20 14 | 15 13 | 15 13 | 13 14 | 15 15 | 15 16 | 17 15 | 17 16 | 18 16 | 17 17 | 18
complexCh
eck 26 14 | 15 13 | 14 9 | 10 14 | 15 14 | 15 24 | 25 21 | 22 15 | 15 17 | 17 18 | 18
findMiddle 28 16 | 22 15 | 18 11 | 13 13 | 19 9 | 12 23 | 28 23 | 27 24 | 28 20 | 26 19 | 26
ESAÑOBIS
IESTO 8 6|6 -|- -|- 4|4 3|3 6|6 -|- -|- 6|6 6|6
triType 34 26 | 26 24 | 26 16 | 18 23 | 23 18 | 18 25 | 25 26 | 32 20 | 26 23 | 23 20 | 20
spaceMana
ge 32 15 | 20 14 | 19 10 | 10 15 | 19 14 | 19 25 | 31 23 | 28 22 | 24 24 | 28 25 | 31
proxima
fecha 48 18 | 28 -|- -|- 16 | 24 16 | 24 22 | 48 -|- -|- 20 | 44 20 | 46
mostrar la
mano 72 55 | 55 53 | 53 49 | 49 54 | 54 54 | 54 65 | 65 57 | 57 63 | 63 59 | 59 60 | 60
ATC 74 42 | 64 40 | 63 24 | 38 40 | 63 37 | 58 42 | 67 42 | 65 44 | 58 42 | 65 41 | 64
# De
Programa mutantes C3 C4
(versiones
defectuosa Yice Boolec Yice Boole
s) Z3 s tor CVC4 STP Z3 s ctor CVC4 STP
abdominales 2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2 1|2
calDate 20 19 | 20 18 | 20 18 | 20 19 | 20 19 | 20 19 | 20 18 | 20 18 | 20 19 | 20 19 | 20
complexCh
eck 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26 26 | 26
findMiddle 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28 24 | 28
 ESAÑOBIS
IESTO 8 8|8 -|- -|- 8|8 8|8 8|8 -|- -|- 8|8 8|8
triType 34 32 | 32 26 | 32 26 | 32 32 | 32 32 | 32 32 | 32 26 | 32 26 | 32 26 | 32 32 | 32
spaceMana
ge 32 25 | 32 26 | 32 25 | 32 25 | 32 25 | 32 25 | 32 26 | 32 25 | 32 25 | 32 25 | 32
proxima
fecha 48 22 | 48 - | - - | - 20 | 48 20 | 48 22 | 48 - | - - | - 20 | 48 20 | 48
mostrar la
mano 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72 72 | 72
ATC 74 42 | 67 42 | 67 42 | 66 42 | 67 42 | 67 42 | 67 42 | 67 42 | 66 42 | 67 42 | 66
* Cada celda de esta tabla es en forma de “a | b”, donde A es el número de muertes de salida y

b es el número de ruta mata.

Se ha propuesto generación de pruebas de caja blanca
para reducir los esfuerzos humanos. Existen una serie
de enfoques, tales como la ejecución simbólica [35], la
ejecución simbólica dinámica [20] y algoritmos
heurísticos [3]. Sin embargo, la mayoría de ellos no
tienen en cuenta BVA, que es el tema principal de este
artículo.
Hay varias obras relacionadas en la aplicación de
BVA a generación de pruebas de caja blanca. Pandital
et al. [29] propuso un enfoque instrumentación
automatizada, lo que añade varias estatales-mentos
auxiliares para el programa para guiar la estrategia de
selección de ruta para BVA o cobertura de MC / DC. Sin
embargo el código instrumentado puede influir en la
estrategia de selección de ruta. Jamrozik et al. [22]
propuso un método general que se aplica diferentes
estrategias para cada trayectoria generada para generar
conjuntos de pruebas para diferentes propósitos, tales
como BVA, el análisis de mutaciones, la cobertura
lógica, etc. Se centraron en el método general, pero no
discutió a fondo la estrategia de seleccionar casos de
prueba para
BVA. Las entradas generadas pueden no ser
verdaderos valores de límite, y el número de casos de
prueba pueden ser relativamente alta.
pruebas combinatorias se ha estudiado desde hace
muchos años. Se han propuesto muchos métodos de
generación de prueba, como AETG [8] y IPO [26]. que
las restricciones son un aspecto importante en la
generación de pruebas CT. Algoritmos tales como
AETG-SAT [9], PICT [10], CASA [15], [16], IPOG-C [34]
y Cascade [38], [37] se centran en la generación de
prueba con la presencia de restricciones. Más detalles
de los diferentes aspectos de la CT se pueden
encontrar en la lista por Nie y Leung [28] y el libro de
Kuhn et al. [25]. Zhang et al. escribió un estudio
exhaustivo de las técnicas de generación de pruebas
combinatorias [36]. A pesar de todo esto, la aplicación
de la TC es aún limitada a las pruebas de recuadro
negro. Nuestra práctica se combina con éxito la TC en
la generación de pruebas de caja blanca para reducir el
número de casos de prueba al mismo tiempo que
garantiza la cobertura límite.
TABLA X: tasa de muerte de salida (en porcentaje) para las faltas inyectadas por Milu [23]
con diferentes conjuntos de pruebas
tipo abdomin
mutante ales CRCR OAAN OCNG
C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4
abdominales 33 33 33 33 62 70 70 70 100 100 100 100 100 100 100 100
calDate 41 45 48 48 82 86 93 93 94 94 94 94 100 100 100 100
complexC
heck 33 43 51 50 58 77 100 100 46 81 100 100 100 100 100 100
findMiddle 25 53 55 46 - - - - - - - - 100 100 100 100
ESAÑOBI
SIESTO 25 25 25 25 70 82 95 95 44 58 78 78 100 100 100 100
triType 35 44 45 39 88 90 93 89 76 83 87 84 100 100 100 100
spaceMana
ge 27 39 38 38 71 97 97 97 85 100 100 100 100 100 100 100
proxima
fecha 27 30 30 30 41 47 47 47 56 56 56 56 100 100 100 100
mostrar la
mano 44 49 50 50 74 79 100 100 63 68 81 81 100 100 100 100
ATC 26 30 30 27 53 59 57 57 52 62 60 50 72 82 81 81
tipo
mutante OLLn OLNG ORRN UOI
C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4
abdominales - - - - - - - - 64 60 60 60 67 67 67 67
calDate 20 95 100 100 100 100 100 100 72 78 88 88 62 70 71 71
sese
nta y
complexC cinc
heck 73 93 100 100 100 100 100 100 o 73 83 83 45 73 79 79
findMiddle 84 89 89 89 92 100 100 100 59 85 94 94 82 89 90 90
ESAÑOBI
SIESTO 100 100 100 100 89 100 100 100 63 75 85 85 69 88 88 88
triType 37 66 83 83 100 100 100 100 76 86 86 83 46 59 71 70
spaceMana
ge 25 70 75 75 58 96 100 100 42 66 70 70 40 56 59 59
proxima
fecha 38 38 38 38 50 51 51 51 37 40 40 40 62 76 76 76
mostrar la
mano 38 58 100 100 100 100 100 100 78 84 89 89 80 86 86 86
ATC 44 44 44 44 73 77 75 75 47 51 50 50 31 43 43 42

TABLA XI: tasa de muerte Path (en porcentaje) para las faltas inyectadas por Milu [23] con
diferentes conjuntos de pruebas
tipo abdomin
mutante ales CRCR OAAN OCNG
C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4
abdominales 40 33 33 33 86 100 100 100 100 100 100 100 100 100 100 100
calDate 43 48 50 50 83 89 96 96 94 94 94 94 100 100 100 100
complexC
heck 33 43 51 50 58 77 100 100 46 81 100 100 100 100 100 100
findMiddle 33 62 69 58 - - - - - - - - 100 100 100 100
ESAÑOBI
SIESTO 25 25 25 25 70 82 95 95 44 58 78 78 100 100 100 100
triType 38 46 46 42 92 95 99 99 76 83 87 84 100 100 100 100
spaceMana
ge 31 44 45 44 74 98 100 100 85 100 100 100 100 100 100 100
proxima
fecha 31 46 46 46 63 87 91 91 72 83 100 100 100 100 100 100
mostrar la
mano 44 49 50 50 74 79 100 100 63 68 81 81 100 100 100 100
ATC 45 48 50 46 71 74 76 76 95 100 100 100 100 100 100 100
tipo
mutante OLLn OLNG ORRN UOI
C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4
abdominales - - - - - - - - 80 80 80 80 67 67 67 67
calDate 20 95 100 100 100 100 100 100 74 80 90 90 62 70 71 71
complexC sese
heck 73 93 100 100 100 100 100 100 nta y 73 83 83 45 73 79 79
 cinc
o
findMiddle 100 100 100 100 97 100 100 100 71 89 100 100 83 89 90 90
ESAÑOBI
SIESTO 100 100 100 100 89 100 100 100 63 75 85 85 69 88 88 88
triType 54 77 100 100 100 100 100 100 83 88 88 85 47 60 72 72
spaceMana
ge 42 92 100 100 100 100 100 100 70 86 88 88 49 62 68 68
proxima
fecha 64 100 100 100 99 99 100 100 80 90 92 92 79 81 84 84
mostrar la
mano 38 58 100 100 100 100 100 100 78 84 89 89 80 86 86 86
ATC 100 100 100 100 100 100 100 100 74 76 78 78 47 58 60 60

VIII. CONCLUSIÓN casos de prueba en otras técnicas de generación de

El software es generalmente problemática en las
entradas extremas, valores límite aka. análisis de valor
límite (BVA) se centra en software control de los valores
de límite para detectar defectos potenciales. Esta
técnica se utiliza generalmente en las pruebas de
recuadro negro. Sin embargo también hay una
necesidad de BVA en las pruebas de caja blanca. En
nuestro trabajo, hemos propuesto una nueva definición
de las condiciones de contorno basado en la mutación y
dio una nueva estrategia de selección de pruebas para
cubrir las condiciones de contorno, mientras que la
cobertura estructural origi-nal es preservada. Se aplicó
la técnica de pruebas combinatoria para hacer que cada
caso de prueba cubre la mayor cantidad posible de las
fronteras, con el fin de reducir el número total de casos
de prueba. Los resultados experimentales muestran que
nuestro enfoque puede lograr una alta tasa de detección
de defectos de contorno, y el número de casos de
prueba se pueden reducir de manera efectiva mediante
la aplicación de CT.
El trabajo futuro incluye: (1) reducir el costo de
restricción solv-ing usando las mejoras de algoritmo
AETG-SAT; (2) descubrir la posibilidad de usar la TC
para reducir el número de
prueba basada en la mutación;
(3) la búsqueda de relaciones de límites predicados de
comparación con los límites lógicos, que se relaciona
con MC / DC, y extender nuestro trabajo a la generación
de pruebas MC / DC si es posible.
RECONOCIMIENTO
Este trabajo está apoyado en parte por el National
Básica Re-búsqueda (973) Programa de China (Nº
2014CB340701), la Fundación Nacional de Ciencias
Naturales de China (Grant No. 91418206, 91118007).
Agradecemos a Cunjing Ge y Feifei Ma por sus útiles
comentarios.
Referencias
[1] P. Ammann, y J. Offutt. “El uso de métodos
formales para derivar los marcos de prueba en las
pruebas de categoría-partición”. En Proc. de la
Novena Conferencia Anual sobre la garantía de
ordenador (COMPASS '94), pp. 69-79. IEEE.
[2] P. Ammann, J. Offutt, y H. Huang. “criterios de
cobertura para las expresiones lógicas”. En Proc.
del 14 Simposio Internacional sobre Ingeniería de
Software Fiabilidad (ISSRE '03), pp. 99-107. IEEE.
 [3] Z. Awedikian, K. Ayari, y G. Antoniol. “Prueba de
generación automática de datos de entrada MC /
DC”. En Proc. de la 11ª Conferencia Anual sobre
Genética y Evolutionary Computation (GECCO '09),
pp. 1657-1664. ACM.
[4] C. Barrett, CL Conway, M. Deters, L. Hadarean, D.
Jovanovic, 'T. King, A. Reynolds, y C. Tinelli.
“CVC4”. En Proc. de la 23ª Conferencia
Internacional de Verificación Asistida por Ordenador
(CAV '11), pp. 171-177. Springer Berlin Heidelberg.
[5] R. Brummayer, y A. Biere. “Boolector: Un
solucionador SMT eficiente para vectores de bits y
matrices”. En Proc. de la 15ª Conferencia
Internacional sobre Herramientas y algoritmos para
la Construcción y Análisis de Sistemas (TACAS
'09), pp. 174-177. Springer Berlin Heidelberg.
[6] C. Cadar, D. Dunbar y D. Engler. “KLEE:
Generación automática y sin ayuda de pruebas de
alta cobertura para los programas de sistemas
complejos”. En
Proc. de la 8ª Conferencia USENIX en los sistemas
operativos Diseño e Implementación (IESO '08), Pp.
209-224.
[7] JR Chang y Huang CY. “Un estudio de mayor
criterio de cobertura MC / DC para las pruebas de
software”. En Proc. de la 31 Conferencia Anual
Internacional de Software y aplicaciones
informáticas (COMPSAC '07), pp. 457-464. IEEE.
[8] DM Cohen, SR Dalal, ML Fredman, y GC Patton. “El
sistema AETG: Una aproximación a las pruebas
basadas en el diseño combinatorio”.
IEEE Transactions on Software Engineering, 23 (7):
437-444, 1997.
[9] MB Cohen, MB Dwyer, y J. Shi. “La construcción de
bancos de pruebas de interacción para sistemas
altamente configurable en presencia de
restricciones: Un enfoque codicioso”. IEEE
Transactions on Software Engineering, 34 (5): 633-
650, 2008.
[10] J. Czerwonka. “Las pruebas por parejas en el
mundo real”. En Proc. de la Conferencia sobre la
calidad del noroeste del Pacífico de software 24
(PNSQC 06), pp 419-.
430.
[11] H. Do, S. Elbaum, y G. Rothermel. “Apoyando
controlada experi-mentación con técnicas de
ensayo: Una infraestructura y su impacto potencial”.
Empírica Software Engineering, 10 (4): 405-435,
2005.
[12] B. Dutertre y L. de Moura. “A solver lineal-aritmética
rápido para DPLL (T)”, en Proc. de la 18ª
Conferencia Internacional de Verificación Asistida
por Ordenador (CAV '06), pp. 81-94. Springer Berlin
Heidelberg.
[13] C. Fang, Z. Chen, y B. Xu. “Comparación de los
criterios de la lógica de cobertura en caso de
priorización de prueba”. Ciencias de China Ciencias
de la Información, 55 (12): 2826-2840, 2012.
[14] V. Ganesh, y DL Dill. “Un procedimiento de toma de
vectores de bits y matrices”. En Proc. de la 19ª
Conferencia Internacional de Verificación Asistida
por Ordenador (CAV '07), pp. 519-531. Springer
Berlin Heidelberg.
[15] BJ Garvin, MB Cohen, y MB Dwyer. “Una búsqueda
mejorada meta-heurística para la interacción
limitada prueba”. En Proc. del 1er Simposio
Internacional sobre búsqueda basada en Ingeniería
de Software (SSBSE '09), pp. 13-22. IEEE.
[16] BJ Garvin, MB Cohen, y MB Dwyer. “Evaluación de
la mejora de una búsqueda de meta-heurística para
la interacción limitada prueba”. Empírica Software
Engineering, 16 (1): 61-102, 2011.
[17] K. Ghani, y JA Clark. “Generación de los datos de
comprobación automático para la condición múltiple
y cobertura MCDC”. En Proc. de la Cuarta
Conferencia Internacional sobre Ingeniería de
Software Avances (ICSEA '09), pp. 152-
157. IEEE.
[18] K. Ghani, Búsqueda de datos de prueba, Tesis
doctoral, Universidad de York, 2009.
[19] S. Godboley, GS Prashanth, DP Mohapatro, y B.
Majhi. “Aumento de la cobertura / Decisión
Condición Modificado utilizando código de programa
trans-ex”. En Proc. de la 3ª Conferencia
Internacional IEEE Avance Computing (IACC '13),
pp. 1400-1407. IEEE.
[20] P. Godefroid, N. Klarlund y K. senador “DART:
automática dirigida Pruebas al Azar”. En Proc. de la
Conferencia ACM 2005 SIGPLAN en Lenguaje de
Programación Diseño e Implementación (PLDI '05),
pp. 213-223. ACM.
[21] KJ Hayhurst, DS Veerhusen, JJ Chilenski, LK
Rierson, “Un práctico tutorial sobre la cobertura de
la condición / decisión modificado”. Informe Técnico,
la NASA / TM-2001-210876. NASA, 2011.
[22] K. Jamrozik, G. Fraser, N. Tillman, y J. de Halleux. Conferencia Interna-cional de software de seguridad
“Generación de pruebas con la ejecución simbólica y fiabilidad (SERE '14), pp. 118-126. IEEE.
dinámica aumentada”. En Proc. de la 7ª [33] Z. Xu, y J. Zhang. “Una herramienta de generación
Conferencia Internacional Análisis y pruebas (TAP de datos de prueba para pruebas unitarias de los
'13), pp. 152-167. Springer Berlin Heidelberg. programas en C”. En Proc. de la Sexta Conferencia
[23] Y. Jia, y M. Harman. “MILU: A, personalizable Internacional sobre la Calidad del Software (QSIC
herramienta de prueba de tiempo de ejecución '06), pp. 107-116. IEEE.
optimizada de orden superior mutación para el [34] L. Yu, Y. Lei, MN Borazjany, RN Kacker y DR Kuhn.
lenguaje C completa”. En Proc. de la tercera “Un algoritmo eficiente para el manejo de la
prueba: académico e industrial Conferencia - generación de la prueba combinatoria restricción”.
Práctica y Técnicas de Investigación (STIC PARTE En Proc. de la Sexta Conferencia Internacional
'08), pp 94-98.. IEEE. IEEE sobre las pruebas de software, verificación y
[24] N. Kosmatov, B. Legeard, F. Peureux, y M. Utting. validación (ICST '13), pp. 242-251. IEEE.
“criterios de cobertura frontera para generación de [35] J. Zhang, X. Chen, y X. Wang. “Generación de
pruebas de los modelos formales”. En Proc. del 15 datos de prueba orientado al trayecto mediante la
Simposio Internacional sobre Ingeniería de Software ejecución simbólica y restricción de las técnicas de
Fiabilidad (ISSRE '04), pp. 139-150. IEEE. resolución”. En Proc. de la Segunda Conferencia
[25] DR Kuhn, RN Kacker., Y. Lei. Introducción a Internacional sobre Ingeniería de Software y
pruebas combinatorias. Chapman y balcón / CRC, Métodos Formales (SEFM '04), pp. 242-250. IEEE.
Londres, Reino Unido, 2013. [36] J. Zhang, Z. Zhang, y F. Ma. Generación automática
[26] Y. Lei, R. Kacker, DR Kuhn, V. Okun, y J. Lawrence. de combinatoria de datos de prueba. Springer Berlin
“IPOG / IPOG- Heidelberg, 2014.
D: generación de pruebas eficientes para la prueba [37] Z. Zhang, J. Yan, Y. Zhao, y J. Zhang. “Generación
combinatoria de múltiples vías”. Soft-ware de de banco de pruebas combinatorio de optimización
prueba, verificación y Fiabilidad, 18 (3): 125-148, combinatoria”. Diario de sistemas y software, 98:
2008. 191-207, 2014.
[27] L. de Moura, y N. Bjørner. “Z3: Un solucionador [38] Y. Zhao, Z. Zhang, J. Yan, y J. Zhang. “Cascade:
SMT eficiente”. En una herramienta de generación de pruebas para las
Proc. de la 14ª Conferencia Internacional sobre pruebas de combinatoria”. En Proc. de la Sexta
herramientas y algoritmos para la Construcción y Conferencia Internacional IEEE sobre pruebas de
Análisis de Sistemas (08) TACAS, Pp. 337-340. software, verificación y validación Talleres (ICSTW
Springer Berlin Heidelberg. '13), pp. 267-270. IEEE.
[28] C. Nie, y H. Leung. “Un estudio de la prueba
combinatoria”. ACM Computing Surveys, 43 (2): 11,
2011.
[29] R. Pandita, T. Xie, N. Tillmann, y J. de Halleux.
“Generación de pruebas guiada por criterios de
cobertura”. En Proc. de 2010 Conferencia
Internacional IEEE sobre mantenimiento de
software (ICSM '10), pp. 1-10. IEEE.
[30] K. Sen, D. Marinov y G. Agha. “LINDA: Un motor de
pruebas Unidad Concolic para C”. En Proc. del 10
de la ingeniería de software con-ferencia Europea
celebrada conjuntamente con el 13 Simposio
Internacional ACM SIGSOFT en Fundamentos de
Ingeniería de Software (ESEC / FSE '05), pp. 263-
272. ACM.
[31] N. Williams, B. Marre, P. Mouy, y M. Roger.
“Pathcrawler: Generación automática de pruebas de
ruta mediante la combinación de análisis estático y
dinámico”. En Proc. de la quinta Conferencia
Europea Dependable Computing en Dependable
Computing (EDCC '05), pp. 281-292. Springer Berlin
Heidelberg.
[32] T. Wu, J. Yan, y J. Zhang. “Prueba automática de
generación de datos para las pruebas unitarias para
lograr MC / DC Criterio”. En Proc. de la Octava