TPT (software)

from Wikipedia, the free encyclopedia
Time Partition Testing (TPT)

TPT Logo.png
Basic data

developer PikeTec GmbH
Current  version 15
(April 2020)
operating system Windows
category Software test
License proprietary
German speaking No
TPT

TPT ( Time Partition Testing ) is a method and a software - tool of the company PikeTec for automated software testing or software verification of embedded systems . Embedded systems are mostly tested with the help of test scripts - with TPT test cases are graphically modeled. TPT is a model-based test tool for the module test , integration test , system test and regression test . Among other things, TPT also supports tests of control systems and systems with continuous behavior ( real-time systems that exchange physical values ​​or signals with their environment, which are received or sent in a time-discrete manner). Most control and regulation systems belong to this system class.

TPT comprises the following areas of responsibility:

  • manual or automatic test case modeling,
  • Test execution (fully automatic) on different platforms with e.g. B. Matlab / Simulink , ASCET , TargetLink , C-Code or using communication standards such as CAN
  • Test evaluation (fully automatic)
  • Test documentation (fully automatic)
  • Test management
  • Traceability of requirements and test cases, test execution and test results
Graphic test case modeling
Test description with hybrid automata

Reactive tests

With TPT, each test case can react specifically to the system behavior during the test sequence, for example to intervene exactly when a certain state occurs and to be able to provoke other test-relevant system states. If, for example, a sensor failure is to be simulated for an engine control when the idle speed is exceeded in order to test the behavior of the engine control in this situation, it must be possible to react to the event "idle speed exceeded" in the description of the test case.

The reactivity together with the real-time capability of the test execution allows the programming of time-discrete dynamic systems such as the implementation of filter functions and control algorithms with TPT.

Graphic test case modeling

The process of test cases is graphically modeled at TPT with the help of special state machines or state transition diagrams. This description technique for test cases is particularly obvious for the field of application of embedded systems, because test cases always consist of individual, chronologically consecutive steps. The test cases can thus be read intuitively, even if they are very complex.

Test Step List example

Simple sequences (test step lists)

Simple sequences of test steps that should not be processed in parallel, such as setting the signal (set channel), signal ramp (ramp channel), setting parameters (set parameter), waiting (wait), can easily be modeled with test steps. Inquiries for the expected test result for test evaluation can be inserted into the sequences as test oracles . If machine states, which in turn contain machines or sequences, are inserted, hierarchical step lists are created. The test sequences can also be combined and parallelized with other modeling methods.

Direct definition example

Direct definition of signals

So-called "Direct Definitions" are possible in the "Test Step Lists". In this form of modeling, signals are defined as functions of time, the past and other signals. The definition of formulas in " C -like" notation is possible in addition to the import of measurement data or a manual signal editor.

Functions

It is possible to define functions that act as clients or servers . Client functions are called from TPT in the system to be tested, whereby server functions implemented in TPT as so-called stub functions can be called from the system to be tested. TPT can also call the server functions itself.

Systematic test cases

TPT was specially developed for testing the continuous and reactive behavior of embedded systems. Even for very complex systems whose thorough testing requires a large number of test cases, TPT's systematic approach to test case identification ensures an overview and thus enables weak points in the system to be tested to be uncovered with an optimal number of test cases. The underlying idea of ​​the systematics of TPT is the separation of similarities and differences between the test cases: Most test cases are very similar to each other in their structural sequence and differ “only” in a few, but decisive details. TPT makes use of this fact by modeling and using common structures together. On the one hand, this avoids redundancies. On the other hand, it is made very clear how the test cases actually differ - that is, which specific aspects they each test. This approach significantly improves the comparability of the test cases and thus the overview and the main focus of the tester is directed to the essentials - the differentiating features of the test cases. The hierarchical structure of the test cases enables complex test problems to be broken down into sub-problems, which also improves the clarity and thus the quality of the test. These modeling techniques support the tester in finding the actually relevant cases, avoiding redundancies and maintaining an overview even with a large number of test cases.

Interact with the test through the dashboard

Automatic test case generation

TPT includes various options for automatic test case generation:

  • Test cases to cover equivalence classes
  • Test cases to cover Simulink models or C code using static analyzes and search-based methods (TASMO)
  • Sequence formation of variants of states in the test model
  • Test cases from recordings of interactions with the SUT via a graphical user interface (dashboard)

Test execution

TPT test cases are independent of their execution. The test cases can be executed automatically on any platform using a so-called virtual machine (TPT-VM) and, if necessary, in real time . For the TPT-VM there are programming interfaces (API) for C and .NET . It can be run manually, in batch mode, or on a Jenkins server.

