TPT (time partition testing) is a systematic test methodology for the automated software test and verification of embedded control systems, cyber-physical systems, and dataflow programs. TPT is specialised on testing and validation of embedded systems whose inputs and outputs can be represented as signals and is a dedicated method for testing continuous behaviour of systems. Most control systems belong to this system class. The outstanding characteristic of control systems is the fact that they interact closely interlinked with a real world environment. Controllers need to observe their environment and react correspondingly to its behaviour. The system works in an interactional cycle with its environment and is subject to temporal constraints. Testing these systems is to stimulate and to check the timing behaviour. Traditional functional testing methods use scripts – TPT uses model-based testing.

TPT combines a systematic and graphic modelling technique for test cases with a fully automated test execution in different environments and automatic test evaluation. TPT covers the following four test activities:

In TPT tests are modelled graphically with the aid of special state machines and time partitioning. All test cases for one system under test can be modelled using one hybrid automaton. Tests often consist of a sequence of logical phases. The states of the finite-state machine represent the logical passes of a test which are similar for all tests. Trigger conditions model the transitions between the test phases. Each state and transition of the automaton may have different variants. The combination of the variants model the individual test cases.

Natural language texts become part of the graphics, supporting the simple and demonstrative readability even for non-programmers. Substantial techniques such as parallel and hierarchical branching state machines, conditional branching, reactivity, signal description, measured signals as well as lists of simple test steps allow an intuitive and graphic modelling even of complex test cases.

The test's complexity is hidden behind graphics. The lowest level signal description consists of either test step lists or so called direct definitions.

Through the use of the Test-Step List, one can model simple sequences of test steps that do not need to execute in parallel, such as setting signals (Set channel), ramping signals (Ramp channel), setting parameters (Set parameter), and waiting (Wait). Requests for the expected test results can be made within the test sequence to evaluate the system under test as it runs. It is also possible to place subautomatons in the Test-Step List, which in turn contain automatons and sequences, resulting in hierarchical Test-Step Lists. The test sequences can also be combined with other modelling methods, allowing for a great deal of complexity (or simplicity) in one's test. Test sequences can also be combined and parallelised with other modelling methods.

Within the Test-Step-List it is possible to implement so-called "Direct Definitions". Using this type of modelling, one can define signals as a function of time, past variables/test events, and other signals. It is also possible to define these signals by writing "C-Style" code as well as importing measurement data and using a manual signal editor.

It is possible to define functions that can act as a clients or servers. Client functions are called from TPT in the system under test, where server functions implemented in TPT can be called as "stub functions" from the system under test. TPT itself may also call the server functions.