Research[1] and literature[2]onconcurrency testing and concurrent testing typically focuses on testing software and systems that use concurrent computing. The purpose is, as with most software testing, to understand the behaviour and performance of a software system that uses concurrent computing, particularly assessing the stability of a system or application during normal activity.
Research and study of program concurrency started in the 1950s,[3] with research and study of testing program concurrency appearing in the 1960s.[4] Examples of problems that concurrency testing might expose are incorrect shared memory access and unexpected order sequence of message or thread execution.[5]: 2 [1] Resource contention resolution, scheduling, deadlock avoidance, priority inversion and race conditions are also highlighted.[6]: 745
Approaches to concurrency testing may be on a limited unit test level right up to system test level.[7]
Some approaches to research and application of testing program/software concurrency have been:
Testing software and system concurrency should not be confused with stress testing, which is usually associated with loading a system beyond its defined limits. Testing of concurrent programs can exhibit problems when a system is performing within its defined limits. Most of the approaches above do not rely on overloading a system. Some literature[6]: 745 states that testing of concurrency is a pre-requisite to stress testing.
A study in 2008[11] analysed bug databases in a selection of open source software. It was thought to be the first real-world study of concurrency bugs. 105 bugs were classified as concurrency bugs and analysed, split as 31 being deadlock bugs and 74 non-deadlock bugs. The study had several findings, for potential follow-up and investigation:
{{cite web}}: CS1 maint: bot: original URL status unknown (link)
