Onekey Qa Review

1.2 文件分类

将变更文件归入以下分类桶：

1.3 识别涉及的模块

根据文件路径中的关键词识别模块：

1.4 自动加载关联文件

对每个识别出的模块，自动读取以下关联文件（如存在）：

• 规则文档：docs/qa/rules/<module>-rules.md
• 用例目录：docs/qa/testcases/cases/<module>/
• 测试脚本：src/tests/<module>/
• ui-map 条目：过滤 shared/ui-map.json 中匹配模块名的条目

1.5 输出范围摘要

审查范围摘要：
- 变更文件：N 个（rules: X, testcases: X, scripts: X, ...）
- 涉及模块：<module1>, <module2>, ...
- 已加载关联文件：<列表>

Phase 2：安全审查（硬拦截）

本阶段对所有变更文件执行扫描，发现任何命中项立即硬拦截，不可跳过。

2.1 扫描项目

2.2 排除项（不触发拦截）

• 正则表达式模式本身（如 /[0-9a-f]{64}/）
• 注释中的示例（// example: 0xabc...）
• 标注了 TEST_ONLY 的值
• docs/ 目录下说明性文档中的占位示例

2.3 输出格式

发现问题时：

SECURITY BLOCK — 发现 <类型>
文件: <path>:<line>
内容（已脱敏）: <前5字符>***<后3字符>

⛔ 安全问题必须修复，不可跳过。提交前请从文件中移除敏感信息。

扫描通过时：

安全审查：通过 ✓

Phase 3：规则文档审查

适用范围： docs/qa/rules/*.md 中的变更文件。

先读取 docs/qa/qa-rules.md 了解规则规范要求。

3.1 结构合规（block）

• 文件有且只有一个一级标题（# 标题）
• 规则条目有编号（如 1.、1.1、R-001）
• 文件末尾有 ## Changelog 或 ## 变更记录 章节

3.2 可验证性（block）

扫描规则正文，标记含有以下模糊词汇的条目：

应正常工作 | 合理展示 | 正确处理 | 符合预期 | 用户友好 | 尽可能 | 一般情况下

每个命中项输出：文件、行号、原文、建议改写方向（"改为可量化的条件，如：价格精度保留 2 位小数"）。

3.3 qa-rules.md 引用（warn）

如果是新增规则文件，检查 docs/qa/qa-rules.md 中是否已有对该模块规则文件的引用。未引用则提示补充。

3.4 用例同步检查（warn）

若规则文件有变更，检查对应模块的 docs/qa/testcases/cases/<module>/ 目录下是否也有变更文件。若规则变更但用例无变更，输出警告：

WARN 规则已变更但未见对应用例更新：
规则文件: <path>
用例目录: <path>（无变更文件）
建议：确认规则变更是否需要同步更新测试用例。

3.5 需求文档同步（warn）

新增规则若无对应的 docs/qa/requirements/<module>-*.md 文件，输出警告建议补充需求文档。

3.6 规则双写一致性（warn）

如果变更涉及 .claude/CLAUDE.md 或 .cursorrules，检查两个文件中的对应章节是否内容一致（关键条目逐行比对）。不一致时列出差异。

Phase 4：手动用例文档审查

适用范围： docs/qa/testcases/cases/**/*.md 中的变更文件。

先读取 docs/qa/qa-rules.md 了解用例规范要求。

4.1 文件规范（block）

• 文件名格式：YYYY-MM-DD_<模块>-<主题>.md（日期合法，模块名全小写）
• 文件存放路径在正确的模块目录下
• 文件首行为 # 开头的标题（不能是空行或代码围栏）
• 文件整体不被 markdown 代码围栏包裹

4.2 表格格式（block）

• 表头为 4 列：| 优先级 | 场景 | 操作步骤 | 预期结果 |
• P0 用例使用 ❗️❗️P0❗️❗️ 标记（不是 P0、[P0] 等变体）
• 多行内容必须用 <br> + 编号（1. xxx<br>2. xxx）。扫描方法：在表格行中搜索含换行意图但缺少 <br> 的单元格（如同一列出现两个 1. 和 2. 但中间无 <br>）
• 不同场景分组放在独立表格中（不混在同一张大表）
• P0 用例排在无依赖的表格最前面（当 P0 与 P1 无先后依赖时）

