Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Tema 2. ValidaciónAnálisis, Validación y Depuración (AVD)
Germán Vidal, Alicia Villanueva
DSIC, ETSInf
Curso 2015-2016
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Objetivos del tema
• Conocer los distintos tipos de prueba que puedenrealizarse.
• Conocer el impacto del software testing (automático)en la calidad del software.
• Familiarizarse con los fundamentos para la generaciónautomática de casos de prueba.
• Ser capaz de analizar la calidad de un programa deforma sistemática.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Validación
ValidaciónProceso de revisión que verifica que el sistema de softwareproducido cumple con las especificaciones y que logra sucometido.
• Se llama validación al conjunto de distintas técnicasaplicadas con este fin:• Validación externa• Software testing en distintas fases de desarrollo• Validación informal/manual• . . .
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Validación automática
• La automatización de cualquier proceso permite• tener tiempos de desarrollo más cortos• evitar errores de codificación/manuales en tareas
repetitivas• poder dedicar recursos humanos a tareas más
exigentes
• Software testing automático como parte del proceso devalidación del producto
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Validación automática
Algunos datos que apoyan su necesidad (1/2):Barron 2002 Aproximadamente el 22 % de los PCs y el
25 % de los portátiles fallan cada año, encomparación al 9 % de los VCRs, el 7 % de lasgrandes pantallas de televisión, el 7 % de lassecadoras de ropa, y el 8 % de las neveras.
US 2002 Los defectos de software están costando a laeconomía de EEUU una estimación de 59.5billones de dólares cada año (Estudio federalllevado a cabo por RTI).
Beizer 1990 Del trabajo empleado para desarrollar unprograma que funcione, normalmente el 50 %se utiliza en tareas de testing y depuración.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Validación automática
Algunos datos que apoyan su necesidad (2/2):Hailpern 2002 Las actividades de validación (depuración,
testing y verificación) pueden fácilmenteabarcar desde el 50 % al 75 % del coste totalde desarrollo
Gould 1975 De un grupo de programadoresexperimentados, los tres mejores en tareas dedepuración eran capaces de encontrardefectos en el 30 % de tiempo del empleadopor los tres peores, y cometían solo un 40 %de los errores.
RTI 2002 Los desarrolladores estiman que las mejorasen testing y depuración podrían reducir elcoste de los errores de software en un tercio
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Software Testing
• Proceso de muestreo de las posibles ejecuciones deun sistema de acuerdo a un criterio determinado.
• La idea no es comprobar de forma sistemática todaslas posibles ejecuciones, por lo queno se garantiza la ausencia total de errores.
• Es sin duda el método más utilizado para la mejora decalidad del software.
El software testing tiene como objetivo encontrar errores, nogarantizar su ausencia
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Software testingReglas básicas del software testing (Zeller 2005):
• Especificar: Un programa no puede ser correcto por símismo, lo será con respecto a una especificación quedescriba su objetivo.
• Prueba temprana: No se debe esperar a que esté elsistema desarrollado completamente para probarlo.
• Prueba primero: Escribe los casos de prueba antes deimplementar la unidad de código correspondiente. Los casosde prueba pueden servir como especificación.
• Prueba con frecuencia: Al menos se debe probar con cadaentrega del software. Lo ideal es probar con cada cambiodel programa (automatización).
• Prueba suficiente: Mide la cobertura de las pruebas.
• Que prueben otros: Probar en busca de problemas es unproceso destructivo. Una persona independiente será másobjetiva haciendo las pruebas.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Alcance del testingSe debe probar en distintas fases del desarrollo desoftware:• pruebas unitarias: se prueban pequeños trozos• pruebas de integración: se prueba que distintos trozos
de código (que pueden haber sido desarrollados pordistintos programadores) funcionan bien en conjunto
• pruebas de sistema: se prueba la funcionalidad delsistema
• pruebas de aceptación: el usuario prueba que elsistema cumple con sus necesidades
• pruebas de regresión: se realizan durante la fase demantenimiento, tras haber realizado algún cambio oactualización. El objetivo es comprobar que el sistemasigue cumpliendo con la funcionalidad anterior.
• pruebas de estrés: se prueba el sistema bajocondiciones extremas.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Técnicas de testing
• Pruebas de caja blanca (o transparente): se depurainspeccionando los detalles internos del sistema (elcódigo).
En este contexto es posible analizar los caminos deejecución: secuencias de puntos de control einstrucciones que aparecen en el código.
• Pruebas de caja negra: no tiene acceso al código delprograma, por lo que usa la información conocida através de la interfaz del sistema.
Para las pruebas tempranas (unidad o integración) sueleseguirse la técnica de caja blanca, mientras que para laspruebas de aceptación es más común seguir la técnica decaja negra.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Cobertura
Un programa puede tener un número infinito (o muygrande) de caminos de ejecución
CoberturaLa cobertura mide la cantidad de posibles ejecuciones quehan sido analizadas tras la ejecución de un conjunto decasos de prueba
• No podemos testear todos los caminos• Se hace un análisis de cobertura para garantizar una
alta cobertura• Existen distintas formas de medir la cobertura. Son los
criterios de cobertura• Si la prueba resulta positiva con una cobertura alta
indica una satisfacción alta con el sistema.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Cobertura
Criterio de coberturaCriterio que permite definir conjuntos de ejecucionesposibles de forma que las ejecuciones en un mismoconjunto puede que tengan el mismo error
• IDEA: En la fase de prueba se probará al menos unaejecución de cada conjunto.
• Llamamos a cada ejecución probada caso de prueba.• Cobertura total: cuando se prueba un caso de prueba
por cada conjunto definido por el criterio de cobertura.• Tener cobertura total no garantiza que no hayan
errores en el código.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura
Existen distintos criterios de cobertura.
• Basados en el grafo de control de flujo:• Cobertura de sentencia• Cobertura de arco (también de rama o de decisión)• Cobertura de condición• Cobertura de condición/decisión• Cobertura de condición múltiple• Cobertura de camino
• Basados en el flujo de datos:• Análisis de variables vivas• Se analiza el código hacia atrás• all-defs, all-uses, etc.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (control)
y := y+1
x=y ∧ z>w
x := x-1
true false
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (control)
y := y+1
x=y ∧ z>w
x := x-1
true false
Condición: fórmulade primer orden
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (control)
y := y+1y := y+1
x=y ∧ z>w
x := x-1x := x-1
true false
COBERTURA DE SENTENCIA
• Cada sentencia ejecutabledebe aparecer al menosen un caso de prueba
EJEMPLO
• Caso de prueba:
{x → 2, y → 2, z → 4,w → 3}
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (control)
y := y+1
x=y ∧ z>w
x := x-1
truetrue falsefalse
COBERTURA DE ARCO
• Cada arco el el grafo deflujo de control debeaparecer al menos en uncaso de prueba
EJEMPLO
• Casos de prueba:
{x → 2, y → 2, z → 4,w → 3}{x → 3, y → 3, z → 5,w → 7}
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (control)
y := y+1
x=y ∧ z>wx=y ∧ z>w
x := x-1
true false
COBERTURA DE CONDICIÓN
• Cada componente de unacondición debe serevaluado a true en almenos un caso de pruebay a false en al menos otro
EJEMPLO
• Casos de prueba:
{x → 3, y → 3, z → 5,w → 7}{x → 3, y → 4, z → 7,w → 5}
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (control)
y := y+1
x=y ∧ z>wx=y ∧ z>w
x := x-1
truetrue falsefalse
COBERTURA DEARCO/CONDICIÓN
• Se deben cubrir tanto losarcos como lascondiciones
EJEMPLO
• Casos de prueba:
{x → 2, y → 2, z → 4,w → 3}{x → 3, y → 3, z → 5,w → 7}{x → 3, y → 4, z → 7,w → 5}
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (control)
y := y+1
x=y ∧ z>wx=y ∧ z>w
x := x-1
true false
COBERTURA DE CON-DICIÓN MÚLTIPLE
• Se deben cubrir todas lascombinaciones de valoresde verdad de loscomponentes de unacondición
EJEMPLO
• Casos de prueba:
{x → 2, y → 2, z → 4,w → 3}{x → 3, y → 3, z → 5,w → 7}{x → 3, y → 4, z → 7,w → 5}{x → 3, y → 4, z → 5,w → 6}
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (control)
y := y+1
x=y ∧ z>w
x := x-1
true false
COBERTURA DE CAMINO
• Cada posible caminoejecutable debe estarcubierto por al menos uncaso de prueba
Problema:
• Los bucles puedengenerar un número infinitode posibles caminos
• el código muerto no puedetener un caso de pruebaexitoso
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejercicio
Dado el siguiente fragmento de programa:
read(x);read(y);if x>y ∧ y>0 then w := x-y
else w := x*x
Escribe un conjunto de casos de prueba con el que seobtenga cobertura total según los criterios vistos:• Cobertura de sentencia:• Cobertura de arco:• Cobertura de condición:• Cobertura de arco/condición:• Cobertura de condición múltiple:
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCuestiones prácticas
Algunos aspectos a tener en cuenta:• Cuando consideramos la cobertura de condición (o
condición múltiple), debemos garantizar, además, quela condición se alcanza
• Los bucles los vamos a tratar como condicionales(excepto en la cobertura de camino)
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios basados en control - Resumen
• Los criterios basados en el grafo de flujo de controltienen algunas limitaciones• Aunque obtengamos una cobertura total, pueden haber
errores no detectados (el testing nunca garantiza laausencia de errores)
• Como se usa la estructura interna del programa, laprueba puede estar condicionada: se prueba conrespecto a cómo se ha implementado, no a cómo sedebería haber hecho.
• Es difícil analizar la idoneidad de los criterios decobertura en general. Deberíamos saber cómo es unprograma tipo.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios basados en control - Resumen
• Comparación entre criterios:• Un criterio subsume a otro cuando cobertura total del
primero garantiza cobertura total del segundo. Es decir,el primero es más exhaustivo, a cambio de un costemayor.
cobertura de caminocoberturade condi-
ción múltiple
cobertura de arco/condición
cobertura de arco
coberturade condicióncobertura de
sentencia
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCobertura de bucle
• Ninguno de los criterios anteriores trata bien los bucles(excepto el de camino pero es poco útil en la práctica)
• Existen algunas estrategias ad-hoc para probar bucles:• Probar el caso donde no se entra en el bucle• Probar el caso donde se ejecuta una vez el cuerpo del
bucle• Probar el caso donde se ejecuta un número típico de
veces el cuerpo del bucle• Si se sabe que el bucle tiene un límite de iteraciones n,
probar el caso para n − 1 iteraciones y para n + 1iteraciones
• Todo se complica cuando hay bucles anidados: elnúmero de casos de prueba necesarios puede crecerexponencialmente.• Se renuncia a ser exhaustivo cuando se tienen bucles
anidados
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
CoberturaCriterios de cobertura (datos)
• Se basan en cómo se usan las variables en lassentencias del programa.
• Ejemplo de criterio básico:
Cobertura all-defsPara cada variable x y sentencia s, se incluye un caminoque alcance un nodo s′ en el que se use la variable x (porejemplo su valor es asignado a otra) y s′ es alcanzabledesde s, siendo que en s se define x y que en los nodosintermedios no se redefine x .
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Software testing automático
Tareas del software testing:• Definición de casos de prueba
• Muy costoso• Automatización difícil
• Evaluación de la cobertura• Objetivo: saber la calidad de la prueba• Dado un conjunto de casos de prueba y un criterio,
evalúan la cobertura• Ejecución de los casos de prueba
• Fácil de automatizar, gran variedad de herramientaspara todos los lenguajes
• Gestión de las pruebas• Se pueden mantener distintas versiones de los
conjuntos de casos de prueba• Útil para hacer pruebas de regresión por ejemplo
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Casos de prueba
• Los casos de prueba se puede definir• dando los valores iniciales de las variables para la
ejecución, y/o• especificando el camino de ejecución y/o• dando los valores para la entrada de usuario
de forma que quede completamente especificado elcamino que debe seguir la ejecución.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Casos de pruebaGeneración automática
• Una de las tareas más costosas es la definición decasos de prueba que garanticen una buena cobertura
• Se puede automatizar la definición de esos casos deprueba explorando los grafos de flujo de control/datossiguiendo alguna estrategia
Idea basePara cada camino debe encontrarse una asignación devalores a variables que garantice la ejecución de dichocamino.• Estrategia: propagación de las condiciones que
aparecen en los grafos: path conditions
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación automática decasos de prueba
Técnicas de generación automática de casos de prueba:• Generación aleatoria
• QuickCheck: Generación aleatoria guiada• Generación estática
• basada en ejecución simbólica• Origen en 1976• Evolución y adaptación a lenguajes modernos (ejemplo
Java PathFinder)• basada en mutantes de código (Budd, Lipton, DeMillo y
Sayward, 1980).• Otras aproximaciones:
• basada en concolic execution• basadas en algoritmos genéticos• basadas en minimización de funciones
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación automática decasos de prueba
Técnicas de generación automática de casos de prueba:• Generación aleatoria
• QuickCheck: Generación aleatoria guiada• Generación estática
• basada en ejecución simbólica• Origen en 1976• Evolución y adaptación a lenguajes modernos (ejemplo
Java PathFinder)• basada en mutantes de código (Budd, Lipton, DeMillo y
Sayward, 1980).• Otras aproximaciones:
• basada en concolic execution• basadas en algoritmos genéticos• basadas en minimización de funciones
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación automática decasos de prueba
Técnicas de generación automática de casos de prueba:• Generación aleatoria
• QuickCheck: Generación aleatoria guiada• Generación estática
• basada en ejecución simbólica• Origen en 1976• Evolución y adaptación a lenguajes modernos (ejemplo
Java PathFinder)• basada en mutantes de código (Budd, Lipton, DeMillo y
Sayward, 1980).• Otras aproximaciones:
• basada en concolic execution• basadas en algoritmos genéticos• basadas en minimización de funciones
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación automática decasos de prueba
Técnicas de generación automática de casos de prueba:• Generación aleatoria
• QuickCheck: Generación aleatoria guiada• Generación estática
• basada en ejecución simbólica• Origen en 1976• Evolución y adaptación a lenguajes modernos (ejemplo
Java PathFinder)• basada en mutantes de código (Budd, Lipton, DeMillo y
Sayward, 1980).• Otras aproximaciones:
• basada en concolic execution• basadas en algoritmos genéticos• basadas en minimización de funciones
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación automática decasos de prueba
Técnicas de generación automática de casos de prueba:• Generación aleatoria
• QuickCheck: Generación aleatoria guiada• Generación estática
• basada en ejecución simbólica• Origen en 1976• Evolución y adaptación a lenguajes modernos (ejemplo
Java PathFinder)• basada en mutantes de código (Budd, Lipton, DeMillo y
Sayward, 1980).• Otras aproximaciones:
• basada en concolic execution• basadas en algoritmos genéticos• basadas en minimización de funciones
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación automática decasos de prueba
Técnicas de generación automática de casos de prueba:• Generación aleatoria
• QuickCheck: Generación aleatoria guiada• Generación estática
• basada en ejecución simbólica• Origen en 1976• Evolución y adaptación a lenguajes modernos (ejemplo
Java PathFinder)• basada en mutantes de código (Budd, Lipton, DeMillo y
Sayward, 1980).• Otras aproximaciones:
• basada en concolic execution• basadas en algoritmos genéticos• basadas en minimización de funciones
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación basada enejecución simbólica
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Aproximación basada enejecución simbólica
• Herramientas, muchas de ellas open-source:• Symbolic (Java) Pathfinder de la NASAhttp://babelfish.arc.nasa.gov/trac/jpf/wiki/projects/jpf-symbc
• CUTE y jCUTE de la UIUChttp://osl.cs.uiuc.edu/~ksen/cute
• KLEE de Stanfordhttp://klee.llvm.org/
• CREST y BitBlaze de UC Berkeleyhttp://code.google.com/p/crest
• Pex, SAGE, YOGI, PREfix de Microsofthttp://research.microsoft.com/en-us/projects/pex/http://research.microsoft.com/en-us/projects/yogi
• Apollo de IBM,• Herramientas de prueba de Parasoft• . . .
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución de un programa
• Semántica de los lenguajes de programación:• Indica qué significa ejecutar una instrucción del
programa• Pueden existir distintas semánticas para cada lenguaje:
operacional, axiomática, denotacional, . . .• La semántica operacional es la más cercana al modelo
de ejecución (imperativo)
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Elementos sintácticos del lenguaje• Enteros N• Valores de verdad T= {true,false}• Posiciones (variables) Loc• Expresiones aritméticas Aexp• Expresiones booleanos Bexp• Instrucciones (commands) Com
• Usamos la notación BNF para expresar la sintaxis dellenguaje• usaremos metavariables, por ejemplo a0,a1
representan expresiones aritméticas
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Expresiones aritméticas Aexp:
a ::= n | X | a0 + a1 | a0 − a1 | a0 × a1
• Expresiones booleanas Bexp:
b ::= true | false | a0 = a1 | a0 ≤ a1 |¬ b | b0 ∧ b1 | b0 ∨ b1
• Instrucciones Com:
c ::= skip | X := a | c0; c1 | if b then c0 else c1 |while b do c
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Estado de un programa: Asignación de valores a lasvariables del programa
• Evaluación de expresiones. Dado un estado,• una expresión aritmética se evalúa a un entero• una expresión booleana se evalúa a un valor de verdad
Formalmente:
Estado de un programaEl conjunto de estados Σ son las funciones σ : Loc→ N devariables a números.σ(X ) es el valor de la variable X en el estado σ
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Evaluación de expresiones aritméticas:• La configuración 〈a, σ〉 representa que hay que evaluar
la expresión a en el estado σ• Definiremos la relación de evaluación 〈a, σ〉 → n entre
configuraciones y números.“La expresión a en el estado σ se evalúa a n”
• Evaluación de números: 〈n, σ〉 → n• Evaluación de variables: 〈X , σ〉 → σ(X )
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Evaluación de sumas:
〈a0, σ〉 → n0 〈a1, σ〉 → n1
〈a0 + a1, σ〉 → n
donde n es la suma de n0 y n1
• Evaluación de restas:
〈a0, σ〉 → n0 〈a1, σ〉 → n1
〈a0 − a1, σ〉 → n
donde n es la resta de n0 y n1
• Evaluación de productos: similar.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Instanciación de una regla. Ejemplo:
〈2, σ0〉 → 2 〈3, σ0〉 → 3〈2 + 3, σ0〉 → 5
• Evaluación de una expresión. Se construye un árbol dederivación.
EjemploDado el estado σ0 = {X 7→ 0,Y 7→ 0, . . .} en el que todavariable tiene asignado el entero 0, desarrolla la evaluaciónde la expresión a ≡ (Y + 5) + (7 + 9).
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Evaluación de expresiones booleanas (1/2):
〈true, σ〉 → true〈false, σ〉 → false
〈a0, σ〉 → n 〈a1, σ〉 → m〈a0 = a1, σ〉 → true
si n y m son iguales
〈a0, σ〉 → n 〈a1, σ〉 → m〈a0 = a1, σ〉 → false
si n y m no son iguales
〈a0, σ〉 → n 〈a1, σ〉 → m〈a0 ≤ a1, σ〉 → true
si n es menor o igual que m
〈a0, σ〉 → n 〈a1, σ〉 → m〈a0 ≤ a1, σ〉 → false
si n es mayor que m
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Evaluación de expresiones booleanas (2/2):
〈b, σ〉 → true〈¬b, σ〉 → false〈b, σ〉 → false〈¬b, σ〉 → true
〈b0, σ〉 → t0 〈b1, σ〉 → t1〈b0 ∧ b1, σ〉 → t
donde t es true si t0 ≡ true yt1 ≡ true, y es false en otro caso
〈b0, σ〉 → t0 〈b1, σ〉 → t1〈b0 ∨ b1, σ〉 → t
donde t es true si t0 ≡ true ot1 ≡ true, y es false en otro caso
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejercicio
Definir reglas alternativas para los operadores booleanos ∧y ∨ de forma que resulten más eficientes:
• Cuando la primera parte de la conjunción se evalúe afalse, no hace falta evaluar la seguna parte pues elresultado será false
• Cuando la primera parte de la disyunción se evalúe atrue, no hace falta evaluar la seguna parte pues elresultado será true
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Ejecución de instrucciones:• La ejecución de una instrucción implica un cambio de
estado• En el estado inicial σ0 de la ejecución de un programa
todas las variables tienen asignado el valor 0:σ0(X ) = 0 para toda variable X
• La ejecución de un programa puede terminar o diverger(no se alcanza un estado final)
• Definiremos la relación 〈c, σ〉 → 〈c′, σ′〉 que significa:la ejecución de paso pequeño de la instrucción c en elestado σ nos lleva a tener que ejecutar la instrucción c′
en el estado σ′
donde σ′ es el estado resultado de actualizar σ con losefectos consecuencia de la ejecución de c.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Ejecución de instrucciones:• Actualización del estado.
Dado el estado σ, una variable X y un número m,σ[X/m] representa el estado resultado de reemplazarel valor asignado a X por el nuevo valor m:
σ[X/m](Y ) =
{m si Y = X ,σ(Y ) si Y 6= X .
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Ejecución de instrucciones:• No hay regla definida para skip (será estado final)• Asignación:
〈a, σ〉 → m〈X := a, σ〉 → 〈skip, σ[X/m]〉
• Secuencia:
〈skip; c1, σ〉 → 〈c1, σ〉〈c0, σ〉 → 〈c′
0, σ′〉
〈c0; c1, σ〉 → 〈c′0; c1, σ′〉
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalestándar
Lenguaje IMP: Un lenguaje imperativo sencillo
• Ejecución de instrucciones:• Condicional:
〈b, σ〉 → true〈if b then c0 else c1, σ〉 → 〈c0, σ〉
〈b, σ〉 → false〈if b then c0 else c1, σ〉 → 〈c1, σ〉
• Bucle:
〈b, σ〉 → false〈while b do c, σ〉 → 〈skip, σ〉
〈b, σ〉 → true〈while b do c, σ〉 → 〈c; while b do c, σ〉
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejercicio
Escribe una versión del condicional donde en el mismopaso se evalúe la condición y además se empiece aejecutar la rama correspondiente (se dé un paso).
• Tendrás que considerar el caso en el que la ramacorrespondiente no pueda avanzar en su ejecución(caso skip)
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución estándar
Ejecución estándarDado un programa, su ejecución consiste en aplicar lasreglas de la semántica estándar desde el estado inicialhasta alcanzar (si existe) el estado final.
EjemploEscribe la traza de la ejecución del siguiente programa:
X := 5; Y := 1
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejercicio
Escribe la traza de la ejecución del siguiente programa:
X := 5; if X > 3 then (Y := 2; X := X − 2) else Y = 6
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución simbólica
• A diferencia de la ejecución estándar, el estado inicialno contiene valores asignados a variables, sinovalores simbólicos.
Ejecución simbólicaDado un programa, su ejecución simbólica consiste enexplorar los caminos de ejecución posibles, de forma que elresultado de dicha ejecución no es un estado final, sinotodos los estados finales posibles junto con lasrestricciones que deben satisfacerse para ser alcanzados
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución simbólicaIdea
• Ejecuta un programa con valores de entrada simbólicos• Los estados simbólicos (durante la ejecución)
representan conjuntos de estados concretos• Para cada camino se construye una path condition
• Condiciones sobre los valores de entrada que hacenque la ejecución siga ese camino
• Comprobar la satisfacibilidad de las path conditions nospermite explorar sólo ejecuciones posibles
• Una configuración simbólica consta de:• Valores y expresiones simbólicas asignadas a las
variables• Una path condition• El punto del programa en el que se encuentra la
ejecución
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución concreta vs simbólicaEjemplo
• Asumamos que X1 y X2 son parámetros de entradadel programa, por lo que el estado inicial de laejecución serán los valores introducidos como entrada
while ¬(X1 = X2) doif X1 > X2 then X1 := X1− X2
else X2 := X2− X1
• Tres trazas concretas como ejemplo:
〈while . . . , {X1 7→ 3,X2 7→ 6}〉 → . . .→ 〈skip, {X1 7→ 3,X2 7→ 3}〉〈while . . . , {X1 7→ 3,X2 7→ 8}〉 → . . .→ 〈skip, {X1 7→ 1,X2 7→ 1}〉〈while . . . , {X1 7→ 4,X2 7→ 6}〉 → . . .→ 〈skip, {X1 7→ 2,X2 7→ 2}〉
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución concreta vs simbólicaEjemplo
• Asumamos que X1 y X2 son parámetros de entradadel programa, por lo que el estado inicial de laejecución serán los valores introducidos como entrada
while ¬(X1 = X2) doif X1 > X2 then X1 := X1− X2
else X2 := X2− X1
• Ejemplo de resultado de la ejecución simbólica:
〈while . . . , {X1 7→ ?X1,X2 7→ ?X2}, true〉 → . . .
(1) . . .→ 〈skip, {X1 7→?X1,X2 7→?X2}, ?X1 =?X2〉(2) . . .→ 〈skip, {X1 7→?X1−?X2,X2 7→?X2},
?X1 6=?X2∧?X1 >?X2∧?X2 =?X1−?X2〉(3) . . .
...
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución concreta vs simbólicaEjemplo
• Asumamos que X1 y X2 son parámetros de entradadel programa, por lo que el estado inicial de laejecución serán los valores introducidos como entrada
while ¬(X1 = X2) doif X1 > X2 then X1 := X1− X2
else X2 := X2− X1
• Ejemplo de resultado de la ejecución simbólica:
〈while . . . , {X1 7→?X1 ,X2 7→?X2 }, true〉 → . . .
(1) . . .→ 〈skip, {X1 7→?X1,X2 7→?X2}, ?X1 =?X2〉(2) . . .→ 〈skip, {X1 7→?X1−?X2,X2 7→?X2},
?X1 6=?X2∧?X1 >?X2∧?X2 =?X1−?X2〉(3) . . .
...
path conditionValores simbólicos
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución concreta vs simbólicaEjemplo
• Asumamos que X1 y X2 son parámetros de entradadel programa, por lo que el estado inicial de laejecución serán los valores introducidos como entrada
while ¬(X1 = X2) doif X1 > X2 then X1 := X1− X2
else X2 := X2− X1
• Ejemplo de resultado de la ejecución simbólica:
〈while . . . , {X1 7→ ?X1,X2 7→ ?X2}, true〉 → . . .
(1) . . .→ 〈skip, {X1 7→?X1,X2 7→?X2}, ?X1 =?X2〉(2) . . .→ 〈skip, {X1 7→?X1−?X2,X2 7→?X2},
?X1 6=?X2∧?X1 >?X2∧?X2 =?X1−?X2〉(3) . . .
...
path condition
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución concreta vs simbólicaEjemplo
• Asumamos que X1 y X2 son parámetros de entradadel programa, por lo que el estado inicial de laejecución serán los valores introducidos como entrada
while ¬(X1 = X2) doif X1 > X2 then X1 := X1− X2
else X2 := X2− X1
• Ejemplo de resultado de la ejecución simbólica:
〈while . . . , {X1 7→ ?X1,X2 7→ ?X2}, true〉 → . . .
(1) . . .→ 〈skip, {X1 7→?X1,X2 7→?X2}, ?X1 =?X2〉(2) . . .→ 〈skip, {X1 7→?X1−?X2,X2 7→?X2},
?X1 6=?X2∧?X1 >?X2∧?X2 =?X1−?X2〉(3) . . .
...
path conditionValores simbólicos
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución simbólicaEjemplo
if X1 > X2 then X1 := X1− X2else X2 := X2− X1
〈if X1 > X2 . . . , {X1 7→?X1,X2 7→?X2}, true〉
〈X1 := X1− X2, {X1 7→?X1,X2 7→?X2}, ?X1 >?X2〉
〈X2 := X2− X1, {X1 7→?X1,X2 7→?X2}, ?X1 ≤?X2〉
〈skip, {X1 7→?X1−?X2,X2 7→?X2}, ?X1 >?X2〉
〈skip, {X1 7→?X1,X2 7→?X2−?X1}, ?X1 ≤?X2〉
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
• Ahora las configuraciones son de la forma
〈c, σ,pc〉
• σ es una función que asigna a cada variable unaexpresión simbólica.
• La relación de evaluación de expresiones ahora esentre configuraciones y expresiones (nonecesariamente valores): 〈a, σ〉 → exp
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
Reglas de ejecución
• Secuencia:
〈skip; c1, σ,p〉 → 〈c1, σ,p〉〈c0, σ,p〉 → 〈c′0, σ′,p′〉
〈c0; c1, σ,p〉 → 〈c′0; c1, σ′,p′〉
• Asignación:
〈a, σ〉 → exp〈X := a, σ,p〉 → 〈skip, σ[X/exp],p〉
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
Reglas de ejecución
• Condicional (1/2):
〈b, σ〉 → exp〈if b then c0 else c1, σ,p〉 → 〈c0, σ,p〉
si p implica exp
〈b, σ〉 → exp〈if b then c0 else c1, σ,p〉 → 〈c1, σ,p〉
si p implica ¬exp
• Debemos tener un motor lógico capaz de determinar silas restricciones de la path condition satisfacen lascondiciones.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
Reglas de ejecución
• Condicional (1/2):
〈b, σ〉 → exp〈if b then c0 else c1, σ,p〉 → 〈c0, σ,p〉
si p implica exp
〈b, σ〉 → exp〈if b then c0 else c1, σ,p〉 → 〈c1, σ,p〉
si p implica ¬exp
• Debemos tener un motor lógico capaz de determinar silas restricciones de la path condition satisfacen lascondiciones.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
Reglas de ejecución
• Condicional (2/2):Cuando no podemos probar p ⇒ exp ni p ⇒ ¬exp, segenera una bifurcación en el árbol mediante laejecución de las siguientes dos reglas:
〈b, σ〉 → exp〈if b then c0 else c1, σ,p〉 → 〈c0, σ,p ∧ exp〉
〈b, σ〉 → exp〈if b then c0 else c1, σ,p〉 → 〈c1, σ,p ∧ ¬exp〉
• Podemos usar un motor lógico para comprobar sip ∧ exp (y p ∧ ¬exp) son satisfacibles. Así podemospodar ejecuciones imposibles.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
Reglas de ejecución
• Condicional (2/2):Cuando no podemos probar p ⇒ exp ni p ⇒ ¬exp, segenera una bifurcación en el árbol mediante laejecución de las siguientes dos reglas:
〈b, σ〉 → exp〈if b then c0 else c1, σ,p〉 → 〈c0, σ,p ∧ exp〉
〈b, σ〉 → exp〈if b then c0 else c1, σ,p〉 → 〈c1, σ,p ∧ ¬exp〉
• Podemos usar un motor lógico para comprobar sip ∧ exp (y p ∧ ¬exp) son satisfacibles. Así podemospodar ejecuciones imposibles.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
Reglas de ejecución
• Bucle (1/2):
〈b, σ〉 → exp〈while b do c, σ,p〉 → 〈skip, σ,p〉 si p implica ¬exp
〈b, σ〉 → exp〈while b do c, σ,p〉 → 〈c; while b do c, σ,p〉 si p implica exp
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
Reglas de ejecución
• Bucle (2/2):Cuando no se pueden aplicar ninguna de las dosreglas anteriores, se aplican las dos siguientesgenerándose una bifurcación.
〈b, σ〉 → exp〈while b do c, σ,p〉 → 〈skip, σ,p ∧ ¬exp〉
〈b, σ〉 → exp〈while b do c, σ,p〉 → 〈c; while b do c, σ,p ∧ exp〉
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Semántica operacionalsimbólica
Ejemplo
while ¬(X1 = X2) doif X1 > X2 then X1 := X1− X2
else X2 := X2− X1
〈while . . . , {X1 7→?X1,X2 7→?X2}, true〉
〈skip, {X1 7→?X1,X2 7→?X2}, ?X1 =?X2〉〈if . . . ;while . . . , {X1 7→?X1,X2 7→?X2}, ?X1 6=?X2〉
〈X1 := X1− X2;while . . . ,
{X1 7→?X1,X2 7→?X2}?X1 6=?X2∧?X1 >?X2〉
〈X1 := X1− X2;while . . . ,
{X1 7→?X1,X2 7→?X2},?X1 6=?X2∧?X1 ≤?X2〉
〈skip, {X1 7→ ?X1−?X2,X2 7→?X2},?X1 6=?X2∧?X1 >?X2∧?X1−?X2 =?X2〉
. . .
〈skip, {X1 7→ ?X1−?X2,X2 7→?X2},?X1 6=?X2∧?X1 ≤?X2∧?X1−?X2 =?X2〉
. . .
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejercicio
Escribe el árbol resultante de la ejecución simbólica delsiguiente programa:
if X > 3 then (Y := 2; X := X − 2) else Y = 6
Escribe el árbol resultante de la ejecución simbólica delsiguiente programa:
if X > Y then (X := X + Y ;
Y := X − Y ;
X := X − Y ;
if X − Y > 0 then Z = false else skip)
else skip
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación de casos de prueba
• Idea:• Usar la path condition de cada configuración final para
generar el caso de prueba asociado a dicho camino• Usar un resolutor de restricciones (SAT Solver) para
obtener valores concretos que satisfagan lasrestricciones de las path conditions.
• Ejemplo:• A partir de la path condition de la configuración final
〈skip, {X1 7→?X1,X2 7→?X2}, ?X1 =?X2〉
se generaría un caso de prueba como
{X1 7→ 1,X2 7→ 1} o{X1 7→ 16,X2 7→ 16}, etc.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Generación de casos de prueba
• Idea:• Usar la path condition de cada configuración final para
generar el caso de prueba asociado a dicho camino• Usar un resolutor de restricciones (SAT Solver) para
obtener valores concretos que satisfagan lasrestricciones de las path conditions.
• Ejemplo:• Para
〈skip, {X1 7→?X1,X2 7→?X2}, ?X1 6=?X2 ∧ ?X1 >?X2 ∧ ?X1−?X2 =?X2〉
se generaría un caso de prueba como
{X1 7→ 6,X2 7→ 3} o{X1 7→ 128,X2 7→ 64}, etc.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Avances y retos
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución simbólicaAvances y retos
• Ejecución simbólica clásica• Gestiona programas secuenciales en los que las
entradas son tipos de datos primitivos• Ejecución simbólica generalizada
• Gestiona estructuras de datos dinámicas y varios hilosde ejecución
• Ideas clave:• Lazy initialization de las estructuras de datos de entrada• Usar la estrategia de un model checker para gestionar la
concurrencia
• Gestión de bucles y recursión• Se puede poner un límite en la profundidad del árbol• Se puede parar cuando se alcanza una cobertura
suficiente• Se puede usar abstracción de estados para parar
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Gestión de estructuras de datosdinámicas
Lazy initialization
• Necesario para los lenguajes de programaciónmodernos
• Lazy initialization:• Inicializa los componentes de las entradas de los
métodos bajo demanda, sin limitar tamaños máximosde entrada.
• Se exploran las distintas posibilidades (bifurcación en elárbol de ejecución), por ejemplo cuando se accede aun puntero habrá tres casos: puntero nulo, que seacceda a un nuevo objeto o a uno ya existente
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Lazy initialization. EstrategiaSe inicializan los campos simbólicos la primera vez que elcódigo accede a ellos durante la ejecución simbólica Paraejecutar el método m de la clase C:
1 Se crea un objeto o de la clase C con campos noinicializados
2 Se invoca o.m() y se sigue la semántica pero:• si encontramos un campo no inicializado, si se trata de
un campo que contiene una referencia f, de forma nodeterminista se inicializa f a:• null, o• un nuevo objeto de la clase T (con campos no
inicializados), o• un objeto existente de la clase T (creado previamente)
Si se trata de un campo de tipo primitivo, se inicializa aun valor simbólico
• si encontramos un punto de elección con una condiciónque implica campos primitivos, de forma nodeterminista actualiza la path condition con la condicióno con su negación
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Gestión de estructuras de datosdinámicas. Ejemplo
• Estructura de una lista enlazada (de enteros)• swapNode actualiza la lista intercambiando los dos
primeros nodos si el primero tiene un número mayorque el segundo
class Node {int elem;Node next;
Node swapNode() {1: if(next!=null)2: if(elem - next.elem > 0) {3: Node t = next;4: next = t.next;5: t.next = this;6: return t;
}7: return this;
}}
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
EjemploGeneralized Symbolic Execut ion for Model Checking and Test ing 559
1
2
3
} in stmt 4Initialize "t.next"
} in stmt 2Initialize "next.elem"
} in stmt 2Initialize "elem"
} in stmt 1Initialize "next"
4
5
X
2
?
......
next
X
X
...t
next
t
nextnext
...
PC: E0<=E1, ...
t...
next nextE0 E1 E0 E1
t ...nextnextnext
tnext next
next
tnext nextnext
E0 E1 ?
?E1E0
E0 E1E1E0
tnext next
PC: E0>E1, next next
E0 E1
E0 E1
next nextE0 E1
next nextE0 ?
next next
next next next
? ?
? ? ? ?
?
Fig. 4. Symbolic execut ion t ree (excerpt s), using notat ion described in Sect ion 2
and corresponds to either execut ion of a statement of swapNode or to a lazy ini-t ializat ion step. Branching in the t ree corresponds to a nondeterminist ic choicethat is int roduced to handle aliasing or build a path condit ion.
The algorithm creates a new node object and invokes swapNode on the object .Line (1) accesses the uninit ialized next field and causes it to be init ialized.The algorithm explores three possibilit ies: either the field is null or the fieldpoints to a new symbolic object or the field points to a previously created objectof the same type (with the only opt ion being it self). Intuit ively, this meansthat , at this point in the execut ion, we make three di�erent assumpt ions aboutthe configurat ion of the input list , according to di�erent aliasing possibilit ies.Another init ializat ion happens during execut ion of statement (4), which result sin four possibilit ies, as there are two Node objects at that point in the execut ion.
When a condit ion involving primit ive fields is symbolically executed, e.g.,statement (2), the execut ion t ree has a branch corresponding to each possibleoutcome of the condit ion’s evaluat ion. Evaluat ion of a condit ion involving refer-ence fields does not cause branching unless uninit ialized fields are accessed.
If swapNode has the precondit ion that it s input should be acyclic, the al-gorithm does not explore the t ransit ions marked with an “X”. The input listcorresponding to the output list pointed to by t in the bot tom most t ree nodeis shown on the bot tom row of Figure 1.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Resumen
• Con la lazy initialization podemos gestionar estructurasde datos dinámicas, pero en general no se controla ladetección de bucles• Comprobar si dos estados hacen matching es
indecidible en general cuando no imponemos un límiteal tamaño de las estructuras de datos dinámicas
• Para garantizar terminación, se recurre a la limitacióndel número de iteraciones en los bucles
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Gestión de bucles y recursión
• En general puede haber un número infinito de ramas• La solución más directa es acotar el número de veces
que se pasa por un bucle• Para mejorar la completitud, existen otras
aproximaciones como Loop abstraction• También podemos mitigar el problema con
• Ejecución paralela o distribuida• Como los subárboles no comparten datos, se puede
particionar para paralelizar. Existen técnicas departición estáticas y dinámicas
• Abstract State Matching• Se almacenan versiones abstractas de los estados
visitados y se comprueba si los nuevos estados estánsubsumidos por estados ya visitados, en cuyo caso separa la exploración.
• Composicional DART = SMART
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Gestión de bucles y recursión
• En general puede haber un número infinito de ramas• La solución más directa es acotar el número de veces
que se pasa por un bucle• Para mejorar la completitud, existen otras
aproximaciones como Loop abstraction• También podemos mitigar el problema con
• Ejecución paralela o distribuida• Como los subárboles no comparten datos, se puede
particionar para paralelizar. Existen técnicas departición estáticas y dinámicas
• Abstract State Matching• Se almacenan versiones abstractas de los estados
visitados y se comprueba si los nuevos estados estánsubsumidos por estados ya visitados, en cuyo caso separa la exploración.
• Composicional DART = SMART
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Gestión de bucles y recursión
• En general puede haber un número infinito de ramas• La solución más directa es acotar el número de veces
que se pasa por un bucle• Para mejorar la completitud, existen otras
aproximaciones como Loop abstraction• También podemos mitigar el problema con
• Ejecución paralela o distribuida• Como los subárboles no comparten datos, se puede
particionar para paralelizar. Existen técnicas departición estáticas y dinámicas
• Abstract State Matching• Se almacenan versiones abstractas de los estados
visitados y se comprueba si los nuevos estados estánsubsumidos por estados ya visitados, en cuyo caso separa la exploración.
• Composicional DART = SMART
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Gestión de bucles y recursiónAbstract subsumption
• La comprobación de subsunción determina si unestado abstracto ya ha sido visitado, en cuyo caso sepoda la rama de ejecución.
• A menudo se trabaja con versiones abstractas de losestados (heap y valores) para optimizar el proceso
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Gestión de bucles y recursión.Ejemplo (1/2)
• Precondición: La lista no es nula y es acíclica• Devuelve el primer nodo cuyo valor es mayor que v
class Node {int elem;Node next; ...
Node find(int v) {1: Node n = this2: while (n!=null){3: if(n.elem > v)
return n;4: n = n.next;
}5: return null;
}}
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejemplo (2/2)168 S. Anand, C.S. Pasareanu, and W. Visser
n
n
n
n
n
n
n
n
n
n
this nextnext
nextnextthis
this
this
PC: true
next
nextthis
next
this next next next
thisnext
nextnext next nextthisnull
n
next next nextthis
next next next
n
this next next nextthis
n
next null
next
nullnext next
this
this
Summary
}
}at line 3Update PC
Initialize nextat line 4
Matched
v2v1
v1 v2
v1
v1
v1 v2 v3
v1
v4v2v1 v2v1 v3
v1 v2 v3 v1 v2 v3
v1
v1
v2
v2v1
s6
v1 ! v " v2 ! v
s4
v1 ! v
s1
v1 ! v " v2 > v
v1 > v
v3
v1 ! v " v2 ! v " v3 > v
s2
v1 ! v
s7
s12
v1 ! v " v2 ! v
s10
s8
s11
v1 ! v " v2 ! v
s9
v1 ! v
s3
s5
v1 ! v " v2 ! v " v3 ! v v1 ! v " v2 ! v " v3 ! v
s13
v1 ! v " v2 ! v " v3 ! v
Fig. 2. State space generated during symbolic execution of find (excerpts)
to a “cloud”, while on the other branch, the cloud is replaced with null (e.g.states s4 and s5). Note that if we wouldn’t have imposed the precondition thatthe input list is acyclic, there had been a third branch corresponding to next
pointing to itself.The (symbolic) state space for this example is infinite and there is no sub-
sumption between the generated symbolic states. However, if we use abstraction,the symbolic state space becomes finite. The list abstraction summarizes con-tiguous node segments that are not pointed to by local variables into a summarynode. Since the number of local variables is finite, the number of abstract heapconfigurations is also finite. For the example, two nodes in state s12 are mappedto a summary node. As a result, the abstract state is subsumed by previouslystored state s8, at which point the model checker backtracks. The analysis ter-minates reporting that there are no null pointer exceptions. Note that due toabstract matching, the model checker might miss feasible behaviors. However,for this example, the abstraction is in fact exact – there is no loss of precision
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Subsumption
• Los estados simbólicos representan conjuntos deestados concretos
• Un estado simbólico s1 subsume a otro s2 si elconjunto de estados representados por s1 es unsuperconjunto de los representados por s2
IdeaSe representa el heap como un grafo de forma que cadaobjeto o variable que contenga una referencia será un nododel grafo y los arcos las relaciones entre los objetos y lasreferencias.• nodos especiales: uninit y null
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Subsumption
Los estados contienen el heap, el punto de ejecución delprograma y la path condition:
Subsunción de heaps simbólicosUn heap H2 subsume a otro H1 (H1 v H2) sii el conjunto deheaps concretos representados por H2 contiene a losrepresentados por H1
• Sólo se comprueba subsunción de estados cuandoestán en el mismo punto de ejecución
• Para que un estado s1 sea subsumido por otro (másgeneral) s2, tiene que cumplirse que su path conditiondebe implicar (ser más fuerte) la de s2
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Subsunción de heapssimbólicos. Ejemplo
8 Saswat Anand et al.: Symbolic Execution with Abstraction
null null
left right
null null
rightleft
null null null nullnull
left right
rightleft
null
rightleft
left
left right
right rightleft
rightleft
unmatchedmatched
! "!"#
Fig. 4. Matched and unmatched heap shapes
where l is a labeling l : NHO ! [{nolbl} and vs denotes
all the symbolic names that are used in symbolic states; this includes both the values stored in the heap andthe values that appear in the path condition.
As an example, consider two symbolic states in Fig-ure 5, where s1 is subsumed by s2. The matched nodesfrom the two heaps have matching labels l1 and l2. Thevaluations for the two nodes labeled l1 and l2 in the left-hand side list are e1 = v1 and e2 = v3 respectively; e1
and e2 are the names computed by the function fn. Sim-ilarly, valuations for the two nodes with labels l1 and l2in the right-hand side list are e1 = v1 and e2 = v2 respec-tively. The state constraint for s1 and s2 are respectively9v1, v3, v2 : e1 = v1 ^ e2 = v3 ^ v1 < v3 ^ v3 < v2 and9v1, v2, v5 : e1 = v1 ^ e2 = v2 ^ v1 ∑ v5 ^ v5 ∑ v2. Notethat the path conditions may contain symbolic valuesthat are not stored in the heap (e.g. v5 in s2) accordingto the program path that led to the symbolic state.
Definition 6. Let Sol(SCls) denote the set of satisfying
solutions for the state constraint SCls of state s for a la-
beling l. SCls2
subsumes SCls1
iÆ Sol(SCls1
) µ Sol(SCls2
)
for same labeling l : NH1
O [ NH2
O ! [ {nolbl}.
Since in general, it may be computationally expen-sive/impossible to enumerate all the solutions of SC1
and SC2 and check for set inclusion, we rather checkSC1 ) SC2, which if valid ensures that Sol(SC1) µSol(SC2).
Now we combine the definitions of heap shape sub-sumption and state constraint subsumption to definestate subsumption as follows:
Definition 7. A state s1 is subsumed by another states2 (or s2 subsumes s1) iÆ H2 wl H1 and SCl
s1) SCl
s2.
In the example from Figure 5, as described before,Algorithm 1 returns true indicating that the heap shapeof s2 subsumes that of s1. Matching nodes from the twostates are labeled with l1 and l2. Notice that the thirdnode in s1 is not labeled due to the uninit node in s2.To check for subsumption of state constraints we check
if the implication between the state constraint of s2 andthat of s1 is valid. State constraint of s1 and s2 simplifiesto e1 < e2 and e1 <= e2 respectively. Since e1 < e2 )e1 <= e2 is valid, s2 subsumes s1.
The complexity for one subsumption step includesthe complexity of heap traversal (O(n) where n is thesize of the heap) and the complexity for checking nu-meric constraints. While the cost of checking numericalconstraints cannot be avoided, we believe that the costof heap traversal can be somewhat alleviated if it is per-formed during garbage collection. However we need toexperiment further with this idea.
5 Symbolic Execution with (Abstract)Subsumption Checking
Algorithm 2 illustrates the procedure for performing sym-bolic execution with (abstract) subsumption checking.The procedure checks if the input program P can reachan error state ¡ from initial state s0. The procedure usesa depth first search order state exploration and it main-tains a set of VisitedStates for the states visited so farand a Stack for storing the states to be explored. Theprocedure is similar to “classical” model checking stateexploration, except that the explored states are sym-bolic, rather than concrete. The path condition on nu-meric data is checked for satisfiability to ensure explo-ration of feasible paths.
As discussed, we use state subsumption to determineif a state was visited before. Performing symbolic exe-cution and subsumption checking during model check-ing may yield an unbounded number of symbolic statesspace. Therefore, we use abstractions to limit the modelchecker’s search space. For each explored symbolic states0, the model checker computes an abstract state Æ(s0),which is then stored for state comparison. Subsumptionchecking is used to compare the abstracted states, to de-termine if an abstract state is being re-visited. This ef-fectively explores an under-approximation of the feasiblepaths through the program. Therefore, all the reported
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Subsunción de heapssimbólicos. Ejemplo
Saswat Anand et al.: Symbolic Execution with Abstraction 9
thisthisnext next next next nextv1 v3 v2
valuation : e1 = v1 ! e2 = v3
PC : v1 < v3 ! v3 < v2
s1 :
v1 v2
valuation : e1 = v1 ! e2 = v2
PC : v1 " v5 ! v5 " v2
s2 :
l2 :l1 : l1 : l2 :
Fig. 5. State Subsumption
Data: Program P and error state ¡Result: Counterexample if ¡ is reachablebegin1
add (Æ(s0), V isitedStates);2
push (s0, Stack);3
while Stack is not empty do4
s := pop (Stack);5
if s = ¡ then return counterexample;6
foreach transition t enabled in s do7
s0:= successor (s, t);8
if PathCondition(s0) is not satisfiable9
then continue;if there exists s00 2 V isitedStates s.t. Æ(s0)10
subsumed by s00 then continue;// s’ not subsumed by any of the visited11
statesadd (Æ(s0), V isitedStates);12
push (s0, Stack);13
end14
end15
end16
Algorithm 2: Symbolic Execution with (Abstract)Subsumption Checking
errors correspond to real errors in the analyzed program.Note however that the analysis might miss some errors,due to the imprecision of the abstraction.
6 Abstractions
6.1 Abstraction for Singly Linked Lists
The abstraction that we have implemented is inspiredby [22,31] and it is based on the idea of summarizing allthe nodes in a maximally uninterrupted list segment witha summary node. The main diÆerence between [22, 31]and the abstraction presented here is that we also sum-marize the numeric data stored in the summarized nodesand we give special treatment to un-initialized nodes.The numeric data stored in the abstracted list is sum-marized by setting the valuation for the summary nodeto be a disjunction of the valuations of the summarizednodes. Intuitively, the numeric data stored in a summarynode can be equal to that of any of the summarizednodes.
Shape subsumption between abstract states is doneby Algorithm 1 as before, which treats summary nodeas any other node in the heap. For checking subsump-tion between numeric constraints, we introduce a newvaluation function for the summary nodes as describedbefore.
Definition 8. A node n is defined as an interruptingnode, or simply an interruption if n satisfies at least oneof following conditions:
1. n = null2. n = uninit3. n 2 {m such that (r,m) 2 ER}, i.e., n is pointed to
by at least one reference variable.4. 9n1, n2 such that (n1, next, n), (n2, next, n) 2 EF .
In other words, n is pointed-to by at least two nodes(cyclic list).
An uninterrupted list segment is a segment of the listthat does not contain an interruption. An uninterruptedlist segment [u, v] is maximal if, (a, next, u) 2 EF )a is an interruption and (v, next, b) 2 EF ) b is aninterruption.
The abstraction for linked list replaces all maximallyuninterrupted list segments in heap H with a summarynode in the abstract state. If [u, v] is a maximally un-interrupted list segment in H, the following transforma-tions on H produces its abstract mapping.
1. A new summary node nsum is added to the set ofnodes NH
O .2. If there is an edge (a, next, u) 2 EH
F , a new edge(a, next, nsum) is added to EH
F .3. If there is an edge (v, next, b) 2 EH
F , a new edge(nsum, next, b) is added to EH
F .4. All nodes m in the list segment [u, v], and all edges
incident on or going out of each m are removed fromH.
Note that the edges between the nodes in the listsegment, which are summarized by a summary node,are not represented in the abstraction state. With thisabstraction, Algorithm 1 is used to check subsumptionof shapes for abstracted heaps.
In order to check subsumption of numeric constraints,we define a valuation function for the summary nodes asfollows. Let NS , NS Ω NO, denote the set of summarynodes introduced in the heap during abstraction.
Saswat Anand et al.: Symbolic Execution with Abstraction 9
thisthisnext next next next nextv1 v3 v2
valuation : e1 = v1 ! e2 = v3
PC : v1 < v3 ! v3 < v2
s1 :
v1 v2
valuation : e1 = v1 ! e2 = v2
PC : v1 " v5 ! v5 " v2
s2 :
l2 :l1 : l1 : l2 :
Fig. 5. State Subsumption
Data: Program P and error state ¡Result: Counterexample if ¡ is reachablebegin1
add (Æ(s0), V isitedStates);2
push (s0, Stack);3
while Stack is not empty do4
s := pop (Stack);5
if s = ¡ then return counterexample;6
foreach transition t enabled in s do7
s0:= successor (s, t);8
if PathCondition(s0) is not satisfiable9
then continue;if there exists s00 2 V isitedStates s.t. Æ(s0)10
subsumed by s00 then continue;// s’ not subsumed by any of the visited11
statesadd (Æ(s0), V isitedStates);12
push (s0, Stack);13
end14
end15
end16
Algorithm 2: Symbolic Execution with (Abstract)Subsumption Checking
errors correspond to real errors in the analyzed program.Note however that the analysis might miss some errors,due to the imprecision of the abstraction.
6 Abstractions
6.1 Abstraction for Singly Linked Lists
The abstraction that we have implemented is inspiredby [22,31] and it is based on the idea of summarizing allthe nodes in a maximally uninterrupted list segment witha summary node. The main diÆerence between [22, 31]and the abstraction presented here is that we also sum-marize the numeric data stored in the summarized nodesand we give special treatment to un-initialized nodes.The numeric data stored in the abstracted list is sum-marized by setting the valuation for the summary nodeto be a disjunction of the valuations of the summarizednodes. Intuitively, the numeric data stored in a summarynode can be equal to that of any of the summarizednodes.
Shape subsumption between abstract states is doneby Algorithm 1 as before, which treats summary nodeas any other node in the heap. For checking subsump-tion between numeric constraints, we introduce a newvaluation function for the summary nodes as describedbefore.
Definition 8. A node n is defined as an interruptingnode, or simply an interruption if n satisfies at least oneof following conditions:
1. n = null2. n = uninit3. n 2 {m such that (r,m) 2 ER}, i.e., n is pointed to
by at least one reference variable.4. 9n1, n2 such that (n1, next, n), (n2, next, n) 2 EF .
In other words, n is pointed-to by at least two nodes(cyclic list).
An uninterrupted list segment is a segment of the listthat does not contain an interruption. An uninterruptedlist segment [u, v] is maximal if, (a, next, u) 2 EF )a is an interruption and (v, next, b) 2 EF ) b is aninterruption.
The abstraction for linked list replaces all maximallyuninterrupted list segments in heap H with a summarynode in the abstract state. If [u, v] is a maximally un-interrupted list segment in H, the following transforma-tions on H produces its abstract mapping.
1. A new summary node nsum is added to the set ofnodes NH
O .2. If there is an edge (a, next, u) 2 EH
F , a new edge(a, next, nsum) is added to EH
F .3. If there is an edge (v, next, b) 2 EH
F , a new edge(nsum, next, b) is added to EH
F .4. All nodes m in the list segment [u, v], and all edges
incident on or going out of each m are removed fromH.
Note that the edges between the nodes in the listsegment, which are summarized by a summary node,are not represented in the abstraction state. With thisabstraction, Algorithm 1 is used to check subsumptionof shapes for abstracted heaps.
In order to check subsumption of numeric constraints,we define a valuation function for the summary nodes asfollows. Let NS , NS Ω NO, denote the set of summarynodes introduced in the heap during abstraction.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Subsunción abstracta deestados simbólicos.
• Para reducir el árbol (el espacio de búsqueda)almacenamos una versión abstracta del estado, que esla que comparamos
• Esto define una bajo-aproximación: se garantiza quese exploran sólo caminos reales, pero no todos
• Abstracción de listas enlazadas (único enlace):• agrupamos los nodos consecutivos siempre que no
• sean nulos,• sean uninit• les apunte alguna referencia• les apunte dos o más nodos (listas con ciclos)
• abstraemos los datos de todos los nodos agrupados
• Abstracción de arrays similar: representados comolistas enlazadas
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Subsunción abstracta deestados simbólicos. Ejemplo
10 Saswat Anand et al.: Symbolic Execution with Abstraction
nn
this this
Summary
next nextnextnextnext nextnext v2 v4v2v1v3v1 v3
l1 : l3 :l2 :
v1 ! v " v2 ! ve1 = v1 " e2 = v2 " e3 = v3 e1 = v1 " (e2 = v2 # e2 = v3) " e3 = v4
v1 ! v " v2 ! v " v3 ! v
l1 : l2 : l3 :
s12s8
Fig. 6. Abstract subsumption between s8 and s12
Definition 9. The “valuation” of a summary node nsum 2NS in state s, with respect to labeling l : NO ! is de-fined as:
vals(nsum, l) :=_
t2sumnodes(nsum)f2primflds(t)
fn(l(nsum), f) = vs(t, f)
where, sumnodes(nsum) denotes the set of nodes that aresummarized by nsum.
6.1.1 Example
To illustrate the approach, let us go back to the examplepresented in Section 3. Figure 6 depicts the abstract heapshape and the valuations of matched nodes for state s12.The abstracted state is subsumed by state s8 as there isa subsumption of heap shape, as represented by label-ings of respective matching nodes and a valid implicationbetween the normalized numeric constraints of the twostates. Note that we don’t explicitly summarize list seg-ments of size one (e.g. the second list element in s8); theabstracted and the un-abstracted states for s8 are in factthe same.
6.1.2 Discussion
Note that the list abstraction ensures that the number ofpossible abstract heap configurations is finite; however,it is still possible to have an infinite number of statesdue to the numeric constraints. To address this issue,we plan to use predicate abstraction in conjunction withthe abstractions presented here, to further abstract thenumeric constraints. This is the subject of future work.Also note that the focus here is on abstracting heapstructures. Therefore we ignored the numeric values oflocal program variables, which may also be unbounded(they are currently discarded in the abstracted state).Predicate abstraction can also be used for the local nu-meric variables.
6.2 Abstraction for Arrays
We extended our framework with subsumption checkingand an abstraction for arrays of integers. The basic ideais to represent symbolic arrays as singly linked lists andto apply the (abstract) subsumption checking methods
developed for lists. Specifically, we maintain the arraysas singly linked lists; nodes in the list represent individ-ual array cells and their ordering in the list correspondto the order of indices of array cells they represent. Con-secutive (initialized) array elements are represented aslinked nodes. Summary nodes are introduced betweenarray elements that are not consecutive. These summarynodes model zero or more uninitialized array elementsthat may possibly exist in the (concrete) array.
With the list representation of arrays we determinesubsumption of program states with arrays as before.However, the roots are now integer program variablesthat are used to index the array, and the special sum-mary nodes representing uninitialized array segments aretreated as any other node in the heap NH
O while check-ing for shape subsumption in Algorithm 1. Abstractionis applied in a way similar to abstraction for linked lists.The definition of interruption is extended to contain thespecial summary nodes.
We must note that this is only one particular ab-straction, and there may be others – for example, ab-stractions based on array representations as ordered se-quences of updates. We adopt this particular representa-tion because in this way we can leverage on our abstrac-tion techniques for lists. Note that subsumption becomes“approximate”, i.e., we might miss the fact that a statesubsumes another.
6.2.1 Array representation
A symbolic array A is represented by a symbolic valuelen representing the array length and an association listof array cells. Each array cell c is a pair (index, elem):index is a symbolic value representing the index in thearray and elem is a symbolic value representing the valuestored in the array at position index.
The array cells are stored in a singly linked list whichis sorted according to the relative order of the indices ofthe cells. Each list element corresponds to an array cellin A. Given array cell c, let index(c) and elem(c) denotethe index and the value of c respectively; also let next(c)denote the cell that is next to c in the list.
The following invariants hold for the list in a programstate with path condition PC.
1. PC ) index(f) >= 0 is valid, where f is the firstcell in the list.
10 Saswat Anand et al.: Symbolic Execution with Abstraction
nn
this this
Summary
next nextnextnextnext nextnext v2 v4v2v1v3v1 v3
l1 : l3 :l2 :
v1 ! v " v2 ! ve1 = v1 " e2 = v2 " e3 = v3 e1 = v1 " (e2 = v2 # e2 = v3) " e3 = v4
v1 ! v " v2 ! v " v3 ! v
l1 : l2 : l3 :
s12s8
Fig. 6. Abstract subsumption between s8 and s12
Definition 9. The “valuation” of a summary node nsum 2NS in state s, with respect to labeling l : NO ! is de-fined as:
vals(nsum, l) :=_
t2sumnodes(nsum)f2primflds(t)
fn(l(nsum), f) = vs(t, f)
where, sumnodes(nsum) denotes the set of nodes that aresummarized by nsum.
6.1.1 Example
To illustrate the approach, let us go back to the examplepresented in Section 3. Figure 6 depicts the abstract heapshape and the valuations of matched nodes for state s12.The abstracted state is subsumed by state s8 as there isa subsumption of heap shape, as represented by label-ings of respective matching nodes and a valid implicationbetween the normalized numeric constraints of the twostates. Note that we don’t explicitly summarize list seg-ments of size one (e.g. the second list element in s8); theabstracted and the un-abstracted states for s8 are in factthe same.
6.1.2 Discussion
Note that the list abstraction ensures that the number ofpossible abstract heap configurations is finite; however,it is still possible to have an infinite number of statesdue to the numeric constraints. To address this issue,we plan to use predicate abstraction in conjunction withthe abstractions presented here, to further abstract thenumeric constraints. This is the subject of future work.Also note that the focus here is on abstracting heapstructures. Therefore we ignored the numeric values oflocal program variables, which may also be unbounded(they are currently discarded in the abstracted state).Predicate abstraction can also be used for the local nu-meric variables.
6.2 Abstraction for Arrays
We extended our framework with subsumption checkingand an abstraction for arrays of integers. The basic ideais to represent symbolic arrays as singly linked lists andto apply the (abstract) subsumption checking methods
developed for lists. Specifically, we maintain the arraysas singly linked lists; nodes in the list represent individ-ual array cells and their ordering in the list correspondto the order of indices of array cells they represent. Con-secutive (initialized) array elements are represented aslinked nodes. Summary nodes are introduced betweenarray elements that are not consecutive. These summarynodes model zero or more uninitialized array elementsthat may possibly exist in the (concrete) array.
With the list representation of arrays we determinesubsumption of program states with arrays as before.However, the roots are now integer program variablesthat are used to index the array, and the special sum-mary nodes representing uninitialized array segments aretreated as any other node in the heap NH
O while check-ing for shape subsumption in Algorithm 1. Abstractionis applied in a way similar to abstraction for linked lists.The definition of interruption is extended to contain thespecial summary nodes.
We must note that this is only one particular ab-straction, and there may be others – for example, ab-stractions based on array representations as ordered se-quences of updates. We adopt this particular representa-tion because in this way we can leverage on our abstrac-tion techniques for lists. Note that subsumption becomes“approximate”, i.e., we might miss the fact that a statesubsumes another.
6.2.1 Array representation
A symbolic array A is represented by a symbolic valuelen representing the array length and an association listof array cells. Each array cell c is a pair (index, elem):index is a symbolic value representing the index in thearray and elem is a symbolic value representing the valuestored in the array at position index.
The array cells are stored in a singly linked list whichis sorted according to the relative order of the indices ofthe cells. Each list element corresponds to an array cellin A. Given array cell c, let index(c) and elem(c) denotethe index and the value of c respectively; also let next(c)denote the cell that is next to c in the list.
The following invariants hold for the list in a programstate with path condition PC.
1. PC ) index(f) >= 0 is valid, where f is the firstcell in the list.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Concolic execution
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Gestión de la resolución derestricciones
• Las path condition pueden ser complejas• Necesitamos un motor lógico capaz de comprobar la
satisfacibilidad de forma efectiva• Se sigue investigando en (más) optimizaciones para la
resolución de restricciones• Se puede recurrir a una ejecución mixta:
• durante la ejecución completa se recogen lasrestricciones simbólicas que se usan para guiar laexploración del árbol (DART, CUTE)
• cuando en la path condition aparece alguna funciónbuilt-in que no puede ser gestionada por un resolutor.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Resolutores
• SMT Solvers• Yices• CVC3
• Resolutores complejos (permiten trabajar conaritmética de coma flotante)• CORAL• Choco
• Resolutores de strings• Hampi• IASolver
• Resolutores para estructuras de datos• Korat
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaDART
DART: Directed Automated Random Testing• Definido para lenguajes C-like• Es una aproximación dinámica aunque usa información
de la ejecución simbólica para guiar la búsqueda• Da solución al problema de la generación de casos de
prueba redundantes o poco significativos de laaproximación aleatoria
• Se instrumenta el código para hacer de formasimultánea una ejecución concreta y simbólica
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaDART. Estrategia
1 Se ejecuta (una vez) el programa con valores deentrada aleatorios.• Durante esa ejecución se almacena la path condition
asociada al camino seguido2 Se usa la path condition calculada para guiar la
ejecución por un camino diferente1 Se niega el último predicado (que no ha sido ya
negado) de la path condition2 Se calculan valores que satisfagan la nueva path
condition
3 Se ejecuta el programa con los valores de entradacalculados y se continúa con el proceso
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaDART. Ejemplo
• con testing aleatorio es difícil detectar el error
1: int f(int x) { return 2 * x; }int h(int x, int y) {
2: if (x!=y)3: if (f(x) == x + 10)4: abort(); /* error */5: return 0;}
1 Valores aleatorios iniciales: x=269167349,y=889801541• no se encuentra el error• se genera la path condition x0 6= y0,2 ∗ x0 6= x0 + 10
2 Se calcula la nueva PC: x0 6= y0,2 ∗ x0 = x0 + 103 Se computan valores que satisfagan las restricciones:x=10, y=889801541
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaDART
+ Mejora la cobertura de ramas con condiciones muyprecisas con respecto al random testing
+ Los errores que detecta son reales, en contraste a loswarnings de los análisis estáticos
+ Aligera la necesidad de tener resolutores derestricciones muy complejos
- Puede no terminar ya que busca cobertura de camino(es incompleto)
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaCUTE
Similar a DART. Mejoras:• Puede manejar tipos dinámicos (punteros, tipos
estructurados)• Admite precondiciones de las funciones para descartar
errores de situaciones que no son reales• Trata aliasing gracias a la lazy initialization
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaCUTE. Estrategia
• Mantiene separadas las restricciones relacionadas condatos de las restricciones sobre la estructura de lospunteros y componentes dinámicas
• Se instrumenta el código para, durante una ejecuciónconcreta, recoger las restricciones simbólicas.
• Simplifica las restricciones sobre los punteros, deforma que mantiene las restricciones sencillas ytratables• Se trata de una aproximación
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaCUTE. Ejemplo
typedef struct cell {int v;struct cell *next;} cell;
int f(int v) {return 2*v + 1;}
int testme(cell *p, int x) {if (x > 0)
if (p != NULL)if (f(x) == p->v)
if (p->next == p)ERROR;
return 0;}
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaCUTE. Ejemplo
1 Genera el valor NULL para p y, de forma nodeterminista 236 para x.
2 Se ejecuta el programa• path condition del camino: x0 > 0, p0 =NULL
3 Se genera la nueva path condition: x0 > 0, p0 6=NULL4 Se computan valores que satisfagan la nueva path
condition: p0 = nonNull , x0 = 236• p apuntará a una celda con sus respectivos campos:p->v valdrá 234 y p->next será NULL
5 Se ejecuta el programa• path condition del camino:
x0 > 0,p0 6= NULL,2 ∗ x0 + 1 6= v0...
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Ejecución mixtaCUTE. Ejemplo
Casos de prueba generados:
pointer operations. For example, pointers may have aliases.Because alias analysis may only be approximate in the pres-ence of pointer arithmetic, using symbolic values to preciselytrack such pointers may result in constraints whose satisfac-tion is undecidable. This makes the generation of test in-puts by solving such constraints infeasible. In this paper, weprovide a method for representing and solving approximatepointer constraints to generate test inputs. Our method isthus applicable to a broad class of sequential programs.
The key idea of our method is to represent inputs for theunit under test using a logical input map that represents allinputs, including (finite) memory graphs, as a collection ofscalar symbolic variables and then to build constraints onthese inputs by symbolically executing the code under test.
We first instrument the code being tested by insertingfunction calls which perform symbolic execution. We thenrepeatedly run the instrumented code as follows. The logi-cal input map I is used to generate concrete memory inputgraphs for the program and two symbolic states, one forpointer values and one for primitive values. The code is runconcretely on the concrete input graph and symbolically onthe symbolic states, collecting constraints (in terms of thesymbolic variables in the symbolic state) that characterizethe set of inputs that would (likely) take the same executionpath as the current execution path. As in [11], one of thecollected constraints is negated. The resulting constraintsystem is solved to obtain a new logical input map I! thatis similar to I but (likely) leads the execution through adi!erent path. We then set I = I! and repeat the process.Since the goal of this testing approach is to explore feasi-ble execution paths as much as possible, it can be seen asExplicit Path Model-Checking.
An important contribution of our work is separatingpointer constraints from integer constraints and keeping thepointer constraints simple to make our symbolic executionlight-weight and our constraint solving procedure not onlytractable but also e!cient. The pointer constraints are con-ceptually simplified using the logical input map to replacecomplex symbolic expressions involving pointers with sim-ple symbolic pointer variables (while maintaining the precisepointer relations in the logical input map). For example, ifp is an input pointer to a struct with a field f, then aconstraint on p->f will be simplified to a constraint on f0,where f0 is the symbolic variable corresponding to the inputvalue p->f. Although this simplification introduces some ap-proximations that do not precisely capture all executions, itresults in simple pointer constraints of the form x = y orx != y, where x and y are either symbolic pointer variablesor the constant NULL. These constraints can be e"cientlysolved, and the approximations seem to su"ce in practice.
We implemented our method in a tool called CUTE(Concolic Unit Testing Engine, where Concolic standsfor cooperative Concrete and symbolic execution). CUTEis available at http://osl.cs.uiuc.edu/~ksen/cute/.CUTE implements a solver for both arithmetic and pointerconstraints to incrementally generate test inputs. The solverexploits the domain of this particular problem to implementthree novel optimizations which help to improve the testingtime by several orders of magnitude. Our experimental re-sults confirm that CUTE can e"ciently explore paths in Ccode, achieving high branch coverage and detecting bugs. Inparticular, it exposed software bugs that result in assertionviolations, segmentation faults, or infinite loops.
typedef struct cell {int v;struct cell *next;
} cell;
intf(int v) {
return 2*v + 1;}
inttestme(cell *p, int x) {
if (x > 0)if (p != NULL)
if (f(x) == p->v)if (p->next == p)
ERROR;return 0;
}
Input 1:
p x 236 NULL
Input 3:
p x 3 1
NULL
Input 4:
p x 3 1
Input 2:
p x 634 236
NULL
Figure 1: Example C code and inputs that CUTEgenerates for testing the function testme
This paper presents two case studies of testing code usingCUTE. The first study involves the C code of the CUTEtool itself. The second case study found two previously un-known errors (a segmentation fault and an infinite loop)in SGLIB [25], a popular C data structure library used ina commercial tool. We reported the SGLIB errors to theSGLIB developers who fixed them in the next release.
2. EXAMPLEWe use a simple example to illustrate how CUTE performs
testing. Consider the C function testme shown in Figure 1.This function has an error that can be reached given somespecific values of the input. In a narrow sense, the inputto testme consists of the values of the arguments p andx. However, p is a pointer, and thus the input includes thememory graph reachable from that pointer. In this example,the graph is a list of cell allocation units.
For the example function testme, CUTE first non-randomly generates NULL for p and randomly generates 236for x, respectively. Figure 1 shows this input to testme. Asa result, the first execution of testme takes the then branchof the first if statement and the else branch of the secondif. Let p0 and x0 be the symbolic variables representing thevalues of p and x, respectively, at the beginning of the ex-ecution. CUTE collects the constraints from the predicatesof the branches executed in this path: x0 > 0 (for the then
branch of the first if) and p0 = NULL (for the else branch ofthe second if). The predicate sequence "x0 > 0, p0 = NULL#is called a path constraint.
CUTE next solves the path constraint "x0 > 0, p0 !=NULL#, obtained by negating the last predicate, to drivethe next execution along an alternative path. The solu-tion that CUTE proposes is {p0 $% non-NULL, x0 $% 236},which requires that CUTE make p point to an allocated cell
that introduces two new components, p->v and p->next, tothe reachable graph. Accordingly, CUTE randomly gen-erates 634 for p->v and non-randomly generates NULL forp->next, respectively, for the next execution. In the sec-ond execution, testme takes the then branch of the firstand the second if and the else branch of the third if.For this execution, CUTE generates the path constraint"x0 > 0, p0 != NULL, 2 · x0 + 1 != v0#, where p0, v0, n0,and x0 are the symbolic values of p, p->v, p->next, andx, respectively. Note that CUTE computes the expression
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Otras herramientas destacadas
• SAGE de Microsoft:• extiende DART para generar los nuevos casos de
prueba de forma fuzzy: modificando un caso bueno• Útil con strings• Mejora la eficacia del testing
• CUTE (para C), jCUTE (para Java)• Usa restricciones sobre punteros y partial order
reduction
• CREST (para C): aproximación dinámica• PEX: Solución de Microsoft para .NET• EXE/KLEE (para C)
• mezcla ejecución simbólica y concreta• se define qué variables son simbólicas• mejora precisión en algunos tipos de errores con
respecto a CUTE
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Hacia el model checking
• La ejecución simbólica tiene muchos aspectos encomún con el model checking• Exploración de todos los caminos gestionando
bifurcaciones• Gestión del problema de caminos infinitos
• Model checking orientado a sistemas concurrentes• Java PathFinder se origina como model checker, pero
aprovecha la estrategia del model checker para hacerejecución simbólica y más cosas!
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Bibliografía (1/3)
Software Testing:• Software Reliability Methods. Doron A. Peled. Springer,
2001. (Capítulo 9).Semántica:• Glynn Winskel. The Formal Semantics of Programming
Languages: An Introduction. MIT Press, 1993 (Capítulo2).
Generación basada en ejecución simbólica:• James C. King. Symbolic execution and program
testing. Comm. of the ACM, 19(7):385-394, 1976.• L.A. Clarke. A System to Generate Test Data and
Symbolically Execute Programs. IEEE Transacions onSoftware Engineering. 2(3):215-222, 1976.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Bibliografía (2/3)
Ejecución simbólica generalizada• Sarfraz Khurshid, Corina S. Pasareanu, Willem Visser.
Generalized Symbolic Execution for Model Checkingand Testing. TACAS 2003: 553-568
Ejecución simbólica con abstracción (subsumption)• Saswat Anand, Corina S. Pasareanu, Willem Visser.
Symbolic execution with abstraction. STTT 11(1): 53-67(2009)
• Saswat Anand, Corina S. Pasareanu, Willem Visser.Symbolic Execution with Abstract SubsumptionChecking. SPIN 2006: 163-181
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
Bibliografía (3/3)
Generación basada en concolic execution:• Koushik Sen, Darko Marinov, Gul Agha. CUTE: a
concolic unit testing engine for C. ESEC/SIGSOFT FSE2005: 263-272
• Patrice Godefroid, Nils Klarlund, Koushik Sen. DART:directed automated random testing. PLDI 2005:213-223
• Cristian Cadar, Vijay Ganesh, Peter M. Pawlowski,David L. Dill, Dawson R. Engler. EXE: AutomaticallyGenerating Inputs of Death. ACM Trans. Inf. Syst.Secur. 12(2) (2008)
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
BibliografíaRelacionada (1/4)
Generación basada en mutantes de código:• T. A. Budd, R. J. Lipton, R. A. DeMillo, F. G. Satward.
Theoretical and empirical studies on using programmutation to test the functional correctness of programs.Proceedings of the 7th conference on Principles ofProgramming Languages, January 1980, 220-233.
• R. A. DeMillo, A. J. Offutt. Constraint-based automatictest data generation. IEEE Transactions on SoftwareEngineering, 17 (9), 1991.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
BibliografíaRelacionada (2/4)
Generación basada en algoritmos genéticos:• B. Jones, H. Sthamer y D. Eyers. Automatic structural
testing using genetic algorithms. The SoftwareEngineering Journal 11, 1996.
• G. McGraw, C. Michael, M. Schatz. Generatingsoftware test data by evolution. Technical ReportRSTR-018-97-01, RST Corporation, 1998.
• R.P. Pargas, M.J. Harrols, R.R. Peck. Test-DataGeneration Using Genetic Algorithms. The journal ofsoftware testing, verification and reliability, 9,1999.
Generación basada en minimización de funciones:• B. Korel. Automated Software Test Data Generation.
IEEE Transactions on Software Engineering, 16(8)1990.
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
BibliografíaRelacionada (3/4)
Loop abstraction:
• Prateek Saxena, Pongsin Poosankam, StephenMcCamant, Dawn Song. Loop-extended symbolicexecution on binary programs. ISSTA 2009: 225-236
• Patrice Godefroid, Daniel Luchaup. Automatic partialloop summarization in dynamic test generation. ISSTA2011: 23-33.
• Jan Strejcek, Marek Trtik. Abstracting path conditions.ISSTA 2012: 155-165
Tema 2
AVD
Introducción
SoftwareTesting
Generaciónbasada enejecuciónsimbólicaRepaso: Semánticaestándar
Semánticasimbólica
Generación decasos de prueba
Avances yretosLazy initialization
Abstractsubsumption
Concolicexecution
Bibliografía
BibliografíaRelacionada (3/4)
Ejecución simbólica composicional (SMART):
• Patrice Godefroid. Compositional dynamic testgeneration. POPL 2007: 47-54
• Saswat Anand, Patrice Godefroid, Nikolai Tillmann.Demand-Driven Compositional Symbolic Execution.TACAS 2008: 367-381
• Patrice Godefroid, Aditya V. Nori, Sriram K. Rajamani,SaiDeep Tetali. Compositional may-must programanalysis: unleashing the power of alternation. POPL2010: 43-56
Top Related