stringtranslate.com

Oráculo de prueba

En las pruebas de software , un oráculo de pruebas (o simplemente oráculo ) es un proveedor de información que describe el resultado correcto en función de la entrada de un caso de prueba . Las pruebas con un oráculo implican comparar los resultados reales del sistema bajo prueba (SUT) con los resultados esperados proporcionados por el oráculo. [1]

El término "oráculo de prueba" fue introducido por primera vez en un artículo de William E. Howden. [2] Elaine Weyuker exploró trabajos adicionales sobre diferentes tipos de oráculos . [3]

Un oráculo puede funcionar por separado del SUT; se puede acceder a él en el momento de ejecución de la prueba , o se puede utilizar antes de ejecutar una prueba con los resultados esperados codificados en la lógica de la prueba. [4]

Sin embargo, las poscondiciones del método son parte del SUT, como oráculos automatizados en los modelos de diseño por contrato . [5]

Determinar la salida correcta para una entrada dada (y un conjunto de estados del programa o sistema) se conoce como el problema del oráculo o problema del oráculo de prueba , [6] : 507  que algunos consideran un problema relativamente difícil e implica trabajar con problemas relacionados con la controlabilidad y la observabilidad. [7]

Categorías

Una encuesta de literatura de investigación que abarcó el período 1978 a 2012 [6] encontró varias categorías potenciales de oráculos de prueba.

Especificado

Un oráculo especificado se asocia típicamente con enfoques formalizados para el modelado de software y la construcción de código de software. Está conectado con la especificación formal , [8] el diseño basado en modelos que se puede utilizar para generar oráculos de prueba, [9] la especificación de transición de estado para la cual se pueden derivar oráculos para ayudar a las pruebas basadas en modelos [10] y las pruebas de conformidad de protocolos , [11] y el diseño por contrato para el cual el oráculo de prueba equivalente es una afirmación .

Los oráculos de prueba especificados presentan una serie de desafíos. La especificación formal se basa en la abstracción, que a su vez puede tener naturalmente un elemento de imprecisión, ya que todos los modelos no pueden capturar todos los comportamientos. [6] : 514 

Derivado

Un oráculo de prueba derivado diferencia el comportamiento correcto del incorrecto mediante el uso de información derivada de artefactos del sistema. Estos pueden incluir documentación, resultados de ejecución del sistema y características de versiones del SUT. [6] : 514  Los conjuntos de pruebas de regresión (o informes) son un ejemplo de un oráculo de prueba derivado: se construyen sobre la suposición de que el resultado de una versión anterior del sistema se puede utilizar como ayuda (oráculo) para una versión futura del sistema. Las características de rendimiento medidas previamente se pueden utilizar como un oráculo para futuras versiones del sistema, por ejemplo, para activar una pregunta sobre la degradación potencial del rendimiento observada. La documentación textual de versiones anteriores del sistema se puede utilizar como base para guiar las expectativas en futuras versiones del sistema.

Un pseudo-oráculo [6] : 515  entra en la categoría de oráculo de prueba derivado. Un pseudo-oráculo, según la definición de Weyuker, [12] es un programa escrito por separado que puede tomar la misma entrada que el programa o SUT de modo que sus salidas se puedan comparar para entender si podría haber un problema que investigar.

Un oráculo parcial [6] : 515  es un híbrido entre un oráculo de prueba especificado y un oráculo de prueba derivado. Especifica propiedades importantes (pero no completas) del SUT. Por ejemplo, las pruebas metamórficas explotan dichas propiedades, llamadas relaciones metamórficas, en múltiples ejecuciones del sistema.

Implícito

Un oráculo de prueba implícito se basa en información y suposiciones implícitas. [6] : 518  Por ejemplo, puede haber alguna conclusión implícita de una falla del programa, es decir, un comportamiento no deseado: un oráculo para determinar que puede haber un problema. Hay varias formas de buscar y probar el comportamiento no deseado, ya sea que algunos lo llamen prueba negativa, donde hay subconjuntos especializados como fuzzing .

