CODEWITHSUNDEEP
cmatlabsimulink
codec
codec

Reputation: 355

Code based testing in TPT with respect to Model based Testing

In my project, am using TPT as the testing environment and we using model based testing. The code coverage is normally comes around 80%. But the customer requires a 100% cover coverage and so want to use .c and .h files for testing.

I am new to this type of testing, as we only did model based testing. May I know how to use TPT in terms of code based testing?

Upvotes: 1

Views: 1318

Answers (3)

Jay Abraham
Jay Abraham

Reputation: 151

You can use tools like Simulink Design Verifier to automatically generate tests to increase coverage. Simulink Coverage can then be used to check how much coverage you are able to get at the Simulink model level (i.e. performing coverage analysis on the Simulink model), then generating code and checking how much coverage you are able to achieve at the code level. You can use Simulink Test to automate this process. See this documentation page for more detail.

If you are not able to achieve high coverage at the model level, then that could mean you design is not completely testable. E.g. it might have dead logic. Simulink Design Verifier can also tell you up front if dead logic exists.

If you only want to perform your analysis on the code, you can use Polyspace Code Prover to check if you have uncreachable code or dead code at the code level. Tools like Simulink Design Verifier and Polyspace Code Prover are formal methods based and they are able to mathematically analyze your design.

Upvotes: 0

jens
jens

Reputation: 26

C-code as well as Simulink models can be tested using TPT. There is no difference in the test development but only in the test execution environment. For testing C-code one can decide if the C-code shall be tested in the so called SiL-mode in Simulink where the C-Code is embedded in Simulink as so called S-function. The generation of the S-function can be doen automatically by m-scripts dependent of the code generator.

Alternatively in TPT C-code can be tested in two ways. The first is using the so called EXE-platform where a test harness is build in C-code and to be compiled by the user by its own compiler. The second alternative is the so called FUSION platform where the user writes an interface that fits a well definid API to its system under test and compiles it as dll. This dll is simulated at the FUISON.

If 100% statement or condition coverage is required TPT comes with a feature called TASMO. TASMO generates test cases automatically to fulfill a maximum of coverage of a Simulink or TargetLink model.

I’m one of the TPT developer. For further information about TPT you can visit our website.

Upvotes: 1

goofy
goofy

Reputation: 559

TPT alone will not help here, since it is basically only a test automation tool for time dependent embedded systems.

More advanced model-based testing tools usually create test cases from executable models of the system under test. They explore (symbolically) the model (or in general code) and generate inputs that cover all the paths, transitions, conditions etc. existing in the model. This part is what you are missing - you need a code exploration tool (like reactis for C to name just one example)

So the kind of tools like "Reactis for C Tester" (http://www.reactive-systems.com/c-testing-tool.html) are completely automatically generating all the test inputs. They calculate these test inputs from searching the C-code (Alternatively you can also search in the Simulink model). It uses a solver for this so it is able to reach 100% coverage. The user does not have to manually implement anything in a user interface like PikeTec TPT.

To solve your problem and to reach 100% coverage you apply Reactis directly to your source code - not to a model. After that you can then read the generated inputs with TPT and stimulate the system under test with it. Alternatively: If you are using the Simulink PC-target (EXE-files) it is also possible to read the generated inputs directly from your EXE-file using file access.

The reason why these exploration tools are often not used directly on the production code is that even relative small systems (like a controller of an engine etc.) lead to far too many test inputs. This is the reason why in model-based testing we create an abstract model of the system to test: the abstract model will not contain all these many unimportant states/path of the production code.

Your case seems to be simpler: you have already 80% code coverage with manual designed test cases so exploration tools should not have any problem to raise this automatically to 100%. You will also save the time for writing the test stimuli in TPT.

Upvotes: 0

Related Questions