---
name: qa-execution-observation
description: >-
  当测试新人不知道执行时应该关注什么、或者有经验的测试发现"执行完了但好像什么都没发现"时使用此技能。测试执行不是"按步骤操作看结果"——你需要同时关注功能表现、接口响应、日志报错、UI 渲染、数据一致性、性能指标六路信号。大多数的 Bug 是被"不小心看到"的而非被测出来的。每轮执行后输出观察记录，在 9 列设计用例上回填「实际结果」与「结论」完成执行闭环，标注异常信号与待跟进问题。⚠️ 本技能示例可能调用外部监控/截图工具，请在受控环境执行。
  触发场景：执行观察、观察日志、测试执行、多轮观察、执行异常、观察报告、需要分析执行过程异常时。 Use when the user asks about: observing test execution across six signal channels — functional behavior, API responses, logs, UI rendering, data consistency, and performance.
license: MIT
allowed-tools: Read Grep Glob Bash
metadata:
  display-name: "Execution Observation"
  version: "1.8.0"
  when-to-use: "用户说\"执行观察\"、\"观察日志\"、\"测试执行\"、\"多轮观察\"、\"执行异常\"、\"观察报告\"、需要执行测试观察、需要分析执行过程异常时"
  related-skills: "{\"upstream\":[\"qa-scenario-tree\",\"qa-boundary-deep-dive\"],\"downstream\":[\"qa-bug-root-cause-analysis\",\"qa-bug-reporting\",\"qa-test-reporting\",\"qa-testability-advocacy\"]}"
  references: "[\"references/observation-guide.md\",\"assets/execution-record.md\"]"
  input-format: "{\"required\":[{\"name\":\"测试用例\",\"type\":\"array\",\"description\":\"来自qa-test-case-design的9列设计用例（不含实际结果）\"},{\"name\":\"执行环境\",\"type\":\"string\",\"description\":\"测试环境配置信息\"}],\"optional\":[{\"name\":\"预期结果\",\"type\":\"array\",\"description\":\"各用例的预期结果对照\"}]}"
  output-format: "{\"traceability\":[\"每轮观察带唯一ID：OBS-{模块缩写}-{三位序号}\",\"关联执行用例ID：TC_{模块缩写}_{功能缩写}_{三位序号}（沿用设计阶段编号，不新造）\"],\"structure\":[{\"execution_record\":\"执行记录表：在设计阶段 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）基础上回填「实际结果」与「结论」两列\"},{\"observation_record\":\"观察记录：执行用例|环境|捕获信号数 + 六路信号逐路观察结果 + 待跟进项\"},\"本技能是全项目唯一有权产出「实际结果」的技能——该列属于执行阶段，设计模板（qa-test-case-design）刻意不含此列\",\"结论取值：通过 / 失败 / 阻塞（阻塞必填原因）\",\"六路信号捕获要求：简单场景≥3路 / 中等≥5路 / 复杂=6路\",\"覆盖率：标注口径（基于本轮实际执行的用例数），禁止\\\"全覆盖/100%\\\"绝对化表述\"]}"
  error-recovery-guidance: "{\"on_failure\":\"记录偏差但不中断流程，汇总到最终报告\",\"retry_behavior\":\"继续执行，在最终报告中标注异常\"}"
  categories: "[\"Development\",\"Testing\",\"Quality\"]"
  depth-requirement: "{\"reference_value\":\"见正文「观察深度要求」表：按场景复杂度决定本轮必须捕获的信号路数\",\"minimum\":\"简单场景至少捕获 3 路信号；未捕获的信号路必须标注原因\"}"
---

> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（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`](references/observation-guide.md) |
| 写执行记录表或观察记录 | [`assets/execution-record.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%"绝对化表述