测试人 Skill 全家桶 · 第①篇开篇我们说了AI 能写用例但写不出该测什么。 这一篇就上第一个技能需求拆解 → 测试点。给你完整 SKILL.md、裸问与用 Skill 的真实对比、以及怎么装进你自己的工具。一、先纠正一个误区漏测的根因90% 在需求阶段【贴图 01】很多人以为漏测是用例写得不够细。不是。测试点是要测哪些事用例是每件事怎么测。测试点漏了用例写得再漂亮也没用——因为根本没往那个方向想。那测试点为什么会漏因为我们读需求时是顺着读的需求写什么我们就测什么。但测试真正要做的是逆着拆——需求没写的、写模糊的、两条规则撞在一起的恰恰是风险最高、也最容易被漏掉的地方。【贴图 02】顺读靠人也会漏靠 AI 更会漏——因为 AI 的默认模式就是顺读。二、一个真实的漏测事故【贴图 03】事故优惠券叠加特价商品价格算错产生 P0 故障时间线需求评审 → 开发 → 测试写了 30 条用例 → 上线 → 客服反馈大面积价格错误复盘需求里只写了满 100 减 20“特价商品不参与”唯独没写特价商品算不算进满减基数根因测试点没有覆盖规则交叉两条规则撞在一起时怎么算和需求未明确项代价P0退款 补偿 口碑一句话总结漏的不是用例是该问的问题。而该问的问题能不能被逼出来取决于你给 AI 的清单够不够狠。三、同一个需求裸问 vs 用 Skill【贴图 04】需求节选电商平台满减优惠券——订单满 100 减 20有有效期每单限用一张特价商品不参与。裸问 AI 的输出5 条看着没毛病领取优惠券使用优惠券下单优惠券过期后不可用每单只能使用一张特价商品不能使用优惠券用「需求拆解 Skill」的输出节选|编号|维度|测试点|优先级|| — | — | — | — ||T02|边界值|订单金额 99.99 / 100.00 / 100.01 是否精确按 100 触发|P0||T04|规则交叉|购物车含特价 普通商品时特价是否计入满减基数|P0||T05|规则交叉|满减与会员价 / 积分抵扣能否叠加叠加顺序|P0||T07|并发时序|同用户多端同时领取是否超发|P0||T08|并发时序|同一张券并发下单是否被重复使用|P0||T10|逆向流程|用券下单后取消 / 退款券是否返还|P0||T11|数据一致性|券状态与订单状态是否强一致对账|P1||T14|依赖降级|券服务不可用时下单能否按原价降级|P1||…|…|共 40 条11 个维度|…||待确认|需求歧义|特价商品是否计入满减基数——需求未写明需产品确认|P0|【贴图 05】对比结论裸问3 个维度、5 条全在功能复述Skill11 个维度、40 条把规则交叉、并发、逆向、需求歧义这些高风险盲区逼了出来。【贴图 06】而整张表里最值钱的是最后那一行——它把一个上线才爆的雷提前到了评审阶段。四、这个 Skill 长什么样【贴图 07】设计三原则维度驱动而非功能驱动用固定检查清单逼 AI 逐维度发散而不是顺着需求读显式暴露不确定把需求没写清楚的地方当成产出的一部分而不是让 AI 脑补每条都可验证测试点必须带明确预期杜绝测试该功能是否正常这种空话。【贴图 08】核心资产就是这份 12 维度检查清单SKILL.md 的正文里1. 功能主流程2. 边界值金额/数量/长度/时间必须给具体数值3. 异常与容错4. 状态与流转状态机、非法跳转5. 并发与时序6. 数据构造/校验/一致性/对账7. 权限与安全8. 兼容性端/版本/时区9. 性能与容量10. 依赖与降级11. 逆向流程12. 埋点与日志配套的硬性规则防止 AI 脑补每个测试点必须有明确、可验证的预期结果必须显式列出待确认项 / 需求歧义不得用假设填补边界值必须给出具体数值不得写极大值“异常值”❌ 禁止测试该功能是否正常这类无法验证的空话五、怎么装进你自己的工具【贴图 09】拿到 SKILL.md 之后别急着扔进 skills 目录——有一条最容易踩的规则目录名必须等于 SKILL.md 里name字段的值。正确姿势以requirement-to-testpoints为例# Claude Code个人级mkdir-p~/.claude/skills/requirement-to-testpointscpSKILL.md ~/.claude/skills/requirement-to-testpoints/SKILL.md# 项目级跟仓库走团队共享mkdir-p.claude/skills/requirement-to-testpointscpSKILL.md .claude/skills/requirement-to-testpoints/SKILL.md用的时候直接说话就行「用 requirement-to-testpoints 拆解这段需求重点覆盖规则交叉和需求歧义」Cursor 要转成.cursor/rules/*.mdc没有 skill 机制的工具比如 Codex CLI、纯网页版把正文当系统提示贴进去只留检查清单 输出格式 硬性规则三段更省 token。六、落地效果 踩过的坑【贴图 10】效果团队自测仅供参考单个需求测试点30 → 78 条覆盖维度 3 → 11 个评审阶段发现的需求歧义2 → 9 个提前澄清显著减少返工上线后因规则交叉导致的回归缺陷下降约 40%四个坑一定要看AI 会编规则需求没写的它可能脑补成真的 → 所有待确认项必须拉产品当面确认优先级要自己校准AI 给的 P0 往往太多按你业务的资损权重重排测试点 ≠ 用例这只是要测什么还要补前置条件、步骤、数据才能执行就是下一篇别关掉待确认项输出那才是这个 Skill 最值钱的部分。 彩蛋公众号后台回复「skills」领取《测试人 Skill 全家桶》本文 SKILL.md 完整版 10 个 Skill 适配手册装哪个工具、怎么装、踩什么坑都写好了。下篇预告《用例设计不是填表格是练判断力》—— 测试点有了怎么把它变成真正有用的用例重点讲哪些用例值得留的判据以及一条用例只验证一个点为什么是硬规则。