Testing Day TATA Consultancy Services Mayo, 2011. Knowledge Development Center (KDC) del LATU Av. Italia 6201, Montevideo.

1. Testing 3D
Testing Day
26.may.2011
TATA Consultancy Services
Irene Pazos Viana
IEEE Uruguay Section Officer
ipazos@ieee.org member

2. testing 3D
• software testing
• verificación, validación
• inferencia, síntesis
• ...
• f: PROC x SPEC → {V, F}
(u name it … de que hablamos realmente??)
ipazos@ieee.org 26-may-11 2

3. testing 3D
hablamos de todo esto?
resultados
pro an
rsos
ye est
rat
om
cto al
recu
e gias ia
A
s
AN ES UR fases
ciones
RT
PL ciclos
e iter
a
ce
an
BE
casos im
pru ple metodología
rm
CO
eba m
en fo
s f procesos taci
unc on p er
i
aci ón o n a
aut omati
z les documentación (ieee 829)
ipazos@ieee.org 26-may-11 3

4. testing 3D
foco
en el inicio fue el proyecto …todas las cosas fueron hechas
por medio de Él, y sin El nada de lo que ha sido hecho, fue hecho…
bajo cualquier metodología y SDLC, testing es
igualmente un proyecto con mismas características
que el proyecto al que sirve (y otra ejecución “fractal”)
ipazos@ieee.org 26-may-11 4

5. testing 3D
proyectos: metodologías, ciclos vida
“no silver bullet”
• los modelos de calidad, metodologías y ciclos
de vida, se eligen para servir mejor a los
proyectos de una organización.
In folklore, the silver bullet is supposed to be the only kind of
bullet for firearms that is effective against a Werewolf, witch,
or some monsters – wikipedia (since Lone Ranger is out of duty).
ipazos@ieee.org 26-may-11 5

6. testing 3D
proyectos
testing: metodologías, ciclos vida
• Testing is the process of executing a program
with the intent of finding errors
The Art of Software Testing, Myers, Nov.2011 3rd edition
(mhhh…tal vez sea una definición demasiado enfocada)
ipazos@ieee.org 26-may-11 6

7. testing 3D totalmente
recusiva !?
Merriam-Webster Dictionary
test: definición
transitive verb
• 1: to put to test or proof : try
intransitive verb
• 1a : to undergo a test b : to be assigned a
standing or evaluation on the basis of tests
• 2: to apply a test as a means of analysis or
diagnosis
ipazos@ieee.org 26-may-11 7

8. el que esté libre de recursión,
que arroje la primera definición
testing 3D
IEEE Std 610.12-1990, IEEE Std. Glossary
of Software Engineering Terminology
test: (A) A set of one or more test cases, or
(B) A set of one or more test procedures, or (C)
A set of one or more test cases and procedures.
test case: A set of input values, execution
preconditions, expected results and execution
postconditions, developed for a particular
objective or test condition, such as to exercise
a particular program path or to verify
compliance with a specific requirement.
ipazos@ieee.org 26-may-11 8

9. testing 3D
Diccionario de la lengua Española
Vigésima segunda edición
prueba REAL ACADEMIA.
• 2. f. Razón, argumento, instrumento u otro
medio con que se pretende mostrar y hacer
patente la verdad o falsedad de algo.
• 4. f. Ensayo o experimento que se hace de
algo, para saber cómo resultará en su forma
definitiva.
• 13. f. Mat. Operación que se ejecuta para
comprobar que otra ya hecha es correcta.
ipazos@ieee.org 26-may-11 9

10. testing 3D
silver bullet service pack+
1. ENSAYO
2. DEMOSTRACIÓN (de teoremas)
gracias Real Academia por las definiciones recibidas
ipazos@ieee.org 26-may-11 10

11. testing 3D
otras dimensiones para pruebas
test: P x E → C x { R }
P procedimiento
E especificación
C métrica de cumplimiento
R resultados
test: aplicación de un procedimiento a una especificación para obtener una
métrica de cumplimiento y un conjunto de resultados
( procedimiento ? )
ipazos@ieee.org 26-may-11 11

