> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（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. 最容易犯的两个错
- 把环境问题当缺陷提 → 缺陷库被污染，团队开始不信缺陷单
- 把缺陷当环境问题放过 → 线上事故
分流规则：看错误栈最深处服务名。是环境 → 记 environment_issues 不提缺陷单；
是产品缺陷 → 按 qa-bug-reporting 提交。
6. 观察记录（每轮一份）
### 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%"绝对化表述
