您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   模型库  
会员   
   
基于 UML 和EA进行分析设计
6月23-24日 北京+线上
人工智能、机器学习 TensorFlow
6月30日-7月1日 直播
图数据库与知识图谱
8月21日-22日 北京+线上
   
 
 订阅
【ASPICE4.0】实操讲解软件集成测试:单元间动态测试 vs 组件间动态测试
 
 
  27  次浏览      1 次
 2025-6-23
 
编辑推荐:
本文主要实操讲解了软件集成测试,重点对比分析了 单元间动态测试 vs 组件间动态测试。 希望对您的学习有所帮助。
本文来自于微信公众号耐思时刻,由火龙果软件Linda编辑、推荐。

今天主要实操讲解下软件集成测试,重点对比分析下 单元间动态测试 vs 组件间动态测试。

一、核心概念说明

先来讲讲这两个测试的相关定义与测试场景。

软件详细设计(SWE.4)中,会包含单元间的动态交互图。涉及到不同单元集成到某一个组件,关注单元间,在运行时的消息传递、时序关系及状态转换。

如:单元 1 调用 单元 2 时,参数传递顺序、返回值处理是否符合设计图。

而在软件架构设计(SWE.3)中,会包含组件间的动态交互图。涉及到不同组件集成,关注组件间,在软件集成中的接口兼容、宏观时序和协议。

如:组件 1 调用 组件 2 时,参数传递顺序、返回值处理是否符合设计图。

一个组件可能包含一个或多个单元。

一个单元可能包含一个或多个函数。

层级关系:

组件 (Component) > 单元 (Unit) >函数(Function)。

在ASPICE中,无论是单元间的动态交互测试,还是组件间的动态交互测试,都可以归到软件集成测试这个过程域来测试。

二、相同点分析

两个测试核心目标是一样的,都是为了验证动态交互行为。

两者都基于动态交互图(如序列图、状态图、活动图)进行测试,目标是验证软件元素(单元或组件)之间通过接口进行的消息传递、事件触发、状态转换、时序逻辑是否符合设计要求。

实操中,两种测试的核心,都是检查信息流和控制流的正确性。

关注接口方面的测试:

两种测试都高度关注接口(Interface)的定义和使用,包括接口(函数名、参数、返回值)、协议(调用顺序、超时、错误处理)和数据(类型、范围、有效性)。

实操中,测试用例会覆盖接口调用的各种边界条件、异常输入、以及接口协议要求的各种时序场景(如重试机制、并发访问)。

黑盒/灰盒测试为主:

两种测试均主要关注外部可见的交互行为,而非内部实现细节(黑盒)。 但在单元/组件测试时,通常也会结合对内部状态或日志的观察(灰盒)。

实操中,测试时,通过接口注入输入参数,然后观察输出结果(返回值、状态变化、事件触发、对其他单元的调用)是否符合预期。

可能需要查看日志或调试信息来辅助判断内部状态。

三、不同点分析

测试对象与范围不对(核心差异):

单元间动态交互测试的测试对象是软件单元(Software Unit)。

单元通常对应详细设计中的最小可测试单元,如一个C文件中的一组紧密相关的函数。

动态交互图描述的是这些内部单元之间如何协作完成一个具体的、局部的功能。

组件间动态交互测试的测试对象是软件组件(Software Component)。

组件是架构设计中的主要构建块,具有明确定义的接口和功能职责,通常由多个单元组成。

动态交互图描述的是这些独立部署或可复用的组件之间如何协作完成一个子系统或系统的功能。

测试层次与目的:

单元间测试:属于单元测试(SWE.4) 或 单元集成测试(SWE.4/SWE.5的过渡) 范畴。 目的是在组件集成前,尽早发现单元接口定义错误、逻辑错误、资源竞争(如并发单元间)、时序问题,确保组件内部的协作基础牢固。

一般是开发者在编码后立即进行的“微观”测试,保证不同单元组合在一起能正确工作。

组件间测试:属于软件集成测试(SWE.5) 的核心部分。

目的是验证架构设计定义的组件接口、协议和协作逻辑是否正确实现,发现组件集成问题、接口协议不匹配、资源冲突(如内存、总线)、性能瓶颈、以及跨越组件边界的错误处理。

一般是集成工程师在组件开发完成后进行的“中观”测试,确保独立开发的组件能按预期协同工作。

测试用例的抽象层次:

单元间测试: 用例通常更具体和底层,关注函数调用的参数组合、返回值、异常抛出、回调触发等。

组件间测试: 用例通常更面向功能/场景,关注组件如何协作完成一个用户可见的功能或用例,验证端到端的交互流和结果。

四、实例说明

下面以一个简化的车窗控制系统为示例,展开描述分析:

相关背景信息描述

该部分软件架构中包含如下四个软件组件,如下图:

WindowManager:车窗管理组件(主控制器)

MotorDriver:电机驱动组件

SafetySensor:安全传感器组件

GPIO:硬件输入输出控制组件

WindowManager单元组件中包含如下三个单元:

WindowManager_Process:车窗控制周期处理函数

WindowLogic:车窗控制逻辑单元

WindowCommand:命令解析单元

C语言代码如下:

组件接口声明 (component_interfaces.h)

WindowManager组件实现 (window_manager.c)

单元间动态交互测试(SWE.4级别)

以组件WindowManager为例,测试该组件内部的单元交互。

单元动态测试主要包含如下三种场景的测试:

测试每个函数(函数流程图)

测试单元间的动态交互

测试单元间接口

具体分析如下:

