ISO26262:2018 Part-6是功能安全的软件部分，其中Clause-9, -10, -11分别是在软件单元层面、软件集成层面以及整个嵌入式软件层面的Verification。标准中在谈及软件单元测试、软件集成测试、嵌入式软件测试时，会谈到“测试方法”、“测试用例设计方法”、“结构化覆盖度方法”等相关方法。本文对这些方法在软件单元测试中的使用进行说明。
测试方法：
- Requirements-based test (基于需求测试)
用于确认软件单元完全正确的实现了“软件单元层面的需求”，"软件单元层面的需求"包括：软件单元设计和分配给软件单元的安全需求。
- I**nterface 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时，程序容易发生错误。
至此，对该软件单元的测试用例设计就完成了。
版权归原作者 电力电子空间 所有， 如有侵权，请联系我们删除。