4.2.1 用例头部元数据完整性（block）

用例文件头部（> 引用块 + 前置条件）必须包含以下信息，缺失即 block：

• 规则文档引用：> 规则文档：docs/qa/rules/<module>-rules.md（必须存在且路径有效）
• 测试端声明：> 测试端： 后跟 iOS / Android / Extension / Desktop / Web 中的一个或多个
• 前置条件：有 ## 前置条件 章节，且不超过 5 行

以下为 warn 级别：

• 需求文档引用（如有）：> 需求文档：docs/qa/requirements/<name>.md
• 变更说明（如适用）：> 变更说明： 描述需求背景
• 前置依赖（如适用）：> 前置依赖： 说明依赖的其他用例

4.3 措辞规范（block）

预期结果列允许词表（可组合使用）：

显示 | 不显示 | 存在 | 不存在 | 选中 | 未选中 | 启用 | 禁用
可点击 | 不可点击 | 数量=N | 包含 | 不包含 | 仅包含
跳转至 | 停留在当前页 | 弹窗显示 | 弹窗关闭

预期结果列禁用词（出现即 block）：

应当 | 正常 | 合理 | 成功 | 符合预期 | 方便用户 | 提升体验 | 正确地 | 尝试

精确扫描方法（严格执行）：

禁用词扫描仅针对表格第 4 列（预期结果），不扫描场景列和操作步骤列。执行方式：

1. 找到所有 | 分隔的表格行（排除表头和分隔行 | --- |）
2. 按 | 分割取第 4 段（预期结果列）
3. 仅在该段内搜索禁用词
4. 场景列（第 2 段）中出现「正常」「合理」等词不报错——这些是合法的前置条件描述

示例（不误报）：

• | ❗️❗️P0❗️❗️ | 网络正常时 | 点击保存 | 显示保存提示 | → 场景列「正常」不报错 ✓
• | ❗️❗️P0❗️❗️ | 名称栏为空 | 输入 24 字符 | 名称输入正常 | → 预期结果列「正常」报错 ✗

对每个命中项输出：文件、行号、完整行、禁用词、建议改写。

4.4 用例质量（warn）

• 场景列描述的前置条件为可观测状态（"已登录 HD 钱包" 而非"正常状态下"）
• 预期结果为可观测的 UI 变化（"按钮变灰不可点击" 而非"操作失败"）
• 边界值/阈值场景有独立测试点（如：最小/最大输入值、零值）
• 状态判断类（开关/权限/层级）用例先验证初始状态再操作

4.5 覆盖度（warn）

优先级分布参考（非硬性要求，仅作审查参考）：

注：P0 占比不作为硬性阈值卡审查，按实际业务重要性分配优先级即可。全部 P0 且无 P1/P2 可提示 warn（便捷功能如粘贴/扫描通常可降级）。

• 涵盖开/关两种状态（toggle 类功能）
• 涵盖 docs/qa/qa-rules.md §4 中的 9 个通用测试维度（加载/空状态/错误/刷新/跨入口/权限/多钱包类型/多链/边界值）
• 与对应的 docs/qa/rules/<module>-rules.md 规则条目有交叉引用或覆盖
• 多钱包类型（HD/观察/HW/多签）相关场景已按钱包类型分组

4.6 数据驱动（warn）

• 多输入场景（如：多条代币/网络/地址）已参数化（不是每条独立一行）
• P0 未对所有参数组合做全量测试（避免组合爆炸）
• 硬件钱包场景已简化为 6 个核心用例（不重复软件钱包所有场景）

4.7 文档联动（warn）

• 对应需求文档 docs/qa/requirements/<module>-*.md 存在
• 对应规则文档 docs/qa/rules/<module>-rules.md 存在且未过期
• docs/qa/qa-rules.md 中有对该模块的引用

4.8 用例内容质量（warn）

逐章节检查用例表格内容，标记以下问题：

冗余检查：

• 章节间无重复用例（同一验证点只出现一次，不在多个章节重复）
• 场景列已说明的信息不在操作步骤中重复（如场景写了"切换到 ETH 网络"，操作步骤不应再写"切换网络"）
• 前置条件只在顶部或章节头写一次，不在每行用例中重复
• 无逻辑重复的用例（如"最大值不含冻结余额"已验证，不需要再单独写"冻结余额无法转出"）
• 无冗余的过渡步骤（如"查看余额"只是看一眼不产生断言，应删除）

