说起测试用例这四个字圈外人很容易把它理解成一件写文档的活儿需求评审完了照着功能点把步骤列一列填上预期结果一个用例就算完成了。我见过不少刚入行的测试同学一天能写出几十条用例结果评审时被开发反问两句就卡住——这条用例你设计出来是想发现什么问题需求里那个例外分支你为什么完全没想到之所以会这样根本原因是把设计测试用例当成了记录功能说明而不是把它当作一次实打实的工程决策。这篇内容我想聊透的就是设计这两个字。它到底在设计什么、有哪些能直接上手的方法组合、怎么从业务需求里挖出容易被漏掉的规则、一个用例该检查几项、以及现在AI能帮你做到哪一步。这套思路不只是用来交差它决定着你最终是测了还是测到位了。无论你是刚转行的测试新人还是做了几年却总觉得用例设计靠感觉的人这篇都值得花十分钟看完。1. 先想清楚测试用例到底在设计什么1.1 写用例和设计用例是两种完全不同的姿势很多人开工第一件事就是把PRD打开对着功能列表一行一行翻译成用例。这个动作本身没什么大错但它只是覆盖了需求并没有真正回答一个问题这些用例合在一起能不能用最合理的成本把缺陷拦住。我习惯把用例设计理解成一份抽样计划。一个功能点的输入空间、数据状态、操作顺序排列组合起来往往是几十万甚至几百万种可能。人力和时间有限我们不可能全测也不该全测。用例设计就是在这片巨大的空间里选出最有代表性的样本用最小代价覆盖最大的风险。如果你始终抱着把所有功能点都列成用例就算完成任务的心态那测出来的结果是可预期的正常路径全绿异常路径随缘。而线上出问题恰恰绝大多数都发生在你没想到的地方。1.2 用例的本质把输入空间、环境状态和操作路径压缩成有限样本我之前带新人时常用一个类比体检不会把人体内所有指标都查一遍而是根据年龄、性别、家族史挑出最关键的项目组合用一套合理方案筛出绝大多数潜在风险。测试用例就是软件的体检套餐——它不是功能的复述而是对可能会出问题的地方做的一次有条理的排查。具体到软件测试我们要覆盖的空间有三个维度输入空间参数值、字段长度、类型、组合关系数据状态空间前置状态新建、待审核、已生效、已失效、库存余量、账户余额操作路径空间正常流程、分支流程、异常回退、重复操作、并发操作设计用例时每个用例都应该能回答出它在哪个空间里采样、采这个样是为了验证什么。如果一条用例连自己为什么存在都说不清那这条用例多半是凑数的。1.3 判断一套用例好不好的三个客观维度我平时评审用例不会只看数量够不够而是盯着三个维度维度弱用例的表现强用例的表现有效性大量用例永远通过测完说不出新信息每条用例都有明确的失败理由和风险点效率写了几百条执行和回归成本极高用几十条用例换回高缺陷发现率可维护性需求一改用例大面积重写需求变更时只需改少量关联用例有效性是最容易被忽视的。很多团队用例库动辄上千条实际跑起来却根本发现不了缺陷原因就是大量用例在验证功能正常工作而没有去挑战功能的脆弱点。设计用例时多问一句这条用例如果失败了能说明程序哪里有问题问不出来的慎重放进去。2. 三个方法别当成模板套等价类、边界值、场景法怎么组合2.1 等价类划分先学会分类才能学会偷懒等价类的基本思想不复杂把数不清的输入数据按程序是否用同一套逻辑处理分成几个子集每个子集里只取一个代表值来测。关键是这个同一套逻辑四个字。我见过很多用例把用户名分成中文、英文、数字、特殊字符来测这其实是按外观分不是按处理逻辑分。如果程序里的校验正则只允许字母和数字那么在程序眼里abc和xyz123是同一类你测十个看起来不同的合法值效果和测一个完全一样。正确的做法是先搞清楚程序的分支条件。比如一个注册接口用户名长度为6到20位包含字母数字下划线那么有效等价类是6到20位且字符合法无效等价类包括太短太长含非法字符为空。每个类里抽一个代表值即可没必要穷举。特别提醒无效等价类不是随便挑几个不合理值就行它是异常分支能否被正确触发、错误提示是否准确的关键验证。很多线上事故恰恰是因为开发没拦住一个特别不该出现的输入而用例里恰好没测这个无效类。2.2 边界值缺陷最爱的藏身地就是临界点边界值为什么值得单独拿出来强调因为开发在写判断条件时最常犯的错误就是差一个数。用大于还是大于等于、数组下标从0还是从1开始、日期比较按哪一天的零点算这些边界的偏差在代码review时肉眼很难发现但一跑用例就会现出原形。实际操作时我会把等价类和边界值绑在一起用。比如密码长度为6到20位这个需求有效等价类是6到20位无效等价类分别是小于6位和大于20位那边界值就要取5、6、7和19、20、21这六个数。取5验证低于下限被拦截取6验证下限本身合法取20验证上限合法取21验证超过上限被拦截中间的7和19是正常值用于确认边界内功能稳定。这里还有个细节闭区间和开区间。促销规则写满300减50到底订单金额刚好300能不能用优惠券不同产品可能有不同的定义设计用例前必须确认清楚然后在300这个点上分别设计刚好达标和差一分不达标两条用例两边的预期结果必须都能在需求里找到依据。2.3 场景法用户是按流程用产品的不是按功能清单用的等价类和边界值再熟练也只能解决单个输入正不正确的问题。用户真实使用时是沿着一条操作流程往前的中间某个环节失败了系统要能给出合理的下一步出口。场景法就是干这个的。我常用的做法是把一个业务场景拆成三类路径主路径基本流用户按最顺畅的方式完成核心目标备选路径备选流在主路径上换一种方式达成目标异常路径中途出现错误、中断、超时、重复操作时系统怎么处理拿登录来说主路径是输入正确账号密码进入首页备选路径可以是忘记密码后重设再登录第三方授权登录异常路径包括密码连续错误触发锁定验证码过期会话超时后点击登录。场景法最大的价值是把零散用例串成了故事执行起来更贴近真实使用也更容易发现单个功能都对但串起来就出问题的集成缺陷。2.4 三者怎么组合登录模块的一次完整拆解很多人学了一堆方法到真正动手时依然不知道先取哪个。我的习惯是先用场景法搭骨架再用等价类和边界值填血肉。以一个带用户名、密码、验证码的登录接口为例先用场景法定主流程正确凭据登录成功再用场景法定分支验证码错误、密码错误、账号锁定、找回密码后登录对每个字段做等价类划分用户名是否为空、是否含非法字符、是否存在密码是否为空、长度是否在限制内验证码是否正确、是否过期对长度类限制取边界值比如密码6到20位取5/6/7/19/20/21对状态类数据补充特殊值禁用账号、未激活账号、已删除账号这样一套下来用例既有结构又有颗粒度。如果条件组合特别多比如三个条件各有三种取值组合起来27种全测太浪费我会再引入判定表或正交试验法挑出覆盖全部单因素和关键组合的最小集合。方法永远是为用最少的用例发现最多问题服务的不是为了凑美感。3. 拿商城下单接口练一遍完整设计流程3.1 从PRD里挖出隐藏规则需求文档永远不会把真相全写出来商城接口测试用例是很多人面试和实际工作中会碰到的题目我拿创建订单接口来做完整示范。单看这个接口的名字新手往往只想到选好商品、点提交、生成订单这三板斧。但真实场景里这个接口背后至少压着六条业务规则用户必须是已登录且账号状态正常的商品必须处于上架状态下单数量不能超过库存可售数量订单金额要经过商品单价、数量、优惠券的完整计算优惠券使用有门槛和有效期限制同样的请求重复提交不能生成重复订单幂等性这些规则里前几条PRD会写最后一条幂等性就经常被漏掉。可现实里用户手抖点了两下提交、或者接口超时后前端自动重试后端如果没做幂等处理就会产生两个订单。这种缺陷一旦上线造成的客诉和财务对账问题非常麻烦。3.2 把接口入参拆成字段维度表我接到接口文档后习惯先把入参全部列出来逐字段标注数据类型、是否必填、长度/取值范围、业务约束。比如下单接口的入参可能是这样字段类型约束需要重点考虑的测试点userIdLong必填已登录用户不存在、已注销、未登录skuIdLong必填商品标识不存在、已下架、已删除quantityInteger必填正整数0、负数、超库存、超单笔上限couponIdLong非必填不存在、已过期、不满足门槛、已使用addressIdLong必填收货地址不存在、地址非本用户remarkString非必填限200字超长、空字符串、特殊字符字段拆完之后我要单独做一张字段-方法对应表把等价类、边界值、异常值贴到每个字段上避免遗漏。这张表不用太复杂但它是后续生成用例清单的底稿。3.3 业务规则转用例库存和幂等是重头戏字段级别的用例只能防参数异常真正体现设计水平的是把业务规则翻译成用例。以库存为例假设某SKU当前可售库存是10件下单数量的测试用例至少要有这几条购买1件正常成功库存变9购买10件刚好等于库存成功购买11件超库存提示库存不足并拦截下单并发下同时购买10件和1件验证不会超卖幂等性这边我会准备一个固定的请求体在第一遍发送成功后用完全相同的请求体再发一次。预期结果是第二次请求返回订单已存在或者直接返回第一次的订单号数据库中订单表只有一条记录。这个用例我建议放在P0优先级因为它直接关系资金安全。优惠券门槛也是典型的边界值场景。规定满100元减20元就要测订单金额正好100元、99.99元、100.01元三档分别验证优惠券是否可用、最终实付金额是否正确。99元和100元的差别恰恰是用户最容易投诉、开发最容易用浮点数精度算出问题的地方。3.4 一套可直接参考的下单接口用例清单为了更直观我按一个简化场景给出一组可落地的用例清单SKU A单价50元库存10件用户有一张满100减20的优惠券收货地址已配置。这里列出核心用例| 用例编号 | 用例描述 | 优先级 | 前置条件 | 操作步骤要点 | 预期结果 | | --- | --- | --- | --- | --- | | TC-01 | 正常下单2件 | P0 | 库存10件 | 用优惠券下单2件 | 下单成功生成订单金额80元库存余8 | | TC-02 | 优惠券门槛临界 | P0 | 库存10件 | 购买2件金额恰好100 | 优惠券可用实付80元 | | TC-03 | 门槛差一分 | P1 | 库存10件 | 购买1件金额50 | 优惠券不可用实付50元 | | TC-04 | 库存刚好临界 | P0 | 库存10件 | 下单10件 | 下单成功库存归零 | | TC-05 | 超库存拦截 | P0 | 库存10件 | 下单11件 | 返回库存不足不创建订单 | | TC-06 | 重复提交幂等 | P0 | 库存足够 | 同一请求体发送两次 | 第二次提示重复订单仅一条 | | TC-07 | 非法数量 | P1 | 库存足够 | quantity传0或负数 | 参数校验报错不创建订单 | | TC-08 | SKU不存在 | P1 | 无 | skuId传随机不存在值 | 返回商品不存在不创建订单 | | TC-09 | 商品已下架 | P1 | 商品下架 | 对下架SKU下单 | 返回不可购买不创建订单 | | TC-10 | 优惠券已使用 | P1 | 券已核销 | 用已用券下单 | 返回券不可用不创建订单 | | TC-11 | 未登录调用 | P1 | 无登录态 | 不带token调用下单 | 返回未授权不创建订单 | | TC-12 | 备注超长 | P2 | 库存足够 | remark传201个字符 | 返回参数校验错误 |注意这套用例里我刻意把库存不足重复提交优惠券门槛放到P0因为这三类问题一旦出线上事故影响的是钱和信任优先级必须最高。3.5 断言设计怎么判断一条用例到底过还是没过接口测试里最常见的断言失误是只看返回里的success字段。我踩过这类线返回成功但订单实际没建上的情况真实存在。现在我做断言至少分三层第一层响应断言。检查HTTP状态码、业务码、返回体里的订单ID、金额等关键字段。第二层数据断言。查库确认订单表真实插入了记录库存表扣减数量正确优惠券状态从未使用变为已使用。第三层下游状态断言。如果下单后要发消息或写流水需要确认消息已投递、流水已落库。一句话总结下单接口的预期结果不是下单成功而是订单、库存、优惠券、流水四方数据全部一致。把预期结果写细一点执行时才能一眼看出到底哪里不对。4. 一个用例最多检查几项别在这个问题上内耗4.1 一个用例只验证一件事这句话得分场景听在测试社区里流传很广的一个说法是一条用例只能有一个断言。这句话本身没有错但很多人在接口测试、端到端测试里也机械执行结果用例数量爆炸维护成本高到团队想哭。我的理解是这句话主要适用于单元测试和接口测试中的最小失败定位场景。一个单元函数当然希望一个用例只验证一个表现失败了能立刻定位到是哪行代码出的问题。但到了端到端场景比如用户完成下单并支付成功这一个用例本身就要经历多点校验订单金额对不对、支付状态有没有更新、优惠券有没有核销。硬拆成三个用例反而破坏了业务完整性前置条件和数据准备都要重复做三遍。4.2 用例粒度过细和过粗分别是两种灾难用例拆太细最直接的后果是数量膨胀。一个登录功能拆出五十条用例执行十分钟维护两小时因为前端文案改一个字所有引用这个文案的用例预期结果都要跟着改。更麻烦的是很多细粒度用例之间共用了公共步骤一旦前置步骤失败后面一串用例全部报障排查时还得从第一条开始看效率极低。用例写太粗问题同样严重。预期结果里写一句页面正常展示执行时看到页面乱码都说不清这算不算失败失败后也找不到是哪个环节出的问题只能重新手工复跑一遍去定位。这种用例只比没有稍好那么一点。4.3 我判断一条用例是否需要拆分的三个信号我平时不会去死记最多检查几项而是靠三个信号来决策信号一预期结果里的独立检查点超过4个。如果一条用例的预期结果列了五六条而且这些检查点分属不同的模块或系统那就拆。比如下单成功、库存减、券核销、消息发送这四点属于四个层面可以拆成一条接口结果用例、一条数据一致性用例。信号二用例存在多个前置分支。比如如果用户是新用户则走A逻辑如果是老用户则走B逻辑这种时候直接拆成两条独立用例因为执行路径完全不同合成一条只会让失败时的信息变得含混。信号三执行失败时无法快速定位。你可以自问一句这条用例红了我能在半分钟内说出大概卡在哪个环节吗说不出来就是太粗了。反过来如果一条用例只是断言点多但都集中在同一个业务闭环里合并着写完全没问题。4.4 落到团队里的执行建议结合这几年的实操我现在的原则是单元测试和接口测试倾向一个用例一个主检查点把定位成本降到最低端到端业务场景允许一条用例包含三到五个检查点但必须保证这些检查点同属一条主流程且每个检查点都有明确的数据可验证。我还会在用例模板里加一列验证目的一句话说明这条用例到底想发现什么问题。这一列看起来不起眼但在用例评审时非常有用——评审员一眼就能看出哪些用例是凑数的哪些用例是真正有风险针对性的。如果你所在团队还在用条数考核测试工作量我建议尽早把指标换成高风险覆盖数和缺陷发现数这样用例设计才会往高质量方向走。5. AI能帮你写用例但设计决策还得自己拍板5.1 现在的AI写测试用例到底靠不靠谱AI根据PRD生成测试用例这个词最近热得很我也在团队里实际试过几轮。结论是AI完全能用但智商取决于你喂它的信息质量和期望值管理。把一份结构完整的PRD和接口字段说明贴给AI它能很快产出一版覆盖正常路径、常见边界、基础异常场景的用例表格格式规整命名也规范。对于新人或者刚接手的模块这个初稿能省掉两三个小时的机械劳动非常值。但如果指望AI看完一段模糊的需求描述就能自动挖出重复提交会创建两个订单这种隐患那还不现实。它不了解你们系统的历史缺陷也不了解业务上的潜在资金风险。坦诚地说AI现在更像一个非常勤奋但缺乏经验的实习生。它能帮你把框架撑起来但哪里要加权重风险用例、哪条业务规则和另一条规则之间存在隐性冲突这些判断还是要人来定。5.2 我实测好用的AI生成用例Prompt写法很多人用AI生成用例效果差问题大多出在提问方式上。直接甩一句帮我写测试用例得到的当然是一堆正确的废话。我常用的套路是把需求上下文、字段定义、输出要求拆开喂给它。下面是我实测过几轮、产出质量比较稳定的Prompt模板你可以直接抄走你是一名资深测试工程师请根据以下需求设计测试用例。 【需求描述】 这里粘贴PRD中对该功能的描述 【接口定义】 粘贴接口文档中的入参字段、类型、约束、返回码说明 【补充说明】 1. 库存为10件优惠券满100减20要求并发和幂等场景必须覆盖 2. 用户未登录、商品下架、优惠券已使用等异常场景必须覆盖 【输出要求】 1. 用Markdown表格输出用例编号、用例描述、优先级、前置条件、操作步骤、预期结果 2. 每条用例请标注使用的设计方法等价类/边界值/场景法/错误推测 3. 优先输出P0高风险用例再补充P1/P2用这个模板生成完之后我会把返回的表格复制到用例管理工具里然后做两件事一是逐条审查预期结果看有没有含糊的正常返回显示正确这类表述二是打开自己的历史缺陷库把最近半年在这个模块上踩过的坑对照一遍缺的用例补上。5.3 哪些环节AI做到不到位经验和技术债是最后一道防线我试过的AI模型里普遍薄弱的环节有三个业务约束推导。比如优惠券不能和秒杀活动叠加白名单用户才能看到这个商品这类需要结合业务上下文才能推导出的规则AI经常漏。历史缺陷模式。你们这个系统曾经因为浮点数精度、时区转换、字符集出过什么事故AI完全不知道。它生成的用例里自然不会针对这些前科做特判。跨系统数据流转。下单涉及订单、库存、优惠券、支付、物流多个系统AI往往只盯着当前接口忽略了数据一致性的检查项。所以我现在的定位很明确AI出初稿我做设计决策最后再用反向问题验收比如拿生成的用例去逐条反问缺陷是什么答不上来的就删。这个流程走顺之后用例设计速度大约能提升三到四成质量不降反升。5.4 用例工程化从写用例到用例即资产顺着AI出现行业里harness工程化这个词被频繁提起。这类工具能做的事包括自动加载用例定义、生成接口测试脚本、跑完自动产出报告甚至把代码变更和用例执行关联起来再做一轮自动Review。本质上测试用例正在从一份给人看的文档变成一套可被机器执行的资产。这意味着用例的写法也要同步变化字段要结构化步骤要能还原成可调用的数据预期结果要能对应到具体的断言表达式。AI生成用例之所以有价值也正是因为它天然倾向结构化输出可以直接喂给harness用。但不管工具链怎么升级最初用例设计的决策环节——选哪些场景、按什么优先级、如何权衡投入产出——依然是最值钱的部分。工具可以帮你把用例跑起来但跑什么、为什么跑得你说了算。5.5 我现在的完整实操流程供你参考最后分享一下我目前在团队里用的流程不见得多高级但每一步都有明确产出需求拆解把PRD和接口文档过一遍列出所有业务规则和字段约束AI初稿用上面的Prompt模板生成首版用例作为草稿底稿人工评审对着历史缺陷库和业务经验补重点风险用例删掉无意义用例结构化入库把用例字段整理成可导入管理工具的格式确保能被后续工程化利用执行复盘每轮测试结束后把新发现的缺陷补进用例库并反向标注它是用哪种方法挖出来的持续积累团队的设计经验这几步做完用例库才不是一潭死水而是越用越懂这个系统的活资产。设计测试用例这件事越往后做越能体会到它考验的根本不是会不会用方法而是有没有判断力。方法学三天就会判断力要靠一次次踩坑、复盘、再试验才能沉淀下来。我到现在还保留着一个习惯拿到新需求时先不急着列用例而是先单独写一句话——这个需求最可能在哪个环节出问题然后才开始设计。你也不妨试一次大概率会发现顺着这句话展开的用例比照着PRD平铺出来的用例有用得多。
