MC/DC：与100%覆盖率的斗争

在软件测试领域，MC/DC或许已经是一个耳熟能详的词汇了，但是我们还是要不断强调如何正确使用MC/DC以及它与安全相关的重要作用。

在测试中，想要对所有变量进行100%的测试几乎是不可能的。有限的时间和资本成本也决定了测试人员无法对软件进行彻底完尽的测试。但是，测试是为软件质量保驾护航的关键，不可或缺。所以对测试人员的挑战就在于如何合理的分配测试资源以及最优化地使用这些资源。选择一个“完成标准”并据此对测试目标进行计划和优先排序，这可能是一个测试团队成功与否的关键所在。

测试计划是基于测试目标来制定的，可以有不同的颗粒度。首先，针对测试组织给出的一般定义开始制定计划，对每个测试层级上的测试对象以及每次发布的内容都给出详细的信息。本质上来讲，对测试目标的定义就隐含了衡量信息，从而决定了哪些内容应该测试，哪些内容无需测试。产品的开发阶段和边界条件会最大程度地影响测试目标的制定。

同时，测试也要符合安全标准。在软件测试中，标准是非常重要的，尤其在安全相关的产品测试中。这些标准对安全相关产品的验证提出了很高的要求。IS026262-6中指出，需求覆盖度和结构覆盖度都必须由恰当的覆盖度量来测量。这也可以视作是对验证完整性的评估。对最高安全等级（ASIL-D）的软件来说，单元级的MC/DC（修正条件/判定覆盖）是强烈推荐的。

有些人可能会因此认为MD/DC就是测试目标。实则非也。测试目标的定义是验证被测软件的属性。被测单元正确的功能性应该是测试的首要目标。MC/DC仅仅展示了是否所有的判定和条件都能通过测试，并不能用来验证系统是否正确无误的运行。因此，覆盖度是不能作为测试目标的。

一般来说，覆盖度量只能作为测试完成的标准。测试完成的标准指被测系统在何时被认为是充分测试的。测试目标和测试完成标准都在测试概念中有明确的定义。建议测试人员们在每次版本迭代发布时更新测试概念，以明确具体实施中的变化及其可能带来的影响。

如何提高MC/DC测试效率？

首先，定义基于需求的测试用例。将需求表示为用例和使用需求，例如边界值的考虑或者等价类的构建。这会帮助测试人员验证被测软件是否具备理想中的完整功能。这会帮工作人员开个好头。通过测量代码覆盖度，测试人员可能会发现尚未测试的漏洞，并据此编写相应的测试用例。

覆盖度的目标值是100%。ISO26262要求对那些未达到100%的情况做出解释。如果测试项目中包含一些测试不到的部分，例如用于调试的部分或者并行软件的配置。我们建议直接在报告中阐述覆盖度降低的原因，而不是在测试之前预先设置一个较低的覆盖度目标值。这样能提高整体测试效率，因为测试人员无需在每次改变测试单元时通过复杂的计算重新检查和调整那些需要减少的覆盖度值。

如果通过上述方法测试却没有达到100%的覆盖度，可能是由于以下几个原因:

1. 需求缺失或不完整

2. 测试用例不够

3. 测试用例识别了无效的、不可访问的或禁用的代码，或者非预期的功能

因为ISO26262要求对每一个偏差值都做出合理解释，对相关部分的代码进行可视化能够帮助测试人员快速找出导致问题的原因。（见图1）

测试往往取决于需求的质量以及软件的设计和所选的架构。为了使测试工作尽可能高效，建议测试人员了解软件架构和软件设计对测试过程的影响，以选择合适的架构和设计模式。

因此，测试过程中与软件架构和设计人员的沟通也很重要。软件架构师和设计师是纵观整个软件产品的生命周期，并有机会通过重组和分离对软件发布产生重大影响的人。

TPT与MC/DC

北汇信息和Piketec希望帮助客户轻松快速地满足所需的指标。为了实现这一目标，我们将在TPT 18中增加了两个MC/DC新功能：

1.测量C/C++和Simulink的MC/DC覆盖率；

2.使用TPT自动生成测试用例:通过这种方式，用户可以快速且轻松地将覆盖率提高到100%。

我们对算法进行了调整，用尽可能少的测试用例来做MC/DC测试。无需自己创建测试用例，只需要执行和维护最小数量的测试用例即可，也不需要购买额外的测量工具来确定覆盖率，将为客户节省大量的时间和资金成本。