EP-Hub-Skill/etunel-role-collaboration/references/testing/execution-and-gates.md

测试执行与质量门禁

测试角色形成《测试计划》、检查提测准入、执行版本测试、管理缺陷或给出质量结论时读取。本文件规定稳定的执行规则；项目具体阈值、样本、周期、资源和响应时限依据当前已批准《测试计划》及上游标准，在每次执行前发布的测试策略中落实，不从历史模板直接继承。

三层测试契约

1. 角色契约：规定测试的长期使命、决定权、边界、必要输入和强制质量原则。
2. 通用执行规则：本文件规定适用性、准入、状态、统计、缺陷、证据和门禁。
3. 项目测试计划：按具体产品、硬件、客户、平台和阶段确定范围、阈值、样本、时长、环境、资源、版本策略和输出节点。

测试可以提出专业阈值建议，但不得自行创造产品要求、客户承诺或验收标准。

前期成果与测试计划

项目前期按适用性形成：

• 测试计划、测试范围、测试用例集；
• 验收标准清单、测试适用性清单；
• 需求—验收标准—用例追踪关系；
• 环境、设备、工具、样机、账号和数据要求；
• 专项清单、样本、周期和外部依赖；
• 测试风险、资源缺口、未决问题和输出节点。

《测试计划》的基本内容是测试标准、测试用例范围和测试项。执行需要的版本、环境、工具、样机、步骤、阈值、风险及输出节点按实际项目补充，不把所有细项变成无条件必填的阶段 3 成果。

测试编制和维护计划，先取得测试负责人确认后提交 Hub。无问题时由 Hub 汇总给技术负责人确认；存在不可测试项或环境、治具缺口时，先由 Hub 转相关角色确认，测试修订计划，再由技术负责人确认其与整体方案、接口和实施依赖一致。技术确认不替代测试的专业决定。

关键覆盖变化、范围缩减及严重缺陷处置需要测试负责人确认；涉及产品验收边界交产品确认，涉及预算、采购、客户承诺或业务风险再由业务批准。

每次测试执行前发布策略

每次测试实际执行前，由测试发布一次本次测试策略；普通测试、迭代测试、缺陷复测及回归均适用，不只在首版或立项时发布。策略围绕本次目标版本、范围、重点、适用用例及必要环境安排说明如何执行，沿用有效测试计划和上游标准；变更范围或验收要求仍走既有权限与确认流程，不能用策略替代批准。

策略可放在现有测试任务或过程沟通中；需要跨角色同步时交 Hub 定向中继，不开放成员 Agent 直连，不默认广播或另设通知渠道。保留实际发布内容与版本的必要过程记录，不新增独立正式成果、固定模板或每轮技术负责人审批。只编写草稿或阅读模板，不算已经发布。

参考测试计划表仅供选项和标准组织参考，不要求补充用例引用，也不因缺少引用栏或独立用例范围栏新增补交要求。阶段 3 正式《测试计划》的测试标准、测试用例范围、测试项及既有确认链继续有效；执行所需覆盖和依据可保留在现有计划、策略、用例及报告中，不强制另建引用清单。

适用性

《功能测试报告》《缺陷清单》必需；《可靠性测试报告》《专项测试报告》《提测佐证》保持选填，由项目Hub对应真人负责人确认是否提交，Hub 登记并同步；决定不提交不阻塞推进，无需豁免，已提交时完成版本登记和负责人确认。平台模板不自动增加内部提交门禁，真人决定也不等于外部平台已接受，见 选填提交规则。选填文件与已批准测试范围是两回事；测试依据可保留在实际报告及支持记录中，不要求另建通用证据包。

测试专项、模块和用例的计划适用性只使用：

• 必测：当前产品、配置、客户、平台或阶段适用，必须执行；
• 不适用：经评估确认不适用，必须记录原因、依据和引用基线；
• 延期：本应执行但获正式延期，必须记录影响、风险、责任、完成节点、关闭条件和批准。

“不适用”不得表示时间／人员不足、环境／样机／账号缺失、版本阻塞、数据缺失、外部依赖未满足、不通过或尚未执行。适用但无法完成的项目是“阻塞”，不是“不适用”。

任何产品需求、验收标准、硬件、PCB、BOM、固件、软件、配置、接口、平台标准、客户范围、试产批次或交付版本变化都触发测试影响评估。是否完整重测由影响分析决定，不能无评估沿用旧结论。

正式提测准入

常规输入为应用层统一固件、版本矩阵及测试计划，不要求另附底层实现资料或硬件设计包；不能以缺少这两个包拒绝提测。具体执行所需事实按下列要求核对，确需补充信息时经 Hub 定向查询，不把查询变成整包提交要求。

每个正式提测版本应提供：

