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.