La investigación [1] y la literatura [2] sobre pruebas de concurrencia y pruebas concurrentes generalmente se enfocan en probar software y sistemas que usan computación concurrente . El propósito es, como ocurre con la mayoría de las pruebas de software , comprender el comportamiento y el rendimiento de un sistema de software que utiliza computación concurrente, en particular, evaluar la estabilidad de un sistema o aplicación durante la actividad normal.
La investigación y el estudio de la concurrencia de programas comenzaron en la década de 1950, [3] y la investigación y el estudio de la concurrencia de programas de prueba apareció en la década de 1960. [4] Ejemplos de problemas que pueden exponer las pruebas de simultaneidad son el acceso incorrecto a la memoria compartida y la secuencia de orden inesperada de ejecución de mensajes o hilos. [5] : 2 [1] También se destacan la resolución de disputas de recursos , la programación , la prevención de interbloqueos , la inversión de prioridad y las condiciones de carrera . [6] : 745
Historia y enfoques seleccionados de la simultaneidad de pruebas
Los enfoques para las pruebas de concurrencia pueden estar en un nivel de prueba unitario limitado hasta el nivel de prueba del sistema. [7]
Algunos enfoques de investigación y aplicación de programas de prueba / concurrencia de software han sido:
- Ejecute una prueba una vez. [8] : 63
- Esto se consideró ineficaz para probar la concurrencia en un sistema no determinista y fue equivalente a la prueba de un programa secuencial no concurrente en un sistema.
- Ejecución de la misma secuencia de prueba varias veces. [8] : 63
- Se considera probable que encuentre algunos problemas en la ejecución de software no determinista.
- Esto más tarde se denominó prueba no determinista. [9]
- Pruebas deterministas. [8] : 63
- Este es un enfoque para configurar el sistema en un estado particular para que el código se pueda ejecutar en un orden conocido.
- Un intento de probar combinaciones de secuencia de sincronización para una entrada específica (el acceso a las variables compartidas no está dañado, probando de manera efectiva las variables de condiciones de carrera). Normalmente, la secuencia se deriva para la ejecución de pruebas no deterministas.
- Enfoques estructurales / Análisis estático
- Análisis de estructura de código y herramientas de análisis estático.
- Un ejemplo fue un enfoque heurístico [11]
- Esto llevó al desarrollo de un verificador de código, por ejemplo, jlint. [12] Investigación y comparación de análisis estático y verificadores de código para detectar errores de concurrencia [13]
- Consulte también Lista de herramientas para el análisis de código estático
- Enfoque multiusuario
Las pruebas de simultaneidad del software y del sistema no deben confundirse con las pruebas de estrés , que generalmente se asocian con la carga de un sistema más allá de sus límites definidos. La prueba de programas concurrentes puede presentar problemas cuando un sistema funciona dentro de sus límites definidos. La mayoría de los enfoques anteriores no se basan en sobrecargar un sistema. Alguna literatura [6] : 745 establece que las pruebas de concurrencia son un requisito previo para las pruebas de estrés.
Lecciones aprendidas del estudio de características de errores de concurrencia
Un estudio en 2008 [11] analizó las bases de datos de errores en una selección de software de código abierto. Se pensó que era el primer estudio del mundo real sobre errores de concurrencia. 105 errores se clasificaron como errores de concurrencia y se analizaron, divididos en 31 errores de interbloqueo y 74 errores de no interbloqueo. El estudio tuvo varios hallazgos, para un posible seguimiento e investigación:
- Aproximadamente un tercio de los errores de simultaneidad provocan bloqueos o programas bloqueados.
- La mayoría de los errores de simultaneidad sin interbloqueo son atomicidad o infracción de orden.
- Es decir, centrarse en la atomicidad (uso protegido de datos compartidos) o la secuencia potencialmente encontrará la mayoría de los errores de tipo no interbloqueo.
- La mayoría de los errores de simultaneidad involucran 1 o 2 subprocesos.
- Es decir, el uso / uso simultáneo intenso no es el desencadenante de estos errores. Existe una sugerencia de que las pruebas por pares pueden ser efectivas para detectar este tipo de errores.
- Más del 20% (31/7) se produjeron errores de interbloqueo con un solo hilo.
- La mayoría de los errores de concurrencia de interbloqueo (30/31) involucraron solo uno o dos recursos.
- Una implicación de que las pruebas por pares desde una perspectiva de uso de recursos podrían aplicarse para revelar puntos muertos.
Ver también
Referencias
- ^ a b Wang, Chao; Dijo, Mahmoud; Gupta, Aarti (21 a 28 de mayo de 2011). Prueba de concurrencia sistemática guiada por cobertura . Actas de ICSE '11 de la 33ª Conferencia Internacional de Ingeniería de Software. Waikiki. págs. 221-230.
- ^ a b Dustin, Elfriede (28 de diciembre de 2002). Pruebas de software efectivas: 50 formas de mejorar las pruebas de software . Addison-Wesley Longman. pag. 186. ISBN 0201794292.
- ^ Leiner, AL; Notz, WA; Smith, JL; Weinberger, A. (julio de 1959). "PILOT: un nuevo sistema informático múltiple". Revista de la ACM . 6 (3): 313–335. doi : 10.1145 / 320986.320987 . S2CID 19867617 .
- ^ Dijkstra, Edsger W. (mayo de 1968). "La estructura del" EL "-sistema de multiprogramación". Comunicaciones de la ACM . 11 (5): 341–346. doi : 10.1145 / 363095.363143 . S2CID 2021311 .
- ^ "Pruebas de software concurrentes: una revisión sistemática" (PDF) . Archivado desde el original el 24 de septiembre de 2015 . Consultado el 4 de marzo de 2014 .CS1 maint: bot: estado de URL original desconocido ( enlace )
- ^ a b c Carpeta, Robert V. (1999). Prueba de sistemas orientados a objetos: modelos, patrones y herramientas . Addison-Wesley Longman. ISBN 0-201-80938-9.
- ^ Melo, Silvana Morita; Souza, Simone do Rocio Senger de; Souza, Paulo Sérgio Lopes de; Carver, Jeffrey C. (2017). Cómo probar su software concurrente: un enfoque para la selección de técnicas de prueba . Conferencia sobre Sistemas, Programación, Lenguajes y Aplicaciones: Software para la Humanidad - SPLASH.
- ^ a b c KC, Tai (20 a 22 de septiembre de 1989). Prueba de software concurrente . Actas de la decimotercera conferencia internacional anual de software y aplicaciones informáticas. Orlando, FL, Estados Unidos, Estados Unidos. págs. 62–64.
- ^ a b Hwang, Gwan-Hwan; Tai, Kuo-Chung; Huang, Ting-Lu (1995). "Pruebas de accesibilidad: un enfoque para probar software concurrente". Revista Internacional de Ingeniería de Software e Ingeniería del Conocimiento . 5 (4): 493–510. doi : 10.1142 / S0218194095000241 .
- ^ Qi, Xiaofang; Li, Yueran (23-24 de noviembre de 2018). Prueba de accesibilidad paralela basada en Hadoop MapReduce . a Conferencia Internacional, SATE 2018. Shenzhen, Guangdong, China. págs. 173-184. doi : 10.1007 / 978-3-030-04272-1_11 .
- ^ a b Lu, Shan; Park, Soyeon; Seo, Eunsoo; Zhou, Yuanyuan (1º a 5 de marzo de 2008). Aprender de los errores: un estudio completo sobre las características de los errores de simultaneidad en el mundo real . ASPLOS XIII Actas de la 13ª conferencia internacional sobre soporte arquitectónico para lenguajes de programación y sistemas operativos. Seattle, WA, Estados Unidos. págs. 329–339.
- ^ Artho, Cyrille; Biere, Armin (27 a 28 de agosto de 2001). Aplicación de análisis estático a programas Java multiproceso a gran escala . Actas 2001 Conferencia australiana de ingeniería de software. Canberra, ACT, Australia, Australia. págs. 68–75.
- ^ Manzoor, Numan; Munir, Hussan; Moayyed, Misagh (27 a 30 de noviembre de 2012). Comparación de herramientas de análisis estático para encontrar errores de simultaneidad . 2012 IEEE 23rd Simposio Internacional sobre Talleres de Ingeniería de Confiabilidad de Software. Dallas, TX, Estados Unidos. págs. 129-133.
Referencias generales
- ¿Qué son las pruebas concurrentes? at the Wayback Machine (archivado el 19 de agosto de 2016)