• 应用层输出的唯一统一固件及匹配版本矩阵（底层、硬件、BOM、配置、样机和批次）；初始提测须技术负责人确认，回归按下述规则校验；
• 可重复取得的安装包、固件、样机或构建物；
• 变更清单、影响范围、研发自测、已知问题和风险；
• 安装、升级、降级和恢复方式；
• 环境、网络、外设、账号和安全引用；
• 提测目标、建议重点、上一版本关系和计划节点。

输入不满足时，测试可判定提测拒绝或阻塞。探索性检查必须与正式测试结果分开。

回归任务（F6.9）使用统一固件、版本矩阵、缺陷清单及必要变更说明；通过 Hub 校验，必要时再由技术负责人确认版本矩阵，不把此确认扩大为每轮必审，也不替代测试准入检查。具体定位资料按问题提供，不默认要求整包。准入事实可复用已有有效记录，不要求每轮重复上传；阶段 5 最终提测及阶段 6 初始准入的技术负责人确认保持必需。

每版测试闭环

每版按以下顺序在测试角色内部执行：

提测准入检查 → 变更影响评估 → 发布本次测试策略 → 内部任务安排 → 环境确认 → 用例执行 → 证据归档 → 缺陷反馈 → 修复复测与回归 → 质量汇总

按版本风险选择策略：

• 普通测试版：基础冒烟、变更点验证、受影响回归；
• 缺陷修复版：原缺陷复测、关联回归、基础冒烟、副作用检查；
• 大版本或跨模块变更：完整功能回归、接口集成、受影响专项和关键稳定性；
• 候选发布版（RC）：完整回归、全部适用专项、遗留缺陷和版本／证据完整性；
• 试产定版：候选基线一致性、抽样验证、最终门禁和已执行测试的交付证据。

实现角色提供变更和自测信息，但不能单方面缩减测试范围。

结果状态

版本整体质量结论只使用通过、不通过、阻塞：

• 通过：全部适用门禁满足；
• 不通过：已执行并确认不满足要求，或存在高风险质量不通过；
• 阻塞：无法完成必测范围或形成有效结论。

专项、模块和正式用例结果只使用通过、不通过、阻塞、不适用。待执行和执行中是进度，不是正式结果。到正式汇总或报告节点，所有计划用例都必须有结果；适用但未完成的用例填“阻塞”，不能留空或改成“不适用”。

阻塞必须说明原因、受影响范围、证据、责任或协调角色、解除条件和补测要求。必测范围中存在阻塞时，版本不能判定通过。只有工具字段明确要求时才使用机器枚举，对负责人和钉钉始终写中文。

统计

年度、月版本缺陷分析模板只作参考，不要求提交独立缺陷分析报告或 bug 数量、回头率、冒头率统计。下列用例执行统计用于解释实际覆盖，与已取消的缺陷汇总统计不是同一要求。

正式报告至少统计计划、通过、不通过、阻塞、不适用、适用和实际执行数量：

• 计划用例数 = 通过 + 不通过 + 阻塞 + 不适用；
• 适用用例数 = 计划用例数 - 不适用；
• 实际执行用例数 = 通过 + 不通过；
• 执行完成率 = 实际执行用例数 ÷ 适用用例数；
• 执行通过率 = 通过 ÷ 实际执行用例数；
• 阻塞率 = 阻塞 ÷ 适用用例数。

实际执行数为 0 时，通过率是“不可计算”，不是 100%。阻塞项保留在适用分母中；不得把阻塞改成不适用，也不得用总体通过率掩盖关键不通过。

缺陷与关闭

测试与实际相关角色负责人共同商议缺陷解决责任人，每项明确一名责任人、一个主责角色、协作及期限。技术负责人提供跨层判断依据；Hub 登记已确认分工，不自行指定责任人。争议经既有异常流程协调。

测试创建、持续维护《缺陷清单》，并对其中缺陷独立复验与关闭。每个缺陷至少记录：

• 缺陷编号和关联测试项；
• 被测统一固件及其匹配的底层、硬件、BOM、配置、样机和批次；
• 环境、前置条件、复现步骤、期望／实际结果和频率；
• 影响程度、暴露概率／范围、风险等级和处理优先级；
• 影响、原始证据、初步责任边界、回归要求和状态。

影响程度、发生概率、风险等级和处理优先级必须分开。不得通过临时降级绕过门禁。

推荐生命周期：

新建 → 已确认 → 已安排修复 → 已修复／待复验 → 已验证 → 已关闭

• 测试负责复现、观察证据、影响、回归要求、复验和测试关闭；
• 实现角色负责根因、修复、变更说明和研发自测；
• 产品负责需求含义和预期行为；
• 技术负责人负责跨层归类和架构接口裁决；
• 业务负责客户范围、交付边界和业务风险接受；
• 责任角色向 Hub 返回原因与计划；Hub 按共同确认分工派发修复任务，并把确认结果同步测试维护缺陷清单；彼此独立且依赖就绪的修复可形成任务波次。

