MC/DC requires all of the below during testing:[1]
Each entry and exit point is invoked
Each decision takes every possible outcome
Each condition in a decision takes every possible outcome
Each condition in a decision is shown to independently affect the outcome of the decision.
Independence of a condition is shown by proving that only one condition changes at a time.
MC/DC is used in avionics software development guidance DO-178B and DO-178C to ensure adequate testing of the most critical (Level A) software, which is defined as that software which could provide (or prevent failure of) continued safe flight and landing of an aircraft. It is also highly recommended for SIL 4 in part 3 Annex B of the basic safety publication[2] and ASIL D in part 6 of automotive standard ISO 26262.[3]
Additionally, NASA requires 100% MC/DC coverage for any safety critical software component in Section 3.7.4 of NPR 7150.2D.[4]
DefinitionsEdit
Condition
A condition is a leaf-level Booleanexpression (it cannot be broken down into simpler Boolean expressions).
Decision
A Boolean expression composed of conditions and zero or more Boolean operators. 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 cases, 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.
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.[5]
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]
Another example that could be considered as "cheating" to achieve higher MC/DC is:
/* Function A */voidfunction_a(inta,boolb,boolc,boold,boole,boolf){if(a==100){if(b||c)// statement 1if(d||e||f)// statement 2}}
/* Function B */voidfunction_b(inta,boolb,boolc,boold,boole,boolf){boola_is_equal_to_100=a==100;boolb_or_c=b||c;boold_or_e_or_f=d||e||f;if(a_is_equal_to_100){if(b_or_c)// statement 1if(d_or_e_or_f)// statement 2}}
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.[6]
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]
RC/DCEdit
In 2002 Sergiy Vilkomir proposed reinforced condition/decision coverage (RC/DC) as a stronger version of the MC/DC coverage criterion that is suitable for safety-critical systems.[7][8]
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.[9]
^Rajan, Ajitha; Heimdahl, Mats; Whalen, Michael (March 2003). "The Effect of Program and Model Structure on MC⁄DC Test Adequacy Coverage" (PDF). {{cite journal}}: Cite journal requires |journal= (help)
^Kapoor, Kalpesh; Bowen, Jonathan P (2005). "A formal analysis of MCDC and RCDC test criteria". Software Testing, Verification and Reliability. Wiley Online Library. 15 (1): 21–40. doi:10.1002/stvr.306. S2CID 35276126.
External linksEdit
An Investigation of Three Forms of the Modified Condition Decision Coverage (MCDC) Criterion
October 18, 2023
modified, condition, decision, coverage, code, coverage, criterion, used, software, testing, contents, overview, definitions, criticism, also, references, external, linksoverview, editmc, requires, below, during, testing, each, entry, exit, point, invoked, eac. Modified condition decision coverage MC DC is a code coverage criterion used in software testing Contents 1 Overview 2 Definitions 3 Criticism 4 RC DC 5 See also 6 References 7 External linksOverview EditMC DC requires all of the below during testing 1 Each entry and exit point is invoked Each decision takes every possible outcome Each condition in a decision takes every possible outcome Each condition in a decision is shown to independently affect the outcome of the decision Independence of a condition is shown by proving that only one condition changes at a time MC DC is used in avionics software development guidance DO 178B and DO 178C to ensure adequate testing of the most critical Level A software which is defined as that software which could provide or prevent failure of continued safe flight and landing of an aircraft It is also highly recommended for SIL 4 in part 3 Annex B of the basic safety publication 2 and ASIL D in part 6 of automotive standard ISO 26262 3 Additionally NASA requires 100 MC DC coverage for any safety critical software component in Section 3 7 4 of NPR 7150 2D 4 Definitions EditCondition A condition is a leaf level Boolean expression it cannot be broken down into simpler Boolean expressions Decision A Boolean expression composed of conditions and zero or more Boolean operators 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 cases 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 EditThis section s factual accuracy is disputed Relevant discussion may be found on Talk Modified condition decision coverage Please help to ensure that disputed statements are reliably sourced January 2018 Learn how and when to remove this template message 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 5 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 Another example that could be considered as cheating to achieve higher MC DC is Function A void function a int a bool b bool c bool d bool e bool f if a 100 if b c statement 1 if d e f statement 2 Function B void function b int a bool b bool c bool d bool e bool f bool a is equal to 100 a 100 bool b or c b c bool d or e or f d e f if a is equal to 100 if b or c statement 1 if d or e or f statement 2 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 6 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 RC DC EditIn 2002 Sergiy Vilkomir proposed reinforced condition decision coverage RC DC as a stronger version of the MC DC coverage criterion that is suitable for safety critical systems 7 8 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 9 See also EditElementary comparison testingReferences Edit Hayhurst Kelly Veerhusen Dan Chilenski John Rierson Leanna May 2001 A Practical Tutorial on Modified Condition Decision Coverage PDF NASA IEC 61508 3 2010 ISO 26262 2011 Part 6 Table 12 NASA Software Engineering Requirements NASA Rajan Ajitha Heimdahl Mats Whalen Michael March 2003 The Effect of Program and Model Structure on MC DC Test Adequacy Coverage PDF a href Template Cite journal html title Template Cite journal cite journal a Cite journal requires journal help http www hbni ac in phdthesis engg ENGG02201004005 pdf bare URL PDF Vilkomir S A Bowen J P 2002 Reinforced condition decision coverage RC DC A new criterion for software testing International Conference of B and Z Users Lecture Notes in Computer Science Springer Verlag 2272 291 308 doi 10 1007 3 540 45648 1 15 ISBN 978 3 540 43166 4 Vilkomir S A Bowen J P 2006 From MC DC to RC DC formalization and analysis of control flow testing criteria Formal Aspects of Computing Springer Nature 18 1 42 62 doi 10 1007 s00165 005 0084 7 S2CID 10467796 Kapoor Kalpesh Bowen Jonathan P 2005 A formal analysis of MCDC and RCDC test criteria Software Testing Verification and Reliability Wiley Online Library 15 1 21 40 doi 10 1002 stvr 306 S2CID 35276126 External links EditWhat is a Decision in Application of Modified Condition Decision Coverage MC DC and Decision Coverage DC May 1 2020 archive An Investigation of Three Forms of the Modified Condition Decision Coverage MCDC Criterion Retrieved from https en wikipedia org w index php title Modified condition decision coverage amp oldid 1170056387, wikipedia, wiki, book, books, library,
