Software testability: Difference between revisions

Revision as of 13:31, 23 September 2014

Revision as of 13:09, 29 September 2014

Line 34:

== Testability hierarchy ==

Based on the amount of test cases required to construct a complete test suite in each context (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.{{cite journal | last1=Rodríguez, L.| first1=Ismael | last2=Llana, P.| first2=Luis | last3=Rabanal (2014)| “Afirst3=Pablo | title=A General Testability Theory: Classes, properties, complexity, and testing reductions”.reductions | journal=IEEE Transactions on Software Engineering. doi| link:volume=40 http://doi.ieeecomputersociety.org/10.1109/TSE.2014.2331690</ref><ref>I.| Rodríguezissue=9 (2009)| "Apages=862-894 General| Testabilityyear=2014 Theory".| CONCURissn=0098-5589 2009, Springer, LNCS 5710, pp.572–586.| doi: =10.10071109/978-3-642-04081-8_38TSE.2014.2331690}}</ref>

<ref>{{cite conference | last=Rodríguez | first=Ismael | title=A General Testability Theory | doi=10.1007/978-3-642-04081-8_38 | year=2009 | booktitle=CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1-4, 2009. Proceedings | pages=572-586}}</ref>

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

* Class II: any partial distinguishing rate (i.e. any incomplete capability to distinguish correct systems from incorrect systems) can be reached with a finite test suite.