InternalFault测试策略设计及测试框架搭建分享

本文链接：https://blog.youkuaiyun.com/weixin_44955553/article/details/139593954

1.Internalfault介绍

1.1 原理

使用ECU内部故障模块关联信号无效故障的诊断，周期读取内部故障状态，并将相关的故障事件存储在应用的非易失性存储器(Nvm)中，通过22读取Nvm中故障的状态，存储的故障信息可以通过例程控制服务0x31清除。

1.2 数据结构

Internalfault的数据结构组成包括以下部分：
①FaultID:故障对应的组号,对应byte0;
②序号:用于标记故障的序号，1表示第一次发生的故障信息，2表示最后一次发生的故障信息，对应byte1，byte11;
③时间：记录故障发生的时间信息，包括年月日时分秒，对应byte2-byte7,byte12-byte17;
④车速：记录故障发生时对应的车速信息，对应byte8-byte9,byte18-byte19;
⑤FaultSignal:记录发生的具体故障，对应byte10，byte20;
第x组Internalfault的数据结构
Fault signal在此处进行进行单独说明：

byte10/20包括bit0-bit7,每个bit都可以对应一个故障，当故障发生时，对应bit置为1，解除后则置为0，例如下文提到的三个故障,假设按照如下关系mapping
①bit0→车速信号无效
②bit1→加速度信号无效
③bit2→转向角信号无效
使用判定表对以上三个情况进行分析，如下图

1.3 故障记录策略

记录策略根据需求描述而不同，此处列举两种策略：

1.3.1策略一

前置条件：无任何故障信息被记录
①当故障第一次发生时，记录byte0-byte20的信息
②当故障解除之后再次触发或发生同组内的其他故障，只更新byte11-byte20的信息
③byte0-byte10的信息在第一次记录后不会再更改，除非使用0x31服务清除

1.3.2策略二

前置条件：无任何故障信息被记录
①当故障第一次发生时，记录byte0-byte10的信息
②当故障解除之后重新触发或发生同组内的其他故障，记录byte11-byte20的信息
③当故障再次解除之后重新触发或发生同组内的其他故障，更新byte11-byte20的信息
④byte0-byte10的信息在第一次记录后不会再更改，除非使用0x31服务清除

备注：
①以上描述中，故障触发记录均需满足故障记录的条件和故障触发需要满足的使能条件
②对于周期小于1s的message,记录的时间允许有1s的误差，周期等于1s的message,记录时间允许有2s的误差

1.4 故障记录的条件以及故障触发需要满足的使能条件

1.4.1 故障记录条件

正如字面意思，在满足故障触发使能条件的前提下，设置条件对应的信息无效持续时间达到T1，触发对应bit故障，当信号恢复正常且持续时间满足T2，对应bit故障解除。
故障记录时间T1的构成图

例如：
①设置车速对应的信号无效；
②设置加速度对应的信号无效；
③设置转向角对应的信号无效；

1.4.2 故障触发需要满足的使能条件

正如字面意思，只有满足所有故障触发使能条件，设置了对应的无效信号，故障才会被触发。
假设使能条件如下:
① 在ECU正常的工作电压范围
② 汽车钥匙处于点火档，也就是常说的IG on
③ …
根据需求描述，不同公司不同产品此次均存在差异，所以此处只列举两条

2.测试点分析

根据以上的简单介绍，我们不难提炼出以下测试点：
① 测试信号无效持续时间小于T1时，不记录故障；
② 测试信号无效持续时间等于T1时，记录故障；
③ 测试信号重复触发，只更新byte11-byte20的信息；
④ 测试同组不同bit的fault触发，byte20的信息记录正确；
⑤ 测试不同组fault触发，不同组的byte0-byte20的信息记录正确；
⑥测试在设备上下电，休眠唤醒等条件后，故障信息是否被正确保留；
⑦ 测试任一使能条件不满足时，信号无效且持续时间等于T1，不记录故障；
⑧ 测试故障解除，对应bit位的信息被置为0；
⑨测试对应的数据结构；

