MC/DC Coverage Explained

What is MC/DC coverage?

MC/DC (modified condition/decision coverage) is a structural coverage metric that requires tests to show that every condition in a decision can, on its own, change the outcome of that decision.

More precisely, a condition C in a decision D is covered by a test suite if the suite contains two test steps X and Y (not necessarily consecutive) such that:

1. C evaluates to a different truth value in step X than in step Y;
2. every other condition in D has the same truth value in both steps; and
3. D evaluates to a different truth value in step X than in step Y.

In other words, each condition must be shown to independently affect the outcome of its decision. MC/DC was introduced by John J. Chilenski of Boeing in the early 1990s, and the definitive paper by Chilenski and Steve Miller of Rockwell-Collins was published in 1994.

What are a decision and a condition?

A decision is a boolean-valued expression that determines which path execution follows; a condition is a boolean sub-expression of a decision that contains no boolean operators.

For example, in this C statement:

if ((x > 0) && (y > 0))
    z = 1;
else
    z = 2;

(x > 0) && (y > 0) is the decision, because its value determines whether z becomes 1 or 2. x > 0 and y > 0 are the two conditions, because neither can be broken into smaller boolean expressions.

How does MC/DC differ from statement, decision and condition coverage?

Statement, decision and condition coverage only require that things happen at least once, while MC/DC requires evidence that each condition independently controls the decision, which makes it the most demanding of the four.

Condition coverage does not imply decision coverage. For the decision A && B, the two tests (A=true, B=false) and (A=false, B=true) make each condition true once and false once, yet the decision is false in both tests and is never true. MC/DC rules this out because it ties every condition to a change in the decision’s outcome.

Can you show a worked example?

Yes: for the decision A && B, three tests give full MC/DC, namely (true, true), (true, false) and (false, true).

• Condition A is covered by tests 1 and 3: A changes, B stays true, and the decision changes from true to false.
• Condition B is covered by tests 1 and 2: B changes, A stays true, and the decision changes from true to false.

The same idea scales up. For C1 && C2 && C3, these four tests achieve MC/DC:

How many tests does MC/DC need?

For a decision with N conditions, MC/DC needs at least N+1 test steps, which is far fewer than the 2^N combinations that multiple condition coverage (MCC) requires.

The examples above show this: two conditions need three tests (instead of four combinations), and three conditions need four tests (instead of eight). The gap widens quickly as decisions grow, which is why MC/DC is practical for real code where multiple condition coverage is not. The exact number depends on the structure of the decision and on how the tests are chosen, and in practice the tests must also be reachable through the system’s inputs, not just the decision in isolation.

Why do safety standards call for MC/DC?

MC/DC gives stronger evidence than decision or condition coverage that the logic of safety-critical software has been tested thoroughly, without the test-count explosion of exhaustive combinations.

The Federal Aviation Administration mandates MC/DC in its DO-178C guidelines for the most safety-critical components of aviation software, and the metric was subsequently adopted by the ISO 26262 safety standard for automotive software. See ISO 26262 Software Testing: Questions and Answers for what ISO 26262 recommends and how Reactis supports those activities. For what DO-178C asks for at each software level, see DO-178C Structural Coverage and MC/DC: Questions and Answers.

How is MC/DC defined for Simulink and Stateflow models?

Reactis applies the definitions of decision and condition to specific model elements: Logical Operator blocks, If blocks and the event and guard of Stateflow transitions.

• Logical Operator blocks. Reactis offers two modes, selected in the Coverage pane of the Info File Editor. In single-block mode the output of each Logical Operator block is a decision and its inputs are the conditions. In multi-block mode, directly connected Logical Operator blocks are grouped into one decision, and the group’s inputs that are not fed by another block in the group are its conditions. A group cannot cross a subsystem boundary and must have exactly one exiting signal line.
• If blocks. The if and elseif expressions in a Simulink If block are decisions, and their atomic boolean-valued sub-expressions are the conditions.
• Stateflow transitions. The event and guard on a transition (event[guard]) form a decision. If the label includes an event, the event is a condition (true when present); the atomic boolean expressions in the guard are conditions too.
• C and Embedded MATLAB code in models. With the Reactis for C Plugin and the Reactis for EML Plugin, decisions in that code are tracked as well.

