Content deleted Content added
No edit summary |
No edit summary |
||
Line 67:
=== Classification Tree Method for Embedded Systems ===
The classification tree method first was intended for the design and specification of abstract test cases. With the classification tree method for embedded systems<ref>{{cite journal|last=Conrad|first=Mirko|coauthors=Krupp, Alexander|title=An Extension of the Classification-Tree Method for Embedded Systems for the Description of Events|journal=Electronic Notes in Theoretical Computer Science|date=1 October 2006|volume=164|issue=4|pages=3–11|doi=10.1016/j.entcs.2006.09.002}}</ref>, test implementation can also be performed.
# In addition to atomic test cases, test sequences containing of several test steps can be specified.
# A concrete timing (e.g. in Seconds, Minutes ...) can be specified for each test step.
# Signal transitions (e.g. [[linear]], [[Spline (mathematics)|spline]], [[sine]] ...) between selected classes of different test steps can be specified.
# A distinction between [[Event (computing)|event]] and [[State (computer science)|state]] can be modelled, represented by different visual marks in a test.
The module and [[unit testing]] tool [[Tessy (software)|Tessy]] relies on this extention.
=== Dependency Rules and Automated Test Case Generation ===
One way of modelling constraints is using the refinement mechanism in the classification tree method. This, however, does not allow for modelling constraints between classes of different classifications. Lehmann and Wegener introduced Dependency Rules with their incarnation of the CTE.<ref>{{cite journal|last=Lehmann|first=Eckard|coauthors=Wegener, Joachim|title=Test Case Design by Means of the CTE XL|journal=Proceedings of the 8th European International Conference on Software Testing, Analysis & Review (EuroSTAR 2000)|year=2000|url=http://www.systematic-testing.com/documents/eurostar2000.pdf}}</ref>
== Advantages ==
| |||