(1) 概述
如下图所示,ISO26262:2018 Part 6-10是”软件集成和集成验证”。其对应的V模型左边的活动是”Part 6-7软件架构设计”。
- 软件架构设计:定义了构成软件的各软件组件,软件组件间的接口和交互,以及资源消耗(如:CPU Load, ROM/RAM等)的设计等。
- 软件集成:当各软件组件开发完成之后,按照软件架构设计中定义的软件组件间的接口将各个软件组件集成在一起而形成”集成后的软件”。
- 软件集成验证,对集成后的软件进行验证,验证软件组件之间的接口和交互是否符合软件架构设计,验证集成后的软件的资源消耗是否符合软件架构设计等。
验证的方法有多种,其中验证组件之间的接口和交互的方法主要是测试,该测试被称为“软件集成测试”。
软件集成测试是伴随着软件集成来实施的,随着软件的每一次集成,都需要有对应的集成测试来验证集成的两个部分之间的接口和交互。
(2) 测试方法
- Requirements-based test (基于需求的测试)
用于确认"集成后的软件”是否实现了分配到“软件架构(软件组件)层面的软件需求”,也就是验证”集成后的软件”是否符合”软件架构设计”。
ASPICE的”SWE.5 软件集成与集成测试”中,提示了软件集成测试的如下测试内容,读者可借鉴下:
- 软件组件之间的正确数据流 the correct dataflow between software items
- 软件组件间数据流的时效性和时间依赖性 the timeliness and timing dependencies of dataflow between software items
- 使用接口对所有软件组件发出的信号的正确解释 the correct interpretation of data by all software items using an interface
- 软件组件间的动态交互 the dynamic interaction between software items
- 对接口的资源消耗目标的遵守 the compliance to resource consumption objectives of interfaces
- Interface test (接口测试)
接口测试的是为了验证"软件组件之间的接口”、以及”软硬件接口”。
软件集成测试时,验证"集成后的软件”是否符合”软硬件接口设计”,是关注的“软件的接口(与硬件的接口)”。
在系统集成测试(ISO 26262 Part4-7)时,也会验证”软硬件接口”,但此时是关注的软件与硬件之间的接口。
- Fault injection test (故障注入测试)
通过注入故障的方式,用于验证在软件架构设计时所设计的”安全机制”的有效性。
- Resource usage evaluation (资源使用评价)
用于确认在最坏情况下,资源(CPU时间、ROM、RAM等)的使用情况
- Back-to-back comparison test between model and code, if applicable (背靠背测试)
(3) 测试用例设计方法
(4) 结构化覆盖度
如上表格中的结构化覆盖度指标是对组件间”交互”的覆盖度要求。
函数覆盖:每一个函数(接口)被覆盖到。
调用覆盖:组件之间的每一次”调用”被覆盖到。
示例:
下图是软件架构设计中,三个软件组件之间交互的设计:
“函数覆盖”的目标是覆盖Error_Handle_1和Error_Handle_2提供的2个接口:
“调用覆盖”的目标是覆盖Temp_Check与Error_Handle_1/Error_Handle_2之间的每次调用:
(5) 示例
接下来举一个例子,综合考虑:
- 测试方法:基于需求测试 & 接口测试
- 测试用例设计方法:需求分析 & 等价类分析 & 边界值
- 结构化覆盖度:调用覆盖
说明:
- 本示例中的逻辑,是为了示例的简单而杜撰的,不具备实际参考价值。
- 本示例中的软件架构设计,以三个组件之间的控制图为例
(5.1)软件架构设计
(5.2) 需求分析的测试用例设计方法:
(考虑“调用覆盖度")
如下图所示,分析组件之间的调用关系,其中①②④是涉及到组件之间的交互。
(5.3) 等价类分析的测试用例设计方法:
根据输入的值域范围,构造等价类,在每个等价类中,选择有代表性的值
注:在选择代表性值时,可尽量采用与"需求分析方法"相同的值,以减少不必要的重复的测试用例。
(5.4) 边界值分析的测试用例设计方法:
基于"等价类分析"中识别的等价类,分析每个等价类的上下边界。之后在每个边界点识别:边界值、比边界略大值、比边界略小值。
至此,软件集成测试的测试用例设计就完成了。