Seguimiento automático de errores

El posicionamiento automático de errores en el software es una actividad de ingeniería de software para detectar fallas que pueden causar un mal funcionamiento en un programa . Su objetivo es reducir el esfuerzo del revelador durante la fase de corrección.

Esta investigación puede realizarse mediante análisis estático o dinámico . En cuanto al análisis dinámico, se relaciona con el estudio de las trazas de ejecución del programa .

Este estudio consiste en recolectar datos durante la ejecución del programa con el fin de determinar la probable ubicación del error.

Localización basada en rastros de ejecución

El seguimiento automático de errores es parte del proceso de corrección de errores que incluye los siguientes pasos:

nota el error
reproducir el error a través de pruebas automatizadas
localizar automáticamente el error sobre la base de pruebas automatizadas para determinar su origen. Para ello, al ejecutar las pruebas, se recopilan los siguientes datos:
- ${\ Displaystyle e_ {f}}$ : el número de pruebas que ejecutaron la entidad estudiada que falló (f para fallida)
- ${\ Displaystyle e_ {p}}$ : el número de pruebas que ejecutaron la entidad estudiada que tuvo éxito (p para aprobada)
- ${\ Displaystyle n_ {f}}$ : el número de pruebas que no ejecutan la entidad estudiada que falló (f para fallida)
- ${\ Displaystyle n_ {p}}$ : el número de pruebas que no ejecutaron la entidad estudiada que tuvo éxito (p para aprobada)
arregla el error .

Los datos se pueden recopilar en diferentes niveles de granularidad, como: fila , bloque, función , clase , ver paquete .

Un ejemplo de recopilación de datos

	Prueba 1	Prueba 2	Prueba 3	Prueba 4	${\ Displaystyle e_ {f}}$	${\ Displaystyle e_ {p}}$	${\ Displaystyle n_ {f}}$	${\ Displaystyle n_ {p}}$
Línea 1	Ejecutado		Ejecutado	Ejecutado	2	1	0	1
Línea 2	Ejecutado	Ejecutado		Ejecutado	1	2	1	0
Línea 3		Ejecutado		Ejecutado	1	1	1	1
...
Resultados de la prueba	Éxito	Éxito	Ha fallado	Ha fallado

En el ejemplo anterior, la Fila 1 es ejecutada por las Pruebas 1, 3 y 4, dos de esas pruebas fallaron ( ) y una pasó ( ), todas las pruebas falladas ejecutaron esta fila ( ) y una prueba exitosa no ejecuta esta línea ( ) . La línea 2 es ejecutada por las Pruebas 1, 2 y 4, una de esas pruebas falló ( ) y dos pasaron ( ), una prueba fallida no ejecuta esta línea ( ) y todas las pruebas exitosas ejecutan esta línea ( ). ${\ Displaystyle e_ {f}}$ ${\ Displaystyle e_ {p}}$ ${\ Displaystyle n_ {f}}$ ${\ Displaystyle n_ {p}}$ ${\ Displaystyle e_ {f}}$ ${\ Displaystyle e_ {p}}$ ${\ Displaystyle n_ {f}}$ ${\ Displaystyle n_ {p}}$

Métrica

Las métricas se utilizan para calcular la distancia entre una entidad de código ( línea , bloque, función , clase ) y un error . Hay diferentes métricas. Las entidades se pueden clasificar de acuerdo con estas distancias, las más cercanas al error probablemente contengan el error , las más alejadas probablemente no sean la causa del error . Sobre la base de esta clasificación, el desarrollador puede examinar las diferentes entidades comenzando por la más cercana hasta que se encuentre la entidad defectuosa. Por lo tanto, si la métrica es efectiva, el desarrollador encontrará la fuente del error más rápidamente que con una búsqueda manual.

La más antigua de las métricas de uso común es Jaccard (1901) que, originalmente destinada al campo de la botánica , ahora se utiliza en varios campos. The Botanic también inspiró muchas métricas como Ochiai (1957) Russel y Rao (1940), Sørensen y Dice (1945), Rogers y Tanimoto (1960), Anderberg (1973) y Single-Matching (2004). La métrica de Hamming (1950) fue creada para la detección y corrección de errores de código y la métrica de Goodman y Kruskal en el campo de la biometría . El campo de los mapas autoadaptativos introdujo las métricas de Kulczynski1, Kulczynski2, Hamann y Sokal. Además, se crearon directamente varias métricas para la localización automática de errores: Tarantula, Ample, Zoltar y Wong1-3.

