Structural c overage is used to identify which code structures and component interfaces have been exercised during the execution of requirements-based test procedures , facilitat ing the empirical measure ment of requirements-based test effectiveness . As the name implies, structural coverage analysis involves the scrutiny of the structural coverage to determine if there are any parts of the code which have not been sufficiently exercised, and if not, why ( Figure 1 ) .
The achievement of objectives A-7 . 5, 6, and 7 ( Figure 2 ) involves the collation of structural coverage me trics, typically by “instrumenting” a copy of the source code – that is, superimposing it with function calls to collate coverage data – and executi ng that instrumented code using requirement based test cases. These test cases primarily reference high-level requirements , supplemented by low-level requirements as needed .
Structural coverage analysis is then applied to assess the effectiveness of this testing by measuring how much of the code has been exercised. Coverage of portions of code unexecuted thus far may require addition al test cases or modifications to existing test cases, changes to requirements, removal of dead code, or perhaps the identification of deactivated code and resulting unintended functionality. An iterative “r eview, analys e , verif y” cycle is typically needed to ensure that software coverage is achieved and low-level requirements are verified, and graphical representation can be a great help.
Figure 1 : Graphical visuali s ation of code coverage in a flow graph in the LDRA tool suite
System requirements can be shown to have been correctly decomposed, implemented, and verified by combining a complete trace from requirements through to code and test cases, with the achievement of comprehensive functional test coverage and structural coverage objectives .
Figure 2 : Structural coverage analysis o bjectives for e ach s oftware l evel . Based on table A-7 from RTCA DO-178C.
Figure 2 shows that DO-178C o bjectives A7-5, 6, and 7 relate to the achievement of 100% MC/DC, decision, and statement coverage respectively. The required combination of those objectives depends on the design assurance level.
1 00% statement coverage is achieved when all the statements in the source code have been executed at least once .
100% decision coverage is achieved when each of the possible branch es at each decision point is executed at least once.
The other coverage metrics require a little more explanation.