feat: 按 V0.16 统一角色协作 Skill 与 Hook 提醒
This commit is contained in:
1 parent
08793151e1
commit
163f655cd0
28 files changed
+673
-456
No files matched your search
@@ -21,35 +21,30 @@
|
||||
- 专项清单、样本、周期和外部依赖;
|
||||
- 测试风险、资源缺口、未决问题和输出节点。
|
||||
|
||||
《测试计划》至少说明:
|
||||
《测试计划》的基本内容是测试标准、测试用例范围和测试项。执行需要的版本、环境、工具、样机、步骤、阈值、风险及输出节点按实际项目补充,不把所有细项变成无条件必填的阶段 3 成果。
|
||||
|
||||
- 目标、范围内事项、范围外事项;
|
||||
- 输入基线和适用版本;
|
||||
- 测试类型、专项和版本分级策略;
|
||||
- 环境、工具、设备、样机和数据;
|
||||
- 测试角色内部安排;
|
||||
- 提测准入、进入和退出条件;
|
||||
- 验收标准及来源;
|
||||
- 适用性和裁剪原则;
|
||||
- 缺陷等级/风险矩阵引用;
|
||||
- 回归、证据、进度、依赖、风险和正式输出。
|
||||
测试编制和维护计划,先取得测试负责人确认后提交 Hub。无问题时由 Hub 汇总给技术负责人确认;存在不可测试项或环境、治具缺口时,先由 Hub 转相关角色确认,测试修订计划,再由技术负责人确认其与整体方案、接口和实施依赖一致。技术确认不替代测试的专业决定。
|
||||
|
||||
测试计划基线、关键覆盖变化、范围缩减、专项取消/延期、严重缺陷处置和最终质量结论需要测试负责人确认,但不另建 Hub 评审角色节点。涉及客户范围或业务风险时,再由 Hub 定向交业务决定。
|
||||
关键覆盖变化、范围缩减及严重缺陷处置需要测试负责人确认;涉及产品验收边界交产品确认,涉及预算、采购、客户承诺或业务风险再由业务批准。
|
||||
|
||||
## 适用性
|
||||
|
||||
《功能测试报告》《缺陷清单》必需;《可靠性测试报告》《专项测试报告》《提测佐证》选填,未提交不阻塞推进,无需豁免。已提交时完成版本登记和负责人确认。选填文件与已批准测试范围是两回事;测试依据可保留在实际报告及支持记录中,不要求另建通用证据包。
|
||||
|
||||
测试专项、模块和用例的计划适用性只使用:
|
||||
|
||||
- 必测:当前产品、配置、客户、平台或阶段适用,必须执行;
|
||||
- 不适用:经评估确认不适用,必须记录原因、依据和引用基线;
|
||||
- 延期:本应执行但获正式延期,必须记录影响、风险、责任、完成节点、关闭条件和批准。
|
||||
|
||||
“不适用”不得表示时间/人员不足、环境/样机/账号缺失、版本阻塞、数据缺失、外部依赖未满足、失败或尚未执行。适用但无法完成的项目是“阻塞”,不是“不适用”。
|
||||
“不适用”不得表示时间/人员不足、环境/样机/账号缺失、版本阻塞、数据缺失、外部依赖未满足、不通过或尚未执行。适用但无法完成的项目是“阻塞”,不是“不适用”。
|
||||
|
||||
任何产品需求、验收标准、硬件、PCB、BOM、固件、软件、配置、接口、平台标准、客户范围、试产批次或交付版本变化都触发测试影响评估。是否完整重测由影响分析决定,不能无评估沿用旧结论。
|
||||
|
||||
## 正式提测准入
|
||||
|
||||
常规输入为应用层统一固件、版本矩阵及测试计划,不要求另附底层实现资料或硬件设计包;不能以缺少这两个包拒绝提测。具体执行所需事实按下列要求核对,确需补充信息时经 Hub 定向查询,不把查询变成整包提交要求。
|
||||
|
||||
每个正式提测版本应提供:
|
||||
|
||||
- 应用层输出、技术负责人确认版本矩阵的唯一统一固件,以及匹配的底层、硬件、BOM、配置、样机和批次;
|
||||
@@ -61,6 +56,8 @@
|
||||
|
||||
输入不满足时,测试可判定提测拒绝或阻塞。探索性检查必须与正式测试结果分开。
|
||||
|
||||
回归任务(F6.9)使用统一固件、版本矩阵、缺陷清单及必要变更说明;具体定位资料按问题提供,不默认要求整包。准入事实可复用已有有效记录,不要求每轮重复上传。
|
||||
|
||||
## 每版测试闭环
|
||||
|
||||
每版按以下顺序在测试角色内部执行:
|
||||
@@ -73,38 +70,40 @@
|
||||
- 缺陷修复版:原缺陷复测、关联回归、基础冒烟、副作用检查;
|
||||
- 大版本或跨模块变更:完整功能回归、接口集成、受影响专项和关键稳定性;
|
||||
- 候选发布版(RC):完整回归、全部适用专项、遗留缺陷和版本/证据完整性;
|
||||
- 试产定版:候选基线一致性、抽样验证、最终门禁和《测试证据包》中的交付证据。
|
||||
- 试产定版:候选基线一致性、抽样验证、最终门禁和已执行测试的交付证据。
|
||||
|
||||
实现角色提供变更和自测信息,但不能单方面缩减测试范围。
|
||||
|
||||
## 结果状态
|
||||
|
||||
版本整体质量结论只使用通过、失败、阻塞:
|
||||
版本整体质量结论只使用通过、不通过、阻塞:
|
||||
|
||||
- 通过:全部适用门禁满足;
|
||||
- 失败:已执行并确认不满足要求,或存在高风险质量失败;
|
||||
- 不通过:已执行并确认不满足要求,或存在高风险质量不通过;
|
||||
- 阻塞:无法完成必测范围或形成有效结论。
|
||||
|
||||
专项、模块和正式用例结果只使用通过、失败、阻塞、不适用。待执行和执行中是进度,不是正式结果。到正式汇总或报告节点,所有计划用例都必须有结果;适用但未完成的用例填“阻塞”,不能留空或改成“不适用”。
|
||||
专项、模块和正式用例结果只使用通过、不通过、阻塞、不适用。待执行和执行中是进度,不是正式结果。到正式汇总或报告节点,所有计划用例都必须有结果;适用但未完成的用例填“阻塞”,不能留空或改成“不适用”。
|
||||
|
||||
阻塞必须说明原因、受影响范围、证据、责任或协调角色、解除条件和补测要求。必测范围中存在阻塞时,版本不能判定通过。只有工具字段明确要求时才使用机器枚举,对负责人和钉钉始终写中文。
|
||||
|
||||
## 统计
|
||||
|
||||
正式报告至少统计计划、通过、失败、阻塞、不适用、适用和实际执行数量:
|
||||
正式报告至少统计计划、通过、不通过、阻塞、不适用、适用和实际执行数量:
|
||||
|
||||
- 计划用例数 = 通过 + 失败 + 阻塞 + 不适用;
|
||||
- 计划用例数 = 通过 + 不通过 + 阻塞 + 不适用;
|
||||
- 适用用例数 = 计划用例数 - 不适用;
|
||||
- 实际执行用例数 = 通过 + 失败;
|
||||
- 实际执行用例数 = 通过 + 不通过;
|
||||
- 执行完成率 = 实际执行用例数 ÷ 适用用例数;
|
||||
- 执行通过率 = 通过 ÷ 实际执行用例数;
|
||||
- 阻塞率 = 阻塞 ÷ 适用用例数。
|
||||
|
||||
实际执行数为 0 时,通过率是“不可计算”,不是 100%。阻塞项保留在适用分母中;不得把阻塞改成不适用,也不得用总体通过率掩盖关键失败。
|
||||
实际执行数为 0 时,通过率是“不可计算”,不是 100%。阻塞项保留在适用分母中;不得把阻塞改成不适用,也不得用总体通过率掩盖关键不通过。
|
||||
|
||||
## 缺陷与关闭
|
||||
|
||||
测试创建、持续维护并最终关闭《缺陷分析报告》。每个缺陷至少记录:
|
||||
测试与实际相关角色负责人共同商议缺陷解决责任人,每项明确一名责任人、一个主责角色、协作及期限。技术负责人提供跨层判断依据;Hub 登记已确认分工,不自行指定责任人。争议经既有异常流程协调。
|
||||
|
||||
测试创建、持续维护《缺陷清单》,并对其中缺陷独立复验与关闭。每个缺陷至少记录:
|
||||
|
||||
- 缺陷编号和关联测试项;
|
||||
- 被测统一固件及其匹配的底层、硬件、BOM、配置、样机和批次;
|
||||
@@ -123,9 +122,9 @@
|
||||
- 产品负责需求含义和预期行为;
|
||||
- 技术负责人负责跨层归类和架构接口裁决;
|
||||
- 业务负责客户范围、交付边界和业务风险接受;
|
||||
- Hub 负责向实际责任角色派发修复任务;彼此独立且依赖就绪的修复可形成任务波次。
|
||||
- 责任角色向 Hub 返回原因与计划;Hub 按共同确认分工派发修复任务,并把确认结果同步测试维护缺陷清单;彼此独立且依赖就绪的修复可形成任务波次。
|
||||
|
||||
实现角色只提交原因分析、修复计划、修复成果、版本和自测,不能替换或关闭《缺陷分析报告》。研发声明修复不能直接关闭缺陷;只有测试在目标版本组合独立复验通过后才能标记为“已验证”或“已关闭”。重复、符合设计、无法复现、不修复和延期等处置都要保留理由与证据;未关闭项进入遗留缺陷和剩余风险。
|
||||
实现角色只提交原因分析、修复计划、修复成果、版本和自测,不能替换或关闭《缺陷清单》。研发声明修复不能直接关闭缺陷;只有测试在目标版本组合独立复验通过后才能标记为“已验证”或“已关闭”。重复、符合设计、无法复现、不修复和延期等处置都要保留理由与证据;未关闭项进入遗留缺陷和剩余风险。
|
||||
|
||||
责任路由起点:
|
||||
|
||||
@@ -137,7 +136,7 @@
|
||||
- 电路、器件、GPIO、电平、PCB、BOM 或硬件时序:硬件;
|
||||
- 测试环境、工具、数据或用例:测试。
|
||||
|
||||
这只是证据化建议,正式修复任务始终由 Hub 按实际责任和依赖创建。
|
||||
这只是供相关负责人商议的证据化建议,不是自动定责表;正式修复任务由 Hub 按共同确认的责任分工和依赖创建。
|
||||
|
||||
## 证据、版本与追踪
|
||||
|
||||
@@ -153,7 +152,7 @@
|
||||
|
||||
追踪链:
|
||||
|
||||
需求/客户标准 → 验收标准 → 测试用例 → 执行结果 → 测试证据包 → 缺陷分析报告 → 修复版本 → 回归结果 → 适用测试报告 → 交付版本
|
||||
需求/客户标准 → 验收标准 → 测试用例 → 执行结果 → 原始测试证据 → 缺陷清单 → 修复版本 → 回归结果 → 适用测试报告 → 交付版本
|
||||
|
||||
测试结论只对实际被测版本、样机、配置和环境有效。无法证明平台、试产和交付版本一致时,最终结论为阻塞。
|
||||
|
||||
@@ -171,18 +170,28 @@
|
||||
6. 中低风险遗留已评估、披露并取得必要确认;
|
||||
7. 修复已在目标版本独立回归;
|
||||
8. 被测版本与平台、试产和交付候选版本一致;
|
||||
9. 测试计划、用例、执行、测试证据包、缺陷分析报告、回归和适用测试报告完整;
|
||||
9. 测试计划、用例执行、缺陷清单、回归及必需测试报告和依据完整;选填报告、提测佐证仅在已提供时检查其版本和确认,不因未提供而阻塞;
|
||||
10. 限制、依赖和剩余风险明确,测试有权人员确认最终结论。
|
||||
|
||||
未关闭的高风险缺陷、关键用例失败、验收标准不满足或严重回归必须判定失败。关键必测用例阻塞、执行不足、环境/依赖不可用、版本不一致或证据不足必须判定阻塞。
|
||||
未关闭的高风险缺陷、关键用例不通过、验收标准不满足或严重回归必须判定不通过。关键必测用例阻塞、执行不足、环境/依赖不可用、版本不一致或证据不足必须判定阻塞。
|
||||
|
||||
最终测试通过不等于业务验收、客户风险接受、发布批准或制造良率批准。
|
||||
|
||||
## 测试结果提交门禁
|
||||
|
||||
上述通过/不通过是测试专业结论,不等于正式提交完成。测试自审及测试负责人确认后执行 F6.10–F6.12,由 Hub 请求项目负责人(Hub 对应真人负责人)明确确认并登记;未确认或退回不得宣布最终提交完成、不得正式进入平台/客户验收。细则及版本重确认规则见 [成果与完成判定](../artifacts-and-evidence.md#测试结果的项目负责人确认)。
|
||||
|
||||
测试已完成且无缺陷时,从 F6.2 直接到 F6.10,仍交功能测试报告和零缺陷清单,继续人工确认,不安排无必要的修复。若被退回,补充或按实际问题修复复验后重新确认;未完成必测项不能走“无缺陷即完成”的捷径。
|
||||
|
||||
## 正式输出深度
|
||||
|
||||
功能报告突出测试结论(通过/不通过)、用例执行结果及 bug log;缺陷清单记录 bug 条目、状态、模块、责任人及必要证据,不附加缺陷汇总统计要求。可靠性报告列高低温测试,跌落、防水测试选填。专项报告列适用专项,不另要求专项矩阵。提测佐证为平台要求的视频、截图、log 材料,选填且由测试负责人直接交产品负责人,Hub 只登记索引与接收确认。
|
||||
|
||||
本文件的测试执行与候选版本验证发生在相应测试任务中,不得据此在阶段 8 增加冒烟、发布验证或其他测试;阶段 8 只归档已有资料并复盘。
|
||||
|
||||
- 普通测试版:策略、版本、范围、状态统计、结果摘要、缺陷增量、阻塞和限制;
|
||||
- 缺陷修复版:原缺陷复测、关联回归、新问题和剩余风险;
|
||||
- 大版本/候选发布版:在适用测试报告、《测试证据包》和《缺陷分析报告》中完整记录覆盖、统计、缺陷、回归与质量结论;
|
||||
- 大版本/候选发布版:在功能测试报告、《缺陷清单》及已提供的选填报告中记录实际覆盖、统计、缺陷、回归与质量结论;
|
||||
- 平台提测版:要求映射、预检、提交版本、平台反馈、整改和重提记录;
|
||||
- 试产定版:最终计划、用例、执行、兼容矩阵、缺陷、回归、证据、遗留风险和质量报告。
|
||||
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
|
||||
当前任务包含第三方/客户平台正式提测或试产候选定版时读取。
|
||||
|
||||
阶段 7 正式验收使用的测试结果须已满足阶段 6 质量门禁及 [项目负责人确认](../artifacts-and-evidence.md#测试结果的项目负责人确认)。内部预检和阶段性问题沟通不冒充正式验收。
|
||||
|
||||
## 平台提测
|
||||
|
||||
平台流程使用:
|
||||
@@ -13,14 +15,16 @@
|
||||
- 平台标准与测试项可追踪;
|
||||
- 内部预检版本、正式提交版本和证据版本一致;
|
||||
- 保存提交材料、版本、账号/环境安全引用、提交时间和平台正式结果;
|
||||
- 平台反馈转入缺陷闭环,修复后复测、回归并按需重提;
|
||||
- 平台反馈与客户问题记入同一份《遗留问题清单》并标明来源,经 Hub 转入缺陷闭环;修复后复测、回归,产生新测试结果须重新取得项目负责人确认后再正式重提;
|
||||
- 平台窗口、账号、客户或业务依赖通过 Hub 定向协调。
|
||||
|
||||
内部预检通过不等于平台通过。只有平台正式结果可以支持“平台通过”。
|
||||
|
||||
平台验收报告或结论由产品依据实际平台结果出具,无需业务批准;客户验收由业务确认。平台与客户验收各自输入就绪时可并行,总门禁必须两者均通过。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人,由产品向 Hub 确认接收,不要求大文件经 Hub 转发。
|
||||
|
||||
## 试产候选定版
|
||||
|
||||
测试负责候选定版产品的独立质量验证,不替生产或硬件责任方批准制造过程和良率。
|
||||
仅在实际测试任务明确包含试产候选验证时执行,不因本引用存在就在阶段 8 追加测试。测试负责独立质量验证,不替生产或硬件责任方批准制造过程和良率;专项测试报告与提测佐证仍按选填规则处理。
|
||||
|
||||
按适用性确认:
|
||||
|
||||
|
||||
@@ -2,12 +2,14 @@
|
||||
|
||||
仅在当前《测试计划》将功耗、高温、低温、温度循环或环境恢复列为适用专项时读取。
|
||||
|
||||
《可靠性测试报告》为选填,列项为高低温测试、跌落测试(选填)、防水测试(选填);《专项测试报告》同样选填。是否执行具体测试以已确认测试计划和适用标准为准,不因报告选填而取消已确定的必测项,也不为提交一份报告额外增加测试范围。
|
||||
|
||||
## 共同原则
|
||||
|
||||
- 功耗与环境可靠性分别设计、记录和给出结论,不能互相代替;
|
||||
- 阈值、供电、温度点、样本、持续时间和循环次数来自已批准《测试计划》或上游标准;
|
||||
- 记录设备、板卡、固件、配置、样本、仪器、采样方法和环境;
|
||||
- 每个适用子项独立给出通过、失败或阻塞结论,不以平均结果掩盖失败。
|
||||
- 每个适用子项独立给出通过、不通过或阻塞结论,不以平均结果掩盖不通过项。
|
||||
|
||||
## 功耗
|
||||
|
||||
|
||||
Reference in new issue
Block a user