说一说利用工具自动生成满足覆盖度要求的测试用例的话题

在一次ASPICE评估中，有这样一段访谈记录：

问：MBD开发时，是如何实施单元测试活动的？

答：是在模型层面实施的单元测试，测试方法是MIL。

问：是如何设计的测试用例呢？

答：是功能安全相关的模块，需要满足MC/DC覆盖度。我们利用MATLAB工具，自动生成符合MC/DC覆盖度的测试用例。

软件单元测试时，使用结构化覆盖度指标(Structural coverage)，其目的何在呢？

上述的做法，是否能达成这样的目的呢？

一、手写代码场合的情况分析

① 根据详细设计中设计的软件单元逻辑（如：函数流程图），设计符合MC/DC的单元测试用例 

② 实施单元测试，度量单元测试用例执行的Source Code的覆盖情况，得到MC/DC的覆盖度指标。

如果MC/DC < 100%，则说明”Source Code”与“软件详细设计“不一致。

ISO26262:2018 Part 6-9.4.4中对此也有阐述。

如下图所示，单元测试的结构化覆盖度指标无法达成时，可会存在如下的问题：

• “inadequacies in requirements/需求不足(软件详细设计内容有缺失)“
• ”dead code/死代码”
• ”deactivated code or unintended functionality/测试不可到达的代码或非预期功能“ 

二、MBD场合的情况分析

根据”模型需求”，进行模型设计，模型设计经过充分验证后，基于“模型“自动生成”Source Code“。

如果自动生成代码工具是可信赖的，那么”模型”和”Source Code”是等效的。

如下图所示：基于模型设计，使用工具自动生成符合覆盖度要求(如：MC/DC)的测试用例，执行测试后，如果覆盖度指标MC/DC  < 100%，能否说明【模型设计的输入(模型需求)】与【模型/Source Code】的不一致呢？

当然是不能了。此两者之间，不存在逻辑关系。

也就是说：ISO26262中提到的，当单元测试的结构化覆盖度不达标时，识别可能存在的下述问题，是识别不出来的。

• “inadequacies in requirements/需求不足“
• ”dead code/死代码”
• ”deactivated code or unintended functionality/测试不可到达的代码或非预期功能“

三、工具自动生成满足覆盖度要求的测试用例的作用或目的是什么呢？

和Mathworks的老董，进行了探讨，得到如下的信息：

(1) 自动生成的测试用例，无法用作功能测试。

(2) 执行”工具自动生成的测试用例”，覆盖度不达标，说明模型设计中存在无法生成测试用例的情况，例如死逻辑。

（但目前Matlab/Simulink提供的模型检查工具，可以检查模型中的上述问题）

(3) 在做背靠背测试(模型与代码的等效性测试)时，可以使用工具自动生成测试用例。

背靠背测试的逻辑是给模型和代码相同的输入，观察输出是否一致。在这样的场景下输入数据越多越好，测试用例是否有功能意义是不重要的。并且，自动生成测试用例又不需要花费开发时间。

文章转载自公众号：仨人谈起