Lista de métricas

La siguiente tabla enumera las principales métricas que utilizan los datos presentados anteriormente para la localización de errores .

apellido	Fórmula	apellido	Fórmula
Jaccard	${\ Displaystyle C_ {jac} = {\ frac {e_ {f}} {e_ {f} + e_ {p} + n_ {f}}}}$	Amplio	${\ Displaystyle C_ {amp} = \| {\ frac {e_ {f}} {e_ {f} + n_ {f}}} - {\ frac {e_ {p}} {e_ {p} + n_ {p} }} \|}$
Dados de Sørensen	${\ Displaystyle C_ {sdice} = {\ frac {2e_ {f}} {2e_ {f} + n_ {f} + e_ {p}}}}$	Dado	${\ Displaystyle C_ {dice} = {\ frac {2e_ {f}} {e_ {f} + n_ {f} + e_ {p}}}}$
Kulczynski1	${\ Displaystyle C_ {kul1} = {\ frac {e_ {f}} {n_ {f} + e_ {p}}}}$	Kulczynski2	${\ Displaystyle C_ {kul2} = {\ frac {1} {2}} ({\ frac {e_ {f}} {e_ {f} + n_ {f}}} + {\ frac {e_ {f}} {e_ {f} + e_ {p}}})}$
Russell y Rao	${\ Displaystyle C_ {rus} = {\ frac {e_ {f}} {e_ {f} + e_ {p} + n_ {f}}}}$	Tarántula	${\ Displaystyle C_ {tar} = {\ frac {\ frac {e_ {f}} {e_ {f} + n_ {f}}} {{\ frac {e_ {f}} {e_ {f} + n_ { f}}} + {\ frac {e_ {p}} {e_ {p} + n_ {p}}}}}}$
Coincidencia simple	${\ Displaystyle C_ {sm} = {\ frac {e_ {f} + n_ {p}} {e_ {f} + e_ {p} + n_ {f} + n_ {p}}}}$	Hamann	${\ Displaystyle C_ {ham} = {\ frac {e_ {f} + n_ {p} -e_ {p} -n_ {f}} {e_ {f} + e_ {p} + n_ {f} + n_ { pag}}}}$
M1	${\ Displaystyle C_ {m1} = {\ frac {e_ {f} + n_ {p}} {n_ {f} + e_ {p}}}}$	M2	${\ Displaystyle C_ {m2} = {\ frac {e_ {f}} {e_ {f} + 2n_ {p} + n_ {f} + 2e_ {p}}}}$
Rogers y Tanimoto	${\ Displaystyle C_ {oca1} = {\ frac {e_ {f} + n_ {p}} {e_ {f} + n_ {p} + 2n_ {f} + 2e_ {p}}}}$	Sokal	${\ Displaystyle C_ {sokal} = {\ frac {2e_ {f} + 2n_ {p}} {2e_ {f} + 2n_ {p} + n_ {f} + e_ {p}}}}$
Hamming	${\ Displaystyle C_ {jamón} = e_ {f} + n_ {p}}$	Buen hombre	${\ Displaystyle C_ {bueno} = {\ frac {2e_ {f} -n_ {f} -e {p}} {2e_ {f} + e_ {p} + n_ {f}}}}$
Ochiai	${\ Displaystyle C_ {oca1} = {\ frac {e_ {f} n_ {p}} {\ sqrt {(e_ {f} + e_ {p}) (e_ {f} + n_ {f})}}} }$	Euclides	${\ Displaystyle C_ {euclid} = {\ sqrt {e_ {f} + n_ {p}}}}$
Ochiai2	${\ Displaystyle C_ {oca2} = {\ frac {e_ {f} n_ {p}} {\ sqrt {(e_ {f} + e_ {p}) (n_ {f} + n_ {p}) (e_ { f} + n_ {p}) (e_ {p} + n_ {f})}}}}$	Anderberg	${\ Displaystyle C_ {anderberg} = {\ frac {e_ {f}} {e_ {f} + 2e_ {p} + 2n_ {f}}}}$
Wong1	${\ Displaystyle C_ {wong1} = e_ {f}}$	Zoltar	${\ Displaystyle C_ {zoltar} = {\ frac {e_ {f}} {e_ {f} + e_ {p} + n_ {f} + {\ frac {1000n_ {f} e_ {p}} {e_ {f }}}}}}$
Wong3	${\ Displaystyle C_ {wong3} = e_ {f} -h {\ text {, donde}} h = {\ begin {cases} e_ {p} & {\ text {if}} e_ {p} {p} < 2 \\ 2 + 0.1 (e_ {p} -2) & {\ text {if}} 2 <e_ {p} {p} <10 \\ 2.8 + 0.01 (e_ {p} -10) & {\ text {if}} e_ {p} {p}> 10 \\\ end {cases}}}$	Wong2	${\ Displaystyle C_ {wong2} = e_ {f} -e_ {p}}$

