For embedded software development projects, code coverage has always played an important role in order to show that all parts of the code have been tested. In particular, the ISO 26262 standard requires fulfilling coverage metrics such as statement coverage, decision coverage or MC/DC.
Despite the analysis of code coverage being performed in most development projects, the handling is often inefficient. As the code coverage is mostly measured during test execution using instrumented code, the user must explicitly run all tests in order to obtain the desired metrics. Further, the tests typically need to be executed again on the non-instrumented code in order to obtain the test results for the code that goes into production.
Code coverage in BTC EmbeddedTester – Integrated, automated and certified
The code covereage is calculated and reported automatically whenever a new test case is created or imported with BTC EmbeddedTester. As this happens entirely in the background, no interaction or manual test execution is needed to update the corresponding report. The coverage calculation in BTC EmbeddedTester is also addressed by the ISO 26262 certificate from TÜV Süd, showing suitability for the use in safety critical projects up to ASIL D.
The coverage report is structured into three main sections. While the first section provides an overview of the different metrics, the second contains a detailed list of all individual coverage goals. The third section shows the source code including additional information regarding the coverage status of each code line.
If the production code has been generated by dSPACE TargetLink, the code coverage report also provides traceability to the original model, making the corresponding model element for a particular coverage goal easily identifiable.
We’ve got you covered
The coverage metrics that BTC EmbeddedTester addresses go far beyond standard goals such as Statement or Decision Coverage. Structural metrics with an even finer granularity such as Condition Coverage and MC/DC make the tool ideal for safety critical ASIL D projects. The “Domain Coverage” goal allows you to flexibly define slices of variables data range as individual coverage goals, e.g. in order to address the ISO 26262 objectives for equivalence classes. The robustness goals like “Range Violation”, “Division by 0” or “Downcast” provide information regarding critical events in the code that should ideally not be reachable.
Intelligent analysis and automatic test generation for structural coverage goals
BTC EmbeddedTester not only calculates the achieved coverage for test data that has been imported or manually created. Powerful analysis engines based on Model-Checking technology are further able to analyze all coverage goals fully automatically and generate corresponding structural test data to achieve full coverage. For code parts that can’t be covered, the tool provides mathematical proof to show that they are unreachable. This allows you to reveal dead code for structural goals, while for the robustness goals it proves that the corresponding critical event can never occur.