Hispanopedia WikiLa investigación [ 1 ] y la literatura [ 2 ] sobre pruebas de concurrencia y pruebas concurrentes generalmente se centran en probar software y sistemas que utilizan computación concurrente . El objetivo es, como en 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 su 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 las pruebas de concurrencia de programas aparecieron en la década de 1960. [ 4 ] Ejemplos de problemas que las pruebas de concurrencia podrían revelar 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 la contención de recursos , la planificación , la prevención de interbloqueos , la inversión de prioridad y las condiciones de carrera . [ 6 ] : 745
Historia y enfoques seleccionados para probar la concurrencia.
Los enfoques para las pruebas de concurrencia pueden abarcar desde un nivel limitado de pruebas unitarias hasta el nivel de pruebas del sistema. [ 7 ]
Algunos enfoques para la investigación y aplicación de pruebas de concurrencia de programas/software han sido:
- Ejecutar una prueba una vez. [ 8 ] : 63
- Se consideró que esto era ineficaz para probar la concurrencia en un sistema no determinista y era equivalente a probar un programa secuencial no concurrente en un sistema.
- Ejecución de la misma secuencia de prueba varias veces. [ 8 ] : 63
- Se considera probable encontrar 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 método consiste en configurar el sistema en un estado particular para que el código pueda ejecutarse en un orden conocido.
- Se trata de un intento de probar combinaciones de secuencias de sincronización para una entrada específica (sin que se corrompa el acceso a variables compartidas, lo que permite comprobar las condiciones de carrera de las variables). La secuencia se suele derivar para la ejecución de pruebas no deterministas.
- Enfoques estructurales / Análisis estático
- Análisis de la estructura del código y herramientas de análisis estático.
- Un ejemplo fue un enfoque heurístico [ 11 ].
- Esto llevó al desarrollo de verificadores de código, por ejemplo jlint. [ 12 ] Investigación y comparación de análisis estático y verificadores de código para errores de concurrencia [ 13 ]
- Véase también Lista de herramientas para el análisis estático de código.
- Enfoque multiusuario
Las pruebas de concurrencia de software y sistemas no deben confundirse con las pruebas de estrés , que generalmente implican sobrecargar un sistema más allá de sus límites definidos. Las pruebas de programas concurrentes pueden presentar problemas incluso cuando un sistema funciona dentro de sus límites definidos. La mayoría de los enfoques mencionados anteriormente no se basan en la sobrecarga del sistema. Algunos estudios [ 6 ] : 745 indican que las pruebas de concurrencia son un requisito previo para las pruebas de estrés.
Lecciones aprendidas del estudio sobre las características de los errores de concurrencia
Un estudio de 2008 [ 11 ] analizó bases de datos de errores en una selección de software de código abierto. Se consideró el primer estudio real sobre errores de concurrencia. Se clasificaron y analizaron 105 errores como errores de concurrencia, divididos en 31 errores de interbloqueo y 74 errores que no lo eran. El estudio arrojó varios hallazgos que podrían ser objeto de seguimiento e investigación:
- Aproximadamente un tercio de los errores de concurrencia provocan fallos o bloqueos de los programas.
- La mayoría de los errores de concurrencia que no son de interbloqueo se deben a problemas de atomicidad o violación del orden.
- Es decir, centrarse en la atomicidad (uso protegido de datos compartidos) o en la secuencia permitirá encontrar potencialmente la mayoría de los errores que no son de tipo interbloqueo.
- La mayoría de los errores de concurrencia involucran 1 o 2 hilos.
- Es decir, el uso simultáneo intensivo de usuarios no es la causa de estos errores. Se sugiere que las pruebas por pares podrían ser efectivas para detectar este tipo de errores.
- Más del 20% (7/31) de los errores de interbloqueo ocurrieron con un solo hilo.
- La mayoría de los errores de concurrencia por interbloqueo (30/31) involucraban solo uno o dos recursos.
- Esto implica que las pruebas por pares, desde la perspectiva del uso de recursos, podrían aplicarse para detectar interbloqueos.
Véase también
Referencias
- 1 2 Wang, Chao; Said, Mahmoud; Gupta, Aarti (21–28 de mayo de 2011). Pruebas sistemáticas de concurrencia guiadas por cobertura . Actas de la 33.ª Conferencia Internacional de Ingeniería de Software de ICSE '11. Waikiki. pp. 221–230 .
- 1 2 Dustin, Elfriede (28 de diciembre de 2002). Pruebas de software efectivas: 50 maneras de mejorar sus pruebas de software . Addison-Wesley Longman. pág. 186. ISBN 0201794292.
- ↑ Leiner, AL; Notz, WA; Smith, JL; Weinberger, A. (julio de 1959). "PILOT: un nuevo sistema informático múltiple" . Journal of the ACM . 6 (3): 313– 335. doi : 10.1145/320986.320987 . S2CID 19867617 .
- ↑ Dijkstra, Edsger W. (mayo de 1968). "La estructura del sistema de multiprogramación "THE" . Communications of the ACM . 11 (5): 341– 346. doi : 10.1145/363095.363143 . S2CID 2021311 .
- ↑ "Pruebas de software concurrentes: una revisión sistemática" (PDF) . Archivado del original el 24 de septiembre de 2015. Consultado el 4 de marzo de 2014 .
{{cite web}}: CS1 maint: bot: estado de la URL original desconocido ( enlace ) - 1 2 3 Binder, Robert V. (1999). Pruebas 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.
- 1 2 3 K.C., Tai (20–22 de septiembre de 1989). Pruebas de software concurrente . Actas de la Decimotercera Conferencia Internacional Anual sobre Software y Aplicaciones Informáticas. Orlando, FL, EE. UU., EE. UU. págs. 62–64 .
- 1 2 Hwang, Gwan-Hwan; Tai, Kuo-Chung; Huang, Ting-Lu (1995). "Pruebas de alcanzabilidad: 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). Pruebas de accesibilidad paralelas basadas en Hadoop MapReduce . ª Conferencia Internacional, SATE 2018. Shenzhen, Guangdong, China. pp. 173–184 . doi : 10.1007/978-3-030-04272-1_11 .
- 1 2 Lu, Shan; Park, Soyeon; Seo, Eunsoo; Zhou, Yuanyuan (1–5 de marzo de 2008). Aprender de los errores: un estudio exhaustivo sobre las características de los errores de concurrencia 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, EE. UU. pp. 329–339 .
- ↑ Artho, Cyrille; Biere, Armin (27–28 de agosto de 2001). Aplicación del análisis estático a programas Java multihilo de gran escala . Actas de la Conferencia Australiana de Ingeniería de Software de 2001. Canberra, ACT, Australia. págs. 68–75 .
- ↑ Manzoor, Numan; Munir, Hussan; Moayyed, Misagh (27–30 de noviembre de 2012). Comparación de herramientas de análisis estático para la detección de errores de concurrencia . 2012 IEEE 23rd International Symposium on Software Reliability Engineering Workshops. Dallas, TX, EE. UU. pp. 129–133 .
Referencias generales
- ¿Qué son las pruebas concurrentes? en Wayback Machine (archivado el 19 de agosto de 2016)
- Pruebas de software
