Aspice介绍——测试流程


ASPICE简介

ASPICE(Automotive Software Process Improvement and Capacity Determination)汽车软件过程改进及能力评估,是汽车行业用于评价软件开发团队的研发能力水平的模型框架。最初由欧洲20多家主要汽车制造商共同制定,于2005年发布,目的是为了指导汽车零部件研发厂商的软件开发流程,从而改善车载软件的质量。
在ASPICE3.1中定义的范围:系统工程领域和软件工程领域。
a


一、V字模型的示意

所有工程过程(即:系统工程和软件工程)是按照“V” 字模型原理进行组织:左边的每个过程是与右边的过程正好相对应。
V

二、测试领域

test
本文从SWE.6:软件合格性测试、SYS.4:系统集成和集成测试、SYS.5:系统合格性测试展开。

2.1 SWE.6:软件合格性测试

过程目的

软件合格性测试的目的是:确保集成软件得到测试,以提供符合软件需求的证据。

过程成果

成功实施本过程的结果如下:

  1. 制订了与项目计划和发布计划相一致的包括回归测试策略在内的软件合格性测试策略,以测试集成软件;
  2. 根据软件合格性测试策略,开发了集成软件的软件合格性测试规范,以适于提供符合软件需求的证据;
  3. 根据软件合格性测试策略和发布计划,选择了软件合格性测试规范中的测试用例;
  4. 使用选定的测试用例测试了集成软件,并记录了软件合格性测试结果;
  5. 建立了软件需求与软件合格性测试规范中的测试用例之间的一致性和双向可追溯性,建立了测试用例与测试结果之间的一致性和双向的可追溯性;
  6. 总结了软件合格性测试结果,并与所有受影响方沟通。

基本实践(BP)

SWE.6.BP1: 制订包括回归测试策略在内的软件合格性测试策略。制订与项目计划和发布计划相一致的软件合格性测试策略。该策略包括当软件项发生变更时,对集成软件实施再测试的回归测试策略。[成果 1]
SWE.6.BP2: 开发软件合格性测试规范。根据软件合格性测试策略,基于验证准则,开发包含测试用例在内的软件合格性测试规范。测试规范应适于提供集成软件符合软件需求的证据。[成果 2]
SWE.6.BP3: 选择测试用例。从测试规范中选择测试用例。根据软件合格性测试策略和发布计划,选定的测试用例应具备足够的覆盖率。[成果 3]
SWE.6.BP4: 测试集成软件。使用选定的测试用例测试集成软件。记录测试结果和日志。[成果 4]

注 1: 不符合项的处理,见 SUP.9。

SWE.6.BP5: 建立双向可追溯性。建立软件需求与软件合格性测试规范中的测试用例之间的双向可追溯性。建立软件合格性测试规范中的测试用例与软件合格性测试结果之间的双向可追溯性。[成果 5]

注 2:双向可追溯性有助于覆盖率、一致性和影响分析。

SWE.6.BP6: 确保一致性。确保软件需求与软件合格性测试规范中的测试用例的一致性。[成果 5]

注 3:一致性由双向可追溯性支持,并可通过评审记录来证明。

SWE.6.BP7: 总结和沟通结果。总结软件合格性测试结果,并与所有受影响方沟通。[成果 6]

注 4:在总结中提供来自测试用例执行的所有必要信息,以便其他方判断结果。

2.2 SYS.4:系统集成和集成测试

过程目的

系统集成与集成测试过程的目的是: 集成系统项以产生与系统架构设计相一致的集成系统,并确保系统项得到测试,以提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据。

过程成果

成功实施这个过程的结果如下:

  1. 制订了与项目计划、发布计划和系统架构设计相一致的系统集成策略,以集成系统项;
  2. 制订了包括回归测试策略在内的系统集成测试策略,以测试系统项之间的交互;
  3. 根据系统集成测试策略,制订了系统集成测试规范,以适于提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据;
  4. 根据集成策略将系统项集成为完整的集成系统;
  5. 根据系统集成测试策略和发布计划,选择了系统集成测试规范中的测试用例;
  6. 使用选定的测试用例测试了系统项之间的交互,并记录了系统集成测试结果;
  7. 建立了系统架构设计的要素和系统集成测试规范中的测试用例之间的一致性和双向可追溯性,并建立了测试用例和测试结果之间的双向可追溯性;
  8. 总结了系统集成测试结果,并与所有受影响方沟通。

