在进行软件单元测试、集成测试，还有硬件和软件的接口验证，以及安全机制的验证这些阶段的时候，常常会碰到一类工作，那就是ISO 26262里的故障注入，到底要怎么去规划，还有注入之后得到的结果，又该怎样去记录；故障注入这件事情，它的目的并不是要故意去把系统给搞坏，而是要把那些有可能会出现的传感器异常、通信时丢掉了帧、存储上出了错、计算发生了溢出，或者执行的时候超了时这些情况，按照预先做好的计划，一个个地放进测试的环境里面去，然后再去观察，我们的安全机制，是不是按照事先预想好的那样去动作了；如果规划这一块做得太粗糙，测试就会很容易变成一种随手去试错的行为；而要是记录做得乱七八糟，到了后面要去做安全论证、客户评审，还有问题复盘的时候，处理起来都会变得非常麻烦。

　　一、ISO 26262故障注入怎么规划

　　要去规划ISO 26262的故障注入，是需要从安全的目标和安全的那些需求开始，一层一层地往下拆的，不能只是靠着测试人员的个人经验，去随便挑几个异常的数值就算完事了，每一个被注入的项目，都应该能够说清楚，它是对应着哪一类的失效，是用来验证哪一条安全需求的，还有，大家预期它会触发一个什么样的诊断，或者是一个什么样的降级动作。

　　1、先把要验证的对象给确定下来

　　我们要先明确一下，这一次的故障注入，目标是软件单元、软件的组件、ECU集成在一起的环境，还是台架和HIL的系统，对象不一样，注入的方式自然也会跟着不一样，在软件单元这个阶段，我们可以去注入那些返回值、边界的数值，还有状态变量上面的错误；而在集成这个阶段，就更适合去注入总线上的报文、接口的信号、时间上的延迟，还有硬件的状态这一类的问题。

　　2、从安全分析里面去提取故障的场景

　　我们需要把安全分析里提到的那些故障的原因，给转化成测试的场景，打个比方说，传感器的信号卡住不动了、CAN的报文干脆丢失了、校验失败了、电压变得不正常了、内存的读写出了错、计数器发生了跳变，这些都可以成为我们的测试场景，不过要注意，不要只是去测那些容易实现的故障，还要去关注那些严重度高、暴露频率高，还有对诊断覆盖的要求比较高的场景。

　　3、把注入的条件和退出的条件都给定义清楚

　　每一条测试用例，都需要写明白故障到底是在什么位置被注入的、在什么时刻注入的、它持续了多长的时间、故障的值是多少、被重复了多少次，以及最后是用了什么方式恢复的，举例来说，在整车上电之后多少秒去注入这个故障，故障会持续几个周期，等到恢复之后，系统是不是允许自动从降级的状态里退出来，只有当这些条件都被写清楚了，换一个人来复测的时候，才不至于跑出来另外一套完全不同的结果。

　　4、要提前把观测的点给确认下来

　　在做故障注入的时候，不能只是看一看界面上有没有亮起报警就算完了，我们应该提前就确认好，都要去采集哪些观测点的数据，比如说，诊断故障码、错误计数器、安全状态机的状态、控制输出的信号、日志的记录、总线上的报文、复位的标志，还有执行的时间等等，要是没有了这些观测点，测试得到的结果，就只能是停留在“看上去好像是有反应了”这种比较含糊的层面上。

　　二、ISO 26262故障注入结果怎么记录

　　对于ISO 26262故障注入的结果，所做的记录要能够支撑得起后续的复现、判断，还有追溯这些工作，记录并不是简简单单地写上一句“通过了”或者是“失败了”就行了的，而是要把故障到底是怎么被加进去的、系统又是怎么去响应的、还有实际的响应跟预期之间，究竟是不是一致，都给写得明明白白。

　　1、去记录测试用例的基本信息

　　每一条记录里面，至少都要包含用例的编号、关联的是哪一条安全需求、故障的类型是什么、注入的对象是哪一个、是在什么样的测试环境里面跑的、软件和标定的版本号、负责的测试人员，还有测试的日期，关于版本的信息，是不能够被省略掉的，实际上，很多后期的争议，都是因为代码在后来已经被改过了，可是从记录里面，却根本看不出来当时跑的是哪一个版本。