12. testing 3D
con el permiso de los autores, se presentan (“bilingüemente”) conceptos
relevantes tomados del material de los cursos:
C2 "Análisis Automático de Programas: de la Teoría a la Práctica"
Dr. Diego Garbervetsky y Lic. Guido de Caso
Universidad de Buenos Aires, Argentina
C3 "Model Checking Continuous-Time Markov Models: From Theory to Practice"
Dr. Joost-Pieter Katoen
RWTH Aachen University, Alemania
C5 "Automated Test Generation and Repair"
Dr. Darko Marinov
University of Illinois at Urbana-Champaign, Estados Unidos
Escuela de Verano de Ciencias Informáticas RÍO 2011
Universidad Nacional de Río Cuarto, Córdoba, Argentina.
ipazos@ieee.org 26-may-11 12

13. testing 3D
procedimiento
otras dimensiones de pruebas
(aun en el ámbito del ensayo)
• ensayo (dinámico)
• análisis (estático) de
programas
• model checking
ipazos@ieee.org 26-may-11 13

14. testing 3D
proyectos …
cuando hace falta extender
dimensión de pruebas ?
(gracias Joost-Pieter Katoen)
Que tal si el proyecto que
recibimos para probar
fuera algo como …
ipazos@ieee.org 26-may-11 14

15. testing 3D
proyectos
Probar que no existe algo como el programa
“scavenge” que permitía abusar de los
tiempos de salto de satélite y los tiempos de
las señales, accediendo en forma gratuita a
servicios telefónicos pagos.
En las películas de cárceles siempre hay un reo que llama(ba) marcando
con la horquilla (antes que los pulsos reemplazaran los tonos).
ipazos@ieee.org 26-may-11 15

16. testing 3D
proyectos
Probar consistencia de criterios de facturación
entre todos los actores y motores que
participan del sistema de facturación de
telefonía celular.
(ej: sistemas que cobran al cliente a fracción de
min., según el plan contratado -20seg-, y
pagan a carriers asociados a fracción de
tiempo negociada -1 min-)
ANTEL tiene un contrato de revisión del sistema de facturación.
ipazos@ieee.org 26-may-11 16

17. testing 3D
proyectos
Probar que mi broadcast en internet (radio, tv),
no retransmite paquetes haciendo overlap
sobre el mismo receptor.
Evitando que el periodista de la radio ESPECTADOR hable encima de si
mismo cuando hay paquetes demorados (se le pisoteó el buffer??).
ipazos@ieee.org 26-may-11 17

18. testing 3D
proyectos
u otros casos bien conocidos:
(después que fallaron, claro … )
• probar que no hay el error en la unidad de división
de punto flotante en procesadores Intel Pentium II.
• probar que no hay un defecto de software en el
sistema de control de la máquina de terapia
Therac25, que produjo la muerte de 6 pacientes de
cáncer por sobre-exposición radioactiva.
ipazos@ieee.org 26-may-11 18

19. testing 3D
proyectos
no es trivial
probar que NO hay error en un sistema
-cuando esto es posible-, eventualmente
cuesta hoy MAS (tiempo, esfuerzo) que
desarrollar el propio sistema.
(buen dato para quienes de dedican a pruebas …)
ipazos@ieee.org 26-may-11 19

20. testing 3D
proyectos
pero…
un solo día de falla en el sistema de
reservas de una compaña aérea
importante puede provocar su
bancarrota
de costos en vidas humanas mejor ni hablamos, pero podemos
calcular cuanto cuesta una falla, un sistema, y cuanto vale una
compañía.
ipazos@ieee.org 26-may-11 20

21. testing 3D Challenger
disaster
Jan. 1986
además…
Ariane 5 crash (1996) Columbia
error in the software design (inadequate protection from integer overflow) disaster
Feb. 2003
software bugs cost US economy
$60B/year [NIST’02] (*)
Estimated savings from better testing
$22B/year (*)
(*) Darko Marinov: Automated Test Generation and Repair
ipazos@ieee.org 26-may-11 21

