qa-execution-observation

该技能用于测试执行阶段：指导同时观察功能结果、性能、日志、数据、UI 渲染、依赖六路信号，按场景复杂度确定必须捕获的信号路数，逐轮输出观察记录，并在设计阶段的 9 列用例上回填「实际结果」与「结论」完成执行闭环，标注异常信号与待跟进项。

kokxi

热度 59.20

最近更新 2026-09-29 12:28:38

分类：开发依赖：代码执行 / 读写文件 / 第三方 API应用场景：报告撰写 / 工作流 / 数据处理 / 模板

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add qa-execution-observation

Metadata

displayName: 测试执行观察
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: {"slug":"qa-execution-observation","display-name":"测试执行观察","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`
写执行记录表或观察记录	`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. 交付前自检

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

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

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