Software testability: Difference between revisions

Revision as of 13:43, 18 August 2014

Revision as of 14:34, 18 August 2014

Line 33:

== Testability hierarchy ==

Based on the amount of test cases required to construct a complete test suite in each context (that is,i.e. a test suite such that, if it is applied to the implementation under test, then we collect enough information to precisely determine whether the system is correct or incorrect according to some specification), a testability hierarchy with the following testability classes has been proposed: <ref> I. Rodríguez, L. Llana, P. Rabanal (2014) “A General Testability Theory: Classes, properties, complexity, and testing reductions”. IEEE Transactions on Software Engineering. doi link: http://doi.ieeecomputersociety.org/10.1109/TSE.2014.2331690 </ref><ref> I. Rodríguez (2009) "A General Testability Theory". CONCUR 2009, Springer, LNCS 5710, pp.572–586. doi: 10.1007/978-3-642-04081-8_38</ref>

* Class I: there exists a finite complete test suite.

Line 45:

* Class V: all cases.

It has been proved that each class is strictly included into the next. For instance, testing when we assume that the implementation under test can be any deterministic [[finite-state machine]] for some known finite sets of inputs and outputs and with some known number of states belongs to Class I (and all subsequent classes). However, if the number of states is not known, then it only belongs to all classes from Class II on. If the implementation under test must be a deterministic finite-state machine failing the specification for a single trace (and its continuations), and its number of states is unknown, then it only belongs to classes from Class III on. Testing temporal machines where transitions are triggered if inputs are produced within some real-bounded interval only belongs to classes from Class IV on, whereas testing many non-deterministic systems only belongbelongs to Class V (but not all, and some even belong to Class I). The inclusion into Class I does not require the simplicity of the computation device, as some testing cases involving implementations written in any programming language, or testing implementations defined as machines depending on continuous magnitudes, have been proved to be in Class I. Other elaborated cases, such as the testing framework by [[Matthew Hennessy]] under must semantics, and temporal machines with rational timeouts, belong to Class II.

== Testability of Requirements ==