MC / DC | 软件测试 / 四个满足条件

MC/DC软件测试详解

原创已于 2025-09-19 18:18:28 修改 · 2.6k 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#MC DC 软件测试

于 2024-11-15 01:07:17 首次发布

code 专栏收录该内容

52 篇文章

订阅专栏

注：机翻，未校。

What is MC/DC?

什么是 MC / DC？

MC/DC

Modified Condition/Decision Coverage (MC/DC) is a code coverage criterion commonly used in software testing. For example, DO-178C software development guidance in the aerospace industry requires MC/DC for the highest Design Assurance Level (DAL) or Item Development Assurance Level (IDAL).
修改的条件/决策覆盖率（MC/DC）是软件测试中常用的代码覆盖率标准。例如，航空航天业的 DO-178C 软件开发指南要求 MC/DC 达到最高设计保证级别（DAL）或项目开发保证级别（IDAL）。

Code coverage is a way of measuring the effectiveness of your test cases. The higher the percentage of code that has been covered by testing, the less likely it is to contain bugs when compared to code that has a lower coverage score. There are three other types of code coverage that are worth considering in relation to MC/DC: Statement coverage, Decision coverage and Multiple condition coverage.
代码覆盖率是衡量测试用例有效性的一种方式。测试覆盖的代码百分比越高，与覆盖率分数较低的代码相比，它包含错误的可能性就越小。与 MC/DC 相关的其他三种类型的代码覆盖率值得考虑：语句覆盖率、决策覆盖率和多个条件覆盖率。

In addition to the criteria required by statement and decision coverage, MC/DC requires that ‘Each condition in a decision has been shown to independently affect that decision’s outcome’.
除了声明和决策覆盖率要求的标准外，MC/DC 还要求“已证明决策中的每个条件都独立影响该决策的结果”。

The four conditions to fulfill the requirements of MC/DC

满足 MC/DC 要求的四个条件

Modified Condition/Decision Coverage (MC/DC) is a method used in software testing to test highly critical systems.
修改的条件/决策覆盖率（MC/DC）是软件测试中用于测试高度关键系统的一种方法。

MC/DC requires that all possible states of each condition must be tested while keeping other conditions fixed. Moreover, the change in an individual condition must be shown to alter the result.
MC/DC 要求必须测试每个条件的所有可能状态，同时保持其他条件不变。此外，必须显示单个条件的变化以改变结果。

Below are the four conditions to fulfill the requirements of MC/DC:
以下是满足 MC/DC 要求的四个条件：

Each exit and entry point of the program must be executed in at least one of the test cases.
程序的每个出口和入口点必须在至少一个测试用例中执行。
Every decision is tested for all possible outcomes.
每个决定都经过所有可能结果的测试。
Each condition in a decision is tested for all possible states.
决策中的每个条件都经过所有可能状态的测试。
Each individual condition must be shown to alter the result independently.
必须显示每个单独的条件才能独立地改变结果。

A condition is a boolean expression that cannot be divided further. A decision is a combination of conditions and boolean operators.
条件是无法进一步划分的布尔表达式。决策是条件和布尔运算符的组合。

Example

Consider the following snippet of code in C++:
请考虑以下 C++ 代码片段：

# include <iostream>
using namespace std;

int main() {
 bool a = false, b = true, c = false;

 if(a && b || c){
  cout << "Inside the IF block" << endl;
 }
}

In the above snippet of code, we have three boolean variables (conditions). Below is the truth table, which shows all possible values of those variables and the result of the boolean expression (decision) in line 7 of the above snippet:
在上面的代码片段中，我们有三个布尔变量（条件）。下面是真值表，其中显示了这些变量的所有可能值以及上述代码片段第 7 行中布尔表达式（decision）的结果：

Test No.	a	b	c	a && b \|\| c
1	0	0	0	0
2	0	0	1	1
3	0	1	0	0
4	0	1	1	1
5	1	0	0	0
6	1	0	1	1
7	1	1	0	1
8	1	1	1	1

