qa-execution-observation

当测试新人不知道执行时应该关注什么、或者有经验的测试发现"执行完了但好像什么都没发现"时使用此技能。测试执行不是"按步骤操作看结果"——你需要同时关注功能表现、接口响应、日志报错、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.

⚠️ 本技能单独使用效果有限，建议配合完整技能集（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%"绝对化表述