Content deleted Content added
→Definitions: Fixed typo Tags: canned edit summary Mobile edit Mobile app edit Android app edit |
Cleanup/needs sources |
||
Line 1:
{
'''Modified condition/decision coverage''' ('''MC/DC''') is a [[code coverage]] criterion used in [[software testing]].
Line 16 ⟶ 17:
==Definitions==
;Condition: A condition is a leaf-level [[Boolean algebra (logic)|Boolean]] [[Expression (programming)|expression]] (it cannot be broken down into simpler Boolean expressions).;Decision: A Boolean expression composed of conditions and zero or more [[Boolean operator (computer programming)|Boolean operator]]s. A decision without a Boolean operator is a condition. A decision does not imply a change of control flow, e.g. an assignment of a boolean expression to a variable is a decision for MC/DC.
;Condition coverage: Every condition in a decision in the program has taken all possible outcomes at least once.
;Decision coverage: Every point of entry and exit in the program has been invoked at least once, and every decision in the program has taken all possible outcomes at least once.
;Condition/decision coverage: Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, and every decision in the program has taken all possible outcomes at least once.
;Modified condition/decision coverage: Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently. A condition is shown to affect a decision's outcome independently by varying just that condition while holding fixed all other possible conditions. The condition/decision criterion does not guarantee the coverage of all conditions in the module because in many [[test case]]s, some conditions of a decision are masked by the other conditions. Using the modified condition/decision criterion, each condition must be shown to be able to act on the decision outcome by itself, everything else being held fixed. The MC/DC criterion is thus much stronger than the condition/decision coverage.
==Criticism==
{{
It is a misunderstanding that by purely syntactic rearrangements of decisions (breaking them into several independently evaluated conditions using temporary variables, the values of which are then used in the decision) which do not change the semantics of a program can lower the difficulty of obtaining complete MC/DC coverage.<ref>{{cite journal | title = The Effect of Program and Model Structure on MC⁄DC Test Adequacy Coverage | last1 = Rajan | first1 = Ajitha | last2 = Heimdahl | first2 = Mats | last3 = Whalen | first3 = Michael | date = March 2003 | url = http://se.inf.ethz.ch/old/teaching/2009-S/0276/slides/fiva.pdf }}</ref>
This is because MC/DC is driven by the program syntax. However, this kind of "cheating" can be done to simplify expressions, not simply to avoid MC/DC complexities. For example, assignment of the number of days in a month (excluding leap years) could be achieved by using either a switch statement or by using a table with an enumeration value as an index. The number of tests required based on the source code could be considerably different depending upon the coverage required, although semantically we would want to test both approaches with a minimum number of tests.{{Citation needed|date=November 2022}}
Another example that could be considered as "cheating" to achieve higher MC/DC is:<syntaxhighlight lang="c" line="1">
Line 69 ⟶ 64:
</syntaxhighlight>if the definition of a decision is treated as if it is an boolean expression that changes the control flow of the program (the text in brackets in an 'if' statement) then one may think that Function B is likely to have higher MC/DC than Function A for a given set of test cases (easier to test because it needs less tests to achieve 100% MC/DC coverage), even though functionally both are the same.<ref>http://www.hbni.ac.in/phdthesis/engg/ENGG02201004005.pdf {{Bare URL PDF|date=March 2022}}</ref>
However, what is wrong in the previous statement is the definition of decision. A decision includes 'any' boolean expression, even for assignments to variables. In this case, the three assignments should be treated as a decision for MC/DC purposes and therefore the changed code needs exactly the same tests and number of tests to achieve MC/DC than the first one. Some code coverage tools do not use this strict interpretation of a decision and may produce false positives (reporting 100% code coverage when indeed this is not the case). {{Citation needed|date=November 2022}}
==RC/DC==
In 2002 [[Sergiy Vilkomir]] proposed '''
[[Jonathan Bowen]] and his co-author analyzed several variants of MC/DC and RC/DC and concluded that at least some MC/DC variants have superior coverage over RC/DC.<ref>{{cite journal |last1=Kapoor |first1=Kalpesh |last2=Bowen |first2=Jonathan P |authorlink2=Jonathan Bowen |title=A formal analysis of MCDC and RCDC test criteria |journal=Software Testing, Verification and Reliability |date=2005 |volume=15 |issue=1 |pages=21–40 |doi=10.1002/stvr.306 |publisher=[[Wiley Online Library]]|s2cid=35276126 }}</ref>
==See also==
*[[Elementary
==References==
|