测试用例设计方法有哪些举例说明这个问题几乎每次带新人都会被问一遍。问的人通常不是想背定义而是想知道面对一个需求怎么从零把用例写出来还能写得不多不少、覆盖关键风险。我自己从手工功能测试一路做到接口、自动化、车载以太网协议测试见过太多“用例写了上千条上线还是出问题”的项目也见过“用例只有几十条但每次都能抓住核心缺陷”的高手。差别不在工具而在设计思路。这篇内容就是把常用测试用例设计方法逐一拆开配上商城、接口、车载以太网等真实场景举例适合刚入行的功能测试同学也适合已经写了很多年用例、但想系统梳理方法的人。你可以把它当成一份可随时翻出来抄作业的实操笔记不必从头背到尾但遇到具体需求时知道该拿哪把刀。1. 先搞清楚测试用例设计到底在解决什么问题1.1 从“写得多”到“测得准”的转变很多人刚做测试时会把测试用例数量当成工作量的证明一天写三百条评审时看起来满满当当。但真正上线后缺陷并不按照用例数量分布。一个优惠券功能写了八十条用例可能漏掉“同一用户叠加两张券后金额为负”的组合一个登录接口写了五十条可能没测“手机号带空格”的边界。测试用例设计方法的价值就是把“随机想到什么写什么”转成“按模型和风险系统推导”。我习惯把测试用例设计分成三个层次。第一层是输入域覆盖也就是参数取值有没有覆盖有效、无效、边界和异常。第二层是逻辑路径覆盖也就是业务规则组合、状态流转有没有走到。第三层是运行环境覆盖也就是不同客户端、不同网络、不同数据量、不同并发下的表现。等价类、边界值解决第一层判定表、因果图、状态迁移解决第二层场景法、正交实验、错误推测解决第三层中的部分问题。把层次分清楚就不会把所有方法混在一起乱用。举个很常见的例子一个输入框限制“1到100的整数”。新手可能写输入1、输入50、输入100、输入空、输入字母。这些当然要写但只写这些远远不够。用等价类划分有效等价类是1到100的整数无效等价类包括小于1、大于100、非整数、非数字、空值、超长字符串。用边界值分析还要取0、1、2、99、100、101以及-1、0.9、100.1。用错误推测还要考虑前后空格、全角数字、科学计数法、中文数字、特殊符号。你看同一需求从五条扩展到二十多条并不是为了凑数而是每一类都有明确的缺陷假设。1.2 一套好用例的四个判断标准我判断一套用例好不好不看数量先看四个标准。第一是否可执行前置条件、操作步骤、预期结果是否明确换一个人能不能照样跑。第二是否可判定预期结果不能写“正常显示”而要写清楚页面文案、接口返回码、数据库字段值。第三是否可追溯每条用例能对应到需求、设计或风险点方便需求变更时精准维护。第四是否分层冒烟用例、核心回归、全量回归、专项用例分开不同阶段跑不同集合。这四个标准里“可判定”最容易被忽略。比如测试商城下单预期结果写“下单成功”就是不合格的。应该写成订单状态变为待发货订单金额等于商品金额加运费减优惠库存扣减对应数量支付流水号写入订单表页面跳转至支付成功页。只有这样自动化脚本才能断言人工执行时也不会靠感觉判断。再比如车载以太网测试预期结果写“通信正常”同样没有意义应该明确帧周期、报文长度、校验和、超时时间、错误计数器变化等可观测指标。还有一个经验用例设计不是一次性的。需求评审时写一版开发设计评审后补一版接口文档出来后细化一版联调时再根据实际返回调整一版。把用例当成活文档而不是一次交付的作业。这样后面做自动化、做AI辅助生成、做回归集优化才有可靠的基础。否则用例本身都是错的工具再先进也只是加速跑偏。2. 八大经典测试用例设计方法拆解与举例2.1 等价类划分把无限输入变成有限集合等价类划分的核心思想是如果某个集合里的一个值能发现缺陷那么同集合里的其他值大概率也能发现同类缺陷。所以不必穷举所有输入而是把输入域分成若干等价类从每个类里选代表值。有效等价类是符合需求规则的输入无效等价类是不符合规则的输入。写用例时有效等价类通常可以合并无效等价类最好一次只覆盖一个避免一个用例里多个错误互相掩盖。以一个商城注册功能为例手机号输入框需求是“11位数字以1开头”。有效等价类11位、以1开头、纯数字。无效等价类长度小于11、长度大于11、不以1开头、包含字母、包含特殊字符、包含空格、空值、纯空格。你可以设计一条有效用例用“13800138000”然后为每个无效类单独设计用例。为什么无效类要单独因为如果你在一条用例里同时输入“abc 123”系统可能只提示“格式错误”你无法判断是字母导致的还是空格导致的缺陷定位会变模糊。等价类划分特别适合表单、接口参数、批量导入、配置项这类输入域明确的功能。它的局限也很明显它假设同一个等价类内部的缺陷分布是均匀的但现实往往不是。比如金额输入0.01和999999.99可能触发不同的精度问题用户名输入1个字符和20个字符可能触发不同的数据库字段问题。所以等价类之后必须接边界值分析两者是搭档不是替代关系。我常用的做法是画一张表左边列参数右边列有效等价类、无效等价类、代表值、备注。评审时大家盯着表补充比盯着文字需求更容易发现遗漏。比如“年龄”字段需求写“18到60岁”表里就会出现有效类18-60无效类小于18、大于60、非整数、非数字、空、前后空格、全角数字。代表值选17、18、19、59、60、61。这张表直接变成用例骨架后续补充业务规则组合即可。2.2 边界值分析缺陷最爱藏在临界点边界值分析的依据很朴素大量缺陷发生在输入范围的边缘而不是中间。因为开发写判断时最容易把“大于”写成“大于等于”把“小于”写成“小于等于”或者数组下标从0还是1开始搞错。所以边界值通常取最小值、最小值减一、最小值加一、最大值、最大值减一、最大值加一有时还要取空值、零值、负数、最大长度、最大长度加一。还是手机号注册边界值包括10位、11位、12位首位是0、首位是1、首位是2全0、全9包含空格的位置在开头、中间、结尾。再看商城优惠券需求“满100减20”边界值就要取99.99、100、100.01优惠后金额为0、0.01、负数优惠券数量为1、0、最大库存。很多金额计算缺陷就藏在小数位和临界值上比如99.999被四舍五入成100系统到底算不算满减这种问题不测上线后客服就会被问爆。接口测试里边界值更重要。比如分页接口pageSize默认10最大100。边界用例pageSize10、11、99、100、101、0、-1、空、非数字、超大数。再看字符串长度限制数据库字段varchar(50)就要测49、50、51个字符还要测中文、英文、emoji、特殊符号混合时的字节长度。有些数据库按字符算有些按字节算不测清楚生产环境就会报“Data too long”。这里有个实操心得边界值不要只测输入边界还要测输出边界和状态边界。比如订单金额为0时能否提交库存为1时并发下单会怎样购物车商品数量达到上限时添加第N1个是什么提示优惠券刚好在23:59:59过期00:00:00使用是否有效这些都属于边界。把“边界”理解成“规则切换的临界点”比死记“最大最小加减一”更有用。2.3 判定表与因果图组合条件不再拍脑袋当业务规则由多个条件组合决定时等价类和边界值就不够用了。比如登录功能条件有“账号正确/错误”“密码正确/错误”“验证码正确/错误”“账号锁定/未锁定”结果有“登录成功”“提示账号或密码错误”“提示验证码错误”“提示账号锁定”。如果每个条件独立测可能漏掉组合。判定表就是把条件桩、动作桩、条件项、动作项列成表格穷举或合并组合确保每个规则至少有一条用例。因果图可以看成判定表的前置分析工具。它把输入条件当作“因”输出结果当作“果”画出因与果之间的逻辑关系包括与、或、非、互斥、包含等约束。实际工作中我不一定画标准因果图但会在白板上画条件关系再转成判定表。判定表的优势是直观开发、产品、测试都能看懂评审时容易发现“这个组合没定义规则”的空白。举个商城促销例子。规则用户是会员且订单满200减30用户是会员但订单不满200减10用户不是会员但订单满200减15用户不是会员且订单不满200不减。条件有两个是否会员、是否满200。每个条件两种取值组合有四种对应四个动作。判定表写出四行每行一条用例。如果再加“是否使用优惠券”“是否参加秒杀”组合会爆炸这时就要用正交实验或场景法裁剪。判定表的常见坑是条件取值不只是“是/否”。比如“订单金额”其实有多个等价区间0、1-99、100-199、200以上。如果直接当成布尔值就会漏掉中间区间。我的做法是先用等价类把连续条件离散化再用判定表组合。这样既不会组合爆炸也不会漏掉关键规则。另外规则冲突和规则缺失要单独标记。比如“会员且满200”同时满足“会员减30”和“满200减15”到底叠加还是取最优这种问题在需求阶段就要问清楚不能等用例执行时才发现。2.4 场景法从用户旅程倒推用例场景法是从用户实际使用路径出发把功能串成完整故事。它不关注单个输入框而关注“用户想完成什么任务会经过哪些步骤中间可能发生什么意外”。基本流是顺利完成的路径备选流是分支路径异常流是出错或中断路径。写场景用例时我习惯先画用户旅程从入口到目标再到结束标出每个决策点。以商城下单为例。基本流搜索商品、进入详情、加入购物车、选择地址、选择优惠券、提交订单、支付成功、查看订单。备选流未登录时加购、库存不足、地址无效、优惠券过期、支付方式切换、支付超时、取消订单、申请退款。异常流网络中断、支付回调重复、库存扣减失败、订单创建后支付失败。把这些路径串起来就能覆盖大量跨模块问题而这些问题往往不是单个接口测试能发现的。场景法最有价值的地方是暴露“状态不一致”。比如用户提交订单后支付超时订单状态是待支付还是已取消库存是锁定还是释放优惠券是占用还是退回如果只测单个接口每个接口都正常一串起来状态就乱了。再比如车载以太网场景单条报文收发正常但车辆上电、下电、休眠、唤醒、诊断、刷写同时发生时通信矩阵和优先级可能出问题。场景法就是把这些真实链路还原出来。我写场景用例时会加两个字段业务价值和发生频率。高频核心场景放冒烟和回归低频异常场景放专项。不要把所有场景都塞进每次回归否则执行成本会压垮团队。另外场景用例的预期结果要写“最终状态”而不仅是每一步的页面提示。比如支付超时后最终状态应该是订单取消、库存释放、优惠券退回、支付流水关闭。只写“提示支付超时”是不够的。2.5 状态迁移法有状态对象必须画状态机状态迁移法适合订单、支付、优惠券、工单、设备连接、车载节点这类有明确状态的对象。核心是画出状态、事件、迁移、动作和 guard 条件。然后覆盖每个状态至少到达一次每条迁移至少触发一次非法迁移要确认被拒绝回退和超时迁移要确认正确。状态迁移法能发现“状态卡死”“重复触发”“越权迁移”等问题。以订单状态为例待支付、已支付、待发货、已发货、已完成、已取消、退款中、已退款。事件包括创建、支付、取消、发货、确认收货、申请退款、退款成功、超时。合法迁移待支付→已支付、待支付→已取消、已支付→待发货、待发货→已发货、已发货→已完成、已支付→退款中、退款中→已退款。非法迁移已取消→已支付、已完成→退款中、已发货→待支付。每条非法迁移都要有用例验证系统拒绝并给出合理提示。状态迁移法还有个隐藏重点并发事件。比如订单待支付时用户同时点击支付和取消最终状态是什么支付回调重复到达两次会不会重复发货优惠券在退款时已经过期退不退这些不是简单状态图能覆盖的需要结合并发测试和幂等测试。我的做法是先用状态迁移法列出所有合法/非法迁移再针对关键迁移补充“重复事件”“乱序事件”“超时事件”三类用例覆盖效果会好很多。车载以太网里状态迁移更常见。节点从上电、初始化、配置、通信、降级、休眠、唤醒每一步都有超时和错误处理。测试用例不能只测“正常通信”还要测初始化超时、配置失败、链路断开、错误帧注入、睡眠中收到唤醒帧、唤醒后重连、诊断会话切换。状态迁移图画出来用例自然就出来了。没有状态图靠拍脑袋想一定漏。2.6 正交实验法多参数组合的降本利器当有多个参数、每个参数多个取值时全组合数量会爆炸。比如有5个参数每个3个取值全组合是243条。正交实验法通过选择正交表用较少的组合覆盖两两参数之间的交互。它不能覆盖所有高阶组合但能显著降低成本适合兼容性测试、配置测试、协议参数测试。常见正交表有L9(3^4)、L16(4^5)等也可以直接用工具生成。举个例子商城搜索功能有四个参数关键词类型中文、英文、数字、排序方式综合、销量、价格、价格区间不限、0-50、50-200、是否包邮是、否。每个参数三个或两个取值全组合36条。用正交表可以压到9条左右同时保证任意两个参数的取值组合至少出现一次。对于非核心功能这种覆盖性价比很高。对于支付金额、库存扣减这类高风险逻辑仍然要全组合或补充判定表。正交实验法的坑在于它只保证两两组合不保证三三组合。如果业务规则涉及三个条件同时满足才触发正交表可能漏掉。所以使用前要问这个功能是参数独立影响结果还是多条件联合决定结果如果是后者正交实验只能作为补充不能替代判定表。另外正交表生成后要人工检查业务禁止组合比如“价格区间0-50”和“排序价格降序”可以组合但某些参数之间可能存在互斥不能机械套表。我实际做接口参数组合时会先按风险分级。高风险参数进判定表全组合中风险参数进正交表两两覆盖低风险参数只测有效值和少量异常。这样既控制用例数量又不丢关键风险。正交实验不是偷懒而是把测试资源花在刀刃上。2.7 错误推测法老司机的经验清单错误推测法听起来最不“科学”但实际价值极高。它依赖测试人员的经验列出可能出错的情况然后针对性设计用例。比如空指针、超时、重复提交、并发、弱网、权限、缓存、时区、编码、大小写、前后空格、特殊字符、边界溢出、默认值、配置开关、灰度逻辑、历史数据兼容。这些不是从需求里推导出来的而是从过往缺陷里总结出来的。我维护了一份“错误推测清单”按领域分类。Web端常见刷新页面、后退、多标签页、重复点击、浏览器缓存、Cookie失效、Token过期、跨域、文件上传类型伪造。接口常见参数缺失、参数类型错误、参数顺序变化、重复请求、大报文、超时重试、幂等、并发、越权、SQL注入、XSS。车载常见错误帧、丢帧、延迟、抖动、总线负载高、节点掉线、唤醒异常、诊断超时。每次写用例时对照清单能快速补充异常场景。错误推测法不能替代系统方法但可以作为最后一道补漏。我的做法是先用等价类、边界值、判定表、状态迁移把主干覆盖好再用错误推测清单扫一遍。两者不冲突。清单也要定期更新每次线上缺陷复盘后把新的缺陷模式加进去。时间久了这份清单就是团队最值钱的资产之一。2.8 路径覆盖与数据流法代码逻辑到用例的映射路径覆盖是白盒测试方法目标是在代码控制流图中覆盖语句、分支、条件、路径。语句覆盖最弱分支覆盖要求每个判断的真假都走到条件覆盖关注每个原子条件路径覆盖关注组合路径。实际测试中完全路径覆盖不现实通常会结合基本路径法和循环测试。基本路径法先画控制流图计算圈复杂度得出独立路径数量再为每条独立路径设计用例。面向数据流的设计方法则关注变量定义和使用。变量在哪里定义在哪里使用是否存在定义后未使用、使用前未定义、重复定义、定义被覆盖等问题。这类方法在静态分析、代码review、单元测试中很有用。比如一个订单金额变量在多个if分支里可能被重新赋值如果某个分支没有赋值后面使用时就会拿到旧值或空值。只看语句覆盖可能发现不了数据流分析可以。普通功能测试同学不一定天天画控制流图但理解这些方法有好处。第一能看懂开发的设计文档知道哪些分支风险高。第二做接口测试时能根据代码逻辑补充异常路径。第三代码review时能提出更具体的问题而不是只说“这里可能有问题”。比如看到一段优惠券计算逻辑圈复杂度很高条件嵌套很深就应该针对性设计组合用例而不是只测几个正常值。3. 真实项目举例商城、接口、车载以太网怎么落地3.1 商城优惠券功能等价类边界值判定表组合假设需求用户可以使用一张优惠券满100减20满200减50会员额外打9折优惠券不可与秒杀商品叠加优惠券有有效期每单限用一张。这个需求看起来简单但组合非常多。我会先拆参数订单金额、用户身份、商品类型、优惠券类型、优惠券状态、时间、使用张数。然后逐一做等价类和边界值。订单金额有效等价类0-99.99、100-199.99、200以上。边界值99.99、100、100.01、199.99、200、200.01。用户身份会员、非会员。商品类型普通、秒杀。优惠券状态有效、过期、已使用、已锁定。使用张数0、1、2。时间有效期内、开始前、结束后、临界秒。判定表把“满减规则会员折扣秒杀限制”组合起来。比如会员满200普通商品有效券最终金额是200减50再打9折还是先打9折再满减这必须问清楚否则用例预期结果无法写。我实际会写一条核心用例非会员普通商品订单金额200使用满200减50券预期支付150优惠券状态变为已使用订单优惠明细显示50。再写边界199.99不减50只减20100刚好减2099.99不减。再写异常秒杀商品使用券提示不可叠加过期券提交提示失效已使用券再次提交提示无效同一单两张券只允许一张。最后用错误推测补优惠后金额为负、优惠券并发使用、退款后券是否退回、部分退款后优惠如何分摊。这些用例写出来评审时产品和开发经常会被问住。比如退款时优惠券退不退部分退款后优惠金额怎么算如果需求没写测试就要推动补充规则。这就是测试用例设计的价值不只是验证更是提前暴露规则空白。3.2 商城接口测试参数组合与幂等、并发接口测试用例设计和页面测试不同页面看到的是提示接口看到的是状态码、响应体、数据库变化、消息队列、缓存。以“创建订单”接口为例参数有userId、skuId、quantity、couponId、addressId、payType、token。等价类userId有效/无效/不存在/被禁用skuId有效/下架/不存在/库存不足quantity 1、0、-1、最大库存、超过库存couponId 有效/过期/已用/不属于该用户addressId 有效/删除/不属于该用户payType 支持/不支持。边界值quantity1、最大库存、最大库存1金额0、0.01、最大限额。接口测试还要测幂等。同一个请求重复提交两次应该只创建一个订单还是创建两个通常需要业务幂等键。用例相同requestId重复请求预期返回同一订单号数据库只有一条订单。并发用例库存1两个用户同时下单预期一个成功一个失败库存不为负。超时用例支付回调延迟、重复回调、乱序回调。权限用例用户A用用户B的地址、优惠券、订单号预期拒绝。安全用例参数注入、越权、敏感字段脱敏。缓存用例商品信息更新后接口是否返回旧缓存。我习惯把接口用例分成四层单参数校验、业务规则、数据一致性、异常与并发。单参数校验用等价类和边界值业务规则用判定表和状态迁移数据一致性检查数据库、缓存、消息异常与并发用错误推测和场景法。这样一套下来接口用例不会只停留在“200就通过”。3.3 车载以太网测试协议一致性与异常注入车载以太网测试用例设计和普通Web测试差别很大。它更关注协议一致性、实时性、可靠性和异常处理。常用方法包括等价类、边界值、状态迁移、场景法、错误推测但具体对象变成了报文、帧、周期、优先级、VLAN、诊断服务、刷写流程。比如测试SOME/IP或DoIP需要覆盖正常请求响应、未知服务、错误方法、超时、重复请求、报文长度边界、序列号回绕、会话切换、并发请求。边界值在车载里非常关键。比如报文周期10ms要测9ms、10ms、11ms报文长度最小、最大、最大1超时时间1s要测999ms、1000ms、1001ms错误计数器阈值要测阈值前、阈值、阈值后。状态迁移覆盖节点上电、初始化、通信、降级、休眠、唤醒。场景法覆盖整车上下电、诊断刷写、网络管理报文、多节点同时唤醒。错误推测则补充错误帧、丢帧、乱序、延迟抖动、总线负载高、节点掉线、电源异常。车载项目里很多缺陷不是功能逻辑错而是时序和状态错。比如唤醒后某个节点还没准备好就收到诊断请求导致无响应或者总线负载高时低优先级报文被延迟触发超时。这类问题靠单条报文测试发现不了必须用场景法和状态迁移法组合。用例预期结果也要写成可测量指标比如响应时间小于50ms、错误计数器不增加、报文周期偏差在允许范围内。3.4 代码review与用例设计如何互相补位代码review和测试用例设计不是两条平行线。Review时看到的分支、条件、异常处理可以直接转化为测试用例。比如review发现某个接口对空参数没有校验就可以补一条空参数用例发现重试逻辑没有限制次数就补重试超限用例发现缓存更新和数据库更新不在同一事务就补一致性用例。反过来测试用例设计时发现某个规则很难构造可以回头review代码看实现是否合理。我参与review时会重点看几类代码金额计算、库存扣减、状态机、权限判断、并发控制、异常捕获、日志脱敏、配置开关。金额计算看精度和舍入库存扣减看是否原子、是否超卖状态机看非法迁移是否拦截权限判断看越权并发控制看锁和幂等异常捕获看是否吞掉错误配置开关看默认值和灰度。每一类都能对应一批测试用例。这样review不是走过场而是直接提升测试覆盖。4. AI辅助生成测试用例能做什么、不能做什么4.1 从PRD到用例草稿的工程化流程AI生成测试用例最近很热尤其是“根据PRD生成用例”“AI自动写用例做自动测试”。我的实际体验是AI适合做草稿和补漏不适合直接定稿。原因很简单AI不知道你的业务历史缺陷、线上真实数据分布、系统架构限制。它可以把需求文字转成看似完整的用例列表但其中可能包含无法执行的步骤、错误的预期结果、遗漏的关键规则。如果直接拿去执行反而增加校验成本。一个可落地的流程是先把PRD拆成结构化输入包括功能描述、输入参数、业务规则、状态流转、异常提示、接口定义。然后让AI按指定模板生成用例草稿。模板字段包括用例编号、所属模块、用例标题、优先级、前置条件、操作步骤、预期结果、设计方法、需求追溯。生成后人工做三轮校验第一轮查规则是否遗漏第二轮查预期结果是否可判定第三轮查是否与现有用例重复。通过后再导入用例管理平台。这里的关键是“结构化输入”。如果直接把一大段PRD丢给AI输出会非常泛。比如PRD写“支持优惠券”AI可能生成“使用有效优惠券成功”“使用无效优惠券失败”两条完全没有覆盖满减规则、叠加限制、过期边界、并发使用。你要在提示词里明确要求按等价类、边界值、判定表、状态迁移分别展开列出有效类、无效类、边界值、状态迁移路径。这样输出质量会高很多。4.2 AI生成用例的提示词模板与校验规则下面是我常用的提示词模板可以直接改成你项目的版本。注意AI生成的内容必须人工复核不能直接作为最终用例。你是一名资深测试工程师。请根据以下需求生成功能测试用例草稿。 需求描述{粘贴结构化需求} 接口定义{粘贴接口文档} 业务规则{列出规则} 状态流转{列出状态} 要求 1. 按等价类、边界值、判定表、状态迁移、场景法分别输出用例。 2. 每条用例包含编号、标题、优先级、前置条件、步骤、预期结果、设计方法。 3. 预期结果必须可判定包含页面提示、接口返回、数据变化。 4. 对不确定的规则单独列出“待确认问题”不要编造。 5. 不要输出与需求无关的通用安全用例除非需求涉及。生成后我会用一张校验表过一遍。校验项包括是否覆盖所有有效等价类是否覆盖无效等价类和边界是否覆盖业务规则组合是否覆盖状态合法迁移和非法迁移是否包含异常、并发、权限、数据一致性预期结果是否具体是否存在重复用例是否标注了待确认问题。只要有一项不过就退回补充而不是直接入库。AI还有一个好用场景把已有用例做去重和分类。比如老项目积累了三千条用例很多重复、过期、优先级混乱。可以让AI按功能模块、设计方法、风险等级聚类再人工确认。但不要让它自动删除用例删除动作必须人工确认。因为有些用例看起来重复实际覆盖不同数据或环境。4.3 哪些场景别交给AI直接定稿有几类场景我不建议让AI直接定稿。第一涉及金额、库存、权限、资金、安全的核心规则。这些必须人工结合判定表和状态迁移仔细推导。第二涉及硬件、协议、时序的车载以太网测试。AI对具体协议栈和硬件行为理解有限容易生成看似合理但无法执行的步骤。第三强依赖历史缺陷和线上数据的场景。比如某个老系统有特定的兼容性问题AI不知道必须由熟悉系统的人补充。第四需要探索性测试的场景。AI可以给方向但真正的缺陷往往在探索过程中发现。我的定位是AI做“第一稿”和“检查清单”人做“规则确认”和“风险判断”。把AI当成一个不知疲倦的实习生它可以帮你列提纲、补边界、换表达但你不能让它签字负责。尤其是在敏捷迭代里需求变化快AI生成的用例如果不跟着更新很快就会变成过期文档。所以用例库的维护责任仍然在人。5. 常见问题与排查技巧实录5.1 用例越写越多但漏测依旧这个问题通常不是方法不够而是没有风险分级。所有需求都用同样粒度写用例核心支付和边缘配置都写五十条结果核心场景覆盖不足边缘场景又过度覆盖。我的做法是先做风险矩阵影响面大、发生频率高、历史缺陷多的功能定为高风险用例写到参数、边界、并发、异常、数据一致性中风险覆盖主流程和关键异常低风险只覆盖基本流和少量异常。这样用例总数可能下降但关键缺陷发现率上升。另一个原因是只写正向用例不写反向用例。正向用例验证“能做什么”反向用例验证“不能做什么”。比如优惠券不仅要用有效的还要测过期、已用、不属于该用户、叠加秒杀、并发使用。权限不仅要有权限能访问还要测无权限被拒绝、越权被拒绝、Token过期被拒绝。反向用例往往更容易发现缺陷。写完正向用例后强制自己问一句如果用户故意乱来系统会怎样5.2 需求含糊时怎么下笔需求含糊是常态。比如“支持批量导入”到底支持多少条文件格式是什么失败是全部回滚还是部分成功重复数据怎么处理这时候不要等需求完美再写用例而是先列出“待确认问题”同时按最可能的假设写草稿。待确认问题要具体不要写“批量导入规则不明确”而要写“单次最大导入条数是多少”“第100条失败时前99条是否入库”“重复手机号是跳过、覆盖还是报错”。评审时逐条确认确认一条更新一条用例。我习惯在用例里加一个“假设”字段。比如“假设单次最大1000条”“假设失败全部回滚”。这样即使需求还没定用例也能先评审等需求明确后只改假设和预期结果不用重写整条用例。这个习惯能显著减少返工。5.3 用例评审怎么避免走过场很多用例评审就是测试一个人念其他人玩手机。要避免走过场评审前必须发材料评审时按风险顺序过而不是按用例编号顺序念。先过核心业务规则、状态迁移、异常场景再过边界和界面。每个模块指定一名非作者作为主评审人提前看用例并准备问题。评审输出要包括新增用例、修改用例、删除用例、待确认问题、责任人、截止时间。没有结论的评审等于没开。我还会在评审时做“反向提问”如果这条用例执行失败可能是什么原因如果这个需求变更哪些用例要改如果线上出问题这条用例能不能复现这些问题能快速暴露用例的薄弱点。另外用例评审不要只叫测试产品和开发必须参加。产品确认规则开发确认实现和接口测试确认覆盖。三方对齐后面执行会顺很多。5.4 用例维护与回归集分层用例写完不是结束维护才是大头。需求变更时要能快速找到受影响的用例。这依赖追溯关系用例关联需求、接口、代码模块。没有追溯变更一来只能全量 review成本极高。我的做法是每个迭代结束更新用例库标记新增、修改、废弃。废弃用例不要直接删除先标记归档保留一个版本周期防止误删。回归集要分层。冒烟集核心主流程每次构建都跑控制在几十条以内。核心回归支付、下单、登录、权限、库存等迭代结束跑。全量回归版本发布前跑。专项集性能、兼容、安全、车载协议等按需跑。用例还要打标签模块、优先级、设计方法、自动化状态、风险等级。这样需要哪一层就筛哪一层不会每次都被全量用例拖死。6. 我个人的几个实操习惯6.1 先画图再写用例我写复杂需求前一定先画图。业务规则画判定表状态对象画状态机用户旅程画流程图接口依赖画时序草图。图不用很漂亮白板、纸上、思维导图都行。画图的过程就是梳理逻辑的过程很多规则空白在画的时候就会暴露。图画完用例骨架基本就有了剩下的就是填参数和预期结果。比直接打开Excel硬写效率高很多。6.2 给用例打风险标签每条用例除了优先级我还会打风险标签资金、库存、权限、数据一致性、兼容性、性能、安全、用户体验。这样当测试时间被压缩时可以优先保留高风险标签的用例。比如只剩半天回归先跑资金、库存、权限再跑界面文案。风险标签也让新人知道为什么这条用例重要而不是机械执行。6.3 保留“错误推测”的活文档我有一个持续更新的错误推测清单按项目、模块、缺陷类型记录。每次线上问题复盘后把新的触发条件加进去。下次写用例时先过一遍清单能快速补一批异常用例。这个清单不需要多正式一个共享文档就够但要坚持更新。时间长了它会成为团队最实用的测试资产之一。