Random testing: Difference between revisions

Revision as of 23:45, 29 June 2021

Revision as of 15:50, 24 May 2022

Line 66:

The following weaknesses have been described :

*It only finds basic bugs (fe.exg. [[null pointer]] dereferencing).

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

*It compares poorly with other techniques to find bugs (fe.exg. [[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">{{cite web|url=https://stackoverflow.com/q/636353 |title=Is it a bad practice to randomly-generate test data?|website=stackoverflow.com|accessdate=15 November 2017}}</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" />

Line 77:

===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) - fe.exg. 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 - fe.exg. "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|issn=0270-5257}}</ref> and "adaptive random testing" <ref name="ART">{{citation |last1=T.Y. Chen |last2=F.-C. Kuo |last3=R.G. Merkel |last4=T.H. Tse |title=Adaptive random testing: The ART of test case diversity |journal=Journal of Systems and Software |volume=83 |issue=1 |pages=60-66 |date=2010 |doi=10.1016/j.jss.2009.02.022|hdl=10722/89054 |hdl-access=free }}</ref>

== Implementations ==

Line 89:

* [[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.

* Randoop - generates sequences of methods and constructor invocations for the classes under test and creates [[JUnit]] tests from these

* Simulant - a [[Clojure]] tool that runs simulations of various agents (fe.exg. 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

* AutoTest - a tool integrated to EiffelStudio testing automatically Eiffel code with contracts based on the eponymous research prototype.<ref name="AutoTest"/>·

* York Extensible Testing Infrastructure (YETI) - a language agnostic tool which targets various programming languages (Java, JML, CoFoJa, .NET, C, Kermeta).

Line 99:

A [[test 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 examplee.g. 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">{{cite web|url=http://se.inf.ethz.ch/research/autotest/|title=AutoTest - Chair of Software Engineering|website=se.inf.ethz.ch|accessdate=15 November 2017}}</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|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==