Alternativa: análisis de predicados

Un enfoque alternativo a la colección de entidades ejecutadas es propuesto por Libit et al., Que consiste en analizar los predicados en lugar de las entidades ejecutadas (líneas, bloques, clases ...). Un predicado interesante puede ser una condición, una devolución de valor ... Durante la ejecución de las pruebas se recogen tanto los predicados ejecutados como los que tienen un valor verdadero. Luego, estos datos se utilizan en métricas que clasifican los predicados en función de su participación en las pruebas fallidas.

Esta es una de las métricas introducidas por Libit et al. : donde ${\ Displaystyle Incremento (B) = Fallo (B) -Contexto (B)}$

${\ displaystyle Failure (B) = {\ frac {\ text {nb de prueba fallida donde B es verdadera}} {\ text {nb de prueba donde B es verdadera}}}}$ y

${\ displaystyle Contexto (B) = {\ frac {\ text {número de prueba fallida donde se ejecuta B}} {\ text {número de prueba donde se ejecuta B}}}}$ .

Combinar métricas

Los estudios empíricos han demostrado que ninguna métrica es perfecta. Una posible solución para mejorar la eficiencia del seguimiento automático de errores es combinar métricas. Wang y col. proponen un enfoque de algoritmos basados en búsquedas , Jifeng Xuan et al. ofrecen una combinación de métricas generadas por aprendizaje automático .

Comparación de métricas

Naish y col. ofrecen una clasificación de métricas sobre datos estandarizados, comparándolos en rendimiento y confiabilidad. Resulta que los algoritmos propuestos por Naish et al. son un mejor compromiso entre rendimiento y fiabilidad, como Wong3, Zoltar, M2 y Ochiai.

Los resultados experimentales de Jifeng Xuan et al. llevado a cabo en 10 proyectos de código abierto muestran que la combinación de métricas puede mejorar la eficiencia de la localización de errores hasta en un 50%. Sin embargo, también muestran que los resultados obtenidos con Ochiai y Ample son buenos. Estos resultados contrastan con los de Naish et al. porque según Jifeng Xuan et al. las suposiciones de Naish et al. sobre los datos no se aplican a casos reales.

Herramientas

Las herramientas para la localización de errores están disponibles como software de forma independiente o como complemento para IDE .

Determinar con precisión

Pinpoint es un marco Java EE para localizar errores en sistemas distribuidos .

Su uso está destinado a la localización de errores en aplicaciones complejas donde varios componentes, en buen estado o defectuosos, interactúan para responder a la solicitud de un cliente. Este marco se desarrolló originalmente para superar las debilidades de los sistemas de seguimiento de errores de análisis estático .

De hecho, las necesidades de dinamismo en aplicaciones complejas ( equilibrio de carga , escalado, etc.) son difíciles de predecir durante un análisis estático.

Su funcionamiento se desarrolla en dos fases:

Observación de las solicitudes realizadas por los clientes y de los componentes del sistema involucrados en las respuestas a estas solicitudes,
Análisis y verificación cruzada de los errores encontrados en las trazas obtenidas en el paso anterior por agrupamiento para identificar los componentes en el origen del error .

El análisis permite resaltar el componente o las combinaciones de componentes que pueden estar en el origen del comportamiento erróneo del sistema.

Varias limitaciones pueden complicar la localización de errores:

En el caso de un acoplamiento fuerte entre un componente defectuoso y un componente saludable, Pinpoint considerará los dos componentes como posibles fuentes del error.
Pinpoint asume que los errores que aparecen en el sistema no corrompen el estado de este último. Sin embargo, rara vez es posible tener la certeza de que un error que apareció durante una solicitud anterior no pueda influir en las solicitudes al sistema en el futuro. Por tanto, un error en el servicio de creación de cuenta podría provocar un error al usuario al autenticarse con el sistema.
No se evalúa la calidad de las solicitudes enviadas por el cliente. Por lo tanto, es imposible para Pinpoint saber si un error es causado por una solicitud inconsistente del cliente o por una falla del servidor.
Los errores detectados sobre la marcha por el sistema durante su ejecución no son registrados por Pinpoint, incluso si el rendimiento de la respuesta a una solicitud se ve afectado.