Both possible states (0/1) of each variable have been tested in the above table while keeping the other two variables constant. Moreover, the decision produced by these conditions is in both possible outcomes at least once.
在保持其他两个变量不变的情况下，每个变量的两种可能状态（0/1）都在上表中进行了测试。此外，这些条件产生的决策在两种可能的结果中至少一次。

Test numbers 0 and 1 show that the variable c can alter the result independently while keeping the other two variables fixed. Test numbers 5 and 7 show that b can independently alter the value of the result. Test numbers 3 and 7 show that a can independently alter the result. Hence, we will choose test numbers 0, 1, 3, 5, and 7 as our test cases.
测试数字 0 和 1 表明变量 c 可以独立地改变结果，同时保持其他两个变量不变。测试 5 和 7 表明 b 可以独立地改变结果的值。测试 3 和 7 表明 a 可以独立地改变结果。因此，我们将选择测试数字 0、1、3、5 和 7 作为我们的测试用例。

MCDC software testing

MCDC 软件测试

Condition coverage, not only for developers

条件覆盖率，不仅适用于开发人员

Many testers are considering or already using test design techniques, allowing them to reduce the effort in testing and still gain a good insight in the quality of systems and software. Looking at the possibilities and the available literature, often a categorization is made, to ease up technique selection for specific situations.
许多测试人员正在考虑或已经使用测试设计技术，这使他们能够减少测试工作量，并且仍然可以很好地了解系统和软件的质量。查看可能性和可用的文献，通常会进行分类，以简化特定情况下的技术选择。

White-box tests for structure, black-box for specifications

结构的白盒测试，规范的黑盒

White-box techniques are supporting the formulation of test cases based on some structure, and are therefore long time seen as something exclusively for developers, as they are the ones working with code, which is seen as such a structure. In contrast, black-box techniques support the design of test cases based on some kind of requirements or specification. Of course a good fit for the business testers as they are mainly using requirements and other specifications to show that the system is behaving as it is supposed to do and giving the results that are expected.
白盒技术支持基于某种结构的测试用例的制定，因此长期以来一直被视为开发人员的专属内容，因为他们是处理代码的人，而代码被视为这样的结构。相比之下，黑盒技术支持基于某种需求或规范的测试用例设计。当然，这很适合业务测试人员，因为他们主要使用需求和其他规范来表明系统的行为符合预期，并给出预期的结果。

This black-and-white differentiation is not a good and definitely not a correct perspective. Categorizations as such provide us some help in that they ease up our conversation and point out our focus in designing test cases, the categorization should definitely not be treated dogmatically. Professional testers nowadays even combine or integrate the corresponding techniques in exploratory testing.
这种非黑即白的区分不是一个好的，也绝对不是一个正确的视角。这样的分类为我们提供了一些帮助，因为它们简化了我们的对话并指出了我们在设计测试用例时的关注点，因此绝对不应该教条地对待分类。现在的专业测试人员甚至在探索性测试中组合或集成相应的技术。

Widen the perspective: White Box’s “condition coverage” for everyone

拓宽视野：White Box 的“状况覆盖”，适合所有人

To widen the perspective of business testers, let us have a look at condition coverage as one of the so-called white box techniques. This technique focuses on having a more in-depth test of complex conditions that represent the underlying rules for a decision in a control flow graph. While we take a look at control flow graphs (representing the structure of a piece of code or of some part of the architecture), we are aware of the fact that control flow graphs use comparable syntax elements as for instance business processes (where statements are activities and decisions … guess what … are decisions), thus the business process as such already allows us to make use of white-box techniques like statement coverage or decision coverage. Within the business processes, the underlying rules of the decision points may evenly contain complex conditions.
为了拓宽业务测试人员的视野，让我们把 condition coverage 看作是所谓的白盒技术之一。该技术侧重于对复杂条件进行更深入的测试，这些条件表示控制流图中决策的基础规则。当我们查看控制流图（表示一段代码或架构的某些部分的结构）时，我们意识到控制流图使用与业务流程（其中语句是活动和决策…你猜怎么着…是决策），因此业务流程本身已经允许我们使用白盒技术，如语句覆盖率或决策覆盖率。在业务流程中，决策点的底层规则可能均匀地包含复杂的条件。

