first commit

etunel-role-collaboration/references/testing/connectivity-and-compatibility.md

@@ -0,0 +1,30 @@
+# 连接与兼容性专项
+
+仅在当前 Test Plan 包含 Wi-Fi、SD 卡或路由器兼容性时读取。每个矩阵按实际客户、市场、芯片方案和产品范围裁剪，并记录未覆盖范围。
+
+## Wi-Fi 性能与稳定性
+
+Wi-Fi 性能／稳定性和路由器兼容性分别管理，可共享设备矩阵。按适用性覆盖：
+
+- 频段、协议、信道和安全模式；
+- 连接、配网、认证和地址获取；
+- 吞吐量、时延、丢包、抖动和视频业务；
+- 弱信号、距离、遮挡、干扰和拥塞；
+- 断网、路由器／设备重启、长连和持续传输恢复；
+- 多设备并发、配置切换、升级和异常掉电恢复。
+
+具体指标、距离、持续时间、并发和网络模型由 Test Plan 定义。
+
+## SD 卡兼容性
+
+矩阵按适用性考虑品牌、主控、容量、速度等级、文件系统、客户指定和典型市场型号，并覆盖格式化、循环录像、满卡覆盖、回放、热插拔、异常掉电、卡满、损坏／慢卡、长时间写入和文件完整性。
+
+少量型号通过不能支持“兼容所有 SD 卡”的结论。
+
+## 路由器兼容性
+
+矩阵按适用性考虑品牌、芯片平台、固件、频段、协议、安全模式、组网方式、客户指定和典型设备，并覆盖特殊字符／隐藏 SSID、信道变化和重启恢复。
+
+兼容矩阵需要版本化，并随客户、市场现场问题和芯片方案更新。未覆盖设备必须披露，不能宣称兼容全部路由器。
+
+环境、设备或客户指定清单缺失而无法完成 Required 覆盖时，结果为 BLOCKED，不得标记 NA。

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