Tarántula

Tarantula es tanto una métrica como una herramienta propuesta por primera vez en 2001 por investigadores del Instituto de Tecnología de Georgia . Fue desarrollado con el objetivo de proporcionar un programa independiente para ver las líneas de código de un programa completo .

Las líneas de códigos del programa estudiado se colorean allí siguiendo una fórmula que indica su grado de sospecha. Además del color, que varía desde el verde para las líneas no sospechosas hasta el rojo para las más sospechosas, un tinte indica la cantidad de veces que la línea se ha ejecutado realmente como resultado de las pruebas.

Estas dos piezas de información se combinan para producir una pantalla que indica el grado de sospecha asociado con cada fila.

AMPLIO

AMPLE (para analizar patrones de métodos para localizar errores) es una herramienta para localizar errores en software escrito en Java desarrollada por investigadores de la Universidad del Saarland en 2005. Su enfoque está orientado a objetos con la clase como unidad de estudio.

Implementado como un complemento para Eclipse , se integra con marcos como JUnit para recopilar los resultados de ejecución de un conjunto de pruebas.

Su funcionamiento se basa en el estudio de las secuencias de llamadas entre los métodos ejecutados durante las pruebas. Al comparar las secuencias entre ejecutar una prueba exitosa y una prueba fallida, AMPLE dirige al desarrollador a la fuente probable del problema. De hecho, es menos probable que las secuencias o fragmentos de secuencias presentes en las 2 ejecuciones lleven errores que los métodos llamados solo en la ejecución defectuosa.

Las secuencias se comparan en una longitud k , elegida en función del nivel de granularidad deseado. Para cada secuencia encontrada en la ejecución fallida y ausente en la ejecución exitosa, se extrae la clase de matriz del objeto en el que se realizan las llamadas faltantes. Al final de la comparación, las clases se ordenan por número promedio de ocurrencias únicas en ejecuciones fallidas.

GZoltar

GZoltar es un marco de error de localización establecido originalmente en 2010 y disponible como complemento Eclipse .

Esta herramienta brinda una opción de visualización y una mejor integración con el entorno del desarrollador a Zoltar, un marco desarrollado originalmente por investigadores de la Universidad Tecnológica de Delft .

El desarrollo luego dio como resultado un software que producía resultados textuales, así como una interfaz no integrada en forma de XZoltar. El código de GZoltar está destinado a ser reutilizado por otros desarrolladores en forma de biblioteca. Al igual que otros complementos como AMPLE, se integra con Eclipse para explotar los resultados producidos por marcos de prueba como JUnit .

Utiliza principalmente la métrica Ochiai para evaluar la sospecha de líneas de código y luego representa gráficamente el resultado. Los cálculos de sospecha los realiza Zoltar utilizando la métrica Ochiai y el resultado se renderiza en 3D utilizando OpenGL .

EzUnit

EzUnit es un marco para la localización de errores desarrollado inicialmente en 2007 en forma de un complemento de Eclipse .

Se integra en el entorno del desarrollador ofreciendo el lanzamiento de pruebas escritas utilizando un marco de prueba como JUnit . EzUnit4, la versión más reciente ofrece una opción para ver gráficos de llamadas.

Los nodos del gráfico producido se colorean luego de acuerdo con el grado de sospecha sobre las llamadas al método. El color varía de verde a rojo para indicar la ubicación probable del error.

Referencias

