Research and literature on concurrency testing and concurrent testing typically focuses on testing software and systems that use

concurrent computing Concurrent computing is a form of computing in which several computations are executed '' concurrently''—during overlapping time periods—instead of ''sequentially—''with one completing before the next starts. This is a property of a syst ...

. 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, with research and study of testing program concurrency appearing in the 1960s. Examples of problems that concurrency testing might expose are incorrect shared memory access and unexpected order sequence of message or thread execution.

Resource contention In computer science, resource contention is a conflict over access to a shared resource such as random access memory, disk storage, cache memory, internal buses or external network devices. A resource experiencing ongoing contention can be descr ...

resolution, scheduling, deadlock avoidance, priority inversion and race conditions are also highlighted.

Selected history & approaches of testing concurrency

Approaches to concurrency testing may be on a limited unit test level right up to system test level. Some approaches to research and application of testing program/software concurrency have been: *Execute a test once. ::This was considered to be ineffective for testing concurrency in a non-deterministic system and was equivalent to the testing of a sequential non-concurrent program on a system *Execution of the same test sequence multiple times. ::Considered likely to find some issues in non-deterministic software execution. ::This later became called non-deterministic testing. *Deterministic testing. ::This is an approach to set the system into a particular state so that code can be executed in a known order. *Reachability testing ::An attempt to test synchronisation sequence combinations for a specified input (shared variable access not being corrupted, effectively testing race conditions variables). The sequence is typically derived for non-deterministic test execution. *Structural Approaches / Static Analysis ::Analysis of code structure and static analysis tools. ::An example was a heuristic approach ::This led to code checker development, for example jlint. Research and comparison of static analysis and code checkers for concurrency bugs ::See also List of tools for static code analysis *Multi-user approach ::This is an approach to testing program concurrency by looking at multiple user access, either serving different users or tasks simultaneously. Testing software and system concurrency should not be confused with

stress testing Stress testing (sometimes called torture testing) is a form of deliberately intense or thorough testing used to determine the stability of a given system, critical infrastructure or entity. It involves testing beyond normal operational capacity, ...

, 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 states that testing of concurrency is a pre-requisite to stress testing.

Lessons learned from concurrency bug characteristics study

A study in 2008 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: *Approximately one-third of the concurrency bugs cause crashes or hanging programs. *Most non-deadlock concurrency bugs are atomicity or order violation. ::I.e. focusing on atomicity (protected use of shared data) or sequence will potentially find most non-deadlock type bugs. *Most concurrency bugs involve 1 or 2 threads. ::I.e. Heavy simultaneous users/usage is not the trigger for these bugs. There is a suggestion that pairwise testing may be effective to catch these types of bugs. *Over 20% (7/31) deadlock bugs occurred with a single thread. *Most deadlock concurrency bugs (30/31) involved only one or two resources. ::An implication that pairwise testing from a resource usage perspective could be applied to reveal deadlocks.

References

General References

* {{Software testing Software testing