实现角色只提交原因分析、修复计划、修复成果、版本和自测，不能替换或关闭《缺陷清单》。研发声明修复不能直接关闭缺陷；只有测试在目标版本组合独立复验通过后才能标记为“已验证”或“已关闭”。重复、符合设计、无法复现、不修复和延期等处置都要保留理由与证据；未关闭项进入遗留缺陷和剩余风险。

责任路由起点：

• 需求、产品行为、验收标准或详细客户输入：产品；
• 合同、业务范围、对外承诺或业务风险：业务；
• 总体架构、跨层接口或责任不清：技术负责人；
• 应用逻辑、状态机、配置、界面或应用协议：嵌入式应用层；
• BSP、Bootloader、RTOS、HAL、驱动、总线或底层实时行为：嵌入式底层；
• 电路、器件、GPIO、电平、PCB、BOM 或硬件时序：硬件；
• 测试环境、工具、数据或用例：测试。

这只是供相关负责人商议的证据化建议，不是自动定责表；正式修复任务由 Hub 按共同确认的责任分工和依赖创建。

证据、版本与追踪

证据应能回答：

• 实际被测版本、样机、批次、配置、环境和外设；
• 使用的方法、步骤和工具；
• 原始观察和数据；
• 如何对应验收标准；
• 阻塞原因和不适用依据；
• 缺陷修复版本与独立回归；
• 测试限制、确认和剩余风险。

追踪链：

需求／客户标准 → 验收标准 → 测试用例 → 执行结果 → 原始测试证据 → 缺陷清单 → 修复版本 → 回归结果 → 适用测试报告 → 交付版本

测试结论只对实际被测版本、样机、配置和环境有效。无法证明平台、试产和交付版本一致时，最终结论为阻塞。

普通测试成果不得保存密码、访问令牌、私钥、证书密钥或其他敏感值；只记录提供状态、适用环境、责任和安全引用。

最终测试定版门禁

只有全部适用条件满足才可给出最终通过：

1. 必测范围执行完成率 100%，没有阻塞；
2. 关键门禁用例全部通过；
3. 所有适用验收标准满足；
4. 所有适用专项有明确结论；
5. 没有未关闭的高风险缺陷；
6. 中低风险遗留已评估、披露并取得必要确认；
7. 修复已在目标版本独立回归；
8. 被测版本与平台、试产和交付候选版本一致；
9. 测试计划、用例执行、缺陷清单、回归及必需测试报告和依据完整；选填报告、提测佐证仅在已提供时检查其版本和确认，不因未提供而阻塞；
10. 限制、依赖和剩余风险明确，测试有权人员确认最终结论。

未关闭的高风险缺陷、关键用例不通过、验收标准不满足或严重回归必须判定不通过。关键必测用例阻塞、执行不足、环境／依赖不可用、版本不一致或证据不足必须判定阻塞。

最终测试通过不等于业务验收、客户风险接受、发布批准或制造良率批准。

测试结果提交门禁

上述通过/不通过是测试专业结论，不等于正式提交完成。测试自审及测试负责人确认后执行 F6.10–F6.12，由 Hub 请求项目负责人（Hub 对应真人负责人）明确确认并登记；未确认或退回不得宣布最终提交完成、不得正式进入平台/客户验收。细则及版本重确认规则见 成果与完成判定。

测试已完成且无缺陷时，从 F6.2 直接到 F6.10，仍交功能测试报告和零缺陷清单，继续人工确认，不安排无必要的修复。若被退回，补充或按实际问题修复复验后重新确认；未完成必测项不能走“无缺陷即完成”的捷径。

正式输出深度

功能报告突出测试结论（通过/不通过）、用例执行结果及 bug log；缺陷清单记录 bug 条目、状态、模块、责任人及必要证据，不附加缺陷汇总统计要求。可靠性报告列高低温测试，跌落、防水测试选填。专项报告列适用专项，不另要求专项矩阵。提测佐证为平台要求的视频、截图、log 材料，选填且由测试负责人直接交产品负责人，Hub 只登记索引与接收确认。

本文件的测试执行与候选版本验证发生在相应测试任务中，不得据此在阶段 8 增加冒烟、发布验证或其他测试；阶段 8 只归档已有资料并复盘。

• 普通测试版：策略、版本、范围、状态统计、结果摘要、缺陷增量、阻塞和限制；
• 缺陷修复版：原缺陷复测、关联回归、新问题和剩余风险；
• 大版本／候选发布版：在功能测试报告、《缺陷清单》及已提供的选填报告中记录实际覆盖、统计、缺陷、回归与质量结论；
• 平台提测版：要求映射、预检、提交版本、平台反馈、整改和重提记录；
• 试产定版：最终计划、用例、执行、兼容矩阵、缺陷、回归、证据、遗留风险和质量报告。

角色契约不固定统一小时级响应时限；响应、测试、回归和报告时限由项目计划或《测试计划》定义。