- | F6.1–6.2 | 技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。 | 项目Hub ↔ 测试 | 测试输入:嵌入式应用层固件包、硬件实现资料、已集成的 嵌入式底层实现资料、版本矩阵、测试计划。 测试提交的成果草案:功能测试报告、专项测试报告、提测佐证、缺陷分析报告。 提测佐证内容:平台要求的视频、截图、log材料。 选填成果:可靠性测试报告。 | 测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件;缺陷必须关联可复现环境和版本。 | 启动测试并更新测试状态。 |
- | F6.3 | 测试发现缺陷或测试异常并形成可追踪记录。 | 测试 → 项目Hub → 建议责任角色 / 技术负责人 / 产品 | 正式成果更新:测试主责的《缺陷分析报告》缺陷条目。 提交与分发内容:缺陷编号、现象、版本矩阵、环境、用例、复现、期望/实际、证据、影响程度、风险、优先级、建议责任边界、受影响成果、回归要求和响应时限。 | 项目Hub只做结构、证据和路由检查;责任明确时按测试建议路由,跨层或根因不清时交技术负责人,需求含义不清时交产品。 | 建立定向返工或裁决任务。 |
- | F6.4–6.5 | 责任角色或裁决角色收到缺陷任务。 | 责任角色 / 技术负责人 / 产品 → 项目Hub → 测试 | 过程记录:原因分析、修复计划或技术/产品决定,包含原因或裁决、影响、修复方案、风险、修复成果计划、期限、需重测范围和证据。 测试动作:引用带来源的原因、修复或裁决输入,更新《缺陷分析报告》状态和回归要求。 | 实现角色不直接替换或关闭测试主责的《缺陷分析报告》;“无法复现”“符合设计”或“不修复”必须带理由与证据。 | 阻断缺陷使阶段阻塞;等待修复成果和目标版本复验。 |
- | F6.6–6.8 | 应用修复、嵌入式底层修复或硬件 ECO 已提交。 | 责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试 | 实现角色修订成果:嵌入式应用层固件包、嵌入式底层实现资料或硬件实现资料。 提交给测试的缺陷输入:原因分析、修复计划、修复成果与版本、实现角色自测、变更记录、证据、影响范围、版本链和建议回归范围;测试引用后更新《缺陷分析报告》。 硬件 ECO 额外内容:新旧板卡/PCB/BOM/ECO 差异、受影响批次、返工/回退方式、板级验证证据、底层驱动/HAL 兼容评估、应用固件有效性确认和新版本矩阵。 | 实现角色无权直接替换或关闭《缺陷分析报告》。嵌入式底层修复不得直接交给测试;必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估;即使不修改固件,也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵,测试在目标组合上复验并独立给出“已验证”或“已关闭”结论。 | 形成唯一可回归的固件与硬件版本矩阵,并由测试复验。 |
- | F6.9 | 统一回归固件和硬件版本矩阵通过项目Hub校验,必要时由技术负责人确认。 | 项目Hub → 测试 | 回归输入:更新后的 嵌入式应用层固件包、相关 嵌入式底层实现资料/硬件实现资料、缺陷分析报告、版本矩阵。 过程记录:回归任务,包含修复范围、受影响用例和时限。 | 旧版本不得覆盖;测试不得接收嵌入式底层单独提交的固件。 | 执行定向回归。 |
- | F6.10 | 阻断缺陷清零且证据齐全。 | 测试 → 项目Hub | 最终确认成果:功能测试报告、专项测试报告、提测佐证、缺陷分析报告,以及已提供的可靠性测试报告的负责人确认版本。 附带内容:质量结论、覆盖率、未关闭缺陷、剩余风险和接受方。 | 测试内部确认状态必须记录;剩余风险必须有接受方。 | 门禁通过并留档后开启验收。 |
+ | F6.1–6.2 | 技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。 | 项目Hub ↔ 测试 | 测试输入:嵌入式应用层固件包、硬件实现资料、已集成的 嵌入式底层实现资料、版本矩阵、测试计划。 必需成果草案:功能测试报告、缺陷清单。 选填成果:可靠性测试报告、专项测试报告、提测佐证。 提测佐证内容(选填):平台要求的视频、截图、log材料。 | 测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件;缺陷必须关联可复现环境和版本。 | 启动测试并更新测试状态。 |
+ | F6.3 | 测试发现缺陷或测试异常并形成可追踪记录。 | 测试 → 项目Hub → 实际相关角色 | 提交与更新成果:测试主责的《缺陷清单》。 分发内容:缺陷编号、现象、状态、模块、版本、环境、用例、复现、证据、影响、风险、优先级和回归要求。 商议结果:缺陷责任人、主责角色、协作角色及处理时限。 | 测试与实际相关角色的负责人共同商议解决缺陷的责任人,每项缺陷明确一名责任人和一个主责角色。项目Hub只登记已确认的分工并路由,不自行指定责任人;跨层技术问题由技术负责人提供判断依据,需求含义由产品澄清。分歧未收敛时按 E.1–E.4 协调。 | 确认缺陷责任分工后,建立定向修复或专业澄清任务。 |
+ | F6.4–6.5 | 相关负责人已共同确认缺陷责任人,责任角色收到缺陷任务。 | 责任角色 / 技术负责人 / 产品 → 项目Hub → 测试 | 过程记录:确认的责任人、主责与协作角色、原因分析、修复计划或技术/产品决定,包含影响、修复方案、风险、修复成果计划、期限、需重测范围和证据。 测试动作:引用已确认的责任分工与修复输入,更新《缺陷清单》的责任人、状态和回归要求。 | 实现角色不直接替换或关闭测试主责的《缺陷清单》;“无法复现”“符合设计”或“不修复”必须带理由与证据;责任人调整仍需相关负责人共同确认。 | 阻断缺陷使阶段阻塞;等待修复成果和目标版本复验。 |
+ | F6.6–6.8 | 应用修复、嵌入式底层修复或硬件 ECO 已提交。 | 责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试 | 实现角色修订成果:嵌入式应用层固件包、嵌入式底层实现资料或硬件实现资料。 提交给测试的缺陷输入:原因分析、修复计划、修复成果与版本、实现角色自测、变更记录、证据、影响范围、版本链和建议回归范围;测试引用后更新《缺陷清单》。 硬件 ECO 额外内容:新旧板卡/PCB/BOM/ECO 差异、受影响批次、返工/回退方式、板级验证证据、底层驱动/HAL 兼容评估、应用固件有效性确认和新版本矩阵。 | 实现角色无权直接替换或关闭《缺陷清单》。嵌入式底层修复不得直接交给测试;必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估;即使不修改固件,也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵,测试在目标组合上复验并独立给出“已验证”或“已关闭”结论。 | 形成唯一可回归的固件与硬件版本矩阵,并由测试复验。 |
+ | F6.9 | 统一回归固件和硬件版本矩阵通过项目Hub校验,必要时由技术负责人确认。 | 项目Hub → 测试 | 回归输入:更新后的 嵌入式应用层固件包、相关 嵌入式底层实现资料/硬件实现资料、缺陷清单、版本矩阵。 过程记录:回归任务,包含修复范围、受影响用例和时限。 | 旧版本不得覆盖;测试不得接收嵌入式底层单独提交的固件。 | 执行定向回归。 |
+ | F6.10 | 阻断缺陷清零且必需成果及其测试依据齐全。 | 测试 → 项目Hub | 最终确认成果:功能测试报告、缺陷清单的负责人确认版本。 已提供时一并确认:可靠性测试报告、专项测试报告、提测佐证。 附带内容:质量结论、覆盖率、未关闭缺陷、剩余风险和接受方。 | 测试内部确认状态必须记录;剩余风险必须有接受方;选填成果未提供不作为门禁阻塞项。 | 门禁通过并留档后开启验收。 |