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 中的类似审议。