English
中文
ISTQB
国际软件测试认证委员会中国分会

CSTQB®工作办公室 咨询热线:021-5596-0906
如需查询ISTQB®考试信息,请点击查询
新闻与活动
新闻与资讯
会议与活动
培训与考试

在线取得联系 马上咨询

资料下载

更多疑问?
请点击这里 联系我们

当前位置:首页 / 新闻与活动 / 新闻与资讯

新闻与资讯icon

ISTQB®汽车软件测试模块开始考试啦!
发表日期:2023-03-31被浏览: 1799次返回

愚您同乐

小伙伴们的迫切心情,小编已经感受到啦!马上就是愚人节了,小编跟大家开个小玩笑!言归正传,今年下半年CSTQB®即将开始ISTQB®汽车软件测试工程师模块的考试认证。

 

若您对这个模块感兴趣,欢迎扫描下方二维码,进行汽车软件测试工程师模块的认证考试预报名!

上一期,我们为大家简要介绍了“ISTQB®汽车软件测试认证工程师(CTFL®-AuT)”第一章节,点击了解详情

 

今天我将带大家一起学习这一模块中第二章节,有关 “E/E(电子电气)系统测试标准” 的知识。这部分的标准会涉及到Automotive SPICE(即:ASPICE)、AUTOSAR等相关内容。

 

Automotive SPICE(即:ASPICE)

 

过程改进遵循的原则是系统的质量取决于开发过程的质量。在这种情况下,通过与参考模型的比较来衡量组织的过程能力,过程模型提供了改进过程的方法。此外,根据评估结果,过程模型还可以用作改进组织过程的框架。

 

2001

2001年起

SPICE用户组和AUTOSIG(Automotive Special Interest Group,汽车特殊利益集团)共同编制了Automotive SPICE(ASPICE)。自2005年发布以来,该标准已在汽车行业站稳脚跟。

2015

2015年ASPICE标准发布

2015年7月,德国汽车工业协会(VDA)发布了3.0版ASPICE。

2017

2017年起

ASPICE的改进版 V.3.1将替代现有的2.5版本。因此,本段中的描述均参考ASPICE 3.1版。

 

ASPICE从两个维度定义了评估模型  

在过程维度,ASPICE定义了过程参考模型。这些模型可以当作参考,用来比对组织过程,以便能够对组织过程进行评估和改进。对于每个过程,ASPICE 都定义了其目的和结果,以及所需的行动(基本实践)和工作结果(工作产品)。如果组织需要ASPICE以外的其他参考过程,可以从标准ISO/IEC 12207或ISO/IEC 15288中获取。

在能力维度,ASPICE定义了许多过程属性。这些属性介绍了过程能力的可测量特征。对于每个过程,都有特定于过程的属性和通用属性。ISO/IEC 33020可作为评估过程能力的依据。通过这个模型,可以对过程(过程维度)的能力(能力维度)进行评估。

 

ASPICE将过程分为8个过程组,这些组又分成3个过程类  

主要过程是与公司核心过程相关的过程:

· 产品和/或服务的采购/获取(ACQ-Acquisition)。

· 产品和/或服务的供应(SPL-Supply)。

· 系统工程(SYS-System engineering)。

· 软件工程(SWE-Software engineering)。

支持过程是为其他过程提供支持的过程:

· 支持过程(SUP-Supporting)。

组织过程是为公司目标提供支持的过程:

· 项目或过程的管理(MAN-Management)。

· 过程改进(PIM-Process improvement)。

· 系统和组件的复用(REU-Reuse)。

 

对于测试工程师来说,系统开发(SYS)和软件开发(SWE)这两个过程组尤其重要。这两个过程组构成了Automotive SPICE V模型的过程。

 

能力维度中的能力级别  

评估师通过一个包含六个级别的评估系统对过程能力进行评估(以级别显示)。ASPICE对能力 级别0级到3级的定义如下:

  • L0(过程不完整):过程不存在或不能实现过程的目标。示例:测试工程师只检查了小部 分的需求。

  • L1(已执行过程):所执行的过程实现了过程目标(但执行方式与原计划可能不一致)。示例:没有测试过程的完整计划。但是,测试工程师可以展示需求的满足程度。

  • L2(已管理过程):项目对过程进行了规划,并在执行过程中进行了监督。在某些情况下, 为了实现目标,会在执行过程中调整行动计划。确定了对工作产品的要求。项目成员检查 了工作产品并进行了核准。示例:测试经理确定了测试目标,规划了测试活动,并监督了 测试过程。如有偏差,他会采取相应的措施。

  • L3(已确定过程):项目采用标准化的过程,并使用结果和反馈不断改进和提升。示例:测试经理为整个组织制定了一个通用测试策略。测试完成后(请参阅基础测试过程),测 试经理会进一步对它进行开发和改进。

 

