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，回归测试跑P0+P1，全量执行才跑P2。分级不是拍脑袋，要结合业务影响面来判断。比如一个给C端用户直接使用的支付页面，“点击支付无响应”这种用例再偏门也得是P0。
标签体系容易被忽略，但跨项目复用的时候特别好用。我的做法是给每条用例打至少三组标签：业务域（如“交易-支付”）、功能模块（如“优惠券”）、执行环境（如“Web端/移动端/接口”）。这样做的好处是，想筛一个特定范围的用例时，用标签一过滤就出来了，不用在几千条Excel里翻。层级结构上，推荐“测试集-测试套件-测试用例”三层组织，测试集对应一轮测试（如“2.3版本回归”），测试套件对应一个功能模块，用例挂到具体套件下面。这样既方便单独执行某个模块，也方便整轮打包执行。
关于用例写的颗粒度再补充一句：执行步骤里的每一个操作，要么是“明确的动作”，要么是“指向明确的数据”，禁止写成“输入一些有效字符”这样的模糊表达。有人担心步骤写得太细会显得“低级”，其实恰恰相反，步骤写得细，执行的人才能不用动脑、不用岔路、不用返工，这是工业化测试的基本要求。
4. 复杂迭代中的用例管理、复用与维护：跨项目组实践
热搜词里有一条很扎眼：“测试用例在不同项目组的复杂迭代需求中的管理复用和维护”。这说明很多人已经意识到，写用例不难，难的是在多个项目组并行、需求快速迭代的环境里，让用例资产持续可用。这块我踩过的坑不少，值得专门写一节。
4.1 为什么用例一多就没人敢动
大多数团队的用例管理是这么演变的：第一版需求，一个Excel；第二个迭代，Excel多了一个sheet；第三个迭代，开始有人复制粘贴到第二个Excel；到了第五个迭代，用例文档分布在五个人手里，每个人都有一份“最新版”。等到真要回归的时候，没有人说得清哪份是准的。
这时候出现一个诡异的现象：用例越多，越没人敢动。因为真正在用的用例和执行结果已经脱节了，一旦有人“修正”了用例，可能导致下一次执行的基线发生变化，而没有人能评估变化的连带影响。所以在很多团队里，用例文档成了“供奉品”——不执行，也不敢改。
要打破这个局面，第一步是把用例从“私人文档”变成“公共资产”。这就必须从管理机制和工具两个维度同时下手。机制方面，用例必须有唯一的owner，owner负责用例的维护和变更评审，其他人可以提意见但不能直接改。工具方面，除非团队规模特别小（比如只有两三个人、项目周期两周以内），否则我不建议用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。
最后再分享一个个人小习惯：我每次写完一批用例，都会自己模拟执行一遍，哪怕不真打开系统，也闭着眼睛在脑子里跑一遍流程。凡是在脑子里跑不通的用例，执行的时候一定会有问题。这个习惯帮我改掉了至少一半的“无效用例”，你也可以试试，成本几乎为零，收益却实实在在。
部署运维指南：从接口配置到安全策略)
