汽车电子与软件

文章数:1511 被阅读:4580472

datasheet推荐 换一换
随便看看
账号入驻

ASPICE-SWE.5 软件集成测试

最新更新时间:2023-02-07
    阅读数:

作者 | 小鹿

出品 | 汽车电子与软件



前言


我相信在很多公司的职位架构里面,并没有单独规划集成测试这个岗位,很多都是将集成测试与系统测试合并为一个岗位,就是软件测试。如下图展示的ASPICE的过程组可知,软件过程组涉及软件集成测试与软件合格性测试, 软件集成测试属于软件工程组的SWE.5,与我们的软件架构设计相对应。此篇我们着重介绍软件集 成测试。

图1 ASPICE过程组

那针对软件集成测试这个岗位职位,想必大家都存在很大的疑惑,它和软件合格性测试到底存在什么区别?测试内容包含哪些?怎么执行软件集成测试?接下来就跟大家介绍一下。通过此篇文章,你可以知道:

  1. 软件集成测试是什么
  2. 软件集成测试的目的
  3. 软件集成测试的测试内容
  4. 软件集成测试的依赖对象
  5. 软件集成测试执行流程



一,什么是软件集成测试?


软件集成测试是在开发人员完成代码开发、自验证和软件单元测试之后,将软件打包集成,再交由集成测试部门完成的软件测试。 单元测试关注的是软件单元;软件集成测试关注的是软件组件,是在单元测试的基础上,测试在将所有的软件单元按照架构设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动;主要是验证集成之后的软件中的软件组件(单元的集合)之间接口的交互,资源使用情况等,验证是否满足软件架构设计,软件测试用例是否覆盖了软件架构设计中的所有设计项;由此可知软件集成测试主要的范围依据是软件架构设计。

需要注意的一点是:在集成测试之前,单元测试应该已经完成,集成测试中所使用的对象应该是已经经过单元测试的软件单元。如果不经过单元测试,那么集成测试的效果将会受到很大影响,并且会大幅增加软件单元代码纠错的代价。
如下是代码四象限分布图示:

图2 代码四象限分布图示

  1. 单元测试负责的是领域代码部分,主要测试的是软件基本单元(如:函数),不会涉及到外部的依赖,测试的独立的一个部分。


  2. 集成测试负责依赖代码部分,是单元测试不能测试的部分,对“依赖”通俗的理解就是,存在除本身之外的强关联项。


小结:


在我们进行软件架构设计时,会设计组件之间的接口交互方式以及内容,开发人员根据软件架构设计的接口进行代码开发,集成测试人员根据软件架构设计进行接口测试,就形成了一个闭环(设计--开发--验证)。

软件集成测试就是在单元测试完成的基础上,根据软件架构设计文档,测试软件组件之间的接口设计,资源,需求等是否符合要求和指标的一项活动。


二,软件集成测试的目的


  1. 验证集成的软件中的软件组件是否符合软件架构设计
  2. 验证集成的软件中的软件组件是否符合软硬件接口协议
  3. 验证集成的软件中的软件组件是否符合特定属性要求(鲁棒性,可靠性)
  4. 验证集成的软件中的软件组件是否符合软件功能需求
  5. 验证集成的软件是否符合最初的软件技术指标



三,软件集成测试的测试内容


根据集成测试的定义可知,集成测试的主要测试内容就是组件间的接口交互,还包括基于需求的测试,注入故障测试,资源使用评估,模型和代码的背靠比较测试,验证控制流和数据流,静态代码分析等。

下面举个栗子说明组件接口的测试:

如下组件之间的动态行为(图1 时序图):

“手机APP”可以称之为我们的组件A,“TSP系统”可以称之为组件B,“车辆”可以称之为组件C(组件的定义遵循软件架构设计);


组件之间假如存在如下接口设计:

组件A的接口:*FuncA_1(......),*FuncA_2(......),*FuncA_3(......)

组件B的接口:*FuncB_1(......),*FuncB_2(......),*FuncB_3(......)

