<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div><br>
</div>
<div><br>
</div>
<div>Paul,</div>
<div>I should have jumped on this from the start …</div>
<div><br>
</div>
<div><i>“DO-178C doesn't require you to achieve 100% structural coverage</i></div>
<div><i>through unit tests. It requires that your requirements-based tests</i></div>
<div><i>(which can be hardware/software integration tests, software</i></div>
<div><i>integration tests or low-level tests) cover all the software</i></div>
<div><i>requirements and exercise all the code.”</i></div>
<div><br>
</div>
<div>That’s not at all how I read DO-178C. Yes, DO-178C does mandate what I would call “100% Requirements Coverage”. But in addition, Table A-7 on Structural Coverage Analysis clearly does mandate (quote):</div>
<div><br>
</div>
<div>Row 5<span class="Apple-tab-span" style="white-space:pre"> </span>"Test coverage of software structure (modified condition/decision) is achieved” for DAL A</div>
<div>Row 6<span class="Apple-tab-span" style="white-space:pre"> </span>“Test coverage of software structure (decision coverage) is achieved” for DAL A , B</div>
<div>Row 7<span class="Apple-tab-span" style="white-space:pre"> </span>“Test coverage of software structure (statement coverage) is achieved” for DAL A, B, C</div>
<div><br>
</div>
<div>While DO-178C may not explicitly mandate that said Structural Coverage be demonstrated at the unit test level, it is often impossible in practice to achieve it in any other way.</div>
<div><br>
</div>
<div><br>
</div>
<div><i>“</i><i>If </i><i>your tests haven't achieved statement coverage, then there's code that</i></div>
<div><i>you've never executed, not even once, during your testing.”</i></div>
<div><br>
</div>
<div>Yes, that’s certainly true. But merely executing any one line of code once during testing does not at all guarantee that:</div>
<div><br>
</div>
<div>a) all defects in that one line of code have been revealed</div>
<div>b) all defects in how that one line of code relates to the other lines of code have been revealed</div>
<div><br>
</div>
<div>In fact, “Statement Coverage” as a Structural Coverage criterion is the absolute weakest of all Control-Flow based Structural Coverage criteria and it has logical holes in it so big that one could drive a proverbial double decker London City bus through
them. It is trivial to show how easy-to-make defects in code would be missed (i.e., unrevealed) by Statement Coverage. IMHO, that anyone would ever be satisfied with even 100% Statement Coverage for anything but the most harmless of software is rather upsetting.
It’s quite trivial to show how even Modified Condition/Decision Coverage (MC/DC) leaves the door open to potentially unexposed defects (subtle nod to Data-flow based Structural Coverage criteria here).</div>
<div><br>
</div>
<div>And the vast majority of organizations I work with only aim for 60% to 70% Statement Coverage for even their most critical code. Shocking.</div>
<div><br>
</div>
<div><br>
</div>
<div>— steve</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</body>
</html>