La inyección de fallas es una técnica de prueba que ayuda a comprender cómo se comporta un sistema [virtual / real] cuando está sometido a tensiones de formas inusuales. [1] Esta técnica se basa en el resultado de una simulación o experimento, por lo que puede ser más válida (o más cercana a la realidad) en comparación con los métodos estadísticos.
En las pruebas de software , la inyección de fallas es una técnica para mejorar la cobertura de una prueba mediante la introducción de fallas en las rutas de código de prueba, en particular las rutas de código de manejo de errores , que de otra manera raramente se seguirían. A menudo se utiliza con pruebas de estrés y se considera que es una parte importante del desarrollo de software robusto . [2] Las pruebas de robustez [3] (también conocidas como pruebas de sintaxis, fuzzing o fuzz testing ) son un tipo de inyección de fallas que se usa comúnmente para probar vulnerabilidades en interfaces de comunicación como protocolos, parámetros de línea de comandos o API.
La propagación de una falla hasta una falla observable sigue un ciclo bien definido. Cuando se ejecuta, una falla puede causar un error, que es un estado no válido dentro de los límites del sistema. Un error puede causar más errores dentro del límite del sistema, por lo tanto, cada nuevo error actúa como una falla, o puede propagarse al límite del sistema y ser observable. Cuando se observan estados de error en los límites del sistema, se denominan fallas. Este mecanismo se denomina ciclo de falla-error-falla [4] y es un mecanismo clave en la confiabilidad .
Historia
La técnica de inyección de fallas se remonta a la década de 1970 [5] cuando se utilizó por primera vez para inducir fallas a nivel de hardware. Este tipo de inyección de fallas se denomina Inyección de fallas implementadas por hardware (HWIFI) e intenta simular fallas de hardware dentro de un sistema. Los primeros experimentos en fallas de hardware no involucraron nada más que cortocircuitar las conexiones en las placas de circuitos y observar el efecto en el sistema (puentear fallas). Se utilizó principalmente como prueba de la confiabilidad del sistema de hardware. Posteriormente se desarrolló hardware especializado para extender esta técnica, como dispositivos para bombardear áreas específicas de una placa de circuito con radiación intensa. Pronto se descubrió que las técnicas de software podían inducir fallas y que algunos aspectos de esta técnica podrían ser útiles para evaluar sistemas de software. En conjunto, estas técnicas se conocen como inyección de fallas implementadas por software (SWIFI).
Modelo de inyección de fallas implementadas
Al aumentar la complejidad de los sistemas ciberfísicos, la aplicación de métodos tradicionales de inyección de fallas ya no es eficiente, por lo que el probador intenta utilizar la inyección de fallas en el nivel de modelo.
Inyección de fallas implementada por software
Las técnicas SWIFI para la inyección de fallas de software se pueden clasificar en dos tipos: inyección en tiempo de compilación e inyección en tiempo de ejecución.
La inyección en tiempo de compilación es una técnica de inyección en la que el código fuente se modifica para inyectar fallas simuladas en un sistema. Un método se llama prueba de mutación que cambia las líneas de código existentes para que contengan fallas. Un ejemplo simple de esta técnica podría cambiar a = a + 1
aa = a – 1
La mutación de código produce fallas que son muy similares a las agregadas involuntariamente por los programadores.
Un refinamiento de la mutación de código es la inyección de fallas de inserción de código, que agrega código, en lugar de modificar el código existente. Esto generalmente se hace mediante el uso de funciones de perturbación que son funciones simples que toman un valor existente y lo perturban a través de alguna lógica en otro valor, por ejemplo
int pFunc ( int valor ) { valor de retorno + 20 ; } int main ( int argc , char * argv []) { int a = pFunc ( aFunction ( atoi ( argv [ 1 ]))); if ( a > 20 ) { / * haz algo * / } else { / * haz algo más * / } }
En este caso, pFunc es la función de perturbación y se aplica al valor de retorno de la función que se ha llamado introduciendo una falla en el sistema.
Las técnicas de inyección en tiempo de ejecución utilizan un disparador de software para inyectar una falla en un sistema de software en ejecución. Las fallas se pueden inyectar a través de varios métodos físicos y los activadores se pueden implementar de varias formas, tales como: Activadores basados en el tiempo (cuando el temporizador llega a un tiempo especificado, se genera una interrupción y el manejador de interrupciones asociado con el temporizador puede inyectar el culpa. ); Disparadores basados en interrupciones (las excepciones de hardware y los mecanismos de captura de software se utilizan para generar una interrupción en un lugar específico del código del sistema o en un evento particular dentro del sistema, por ejemplo, el acceso a una ubicación de memoria específica).
Las técnicas de inyección en tiempo de ejecución pueden usar varias técnicas diferentes para insertar fallas en un sistema a través de un disparador.
- Corrupción del espacio de la memoria: esta técnica consiste en corromper la RAM, los registros del procesador y el mapa de E / S.
- Técnicas de interposición de llamadas al sistema: se trata de la propagación de fallas desde las interfaces del kernel del sistema operativo hasta el software del sistema en ejecución. Esto se hace interceptando las llamadas al sistema operativo realizadas por el software de nivel de usuario e inyectando fallas en ellas.
- Inyección de fallas a nivel de red: esta técnica se ocupa de la corrupción, pérdida o reordenamiento de paquetes de red en la interfaz de red.
Estas técnicas a menudo se basan en las facilidades de depuración que proporcionan las arquitecturas de procesadores de computadoras.
Inyección de fallas de software de protocolo
Los sistemas de software complejos, especialmente los sistemas distribuidos de múltiples proveedores basados en estándares abiertos, realizan operaciones de entrada / salida para intercambiar datos a través de intercambios estructurados con estado conocidos como " protocolos ". Un tipo de inyección de fallas que es particularmente útil para probar implementaciones de protocolos (un tipo de código de software que tiene la característica inusual de que no puede predecir o controlar su entrada) es fuzzing . Fuzzing es una forma especialmente útil de prueba de caja negra, ya que las diversas entradas no válidas que se envían al sistema de software no dependen y no se crean en base al conocimiento de los detalles del código que se ejecuta dentro del sistema.
Inyección de fallas implementadas por hardware
Esta técnica se aplicó en un prototipo de hardware. Los probadores inyectan fallas cambiando el voltaje de algunas partes en un circuito, aumentando o disminuyendo la temperatura, bombardeando la placa con radiación de alta energía, etc.
Inyección eficiente de fallas
Las fallas tienen tres parámetros principales. [6]
- Tipo: ¿Qué tipo de falla se debe inyectar? Por ejemplo, pegado al valor, retardo, ignorar algunas funciones, ignorar algunos parámetros / variables, fallas aleatorias, la falla de polarización, el ruido, etc. La amplitud de cada falla también es importante.
- Hora: ¿Cuándo debería activarse? Por ejemplo, el tiempo de activación de la falla o la condición de activación de la falla.
- Ubicación: ¿Dónde debería estar en el sistema? Por ejemplo, falla en el enlace / conexión entre sistemas, fallas dentro de sistemas / subsistemas / función, etc.
Estos parámetros crean el reino del espacio de fallas. El ámbito del espacio de fallas aumentará exponencialmente al aumentar la complejidad del sistema. Por lo tanto, el método tradicional de inyección de fallas no será aplicable para su uso en los sistemas ciberfísicos modernos, porque serán muy lentos y encontrarán una pequeña cantidad de fallas (menos cobertura de fallas). Por lo tanto, los probadores necesitan un algoritmo eficiente para elegir fallas críticas que tengan un mayor impacto en el comportamiento del sistema. Por lo tanto, la principal pregunta de investigación es cómo encontrar fallas críticas en el ámbito del espacio de fallas que tengan efectos catastróficos en el comportamiento del sistema. Estos son algunos métodos que pueden ayudar a la inyección de fallas a explorar de manera eficiente el espacio de fallas para alcanzar una mayor cobertura de fallas en menos tiempo de simulación.
- Análisis de sensibilidad: [7] En este método, el análisis de sensibilidad se ha utilizado para identificar las señales más importantes que tienen un mayor impacto en la especificación del sistema. Al identificar esas señales o parámetros importantes, la herramienta de inyección de fallas se enfocará en esas señales efectivas en lugar de enfocarse en todas las señales del sistema.
- Aprendizaje por refuerzo: [8] En este método, el algoritmo de aprendizaje por refuerzo se ha utilizado para explorar de manera eficiente el espacio de fallas y encontrar fallas críticas.
Herramientas de inyección de fallas
Aunque este tipo de fallas se pueden inyectar a mano, la posibilidad de introducir una falla no intencional es alta, por lo que existen herramientas para analizar un programa automáticamente e insertar fallas.
Herramientas de investigación
Se han desarrollado varias herramientas SWIFI y aquí se ofrece una selección de estas herramientas. Seis herramientas de inyección de fallas de uso común son Ferrari, FTAPE, Doctor, Orchestra, Xception y Grid-FIT.
- MODIFI (inyección de fallas implementadas por MODel) es una herramienta de inyección de fallas para la evaluación de la robustez de los modelos de comportamiento de Simulink. Es compatible con el modelado de fallas en XML para la implementación de modelos de fallas específicos del dominio. [9]
- Ferrari (Fault and ERR o Automatic Real-time Injection) se basa en trampas de software que inyectan errores en un sistema. Las trampas se activan mediante una llamada a una ubicación de memoria específica o un tiempo de espera. Cuando se llama una trampa, el controlador inyecta una falla en el sistema. Las fallas pueden ser transitorias o permanentes. La investigación realizada con Ferrari muestra que la detección de errores depende del tipo de falla y de dónde se inserta la falla. [10]
- FTAPE (Fault Tolerance and Performance Evaluator) puede inyectar fallas, no solo en la memoria y los registros, sino también en los accesos al disco. Esto se logra insertando un controlador de disco especial en el sistema que puede inyectar fallas en los datos enviados y recibidos desde la unidad de disco. FTAPE también tiene una unidad de carga sintética que puede simular cantidades específicas de carga para propósitos de pruebas de robustez. [11]
- DOCTOR (entorno de inyección de fallas de software integrado) permite la inyección de memoria y registrar fallas, así como fallas de comunicación de red. Utiliza una combinación de tiempo de espera, captura y modificación de código. Los disparadores de tiempo de espera inyectan fallas de memoria transitorias y las trampas inyectan fallas de hardware emuladas transitorias, como la corrupción de registros. La modificación de código se utiliza para inyectar fallas permanentes. [12]
- Orchestra es un inyector de fallas controlado por script que se basa en la inyección de fallas a nivel de red. Su uso principal es la evaluación y validación de las características de temporización y tolerancia a fallos de los protocolos distribuidos. Orchestra se desarrolló inicialmente para el sistema operativo Mach y utiliza ciertas características de esta plataforma para compensar las latencias introducidas por el inyector de fallas. También se ha portado con éxito a otros sistemas operativos. [13]
- Xception está diseñado para aprovechar las funciones de depuración avanzadas disponibles en muchos procesadores modernos. Está escrito para no requerir ninguna modificación de la fuente del sistema ni la inserción de trampas de software, ya que las capacidades de manejo de excepciones del procesador desencadenan la inyección de fallas. Estos desencadenantes se basan en accesos a ubicaciones de memoria específicas. Dichos accesos pueden ser para datos o para obtener instrucciones. Por lo tanto, es posible reproducir con precisión las ejecuciones de prueba porque los desencadenantes se pueden vincular a eventos específicos, en lugar de tiempos de espera. [5]
- Grid-FIT (Grid - Tecnología de inyección de fallas) [14] es un método y una herramienta de evaluación de la confiabilidad para evaluar los servicios de la red mediante inyección de fallas. Grid-FIT se deriva de un inyector de fallas anterior WS-FIT [15] que estaba destinado a los servicios web Java implementados mediante el transporte Apache Axis. Grid-FIT utiliza un mecanismo de inyección de fallas novedoso que permite utilizar la inyección de fallas a nivel de red para brindar un nivel de control similar a la inyección de fallas por inserción de código, pero que es menos invasivo. [dieciséis]
- LFI (Library-level Fault Injector) [17] es un conjunto de herramientas de prueba automático, que se utiliza para simular en un entorno de prueba controlado, situaciones excepcionales que los programas necesitan manejar en tiempo de ejecución pero que no son fáciles de verificar mediante pruebas de entrada solamente. LFI identifica automáticamente los errores expuestos por las bibliotecas compartidas, encuentra el código de recuperación de errores potencialmente defectuoso en los binarios del programa e inyecta las fallas deseadas en el límite entre las bibliotecas compartidas y las aplicaciones.
- ChaosMachine, [18] una herramienta que hace ingeniería del caos a nivel de aplicación en la JVM. Se concentra en analizar la capacidad de manejo de errores de cada bloque try-catch involucrado en la aplicación inyectando excepciones.
- TripleAgent, [19] un sistema de evaluación y mejora de la resiliencia para aplicaciones Java. La característica única de TripleAgent es combinar el monitoreo automatizado, la inyección automatizada de perturbaciones y la mejora automatizada de la resiliencia.
- FIBlock (Fault Injection Block), [20] un método de inyección de fallas basado en modelos implementado como un bloque Simulink altamente personalizable. Admite la inyección en modelos de MATLAB Simulink de fallas típicas de componentes heterogéneos esenciales de sistemas ciberfísicos, como sensores, hardware informático y redes. Las entradas y salidas de disparo adicionales del bloque permiten el modelado de fallas condicionales. Además, dos o más FIBlocks conectados con las señales de disparo pueden modelar los llamados errores encadenados.
Herramientas comerciales
- Más allá de la seguridad beSTORM [21] es una herramienta comercial de análisis de seguridad de software de caja negra . A menudo se usa durante el desarrollo por los fabricantes de equipos originales, pero también se usa para probar productos antes de su implementación, especialmente en el sector aeroespacial, bancario y de defensa. El proceso de prueba de beSTORM comienza con los escenarios de ataque más probables, luego recurre a un fuzzing exhaustivo basado en la generación . beSTORM proporciona módulos para protocolos comunes y 'autoaprendizaje' de protocolos nuevos o propietarios, incluidos los ataques basados en mutaciones. Aspectos destacados: análisis binario y textual, pruebas de protocolos personalizados, depuración y seguimiento de pila, lenguaje de desarrollo independiente, compatible con CVE.
- ExhaustiF es una herramienta de software comercial que se utiliza para las pruebas de caja gris basadas en la inyección de fallas de software (SWIFI) para mejorar la confiabilidad de los sistemas con uso intensivo de software. La herramienta se puede utilizar durante la integración del sistema y las fases de prueba del sistema de cualquier ciclo de vida de desarrollo de software, complementando también otras herramientas de prueba. ExhaustiF puede inyectar fallas tanto en el software como en el hardware. Al inyectar fallas simuladas en el software, ExhaustiF ofrece los siguientes tipos de fallas: Corrupción variable y Corrupción de procedimientos. El catálogo de inyecciones de fallas de hardware incluye fallas en la memoria (E / S, RAM) y CPU (unidad entera, unidad flotante). Hay diferentes versiones disponibles para RTEMS / ERC32, RTEMS / Pentium, Linux / Pentium y MS-Windows / Pentium. [22]
- Holodeck [23] es una herramienta de prueba desarrollada por Security Innovation que utiliza la inyección de fallas para simular errores de aplicaciones y sistemas del mundo real para aplicaciones y servicios de Windows. Los clientes de Holodeck incluyen muchas de las principales empresas de desarrollo de software comercial, incluidas Microsoft, Symantec, EMC y Adobe. Proporciona un entorno controlado y repetible en el que analizar y depurar el código de manejo de errores y las superficies de ataque de las aplicaciones para las pruebas de fragilidad y seguridad. Simula fallas de fuzzing de archivos y redes, así como una amplia gama de otras fallas de recursos, sistemas y definidas de manera personalizada. Analiza el código y recomienda planes de prueba y también realiza el registro de llamadas de funciones, la intercepción de API, las pruebas de estrés, el análisis de cobertura de código y muchas otras funciones de garantía de seguridad de las aplicaciones.
- La plataforma de ingeniería del caos de Proofdock se centra en la plataforma en la nube de Microsoft Azure . Inyecta fallas a nivel de infraestructura, plataforma y aplicación.
- Gremlin es una plataforma de "falla como servicio" que ayuda a las empresas a construir sistemas más resistentes mediante la práctica de la ingeniería del caos. Gremlin recrea las fallas más comunes en tres categorías: recursos , red y estado, inyectando de manera segura las fallas en los sistemas para identificar y corregir de manera proactiva las fallas desconocidas.
- Codenomicon Defensics [24] es un marco de automatización de pruebas de caja negra que inyecta fallas en más de 150 interfaces diferentes, incluidos protocolos de red, interfaces API, archivos y estructuras XML. El producto comercial se lanzó en 2001, después de cinco años de investigación en la Universidad de Oulu en el área de inyección de fallas de software. VTT, uno de los miembros del consorcio PROTOS, publicó un trabajo de tesis que explica los principios de fuzzing utilizados. [3]
- Mu Service Analyzer [25] es una herramienta de prueba de servicios comerciales desarrollada por Mu Dynamics . [26] El Mu Service Analyzer realiza pruebas de caja negra y caja blanca de servicios basados en sus interfaces de software expuestas, utilizando simulaciones de denegación de servicio, variaciones de tráfico de nivel de servicio (para generar entradas no válidas) y la reproducción de activadores de vulnerabilidad conocidos. Todas estas técnicas ejercitan la validación de entrada y el manejo de errores y se utilizan junto con monitores de protocolo válidos y SNMP para caracterizar los efectos del tráfico de prueba en el sistema de software. Mu Service Analyzer permite a los usuarios establecer y rastrear métricas de confiabilidad, disponibilidad y seguridad a nivel del sistema para cualquier implementación de protocolo expuesta. La herramienta ha estado disponible en el mercado desde 2005 por clientes en América del Norte, Asia y Europa, especialmente en los mercados críticos de operadores de red (y sus proveedores) y sistemas de control industrial (incluida la infraestructura crítica ).
- Xception [27] es una herramienta de software comercial desarrollada por Critical Software SA [28] que se utiliza para pruebas de caja negra y caja blanca basadas en inyección de fallas de software (SWIFI) e inyección de fallas en cadena de escaneo (SCIFI). Xception permite a los usuarios probar la solidez de sus sistemas o solo parte de ellos, lo que permite tanto la inyección de fallas de software como la inyección de fallas de hardware para un conjunto específico de arquitecturas. La herramienta se ha utilizado en el mercado desde 1999 y tiene clientes en los mercados americano, asiático y europeo, especialmente en el crítico mercado aeroespacial y de telecomunicaciones. La familia completa de productos Xception incluye: a) La herramienta principal Xception, un líder de vanguardia en tecnología de inyección de fallas implementadas por software (SWIFI); b) Las herramientas complementarias Easy Fault Definition (EFD) y Xtract (Xception Analysis Tool); c) La herramienta Xception extendida (eXception), con las extensiones de inyección de fallas para Scan Chain y forzado a nivel de pin.
Bibliotecas
- libfiu (Inyección de fallas en el espacio de usuario), biblioteca C para simular fallas en las rutinas POSIX sin modificar el código fuente. Se incluye una API para simular fallas arbitrarias en tiempo de ejecución en cualquier punto del programa.
- TestApi es una biblioteca de API de fuente compartida, que proporciona facilidades para pruebas de inyección de fallas, así como otros tipos de pruebas, estructuras de datos y algoritmos para aplicaciones .NET.
- Fuzzino es una biblioteca de código abierto, que proporciona un rico conjunto de heurísticas fuzzing que se generan a partir de una especificación de tipo y / o valores válidos.
Inyección de fallas en propiedades funcionales o casos de prueba
A diferencia de las pruebas de mutación tradicionales en las que se generan fallas mutantes y se inyectan en la descripción del código del modelo, también se ha investigado la aplicación de una serie de operadores de mutación recién definidos directamente a las propiedades del modelo en lugar de al código del modelo. [29] Las propiedades mutantes que se generan a partir de las propiedades iniciales (o casos de prueba) y validadas por el verificador del modelo deben considerarse como nuevas propiedades que se han perdido durante el procedimiento de verificación inicial. Por lo tanto, agregar estas propiedades recientemente identificadas a la lista existente de propiedades mejora la métrica de cobertura de la verificación formal y, en consecuencia, conduce a un diseño más confiable.
Aplicación de inyección de fallas
La inyección de fallas puede tomar muchas formas. En la prueba de sistemas operativos, por ejemplo, la inyección de fallas a menudo la realiza un controlador ( software en modo kernel ) que intercepta las llamadas al sistema (llamadas al kernel) y devuelve aleatoriamente una falla para algunas de las llamadas. Este tipo de inyección de fallas es útil para probar software de modo de usuario de bajo nivel. Para software de nivel superior, varios métodos inyectan fallas. En código administrado , es común usar instrumentación . Aunque la inyección de fallas se puede realizar a mano, existen varias herramientas de inyección de fallas para automatizar el proceso de inyección de fallas. [30]
Dependiendo de la complejidad de la API para el nivel donde se inyectan las fallas, las pruebas de inyección de fallas a menudo deben diseñarse cuidadosamente para minimizar el número de falsos positivos. Incluso una prueba de inyección de fallas bien diseñada a veces puede producir situaciones que son imposibles en el funcionamiento normal del software. Por ejemplo, imagina que hay dos API funciones , Commit
y PrepareForCommit
, de tal manera que solo, cada una de estas funciones, posiblemente, puede fallar, pero si PrepareForCommit
se llama y tiene éxito, una llamada posterior a Commit
está garantizado para tener éxito. Ahora considere el siguiente código:
error = PrepareForCommit (); if ( error == SUCCESS ) { error = Commit (); afirmar ( error == ÉXITO ); }
A menudo, no será factible que la implementación de la inyección de fallas realice un seguimiento del estado suficiente para hacer la garantía que hacen las funciones de la API. En este ejemplo, una prueba de inyección de fallas del código anterior podría afectar a la aserción , mientras que esto nunca sucedería en el funcionamiento normal.
La inyección de fallas se puede utilizar en el momento de la prueba, durante la ejecución de casos de prueba. [31] Por ejemplo, el algoritmo de prueba de cortocircuito [31] inyecta excepciones durante la ejecución de la serie de pruebas para simular errores imprevistos. Este algoritmo recopila datos para verificar dos propiedades de resiliencia.
Ver también
- Bebugging
- Prueba de mutación
Referencias
- ^ Moradi, Mehrdad; Van Acker, Bert; Vanherpen, Ken; Denil, Joachim (2019). Chamberlain, Roger; Taha, Walid; Törngren, Martin (eds.). "Inyección de fallas híbridas implementadas en modelos para Simulink (demostraciones de herramientas)". Sistemas ciberfísicos. Diseño basado en modelos . Apuntes de conferencias en Ciencias de la Computación. Springer International Publishing. 11615 : 71–90. doi : 10.1007 / 978-3-030-23703-5_4 . ISBN 9783030237035.
- ^ J. Voas, "Inyección de fallas para las masas", Computadora, vol. 30, págs. 129-130, 1997.
- ↑ a b Kaksonen, Rauli. Un método funcional para evaluar la seguridad de la implementación del protocolo. 2001.
- ↑ A. Avizienis, J.-C. Laprie, Brian Randell y C. Landwehr, "Conceptos básicos y taxonomía de la informática segura y confiable", Computación segura y confiable, vol. 1, págs. 11–33, 2004.
- ^ a b J. V. Carreira, D. Costa y SJ G, "Fault Injection Spot-Checks Fiabilidad del sistema informático", IEEE Spectrum, págs. 50-55, 1999.
- ^ Benso, Alfredo; Prinetto, Paolo, eds. (2003). Técnicas y herramientas de inyección de fallas para la evaluación de la confiabilidad de los sistemas integrados . Fronteras en pruebas electrónicas. Springer EE. UU. ISBN 978-1-4020-7589-6.
- ^ "Optimización de la inyección de fallas en la co-simulación de FMI a través de la partición de sensibilidad | Actas de la Conferencia de simulación de verano de 2019" . dl.acm.org . Consultado el 14 de junio de 2020 .
- ^ Moradi, M., Oakes, BJ, Saraoglu, M., Morozov, A., Janschek, K. y Denil, J., 2020. EXPLORACIÓN DEL ESPACIO DE PARÁMETROS DE FALLA UTILIZANDO LA INYECCIÓN DE FALLA BASADA EN EL APRENDIZAJE DE REFUERZO.
- ^ Rickard Svenningsson, Jonny Vinter, Henrik Eriksson y Martin Torngren, "MODIFI: Una herramienta de inyección de fallas implementada por MODel", Notas de la conferencia en Ciencias de la Computación, 2010, Volumen 6351/2010, 210-222.
- ^ GA Kanawati, NA Kanawati y JA Abraham, "FERRARI: Un sistema flexible de inyección de errores y fallas basado en software", Transacciones de IEEE en computadoras, vol. 44, págs. 248, 1995.
- ^ T. Tsai y R. Iyer, "FTAPE: Una herramienta de inyección de fallas para medir la tolerancia a fallas", presentado en Informática aeroespacial, San Antonio; TX, 1995.
- ^ S. Han, KG Shin y HA Rosenberg, "DOCTOR: Un entorno de inyección de fallas de software integrado para sistemas distribuidos en tiempo real", presentado en el Simposio internacional de rendimiento y confiabilidad de computadoras, Erlangen; Alemania, 1995.
- ^ S. Dawson, F. Jahanian y T. Mitton, "ORCHESTRA: Un entorno de sondeo e inyección de fallas para las implementaciones de protocolos de prueba", presentado en el Simposio internacional de rendimiento y confiabilidad de computadoras, Urbana-Champaign, Estados Unidos, 1996.
- ^ Sitio web de Grid-FIT Archivado el 2 de febrero de 2008 en Wayback Machine.
- ^ N. Looker, B. Gwynne, J. Xu y M. Munro, "Un enfoque basado en la ontología para determinar la confiabilidad de las arquitecturas orientadas a servicios", en las actas del décimo taller internacional de IEEE sobre realidades orientadas a objetos time Dependable Systems, EE. UU., 2005.
- ^ N. Looker, M. Munro y J. Xu, "Una comparación de la inyección de fallas a nivel de red con inserción de código", en las actas de la 29ª Conferencia internacional de aplicaciones y software informático IEEE, Escocia, 2005.
- ^ Sitio web de LFI
- ^ Zhang, Long; Morin, Brice; Haller, Philipp; Baudry, Benoit; Monperrus, Martín (2019). "Un sistema de ingeniería del caos para análisis en vivo y falsificación de manejo de excepciones en la JVM". Transacciones IEEE sobre ingeniería de software : 1. arXiv : 1805.05246 . doi : 10.1109 / TSE.2019.2954871 . ISSN 0098-5589 . S2CID 46892241 .
- ^ Zhang, Long; Monperrus, Martín (2019). "TripleAgent: monitoreo, perturbación y olvido de fallas para la mejora automatizada de la resiliencia en aplicaciones Java". 2019 IEEE 30th International Symposium on Software Reliability Engineering (ISSRE) . IEEE: 116–127. arXiv : 1812.10706 . doi : 10.1109 / ISSRE.2019.00021 . ISBN 978-1-7281-4982-0.
- ^ Flatag (2020-05-16), Flatag / FIBlock , consultado el 16-05-2020
- ^ información del producto beSTORM
- ^ Sitio de la herramienta ExhaustiF SWIFI
- ^ Descripción general del producto Holodeck Archivado el 13 de octubre de 2008 en Wayback Machine.
- ^ Descripción general del producto Codenomicon Defensics
- ^ Analizador de servicios Mu
- ^ Mu Dynamics, Inc.
- ^ Sitio web de Xception
- ^ Software crítico SA
- ^ Abbasinasab, Ali; Mohammadi, Mehdi; Mohammadi, Siamak; Yanushkevich, Svetlana; Smith, Michael (2011). "Inyección de fallas mutantes en las propiedades funcionales de un modelo para mejorar las métricas de cobertura". 2011 XIV Congreso Euromicro sobre Diseño de Sistemas Digitales . págs. 422–425. doi : 10.1109 / DSD.2011.57 . ISBN 978-1-4577-1048-3. S2CID 15992130 .
- ^ N. Looker, M. Munro y J. Xu, "Simulación de errores en servicios web", Revista internacional de sistemas de simulación, ciencia y tecnología, vol. 5 de 2004.
- ^ a b Cornu, Benoit; Seinturier, Lionel; Monperrus, Martín (2015). "Análisis y transformación de manejo de excepciones mediante inyección de fallas: Estudio de resiliencia frente a excepciones imprevistas" . Tecnología de la información y el software . 57 : 66–76. CiteSeerX 10.1.1.670.3667 . doi : 10.1016 / j.infsof.2014.08.004 .
enlaces externos
- Software de certidumbre de Certess Inc.