동시 테스트

Concurrent testing

동시성 테스트와 동시 테스트에 관한 조사와[2] 문헌은 일반적으로 동시 컴퓨팅을 사용하는 소프트웨어와 시스템의 테스트에 초점을 맞추고 있습니다[1].그 목적은 대부분의 소프트웨어 테스트와 마찬가지로 동시 컴퓨팅을 사용하는 소프트웨어 시스템의 동작과 성능을 이해하는 것입니다.특히 통상적인 액티비티에서 시스템 또는 애플리케이션의 안정성을 평가하는 것입니다.

프로그램 동시성에 대한 연구와 연구는 1950년대에 [3]시작되었고, 테스트 프로그램 동시성에 대한 연구와 연구는 1960년대에 [4]나타났다.동시성 테스트에서 드러날 수 있는 문제의 예로는 잘못된 공유 메모리 액세스, 메시지 또는 스레드 실행 [5]: 2 [1]순서 등이 있습니다.자원 경합 해결, 스케줄링, 교착 상태 회피, 우선 순위 반전 및 레이스 조건도 [6]: 745 강조 표시됩니다.

선택된 동시성 테스트 이력 및 접근법

동시성 테스트에 대한 접근법은 시스템 테스트 [7]수준까지 제한된 단위 테스트 수준에 있을 수 있습니다.

테스트 프로그램/소프트웨어 동시성 조사 및 적용에 대한 접근방식은 다음과 같습니다.

  • 테스트를 한 [8]: 63 번 실행합니다.
이것은 비결정론적 시스템의 동시성 테스트에 효과적이지 않은 것으로 간주되었으며, 이는 시스템에서 순차적 비동시 프로그램의 테스트와 동등했다.
  • 동일한 테스트 시퀀스를 여러 [8]: 63 번 실행합니다.
비결정적 소프트웨어 실행에서 몇 가지 문제가 발견될 가능성이 높다고 생각됩니다.
이것은 나중에 비결정론적 [9]시험이라고 불리게 되었다.
  • 결정론적 [8]: 63 테스트
이는 시스템을 특정 상태로 설정하여 코드를 알려진 순서로 실행할 수 있도록 하는 접근법입니다.
지정된 입력에 대한 동기화 시퀀스 조합을 테스트하는 시도(공유 변수 액세스가 손상되지 않고 레이스 조건 변수를 효과적으로 테스트).이 시퀀스는 일반적으로 비결정론적 테스트 실행을 위해 도출됩니다.
  • 구조적 접근 / 정적 분석
코드 구조 및 정적 분석 도구 분석
한 예로 휴리스틱[11] 접근법을 들 수 있다.
이를 통해 jlint와 [12]같은 코드 체커가 개발되었습니다.동시성 버그에 대한 정적 분석 및 코드 체커 조사 및 비교
정적 코드 분석을 위한 도구 목록도 참조하십시오.
  • 멀티 유저 어프로치
이는 여러 사용자 또는 작업을 [2][6]동시에 처리하는 여러 사용자 액세스를 검토하여 프로그램 동시성을 테스트하는 방법입니다.: 745

테스트 소프트웨어와 시스템 동시성은 일반적으로 정의된 한계를 초과하는 시스템 로딩과 관련된 스트레스 테스트와 혼동해서는 안 된다.시스템이 정의된 제한 범위 내에서 수행 중일 때 동시 프로그램 테스트에서 문제가 발생할 수 있습니다.상기의 어프로치의 대부분은, 시스템의 과부하에 의존하지 않습니다.일부 문헌에는[6]: 745 동시성 테스트가 스트레스 테스트의 전제 조건이라고 명시되어 있다.

동시성 버그 특성 연구에서 얻은 교훈

2008년의 연구는[11] 선별된 오픈 소스 소프트웨어에서 버그 데이터베이스를 분석했습니다.이것은 동시성 버그에 대한 최초의 실제 연구라고 생각되었다.105개의 버그가 동시성 버그로 분류되어 분석되었으며, 31개의 교착 버그와 74개의 비동기 버그로 분할되었습니다.이 연구에는 잠재적인 추적 조사 및 조사를 위해 다음과 같은 몇 가지 결과가 있었습니다.

  • 약 3분의 1의 동시성 버그로 인해 크래시 또는 프로그램 행이 발생합니다.
  • 대부분의 비데드록 동시성 버그는 원자성 또는 순서 위반입니다.
