Random testing: Difference between revisions

Revision as of 15:42, 21 February 2017

Revision as of 22:23, 10 July 2017

Line 1:

{{refimproveRefimprove|date=September 2014}}

'''Random testing''' is a black-box software testing technique where programs are tested by generating random, independent inputs. Results of the output are compared against software specifications to verify that the test output is pass or fail.<ref name="Hamlet94"/> In case of absence of specifications the exceptions of the language are used which means if an exception arises during test execution then it means there is a fault in the program.

== History of random testing ==

Random testing for hardware was first examined by [[Melvin Breuer]] in 1971 and initial effort to evaluate its effectiveness was done by Pratima and [[Vishwani Agrawal]] in 1975.<ref>[http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1672882&tag=1 Agrawal, P.; Agrawal, V.D., "Probabilistic Analysis of Random Test Generation Method for Irredundant Combinational Logic Networks," Computers, IEEE Transactions on , vol.C-24, no.7, pp.691,695, July 1975]</ref>

In software, Duran and Ntafos had examined random testing in 1984.<ref>[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5010257 Duran, J. and S. Ntafos, An evaluation of random testing, IEEE Trans. Software Eng. SE-10 (July, 1984), 438-444]</ref> Earlier Howden had termed it functional testing in 1980.{{Citation needed|date=January 2015}}

== Overview ==

Consider the following C++ function:

Line 22 ⟶ 21:

</syntaxhighlight>

Now the random tests for this function could be {123, 36, -35, 48, 0}. Only the value '-35' triggers the bug. If there is no reference implementation to check the result, the bug still could go unnoticed. However, an [[assertion (software development)|assertion]] could be added to check the results, like:

<syntaxhighlight lang="cpp">

Line 52 ⟶ 51:

While this example is limited to simple types (for which a simple random generator can be used), tools targeting object-oriented languages typically explore the program to test and find generators (constructors or methods returning objects of that type) and call them using random inputs (either themselves generated the same way or generated using a pseudo-random generator if possible). Such approaches then maintain a pool of randomly generated objects and use a probability for either reusing a generated object or creating a new one.<ref name="AutoTest"/>

== On randomness ==

According to the seminal paper on random testing by D. Hamlet

<blockquote>[..] the technical, mathematical meaning of "random testing" refers to an explicit lack of "system" in the choice of test data, so that there is no correlation among different tests.<ref name=Hamlet94>{{cite book|title=Encyclopedia of Software Engineering|year=1994|publisher=John Wiley and Sons|isbn=0471540021|author=Richard Hamlet|edition=1|editor=John J. Marciniak|accessdate=16 June 2013|chapter=Random Testing}}</ref></blockquote>

== Strengths and weaknesses ==

{{unreferencedUnreferenced section|date=August 2014}}

Random testing is typically praised for the following strengths:

* It is cheap to use: it does not need to be smart about the program under test.

* It does not have any bias: unlike manual testing, it does not overlook bugs because there is misplaced trust in some code.

* It is quick to find bug candidates: it typically takes a couple of minutes to perform a testing session.

* If software is properly specified: it finds real bugs.

The following weaknesses are typically pointed out by detractors:

* It only finds basic bugs (f.ex. [[Nullnull pointer]] dereferencing).

* It is only as precise as the specification and specifications are typically imprecise.

* It compares poorly with other techniques to find bugs (f.ex. [[static program analysis]]).

* If different inputs are randomly selected on each test run, this can create problems for [[continuous integration]] because the same tests will pass or fail randomly.<ref name="so">http://stackoverflow.com/questions/636353/is-it-a-bad-practice-to-randomly-generate-test-data</ref>

* Some argue that it would be better to thoughtfully cover all relevant cases with manually constructed tests in a white-box fashion, than to rely on randomness.<ref name="so" />

== Types of random testing ==

=== With respect to the input ===

* Random input sequence generation (i.e. a sequence of method calls)

* Random sequence of data inputs (sometimes called stochastic testing) - f.ex. a random sequence of method calls

* Random data selection from existing database

=== Guided vs. unguided ===

* undirected random test generation - with no heuristics to guide its search

