企业官网建设流程全解析

测试人 Skill 全家桶 · 第①篇

开篇我们说了：AI 能写用例，但写不出"该测什么"。 这一篇就上第一个技能：需求拆解 → 测试点。给你完整 SKILL.md、裸问与用 Skill 的真实对比、以及怎么装进你自己的工具。

一、先纠正一个误区：漏测的根因，90% 在需求阶段

【贴图 01】

很多人以为漏测是"用例写得不够细"。不是。

测试点是"要测哪些事"，用例是"每件事怎么测"。测试点漏了，用例写得再漂亮也没用——因为根本没往那个方向想。

那测试点为什么会漏？

因为我们读需求时是顺着读的：需求写什么，我们就测什么。

但测试真正要做的，是逆着拆——需求没写的、写模糊的、两条规则撞在一起的，恰恰是风险最高、也最容易被漏掉的地方。

【贴图 02】

顺读靠人也会漏，靠 AI 更会漏——因为 AI 的默认模式就是"顺读"。

二、一个真实的漏测事故

【贴图 03】

• 事故

  ：优惠券叠加特价商品，价格算错，产生 P0 故障

• 时间线

  ：需求评审 → 开发 → 测试写了 30 条用例 → 上线 → 客服反馈大面积价格错误

• 复盘

  ：需求里只写了"满 100 减 20"“特价商品不参与”，唯独没写：特价商品算不算进满减基数

• 根因

  ：测试点没有覆盖"规则交叉"（两条规则撞在一起时怎么算）和"需求未明确项"

• 代价

  ：P0，退款 + 补偿 + 口碑

一句话总结：

漏的不是用例，是"该问的问题"。

而"该问的问题"能不能被逼出来，取决于你给 AI 的清单够不够狠。

三、同一个需求，裸问 vs 用 Skill

【贴图 04】

需求（节选）：电商平台"满减优惠券"——订单满 100 减 20，有有效期，每单限用一张，特价商品不参与。

裸问 AI 的输出（5 条，看着没毛病）

1. 领取优惠券

2. 使用优惠券下单

3. 优惠券过期后不可用

4. 每单只能使用一张

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 条，全在"功能复述"；

• Skill：11 个维度、40+ 条，把"规则交叉、并发、逆向、需求歧义"这些高风险盲区逼了出来。

【贴图 06】

而整张表里最值钱的，是最后那一行——它把一个上线才爆的雷，提前到了评审阶段。

四、这个 Skill 长什么样

【贴图 07】

设计三原则：

1. 维度驱动，而非功能驱动

   ：用固定检查清单逼 AI 逐维度发散，而不是顺着需求读；

2. 显式暴露"不确定"

   ：把"需求没写清楚的地方"当成产出的一部分，而不是让 AI 脑补；

3. 每条都可验证

   ：测试点必须带明确预期，杜绝"测试该功能是否正常"这种空话。

【贴图 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%

四个坑（一定要看）：

1. AI 会"编规则"

   ：需求没写的，它可能脑补成真的 → 所有"待确认项"必须拉产品当面确认；

2. 优先级要自己校准

   ：AI 给的 P0 往往太多，按你业务的资损权重重排；

3. 测试点 ≠ 用例

   ：这只是"要测什么"，还要补前置条件、步骤、数据才能执行（就是下一篇）；

4. 别关掉"待确认项"输出

   ：那才是这个 Skill 最值钱的部分。

🎁 彩蛋公众号后台回复「skills」，领取《测试人 Skill 全家桶》：本文 SKILL.md 完整版 + 10 个 Skill +适配手册（装哪个工具、怎么装、踩什么坑，都写好了）。

下篇预告：《用例设计不是填表格，是练判断力》—— 测试点有了，怎么把它变成"真正有用"的用例？重点讲"哪些用例值得留"的判据，以及"一条用例只验证一个点"为什么是硬规则。