Paul Jaccard 1901 , p. 547--579
Akira Ochiai 1957 , p. 526–530
Paul F RUSSELL, T Ramachandra Rao y otros, 1940 , p. 153-178
T. Sørensen 1948 , p. 1-34
David J. Rogers y Taffee T. Tanimoto 1960 , p. 1115-1118
Michael R Anderberg 1973
R. R. Sokal y Michener CD 1958 , p. 1409-1438
Richard W Hamming 1950 , p. 147–160
Leo A Goodman y William H de Kruskal 1954 , p. 732–764
Fernando Lourenco, Victor Lobo y Fernando Bacao 2004
James A. Jones, Mary Jean Harrold y John T. Stasko 2001 , p. 71–75
Valentin Dallmeier, Christian Lindig y Andreas Zeller 2005 , Monterey, California, EE . UU., P. 99-104
A Gonzalez 2007
W. Eric Wong et al. 2007 , Washington, DC, EE . UU., Pág. 449-456
Valentin Dallmeier, Christian Lindig y Andreas Zeller 2005 , Monterey, California, EE.UU., p. 99-104
Lee R Dice , 1945 , p. 297-302
Brian Sidney Everitt 1978 , Nueva York
Lee Naish, Hua Jie Lee y Kotagiri Ramamohanarao 2011 , Nueva York, NY, EE.UU., p. 11: 1–11: 32
Ben Liblit et al. 2005 , pág. 15-26
Rui Abreu y col. 2009 , Nueva York, NY, EE . UU., Pág. 1780-1792
Lucia Lucia et al. 2014 , pág. 172–219
Shaowei Wang y col. 2011 , Washington, DC, EE . UU., Pág. 556–559
Feng Ji Xuan y Martin Monperrus 2014
MY Chen et al. 2002 , pág. 595–604
James A. Jones, Mary Jean Harrold y John T. Stasko 2001 , p. 71–75
André Riboira y Rui Abreu 2010 , p. 215–218
T. Janssen, R. Abreu y AJC van Gemund 2009 , p. 662–664
(in) " GZoltar " (consultado el 14 de diciembre de 2014 )
(en) " EzUnit " (consultado el 14 de diciembre de 2014 )
(in) " EzUnit4 " (consultado el 14 de diciembre de 2014 )

Bibliografía