Examples for the application are Model in the Loop (MiL) with Matlab / Simulink , TargetLink or ASCET , C programs , CAN , CANape , CANoe , AUTOSAR components, INCA , LABCAR , Software in the Loop (SiL) and Hardware in the Loop (HiL) .

For an analysis and measurement of the test coverage, there is, for example, a connection to the Code Coverage Analyzer Testwell ctc ++ or gcov for C programs .

TPT can also be used as a signal generator to "try out" the implementation during the development phase. Due to the possibility of generating any signals, TPT can also be used as a signal generator. In Matlab / Simulink , switches and signal generators can be easily replaced. The results are repeatable and lead to an improved quality of development.

The test-synchronous measurement of internal ECU measured variables on the test bench or in the vehicle is carried out using tools such as INCA or CANape . The measurement results are available for test case evaluation or during the test run time.

A configurable graphical user interface with displays and controls is available for testing. This means that values ​​can be stimulated or displayed by the user in real time parallel to the test execution. This interaction can also be recorded to include tests as a step list.

Programmed test evaluation

Test results must be assessed. Qualitative statements such as "true", "false" or "uncertain" must be given in the test documentation . Deviations from the target behavior should be recorded. In addition to manual evaluation and comparison with reference data ( regression test ), test results can be evaluated automatically with TPT. Rule-based evaluations are possible. Temporal and functional behavior of the test object can thus not only be assessed strictly quantitatively, but also qualitatively in a simple manner. A visual inspection after each test run is not necessary.

The test evaluation , also called test assessment, is based on recorded test data . Evaluations are carried out at well-defined time intervals, since in many cases an evaluation of the results can only take place under certain entry conditions. For example, a prerequisite for a light to shine is that the light is on.

Graphic user interfaces are available for common and simple test evaluations :

  • Monitoring of signal limits (min / max comparison)
  • Error-tolerant comparison of signals with reference signals ( regression test )
  • Investigation of discrete signal sequences
  • Rule-based examinations according to time trigger conditions
  • Integration of Matlab scripts

A Python- based programming language is available for more extensive investigations . This programming language provides an extensive library for calculating with signals. E.g. Filter operations, monotony tests, time queries, tests to determine whether a condition always or never occurs, or the definition of time intervals are possible. An evaluation of measurement results obtained elsewhere is also possible. The measurement data from model-internal TargetLink or Simulink signals as well as data from other measurement devices can automatically be used in the test evaluation.

Test management

TPT supports the following areas of test management:

  • Test case creation (test case modeling)
  • Test planning
  • Test documentation
  • Progress indicator for different releases
  • Traceability of requirements, test cases, test execution and test results

Areas of application

TPT is primarily used in the automotive industry. The original idea arose at Daimler AG and Mercedes-Benz for their own vehicle development. The first versions of the test tool were already being used there in 2000. Other automotive companies such as GM , Volkswagen , Audi , Porsche and BMW as well as suppliers such as Bosch , Hella , TRW and Continental are now also using the test tool. Daimler coordinated the further development of TPT itself for years and optimized TPT for the automotive software sector.

Requirements traceability

International standards for safe systems such as IEC 61508 , DO-178B , EN 50128 and ISO 26262 require traceability of requirements and tests. With TPT, for example, requirements can be imported from the DOORS tool , test cases can be linked to the requirements and the data can be synchronized with one another. Coverage and traceability analyzes are possible. When importing changed requirements, the affected test cases are marked and can thus be specifically adapted to new specifications.

literature

  1. ↑ see manufacturer's website : http://piketec.com
  2. ↑ Benjamin Wilmes: Hybrid test procedure for Simulink / TargetLink models , dissertation, TU-Berlin, Germany, 2015. [1]
  3. ↑ Jens Lüdemann: AUTOSAR component test with TPT , In: 2. Electronics automotive congress in Ludwigsburg, Germany, 2010. PDF article
  4. ↑ Jens Lüdemann: Automatic ASAM MCD-3 supported test , In: Open Technology Forum at the Testing Expo in Stuttgart, Germany, 2009. PDF article
  5. ↑ Model-based development of embedded vehicle software at DaimlerChrysler In: Informatik - Research and Development Volume 20, Numbers 1–2 (2005), 3–10; Springer Berlin / Heidelberg . Springerlink.com. July 9, 2001. Retrieved August 8, 2013.
  6. ↑ Hauser Automotive Website ( Memento from November 24, 2015 in the Internet Archive ). Retrieved March 16, 2015.

Web links