* directed random test generation - f.ex. "feedback-directed random test generation"<ref name="PachecoLET2007">{{cite journal|last=Pacheco|first=Carlos|author2=Shuvendu K. Lahiri |author3=Michael D. Ernst |author4=Thomas Ball |title=Feedback-directed random test generation|journal=ICSE '07: Proceedings of the 29th International Conference on Software Engineering|date=May 2007|pages=75–84|url=http://people.csail.mit.edu/cpacheco/publications/feedback-random.pdf|publisher=IEEE Computer Society|issn=0270-5257}}</ref> or "adaptive random testing" <ref name="ART">{{cite journal|last=Chen|first=T.Y.|author2=H. Leung |author3=I.K. Mak | title=Adaptive Random Testing |journal=Advances in Computer Science - ASIAN 2004. Higher-Level Decision Making |date= 2005|pages=320–329|url=http://www.utdallas.edu/~ewong/SYSM-6310/03-Lecture/02-ART-paper-01.pdf|publisher=Lecture Notes in Computer Science Volume 3321}}</ref>

== Implementations ==

Some tools implementing random testing:

* [[QuickCheck]] - a famous test tool, originally developed for [[Haskell (programming language)|Haskell]] but ported to many other languages, that generates random sequences of API calls based on a model and verifies system properties that should hold true after each run. Check this [http://www.quviq.com/documents/QuviqFlyer.pdf QuviQ QuickCheck flyer] for a quick overview.

* [https://randoop.github.io/randoop/ Randoop] - generates sequences of methods and constructor invocations for the classes under test and creates [[JUnit]] tests from these

* [https://github.com/Datomic/simulant/wiki/Overview Simulant] - a [[Clojure]] tool that runs simulations of various agents (f.ex. users with different behavioral profiles) based on a statistical model of their behavior, recording all the actions and results into a database for later exploration and verification

* [https://docs.eiffel.com/book/eiffelstudio/autotest AutoTest] - a tool integrated to EiffelStudio testing automatically Eiffel code with contracts based on the eponymous research prototype.<ref name="AutoTest"/>·

* [https://code.google.com/p/yeti-test/ York Extensible Testing Infrastructure (YETI)] - a language agnostic tool which targets various programming languages (Java, JML, CoFoJa, .NET, C, Kermeta).

* [https://github.com/codelion/gramtest GramTest] - a grammar based random testing tool written in Java, it uses BNF notation to specify input grammars.

== Critique ==

== Critique ==

<blockquote>Random testing has only a specialized niche in practice, mostly because an effective oracle is seldom available, but also because of difficulties with the operational profile and with generation of pseudorandom input values.<ref name="Hamlet94"/></blockquote>

An [[Oracleoracle (software testing)|oracle]] is an instrument for verifying whether the outcomes match the program specification or not. An operation profile is knowledge about usage patterns of the program and thus which parts are more important.

For programming languages and platforms which have contracts (for example Eiffel. .NET or various extensions of Java like JML, CoFoJa...) contracts act as natural oracles and the approach has been applied successfully.<ref name="AutoTest">http://se.inf.ethz.ch/research/autotest/</ref> In particular, random testing finds more bugs than manual inspections or user reports (albeit different ones).<ref name="ManualvsRandom">{{cite journal|title=On the number and nature of faults found by random testing|year=2009|publisher=John Wiley and Sons|url=http://onlinelibrary.wiley.com/doi/10.1002/stvr.415/abstract|author=Ilinca Ciupa|author2=Alexander Pretschner|author3=Manuel Oriol|author4=Andreas Leitner|author5=Bertrand Meyer|journal=Software Testing, Verification and Reliability|doi=10.1002/stvr.415|volume=21|pages=3–28}}</ref>

== See also ==

* [[Fuzz testing]] - a kind of random testing whenwhich provides invalid input isto provided tothe tested program.

* [[Lazy systematic unit testing#Systematic Testing]] - a systematic way of exploring "all" method calls, as implemented e.g. by NASA's [http://babelfish.arc.nasa.gov/trac/jpf/wiki/intro/what_is_jpf Java Path Finder] (which blands [http://babelfish.arc.nasa.gov/trac/jpf/wiki/intro/testing_vs_model_checking testing with model checking] by limiting the state space to a reasonable size by various means)

* [[SystemVerilog#Constrained random generation|Constrained random generation in SystemVerilog]]

* [[Corner case]]

* [[Edge case]]

* [[Concolic testing]]

== References ==

{{reflistReflist}}

== External links ==

* [http://www.uio.no/studier/emner/matnat/ifi/INF4290/v10/undervisningsmateriale/INF4290-RandomTesting.pdf Random testing] by Andrea Arcuri.

* [http://web.cecs.pdx.edu/~hamlet/random.pdf Random testing] by Richard Hamlet, professor emeritus at Portland State University; a valuable list of resources at the end of the paper

* [http://c2.com/cgi/wiki?RandomTesting Random Testing wiki] at Cunningham & Cunningham, Inc.

[[Category:Software testing]]