MBD软件开发测试之单元测试

ISO26262:2018 Part-6是功能安全的软件部分，其中Clause-9, -10, -11分别是在软件单元层面、软件集成层面以及整个嵌入式软件层面的Verification。标准中在谈及软件单元测试、软件集成测试、嵌入式软件测试时，会谈到“测试方法”、“测试用例设计方法”、“结构化覆盖度方法”等相关方法。本文对这些方法在软件单元测试中的使用进行说明。
 

测试方法：

• Requirements-based test (基于需求测试)

用于确认软件单元完全正确的实现了“软件单元层面的需求”，"软件单元层面的需求"包括：软件单元设计和分配给软件单元的安全需求。
 

•  Interface test (接口测试)

接口测试的是为了验证软件单元之间的交互的数据(软件单元的输入/输出数据)的完整性。
 

• Fault injectiontest (故障注入测试)

通过注入故障的方式，用于验证软件单元的“故障检测及处理”功能的正确性。软件单元需要承担哪些“故障检测及处理”功能？需要注入哪些“故障”呢？

这涉及到在功能安全中，从技术角度，软件需要承担的职责：

1）系统层面的TSC中定义的安全机制中，需要软件完成的部分（如：多样性算法）

通俗的话来说就是：分配给软件的任务，软件要完成。

2）硬件层面对软件提出的诊断硬件失效的要求（如：传感器开路诊断）

3）需要有安全机制应对软件的系统性失效，这是通过软件安全分析/软件依赖性分析等来识别的（如：控制流监控）

通俗的话来说就是：软件在运行时，要保证自身是足够安全的。

故障注入的方式如：改变变量的值、改变代码、改变uC各寄存器值、插入桩函数等。

• Resource usage evaluation (资源使用评价)

用于确认在最坏情况下，资源（CPU时间、ROM、RAM等）的使用情况

• Back-to-back comparison test between model and code, if applicable (背靠背测试)       

是在基于模型开发的场景下，用于确认模型与代码之间的一致性。

测试方法是如何来进行测试的方法。

不同的测试方法，所采用的测试环境/工具等往往是不一样的。如：资源消耗测试、基于需求的测试、背靠背测试，其测试方法/使用的工具环境等都是不一样的。因此ISO 26262 Part8 9.4.2.3中有这样的要求：test cases shall be grouped according to the test methods to be applied（测试用例需要按照所应用的测试方法来进行分组）。

“基于需求测试”与“接口测试”都是基于软件单元设计，其测试方法可以认为是一致的。

测试用例设计方法：

结构化覆盖度：

接下来我们举一个例子，综合考虑:

• 测试方法：基于需求测试 & 接口测试
• 测试用例设计方法：需求分析 & 等价类分析 & 边界值 & 错误猜想
• 结构化覆盖度：分支覆盖

说明：本示例中的逻辑，是为了示例的简单而杜撰的，不具备实际参考价值。

软件单元设计：

需求分析的测试用例设计方法：

说明：考虑了“分支覆盖度”。

• 分析输入/输出

• 分析输入/输出数值

• 设计测试用例

等价类分析的测试用例设计方法：

根据输入的值域范围，构造等价类，在每个等价类中，选择有代表性的值

注：在选择代表性值时，可尽量采用与"需求分析方法"相同的值，以减少不必要的重复的测试用例。

• 设计测试用例

边界值分析的测试用例设计方法：

基于"等价类分析"中识别的等价类，分析每个等价类的上下边界。之后在每个边界点识别：边界值、比边界略大值、比边界略小值。

• 设计测试用例

错误猜想的测试用例设计方法：

错误猜想的方法是应用已有的经验/教训（如：以往的缺陷，专家经验等）来设计测试用例。

在本示例中，根据以往的经验，当电芯电压为0时，程序容易发生错误。

至此，对该软件单元的测试用例设计就完成了。