测试用例设计进阶从能写好到能写精作者楠风测开 | 5 年测试工程师 | 上海 本文 3500 字 | 阅读 9 分钟 | 建议收藏 ⭐我刚做测试的时候写用例全靠拍脑袋说出来不怕你笑话我刚做测试那会儿写用例是真的拍脑袋。看到 PRD 上的登录功能我写了 3 条TC001 输入用户名密码 → 登录成功 TC002 用户名错 → 失败 TC003 密码错 → 失败就这 3 条我就敢说自己测完了。结果呢上线当天用户疯狂报 bug。我老大把我叫过去你写的这是啥用例3 条就测完了那一刻我才意识到写用例不是凑数是写防御工事。这个故事是我想跟你聊的起点。写用例这件事看起来简单做起来全是坑。今天我分享 5 个让我从 60 分跃到 95 分的关键技巧。技巧 1你是不是也在写假用例假用例是我见过最普遍的 3 个错误之一。假用例长什么样TC001 登录 → 系统正常 TC002 注册 → 系统正常 TC003 下单 → 系统正常我敢说写过测试用例的人80% 都写过这种假用例。包括我自己。假用例的 3 个特点❌ 预期结果是系统正常——什么是正常 ❌ 没有具体操作步骤——怎么做 ❌ 没有前置数据——用什么测这种用例评审的人看不懂执行的人不知道怎么做开发看了更懵。怎么写真用例改 3 个地方❌ 登录 → 系统正常 ✅ 输入 admin / 123456 → 跳转到首页显示用户名 admin ❌ 用户名错 → 失败 ✅ 输入不存在的用户名 → 提示用户名不存在 ❌ 密码错 → 失败 ✅ 密码连续输错 3 次 → 提示已锁定并跳转到忘记密码页判断标准别人看了你的用例能不能直接执行我做了 5 年测试最大的一个感受是用例不是给自己看的是写给团队看的。写得清楚别人才能用。技巧 27 种方法别背 99%要会组合Day 2 我讲了 7 种方法等价类、边界值、场景法、错误猜测、判定表、因果图、正交实验。很多新人爱问我应该先用哪种方法这个问题本身就问错了。正确的问题是我应该怎么组合实战案例登录功能我用一个真实例子带你走一遍 5 步组合法。Step 1等价类划分输入范围我打开 PRD看到用户名6-20 位字母数字 密码8-20 位我会立刻想到有效6-20 位 / 8-20 位 无效超长 / 含特殊字符 / 为空 / 全空格这一下就是 4 条用例。Step 2边界值测关键节点边界值我最关心的是 3 个点用户名5、6、20、21边界 1 密码7、8、20、21边界 1又是 8 条用例。Step 3场景法覆盖业务流程登录不只是登录还会做其他事登录成功 → 跳首页 登录失败 → 提示错误 连续输错 → 锁定账号 登录后刷新 → 还保持登录 登录后退出 → 状态清除又是 5 条。Step 4错误猜测补异常场景这一步最看经验。我会问自己- SQL 注入会怎么样 - XSS 攻击会怎么样 - 用户名含 emoji 会怎么样 - 密码超长100 位会怎么样 - 100 个用户同时登录会怎么样又是 5 条。Step 5判定表覆盖条件组合用户名错、密码错、验证码错3 个条件错组合 16 种情况。我一开始觉得太繁琐后来发现——这种条件组合开发最爱挑刺。提前测完省事。5 步组合后的用例数等价类4 条 边界值8 条 场景法5 条 错误猜测5 条 判定表16 条 合计38 条对比1 个功能 1 条用例用例数提升 38 倍。这就是 7 种方法组合用的威力。技巧 3测试数据决定用例质量很多人写用例只关注测什么忽略用什么测。测试数据不对再多的用例也没用。我自己吃过这个亏有一次我测删除订单功能我的用例是TC001 删除订单 → 删除成功结果开发说订单不存在时怎么办订单已删除时怎么办订单属于其他用户时怎么办我一脸懵。后来我学会了——测试数据要覆盖 3 个原则1. 覆盖所有等价类有效 无效都要有 2. 覆盖边界值上点 离点 内点 3. 考虑数据依赖存在/不存在/权限/状态数据设计不是技术活是业务理解 经验。技巧 4让你的用例能用 100 次我见过很多团队的用例库写完就扔。下次类似功能重新写一遍。5 年下来团队用例库 0 增长。我自己的做法是——把用例当资产不是作业。我用的 4 个做法做法 1模板化TC_功能_编号_场景 示例TC_LOGIN_001_正常登录为什么搜得到、改得快、复用方便。我团队用了这套模板新人入职 2 天就能上手写用例。做法 2分层组织用例库/ ├── 用户模块/ │ ├── 登录/ │ └── 注册/ ├── 订单模块/ │ ├── 创建订单/ │ └── 支付订单/为什么一个模块出了问题只影响这一块不会牵连整个库。做法 3参数化反例 TC001 用户名 admin 密码 123456 → 登录成功 TC002 用户名 admin 密码 1234567 → 登录失败 正例 TC{user}_{pwd} → 期望结果 TC_ADMIN_123456 → 登录成功 TC_ADMIN_1234567 → 登录失败为什么换数据不换用例自动化脚本可以直接复用。做法 4版本管理v1.0基础版20 条 v1.1补充异常场景10 条 v2.0重大重构重写为什么变更可追溯争议有依据。技巧 5写用例 vs 设计用例5 年下来我最大的感受是——测试工程师分 3 个层次层次 1写用例60 分 层次 2评审用例80 分 层次 3设计用例95 分你在哪一层层次 1写用例能用 7 种方法 1 个功能写 10-20 条用例 用例能用但评审被打回层次 2评审用例能 review 别人的用例 能发现漏掉的场景 用例覆盖率达到 80%层次 3设计用例能设计整套测试体系 能从业务出发设计用例 用例覆盖率 95% 团队测试 leader怎么从 60 分到 95 分5 个能力要补1. 业务建模能力能画出业务流程图 2. 风险评估能力能给用例排优先级 3. 复用设计能力能设计通用用例库 4. 自动化转换能力能把用例转脚本 5. 质量度量能力能度量用例覆盖率我自己就是从层次 1 一路走到层次 3 的每个能力都是踩坑踩出来的。实战案例从 60 分到 95 分的转变第 1 年60 分写用例全靠拍脑袋1 个功能 3 条用例完事。第 2 年75 分学了 7 种方法但每种方法单独用用例数上去了但质量没跟上。第 3 年85 分学会 7 种方法组合用开始做测试数据设计。第 4 年90 分开始做业务建模能从流程图倒推用例。第 5 年95 分开始设计整套测试体系把用例变成可复用资产。AI 怎么帮你2026 年的实战工作流最后一个环节——AI 怎么用。2026 年 AI 工具已经很成熟了我最推荐的工作流是 Dify。为什么用 Dify因为它能搭一条用例生成流水线可视化、不写代码。Dify 工作流4 步 ① 输入 PRD ② AI 标准化需求 ③ AI 生成测试用例 ④ AI 补充异常场景 ⑤ 输出完整用例集一次搭建永久使用。团队共享。我的实际工作流Step 1搭工作流Dify1 小时一次性 Step 2日常使用Dify5 分钟 Step 3批量优化Cursor 2 / Trae Step 4复杂任务Claude Code2026 年常用的 5 款工具工具类型适合DifyAI 工作流平台搭用例流水线 ⭐Cursor 2AI IDE临时任务Claude CodeCLI复杂任务Trae字节AI IDE中文免费Coze扣子AI Agent团队共享真实提效数据传统手写 1 个项目10 个功能 - 10 小时 - 60-80 条用例 AI 工作流 1 个项目 - 1 小时 - 100-150 条用例 提效10 倍 质量覆盖率 30%AI 不能做什么❌ 复杂业务逻辑金融、医疗 ❌ 历史问题回归特定版本修过的 bug ❌ 性能 / 安全测试需要专业工具核心认知AI 是加速器不是替代者。写在最后写用例这件事没那么难做了 5 年测试我最大的感受是——写用例这件事80% 的人没入门15% 的人入门了只有 5% 的人做到了极致。如果你现在还是 60 分别慌。按我说的 5 个技巧慢慢打磨今天找 1 个你之前写的用例看看是不是假用例 本周选 1 个功能用 7 种方法组合重写 90 天建立你的用例库1 年后回头看你会发现自己进步巨大。下期预告Day 8测试工程师的 AI 工作流设计实战 - 4 种工作流模板用例 / Bug / 报告 / 日志 - 让你的测试效率翻倍如果这篇文章对你有帮助点赞 收藏建议收藏评论区告诉我你在哪个层次转发给同样写用例的同行全文 3500 字 | 阅读 9 分钟 | 建议收藏【原创声明】本文为楠风测开原创转载请联系作者授权。