1. 需求拆解用例设计的真正起点不是点开word套模板很多同学问我用例设计最难的地方在哪我一般会反问一句你接到任务之后是先打开模板还是先看需求如果你的手指下意识点了“新建用例”的按钮那这篇文章正好可以帮你把节奏慢下来。用例设计做得烂通常不是因为没有方法而是因为需求没吃透。等价类、边界值、判定表都是后面的招式内功是需求拆解。你连被测对象要解决什么业务问题都没搞清楚谈用例设计就是空中楼阁。我见过不少人一个订单功能用例写了200条结果需求里明确要求的“超时未支付自动取消”漏测了。你说他是不会边界值吗不是他是压根没把需求当回事。1.1 用例设计的上游把需求翻译成可以验证的东西需求文档、原型图、接口文档、产品口头补充这些都是用例设计的输入。但输入不等于结论你需要先做一次“翻译”。比如需求里写“用户登录后进入首页”这句话本身不可测试。你需要继续追问登录成功是什么表现登录失败提示什么连续输错密码有没有限制记住密码功能到底是记住用户名还是记住账号密码这些追问汇总起来才是可测试的需求实体。在团队里我习惯用一张自查表来清点需求信息核心就这几项功能角色是谁普通用户、管理员、商户不同角色行为是否不同。数据从哪里来用户输入、系统计算、第三方回调数据来源决定校验策略。异常情况有哪些网络中断、数据超时、库存不足、重复提交。业务规则是什么比如折扣叠加、库存扣减顺序、积分抵扣上限。交互约束有哪些字数限制、格式限制、频次限制。把这些信息列出来之后用例的雏形其实已经出来了。比如电商下单你至少能推导出普通用户和会员看到的价格不同优惠券和满减到底能不能叠加下单后库存是锁了还是扣了支付超时会不会释放库存重复点击提交会不会产生两笔订单。这些点都不是面试题里背出来的而是把需求翻来覆去嚼碎之后自然长出来的。还有一个很关键的动作把你不确定的东西明确标出来。不清楚库存是“扣减”还是“锁定”那就写“待确认”拉着产品和技术对齐。用例评审时最尴尬的不是你漏写了用例而是你对着一个自己都没弄明白的功能写了一堆想当然的步骤。1.2 用业务场景串联需求而不是按页面机械拆分这里我想多说一句很多新人的用例设计方式是按页面走的登录页写一批首页写一批个人中心写一批。这样不是不行但容易把一个完整业务流程拆得七零八落。真正有价值的用例应该是按业务场景串联起来的。比如“用户下单”这个场景它会跨越商品列表页、商品详情页、购物车、确认订单页、支付页、订单列表页甚至还包括后台的库存扣减、订单状态变更、发券脚本。如果按页面拆分你很难发现“购物车里的商品已被后台下架用户仍能提交订单”这种跨页面的逻辑漏洞。所以我在具体设计之前会先画一条主流程线登录—搜索—加购—提交订单—在线支付—查看订单状态。这条线上的每一个节点再去做分支和异常展开。这样做还有一个额外收益用例能直接对应到端到端的业务验收。你拿着一组场景用例去执行一遍基本就敢跟产品说“这个版本的核心流程是通的”。而按页面拆出来的用例可能每一页都通过但用户实际操作一圈下来却卡住了这种测试是自欺欺人。2. 用例的完整骨架写不齐要素后面所有工作都会塌需求拆解完之后才进入真正的用例编写阶段。很多新人觉得用例就是“操作步骤预期结果”但从工作流的角度看这不是你一个人的笔记而是给团队、给自动化脚本、给后续复盘看的一份正式文档。要素写不齐后面所有工作都会塌。2.1 一条能直接落地的用例至少包含十个字段我先把我日常使用的用例模板字段列出来你可以直接抄作业字段说明示例值用例编号全局唯一按模块编码TC_LOGIN_001所属模块被测功能模块登录前置条件执行前必须满足的状态已安装App未登录测试步骤可执行的完整操作序列1.打开登录页 2.输入手机号 3.输入密码 4.点击登录按钮测试数据执行步骤使用的数据手机号138xxxx1234密码123456预期结果每一步或最终可观察的结果登录成功跳转首页显示用户昵称优先级P0/P1/P2/P3P1实际结果执行后填写与预期一致关联需求标明来源REQ-2024-0312执行时间/执行人可追溯性2024-06-01/张三这里我特别强调两个经常被敷衍的字段。第一个是前置条件。前置条件不写清楚用例执行就是耍流氓。比如你测支付功能前置条件是“存在一笔待支付订单”你没写结果执行的人发现页面上压根没有支付入口他只能自己随便造数据那用例的规范性就形同虚设了。第二个是测试数据。如果你只写“输入有效的手机号和密码”执行的人还得自己想一个手机号每次都不同结果团队内无法复现。好的做法是把数据写死手机号13800001111密码Test1234就算执行人换了一拨结果依然可复现。2.2 优先级排序不是所有用例都值得同等待遇用例数量一旦多起来执行阶段最大的矛盾就是“时间不够”。一个版本的回归测试可能只有两三天几百条用例根本跑不完。所以从设计阶段就得分出优先级我比较习惯用P0到P3四级P0主流程、核心功能、用户最常用路径一旦失败直接阻断发版。P1重要功能但存在替代方案失败影响较大但不完全阻断。P2一般功能、边界场景、非主路径。P3极低概率场景、兼容性细节、文案类验证。优先级谁来定不是测试自己拍脑袋而是测试、产品、开发一起定。你设计完用例后拉一个评审会把每条用例过一遍大家现场确认优先级。尤其要盯住的是P0P0用例不是用例是发版门槛。新版本手工测试时间再紧P0也必须全部跑完。2.3 用例编号和组织结构提前为自动化留后路还有一个容易被忽视的问题是编号规则。用例编号不只是为了好看它的核心价值是建立关联和自动化的数据来源。比如我的常用规则是“模块缩写_场景_三位序号”登录模块就是TC_LOGIN_SUCCESS_001、TC_LOGIN_PWD_ERR_002。这样一看编号就知道测的是登录成功还是密码错误不用展开详情。有些团队会用一个Excel表格把所有用例堆在一个sheet里几百条用例看起来密密麻麻查询和筛选都不方便。我更推荐按模块拆sheet或者用禅道、TAPD这类项目管理工具来管理用例。至于更具体的管理细节后面讲维护时会展开。3. 经典设计方法的正确打开方式不是背公式是组合拳到了最核心的部分——用例设计方法。等价类、边界值、决策表、状态迁移、场景法这些名词你应该都听过但我必须泼一盆冷水如果只会背定义用例设计依然是废的。工作里真正好用的从来不是单一方法而是根据业务逻辑自由组合。3.1 等价类划分先做数据判别再追求覆盖效率等价类划分的核心思想是把你无穷无尽的测试数据分成若干个“性质相同”的组从每组里面挑一个代表数据去测。拿最经典的注册功能举例用户名字段要求“6到20个字符只能包含字母、数字、下划线”。按等价类的逻辑划分有效等价类6个字符、20个字符、字母数字下划线组合。无效等价类5个字符、21个字符、包含中文、包含空格、纯数字超长、空值。这里建议把有效等价类和无效等价类分别列出来有效等价类保证功能可用无效等价类保证异常被正确拦截。但等价类有个缺点它不关注边界。6到20个字符你只测6和20会漏掉“7个字符是否正常”这种边界附近的波动。所以等价类通常要搭配边界值一起用。3.2 边界值分析缺陷最密集的区域没有之一行业里一直有个不成立但很有参考价值的说法80%的缺陷集中在边界附近。边界值分析的逻辑很简单——取边界值、边界两侧的相邻值去测。还是“6到20个字符”这个规则我会设计这样一组测试5个字符下边界-1无效6个字符下边界有效7个字符下边界1有效19个字符上边界-1有效20个字符上边界有效21个字符上边界1无效你看一张边界表就把问题看明白了。这组数据适用于所有需要校验长度、数值范围的输入项。再比如订单金额要求“满100元减20元”那99.99、100、100.01这三个值就一定要纳入用例。金额、时间、库存、运单号这些数值类字段边界值永远是重点。3.3 决策表法条件组合一多只有决策表能兜住有一次我在一个银行类项目里处理开户功能需求里有大量“如果客户年龄在18到65岁之间且持有有效身份证且未在其他网点开户则允许线上开户否则转人工”的规则。三个条件两两组合靠脑子记根本记不住。这时候决策表就派上用场了。决策表的做法是把所有条件组合列出来再把每个组合对应的动作写清楚。拿一个简化版的会员折扣规则举例是否会员是否特价商品是否满200元预期动作是是是按商品原价*会员折扣但不叠加满减是是否特价商品不打折扣是否是按商品原价*会员折扣且追加满减是否否按商品原价*会员折扣否是是不享受会员折扣享受满减否是否不享受任何折扣否否是享受满减否否否无优惠这个表格一出来产品规则里的逻辑漏洞就藏不住了。比如“不是会员但满200元买特价商品”到底能不能满减如果产品没明确这就是一个需求缺口你得趁早提出来。决策表最强大的地方就是帮助测试人员在设计阶段就把逻辑冲突暴露出来而不是等上线后被用户投诉再排查。3.4 状态迁移法有状态变化的流程盯着每个转折点凡是有状态机概念的功能比如订单状态、审批状态、工单流转、设备开关机都要用状态迁移法。假设一个订单有待支付、已支付、已发货、已收货、已取消、已退款六个状态。你要在用例里覆盖的状态转移至少包括待支付 → 已支付正常付款。待支付 → 已取消用户主动取消。待支付 → 超时自动关闭系统定时任务关单。已支付 → 已发货商家发货。已付款 → 已退款用户申请退款且商家同意。已发货 → 已取消这个状态如果出现了大概率是系统bug或者需要逆向流程支撑。状态迁移法设计出来的用例特别适合做接口测试和自动化测试因为它能用“路径”来描述系统行为。把状态当成一个节点路径当成连接线遍历所有可达路径和不可达路径很多隐藏问题就暴露了。比如我上面提到的“已发货 → 已取消”在正常业务里不应该发生但如果迁移图里没有这个箭头而实际系统允许说明状态机控制有漏洞。3.5 错误推测法依赖经验但要有章法错误推测法听起来很玄学但它本质上就是“根据过去的缺陷模式猜哪里会出错”。这要求你对被测系统过往的bug分布有了解。比如支付系统常见问题有重复点击导致重复扣款、返回按钮导致重复提交、前后端金额校验不一致、并发请求超时无提示。这些不是靠书本推出来的而是靠历史bug记录沉淀下来的。我个人的建议是每次项目复盘之后把经典的缺陷整理成一个“易错点清单”。下次设计用例时打开这个清单逐条对照命中率会高得吓人。比如短信验证码模块我清单里永远有这几条同一手机号频繁发送是否有频控、验证码有效期是否精确到分钟、多次输错是否锁定、验证码能否被复用。这些细节产品文档里可能只写“发送验证码”但实际测试你必须全部覆盖。3.6 场景法用真实用户路径串起所有分支场景法可以理解为“把前面的方法串起来”它更适合做整条业务链路的用例设计。你模拟真实用户的操作路径从进入入口到最后结果中间每个环节都可能出现异常每个异常就是一个分支场景。还是拿登录来说主场景是打开App—输入正确账号密码—进入首页。分支场景是首次登录需要同意用户协议、密码错误超过次数触发验证码、账号被锁定需要找回密码、弱网下登录超时提示网络异常、切换Wifi后登录状态是否保持。主场景加分支场景就构成了一棵完整的场景树。用场景法设计出来的用例执行阶段就像在走用户走过的路业务价值非常明确。4. 功能用例和接口用例不是两套独立工作是一件事的两层视角很多测试工程师一年下来只做页面点击接口用例设计基本不碰。这在早期的纯功能项目里还能混但放到现在的服务化架构里你就等着线上出事故吧。页面能看到的问题是有限的大量数据层、逻辑层的缺陷必须在接口层提前拦下。4.1 为什么接口用例能发现更深层的问题页面上你看到的只是前端渲染后的结果。前端可能会把接口返回的异常吞掉也可能在界面上做了各种兜底导致服务端明明已经返回500了用户看到的还是空白或提示“加载失败请重试”。但服务端的异常数据已经写进数据库了这种情况页面用例是发现不了的。举个例子用户修改手机号的功能页面上提示“修改成功”但数据库里新旧手机号都绑在了同一账号上潜在风险非常大。这种问题只能通过直接调接口查返回值或者查数据库才能发现。所以我做用例设计时功能用例和接口用例会同步展开而且接口用例的优先级往往更高。4.2 接口用例的核心关注点接口用例设计的输入是接口文档但文档经常会坑你。我的习惯是拿到接口文档先通读然后把每个接口涉及的字段都拆出来。接口用例的核心关注点大概有这几块必填参数校验缺一个必填参数接口是否返回明确的参数错误码。参数类型校验传输number类型时传string类型是否做类型转换或拒绝。参数边界校验比如分页接口的页码传负数、传0、传超大值。业务逻辑校验如订单接口传一个已取消的订单号创建退款是否被拒绝。权限校验普通用户调用管理员接口是否返回403。异常场景接口超时、第三方服务不可用、数据库连接失败时的返回。数据一致性事务型操作中中间一步失败前置操作是否回滚。你可能注意到这些关注点里约一多半不是接口文档能直接写出来的而是靠你对业务逻辑的理解去推导的。比如删除用户接口文档只写“按用户ID删除用户”但实际用例必须覆盖删除不存在ID、删除已删除的ID、删除仍有订单关联的ID、重复调用删除接口、无权限调用删除接口。每一个都是在文档之外补出来的。4.3 功能用例与接口用例的映射关系我的习惯是做一个简单的映射表。每条功能用例至少对应一条接口用例反之亦然。这样设计的好处是当功能用例回归执行失败时能快速定位是页面问题、前端逻辑问题还是服务端接口问题省去了大量排查成本。实践下来我建议测试团队在项目启动时同时产出三份东西功能用例、接口用例、数据准备清单。数据准备清单听起来简单但坑很多。比如创建订单接口要求传商品ID和数量那你需要提前在数据库里准备库存充足、库存不足、商品下架三种状态。没有数据接口用例就是纸上谈兵。5. 用例评审和用例维护写完了只是开始后面的过程更考研功力有些测试工程师把用例设计当成“一次性动作”写完提交就完事。但真实项目里用例从诞生到失效中间要经过评审、修改、补充、删除、自动化转化等多个阶段。用例维护做得好不好直接决定了你这个团队的测试效率。5.1 用例评审这个会不是走过场是拆雷现场我参加过的用例评审会有两类截然不同的画风。一类是测试自己把用例念一遍产品开发全程低头看手机最后说“挺好没问题”另一类是测试把关键用例、关键场景、规则分支抛出来产品和开发现场就要拍板双方还吵得面红耳赤。后者虽然开得累但每次都能揪出一堆需求层面的坑。怎么开好用例评审会我总结了几条经验评审前先发用例文档让参会者提前至少半天看完会上不要花时间逐条念。会上重点只过三类内容P0用例、有争议的业务规则、边界条件。每个模棱两可的预期结果当场指定唯一负责人确认不要把问题留到会后。评审纪要及时归档用例修改要有变更记录。经验之谈用例评审时产品最容易被“超时未支付自动取消超时时间是多久”“重复提交订单系统是拦截还是允许”“退款退的是原路还是余额”这类问题问住。这些问题在用例设计阶段发现成本几乎为零到了测试执行阶段发现可能就要重新开发代码了。5.2 用例基线和结构维护用例要有一个“基线版本”的概念。每个迭代开始前把上一轮的用例基线复制出来针对本迭代的需求增量做增删改而不是在旧文档上随手涂改。这样你可以回答一个很关键的问题这个版本到底新增了哪些用例、删了哪些用例、修改了哪些用例每一处变动都要有其他角色确认过。维护用例结构时我的经验是定期清理三个东西过时用例、重复用例、不可执行用例。过时用例指功能已下线却还躺在用例库里重复用例指同一个功能点在多个用例里反复出现执行时白白浪费时间不可执行用例指前置条件永远无法满足的用例比如依赖一个已下线的第三方接口。每季度清理一次用例库就不会腐化。5.3 回归用例的选择逻辑版本更新时不是所有用例都需要全量回归但也不是只跑新增功能就行。回归用例的选择逻辑我一般遵循三个原则本次改动直接影响的功能模块相关用例必跑。与改动模块有数据交互、状态流转的相邻模块相关用例必跑。公共基础能力比如登录、支付、权限无论本次是否改动建议抽核心用例跑一遍。举例来说这次开发改了订单金额计算逻辑那支付模块、优惠券模块、退款模块的用例都必须回归。因为金额计算一变上下游拿到的数据可能全部异常。如果开发只改了一个商品描述文案那只需要回归商品模块主流程就够了把P0相关用例跑一下。不要被“全量回归”这个词吓倒它的正确解法是基于影响面的评估而不是闭眼全跑。6. 踩过几次坑之后我对用例设计的三个重新认知最后一个部分我不想再讲方法而是想聊聊认知层面的变化。这些东西大部分不是从书上学来的是踩坑和复盘得来的。6.1 用例数量不是KPI不该用“量”来证明价值有一段时间团队里的用例设计评比是看“条数”的于是一堆低价值用例被硬凑出来。比如“点击登录按钮登录成功”“点击登录按钮登录成功第二次”这种用例有什么价值没有。用例设计的目标是覆盖风险不是一个功能点的无脑重复。现在我的原则是宁可少写一半用例也要把核心路径和关键异常覆盖到位。执行者的时间也是成本一百条低价值用例拖慢整个迭代节奏反而让真正重要的用例没有时间跑完。6.2 “预期结果”务必写得可观察、可判定这是我在新人身上看到最多的问题。预期结果写“登录正常”和没写一样什么叫正常我建议预期结果写成可以观察和断言的表述比如“登录成功后跳转到首页右上角显示用户昵称底部Tab栏默认选中‘首页’”。自动化脚本断言的时候它需要具体的元素状态而手工测试人员判断的时候也需要一个明确的对照标准。再举个例子预期结果写“订单金额计算正确”就很模糊正确的标准是什么我建议写成“商品单价99元数量2件运费10元无优惠应付金额208元”。这样执行人员只要把页面显示数字和预期一比对结果立刻清楚。6.3 用例设计能力和测试深度是互相成就的回头看用例设计并不是测试流程里一个孤立环节它跟你对业务的理解、你对架构的认知、你对数据的敏感度都绑定在一起。刚入行时我以为用例设计是“照着需求文档把每个按钮点一遍”干了两三年之后我才意识到真正好的用例是在需求阶段就能带着产品去思考“如果一个用户没有网络他还能做什么”。很多人觉得测试工作没有技术含量因为它用不到高深算法。但用例设计这件事其实是在不断训练一个人的逻辑缜密程度。你把一个复杂业务拆成一个个可验证的点这个过程本身就是一种结构化的思维训练。最后说一个我最近常给的实践建议每次用例设计完成之后自己先对着用例走一遍假装自己是用户从头到尾执行一次。如果连你自己都觉得某条用例步骤中间断了一环执行人会更加莫名其妙。自己先折磨自己一遍交付出去的用例才靠谱。