Empowering your testing journey at every level with ultra fast test results.

mil-sil-hil-pil testing tpt

Model-in-the-Loop Testing

mil-testing-icon

You are testing your software directly in the development environment and TPT just integrates seamlessly:

  • Testing every model that is executable in MATLAB/Simulink
  • TargetLink as SiL-Testing
  • Fully automatic ASCET model testing

 

 

Software-in-the-Loop Testing

Both generated and manually written code can be tested and integration is often fully automatic.

 

sil testing

Processor-in-the-Loop Testing

pil-testing-icon

The supported platforms in PiL Testing:

So you can even integrate EHX and ELF files.

Save hardware costs with a simulated environment: Get our Trace32 Support Package for an execution in the simulation environment.

Hardware-in-the-Loop Testing

HiL Tests can be run on the control PC or in real-time with cycle times of less than 100µs. These are the supported systems:

Also possible and easy to set up is communication with application tools such as INCA, CANape, fault simulators, or directly with the CAN bus.

hil-testing-icon

Vehicle-in-the-Loop Testing

vil testing icon

Vehicle-in-the-Loop (ViL) testing integrates components, control units, and sensors into the final vehicle environment, simulating real-world conditions.

TPT´s Autotester

This solution enhances ViL testing by structuring and automating vehicle tests. It allows manual driving maneuvers to be described, guiding drivers step-by-step with visual and audio cues, while ensuring correct execution. Tests can also be fully automated, streamlining the process. In case of anomalies, drivers can easily record voice notes, and the system automatically tags and trims the driving data for efficient analysis. This simplifies both the testing and evaluation of results.

Black-Box, Grey-Box, and White-Box Testing

Operational testing can be distinguished between these three approaches: Black-Box, Grey-Box, and White-Box testing. The differentiating factor is the information available to the tester for test creation and execution. For the embedded domain, the following characteristics apply.

Black-Box Test

In Black-Box Testing, the tester receives a test object as a black box along with a description of how the Black Box should behave, usually in the form of requirements. There is no information about the internal structure. The tester creates test cases, executes them, and compares the responses of their Black-Box with the expected values derived from the specification.

Grey-Box Test

Test case creation in Grey-Box testing is essentially like Black-Box testing, but the tester has basic knowledge of the internal structure, for example, through descriptions of internal states the system can assume. However, the tester does not have direct access to the implementation or the code.

White-Box Test

In White-Box testing, the tester has all the information, including insight into the codebase. In practice, this approach often leads to lower product quality than the Black-Box approach. From a quality assurance perspective, this approach should never be used as a reference for deriving expected values. However, there are meaningful exceptions, such as when White-Box testing is used to test defensive programming constructs, like sequentially repeating null pointer checks, which cannot be stimulated with Black-Box approaches.

Conclusion

It is unclear whether coverage reports available to the tester after execution are considered White Box or Black Box. This remains somewhat ambiguous. However, it is clear that coverage reports can help identify gaps in testing compared to requirements and/or gaps in requirements compared to the code.

Support and Training

SolvNetPlus

Explore the Synopsys Support Community! Login is required.

SNUG

Erase boundaries and connect with the global community.

Connect with the Synopsys TPT Team

mil-sil-hil-pil testing tpt