基于需求的测试是否适用MC/DC

1 背景

在航空领域做基于需求的用例生成时，会生成一类MC/DC用例。这就带来一个问题，即：MC/DC是DO-178针对A级软件的结构覆盖要求，属于白盒测试；而基于需求的测试，不管被测对象是软件、设备还是系统，都是一种黑盒测试；因此，在基于需求的黑盒测试中，是否适用MC/DC规则？

2 什么是MC/DC?

所谓MC/DC（Modified Condition / Decision Coverage），即修改条件/判定覆盖。相比于DO-178B，DO-178C中MC/DC定义发生了改变，主要是为了更好的适应判定中存在耦合条件的情况。具体差异这里不展开讨论。本文仍然按照DO-178B Unique Cause MC/DC进行讨论。

考虑如下语句：

if A or (B and C)then …，其中A、B、C为布尔变量

上述条件语句中，逻辑表达式“Aor (B and C)”为判定，A、B、C为条件。

满足MC/DC规则的用例集，应使每个条件独立决定判定结果，即其他条件保持不变，独立条件的变化导致判定结果变化。针对该判定，一个可能的MC/DC用例集如下表所示：

表1：A or (B and C)的MC/DC用例表

用例编号	A	B	C	判定
1	True	True	False	True
2	False	True	False	False
3	False	True	True	True
4	False	False	True	False

假设令B为独立条件，即判定的结果由条件B独立决定，显然应使A为False，C为True，即为上表中的用例对{3, 4}。同样，针对条件A的用例对为{1, 2}, 针对条件C的用例对为{2, 3}。

由上表可见，3个条件的判定，用4个用例即实现了MC/DC要求的覆盖。实际上，对于由n个非耦合条件构成的判定，能够获得数量为n+1的用例集，满足MC/DC，也即最小用例集。

3 一个需求实例

考虑下述需求：

当温度高于30℃且保持不少于10s，或湿度高于80%且保持不少于30s，应告警。

如果测试仅要求做判定覆盖，则下述两条用例即可满足：1）设置温度高于30℃且保持10s，检查告警出现；2）设置温度小于30℃、湿度低于80%，检查不应触发告警。

如果需要检查每个条件是否有效，则应对上述需求进行结构分解。该需求中，判定为：(A and B) or (C and D)，4个条件分别为：

• A := (T>30), 其中T为温度；

• B := (t1>=10)，其中t1为条件A变化时重置为0的时钟；

• C := (H>80), 其中H为湿度；

• D := (t2>=30)，其中t2为条件C变化时重置为0的时钟；

4个条件最多可构成16个不同的测试用例。按照MC/DC规则，每个条件能够独立决定判定，由下表所示的5个用例即可满足。因此，采用MC/DC规则对需求进行结构覆盖，也是一种有效的用例设计方法。

表2：(A and B) or (C and D)的MC/DC用例表

编号	T	t1	H	t2	A	B	C	D	判定
1	31	10	81	0	True	True	True	False	True
2	29	10	81	0	False	True	True	False	False
3	31	0	81	0	True	False	True	False	False
4	31	0	81	30	True	False	True	True	True
5	31	0	79	30	True	False	False	True	False

说明：该例中，由于包含时间变量，某些用例的判定结果会随时间发生变化。因此在实际应用中应设计尽可能对时间不敏感的用例。

4 分析

从上述过程可见，应用MC/DC规则生成基于需求的测试用例，是一个自然过程。

某种程度上，MC/DC可以看作一种筛选规则，即从由多个输入变量赋值构成的组合中（n个bool变量有2^n种组合），选择出一组数量较少的赋值组合（最少为n+1个，最多为2n个），能够保证每个条件至少一次影响判定结果，从而用更少的用例实现更好的测试效果。（能不能对判定中的条件进行全覆盖测试呢？这也是常见问题。实际中，一个判定包含几十个条件的情况并不少见。假设包含20个条件，全覆盖的用例数为1,048,576个，而MC/DC的用例数最少为21个，最多40个。所以这不是能不能的问题，是可不可行的问题。）

实际上，需求中普遍存在由多个条件构成判定的情况。如果要对需求中各个条件的有效性进行测试，就需要确定一种规则。MC/DC是在测试领域被较为广泛的理解、接受的规则，且具有较高的性价比（从用例数量和测试效果的角度）。虽然DO-178中将MC/DC作为软件结构覆盖的要求，但并不妨碍在需求中应用MC/DC进行需求结构覆盖及用例生成。

同时，DO-178及其相关文献中，对MC/DC 规则进行了明确解释，一定程度上避免了实际应用中在规则上的争议；另外，DO-178C在唯一原因（Unique Cause）MC/DC之外，允许屏蔽（Masking）MC/DC和短路（Short Circuit）MC/DC，增强了MC/DC的适用性。这都促进了在面向需求的用例生成中应用MC/DC。

需要注意的是，在需求测试中应用MC/DC，更多是可行性的问题。MC/DC是一种结构覆盖，但是大量需求是基于自然语言的，较难自动化获得其结构关系。关于如何将需求结构化，则是另外一个问题。

5 总结

MC/DC作为一种结构覆盖准则，本身不存在应用场景的限定。不管是针对需求、代码还是模型，只要适用且可行，都可以应用MC/DC来进行用例生成。

作为补充，在相关MC/DC研究报告中明确指出，MC/DC可以应用于开发过程中的任何地方。在源代码中应用MC/DC是最低级别的覆盖，而在需求中应用MC/DC是最高级别的覆盖。

说明

本文是非正式说明，仅供参考、讨论。