Los oráculos de prueba implícitos tienen limitaciones, ya que se basan en conclusiones y suposiciones implícitas. Por ejemplo, una falla de un programa o proceso puede no ser un problema prioritario si el sistema es tolerante a fallas y, por lo tanto, opera bajo una forma de autorreparación o autogestión . Los oráculos de prueba implícitos pueden ser susceptibles a falsos positivos debido a dependencias del entorno. Las pruebas basadas en propiedades se basan en oráculos implícitos.

Humano

Un humano puede actuar como un oráculo de pruebas. [7] Este enfoque se puede categorizar como cuantitativo o cualitativo. [6] : 519–520  Un enfoque cuantitativo tiene como objetivo encontrar la cantidad correcta de información para recopilar en un SUT (por ejemplo, resultados de pruebas) para que una parte interesada pueda tomar decisiones sobre la adecuación al propósito o el lanzamiento del software. Un enfoque cualitativo tiene como objetivo encontrar la representatividad e idoneidad de los datos de prueba de entrada y el contexto de la salida del SUT. Un ejemplo es usar datos de prueba realistas y representativos y dar sentido a los resultados (si son realistas). Estos pueden guiarse por enfoques heurísticos , como instintos viscerales, reglas generales, ayudas de listas de verificación y experiencia para ayudar a adaptar la combinación específica seleccionada para el SUT.

Ejemplos

Los oráculos de prueba se basan más comúnmente en especificaciones y documentación . [13] [14] Una especificación formal utilizada como entrada para el diseño basado en modelos y las pruebas basadas en modelos sería un ejemplo de un oráculo de prueba especificado . El oráculo basado en modelos utiliza el mismo modelo para generar y verificar el comportamiento del sistema. [15] La documentación que no es una especificación completa del producto, como una guía de uso o instalación, o un registro de características de rendimiento o requisitos mínimos de la máquina para el software, normalmente sería un oráculo de prueba derivado.

Un oráculo de consistencia compara los resultados de una ejecución de prueba con otra para comprobar su similitud. [16] Este es otro ejemplo de un oráculo de prueba derivado.

Un oráculo para un programa de software podría ser un segundo programa que utiliza un algoritmo diferente para evaluar la misma expresión matemática que el producto en prueba. Este es un ejemplo de un pseudo-oráculo, que es un oráculo de prueba derivado. [12] : 466 

Durante la búsqueda en Google , no tenemos un oráculo completo para verificar si la cantidad de resultados devueltos es correcta. Podemos definir una relación metamórfica [17] de modo que una búsqueda acotada posterior produzca menos resultados. Este es un ejemplo de un oráculo parcial, que es un híbrido entre un oráculo de prueba especificado y un oráculo de prueba derivado.

Un oráculo estadístico utiliza características probabilísticas, [18] por ejemplo, con el análisis de imágenes, donde se define un rango de certeza e incertidumbre para que el oráculo de prueba declare una coincidencia o no. Este sería un ejemplo de un enfoque cuantitativo en un oráculo de prueba humano.

Un oráculo heurístico proporciona resultados representativos o aproximados sobre una clase de entradas de prueba. [19] Este sería un ejemplo de un enfoque cualitativo en un oráculo de prueba humano.

