agentleFS
Sign inStart free
KokxiKokxi/qa-test-skills/skills/qa-execution-observation/SKILL.md

qa-execution-observation

Skill31 starsChanged 48 days agoMITView on GitHub

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

The file

Create a free account to mount
Files
SKILL.md

⚠️ 本技能单独使用效果有限，建议配合完整技能集（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. 观察记录（每轮一份）

### 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%"绝对化表述

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free