1、测试每个函数(函数流程图)

此时,需要对本函数中调用的其他函数进行打桩,如下图:

然后,遍历所有的分支。满足C0/C1/C2覆盖率要求(具体以OEM要求为准)。

2、测试单元间的动态交互

根据此动态行为图,需要测试两个时序。

此部分测试主要为了测试单元间的动态交互测试是否与设计要求一致,一般要求不打桩,直接调用。

这样才能真实确认相关函数接口是否能被正常调用到。

时序1:遇到障碍的情况

时序2:未遇到障碍的情况

上图,绿线部分的接口为WindowManger组件单元间的接口,故需要单元集成时进行测试。

粉色部分的接口为组件间的接口,故需在组件集成时进行测试。

按ASPCIE,无论是单元集成,还是组件集成,都是归到软件集成这个过程域里的。

3、测试单元间接口:

接口1:****intWindowCommand_Parse(const uint8_t* rawData, UserCommand* output) rawData,正常取值范围为:0,1,2

 

故一般需设置如下6组测试用例,用来测试该接口: 正常处理:

rawData=0;//最小有效值

rawData=1;//有效值等价类

rawData=2;//最大有效值

异常处理:

rawData=3;//最小无效值边界测试

rawData=100;//无效值等价类

rawData=255;//变量的最大值边界测试

接口2:void WindowLogic_Process(const UserCommand* cmd, WindowState* state) cmd,正常取值范围为:0,1,2

 

故一般需设置如下6组测试用例,用来测试该接口: 正常处理:

cmd=0;//最小有效值

cmd=1;//有效值等价类

cmd=2;//最大有效值

异常处理:

cmd=3;//最小无效值边界测试

cmd=100;//无效值等价类

cmd=255;//变量的最大值边界测试

组件间动态交互测试(SWE.3级别)

组件动态测试主要包含如下两种场景的测试:

测试组件间的动态交互

测试组件间接口

具体详见如下解析:

1、测试组件间的动态交互

根据此动态行为图,需要测试两个序列。

时序1:遇到障碍的情况

时序2:未遇到障碍的情况

2、组件间接口测试:

接口1:void WindowManager_Process(uint8_t rawInput);

rawInput,正常取值范围为:0,1,2

 

故一般需设置如下6组测试用例,用来测试该接口: 正常处理:

rawInput=0;//最小有效值

rawInput=1;//有效值等价类

rawInput=2;//最大有效值

异常处理:

rawInput=3;//最小无效值边界测试

rawInput=100;//无效值等价类

rawInput=255;//变量的最大值边界测试

接口2:void SafetySensor_GetStatus(SafetyStatus status);

status,正常取值为0,1 因为本接口函数无输入控制参数,故可能需结合其他信息,编写测试用例,测试确认其返回值范围为0~1。

接口3:void MotorDriver_Execute(cmd);

cmd,正常取值范围为:0,1,2

 

故一般需设置如下6组测试用例,用来测试该接口: 正常处理:

cmd=0;//最小有效值

cmd=1;//有效值等价类

cmd=2;//最大有效值

异常处理:

cmd=3;//最小无效值边界测试

cmd=100;//无效值等价类

cmd=255;//变量的最大值边界测试

接口4:void MotorControl(uint8_t Ctrlcmd)

Ctrlcmd,正常取值范围为:0,1,2

 

故一般需设置如下6组测试用例,用来测试该接口: 正常处理:

Ctrlcmd=0;//最小有效值

Ctrlcmd=1;//有效值等价类

Ctrlcmd=2;//最大有效值

异常处理:

Ctrlcmd=3;//最小无效值边界测试

Ctrlcmd=100;//无效值等价类

Ctrlcmd=255;//变量的最大值边界测试

五、总结

单元间动态测试与组件间动态测试是非常相似的,都在软件集成测试这个过程域来进行。

层级关系: 组件 (Component) > 单元 (Unit) >函数(Function)。

一个组件可能包含一个或多个单元。

一个单元可能包含一个或多个函数。

测试方法,一般会包含:

基于需求进行测试

基于边界值进行测试

基于等价类进行测试

单元间/组件间的动态交互,主要更关注的是测试路径,需确保所有的路径都被测试,一般不打桩。当然如果真涉及到底层运行,需要打桩,也是OK的。但需注意测试时,测试用例****需要确保有对这些函数接口的调用进行测试,以确保相关函数调用是能正常运行的。

单元内部的函数流程图测试,主要更关注本函数内部逻辑,调试的其他函数,经常采用打桩的方式。

 

   
27 次浏览       1
 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证

最新活动计划
DeepSeek大模型应用开发 6-12[厦门]
人工智能.机器学习TensorFlow 6-30[直播]
基于 UML 和EA进行分析设计 6-23[北京]
嵌入式软件架构-高级实践 7-9[北京]
用户体验、易用性测试与评估 7-25[西安]
图数据库与知识图谱 8-23[北京]
 
 
最新文章
iPerson的过程观:要 过程 or 结果
基于模型的需求管理方法与工具
敏捷产品管理之 Story
敏捷开发需求管理(产品backlog)
Kanban看板管理实践精要
最新课程
基于iProcess的敏捷过程
软件开发过程中的项目管理
持续集成与敏捷开发
敏捷过程实践
敏捷测试-简单而可行
更多...   
成功案例
英特尔 SCRUM-敏捷开发实战
某著名汽车 敏捷开发过程与管理实践
北京 敏捷开发过程与项目管理
东方证券 基于看板的敏捷方法实践
亚信 工作量估算
更多...