@@ -0,0 +1,189 @@
+# 测试执行与质量门禁
+
+测试角色形成 Test Plan、检查提测准入、执行版本测试、管理缺陷或给出质量结论时读取。本文件规定稳定的执行规则；项目具体阈值、样本、周期、资源和 SLA 由当前已批准 Test Plan 定义。
+
+## 三层测试契约
+
+1. **角色契约**：规定测试的长期使命、决定权、边界、必要输入和强制质量原则。
+2. **通用执行规则**：本文件规定适用性、准入、状态、统计、缺陷、证据和门禁。
+3. **项目 Test Plan**：按具体产品、硬件、客户、平台和阶段确定范围、阈值、样本、时长、环境、资源、版本策略和输出节点。
+
+测试可以提出专业阈值建议，但不得自行创造产品要求、客户承诺或验收标准。
+
+## 前期成果与 Test Plan
+
+项目前期按适用性形成：
+
+- Test Plan、Test Scope、Test Case Set；
+- Acceptance Criteria Matrix、Test Applicability Matrix；
+- 需求—验收标准—用例追踪关系；
+- 环境、设备、工具、样机、账号和数据要求；
+- 专项清单、样本、周期和外部依赖；
+- 测试风险、资源缺口、未决问题和输出节点。
+
+Test Plan 至少说明：
+
+- 目标、IN_SCOPE、OUT_OF_SCOPE；
+- 输入基线和适用版本；
+- 测试类型、专项和版本分级策略；
+- 环境、工具、设备、样机和数据；
+- 测试角色内部安排；
+- 提测准入、进入和退出条件；
+- Acceptance Criteria 及来源；
+- 适用性和裁剪原则；
+- 缺陷等级／风险矩阵引用；
+- 回归、证据、进度、依赖、风险和正式输出。
+
+Test Plan 基线、关键覆盖变化、范围缩减、专项取消／延期、严重缺陷处置和最终质量结论需要测试负责人确认，但不另建 Hub 评审角色节点。涉及客户范围或业务风险时，再由 Hub 定向交业务决定。
+
+## 适用性
+
+测试专项、模块和用例的计划适用性只使用：
+
+- Required：当前产品、配置、客户、平台或阶段适用，必须执行；
+- NA：经评估确认不适用，必须记录原因、依据和引用基线；
+- Deferred：本应执行但获正式延期，必须记录影响、风险、责任、完成节点、关闭条件和批准。
+
+NA 不得表示时间／人员不足、环境／样机／账号缺失、版本阻塞、数据缺失、外部依赖未满足、失败或尚未执行。适用但无法完成的项目是 BLOCKED，不是 NA。
+
+任何产品需求、验收标准、硬件、PCB、BOM、固件、软件、配置、接口、平台标准、客户范围、试产批次或交付版本变化都触发测试影响评估。是否完整重测由影响分析决定，不能无评估沿用旧结论。
+
+## 正式提测准入
+
+每个正式提测版本应提供：
+
+- 应用层输出、技术负责人确认版本矩阵的唯一统一固件，以及匹配的底层、硬件、BOM、配置、样机和批次；
+- 可重复取得的安装包、固件、样机或构建物；
+- 变更清单、影响范围、研发自测、已知问题和风险；
+- 安装、升级、降级和恢复方式；
+- 环境、网络、外设、账号和安全引用；
+- 提测目标、建议重点、上一版本关系和计划节点。
+
+输入不满足时，测试可判定提测拒绝或 BLOCKED。探索性检查必须与正式测试结果分开。
+
+## 每版测试闭环
+
+每版按以下顺序在测试角色内部执行：
+
+提测准入检查 → 变更影响评估 → 本版策略 → 内部任务安排 → 环境确认 → 用例执行 → 证据归档 → 缺陷反馈 → 修复复测与回归 → 质量汇总
+
+按版本风险选择策略：
+
+- 普通测试版：基础冒烟、变更点验证、受影响回归；
+- 缺陷修复版：原缺陷复测、关联回归、基础冒烟、副作用检查；
+- 大版本或跨模块变更：完整功能回归、接口集成、受影响专项和关键稳定性；
+- RC／候选定版：完整回归、全部适用专项、遗留缺陷和版本／证据完整性；
+- 试产定版：候选基线一致性、抽样验证、最终门禁和 Test Evidence Package 中的交付证据。
+
+实现角色提供变更和自测信息，但不能单方面缩减测试范围。
+
+## 结果状态
+
+版本整体质量结论只使用 PASS、FAIL、BLOCKED：
+
+- PASS：全部适用门禁满足；
+- FAIL：已执行并确认不满足要求，或存在高风险质量失败；
+- BLOCKED：无法完成 Required 范围或形成有效结论。
+
+专项、模块和正式用例结果只使用 PASS、FAIL、BLOCKED、NA。待执行和执行中是进度，不是正式结果。到正式汇总或报告节点，所有计划用例都必须有结果；适用但未完成的用例填 BLOCKED，不能留空或改成 NA。
+
+BLOCKED 必须说明原因、受影响范围、证据、责任或协调角色、解除条件和补测要求。Required 中存在 BLOCKED 时，版本不能判定 PASS。
+
+## 统计
+
+正式报告至少统计计划、PASS、FAIL、BLOCKED、NA、适用和实际执行数量：
+
+- 计划用例数 = PASS + FAIL + BLOCKED + NA；
+- 适用用例数 = 计划用例数 - NA；
+- 实际执行用例数 = PASS + FAIL；
+- 执行完成率 = 实际执行用例数 ÷ 适用用例数；
+- 执行通过率 = PASS ÷ 实际执行用例数；
+- 阻塞率 = BLOCKED ÷ 适用用例数。
+
+实际执行数为 0 时，通过率是“不可计算”，不是 100%。BLOCKED 保留在适用分母中；不得把 BLOCKED 改为 NA 或用总体通过率掩盖关键失败。
+
+## 缺陷与关闭
+
+测试创建、持续维护并最终关闭 Defect Analysis Report。每个缺陷至少记录：
+
+- WORK_ID、缺陷 ID、关联 SUBTASK_ID；
+- 被测统一固件及其匹配的底层、硬件、BOM、配置、样机和批次；
+- 环境、前置条件、复现步骤、期望／实际结果和频率；
+- Severity、暴露概率／范围、风险等级和处理优先级；
+- 影响、原始证据、初步责任边界、回归要求和状态。
+
+影响程度、发生概率、风险等级和处理优先级必须分开。不得通过临时降级绕过门禁。
+
+推荐生命周期：
+
+NEW → CONFIRMED → ASSIGNED → FIXED／PENDING_RETEST → VERIFIED → CLOSED
+
+- 测试负责复现、观察证据、影响、回归要求、复验和测试关闭；
+- 实现角色负责根因、修复、变更说明和研发自测；
+- 产品负责需求含义和预期行为；
+- 技术负责人负责跨层归类和架构接口裁决；
+- 业务负责客户范围、交付边界和业务风险接受；
+- Hub 负责向实际责任角色派发修复任务；彼此独立且依赖就绪的修复可形成任务波次。
+
+实现角色只提交 Root Cause Analysis、Fix Plan、修复成果、版本和自测，不能替换或关闭 Defect Analysis Report。研发声明修复不能直接关闭缺陷；只有测试在目标版本组合独立复验通过后才能 VERIFIED 或 CLOSED。Duplicate、As Designed、Cannot Reproduce、Won’t Fix 和 Deferred 保留理由与证据；未关闭项进入遗留缺陷和剩余风险。
+
+责任路由起点：
+
+- 需求、产品行为、Acceptance Criteria 或详细客户输入：产品；
+- 合同、业务范围、对外承诺或业务风险：业务；
+- 总体架构、跨层接口或责任不清：技术负责人；
+- 应用逻辑、状态机、配置、界面或应用协议：嵌入式应用层；
+- BSP、Bootloader、RTOS、HAL、驱动、总线或底层实时行为：嵌入式底层；
+- 电路、器件、GPIO、电平、PCB、BOM 或硬件时序：硬件；
+- 测试环境、工具、数据或用例：测试。
+
+这只是证据化建议，正式修复任务始终由 Hub 按实际责任和依赖创建。
+
+## 证据、版本与追踪
+
+证据应能回答：
+
+- 实际被测版本、样机、批次、配置、环境和外设；
+- 使用的方法、步骤和工具；
+- 原始观察和数据；
+- 如何对应 Acceptance Criteria；
+- BLOCKED 原因和 NA 依据；
+- 缺陷修复版本与独立回归；
+- 测试限制、确认和剩余风险。
+
+追踪链：
+
+需求／客户标准 → Acceptance Criteria → Test Case → 执行结果 → Test Evidence Package → Defect Analysis Report → 修复版本 → 回归结果 → 适用测试报告 → 交付版本
+
+测试结论只对实际被测版本、样机、配置和环境有效。无法证明平台、试产和交付版本一致时，最终结论为 BLOCKED。
+
+普通测试成果不得保存密码、Token、私钥、证书密钥或其他敏感值；只记录提供状态、适用环境、责任和安全引用。
+
+## 最终测试定版门禁
+
+只有全部适用条件满足才可给出最终 PASS：
+
+1. Required 范围执行完成率 100%，无 BLOCKED；
+2. 关键门禁用例全部 PASS；
+3. 所有适用 Acceptance Criteria 满足；
+4. 所有适用专项有明确结论；
+5. 无高风险 Open Bug；
+6. 中低风险遗留已评估、披露并取得必要确认；
+7. 修复已在目标版本独立回归；
+8. 被测版本与平台、试产和交付候选版本一致；
+9. Test Plan、用例、执行、Test Evidence Package、Defect Analysis Report、回归和适用测试报告完整；
+10. 限制、依赖和剩余风险明确，测试有权人员确认最终结论。
+
+高风险 Open Bug、关键用例失败、Acceptance Criteria 不满足或严重回归必须 FAIL。关键 Required 用例 BLOCKED、执行不足、环境／依赖不可用、版本不一致或证据不足必须 BLOCKED。
+
+最终测试 PASS 不等于业务验收、客户风险接受、发布批准或制造良率批准。
+
+## 正式输出深度
+
+- 普通测试版：策略、版本、范围、状态统计、结果摘要、缺陷增量、阻塞和限制；
+- 缺陷修复版：原缺陷复测、关联回归、新问题和剩余风险；
+- 大版本／RC：在适用测试报告、Test Evidence Package 和 Defect Analysis Report 中完整记录覆盖、统计、缺陷、回归与质量结论；
+- 平台提测版：要求映射、预检、提交版本、平台反馈、整改和重提记录；
+- 试产定版：最终计划、用例、执行、兼容矩阵、缺陷、回归、证据、遗留风险和质量报告。
+
+角色契约不固定统一小时级 SLA；响应、测试、回归和报告时限由项目计划或 Test Plan 定义。