(en) Rui Abreu , Peter Zoeteweij , Rob Golsteijn y Arjan JC van Gemund , “ Una evaluación práctica de la localización de fallas basada en el espectro ” , J. Syst. Softw. , Nueva York, NY, EE.UU., Elsevier Science Inc., vol. 82, n o 11,noviembre de 2009, p. 1780–1792 ( ISSN 0164-1212 , DOI 10.1016 / j.jss.2009.06.035 , leer en línea )
(en) Michael R Anderberg , Análisis de conglomerados para aplicaciones ,1973
(en) Mike Y. Chen , Emre Kiciman , Eugene Fratkin , Armando Fox y Eric Brewer , “ Pinpoint: Problem Determination in Large, Dynamic Internet Services ” , Actas de la Conferencia internacional de 2002 sobre redes y sistemas confiables , Washington, DC, EE. UU. , IEEE Computer Society, dSN '02,2002, p. 595–604 ( ISBN 0-7695-1597-5 , leer en línea )
(en) Valentin Dallmeier , Christian Lindig y Andreas Zeller , " Lightweight Bug Localization with AMPLE " , Actas del sexto simposio internacional sobre depuración automatizada basada en análisis , Nueva York, NY, EE. UU., ACM, aADEBUG'05,2005, p. 99–104 ( ISBN 1-59593-050-7 , DOI 10.1145 / 1085130.1085143 , leer en línea )
(en) Lee R Dice , “ Medidas de la cantidad de asociación ecológica entre especies ” , Ecología , JSTOR, vol. 26, n o 3,1945, p. 297-302
(en) Brian Sidney Everitt , Técnicas gráficas para datos multivariantes , Nueva York, Holanda Septentrional,1978( ISBN 0-444-19461-4 )
(es) A González , Técnicas de detección automática de errores basadas en invariantes dinámicos ,2007
(en) Leo A Goodman y William H Kruskal , “ Medidas de asociación para clasificaciones cruzadas * ” , Revista de la Asociación Estadounidense de Estadística , Taylor \ & Francis, vol. 49, n o 268,1954, p. 732–764
(en) Richard W Hamming , " Códigos de detección y corrección de errores " , Bell System Technical Journal , Wiley Online Library, vol. 29, n o 21950, p. 147–160
Paul Jaccard , " Estudio comparativo de la distribución floral en una porción de los Alpes y Jura ", Boletín del la Société Vaudoise des Sciences Naturelles , vol. 37,1901, p. 547–579
(en) A. James , Jean Mary y T. John , “ Visualización para la localización de fallas ” , Actas del Taller sobre visualización de software (SoftVis), 23ª Conferencia Internacional sobre Ingeniería de Software ,Mayo de 2001, p. 71–75
(en) T. Janssen , R. Abreu y AJC van Gemund , “ Zoltar: Un conjunto de herramientas para la localización automática de fallas ” , Ingeniería de software automatizada, 2009. ASE '09. 24a Conferencia Internacional IEEE / ACM sobre ,noviembre de 2009, p. 662-664 ( ISSN 1938-4300 , DOI 10.1109 / ASE.2009.27 )
(en) Ben Liblit , Mayur Naik , Alice X Zheng , Alex Aiken y Michael I Jordan , " Aislamiento de errores estadísticos escalables " , ACM SIGPLAN Notices , ACM, vol. 40, n o 6,2005, p. 15-26
(en) Fernando Lourenco , Victor Lobo y Fernando Bacao , “ Medidas de similitud de base binaria para datos categóricos y su aplicación en Mapas Autoorganizados ” , JOCLAD ,2004
(en) Lucia Lucia , David Lo , Lingxiao Jiang , Ferdian Thung y Aditya Budi , “ Estudio integral extendido de medidas de asociación para la localización de fallas ” , Journal of Software: Evolution and Process , vol. 26, n o 22014, p. 172–219 ( ISSN 2047-7481 , DOI 10.1002 / smr.1616 , leer en línea )
(en) Lee Naish , Hua Jie Lee y Kotagiri Ramamohanarao , " Un modelo para el diagnóstico de software basado en espectros " , ACM Trans. Softw. Ing. Methodol. , Nueva York, NY, EE.UU., ACM, vol. 20, n o 3,agosto 2011, p. 11: 1-11: 32, artículo n o 11 ( ISSN 1049-331X , DOI 10.1145 / 2000791.2000795 , leer en línea )
(ja) Akira Ochiai , “ Estudios zoogeográficos sobre los peces soleoides encontrados en Japón y sus regiones vecinas ” , Bull. Jpn. Soc. Sci. Pescado , vol. 22, n o 9,1957, p. 526–530
(en) Paul F RUSSELL , T Ramachandra Rao y otros , “ Sobre el hábitat y la asociación de especies de larvas anofelinas en el sudeste de Madras. ” , Revista del Instituto de Malaria de la India , vol. 3, n o 1,1940, p. 153-178
(en) André Riboira y Rui Abreu , “ El proyecto GZoltar: una interfaz gráfica de depuración ” , Pruebas - Práctica y técnicas de investigación , Springer Berlin Heidelberg, Notas de la conferencia en Ciencias de la Computación, vol. 6303,2010, p. 215-218 ( ISBN 978-3-642-15584-0 , DOI 10.1007 / 978-3-642-15585-7_25 , leer en línea )
(en) David J. Rogers y Taffee T. Tanimoto , " Un programa informático para clasificar plantas " , Ciencia , Asociación Estadounidense para el Avance de la Ciencia, vol. 132, n o 3434,21 de octubre de 1960, p. 1115–1118 ( ISSN 1095-9203 , PMID 17790723 , DOI 10.1126 / science.132.3434.1115 , leer en línea )
(en) Wang Shaowei , D. Lo , Jiang Lingxiao , Lucia y Chuin Hoong , " Localización de fallas basada en búsquedas " , Ingeniería de software automatizada (ASE), 26ª Conferencia internacional IEEE / ACM de 2011 ,noviembre 2011, p. 556-559 ( ISSN 1938-4300 , DOI 10.1109 / ASE.2011.6100124 )
(en) RR Sokal y CD Michener , " Un método estadístico para evaluar relaciones sistemáticas " , University of Kansas Science Bulletin , vol. 38,1958, p. 1409-1438
(en) T. Sørensen , “ Un método para establecer grupos de igual amplitud en sociología vegetal basado en la similitud de especies y su aplicación a los análisis de la vegetación en los comunes daneses ” , Biol. Skr. , vol. 5,1948, p. 1-34
(en) W. Eric Wong , Yu Qi , Lei Zhao y Kai-Yuan Cai , " Localización efectiva de fallas mediante la cobertura del código " , Actas de la 31ª Conferencia Anual Internacional de Aplicaciones y Software Informático - Volumen 01 , Washington, DC, EE. UU., IEEE Sociedad de Informática, cOMPSAC '07,2007, p. 449–456 ( ISBN 0-7695-2870-8 , DOI 10.1109 / COMPSAC.2007.109 , leer en línea )
(en) Jifeng Xuan y Martin Monperrus , " Aprendiendo a combinar múltiples métricas de clasificación para la localización de fallas " , Actas de la 30ª Conferencia Internacional sobre Mantenimiento y Evolución de Software ,2014( leer en línea )