中文翻译《ASPICE in practice》之“ENG.10 系统测试”

2.12 ENG.10 系统测试

2.12.1 目的

系统测试过程的目的是确保对每个系统要求的实施进行合规性测试,并确保系统已准备好交付。

整个系统都经过测试,包括硬件、软件和机械。正如系统集成测试过程 ENG.9 可以与软件集成测试过程 ENG.7 类似一样,系统测试过程 ENG.10 除一些小细节外,在方法上可以视为与软件测试过程 ENG.8 相同。因此,以下讨论将主要关注与 ENG.8 的不同之处。后期阶段(SOP——开始生产前不久)的系统测试有时称为“交付测试”。

2.12.2 汽车行业特有的特征

此过程的实施通常具有明显的验证特征,并且在其他方面也超出了 Automotive SPICE 要求,因为仅测试系统要求是不够的。原因是,在实践中,系统要求规范以及系统级别的客户要求规范并未显示所需的质量和完整性。此外,在某些领域,系统要求无法准确描述。例如,在车辆开发中,底盘电子设备的微调就是如此。与传统的系统测试不同,测试驾驶员与开发工程师合作进行长时间的测试,调整底盘参数,直到每个人都满意(另请参阅我们在 ENG.7、ENG.8 和 ENG.9 流程中关于“汽车行业特有的特征”的讨论)。

2.12.3 基本实践

BP1:制定系统测试策略。制定与发布策略一致的系统测试策略。

关于这一点,请参阅 ENG.8 BP1 中的讨论。根据系统需求的验证标准,可以确定何时可以认为测试已成功通过。例如,对于功能测试,验证标准详细描述了预期的系统行为。理想情况下,系统测试用例的开发应在需求分析后进行(参见 ENG.2)。目标应该是通过相关测试用例实现对现有系统需求的 100% 覆盖,以证明所有系统需求都已得到满足。发布策略及其样本阶段(有关汽车行业样本阶段的说明,请参阅 SPL.2)是系统测试策略的基础。

BP2:制定系统测试的测试规范。制定系统测试的测试规范,包括要在集成系统上执行的测试用例。测试用例应证明符合系统要求。

注意:系统测试过程应在系统开发生命周期的早期开始。在开发测试用例和可测试需求方面,与系统需求分析ENG.2、系统架构设计ENG.3和需求引出ENG.1密切相关。

我们在ENG.8 BP2中显示的考虑也适用于此。系统测试过程的要求应该像系统集成测试过程ENG.9的要求一样,在系统需求分析期间就已考虑,以便对验证标准进行适当的解释。在这里,测试策略也作为测试计划的一部分记录下来——这里也建议采用涵盖所有测试的总体策略。

BP3:验证集成系统。根据系统测试的测试用例和系统测试策略验证集成系统。

注意:集成系统验证会产生测试日志。

注意:考虑到效率,测试应尽可能自动化。

执行测试并将其结果记录在测试日志中。关于在测试日志中记录测试结果,另请参阅我们在 ENG.7 BP5/BP6 中提供的审议,以及 ENG.6 中的附录“测试文档”。

BP4:记录系统测试结果。记录系统测试结果并传达给所有相关方。

注:测试事件报告和测试总结报告基于测试日志。

与 ENG.7 BP6 类似,测试日志构成了创建集成系统测试事件报告和测试总结报告的基础。根据测试总结报告,特别是交付和客户验收测试的结果,可以决定系统质量是否足以交付给客户。

评估员须知

应客户要求,例如,在紧急需要纠正早期和中间样品版本的缺陷的情况下,可以部分或全部省略系统测试。这一点以及伴随的风险必须在样品交付的文件中明确说明。最低测试方案可以采用回归测试策略作为指导方针。

如果由于缺陷而需要,则必须将规范修订到系统级别,类似于 ENG.8 BP4。

BP5:确保系统需求与系统测试规范的一致性和双向可追溯性。确保系统需求与系统测试规范(包括测试用例)的一致性。通过在系统需求和系统测试规范(包括测试用例)之间建立和维护双向可追溯性来支持一致性。

注意:一致性可以通过审查记录来证明。

此基本实践类似于 ENG.8 BP5,即系统需求与系统测试规范之间的一致性由系统需求与系统测试规范之间的“水平”可追溯性(另见第 2.24 节)保证。这意味着对于每个系统需求,必须定义将覆盖它的系统测试。另一方面,系统测试也必须定义要测试哪些需求。实际测试覆盖率可以通过审查和相应的审查记录来验证。在这里,也必须在项目的整个生命周期内保持可追溯性——尤其是在变更之后。

BP6:制定系统回归测试策略并进行测试。制定在系统元素发生变化时重新测试集成系统的策略。如果对系统元素进行了更改,则按照系统回归测试策略中的定义进行回归测试,并记录结果。

此实践要求对整个系统进行回归测试(关于回归测试,请参阅 ENG.7 BP8)。

2.12.4 指定工作产品

08-50 测试规范

参见 ENG.8

08-52 测试计划

参见 ENG.8

13-50 测试结果

参见 ENG.8

2.12.5  2 级特性

参见 ENG.8 中的类似审议。

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
### 回答1: ASPICE是指汽车供应链产品开发基础设施的改进方法,实现了产品组件的重用、可靠性设计和自动化测试。在ASPICE的指导下,汽车制造商和供应商可以更快地将高质量的产品带到市场上,同时还可以降低开发和生产成本。ASPICE使用一系列的过程和模板,来指导汽车供应链中的开发团队。这些模板和过程包括需求分析、系统设计、软件开发、测试等不同阶段,使得开发团队能够掌握和发展最佳实践。ASPICE主要分为3个级别,即基本水平、中间水平和高级水平。每个级别都有不同的指标和标准,开发团队需要按照这些标准进行评估和改进,从而不断提升产品质量和开发效率。ASPICE还提供了评估和认证机制,对汽车供应链中的开发团队进行评估和认证,确保他们符合汽车制造商的要求和标准。ASPICE是汽车供应链的重要工具,已经得到了全球范围内的广泛应用。 ### 回答2: ASPICE是一种软件过程评估标准,它的全称为Automotive SPICE(汽车软件过程改进与能力评估),是汽车行业的一种通用标准。ASPICE被设计用来提升汽车软件开发的质量和效率,涉及到软件开发的不同阶段,从需求定义到开发、测试和集成,甚至到配置管理和项目管理等。它将软件过程分成了六个级别,不同的级别评估软件开发流程的成熟度,其中最高的是LEVEL 5。ASPICE也提供了详细的流程指南、工具和模板,支持开发团队的自我评估和检查。 SWE.3是ASPICE中的一个级别,也称为软件产品的设计和实现。在这个级别中,开发团队需要对软件的需求进行分析和概念设计,并在此基础上完成详细的设计和编码。这个过程需要保证软件质量,并且需要符合特定的标准和规范。在这个阶段,开发团队还需要进行代码静态分析、单元测试和集成测试,并在这个过程中迭代改进软件的设计和编码,确保软件的质量和符合需求。此外,这个阶段的评估还要看开发团队能否满足特定的要求,如安全性、可靠性、可维护性和性能等。这意味着开发团队需要对软件开发的整个过程进行细致的管理和控制,确保软件产品的质量和符合ASPICE标准的要求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

Judith Chai

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

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

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

打赏作者

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

抵扣说明:

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

余额充值