Now coverage measures (from the white-box techniques) are typically explained in a very theoretical, almost scientific manner. They are hard to understand and therefore these techniques are not commonly applied. This especially goes for the MCDC technique. MCDC stands for Modified Condition Decision Coverage, one of the condition coverage techniques. This strong technique reduces the number of test cases from 2N to N+1, where N is the number of atomic conditions. Atomic conditions are the individual conditions that are part of the complex condition, e.g. when the complex condition is “A>18 AND B<60”, “A>18” and “B<60” are the atomic conditions.
现在覆盖率测量（来自白盒技术）通常以非常理论化、几乎科学的方式进行解释。它们很难理解，因此这些技术并不常用。这尤其适用于 MCDC 技术。MCDC 代表 Modified Condition Decision Coverage，这是条件覆盖率技术之一。这种强大的技术将测试用例的数量从 2N 减少到 N+1，其中 N 是原子条件的数量。原子条件是作为复数条件一部分的单个条件，例如，当复数条件为“A>18 AND B<60”时，“A>18”和“B<60”是原子条件。

Advantages of MCDC Modified Condition Decision Coverage

MCDC 修改条件决策覆盖率的优势

MCDC is way easier to apply than e.g. decision tables as it takes the approach to directly define the minimal set of test cases, where decision tables take the approach to define the total number of possible test cases and then reduce the numbers in a structured manner.
MCDC 比决策表更容易应用，因为它采用直接定义最小测试用例集的方法，其中决策表采用定义可能测试用例总数的方法，然后以结构化的方式减少数量。

For MCDC, the rule for designing test cases is that each of the atomic conditions in the complex condition should contribute to a false and once to a true result for the complex condition. That means, changing the value of the atomic conditions directly leads to a change in the result of the complex condition.
对于 MCDC，设计测试用例的规则是，复杂条件中的每个原子条件都应该导致复杂条件的 false 和 true 结果。这意味着，更改原子条件的值直接导致复杂条件的结果发生变化。

Let’s take the example of the complex condition A AND B:
让我们以复杂条件 A 和 B 为例：

在这里插入图片描述

Leaving us with 3 test cases (N+1) instead of 4(2N) test cases.
给我们留下 3 个测试用例（N+1）而不是 4 个（2N）个测试用例。

Now to apply this on even more complex conditions, we apply a “trick” to quickly come up with the corresponding combinations, analyzing the sequential combination of atomic conditions, so for the complex condition “A AND B AND C”, we first analyze A AND B, then B AND C and if the complex condition would be even longer than we would proceed with these same steps for the consecutive pairs:
现在，为了将其应用于更复杂的条件，我们应用一个 “技巧” 来快速得出相应的组合，分析原子条件的顺序组合，因此对于复数条件 “A AND B AND C”，我们首先分析 A 和 B，然后分析 B 和 C，如果复数条件比我们对连续对进行这些相同步骤的时间还要长：

在这里插入图片描述
Now to cover the entire complex condition, we still need to add values for atomic conditions “A” in the “test cases” 4 – 6 and “C” in the “test cases” 1 – 3 (printed in red) as follows:
现在，为了涵盖整个复杂条件，我们仍然需要为“测试用例”4 – 6 中的原子条件“A”和“测试用例”1 – 3 中的“C”添加值（以红色打印），如下所示：

在这里插入图片描述
Applying the following rule:
应用以下规则：

If the analyzed relation is combined with the other atomic condition with an “AND”-relation, then we add a “1”, whereas with an “OR”-relation, we would add a “0”, to not change the complex condition outcome.
如果分析的关系与具有 “AND” 关系的另一个原子条件组合，则我们添加 “1”，而对于 “OR” 关系，我们将添加 “0”，以免改变复杂条件结果。

Now we can still reduce the doubles:
现在我们仍然可以减少双倍值：

在这里插入图片描述
Leaving us with N+1 is 4 test cases.
留给我们 N+1 的是 4 个测试用例。

The same approach is helping us in situations which even include combinations of AND and OR and probably also with brackets. As follows:
同样的方法在甚至包括 AND 和 OR 的组合以及可能还有括号的情况下帮助我们。如下：

