鉴源实验室 | 软件代码结构化覆盖测试-MC/DC覆盖

作者 |?李伟 上海控安安全测评部总监

来源 |?鉴源实验室

社群 |?添加微信号“TICPShanghai”加入“上海控安51fusa安全社区”

前两篇我们介绍了白盒测试中代码结构覆盖率测试的语句和分支覆盖测试，本篇我们介绍MC/DC覆盖测试。

01

关于定义

MC/DC的全称是Modified Condition/Decision Coverage，修正条件判定覆盖率。很多文章对于定义的解释都比较专业，通常也会让人感觉理解困难，本文我们用通俗易懂的说明给大家做介绍。从字面意思看这种覆盖率是通过对条件覆盖和判定覆盖组合后进行了一定的修正达成的。我们都知道穷举测试是不可取的，所以有等价类、边界值等测试方法来选取典型情况做测试设计。MC/DC的情况也比较类似，随着代码判定条件的增多，判定内部每个条件的取值都会对判定结果产生作用，所有判定和所有条件的组合如果穷举的话是不可取的，MC/DC就对组合的方式选择进行了约束。

MC/DC涉及到了条件覆盖和判定覆盖，其中判定覆盖（分支覆盖）我们在上一篇中已经作了比较详细的说明。本篇我们就先对条件覆盖测试做简单说明。

02

条件覆盖

条件覆盖测试要求测试设计时涉及逻辑判定的每个条件均要考虑到真假两种情况。覆盖时通常不考虑每个条件测试取值对整体判定路径覆盖的影响，也不考虑条件间的组合，只考虑每个条件要设计真假两种情况。理论上在一次逻辑判定的路径选择由两个及以上条件组合决定时，条件覆盖的测试用例数要多于分支覆盖测试。

2.1 条件覆盖测试的举例

我们继续使用上篇中的一段简单代码来举例说明：

这段代码有一个逻辑判定，x < 10 && y > 10的结果是否为假，对应判定的两个分支。这样设计测试用例对应判定是基于分支覆盖来进行的，可以用如下表进行条件取值来做到分支判定100%覆盖率。

基于条件覆盖做测试设计时，我们测试用例应该要保证每个条件的真假都被覆盖到，如下表所示。

我们可以看到判定覆盖时条件y并没有取到假的情况，同样满足了判定覆盖率100%，如果刚好此情景下存在故障，仅执行了100%的判定覆盖是不能发现这个故障的。因此通过这个例子我们可以看到当参与路径判定的条件足够多时，条件覆盖的测试充分程度是高于分支覆盖的。

2.2 条件覆盖的不足

从定义要求中我们可以看到，条件覆盖只关注了每个条件的真假要覆盖到，对于条件之间的组合或组合对最终判定的影响是不关注的，如果使用仅符合于条件覆盖需要的测试设计，在某些情况下即使每个条件都做到了真假的覆盖，由于条件之间的组合，也可能导致某些路径不会被覆盖到。

我们将前例中的判定增加一个条件，如下表中所示。

例：if (x < 10 && y > 10 && z == 0)

如上表所示我们根据条件覆盖的要求，测试设计时考虑到了每个条件均做了真假两种情况的取值，但是整体的路径判定只覆盖到了为真的情况，分支判定为假的路径例中的测试设计并未覆盖到。

那我们为什么不将每种组合都做设计呢，设想一下如果参与路径判定的条件有5个时，测试用例的设计将会多达10余条。程序中的判定越多，参与判定的条件越多，这样设计的测试用例会迅速扩大至无法实际操作。MC/DC覆盖能够在两者之间进行一个很好的平衡，既考虑分支路径的判断覆盖又满足参与判定的条件取值要求。

03

MC/DC覆盖

MC/DC的覆盖要求源于DO 178适航符合性方法。该标准由美国航空无线电技术委员会（RTCA）编制发布，并作为民用飞机机载软件开发和适航认证的标准指南文件。由于民航适航认证过程的强制性，MC/DC覆盖率测试也成为民用航空电子软件适航测试过程的必须执行项。

DO 178标准首个版本于1982年发布，最新版本为2011年12月发布的第四版DO 178C。标准对MC/DC覆盖的定义原文描述如下：

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, every decision in the program has taken all possible outcomes at least once, and each condition in a decision has been shown to independently affect that decision’s outcome. A condition is shown to independently affect a decision’s outcome by: (1) varying just that condition while holding fixed all other possible conditions, or (2) varying just that condition while holding fixed all other possible conditions that could affect the outcome.

定义要求：程序里的每一个输入和输出点要至少被调用一次，程序里一个判定中每个条件要至少一次考虑达到所有可能性的结果，程序里每个判定至少一次考虑达到了所有可能性结果，并且一次判定中的每个条件已体现独立地影响该判定的结果。一个条件可以通过以下方式独立地影响决策的结果：(1)只改变该条件，同时保持所有其他可能的条件不变；或(2)只改变该条件，同时保持所有其他可能影响结果的条件不变。

原文的专业定义大家可能觉得难以理解，我们继续使用之前的例子来说明MC/DC的覆盖设计要求。

以SIL A级要求为准，示例代码的条件判断组合如下：if (x < 10 && y > 10 && z == 0)

示例中有一次判定，和3个对结果有影响的条件。设计的测试用例中，查看完整的示例代码（示例代码没有补充输入变量z）所有输入输出都做了考虑，每个条件的可能情况均做了取值，判定的两种结果都做到了测试覆盖，某条件取值变化时都保持了所有其他条件的不变。

04

MC/DC覆盖测试的设计取值模型

通常根据安全要求的等级不同，覆盖率设计要求也不同，下面我们简单对不同情况下判定和条件测试设计考虑情况进行举例。

4.1 MC/DC 测试设计 (SIL A)

其他SIL等级下的DC和SC测试设计时的情况组合我们就不列举了，前篇文档我们已做了说明，具体使用时大家也可以查阅相关的专业文档和测试设计要求文档。

05

测试小结

在执行MC/DC覆盖测试时我们有以下建议供大家参考。

1.?MC/DC覆盖测试的条件取值组合有比较详细的要求，不能简单认为已完成分支的覆盖率100%和某些条件的设计取值，就已经完成了MC/DC覆盖率的设计要求。需要根据上一章节中的标准设计取值模型或实际项目中要求的标准，对所有条件的可能情况和分支覆盖情况做整体考虑。

2.?MC/DC覆盖测试比其他结构的覆盖测试复杂，测试设计时可以使用辅助工具来演算每个条件对判定的影响情况，从而更全面的完成用例编写。

3.?提高代码的编写和阅读能力对测试会有很大的帮助，同样此类测试执行多了对代码编写质量的提升也会有很大帮助。

参考文献：

[1] RTCA DO-178C, “Software Considerations in Airborne Systems and Equipment Certification,” December 2011