准确性检查：

• 场景描述与实际产品行为一致（不描述不存在的功能或数据源）
• 同一逻辑的正反面准确区分（如 ≥ 阈值直接成功无提示 vs < 阈值弹出提示，不能套模板一刀切）
• 数据来源描述正确（API 接口 vs 本地记录 vs 链上数据，不混淆）

精简检查：

• 措辞简洁，不使用冗长的条件描述（能一句话说清的不写三句）
• 英文术语括号注释可省略（如不需要写"existential deposit"、"rent exemption"）
• 多链同类测试的操作步骤只保留差异部分

接口自动化下沉检查：

• 纯服务端逻辑（过滤规则、排序、去重、条数上限、字段校验）应标记为接口自动化覆盖或已下沉
• 已被接口自动化覆盖的用例在顶部有简要说明，表格中不重复展开
• 接口已覆盖但仍需验 UI 的场景，简化为一句话带过（如"确认前端展示与接口一致"）

优先级检查：

• 识别/提示类用例（如地址格式识别、金额提示拦截）优先级为 P0
• 实际操作验证类（如转账成功、附加费用）可降为 P1
• 纯服务端验证已下沉到接口自动化的，从 P0 降级或移除

术语一致性检查：

• 同一文档内同一概念使用统一术语（不出现"stored recipients"和"本地历史记录"混用）
• 字段名统一（如 tag 不写成 destinationTag、memo 不写成 Memo/备注 混用）
• 不使用产品中不存在的概念（如"链历史"实际不存在则不应出现）
• 中英文混用时保持一致风格（要么全用中文描述，要么首次出现标注英文后续统一用中文）
• 钱包类型术语统一：助记词钱包写作 HD 钱包（不写"软件钱包"），硬件钱包写作 HW 钱包（不写"硬件钱包"），Private Key / Keyless 直接点名。同一文档内不得混用「软件钱包」「HD 钱包」「助记词钱包」指代同一概念（详见 docs/qa/qa-rules.md 术语统一表）

测试数据完整性检查：

• 需要具体测试数据的用例（如 scam 地址过滤、特定链转账）有明确的地址/金额/链名
• 测试数据在顶部"前置条件与测试数据"或用例场景列中给出，不留模糊描述（如"某个地址"、"一笔交易"）
• 涉及阈值/限制的用例标明具体数值（如"最低 0.1 ALGO"而非"低于最低限额"）

4.9 跨文件数据一致性（block）

当用例文件引用了其他用例的数据时（如「前置依赖：添加地址用例中的数据未删除」），必须交叉验证：

• 记录数一致：引用的记录数（如「77 条」）与被引用文件中的实际数据行数一致
• 具体数据一致：引用的具体值（如地址 38Xegnipu2RhZouctnGnwmDRk2bLXfDHf4、名称 BTC-taproot）在被引用文件中确实存在
• 网络名称一致：两个文件中同一网络的显示名称相同（不能一个写 BNB Smart Chain 另一个写 BNB Chain）

执行方法：

1. 从文件头部 > 前置依赖： 提取被依赖的文件
2. 读取被依赖文件，提取数据集行数和关键值
3. 与当前文件中引用的数值逐一比对

4.10 生成时自检清单（info）

以下清单用于用例生成阶段的自检，review 阶段作为 info 级别提示。如果用例是新生成的（untracked file），自动输出此清单的不合规项：

qa-rules.md 合规自检：

• 文件名 YYYY-MM-DD_<模块>-<主题>.md，日期为今天
• 首行 # 标题与文件名主题一致
• 头部引用块包含规则文档、测试端
• 前置条件不超过 5 行
• 表格 4 列格式：| 优先级 | 场景 | 操作步骤 | 预期结果 |
• 预期结果列无禁用词（应当/正常/合理/成功/符合预期/方便用户/提升体验/正确地/尝试）
• 预期结果列使用允许词表中的动词
• 多行内容使用 <br> + 编号
• 不同场景分组在独立表格
• 边界值覆盖（qa-rules.md §4.1）：空值、空格、超长、特殊字符、恰好=阈值、超出阈值
• 操作步骤为具体动作（点击/输入/滑动），不用「尝试」
• 场景列为可观测的起始状态，不用模糊描述