基本实践(BP)

SYS.4.BP1: 制订系统集成策略。制订与项目计划和发布计划相一致的系统项集成策略。基于系统架构设计识别系统项,并定义其集成顺序。[成果 1]
SYS.4.BP2: 制订包括回归测试策略在内的系统集成测试策略。遵循集成策略,制订集成系统项的测试策略。该策略包括当系统项变更时对集成的系统项实施再测试的回归测试策略。[成果 2]
SYS.4.BP3:开发系统集成测试规范。根据系统集成测试策略,开发系统集成测试规范(包括系统项的各集成步骤的测试用例)。测试规范应适于提供集成的系统项符合系统架构设计的证据。[成果 3]

注 1:系统要素之间的接口描述是系统集成测试用例的输入
注 2:符合系统架构设计是指,定义的集成测试适于证明系统项之间的接口满足系统架构设计的规范。
注 3:系统集成测试用例可关注:
 系统项之间的正确信号流
 系统项之间信号流的时效性和时序依赖性
 使用接口正确解释所有系统项的信号
 系统项之间的动态交互
注 4:可使用仿真环境(例如:硬件在环仿真,车载网络仿真,数字原型)支持系统集成测试。

SYS.4.BP4: 集成系统项。根据系统集成策略,将系统项集成为集成系统。[成果 4]

注 5:系统集成可逐步集成系统项(例如:作为原型硬件的硬件要素,外设(传感器和执行器),机械和集成软件),以产生与系统架构设计相一致的系统。

SYS.4.BP5: 选择测试用例。从系统集成测试规范中选择测试用例。测试用例的选择应根据系统集成测试策略和发布计划具备足够的覆盖率。[成果 5]
SYS.4.BP6: 执行系统集成测试。使用选定的测试用例执行系统集成测试。记录集成测试结果和日志。[成果 6]

注 6:不符合项的处理,见 SUP.9。

SYS.4.BP7: 建立双向可追溯性。建立系统架构设计要素与系统集成测试规范中的测试用例之间的双向可追溯性。建立系统集成测试规范中的测试用例与系统集成测试结果之间的双向可追溯性。[成果 7]

注 7:双向可追溯性有助于覆盖率、一致性和影响分析。

SYS.4.BP8: 确保一致性。确保系统架构设计要素与系统集成测试规范中的测试用例之间的一致性。[成果 7]

注 8:一致性由双向可追溯性支持,并可通过评审记录来证明。

SYS.4.BP9: 总结和沟通结果。总结系统集成测试结果,并与所有受影响方沟通。[成果 8]

注 9:在总结中提供来自测试用例执行的所有必要信息,以便其他方判断结果。

2.3 SYS.5:系统合格性测试

过程目的

系统合格性测试过程的目的是:确保集成系统得到测试,以提供符合系统需求的证据,并确保系统可用于交付。

过程成果

成功实施这个过程的结果如下:

  1. 制订了与项目计划和发布计划相一致的系统合格性测试策略(包括回归测试策略),以测试已集成的系统。
  2. 根据系统合格性测试策略,制订了已集成系统的系统合格性测试规范,以适于提供符合系统需求的证据。
  3. 根据系统合格性测试策略和发布计划,选择了系统合格性测试规范中的测试用例。
  4. 使用选择的测试用例测试了已集成的系统,并记录了系统合格性测试的结果。
  5. 建立了系统需求与系统合格性测试规范中测试用例之间的一致性和双向可追溯性,并建立了测试用例与测试结果之间的一致性和双向可追溯性。
  6. 总结了系统合格性测试结果,并与所有受影响方沟通。

基本实践(BP)