组件C的接口:*FuncC_1(......),*FuncC_2(......),*FuncC_3(......)

组件A中的*FuncA_1(......)假如是请求开车窗的函数接口;组件B中的*FuncB_1(......)是下车开窗指令的接口;组件C中的*FuncC_1(......)作为我们的结果返回。
那集成测试就是验证*FuncA_1(......),*FuncB_1(......),*FuncC_1(......)接口之间交互的正确性。组件之间的接口数据流向一般不止一条,根据时序来从正常值,异常值,边界值出发来设计不同测试用例。

图3 时序图



四,软件集成测试的依赖对象


集成测试依赖软件架构设计文档,软件需求说明文档,功能规范等作为协助。



五,软件集成测试执行流程


1,集成测试计划形成

  • 集成测试计划主要从几个方面考虑:环境搭建、测试工具部署、测试用例编制及执行,测试问题整理,测试报告编制。

2,集成测试用例编制

  • 测试用例的编制可以通过需求分析,等价类的分析,边界值的分析,基于经验或知识的错误推测等方向来考虑。

  • 需求的分析就是基于需求的理解设计测试用例,结果主要是判断这个功能是否OK;
  • 等价类的分析就是将输入输出进行分类,为分类选择代表性的数据进行验证;
  • 边界值的分析就是分析代码中设计的变量,参数等在达到边界,跨越边界时的情况,以此来判断是否符合设计要求,简单理解就是代码设计要考虑边界的所有情况,并设定不同边界情况的不同处理结果。
  • 基于经验或者知识的错误推测,就是结合自己测试的经验,以及结合同类项目的问题总结,增加额外的测试用例,覆盖更全的测试场景。


3,集成测试用例评审

  • 评审测试用例的设计是否覆盖软件架构设计中所有设计项,对软件架构的覆盖度。
  • 评审测试用例是否覆盖所有的功能需求
  • 评审测试用例的充分性
  • 还可以结合自己公司的要求,评审测试用例的合规性
  • 评审测试用例设计的测试环境是否与目标环境大致类似


4,执行测试用例
  • 执行测试用例的前提条件是测试环境以及测试工具部署好。集成测试前期最重要的工作之一就是部署测试工具链,根据测试的内容不同,使用的测试工具也是有差异的,汽车行业常用的测试工具为CanOe,劳巴,PCAN,E2等等。


5,编制测试报告
  • 测试报告着重体现测试内容,测试用例执行率,通过率,问题关闭率等。根据公司要求进行输出。



六,思考:软件集成测试的必要性


所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式,具体的开发工作总得从一个一个的软件单元做起,软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成,总是会出现一些常见问题,工程实践中,几乎不存在软件单元集成过程中不出任何问题的情况。同时集成测试需要花费的时间远远超过单元测试,由图2可知单元测试与集成测试关注的是不同的内容,因此直接从单元测试过渡到系统测试是极不妥当的做法,集成测试也是我们代码质量的保证之一。

开始集成测试的前提条件是完成单元测试,单元测试通过之后再进行集成测试是否问题数是0呢,我相信答案肯定是“NO”,这就是为什么需要做集成测试的原因。单元测试的场景并不能覆盖集成测试场景,一般情况下集成测试发现的问题数量是大大超过单元测试的,单元测试只是测试单个个体,独立测试都没问题,但是集成之后反而存在很多问题,那是因为集成之后存在很多的外部关联,外部关联是否测试通过是影响最后测试结果的重要因素之一。一个有效的集成测试有助于解决相关的软件与其它系统的兼容性和可操作性的问题。

单元测试是开发工程师完成的,集成测试是单独由集成测试部分完成的,不建议集成测试和单元测试由相同的人员完成。


添加下方微信加入汽车研发管理交流群
(仅限专业人士)
添加备注姓名+公司+领域


 
EEWorld订阅号

 
EEWorld服务号

 
汽车开发圈

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: TI培训

北京市海淀区中关村大街18号B座15层1530室 电话:(010)82350740 邮编:100190

电子工程世界版权所有 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号 Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved