2011 05-26-ieee-TCS testing-day-testing 3d
1 recomendación454 vistas
El documento se centra en la metodología de pruebas de software, enfatizando la importancia de la validación y verificación a través de diversas técnicas analíticas y dinámicas. Se discuten conceptos como el análisis estático, el model checking y las pruebas dinámicas, resaltando su relevancia en el desarrollo de software confiable. Además, se mencionan casos reales de fallos en sistemas por errores de software, subrayando la necesidad de enfoques exhaustivos en las pruebas.
![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](https://image.slidesharecdn.com/2011-05-26-ieee-tctestingday-testing3d-110526170229-phpapp01/85/2011-05-26-ieee-TCS-testing-day-testing-3d-21-320.jpg)
![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](https://image.slidesharecdn.com/2011-05-26-ieee-tctestingday-testing3d-110526170229-phpapp01/85/2011-05-26-ieee-TCS-testing-day-testing-3d-36-320.jpg)
2011 05-26-ieee-TCS testing-day-testing 3d
- 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