返回技能市场
Execution Observation
当测试新人不知道执行时应该关注什么、或者有经验的测试发现"执行完了但好像什么都没发现"时使用此技能。测试执行不是"按步骤操作看结果"——你需要同时关注功能表现、接口响应、日志报错、UI 渲染、数据一致性、性能指标六路信号。大多数的 Bug 是被"不小心看到"的而非被测出来的。每轮执行后输出观察记录，标注异常信号和后续需要跟进的问题。 ⚠️ 本技能示例可能调用外部监控/截图工具，请在受控环境执行。
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. 最容易犯的两个错
- 把环境问题当缺陷提 → 缺陷库被污染，团队开始不信缺陷单
- 把缺陷当环境问题放过 → 线上事故
分流规则：看错误栈最深处服务名。是环境 → 记 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%"绝对化表述
评论与讨论
0/2000
还没有评论，分享你的体验吧。