02 - 汽车功能安全系列之概念阶段开发 - Item Definition & HARA
03 - 汽车功能安全(ISO 26262)系列: 概念阶段开发 - 功能安全需求及方案(FSR&FSC)
04 - 汽车功能安全(ISO 26262)系列: 系统阶段开发 - 技术安全需求(TSR)及安全机制
05 - 汽车功能安全(ISO 26262)系列: 系统阶段开发 - 技术安全方案TSC及安全分析
06 - 汽车功能安全(ISO 26262)系列: 系统阶段开发 - 系统安全架构
07 - 汽车功能安全(ISO 26262)系列: 硬件开发 - 硬件安全需求,安全设计及安全机制
08 - 汽车功能安全(ISO 26262)系列: 硬件开发 - 硬件随机失效概率化评估
09 - 汽车功能安全(ISO 26262)系列: 硬件开发 - 随机硬件失效量化FMEDA
10 - 汽车功能安全(ISO 26262)系列: 软件开发 - 软件开发模型及安全需求
11 - 汽车功能安全(ISO 26262)系列: 软件开发 - 软件架构安全设计
上一篇我们聊完了软件架构安全设计相关内容,接下来以此为基础进行相应软件详细设计和后续的安全测试。
01
软件详细设计
建模和编码指南约束
不同ASIL等级软件单元设计语言或标记约束
02
软件安全测试内容及方法
根据软件开发V模型,软件安全详细设计完成之后,需要进行相应的软件验证,集成及测试等内容,即V模型右边内容,具体包括,软件单元验证(Software Unit Verification),软件集成和验证(Software Integration and Verification),软件测试(Testing of the embedded Software),具体如下图所示:
细心的朋友可能已经发现了,软件单元,集成后的软件组件用的都是Verification,即验证,非Validation,即确认。最后一部分嵌入式软件用的Testing,即测试,其实也属于验证。
2.1 验证(Verification) vs. 确认(Validation)
1
简单说就是,关注实现过程,不看结果,即整个开发过程是不是按照规定的要求去做,工作输出物是否完整,至于输出结果是否满足客户预期功能或需求,不属于验证的范畴。
2
确认(Validation): 提供客观的证据,证明开发结果满足客户预期的功能或需求。旨在回答: Are we building the right product?
简单说就是,关注结果,不关心过程,即不管开发过程,关心最终输出结果是否满足客户预期需要功能或需求。
2.2 软件安全验证方法
静态分析(Static Analysis)
动态分析(Dynamic Analysis)
对于功能安全软件安全测试,软件单元验证,集成验证,嵌入式软件验证对应测试类型如下:
单元验证: 静态分析 + 动态分析,静态为主
集成验证: 静态分析 + 动态分析,动态为主
那什么是静态分析和动态分析呢?
静态测试属于最基本的测试,是指不用执行程序的测试,它主要采取代码走查、技术评审、代码审查等方法对软件产品进行测试,它主要包括:
1
软件/代码是否满足相关质量标准?
─ 走查,结对编程,检查
─ 控制流分析
─ 数据流分析
─ 静态代码分析
除不同类型的人为分析检查外,静态分析最最要内容为静态代码分析,主要目的是检查代码编写是否符合特定的编程规则。对于大部分车辆控制器代码而言,静态代码分析,即C代码静态分析(如果基于模型开发,则是自动生成的代码),主要是保证代码满足MISRA C(Motor Industry Software Reliability Association, 汽车工业软件可靠性协会)相关的要求。
静态代码分析一般可以直接采用自动化检测软件,例如SIMULINK, Model Advisor; Vector, VectorCAST; Perforce, Helix QAC等,通过配置代码检测规则,然后导入源文件进行自动化分析,如果不满足相关要求,则需要对代码进行修改直至满足为止。
2.2.2 动态分析
动态分析是指实际运行程序,并通过观察程序运行的实际结果来发现错误的软件测试技术,它包括了以下几个方面:
1
软件/代码是否做了它应该做的?
2
软件/代码是否做了它不应该做的?
3
软件/代码是否足够?
─ 结构覆盖性测试
重要的动态测试包括:
基于需求测试
─ 需管理需求和测试用例及结果的可追溯性,进行覆盖率解析。
接口测试
─ 不同软件层次接口,包括信号名称,数目,数据类型,范围测试。
错误注入测试
─ 即鲁棒性测试,故障注入测试主要目的是验证系统设计、软件设计过程所提出安全机制或安全措施的有效性,通过在特定位置注入错误,包括错误的数值,方向,频率等,对系统功能安全机制响应时间、诊断覆盖等内容进行验证。
Back-to-Back测试
─ 基于模型设计的测试,验证模型和生成的代码的一致性,即采用相同的测试用例,同时输入模型和生成的代码进行执行,对二者输出结果进行比较,一致则通过,否则存在不一致。
除基本测试方法外,ISO 26262-6:2018对不同阶段的软件安全测试环境也有相应的要求:
单元验证及集成验证: 基于开发环境的软件测试,包括模型在环,软件在环,处理器在环,硬件在环。
嵌入式软件验证: 硬件在环或车辆
2.3 软件安全测试用例导出
静态测试多自动化完成,多不需要测试用例,相对比较简单,而动态测试基本上都需要用到测试用例,那如何导出测试用例,用尽可能少的测试用例,覆盖尽可能多的测试场景,这是个很重要的问题。
操作用例的分析
03
如何保证软件安全测试完整性
首先明确一点,这里的结构覆盖率不是指我们对百分之多少的测试用例或者需求进行了测试,这是属于基于需求的测试覆盖率,它和结构覆盖率有本质区别。
结构覆盖率用于度量我们设计的测试用例在多大程度上可以覆盖我们的代码,包括代码的语句,函数,分支等等。因此,结构覆盖率又可以进一步分为:
语句覆盖率: 用于统计每个代码语句被测试用例执行的比例
分支覆盖率: 用于统计每个判定分支(即If...else等)被测试用例执行的比例
函数覆盖率: 用于统计代码中所有函数被测试用例执行的比例
调用覆盖率: 用于统计每个函数调用端被测试用例执行的比例
MC/DC(修改条件/判定覆盖率): 这个比较复杂,我们单独来讲
例如,对于测试对象:
if A==1, then f1, f2,
else if (0), then f3,
else, then f4,
end
该情况下,由于elseif (0), 函数f3永远不会被执行,所以函数调用覆盖率为3/4=75%,但所有定义的函数均被执行,所以函数覆盖率为100%。
2) MC/DC(修改条件/判定覆盖率)
MC/DC是分支测试的进一步补充,适用于判定类代码覆盖检测,它要求较为复杂:
在一个程序中每一种所有可能的输入和输出至少出现一次。
什么意思呢,我们来看个实例。例如,对于测试对象:
if A and (B or C), then⋯
else,⋯
end
理论上,对于三个输入判定条件(A, B, C),一共存在8种测试Case,为实现MC/DC全覆盖,其实只需要以下4个测试用例,即Case1 - 4,就能使得A,B,C输入和判定输出结果true和false都出现一次,且只要A,B,C一个条件值发生改变,就会最终判定结果发生变化。
为保证软件安全测试完整性,ISO 26262-6:2018还对软件单元,集成软件的测试覆盖率进行相应要求,具体包括:
需要注意的是:
1
结构覆盖率不需要一味追求100%,高结构覆盖率并不完全说明代码已经进行高质量充分测试,它只说明哪些代码没有被测试用例有效执行。
2
结构覆盖率测试可以帮我们反推前期测试用例设计是否充分,是否存在盲点,哪些地方需要进行补充,增加测试完整性。
3
结构覆盖率测试并不能解决软件事先没有考虑到的情形及功能不足。
写在最后:
END
【点赞】和【在看】= 原创的动力
多谢【点赞】和【在看】
联系客服