Phase 5：自动化脚本审查

适用范围： src/tests/**/*.test.mjs 中的变更文件。

先读取 CLAUDE.md 中的 "Test Script Rules" 章节作为评审标准。

5.1 脚本结构（block）

• 文件导出 export const testCases = [{ id, name, fn }]
• 文件导出 export async function setup(page)
• 文件导出 export async function run()
• 所有 fn 只接收 page 一个参数（不接收额外参数）
• 文件顶部有注释说明用例覆盖范围（如 // covers: XXX-001 ~ XXX-008）

5.2 用例映射（block）

• testCase 数量与用例文档中的大标题（一级编号）数量一致
• 每个 testCase 的 id 和 name 与文档标题对应
• 如文档有变更，脚本的 id/name 也已同步更新
• 一个 testCase 对应文档一个大标题，不拆分也不合并大标题

5.3 断言质量（block）

• 使用 createStepTracker + safeStep（不使用自定义步骤函数）
• 无软断言（如 assertHasSomeTableLikeContent(page)）
• 数值变化用精确 delta（=== before + 1），不用模糊比较（!== before）
• 多入口状态同步用例已在所有入口逐一验证
• 每个断言有明确的 passed/failed 判定（没有"检查了但标 passed"的逻辑）
• 每个 fn 末尾有 return t.result()

5.4 选择器健壮性（warn）

• 优先使用 ui-map.json / components.mjs / PageObject 中的选择器
• 相同定位逻辑出现 2 次以上已提取到公共库
• TMPopover-ScrollView 使用 querySelectorAll 遍历可见实例（不用 querySelector）
• 弹窗内操作定位到弹窗内部元素（不在弹窗外操作）
• 输入操作使用 locator.pressSequentially()（不用 fill 或 keyboard.type）

5.5 环境硬编码检查（block）

扫描以下硬编码类型并输出表格：

扫描项：

• 钱包地址（0x 开头 40 字节十六进制，或 Cosmos/Solana 格式）
• 固定交易金额（非测试占位符的数字，如 amount: 100）
• 硬编码代币列表（数组中写死的 ticker，如 ['BTC', 'ETH', 'BNB']）
• 硬编码账户名（如 'hl-99'、'测试账户1'）
• 过长 sleep（await sleep(N) 且 N ≥ 3000，无轮询等待）

同时检查：变更脚本是否引用了相关的规则文档（注释中是否注明 source of truth）。 如果脚本注释中标注了数据来源（如 // source: swap-network-features.md），该硬编码值降级为 info 而非 block。

5.6 Dashboard 反馈（block）

• 所有操作步骤用 safeStep 包裹（不裸写 await page.click(...)）
• 步骤粒度合理（每个有意义操作独立一步）
• 步骤名称简洁描述做了什么（不是 step1、操作）
• failed 步骤有非空 detail（错误信息）
• skipped 步骤有非空 detail（跳过原因）
• fn 末尾 return t.result()

5.7 状态清理（warn）

• 测试间调用 dismissOverlays(page) 清理残留弹窗
• 不向全局状态写入（不污染其他 testCase 的前置条件）
• 截图只在失败时拍摄（safeStep 失败分支已配置截图，成功分支无截图）

Phase 6：Skill 文件审查