For example, with three Logical Operator blocks A or B, C or D and a block that ANDs their outputs, single-block mode tracks three separate decisions, while multi-block mode tracks one decision with the four conditions A, B, C and D.

Does short-circuit evaluation matter?

Yes: when a boolean operator short-circuits, some conditions are never evaluated, which makes full MC/DC easier to achieve and reduces the number of MCC targets.

A short-circuited and does not evaluate its second operand when the first is false. For C1 && C2 && C3, multiple condition coverage creates 8 targets without short-circuiting but only 4 with it. In the General pane of the Info File Editor you can choose whether Reactis treats Simulink and Stateflow boolean operators as short-circuited, so that coverage is measured the way your code will actually execute.

How do I measure MC/DC in a Simulink model?

Run a test suite in Reactis Simulator; Reactis highlights the model where MC/DC targets are uncovered and can generate a coverage report from the test execution.

1. Open the model in Reactis for Simulink and load or generate a test suite. Tests you wrote yourself or created in another tool can be imported from a CSV file.
2. Execute the tests in Simulator. A red dot on a Logical Operator block’s output means that the decision has not yet evaluated to both true and false; a red dot on an input means that the port has an uncovered condition or MC/DC target.
3. Right-click a decision and choose View Coverage Details to see which targets remain.
4. Create a coverage report from the test execution to keep as evidence.

See Reactis coverage metrics and the Reactis User’s Guide chapter on coverage metrics for the full list of supported metrics.

How do I generate tests that achieve MC/DC?

Use Reactis Tester, which generates test suites automatically and uses the coverage targets that are still uncovered, including MC/DC targets, to steer the creation of each new test step.

Reactis Tester uses a patented technique called guided simulation. As it generates test data it tracks a collection of coverage metrics, and it uses the targets of those metrics that remain uncovered to influence the construction of subsequent test steps. The result is a test suite you can run, review and keep. If some targets remain, the user-guided simulation feature of Simulator lets you extend a test or create a new one by hand. See Maximizing coverage in the User’s Guide for techniques.

What if I cannot reach 100% MC/DC?

Find out why each remaining target is uncovered: it may be unreachable code, inputs that are constrained too tightly, or a target that needs a longer or more specific test; then close the gap or document a rationale.

• Unreachable targets and dead code. After test generation, examine the targets that Reactis flags as unreachable. A target that cannot be reached points to dead or redundant logic that should be fixed or justified.
• Overconstrained inputs. If the input constraints you set exclude values that can really occur, coverage will be poor and some run-time errors may be missed. Check the constraints when coverage is unexpectedly low.
• Coupled conditions. If two conditions in one decision depend on the same underlying signal, it may be impossible to change one without changing the other, so independence cannot be shown for that pair. Restructuring the logic is often the right fix.
• Targets that need specific sequences. Extend a test with user-guided simulation in Simulator.
• Documenting a rationale. ISO 26262-6 requirement 9.4.4 allows a rationale based on other methods where coverage is judged insufficient.

Does Reactis measure MC/DC for C code?

Yes: Reactis for C measures statement, decision, condition, MC/DC and multiple condition coverage, plus function and function-call coverage, for standalone C code.

The Reactis for C tool generates tests with the same guided simulation approach, highlights uncovered code and produces coverage reports. For C code that is part of a Simulink model (C Caller blocks, S-Functions and Stateflow custom code), the Reactis for C Plugin tracks coverage in that code together with the rest of the model, so one test suite can exercise both.

Is 100% MC/DC enough?

No: coverage measures how thoroughly tests exercise the logic, not whether the software produces the right results, so MC/DC needs to be paired with checks against the requirements.

A test suite can reach full MC/DC and still miss a defect if nothing checks the outputs. In Reactis you express requirements as Validator assertions and user-defined targets, and Tester searches for scenarios that violate the assertions or cover the targets. Running the same tests on generated code (back-to-back testing) checks that the code behaves like the model. See ISO 26262 software testing for how these activities fit together.