22. testing 3D
pruebas
ok, hace falta considerar
múltiples dimensiones de
pruebas.
ipazos@ieee.org 26-may-11 22

23. testing 3D
aproximaciones para pruebas
• ensayo (dinámico)
• análisis (estático) de
programas
• model checking
ipazos@ieee.org 26-may-11 23

24. aproximaciones
ensayo de software
dinámico
• run code for some inputs, check outputs
• checks correctness for some executions
problemas
• generación datos de entrada
• adecuación de suites de prueba
precedencia, cobertura..
• “test oracles”
mecanismos para determinar si prueba pasa o falla
ipazos@ieee.org 26-may-11 24

25. aproximaciones
análisis de programas
estático
• verifica la correctitud de TODA ejecución
posible del programa
algunas técnicas
• análisis de dataflow
abstracción divisiones por cero: σ : var → {indef, Z, NZ, QZ }
• generación de condiciones de verificación
con anotaciones como tipos o contratos
problemas
• corrección vs. completitud:
falsos positivos & negativos
ipazos@ieee.org 26-may-11 25

26. aproximaciones
model checking
combina estático & dinámico
• verifica correctitud de TODA ejecución
• analiza automáticamente cumplimiento de
determinadas propiedades sobre un modelo
formal de un sistema (un grafo dirigido, con
estados etiquetados para las propiedades).
Discrete-time Markov chain
ipazos@ieee.org 26-may-11 26

27. aproximaciones
todo muy lindo .. pero … limitaciones
(yet .. no silver bullet)
análisis dinámico
NO: ensayo exhaustivo de toda posible entrada
espacio( input ) continuo
→ infinitas pruebas
análisis estático
NO: modelo preciso de cada estado posible
espacio( abstracción )
== sistema
ipazos@ieee.org 26-may-11 27

28. aproximaciones
soundness & completeness
• encontramos todas las anomalías?
análisis dinámico imposible
análisis estático seguramente
• anomalías reportadas son reales?
análisis dinámico seguramente
análisis estático imposible
“Most practical techniques and tools are both
unsound and incomplete!”
(false positives, false negatives)
ipazos@ieee.org 26-may-11 28

29. aproximaciones
comparación
• nivel automatización
apretar un botón vs. manual
• tipo de anomalías encontrados
complicadas de reproducir vs. fácil
baja probabilidad vs. alta
propiedades comunes vs. específicas
• tipo de problemas (no) encontrados
ipazos@ieee.org 26-may-11 29

30. aproximaciones
estado actual
• ensayo -dinámico- se mantiene como
aproximación más ampliamente usada para
encontrar problemas
• en la última década hay grandes progresos en
análisis estático (de “sound” a práctico) y
model checking (de hardware a software)
• “Vibrant research in the area”, “Gap between
research and practice”.
ipazos@ieee.org 26-may-11 30

31. aproximaciones
“how-to” – bug dealing
• eliminar
- debug, test
• prevenir
- procesos de desarrollo software
- diseño de lenguajes de programación
• demostrar ausencia
- prueba de teoremas
- model checking, análisis de programas
ipazos@ieee.org 26-may-11 31

32. testing 3D
(snapshot)
• ensayo (dinámico)
• análisis (estático) de
programas
• model checking
ipazos@ieee.org 26-may-11 32

33. testing
Darko Marinov
ensayo
research: automate testing
no hablamos de una persona que enseña a
una máquina a reemplazar el trabajo manual
de otra persona que hace pruebas
es una persona que crea una máquina que
crea artefactos de pruebas.
ipazos@ieee.org 26-may-11 33

34. testing
Darko Marinov
ensayo
máquinas
• Randoop: random generation of OO tests
• Pex: dynamic symbolic generation of inputs
• UDITA: generation of complex data inputs
• ReAssert: repair of OO unit tests
• JPF: systematic testing of Java code
ipazos@ieee.org 26-may-11 34

