Jump to content

Concurrent testing

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Yorkyabroad (talk | contribs) at 11:06, 5 May 2019 (Citation needed in last sentence). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Research[1] and literature[2] on concurrency testing and concurrent testing typically focuses on testing software and systems that use concurrent computing. The purpose is, as with most software testing, is to understand the behaviour and performance of a software system that uses concurrent computing.

Research and study of program concurrency started in the 1950’s[3], with research and study of testing program concurrency appearing in the 1960’s[4]. Examples of problems that concurrency testing might expose are incorrect shared memory access and unexpected order sequence of messages or threads[5]: 2 [6]. Resource contention resolution, scheduling, deadlock avoidance, priority inversion and race conditions are also highlighted [7]: 745 

Approaches to concurrency testing may be on a limited unit test level right up to system test level[8].

Concurrent testing is a software testing activity that determines the stability of a system or application under test during normal activity. Concurrent testing is the exercise of running continuous testing with functional testing concurrently in order to discover defects that would not otherwise be detected without the additional activity. Concurrent tests commonly put a greater emphasis on robustness, performance, and system integration with production-like activity, which should determine correct behavior of the system under normal circumstances.

Concurrent test vs. Stress test;Stress test[non sequitur]

Stress testing tries to break the system under test by overwhelming its resources or by taking resources away from it (in which case it is sometimes called negative testing). The main purpose of this process is to make sure that the system fails and recovers gracefully—a quality known as recoverability.

Concurrent testing implies a controlled environment staying at a constant level of activity.[citation needed] Stress testing focuses on more random events, chaos and unpredictability.

See also

References

  1. ^ 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.{{cite conference}}: CS1 maint: date format (link)
  2. ^ 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 (JACM). 6 (3): 313–335. doi:10.1145/320986.320987.
  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.
  5. ^ Concurrent Software Testing: A Systematic Review at the Wayback Machine (archived 24 September 2015)
  6. ^ Lu, Shan; Park, Soyeon; Seo, Eunsoo; Zhou, Yuanyuan (1–5 March 2008). Coverage guided systematic concurrency testing. ASPLOS XIII Proceedings of the 13th international conference on Architectural support for programming languages and operating systems. Seattle, WA, USA. pp. 329–339.{{cite conference}}: CS1 maint: date format (link)
  7. ^ Binder, Robert V. (1999). Testing object-oriented systems: models, patterns, and tools. Addison-Wesley Longman. ISBN 0-201-80938-9.
  8. ^ 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.

General References