标准的要求•测试特定过程

ASPICE根据软件和系统开发的所有过程对测试过程进行了定义 :

  • 软件单元验证(SWE.4)过程需要进行静态和动态测试。此过程会根据其详细的设计(SWE.3)对软件的组件进行评估。

  • 软件集成测试(SWE.5)会根据软件架构设计对集成的软件进行评估(SWE.2)。

  • 软件合格性测试(SWE.6)会根据软件需求对集成的软件进行评估(SWE.1)。

  • 系统集成测试(SYS.4)会根据系统架构设计对集成的系统进行评估(SYS.3)。

  • 系统合格性测试(SYS.5)会根据系统需求对集成的系统进行评估(SYS.2)。

 

评估等级和能力指标

评估师可以通过能力指标来评估过程能力。ASPICE为能力等级(过程)定义了9个过程属性(PA)。对于能力级别1到3,其定义如下(括号中以SWE.6为例):

  • PA1.1:过程执行(测试工程师通过基本测试过程确定自己的工作)。

  • PA2.1:执行管理(测试工程师负责计划、监督和控制包括测试活动在内的一些相关活动)。

  • PA2.2:工作产品管理(测试工程师负责检查包括测试文档在内的一些文档的质量)。

  • PA3.1:过程定义(负责测试过程的人员定义通用和跨项目的测试策略)。

  • PA3.2:过程部署(测试工程师应用PA3.1中定义的测试策略)。

 

对于过程执行(PA1.1),ASPICE定义了两类指标:基本实践(BP-Base Practices)和工作产品(WP-Work Products)。此外,还定义了通用实践(GP-Generic Practices)和资源。过程属性的评估基于这些指标的实现程度,设定为四个评估等级:

  • N(无/None):未实现(0%至≤15%)。

  • P(部分/Partly):部分实现(>15%,≤50%)。

  • L(大部分/Largely):大部分实现(>50%,≤85%)。

  • F(完全/Fully):完全实现(>85%,≤100%)。

要使过程达到特定能力等级,该能力等级对应级别的指标必须是“大部分实现(L)”,而低于对应级别的能力等级指标则必须是“完全实现(F)”。

 

测试策略和回归测试策略  

作为基本实践,ASPICE要求为每个测试专用过程制定测试策略。测试经理 负责在测试计划中制定测试策略。测试指南、项目目标以及合同和法规要求是制定测试策略时要考虑的基本要素。测试工程师应知晓尽早测试的测试原则。这项原则也适用于汽车环境中的软件测试。然而,这里采用这个原则还有另一个原因,那就是较高测试级别的测试环境成本显著增加。例如,要进行较高级别的测试,专门开发完成的嵌入式硬件是必须的(例如,产品原型或唯一的模型)。测试策略 不仅要定义与测试级别相适应的测试环境,还要定义测试工程师需要在哪些测试环境中执行哪些测试。

回归测试策略是测试策略的一个重要组成部分。其挑战在于如何选择经济适用的测试用例 (“测试的附加价值”)。回归策略定义了选择回归测试的目标和技术。例如,可以基于风险进行 选择。影响分析可帮助确定测试工程师在回归测试中需要关注的方面。但是,测试经理也可能会要 求测试工程师对每次发布都重复执行所有的自动化测试用例。

 

ASPICE中规定的测试文档

关于测试活动的文档,ASPICE要求测试工程师编写一些工作产品(WP),正如CTFL®规定的一样

  • WP08-50:测试规格说明(包含测试设计、测试用例和测试规程说明)。

  • WP08-52:符合ISO/IEC/IEEE 29119-3[34]要求并包含测试策略(WP19-00)的测试计划。

  • WP13-50:测试结果、测试日志、事件/偏差报告和测试总结报告。