35. testing
Darko Marinov
Feedback-directed random test generation Randoop
•by Carlos Pacheco,
Shuvendu K. Lahiri, Michael
D. Ernst, and Thomas Ball
generar test unitarios (ICSE 2007)
• genera secuencias de invocaciones a métodos
• elección aleatoria de métodos y parámetros
• implementación java liberada (público)
ipazos@ieee.org 26-may-11 35

36. testing
Darko Marinov
Pex – White Box Test Generation for .NET PEX
•by Nikolai Tillmann and
Jonathan de Halleux
generar test unitarios (TAP 2008)
• describe test scenarios with parameterized
unit tests (PUTs)
• dynamic symbolic execution
• implementación .NET
Choose next path
Code to generate inputs for: Solve Execute&Monitor
void CoverMe(int[] a)
Constraints to solve Data Observed constraints
{
if (a == null) return; null a==null
if (a.Length > 0) a!=null &&
a!=null {} !(a.Length>0)
if (a[0] ==
a!=null &&
1234567890)
throw new
a!=null && Negated condition
{0} a.Length>0 &&
a.Length>0 a[0]!=123456789
Exception("bug"); 0
} a==nul a!=null && {123
F l T a.Length>0 && …} a!=null &&
a[0]==12345678 a.Length>0 &&
a.Length> 90 a[0]==123456789
F 0 T 0
Done: There is no path left.
a[0]==123…
F T
ipazos@ieee.org 26-may-11 36

37. s2
red-black tree s1 s4 s5
testing 1 s3 web sites
0 3
Darko Marinov
2
Test Generation through Programming in UDITA UDITA
•by Milos Gligoric, Tihomir Gvero,
Vilas Jagannath, Sarfraz Khurshid,
Viktor Kuncak, and Darko Marinov
generate complex test inputs (ICSE 2010)
• combines filtering approach (check validity)
and generating approaches (valid by
construction)
• java-based language with non-determinism
• tool for Java
inputs outputs
1 2
0 3 0 3
2
pass
test test
code
generation oracle
0
2
3 0
3 fail
ipazos@ieee.org 26-may-11 37

38. testing
Darko Marinov
ReAssert: Suggesting repairs for broken unit tests ReAssert
•by Brett Daniel, Vilas Jagannath,
Danny Dig, and Darko Marinov
(ASE 2009)
automate repair tests for software
evolutioned versions
• find small changes that make tests pass
• ask the user to confirm proposed changes
• tool for Java/Eclipse
ipazos@ieee.org 26-may-11 38

39. testing
Darko Marinov
Model Checking Programs JPF
•by W. Visser, K. Havelund, G. Brat, S. Park and F. Lerda
(J-ASE, vol. 10, no. 2, April 2003)
Java Path Finder : Model checking of real code
• specialized Java Virtual Machine
• supports backtracking, state comparison
• many optimizations to make it scale
• publicly available tool (Java PathFinder)
ipazos@ieee.org 26-may-11 39

40. testing 3D
• ensayo (dinámico)
• análisis (estático) de
programas
• model checking
ipazos@ieee.org 26-may-11 40

41. análisis de programas
Diego Garbervetsky, Guido de Caso
análisis estático
• analiza código sin ejecutarlo
• es la examinación sistemática de una
abstracción del espacio de estados del
programa.
sistemática - examina en forma exhaustiva todos
los caminos dentro de cada función ( loops!? )
abstracción - sólo mantenemos información relevante
a la propiedad a inferir: signo de las variables (+,-),
referenciamiento, ..
ipazos@ieee.org 26-may-11 41

42. análisis de programas
Diego Garbervetsky, Guido de Caso
técnicas más conocidas
ipazos@ieee.org 26-may-11 42

43. análisis de programas
Diego Garbervetsky, Guido de Caso
Static Analysis can reduce defects
by up to a factor of six!
Capers Jones, Software Productivity Group
efecto en la industria:
MICROSOFT
• Todo desarrollo interno pasa por analizadores automáticos
• Visual Studio + Code Contracts:
Análisis estático + Generación de Test
• Kit de aceptación de drivers que se entrega a los fabricantes
ipazos@ieee.org 26-may-11 43

