Modeling tests in TPT

In TPT, tests are described graphically with hybrid automatons and with test steps. External measurement data can be used inside test step lists or test cases can be generated from it.
You can use conditions as well as functions in the test model.
The test model itself can be built hierarchically or in parallel, or uses both approaches.

You have the freedom to create an unlimited number of variants of the states and transitions. The appropriate state variants, transition variants, and the paths of the automaton that should be taken are selected in the test cases.
Since tests in TPT are reactive, you can define state-based decisions as well as state-based transitions.

TPT assists you with numerous features in generating meaningful test data,
for example TASMO for the test data generation from Simulink models.


To model tests graphically, extended state-transition-diagrams, called TPT-automatons, are used. These TPT-automatons specify graphically which states and phases are part of the test, how long the duration of the parts and phases is,
and under which conditions states may change.

The different combinations of state sequences, variants of states, and transition conditions constitute individual test cases. These individual test cases are not viewed independently but they are presented in a joint model, where similarities as well as differences between the test cases clearly stand out. Moreover, this way the tester gains a detailed overview of the aspects that were tested and those that weren't yet.

  • TPt test modeling: On a junction, it is determined during runtime which branch to take according to the transition conditions (t>23, t==23, t<23).
  • TPT test modeling as parallel automaton with active paths in black and inactive paths grey.
  • Modeling test pases with TPT.
  • You can set up variants of states and transitions. With these variants, you can effectively and easily create test case variations.

Test Step Lists

Test steps are made up of sequences of commands. These sequences are processed successively or in parallel. You can model test steps using hierarchies, conditional statements, parallelisms, reactive behavior, or loops.

Signals are defined by assigning values, time-dependent synthetic functions,
or by imported measurement data. You can embed or link measurement data from various file formats like *.csv, *.dat, *.mat, *.mf4, *.mdf, *.tptbin or *.xls in test step lists.

  • You can run test steps simultaneously.This feature complies with the parallel automatons in the graphical test modeling.
  • You can set up direct definitions as a single-line mathematical formula. Or you use the convenient Direct Definition Function Wizard.
  • Inside a test step list, you can change parameter values, as well as reset single parameters or all parameters to their default value.
  • You use the Compare Step to check if a condition is true. Here: when the light_switch is set to "on", check if the headlight is "on" too.
  • You can deactivate test steps in a test step list to exclude them from the test execution. You can, of course, activate them again easily.
  • You are free to insert comments in the test step list.
  • The behavior of signals can be controlled by using If and Else steps. Here: if "a" is greater than 3.5, ramp the channel "foo" every two seconds two units up until 6 is reached. Else, ramp "bar" to 5.
  • You can influence the duration of a state by linking it to the fulfilling of a condition (Wait...). Here: wait until the length of  the embedded signal is reached, then terminate this step.
  • Using While steps, you can execute test steps in the loop, thus several times in succession.
  • You can nest While Steps inside a test step list.
  • Simple table step in a test step list.
  • From a single measurement file, you can embed several signals (channels and parameters) in TPT at the same time.

Follow us