在这里插入图片描述
Filling the gaps accordingly:

在这里插入图片描述
And getting rid of the doubles:

在这里插入图片描述
If the number of atomic conditions is higher, you just continue this approach and you will end up with N+1 test cases (instead of 2n test cases).
如果原子条件的数量更多，你只需继续这种方法，你最终会得到 N+1 个测试用例（而不是 2n 个测试用例）。

Conclusion

结论

Allocating specific (groups of) test design techniques to different kinds of practical problems sounds like a good support for the tester in general, deciding what to use to strengthen not only the coverage but also the testing profession. However if the categorization leads to an unnecessary reduction of options for the tester, then we should cease using those categories. Categories should be supportive, not a science in itself.
将特定的（组）测试设计技术分配给不同类型的实际问题听起来像是对测试人员的良好支持，可以决定使用什么来加强覆盖率和测试专业。但是，如果分类导致测试者选项的不必要减少，那么我们应该停止使用这些类别。分类应该是支持性的，而不是一门科学。

The use of MCDC is in many situations easier and more effective than using decision tables or other techniques. Let us open ourselves up for the techniques and thoughts available in the community, without bothering about barriers that some still try to impose on us.
在许多情况下，使用 MCDC 比使用决策表或其他技术更容易、更有效。让我们敞开心扉，接受社区中可用的技术和思想，而不必理会一些人仍然试图强加给我们的障碍。

DO-178

RTCA DO-178C / EUROCAE ED-12C: Software Considerations in Airborne Systems and Equipment Certification is the primary document by which certification authorities such as the FAA and EASA approve civil software-based aerospace systems. Recently, it has become the de facto approach for demonstrating airworthiness in military avionics systems worldwide.
RTCA DO-178C / EUROCAE ED-12C：机载系统和设备认证的软件注意事项是 FAA 和 EASA 等认证机构批准基于民用软件的航空航天系统的主要文件。最近，它已成为全球军事航空电子系统中证明适航性的实际方法。

Introduction to DO-178C

DO-178C 简介

DO-178 was originally developed in the late 1970s to define a prescriptive set of design assurance processes for airborne software that focused on documentation and testing. In the 1980s, DO-178 was updated to DO-178A, which suggested different levels of activities dependent on the criticality of the software, but the process remained prescriptive.
DO-178 最初是在 1970 年代后期开发的，用于定义一套专注于文档和测试的机载软件的规范性设计保证流程。在 1980 年代，DO-178 更新为 DO-178A，它根据软件的关键性建议不同级别的活动，但该过程仍然是规范性的。

Released in 1992, DO-178B was a total re-write of DO-178 to move away from the prescriptive process approach and define a set of activities and associated objectives that a design assurance process must meet. This update allowed flexibility in the development approaches that could be followed, but also specified fundamental attributes that a design assurance process must have, which were derived from the airworthiness regulations.
DO-178B 于 1992 年发布，是对 DO-178 的完全重写，摆脱了规范性流程方法，并定义了设计保证流程必须满足的一组活动和相关目标。此更新为可以遵循的开发方法提供了灵活性，但也指定了设计保证流程必须具备的基本属性，这些属性源自适航法规。

History of DO-178

Many advances in software engineering technologies and methodologies since the release of DO-178B made consistent application of the DO-178 objectives difficult. In 2012, DO-178C/ED-12C was released, which clarified details and removed inconsistencies from DO-178B, and which also includes supplements that provide guidance for design assurance when specific technologies are used, supporting a more consistent approach to compliance for software developers using these technologies. DO-178C guidance also clarified some details within DO-178B so that the original intent could be better understood and more accurately met by developers.
自 DO-178B 发布以来，软件工程技术和方法的许多进步使得 DO-178 目标的一致应用变得困难。2012 年，发布了 DO-178C/ED-12C，它澄清了 DO-178B 的细节并消除了不一致之处，其中还包括补充内容，为使用特定技术时的设计保证提供指导，为使用这些技术的软件开发人员提供更一致的合规性方法。DO-178C 指南还阐明了 DO-178B 中的一些细节，以便开发人员可以更好地理解和更准确地满足最初的意图。