44. análisis de programas
Diego Garbervetsky, Guido de Caso
en la industria
• Java FindBugs: más de 1,5 millón downloads
- usado en Google, Sun, Ebay, …
- encuentra errores “mecánicos”o patrones de
errores
• En Google descubrieron automáticamente
- > 4000 problemas de código en producción
- más de 80 ciclos infinitos
http://findbugs.sourceforge.net/
ipazos@ieee.org 26-may-11 44

45. testing 3D
• ensayo (dinámico)
• análisis (estático) de
programas
• model checking
ipazos@ieee.org 26-may-11 45

46. model checking
Carnegie Mellon
• method for formally verifying finite-state
concurrent systems. Specifications about the
system are expressed as temporal logic
formulas, and efficient symbolic algorithms are
used to traverse the model defined by the
system and check if the specification holds or
not.
Extremely large state-spaces can often be traversed in minutes. The
technique has been applied to several complex industrial systems
such as the Futurebus+ and the PCI local bus protocols
Model Checking Group, Specification and Verification Center. Carnegie Mellon.www.cmu.edu
ipazos@ieee.org 26-may-11 46

47. model checking
Joost-Pieter Katoen
utilidad
cuantificación
• colas, tiempos de espera, QoS, MTBF,…
• impresiciones en inputs, retrasos, deadlines
ejemplos
• IEEE 1394 (Firewire): “biased delay” óptimo
• análisis protocolos de seguridad
• sistemas biológicos: Enzyme-catalysed substrate
conversion
• software de satélites
ipazos@ieee.org 26-may-11 47

48. model checking
Joost-Pieter Katoen
contexto
ipazos@ieee.org 26-may-11 48

49. model checking
Joost-Pieter Katoen
alcance en modelado
sólo una vista totalmente “brutal”
• Quantitative and Qualitative Reachability,
Probabilistic Computation Tree Logic (PCTL),
PCTL Counterexamples, Continuous-Time
Markov Chains (CMTC), Continuous Stochastic
Logic (CSL)
REACHABILITY PROBABILITIES
ipazos@ieee.org 26-may-11 49

50. model checking
Joost-Pieter Katoen
propiedades?, modelos?
ipazos@ieee.org 26-may-11 50

51. model checking
Joost-Pieter Katoen
estado actual y perspectivas
ipazos@ieee.org 26-may-11 51

52. testing 3D
• ensayo (dinámico)
• análisis (estático) de programas
• model checking
• epílogo &
ultra-epílogo UY
ipazos@ieee.org 26-may-11 52

53. testing 3D
testing
test: P x E → C x { R }
P procedimiento
test
E especificación
C métrica de cumplimiento gestión
R resultados
gestión
test: aplicación de un procedimiento a una proyecto
especificación para obtener una métrica de
cumplimiento y un conjunto de resultados
P = (análisis estático U análisis dinámico U model checking)
ipazos@ieee.org 26-may-11 53

54. testing 3D
testing en uruguay
• industria: cursos abiertos (2007)
• UDELAR/FIng
INCO Taller de Verificación de Software
CPAP Inspección de Software
• CES – Lanzamiento de Carrera de Testing (2011)
• Emprendimiento (InCo) especializado en proveer servicios de testing a empresas.
• Apoyo UE, PNUD para proyecto de Desarrollo tecnológico (URY/2003/5906)
ipazos@ieee.org 26-may-11 54

55. testing 3D
testing en uruguay
horizonte …
• cobertura universitaria para desarrollo de
la industria software bugs cost US economy $60B/year
Estimated savings from better testing
$22B/year
• monitor de calidad, compilando
resultados de industria
• recursos para I+D (apoyados por
monitoreo ..)
Randoop, Pex, UDITA,
ReAsert, JPF
ipazos@ieee.org 26-may-11 55

56. testing 3D
Testing Day
TATA Consultancy Services
Mayo, 2011.
Knowledge Development Center (KDC) del LATU
Av. Italia 6201, Montevideo.

57. ipazos@ieee.org 26-may-11 57