　　2、去记录实际注入的整个过程

　　要把具体的注入步骤都给写清楚，比方说，是修改了哪一个输入的信号、屏蔽掉了哪一条报文、强制修改了哪一个变量的值、让哪一个接口返回了一个错误的代码，如果在这个过程中用到了脚本，或者是HIL的工程文件，那么也要把脚本的名字、相关的参数，还有执行的日志都给记录下来，这样做，是为了避免到了最后，手头只剩下一张截图，却怎么也说不清楚它的来源。

　　3、把预期的结果和实际的结果都记录下来

　　预期的结果，是要在测试之前就提前写好的，比如说，系统应该要进入到安全的状态、输出的范围会被限制到某一个数值之内、诊断故障码要在规定的周期里面完成置位、故障恢复之后会把那些临时的状态给清除掉，而实际的结果，则是需要用数据来说话的，最好能尽量附上日志里的时间点、波形的截图、报文的记录，还有状态变化的描述。

　　4、去把判定的结论给记录下来

　　结论这一项，可以分成通过、失败、还需要再分析、还有受限通过这么几类，不要把那些还不确定的问题，直接就写成是通过了，如果在测试当中发现，响应的时间超出了要求、诊断故障码压根就没有置位、恢复的逻辑表现得异常、或者是不该触发降级的时候却被误触发了，那么就需要把问题单的编号，还有整改的责任人，都给一起写进去。

　　三、ISO 26262故障注入结果怎样闭环

　　如果ISO 26262故障注入得到的结果，只是安安静静地躺在测试报告里面，那么它的价值，其实是会被大大削弱的，真正有用的做法，是要把测试中发现的那些问题，再给传回到需求、设计、代码，还有安全分析的文件里面去，要让每一次出现的异常，都有一个明确的、可以去的地方。

　　1、失败的项目一定要关联到问题单

　　当故障注入出现了失败之后，我们应该去建立一个正式的问题单，在里面写明复现的步骤、影响的范围、关联了哪些安全需求，还有初步的一个判断，等到修复的工作都做完了以后，还需要用同一条故障注入的用例，再去重新测一遍，而不能仅仅是靠着开发人员的一个说明，就把它给关闭掉。

　　2、有偏差的项目要去说明理由

　　有些时候，实际跑出来的结果跟预期的并不完全一样，但是在经过了仔细的评估以后，认为这个情况还是可以被接受的，那么对于这类情况，就需要去写一份偏差的说明，在这个说明里面，要包含造成偏差的原因、可能带来的风险影响、有没有采取什么补偿的措施，还有得到批准的记录，不能够仅仅写上一句“项目接受了”就完事了。

　　3、测试的证据要做到统一归档

　　测试的计划、用例、脚本、日志、截图、报告、问题单，还有复测的记录，这些东西应该被放在同一条可以追溯的链条上面，到了后期做评审的时候，就可以从一条安全需求，一路追到测试用例，再追到具体的执行结果，还有那个问题最终的闭环情况。

　　4、计划要跟着变更一起去更新

　　当软件的运行逻辑、诊断的阈值、通信的矩阵、硬件的接口，或者是安全的需求发生了变动以后，原来那份故障注入的计划，就需要被拿出来重新再检查一遍，该去补充的场景，要及时地补充进去，那些已经失效了的记录，也要把它标记成失效，不能一直把旧版本下的测试结果，继续用在新版本的产品上面。

　　总结

　　总地来说，ISO 26262故障注入要怎么去规划，还有它的结果又该怎样去记录，这里面最核心的一点，就是要让故障的场景有一个清楚的来源，注入的过程可以被人复现，响应的结果能够被清晰地判断，而出现的异常问题呢，又可以被最终闭环掉，在规划的阶段，我们要从安全的需求和安全分析出发，把对象、场景、条件和观测点都明确下来；在记录的阶段，则是要把版本、步骤、数据、结论，还有证据，都留得完完整整，这样做了之后，故障注入才不至于仅仅是走了一次测试的过场，而是能够真正地撑起功能安全的验证，还有后续的那些评审工作。