对于每项工作产品,ASPICE都定义了其特性和内容示例。评估师可以通过现场抽查来评估这些工作产品。对于评估师来说,这些工作产品是评估过程执行情况的客观指标。

关于测试计划,ASPICE直接引用了ISO/IEC/IEEE 29119-3标准。该标准还提供了可用于其他所 需工作产品的模板,并且可以根据特定目的对这些模板进行调整。必须确保测试计划的内容能够帮 助实现过程的既定目标。

 

单元验证的验证策略和准则(SWE.4)

对于软件单元的验证(SWE.4),ASPICE 要求制定验证策略。在SWE.5/SWE.6/SYS.4/SYS.5这些与测试相关的过程中,ASPICE要求制定测试策略(请参阅2.1.2.3)。这个测试策略“只”针对动态测试。因此,它是对代码审查和静态分析(在CTFL®的术语中,这两种技术被称为“静态测试”技术)这些验证策略的补充。

测试工程师需要根据验证策略,验证产品是否符合详细软件设计的要求,以及功能性和非功能 性的需求。该策略定义了测试工程师提供证据的方式。这样,测试工程师就可以通过将静态和动态 测试技术进行不同形式的组合,实现对单元的验证。

如果开发人员更改了单元,那么测试工程师也必须对此变更进行评估。因此,单元验证的策略 也包含回归策略,具体包括:验证更改的代码、确认测试以及重复验证未更改的部分(静态和动态 回归测试)。

在SWE.4(软件单元验证).BP.2(制定单元验证准则)中,ASPICE要求制定单元验证准则,并 明确要实现的目标。因此,测试工程师应评估以下两点:单元满足非功能性需求的程度,以及单元 与详细设计的匹配程度。在进行单元验证时,可依据以下准则:

  • 单元测试用例(包括测试数据)。

  • 测试覆盖度目标(例如,判定覆盖)。

  • 借助工具进行静态分析,从而评估产品是否符合编码标准(例如MISRA-C,请参阅4.1.1)。

  • 对于无法通过工具进行静态分析的单元或部分单元,应进行代码评审。

根据Automotive SPICE(ASPICE),将验证策略文档化是单元级别测试计划的一部分。根据ISO/IEC/IEEE 29119-3,可对文档内容进行拆分,并增加关于静态测试的内容。

 

Automotive SPICE(ASPICE)中的可追溯性要求 

与CTFL®核心课程大纲相同,ASPICE也要求具有双向可追溯性。根据双向可追溯性,测试工程师才有可能完成以下工作:

  • 对影响进行分析。

  • 对覆盖进行评估,或

  • 对状态进行跟踪。

而且,测试工程师还可以确保相互关联的元素在内容和语义上保持一致。

ASPICE对纵向/垂直可追溯性和横向/水平可追溯性进行了区分:

垂直可追溯性:ASPICE要求将利益相关方的需求与软件组件相链接。这样,横跨所有开发级别 的链接可确保相关工作产品之间的一致性。

水平可追溯性:ASPICE还要求开发的工作结果与相应的测试规格说明、测试结果之间具有可追 溯性和一致性。

此外,基本实践SUP.10(变更请求管理).BP8(建立双向可追溯性)也要求变更请求和受变更请求影响的工作产品之间具有双向可追溯性。变更请求的发起是因为缺陷或问题的出现,因此,变更请求和相应的问题报告之间也需要具有双向可追溯性。由于常常会有大量和复杂的关联性,因此 连续和具有追溯功能的工具链会大有帮助,通过工具链,测试工程师能够高效地创建和管理关联/追溯性。

 

以上就是“ISTQB®汽车软件测试认证工程师(CTFL-AuT)”第二章节,有关 “E/E(电子电气)系统测试标准”中Automotive SPICE(即:ASPICE)的相关内容。

 

微信扫描下方二维码,收听ISTQB®汽车软件测试工程师模块第二章大纲内容

2023年第十二届中国软件质量工程iSQE峰会,参会报名请点击:链接

top
关于CSTQB®
机构介绍
专家工作组
注册讲师介绍
合作企业介绍
ISTQB®合作伙伴
认证项目
认证项目介绍
新闻与活动
新闻与资讯
会议与活动
培训与考试
资料中心
资料下载
常见问题
常见问题
TMMi®
TMMi®简介
资料下载
组织机构
TMMi®测试过程改进者
加入我们
加入我们
联系我们
联系我们