⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

执行观察力#

核心原则#

同样在执行，专家看到了更多信息。

大多数 Bug 是被"不小心看到"的，而不是被测出来的——你得同时盯着六路信号，才有机会看到它们。

1. 六路信号速查#

信号最易漏的观察点可靠性1 功能结果结果一致性与边界处理中2 性能资源占用（不阻塞功能，最易漏）中3 日志****WARN 级异常警告（常被"吞掉"）高4 数据字段精度/格式/时区最高（界面会骗人，数据库不会）5 UI 渲染控制台报错（界面正常但控制台红）中6 依赖消息队列与缓存（前端无感知）中

逐路的观察要点与观察方法见 references/observation-guide.md。

2. 观察深度要求#

关键指标：按场景复杂度决定本轮必须捕获几路信号。

复杂度必须捕获说明简单场景**≥ 3 路单一功能路径中等场景≥ 5 路多分支交互复杂场景全部 6 路**跨模块/分布式

未捕获的信号路必须写明原因。 不要为凑数把 6 路全标已观察—— 标了没看比没标更危险。

3. 加载时机#

什么时候读读哪个逐路信号的观察要点与方法、异常信号识别、异常分流references/observation-guide.md写执行记录表或观察记录assets/execution-record.md（执行记录表 + 观察记录 + 填写要求 + 自检）

4. 产出：设计 → 执行闭环#

qa-test-case-design 产出 9 列设计用例（刻意不含「实际结果」）； 本技能在其上回填两列完成闭环。 这是全项目唯一有权产出「实际结果」的技能。

用例编号测试类型功能模块测试标题用例级别预置条件测试步骤预期结果风险等级实际结果****结论TC_API_LOGIN_001功能测试认证/登录正确凭证登录成功P0账号 u1 已就绪POST /api/login返回 200，响应含 token高返回 200，token 有效；87ms；日志无 ERROR通过TC_API_LOGIN_002安全测试认证/登录伪造 Token 被拒P0已知合法 token改 1 字符请求返回 401，不含内部信息高返回 200，且返回了用户手机号失败TC_API_LOGIN_003异常测试认证/登录超时重试不重复副作用P1网关可注入延迟延迟至超时后重放 2 次最终仅 1 次登录记录中阻塞：注入延迟后网关无响应，无法重放阻塞

• 实际结果 写观察到的事实，不是判断
• 结论 只有三种：通过 / 失败 / 阻塞（阻塞必填原因）

完整模板与填写要求见 assets/execution-record.md。

5. 最容易犯的两个错#

1. 把环境问题当缺陷提 → 缺陷库被污染，团队开始不信缺陷单
2. 把缺陷当环境问题放过 → 线上事故

分流规则：看错误栈最深处服务名。是环境 → 记 environment_issues 不提缺陷单； 是产品缺陷 → 按 qa-bug-reporting 提交。

6. 观察记录（每轮一份）#

markdown

### OBS-LOGIN-001 — 登录功能执行观察（第 1 轮）

- **执行用例**：TC_API_LOGIN_001 / 002 / 003
- **环境**：预发 env-2，Chrome 120，2026-09-28 14:30
- **捕获信号数**：6/6

**待跟进**
1. 002 伪造 token 返回 200 且泄漏手机号 → 提交缺陷（安全，高危）
2. 日志 WARN 与 002 是否同源？→ 交 qa-bug-root-cause-analysis

7. 交付前自检#

执行自检（这轮做对了吗）

• 是否观察了六路信号？（按深度要求，注明捕获几路）
• 是否记录了异常信号？
• 是否分析了异常原因？
• 是否验证了数据状态？
• 是否清理了测试数据？
• 是否恢复了测试环境？

交付检查（产出能交了吗）

• 观察维度是否覆盖（功能/接口/日志/UI）？
• 异常信号是否记录？
• 多轮观察是否对比？
• 观察报告是否生成？
• 可疑点是否标注？
• 每条执行用例都有实际结果与结论，无留空
• 实际结果写的是事实而非判断（不是"正常""符合预期"）
• 结论为"阻塞"的写了阻塞原因
• 每个异常信号都做了 环境 vs 缺陷分流
• 发现的缺陷已按 qa-bug-reporting 提交
• 汇总口径已标注，无"全覆盖/100%"绝对化表述