Referencias

  1. ^ Earl T. Barr et al; El problema de Oracle en las pruebas de software: una encuesta , 2015
  2. ^ Howden, WE (julio de 1978). "Estudios teóricos y empíricos de pruebas de programas". IEEE Transactions on Software Engineering . 4 (4): 293–298. doi :10.1109/TSE.1978.231514.
  3. ^ Weyuker, Elaine J.; "La suposición de Oracle sobre las pruebas de programas", en Actas de la 13.ª Conferencia Internacional sobre Ciencias de Sistemas (ICSS), Honolulu, HI, enero de 1980 , págs. 44-49
  4. ^ Jalote, Pankaj; Un enfoque integrado para la ingeniería de software , Springer/Birkhäuser, 2005, ISBN 0-387-20881-X 
  5. ^ Meyer, Bertrand; Fiva, Arno; Ciupa, Ilinca; Leitner, Andreas; Wei, Yi; Stapf, Emmanuel (septiembre de 2009). "Programas que se ponen a prueba a sí mismos". Computer . 42 (9): 46–55. doi :10.1109/MC.2009.296.
  6. ^ abcdefgh Barr, Earl T.; Harman, Mark; McMinn, Phil; Shahbaz, Muzammil; Yoo, Shin (noviembre de 2014). "El problema de Oracle en las pruebas de software: una encuesta" (PDF) . IEEE Transactions on Software Engineering . 41 (5): 507–525. doi : 10.1109/TSE.2014.2372785 .
  7. ^ ab Ammann, Paul; y Offutt, Jeff; "Introducción a las pruebas de software, 2.ª edición", Cambridge University Press , 2016, ISBN 978-1107172012 
  8. ^ Börger, E (1999). "Diseño y análisis de sistemas de alto nivel utilizando máquinas de estados abstractos". En Hutter, D; Stephan, W; Traverso, P; Ullman, M (eds.). Métodos formales aplicados: tendencias de FM 98. Apuntes de clase en informática. Vol. 1641. págs. 1–43. CiteSeerX 10.1.1.470.3653 . doi :10.1007/3-540-48257-1_1. ISBN.  978-3-540-66462-8.
  9. ^ Peters, DK (marzo de 1998). "Uso de oráculos de prueba generados a partir de la documentación del programa". IEEE Transactions on Software Engineering . 24 (3): 161–173. CiteSeerX 10.1.1.39.2890 . doi :10.1109/32.667877. 
  10. ^ Utting, Mark; Pretschner, Alexander; Legeard, Bruno (2012). "Una taxonomía de enfoques de prueba basados ​​en modelos" (PDF) . Pruebas de software, verificación y confiabilidad . 22 (5): 297–312. doi :10.1002/stvr.456. ISSN  1099-1689.
  11. ^ Gaudel, Marie-Claude (2001). "Pruebas a partir de especificaciones formales, un enfoque genérico". En Craeynest, D.; Strohmeier, A (eds.). Tecnologías de software fiables: Ada-Europe 2001. Apuntes de clase en informática. Vol. 2043. págs. 35–48. doi :10.1007/3-540-45136-6_3. ISBN 978-3-540-42123-8.
  12. ^ ab Weyuker, EJ (noviembre de 1982). "Sobre la prueba de programas no comprobables". The Computer Journal . 25 (4): 465–470. doi : 10.1093/comjnl/25.4.465 .
  13. ^ Peters, Dennis K. (1995). Generación de un Oracle de prueba a partir de la documentación del programa (tesis de maestría en ingeniería). Universidad McMaster. CiteSeerX 10.1.1.69.4331 . 
  14. ^ Peters, Dennis K.; Parnas, David L. "Generación de un Oracle de prueba a partir de la documentación del programa" (PDF) . Actas del Simposio internacional de 1994 sobre pruebas y análisis de software . ISSTA. ACM Press. págs. 58–65.
  15. ^ Robinson, Harry; Pruebas basadas en modelos de estados finitos con un presupuesto limitado, STAR West 1999
  16. ^ Hoffman, Douglas; Análisis de una taxonomía para oráculos de prueba, Quality Week, 1998
  17. ^ Zhou, ZQ; Zhang, S.; Hagenbuchner, M.; Tse, TH; Kuo, F.-C.; Chen, TY (2012). "Pruebas funcionales automatizadas de servicios de búsqueda en línea". Pruebas de software, verificación y confiabilidad . 22 (4): 221–243. doi :10.1002/stvr.437. hdl : 10722/123864 .
  18. ^ Mayer, Johannes; Guderlei, Ralph (2004). "Prueba de oráculos mediante métodos estadísticos" (PDF) . Actas del Primer Taller Internacional sobre Calidad de Software, Lecture Notes in Informatics . Primer Taller Internacional sobre Calidad de Software. Springer. págs. 179–189.
  19. ^ Hoffman, Douglas; Oráculos de pruebas heurísticas, Revista de ingeniería de calidad y pruebas de software, 1999

Bibliografía