4 key benefits of structural coverage for DO-178B systems

Sometimes the value of performing structural coverage (AKA code coverage) is questioned. When it’s performed as an end in itself, this might be true, but when it’s used to show the effectiveness of requirements-based testing, there are some really strong benefits.

At the SIGAda DO-178C tutorial, the penny really dropped for me on the benefits of structural coverage for DO-178B. I’d heard all of the pieces before, but everything snapped into place to give me a clear picture. I’d like to share this – in case it’s not totally obvious to everyone else. In DO-178B, testing emphasises requirements coverage.

Each requirement has one or more tests to prove that it has been implemented correctly. Structural coverage (according to DO-178B this will be statement coverage, decision coverage or MC/DC depending on the software level you're developing) is used to prove that these tests exercise all of the code. If you don’t get 100% structural coverage, it means one of four things and each requires action on your part:

• There’s a requirement missing. The code that hasn’t been covered is performing an essential activity, but no requirement indicates that this should be done.

Action: need to add a new requirement (and associated tests).

• There’s a test missing. The code that hasn’t been covered relates to an existing requirement, but no test was implemented for it.

Action: add a new test.

• Extraneous/dead code. The code that hasn’t been covered is not traceable to any requirement and isn’t needed by the application.

Action: remove the code.

• Deactivated code. The code that hasn’t been covered isn’t traceable to any requirements for the current system, but is intended to be executed in certain configurations.

Action: show that a configuration exists in which the code will execute. This means that in the context of requirements-based testing (like DO-178B requires), performing structural coverage has four key benefits:

• requirements are complete (with respect to the code);
• tests are complete;
• no code is deployed that shouldn’t be there;
• code for use in other configurations is clearly identified.

For more on structural code coverage, download our white paper: Eight top code coverage questions in embedded avionics systems