ISO26262:2018 Part-6是功能安全的软件部分，其中Clause-9, -10, -11分别是在软件单元层面、软件集成层面以及整个嵌入式软件层面的Verification。标准中在谈及软件单元测试、软件集成测试、嵌入式软件测试时，会谈到“测试方法”、“测试用例设计方法”、“结构化覆盖度方法”等相关方法。本文对这些方法在软件单元测试中的使用进行说明。
说明：本文参照的是ISO26262:2018版
测试方法：
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时，程序容易发生错误。
至此，对该软件单元的测试用例设计就完成了。
本示例采用了多种测试用例设计方法，并考虑了'分支覆盖率'。
软件集成测试及嵌入式软件整体的测试，敬请期待后续文章
联系客服