etunel-role-collaboration/references/testing/image-quality.md

@@ -0,0 +1,25 @@
+# 画质专项
+
+仅在当前产品、客户范围或 Test Plan 要求画质验证时读取。
+
+## 责任边界
+
+- 产品确认用户可见行为、目标风格和 Acceptance Criteria；
+- 硬件提供 Sensor、镜头、IR-CUT、补光和相关规格事实；
+- 嵌入式底层／应用层提供实际图像链路、参数、构建和配置版本；
+- 测试设计场景、执行测量、保留数据并形成独立结论；
+- 含义或目标风格不清时通过 Hub 返回产品，不以“观感良好”替代标准。
+
+## 测试设计
+
+按适用性结合客观指标、标准场景、Golden Sample 和受控主观评价，覆盖：
+
+- 清晰度、色彩、白平衡、曝光和宽动态；
+- 逆光、高光、低照度、噪声和拖影；
+- 日夜切换、畸变、暗角、坏点和闪烁；
+- 分辨率、码率、帧率及关键参数组合；
+- 不同硬件、固件、配置和样本的一致性。
+
+Test Plan 明确光源、场景、距离、环境、样本、设备、指标、主观评价方法、目标版本和阈值来源。原图、视频、参数快照、测量数据和对比结果应可追踪。
+
+未覆盖场景必须披露；不得由少量主观观察推导全部画质条件通过。