SYS.5.BP1: 制订包括回归测试策略在内的系统合格性测试策略。 制订与项目计划和发布计划相一致的系统合格性测试策略。该策略包括当系统项变更时,对已集成系统实施再测试的回归测试策略。[成果 1]
SYS.5.BP2: 开发系统合格性测试规范。 根据系统合格性测试策略,开发系统合格性测试规范(包括基于验证准则的测试用例)。该规范应适于提供集成系统符合系统需求的证据。 [成果 2]
SYS.5.BP3: 选择测试用例。 从系统合格性测试规范中选择测试用例。对于系统合格性测试策略和发布计划而言,所选择的测试用例应具备足够的覆盖率。 [成果 3]
SYS.5.BP4: 测试已集成的系统。 使用已选择的测试用例测试已集成的系统。 记录系统合格性测试的结果和日志。 [成果 4]

注 1:不符合项的处理,见 SUP.9。

SYS.5.BP5: 建立双向可追溯性。建立系统需求与系统合格性测试规范中的测试用例之间的双向可追溯性。建立系统合格性测试规范中的测试用例与系统合格性测试结果之间的双向可追溯性。[成果 5]

注 2:双向可追溯性有助于覆盖率、一致性和影响分析。

SYS.5.BP6: 确保一致性。确保系统需求和系统合格性测试规范中的测试用例之间的一致性。 [成果 5]

注 3:一致性由双向可追溯性支持,并可通过评审记录来证明。

SYS.5.BP7: 总结和沟通结果。 总结系统合格性测试结果,并与所有受影响方沟通。 [成果 6]

三、测试类型之间的区别

qubie

软件合格性测试

软件合格性的测试对象:已经集成的软件
测试层级:软件集成测试之后
测试操作:测试依赖软件接口

系统集成测试

系统集成测试的对象:软件与硬件集成的接口
测试层级:软件合格性测试之后
测试操作:接口操作

系统合格性测试

系统合格性测试的对象:已集成的系统
测试层级:系统集成测试之后
测试操作:测试操作和反馈均在应用层显示

四、追溯性和一致性

追溯性和一致性在 Automotive SPICE 3.1 PAM 是通过两个单独的基本实践来提出。追溯性指的是在工作产品之间存在引用或链接,由此可以进一步支持覆盖率、影响分析、需求实施状态跟踪等。相反,一致性关注内容和语义。
一致性

  • 16
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
ASPICE(Automotive SPICE)是一种用于评估软件开发流程的国际标准。其主要目的是确保汽车软件开发过程的质量和可靠性。ASPICE对软件开发活动进行了分类,以便更好地评估其成熟度和质量水平。 ASPICE软件开发流程包括以下几个阶段:需求工程、软件架构设计、软件详细设计、软件编码、软件测试和软件集成。每个阶段都有相应的活动和要求,以确保开发过程按照规范进行。 在需求工程阶段,软件开发团队收集和分析客户需求,并将其转化为软件需求规格。然后,在软件架构设计阶段,团队会设计软件的整体结构和模块划分。接下来,在软件详细设计阶段,团队将具体的设计方案转化为软件设计规格。 软件编码阶段是将设计规格转化为可执行代码的过程。在这个阶段,开发人员需要按照编码规范和标准进行编写,并对代码进行测试和调试。 软件测试阶段是验证软件是否满足需求规格的重要环节。测试包括单元测试、集成测试和系统测试等,以确保软件的功能和性能符合预期。 最后,软件集成阶段将各个模块和组件集成为一个整体,并进行测试和验证。 ASPICE软件开发流程的评估以能力级别的方式进行,从级别0到级别5依次递增。级别0表示没有任何软件开发活动,而级别5表示有完善的软件开发过程,所有活动都被跟踪和文档化。 总之,ASPICE软件开发流程涵盖了需求工程、架构设计、详细设计、编码、测试和集成等阶段,以确保汽车软件开发的质量和可靠性。它为软件开发团队提供了一种规范和评估方法,帮助他们提高开发过程的效率和质量。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

诊断协议那些事儿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值