项目工作范围与服务声明（SOW）
1. 服务范围概述
1.1 服务内容
1.1.1 工作包1：测试用例设计与分析
- 系统规范和描述的提供，包括功能架构、信号矩阵、法规标准范围等。
- 基于通用汽车（GM）提供的输入，设计可执行的HIL测试用例，并进行详细的分步操作。
- 定义测试用例的初始和最终状态，以及具体的测试场景、前提条件、动作和预期结果。
- 将测试用例及其场景映射到通用汽车的需求管理系统JAMA。
- 根据项目或需求可能的变化，调整技术解决方案和工作计划。
1.1.2 工作包2：测试场景构建
- 根据GM的测试用例描述，生成测试场景，包括道路网络、静态道路元素、车辆动作等。
- 在GM的测试台和工具链上测试和调试测试用例和场景。
- 生成场景管理工具，支持场景的添加、删除、修改和查询。
- 开发场景生成管道，能够将车辆测试算法输出的对象列表和车道信息转换为OpenX格式。
1.1.3 工作包3：测试自动化
- 设计测试自动化框架，包括所有相关工具链和数据流。
- 开发配置文件、参数文件、测试库，以及自动化测试用例。
- 实现自动化测试结果分析、评估和报告生成。
- 实现远程测试的扩展功能。
1.1.4 工作包4：测试执行
- 在GM的HIL测试台上执行功能测试，包括烟雾测试、功能发布测试等。
- 根据自动化水平手动或自动执行测试用例。
- 分析测试结果，生成测试报告。
- 维护测试台。
1.2 交付物与验收标准
1.2.1 工作包1交付物
- 涵盖所有GM ADAS/AD/停车功能（如AEB、RVB、LSS等）的指定测试用例。
- 包含至少800个每个功能的测试用例，并根据GM的需求和需求进行扩展。
- 覆盖测试范围，包括烟雾测试、集成测试、ODD测试等，并根据GM的需求和需求进行扩展。
1.2.2 工作包2交付物
- 包含基于GM L2/L2++测试用例生成的场景。
- 包含至少100个每个功能的测试场景，并根据GM的需求和需求进行扩展。
- 包含典型的交通事故场景数据库，并与测试用例清晰映射。
1.2.3 工作包3交付物
- 基于GM测试用例、测试台工具链和自动化工具ecu.test的自动化测试框架。
- 能够应用于所有GM L2/L2++测试用例。
- 包含测试用例转换脚本，能够将GM测试用例转换为自动化工具ecu.test中的测试序列。
1.2.4 工作包4交付物
- 手动和自动执行测试用例，并根据GM的测试计划进行。
- 执行回归测试。
- 生成测试结果分析、评估和报告。
1.3 时间框架
1.3.1 工作包1时间框架
- 2024年12月底前，完成90%的能力建设。
- 2025年2月底前，完成100%的能力建设。
1.3.2 工作包2时间框架
- 2024年12月底前，完成90%的能力建设。
- 2025年2月底前，完成100%的能力建设。
1.3.3 工作包3时间框架
- 2024年12月底前，完成90%的能力建设。
- 2025年2月底前，完成100%的能力建设。
1.3.4 工作包4时间框架
- 测试执行开始时间取决于GM的测试计划和测试范围。
- 供应商的测试执行将持续到2025年6月。
工作包1：测试用例设计与分析
1.1 测试用例设计
1.1 测试用例设计
####1.1.1 测试用例的定义
- 测试用例是用于验证软件功能的一系列输入、操作步骤和预期结果。
- 测试用例的设计需要基于系统规范和功能描述，以确保覆盖所有预期的功能和场景。
1.1.2 测试用例的分类
- 功能测试用例：验证软件的功能是否符合预期。
- 性能测试用例：验证软件在预期的工作环境下是否能达到性能指标。
- 安全性测试用例：验证软件在异常情况下是否能保证数据和系统的安全。
1.1.3 测试用例的设计流程
- 确定测试目标：明确要测试的功能和性能指标。
- 分析需求文档：了解软件的功能和业务逻辑。
- 设计测试步骤：根据需求文档设计输入和操作步骤。
- 编写预期结果：根据需求文档编写预期的输出和状态。
- 设计测试数据：设计用于测试的数据和场景。
- 评审和修改：对测试用例进行评审和修改，确保其完整性和可执行性。
1.2 测试用例分析
1.2.1 测试用例分析的目的
- 确保测试用例的完整性和覆盖率。
- 识别潜在的风险和问题，并提前解决。
- 优化测试用例，提高测试效率和质量。
1.2.2 测试用例分析的方法
- 静态分析：通过阅读测试用例文档，检查测试用例的设计是否合理。
- 动态分析：通过实际执行测试用例，验证测试用例的正确性和有效性。
- 覆盖率分析：通过分析测试用例的执行结果，评估测试用例的覆盖率。
工作包2：测试场景构建
2.1 测试场景的定义
- 测试场景是一系列测试用例的组合，用于验证软件在特定环境下的功能和性能。
- 测试场景的设计需要基于实际使用场景和潜在的风险，以确保覆盖所有可能的测试场景。
2.2 测试场景的构建
2.2.1 测试场景的分类
- 功能测试场景：验证软件的功能是否符合预期。
- 性能测试场景：验证软件在预期的工作环境下是否能达到性能指标。
- 安全性测试场景：验证软件在异常情况下是否能保证数据和系统的安全。
2.2.2 测试场景的构建流程
- 确定测试目标：明确要测试的功能和性能指标。
- 分析需求文档：了解软件的功能和业务逻辑。
- 设计测试场景：根据需求文档设计输入和操作步骤。
- 编写预期结果：根据需求文档编写预期的输出和状态。
- 设计测试数据：设计用于测试的数据和场景。
- 评审和修改：对测试场景进行评审和修改，确保其完整性和可执行性。
2.3 测试场景的管理
2.3.1 测试场景管理的目的
- 确保测试场景的完整性和覆盖率。
- 方便测试场景的维护和更新。
- 提高测试效率和质量。
2.3.2 测试场景管理的方法
- 建立测试场景库：将所有测试场景存储在数据库中，方便查询和管理。
- 提供场景管理工具：支持场景的添加、删除、修改和查询。
- 定期评审和更新：定期对测试场景进行评审和更新，确保其与实际需求和风险保持一致。
工作包3：测试自动化
3.1 测试自动化的定义
- 测试自动化是通过编写脚本或使用工具来自动执行测试用例的过程。
- 测试自动化可以提高测试效率，减少人工干预，提高测试覆盖率和质量。
3.2 测试自动化的优势
3.2 测试自动化的优势
- 提高测试效率：自动执行测试用例，减少人工操作的时间和错误。
- 提高测试覆盖率：自动执行更多的测试用例，覆盖更多的测试场景。
- 提高测试质量：自动执行一致和可靠的测试用例，减少人为因素的影响。
- 提高测试的可重复性：自动执行测试用例，确保每次测试结果的一致性。
3.3 测试自动化的实现
3.3.1 测试自动化的实现流程
- 确定测试目标：明确要测试的功能和性能指标。
- 设计测试用例：根据需求文档设计输入和操作步骤。
- 编写自动化脚本：根据测试用例编写自动化脚本或使用自动化工具。
- 测试脚本：执行自动化脚本，验证测试用例的正确性和有效性。
- 优化和维护：根据测试结果优化和维护自动化脚本，确保其高效和稳定。
3.4 测试自动化的挑战
3.4 测试自动化的挑战
- 测试脚本的编写和维护需要一定的技术能力。
- 测试自动化可能无法完全覆盖所有测试场景和风险。
- 测试自动化需要定期更新和维护，以适应软件的变更和升级。
工作包4：测试执行
4.1 测试执行的定义
- 测试执行是通过手动或自动的方式执行测试用例的过程。
- 测试执行的目的是验证软件的功能和性能是否符合预期，并及时发现和解决缺陷。
4.2 测试执行的方法
4.2 测试执行的方法
- 手动测试执行：通过人工操作软件，按照测试用例的步骤执行测试。
- 自动测试执行：通过自动化工具或脚本自动执行测试用例。
- 混合测试执行：结合手动和自动测试执行，以提高测试效率和覆盖率。
4.3 测试执行的挑战
4.3 测试执行的挑战
- 测试用例的执行需要大量的时间和资源。
- 测试结果的分析和评估需要专业知识和经验。
- 测试执行需要与软件开发和需求变更保持同步。
4.4 测试执行的改进
4.4 测试执行的改进
- 优化测试用例的设计和维护，提高测试覆盖率和效率。
- 引入自动化测试工具和脚本，减少人工操作的时间和错误。
- 加强测试结果的分析和评估，及时发现和解决缺陷。
- 与软件开发和需求变更保持紧密合作，确保测试执行的有效性和及时性。