etunel-role-collaboration/references/testing/platform-and-pilot.md

@@ -0,0 +1,34 @@
+# 平台提测与试产定版
+
+当前任务包含第三方／客户平台正式提测或试产候选定版时读取。
+
+## 平台提测
+
+平台流程使用：
+
+INTERNAL_PRECHECK → READY_FOR_SUBMISSION → SUBMITTED → PLATFORM_PASSED／PLATFORM_FAILED／PLATFORM_BLOCKED
+
+要求：
+
+- 平台标准与测试项可追踪；
+- 内部预检版本、正式提交版本和证据版本一致；
+- 保存提交材料、版本、账号／环境安全引用、提交时间和平台正式结果；
+- 平台反馈转入缺陷闭环，修复后复测、回归并按需重提；
+- 平台窗口、账号、客户或业务依赖通过 Hub 定向协调。
+
+内部预检通过不等于平台通过。只有平台正式结果可以支持 PLATFORM_PASSED。
+
+## 试产候选定版
+
+测试负责候选定版产品的独立质量验证，不替生产或硬件责任方批准制造过程和良率。
+
+按适用性确认：
+
+- 样机、批次、硬件、底层固件、应用构建和配置与候选基线一致；
+- 抽样方法、样本数和批次可追踪；
+- 核心功能、升级恢复、画质、连接、存储和必要专项完成；
+- 试产问题进入缺陷闭环；
+- 无高风险 Open Bug；
+- 报告明确未覆盖范围、限制和剩余风险。
+
+最终测试版本必须与平台送审、试产和交付候选版本一致。无法证明一致时，质量结论为 BLOCKED。

etunel-role-collaboration/references/testing/power-and-environment.md

@@ -0,0 +1,35 @@
+# 功耗与环境可靠性
+
+仅在当前 Test Plan 将功耗、高温、低温、温度循环或环境恢复列为适用专项时读取。
+
+## 共同原则
+
+- 功耗与环境可靠性分别设计、记录和给出结论，不能互相代替；
+- 阈值、供电、温度点、样本、持续时间和循环次数来自已批准 Test Plan 或上游标准；
+- 记录设备、板卡、固件、配置、样本、仪器、采样方法和环境；
+- 每个适用子项独立给出 PASS、FAIL 或 BLOCKED，不以平均结果掩盖失败。
+
+## 功耗
+
+按产品场景选择开机峰值、待机、预览／推流、录像与存储、Wi-Fi 高负载、日夜切换、补光／红外、升级、重启和其他高负载状态。
+
+Test Plan 明确：
+
+- 供电与配置；
+- 业务场景、样本数和预热条件；
+- 测量设备、采样频率和方法；
+- 稳态、平均值、峰值和异常波动判定；
+- 时长、重复次数和阈值来源。
+
+## 高低温与循环
+
+按适用性覆盖：
+
+- 高温启动和运行；
+- 低温启动和运行；
+- 高低温循环；
+- 必要的高低温存储和恢复后验证。
+
+Test Plan 明确温度点、升降温条件、稳定时间、持续时间、循环次数、样本数、负载和恢复时间。环境中及恢复后检查适用的启动、核心功能、画质、网络、存储、升级／恢复、日志和不可逆变化。
+
+无法满足环境、仪器、样本或持续时间要求时标记 BLOCKED，不得改成 NA。