1. 为什么多数测试用例写着写着就“废”了我见过太多项目组把测试用例当成一个“交付物”来凑需求评审完了测试经理排个deadline测试工程师花两三天把用例铺满Excel领导一看数量不少归档。然后呢开发提测之后真正按用例执行的人没几个大家更习惯“打开页面随手点”用例文档从此躺在文档库里吃灰。等到下个迭代需求一改这份用例又要返工大改改到最后连写的人自己都不想看。问题出在哪出在我们从一开始就把用例当成了“执行记录”而不是“设计文档”。1.1 用例是设计文档不是执行记录执行记录是什么是你测完之后写的“我点了什么、输了什么、看到了什么”。它描述的是过去。而测试用例应该是面向未来的它描述的是“在什么条件下、准备什么数据、做哪些操作、应该观察到什么结果”目的是让任何一个具备基本测试能力的人——甚至三个月后的你自己——都能照着它复现一轮完整的验证。这两者的区别直接决定了用例的颗粒度。如果是执行记录你会写“输入手机号点击获取验证码收到短信”结束。但作为设计文档你得回答几个问题手机号是已注册的还是未注册的短信通道有没有限流验证码有效期是多少同一个手机号在60秒内重复点击会触发什么这些才是用例的价值所在。实话讲我早年间写用例也走过这个弯路。有一回做支付模块回归我自信用例覆盖率拉满了结果线上出了“退款金额大于实付金额”的漏测。翻用例一看我只写了“退款成功”压根没写“退款金额边界校验”。不是我不想写是我压根没把那次验证当成一个独立的、需要设计的场景脑子里默认“能退就行”。从那以后我给自己定了一条规矩每条用例必须能回答“我到底在验证哪个业务规则”回答不上来这条用例就不要写。1.2 常见病根覆盖靠灵感表达靠截图“覆盖靠灵感”是新手最容易踩的坑。需求文档里写了一句“支持优惠券抵扣”他就设计了三五条用例有券抵扣、无券不可抵扣、金额抵扣至0。看着挺全但优惠券的叠加规则、使用门槛、过期处理、退款时优惠券是否退回、一个订单能否用多张券——全没覆盖。这不是不认真而是缺少系统性的设计方法想到哪写到哪。“表达靠截图”则是另一个极端。很多用例里贴了一堆截图步骤倒也有但截图一晃眼文字描述又含糊其辞“选择正确的文件上传”。什么叫正确.txt算吗.exe算吗超过2MB算吗文件名带空格、带中文、带特殊字符算吗用例一含糊执行人就得猜猜的结果就是十个人测出十种结果缺陷复现率直线下降。所以写测试用例本质上是在做两件事第一把需求里的隐式规则显式化第二把无穷的输入空间和操作路径压缩成一组有限的、有代表性的验证样本。这两件事都做扎实了用例才真正有生命力。接下来我按实际工作中最常用的几条设计方法展开聊这些方法不新鲜但怎么用到位、怎么组合起来用值得仔细说说。2. 用例设计方法等价类、边界值与场景流的正确用法设计方法不是拿来装点文档的是拿来对抗“灵感式覆盖”的。我的习惯是拿到一个需求之后先做一轮静态分析把输入条件、处理逻辑、输出规则一条条列出来再去套方法。套方法的过程就像给需求做CT扫描一层一层把容易漏的地方翻出来。2.1 等价类划分——先把无穷输入归成几筐等价类划分的基本思路一句话就能讲完把无穷的输入数据按“测不测都一样”的原则分成若干类每一类里取一个有代表性的值来测。但真正的问题在于“测不测都一样”这个判断里面全是细节。拿登录框举例。一个用户名输入框有效等价类可能是“6-16位字母数字组合”无效等价类可能是“长度小于6位”“长度大于16位”“包含特殊字符”“包含中文”“全是数字”“全是字母”。这里有个关键点很多人会把无效等价类合并成一条“输入非法字符”这是典型的不合格设计。因为“非法”是个合集里面每一种非法规则的实现代码可能是不同的校验分支合并成一条用例测过A分支漏掉B分支的情况很常见。更进阶一点等价类划分要结合业务规则而不是只盯着格式。举个例子“新用户首单立减10元”如果你只按输入框格式划分等价类那永远漏不了格式问题但真正容易漏的是“新用户”的定义边界——注册超过30天算不算新用户用微信登录但没绑定手机号算不算在A渠道注册、B渠道下单算不算这些都不是输入格式能划分出来的必须回到业务规则去定义等价类。所以我每次划分等价类前第一件事是要求自己对业务规则逐条列出可验证的断言再动手分类。2.2 边界值分析——缺陷聚集地的守门员边界值是所有方法里性价比最高的没有之一。原因很简单代码里的比较逻辑大于、小于、等于、区间判断最容易在边界处出岔子而边界值的测试成本极低一个值一条用例而已。取值规则不复杂如果要求输入范围是1到100的整数那要测的边界值包括0下边界减1、1下边界、2下边界加1、99上边界减1、100上边界、101上边界加1。需要注意的是有些边界是复合的比如“满100减20”里的“满100”既要测99.99、100.00、100.01还要考虑这个金额是商品原价还是优惠前的应付金额。这类业务边界往往埋得深需求文档不一定明确写得靠测试自己推演。我在做电商项目时遇到过很典型的一个边界缺陷满减规则按“商品金额合计”计算但凑单退款之后应付金额已经低于满减门槛系统却没有自动收回优惠。这就是“边界值状态变化”叠加出的问题单测静态边界测不出来得结合后文要讲的场景法。硬件测试领域同样是边界值重灾区。搜到的热搜词里有人提到SPI硬件测试用例SPI通信的时序边界——时钟频率的最大最小值、片选信号的建立时间和保持时间、数据采样沿的setup/hold时间——每一个都是硬边界软件测试里一条断言没写可能只是漏个功能硬件时序边界踩过了就是实打实的通信丢帧甚至设备挂死。这类用例写起来更强调“数值精度”比如“SCLK频率在1MHz时正常在2MHz时丢帧”而不是笼统写“高速时异常”。对硬件测试感兴趣的朋友写用例时一定把数值边界给足别用模糊词汇。2.3 场景法——把用户行为串成业务流单点验证做得再好也替代不了场景验证。因为用户从来不是一个功能一个功能地用的他们是一条路径一条路径地走。场景法就是把用户的典型业务路径拆出来一个路径就是一套用例组合。设计场景法我一般分四步走先画主流程用户从进入到完成核心目标的最短路径。比如下单场景主流程就是“搜索商品-加入购物车-提交订单-支付-完成”。再画备选流程每一步上的常见分支。比如提交订单时的无库存分支、支付时的余额不足分支、支付超时取消分支。接着画异常流程系统异常、外部依赖失败、数据异常。比如支付回调超时、风控拦截、并发下单导致库存超卖。最后做场景矩阵把这些流程按“主备”“主异”“备异”组合起来形成场景清单。这里要强调一点场景法是为了验证“业务逻辑”的设计方法不是简单的“按用户路径走一遍就完”。同一个路径数据不同、状态不同验证的规则完全不同。比如“提交订单”这个动作全新用户、老用户、黑名单用户、未实名用户、账号异常用户走的是同一套页面操作但背后的校验逻辑可能走的是五套不同代码分支。所以场景法里的每个场景都必须明确“前置状态特定数据”否则就退回到了“随便点点”的层面。我见过不少团队把场景法用成了“端到端大用例”一条用例里塞十几个步骤断言五六个页面。这种做法在冒烟测试阶段没问题但一旦某个步骤失败整条用例的执行链就断了定位问题成本极高。我的习惯是场景用例里的断言按“关键业务节点”来切一个节点一条断言宁可多几条用例也不要把整个故事塞进一条。3. 用例表达从“能执行”到“能复用”的颗粒度控制设计方法解决的是“测什么”表达规范解决的是“怎么把设计结果写成别人能理解、能执行、能复用的东西”。这一步常常被低估实际上是拉开初级和高级测试工程师差距的分水岭。3.1 前置条件、测试数据与预期结果怎么写到不暧昧一条规范的用例至少要包含编号、标题、前置条件、测试数据、操作步骤、预期结果、优先级这几个要素。其中写得最烂的、最需要较真的是前置条件和预期结果。先说前置条件。很多人写“已登录”完了。但“已登录”的用户是什么角色普通用户、管理员、还是被限制的用户账号余额是充足还是不充足商品库存是有货还是无货这些都属于前置条件的一部分。前置条件写得越具体用例的确定性就越高。我通常会把前置条件拆成“系统状态账号状态数据准备”三段来写比如“系统处于正常服务状态用户A已登录且绑定了手机号用户A有一张未过期的满100减20优惠券”。三条清清楚楚执行的人不用猜。再说预期结果。预期结果最大的问题是“只写结果不写标准”。举个例子“系统提示下单成功”这算结果但不算标准。真正的预期结果应该写“页面跳转至订单详情页订单状态显示‘待支付’订单金额为扣除优惠后的金额同时库存扣减1优惠券状态变为‘已使用’”。为什么因为结果是一个表象标准是一组可核验的断言。用例执行的核心工作就是逐条核对断言断言写不清楚执行就是在走过场。测试数据这块我的原则是“一个用例一套独立数据数据之间不互相依赖”。以前我图省事十条用例共用一套测试账号结果前一条用例把优惠券用了后一条用例的前置条件就废了。现在凡是涉及状态变更领券、下单、充值、退款的数据每条用例都单独准备宁可在数据准备阶段多花时间也不在执行阶段互相踩脚。3.2 优先级、标签与层级结构用例进入资产阶段的前提用例写到一定规模就面临一个很现实的问题不是所有用例都值得每次都跑。接口改了UI的用例大概率受影响后台加了个配置项核心流程的用例必须全跑但边角功能的用例可以先放一放。这时候优先级就派上用场了。我习惯把用例优先级分为P0、P1、P2三档。P0是核心业务主流程一旦失败直接阻塞发布P1是重要功能边界和业务规则失败影响体验或产生资损风险P2是异常场景、兼容性、界面细节。这个分级直接决定执行策略冒烟测试只跑P0回归测试跑P0P1全量执行才跑P2。分级不是拍脑袋要结合业务影响面来判断。比如一个给C端用户直接使用的支付页面“点击支付无响应”这种用例再偏门也得是P0。标签体系容易被忽略但跨项目复用的时候特别好用。我的做法是给每条用例打至少三组标签业务域如“交易-支付”、功能模块如“优惠券”、执行环境如“Web端/移动端/接口”。这样做的好处是想筛一个特定范围的用例时用标签一过滤就出来了不用在几千条Excel里翻。层级结构上推荐“测试集-测试套件-测试用例”三层组织测试集对应一轮测试如“2.3版本回归”测试套件对应一个功能模块用例挂到具体套件下面。这样既方便单独执行某个模块也方便整轮打包执行。关于用例写的颗粒度再补充一句执行步骤里的每一个操作要么是“明确的动作”要么是“指向明确的数据”禁止写成“输入一些有效字符”这样的模糊表达。有人担心步骤写得太细会显得“低级”其实恰恰相反步骤写得细执行的人才能不用动脑、不用岔路、不用返工这是工业化测试的基本要求。4. 复杂迭代中的用例管理、复用与维护跨项目组实践热搜词里有一条很扎眼“测试用例在不同项目组的复杂迭代需求中的管理复用和维护”。这说明很多人已经意识到写用例不难难的是在多个项目组并行、需求快速迭代的环境里让用例资产持续可用。这块我踩过的坑不少值得专门写一节。4.1 为什么用例一多就没人敢动大多数团队的用例管理是这么演变的第一版需求一个Excel第二个迭代Excel多了一个sheet第三个迭代开始有人复制粘贴到第二个Excel到了第五个迭代用例文档分布在五个人手里每个人都有一份“最新版”。等到真要回归的时候没有人说得清哪份是准的。这时候出现一个诡异的现象用例越多越没人敢动。因为真正在用的用例和执行结果已经脱节了一旦有人“修正”了用例可能导致下一次执行的基线发生变化而没有人能评估变化的连带影响。所以在很多团队里用例文档成了“供奉品”——不执行也不敢改。要打破这个局面第一步是把用例从“私人文档”变成“公共资产”。这就必须从管理机制和工具两个维度同时下手。机制方面用例必须有唯一的ownerowner负责用例的维护和变更评审其他人可以提意见但不能直接改。工具方面除非团队规模特别小比如只有两三个人、项目周期两周以内否则我不建议用Excel做管理至少用一套带版本管理的测试管理平台把用例和需求、缺陷、执行记录关联起来。4.2 分层用例库与“三级复用”策略跨项目组复用的核心不是“把用例直接搬过去”而是“把可复用的部分抽象出来把不可复用的部分隔离掉”。我采用的方法是分层用例库。参考架构分三层平台层用例针对底层公共能力的用例比如用户认证、权限管理、消息中心、基础组件。这类用例最稳定跨项目直接复用改动频率最低。业务层用例针对某一类业务通用流程的用例比如电商的订单流程、支付流程。这类用例可以在同业务的A项目和B项目之间复用但需要针对项目差异做少量参数化调整。项目专属用例只属于特定项目的用例比如某个活动页面的一次性功能。这类用例不做复用项目结束之后按需归档。这个分层解决了一个很关键的问题什么时候允许“改别人的用例”。平台层和业务层的用例变更必须走统一评审因为影响面是跨项目的项目专属用例则给项目组最大的自主权怎么改都不影响全局。具体到复用方式我总结了“三级复用”一级是“原样复用”平台层的用例基本属于这一类拿过来直接执行即可二级是“参数化复用”同一个用例模板通过替换测试数据来适配不同项目比如订单流程用例里的商品、用户、金额全部做成参数各个项目代入自己的数据执行三级是“组装复用”把多个基础用例作为步骤拼装成新场景比如把“登录”“加购”“下单”三个用例拼成一条“登录到下单全流程”的冒烟用例。三级复用越往上维护成本越高但覆盖能力和执行效率也越高按团队能力逐步推进就好。4.3 失效用例处理与版本联动迭代过程中需求变更、功能下线、交互改版都会导致用例失效。老练的团队会专门安排“用例维护日”定期做一次全面体检但我见过更普遍的场景是新用例不断追加失效用例迟迟不标记最终用例库变成“僵尸库”。处理失效用例我的原则是“先标记后评估再处理”。发现用例失效后第一时间把状态改为“废弃待确认”写清失效原因比如“需求变更优惠券叠加规则取消”然后由用例owner在下一个迭代的用例评审会上确认是改逻辑还是直接删除同时检查是否有其他用例依赖了这条失效用例避免“依赖链断裂”。最容易被忽略的是用例和版本的联动。每次版本回归结束后我要求把“本次执行的用例版本号”记录在执行报告里。为什么因为两个版本之间如果用例基线漂移了执行结果就没法对比。有了版本号下次回归的时候可以快速对比“同一份用例、两个版本的结果差异”这才是回归测试的真正意义——不是看这次的用例跑了多少条而是看这次相对上次的变化是什么。我还想特意提一下硬件测试用例的维护。硬件用例和软件用例的生命周期差异很大一块开发板的SPI接口或者短距通信模块硬件改版之后之前能通过的时序用例可能一夜之间全挂。这种场景下用例维护的核心是和硬件版本号绑定同一份用例针对硬件v1.0和v2.0要分别维护通过标准不能混在一起。我在做嵌入式项目维护时给每条硬件用例都加了“适用硬件版本”字段测试报告也按硬件版本分开出否则出了故障都没法判断是软件回归问题还是硬件改版引入的。5. 用例资产的新出口从自动执行到AI生成脚本测试用例的价值不止于手工执行。这几年UI自动化测试的热度又上来了特别是Playwright这类工具普及之后很多人发现真正卡住自动化落地速度的不是工具不会用而是用例写得不够结构化——自动化脚本编写的工作量绝大部分花在了把自然语言用例翻译成代码这件事上。于是一个更前卫的想法开始流行能不能让AI直接读测试用例自动生成自动化脚本5.1 Playwright这类工具对用例写作的反推Playwright这类工具的流行对用例写作最大的影响是它逼迫用例变严谨。为什么因为人执行用例的时候遇到模糊的步骤会“脑补”比如“输入手机号”人会自动填一个格式正确的手机号但脚本不会它需要你告诉它“输入哪个手机号、点击哪个按钮、等待什么元素出现、断言什么文本或者什么状态”。换句话说想喂给Playwright跑起来的用例必须满足这么几个条件定位方式可识别你得说清楚操作哪个元素而不是说“点击页面右上角的按钮”、测试数据是具体值或者参数占位符、预期结果变成可程序化断言比如断言某个元素可见、某个接口返回200、某个文本等于特定值。这实际上就是用例规范在自动化时代的价值兑现。我见过很多团队自动化测试搞了一年脚本库倒是不少但维护成本高得吓人根因就是原始用例在“可执行性”这块不行脚本只能依靠开发人员自己理解需求后再“翻译”一遍用例在中间等于没起作用。如果你正准备用Playwright做UI自动化我建议先别急着写脚本先把目标模块的用例按前面说的规范整理一遍重点确保每条用例的操作步骤里都有明确的页面元素指向预期结果里都有可断言的客观标准。做完这个前置工作再写脚本效率会翻倍维护成本会直线下降。5.2 基于LangChain搭建“读用例生成脚本”Agent的思路与边界最近网络上关于“基于LangChain开发一个能读取测试用例、自动生成UI自动化测试脚本的Agent”的讨论不少我也实际试过这个方向分享一下真实体会。整体思路是把用例数据最好是结构化的比如JSON或者平台导出的格式作为输入通过LangChain构建一个Agent让它调用LLM理解用例语义再结合页面对象模型POM中已定义的元素定位信息生成对应Playwright代码。流程大致是读取用例 - 解析用例步骤与断言 - 检索元素定位 - 组装脚本片段 - 输出代码文件。这里有个关键设计不要让AI“裸写”定位器。实践下来最稳的做法是先把页面的关键元素定位收集好存成结构化的页面对象库Agent生成脚本时只负责“调用”已经定义好的页面对象方法而不是让AI猜元素的xpath。否则AI生成的定位器大概率不稳定页面一改就报废。本质上这个Agent做的是“语义翻译代码组装”而不是“从零发明”。但也要说清楚边界。以目前的技术现状这类Agent最适合的场景是用例结构化程度高、页面元素稳定性好、断言类型单一比如文本断言、元素可见性断言的模块。对于那些需要复杂动态交互拖拽、画布操作、第三方嵌入页面、强视觉验证截图比对、UI样式校验的场景生成脚本的准确率还远远不够盲目追求全自动化生成是有风险的。从实践角度看我觉得更有价值的用法是“人机协作”让Agent先根据用例生成一版初稿脚本测试开发工程师做代码评审和修正而不是完全自动提交执行。这样做的好处是用例规范和脚本生成之间形成了一个正向循环——用例写得越清晰Agent生成的脚本质量越高评审修正的成本越低那么这个流程就越能持续运转下去。5.3 对用例演进方向的一点判断做了这么多年测试我的一个感受是用例永远不会被替代但用例的存在形式一定会变。过去是Excel里的表格文本后来变成了平台上的结构化条目再往后它会逐渐变成“既供人阅读、也供机器消费”的中间资产——既可以指导手工测试也可以直接驱动自动化执行甚至可以成为AI训练与生成的基础语料。对测试新人我的建议是先别追工具老老实实把用例设计的基本功练扎实你写的每一条用例都做到“前置条件清楚、数据独立、步骤明确、断言可核验”这个习惯养成了后面学什么工具都快。对已经在带团队的测试负责人我给的建议是重视用例资产化像治理代码一样治理用例有版本、有Owner、有评审、有废弃流程用例库才能真正成为团队的公共资产而不是某个人电脑里那个谁也不想打开的Excel。最后再分享一个个人小习惯我每次写完一批用例都会自己模拟执行一遍哪怕不真打开系统也闭着眼睛在脑子里跑一遍流程。凡是在脑子里跑不通的用例执行的时候一定会有问题。这个习惯帮我改掉了至少一半的“无效用例”你也可以试试成本几乎为零收益却实实在在。