즉, 원자성(공유 데이터의 보호 사용) 또는 시퀀스에 초점을 맞추면 대부분의 비데드록 유형의 버그가 발견될 수 있습니다.
  • 대부분의 동시성 버그는 1개 또는2개의 스레드를 포함합니다.
즉, 대량의 동시 사용자/사용이 이러한 버그의 트리거가 되지 않습니다.이러한 종류의 버그를 검출하기 위해서는 쌍별 테스트가 효과적일 수 있다는 의견이 있습니다.
  • 단일 스레드에서 20%(7/31)가 넘는 교착 버그가 발생했습니다.
  • 교착 상태의 동시성 버그(30/31)의 대부분은 1개 또는2개의 자원만을 포함하고 있었습니다.
리소스 사용률 관점에서 쌍별 테스트를 적용하여 교착 상태를 파악할 수 있다는 의미입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Wang, Chao; Said, Mahmoud; Gupta, Aarti (21–28 May 2011). Coverage guided systematic concurrency testing. ICSE '11 Proceedings of the 33rd International Conference on Software Engineering. Waikiki. pp. 221–230.
  2. ^ a b Dustin, Elfriede (28 December 2002). Effective Software Testing: 50 Ways to Improve Your Software Testing. Addison-Wesley Longman. p. 186. ISBN 0201794292.
  3. ^ Leiner, A.L.; Notz, W.A.; Smith, J.L.; Weinberger, A. (July 1959). "PILOT—A New Multiple Computer System". Journal of the ACM. 6 (3): 313–335. doi:10.1145/320986.320987. S2CID 19867617.
  4. ^ Dijkstra, Edsger W. (May 1968). "The structure of the "THE"-multiprogramming system". Communications of the ACM. 11 (5): 341–346. doi:10.1145/363095.363143. S2CID 2021311.
  5. ^ "Concurrent Software Testing: A Systematic Review" (PDF). Archived from the original on 24 September 2015. Retrieved 4 March 2014.{{cite web}}: CS1 maint: bot: 원래 URL 상태를 알 수 없습니다(링크).
  6. ^ a b c Binder, Robert V. (1999). Testing object-oriented systems: models, patterns, and tools. Addison-Wesley Longman. ISBN 0-201-80938-9.
  7. ^ Melo, Silvana Morita; Souza, Simone do Rocio Senger de; Souza, Paulo Sérgio Lopes de; Carver, Jeffrey C. (2017). How to test your concurrent software: an approach for the selection of testing techniques. Conference on Systems, Programming, Languages, and Applications: Software for Humanity - SPLASH.
  8. ^ a b c K.C., Tai (20–22 September 1989). Testing of concurrent software. Proceedings of the Thirteenth Annual International Computer Software & Applications Conference. Orlando, FL, USA, USA. pp. 62–64.
  9. ^ a b Hwang, Gwan-Hwan; Tai, Kuo-Chung; Huang, Ting-Lu (1995). "Reachability Testing: An Approach To Testing Concurrent Software". International Journal of Software Engineering and Knowledge Engineering. 5 (4): 493–510. doi:10.1142/S0218194095000241.
  10. ^ Qi, Xiaofang; Li, Yueran (23–24 November 2018). Parallel Reachability Testing Based on Hadoop MapReduce. th International Conference, SATE 2018. Shenzhen, Guangdong, China. pp. 173–184. doi:10.1007/978-3-030-04272-1_11.
  11. ^ a b Lu, Shan; Park, Soyeon; Seo, Eunsoo; Zhou, Yuanyuan (1–5 March 2008). Learning from mistakes: a comprehensive study on real world concurrency bug characteristics. ASPLOS XIII Proceedings of the 13th international conference on Architectural support for programming languages and operating systems. Seattle, WA, USA. pp. 329–339.
  12. ^ Artho, Cyrille; Biere, Armin (27–28 August 2001). Applying static analysis to large-scale, multi-threaded Java programs. Proceedings 2001 Australian Software Engineering Conference. Canberra, ACT, Australia, Australia. pp. 68–75.
  13. ^ Manzoor, Numan; Munir, Hussan; Moayyed, Misagh (27–30 November 2012). Comparison of Static Analysis Tools for Finding Concurrency Bugs. 2012 IEEE 23rd International Symposium on Software Reliability Engineering Workshops. Dallas, TX, USA. pp. 129–133.

일반 참고 자료