3.测试框架搭建

3.1 针对不同策略，设置更多可复用脚本

根据以上拆分的测试点可知，当每个测试用例对应的测试点单一时，在发现软件缺陷时，更方便测试人员对问题的定位，继而在之后版本的验证时，需要执行的测试用例范围也更加准确。
基于以上的思想设计以下的测试框架：
框架结构

3.2 测试框架实现

3.2.1 通用步骤相关的函数实现

3.2.1.1 前置条件设置

根据不同的产品，设置对应的前置条件脚本，使ECU处于一个稳定正常的待测状态，本文不对此部分内容展开介绍。

3.2.1.2 使能条件设置

尽可能将所有产品此部分需求对应的使能条件融合，例如可以通过传参char EnCondi 和 int EnCondiOkNok的值控制是否设置所有的使能条件或者单独设置其中一个是使能条件。
示例伪代码如下，仅供参考：

	if (EnCondi == "AllEnable")&&(EnCondiOkNok == EnCondiOk)
	{	
		设置使能条件①满足
		设置使能条件②满足
		...
		(使能条件全部满足)
	}
	else
	{
		if (EnCondi == 使能条件①的字符串)
		{
			if (EnCondiOkNok == EnCondiOk)
			{
				设置使能条件①满足
			}
			else
			{
				设置使能条件①不满足
			}
		}
		else if (EnCondi == 使能条件②的字符串)
		{
			if (EnCondiOkNok == EnCondiOk)
			{
				设置使能条件②满足
			}
			else
			{
				设置使能条件②不满足
			}
		}
		...
		else
		{
			打印提示：传入使能条件不支持
		}			
	}

3.2.1.3 清除记录的信息以及检查清除成功设置

在测试前需保证Nvm中为空，所以通过0x31服务清除后之后通过0x22服务获取响应是否等于0。
示例伪代码如下，仅供参考：
①send 0x31 xx xxxx， clear fault message
②send 22 xxxx read fault message
③compare ② respond equal to 0

3.2.1.4 更新函数的设置

在对比较函数进行实现前，需要考虑以下两个关键点：
①针对不同策略更新数组中的信息的手段也不同；
②当存在不同bit故障时的处理；
备注：以上两点均可以通过传参控制更新，假设策略通过stgAlone和stgSync区分，同组不同bit故障触发通过overBitFlag区分。
示例伪代码如下，仅供参考：
通过传参b0b1b2解析groBit的值判断overBitFlag的值(groBit[0]判断叠加的故障，groBit[1]为FaultSignal的值)

overBitFlag = groBit[0]
switch (overBitFlag):
 	case 1:
 		updateArry函数
 	case 2:
 	     updateArry函数
 	case 3：
 		updateArry函数
 		  ....
 	default:
 	    打印提示：入参不支持
...

updateArry函数的伪代码如下

if (stg == stgAlone)
{
	根据传入的触发counter 更新数组中的内容
	switch (trigCounter):
 		case 1:
 			根据传入的组号的信息，更新对应组的byte0-byte20的信息，其他组设置为0
 		case 2:
 		case 3：
 			根据传入的组号的信息，更新对应组的byte0-byte20的信息，其他组设置为0
 		default:
 	    	打印提示：入参不支持
}
else if {stg == stgSync}
{
	根据传入的触发counter 更新数组中的内容
	switch (trigCounter):
 		case 1:
 			根据传入的组号的信息，更新对应组的byte0-byte20的信息，其他组设置为0
 		case 2:
 		case 3：
 			根据传入的组号的信息，更新对应组的byte0-byte20的信息，其他组设置为0
 		default:
 	    	打印提示：入参不支持
}
else
{
	打印提示：传入策略不支持
}

备注：以上的过程中还需要一个可以获取总线时间的函数，此处不做展开介绍