适用范围： .claude/skills/** 中的变更文件。

6.1 格式规范（warn）

• 文件有 YAML frontmatter（--- 包裹）
• Frontmatter 包含 name、description、user-invocable 字段
• description 中有 Triggers on: 说明触发词

6.2 触发词冲突检查（warn）

读取所有其他 Skill 的 description 中的 Triggers on: 内容，与当前变更 Skill 的触发词比对，输出重叠项：

WARN 触发词冲突：
当前 Skill: <name>  触发词: "<trigger>"
已存在 Skill: <name> 也使用该触发词
建议：修改其中一个的触发词或合并 Skill。

6.3 路径引用规范（warn）

扫描 Skill 正文中的文件路径引用：

• OneKey 可执行文件使用 $ONEKEY_BIN 环境变量，不硬编码绝对路径
• 项目目录使用相对路径，不硬编码 /Users/<username>/... 等绝对用户路径（info 级别）

6.4 规则双写一致性（warn）

如果 Skill 变更包含与 CLAUDE.md 或 .cursorrules 重叠的规则内容，检查两边是否一致。

Phase 7：通用代码审查

适用范围： 所有变更文件。

7.1 调试代码残留（warn）

扫描：

• console.log（非 stepTracker 的 t.add 调用）—— 提示是否为调试日志
• debugger 语句
• 注释掉的代码块（连续 5 行以上的 // 注释）

输出：文件、行号、内容片段。

7.2 导入路径合法性（warn）

• 所有 import 语句的目标文件实际存在
• 无循环依赖（A 导入 B，B 导入 A）

7.3 文件命名规范（info）

• 测试脚本：<module>-<feature>.test.mjs（小写，用连字符）
• 辅助文件：<name>.mjs（小写）
• 文档：YYYY-MM-DD_<Module>-<Topic>.md（日期 + 驼峰模块名）

7.4 死代码（info）

• 无未使用的变量（声明后从未读取）
• 无未使用的导入（import 后从未引用）
• 无被注释掉且不再需要的函数定义

Phase 8：生成报告 + 拦截决策

8.1 问题汇总表

将所有发现的问题按维度和级别汇总：

| 维度 | security | block | warn | info | 合计 |
|------|----------|-------|------|------|------|
| 安全审查 | X | - | - | - | X |
| 规则文档 | - | X | X | - | X |
| 用例文档 | - | X | X | X | X |
| 自动化脚本 | - | X | X | - | X |
| Skill 文件 | - | - | X | - | X |
| 通用代码 | - | - | X | X | X |
| **合计** | X | X | X | X | X |

8.2 写入完整报告

报告路径：shared/reports/review-YYYY-MM-DD-HHMMSS.md（使用当前时间戳）

报告结构：

# QA 审查报告

**时间：** YYYY-MM-DD HH:MM:SS
**审查范围：** <Phase 1 的范围摘要>
**变更文件数：** N

## 问题统计
<Phase 8.1 的汇总表>

## 详细问题列表

### 安全问题（security）
<按文件:行号列出，内容脱敏>

### 阻断问题（block）
<按审查维度分组，每条含文件:行号+描述+建议>

### 警告问题（warn）
<同上>

### 信息提示（info）
<同上>

## 覆盖度分析
| 模块 | P0 | P1 | P2 | 总计 | 9维度覆盖 |
|------|----|----|----|----|---------|
| ... | ... | ... | ... | ... | ...% |

## 环境适应性问题
| 文件 | 行号 | 类型 | 当前值 | 风险 | 建议 |
|------|------|------|--------|------|------|
| ... | ... | ... | ... | ... | ... |

## 用户确认跳过的问题
<如有用户选择跳过的 block 问题，记录在此>

8.3 对话中输出精简版

只输出 security 和 block 级别的问题列表，warn/info 仅给统计数字：

审查完成。发现 <security> 个安全问题，<block> 个阻断问题，<warn> 个警告，<info> 个提示。
完整报告：shared/reports/review-YYYY-MM-DD-HHMMSS.md

[如有 security/block 问题则列出详情]

8.4 拦截决策

根据问题级别执行对应策略：

security > 0：

⛔ SECURITY BLOCK
发现 N 个安全问题，无法跳过。
请修复后重新运行 /onekey-qa-review。

block > 0（无 security）：

🚫 发现 N 个阻断问题：

1. [block] <文件>:<行> — <描述>
2. [block] <文件>:<行> — <描述>
...

请选择：
(1) 我来修复，修复后重新审查
(2) 我确认这些问题可以跳过，继续提交

用户选择 (2) 时，记录到报告的"用户确认跳过的问题"章节，然后继续。

只有 warn/info：

✅ 审查通过（warn: N, info: N）
可以提交。建议在下次迭代中处理警告项。

8.5 报告文件清理

保留最多 20 个审查报告，超出时删除最旧的：

ls -t shared/reports/review-*.md | tail -n +21 | xargs rm -f

参考文档

• docs/qa/qa-rules.md — 用例规范总纲
• docs/qa/rules/<module>-rules.md — 各模块规则文档
• docs/qa/requirements/ — 需求文档目录
• .claude/CLAUDE.md → Test Script Rules — 自动化脚本规范
• shared/reports/ — 审查报告输出目录
• src/tests/helpers/components.mjs — 公共组件库（createStepTracker, safeStep）