测试用例这个东西在研发团队里的地位一直很微妙。你说它重要吧项目排期一紧张第一批被砍掉的就是用例设计的时间你说它不重要吧线上出了故障复盘的时候十有八九又会翻出用例来追问“这条场景当时为什么没覆盖到”。我在测试这条路上摸爬滚打这些年最大的感受是测试用例不是一个用来应付评审的文档它是测试团队和整个研发流程之间的契约是质量保障最核心的抓手。这篇文章不讲虚的就把用例从设计、编写、评审、执行到维护这一整套流程里的门道掰开揉碎了说清楚适合刚入行的测试工程师也适合写了几年用例但总觉得越写越乱的同事。1.1 用例在研发流程里的真实定位很多人把测试用例理解成“操作步骤加预期结果”这么理解没错但太浅了。用例在研发流程里至少承担了三层角色第一层是执行依据也就是测试人员照着步骤做验证第二层是回归资产产品迭代之后靠它确认老功能没被改坏第三层是沟通语言开发、产品、测试三方对齐需求时用例是最具体、最不容易产生歧义的需求表达方式。我见过不少团队需求文档写得模棱两可开发和测试对同一句话的理解完全不一样。这时候把用例往桌上一摆每一步操作和预期结果清清楚楚分歧立刻就能暴露出来。从这个角度看用例设计得越早团队踩坑的成本就越低因为大部分需求歧义在用例评审阶段就能被发现而不是等到功能做完了再扯皮。1.2 什么样的用例才算“好用例”判断用例写得好不好不是看数量也不是看格式多漂亮。我自己的标准是四个“能”能执行、能追溯、能发现问题、能指导回归。能执行指的是别人拿到你的用例不需要再问你任何问题照着步骤就能跑。能追溯是每条用例都能对应到具体的需求点需求变了知道该改哪条用例。能发现问题是说这条用例设计出来是有价值的不是重复造轮子。能指导回归是说用例要有优先级、有依赖关系回归的时候知道先跑什么后跑什么。这四个标准说起来简单做起来难。尤其是“能发现问题”这一条很多新人写的用例都是沿着正常流程走一遍全是happy path真正容易出问题的异常路径、边界状态、环境依赖反而被忽略了。这个后面展开讲。2. 用例设计的核心方法从需求到用例的拆解思路2.1 先拆需求再写用例我观察到一个普遍现象新人拿到需求文档第一反应就是打开Excel开始填用例。这个动作顺序其实是错的。写用例之前必须有一个需求拆解的步骤这个步骤做扎实了用例设计就是顺水推舟跳过这个步骤用例写出来一定是零散的、拍脑袋的。需求拆解我习惯分三步走。第一步是识别功能点把需求里所有的“用户能做什么”列出来比如“用户能登录”“用户能修改密码”“用户能查看订单列表”这是一棵功能树的叶子节点。第二步是提取业务规则也就是每个功能点下面有哪些约束条件例如“密码长度8到20位”“验证码五分钟内有效”“订单只能由本人取消”。第三步是梳理异常路径正常规则之外用户还可能怎么操作例如密码输入错误怎么办、网络超时怎么办、并发提交怎么办。这三步做完你会得到一张功能点、业务规则、异常路径的清单。后面所有用例设计方法其实都是围绕这张清单展开的。需求拆解这一步偷了懒后面再怎么套方法论都是空中楼阁。2.2 经典设计方法怎么组合用等价类、边界值、场景法、判定表、错误推测这些方法在教科书里都有但实际项目里很少有人告诉你它们该怎么搭配。我的经验是不要试图用一种方法覆盖所有场景每种方法都有自己的适用范围组合起来用才是完整的。等价类划分解决的是“海量输入数据怎么抽样”的问题。比如一个输入框接受1到100的整数你不可能每个数字都测一遍把输入域划分成有效等价类和无效等价类每个类别选一个代表值就够了。边界值分析是等价类的最佳搭档大量缺陷都发生在边界的左右两侧1和100要测0和101更要测这叫“上点、内点、离点”都要覆盖。场景法解决的是“业务流程怎么串”的问题。它关注的不是单个输入框而是用户从一个操作走到另一个操作的完整路径比如电商下单要经过加购物车、确认订单、支付、支付回调、订单状态更新这一整条链路中间任何一环断了都是场景级别的Bug。判定表适合处理“多个条件组合决定一个结果”的规则比如优惠券使用规则“是否登录、是否过期、是否达到门槛、是否叠加”四个条件组合出十几条用例用判定表一眼就能看出有没有漏。错误推测则是靠经验补漏哪里容易出问题就往哪里测这部分没有固定套路积累越多命中率越高。我见过把等价类和边界值当成万能药的人所有用例都用这两个方法套结果业务流程里的串行问题一个都没发现。方法和场景要匹配这是用例设计里最容易踩的坑。2.3 一个登录功能的完整拆解示例拿登录功能举个例子。很多新人觉得登录太简单了用户名密码输进去点按钮就完了。实际上登录功能是验证用例设计功底最好的试金石因为它既有输入规则、又有业务流程、还有异常状态。需求拆解阶段功能点是“用户通过账号密码登录系统”业务规则可能包括账号格式是手机号、密码长度8到20位且包含字母和数字、连续输错5次锁定账号、锁定时间15分钟。异常路径包括网络超时、服务端返回500、账号已锁定、密码错误、重复提交登录请求。把这些列出来用例设计就有章可循了。等价类和边界值负责输入域手机号有效和无效、密码长度边界8位和20位、密码纯数字和纯字母这些组合每条都覆盖一次。场景法负责流程正常登录跳转首页、登录后在会话过期时操作、锁定后15分钟内再次登录。判定表负责规则组合密码错1次和错5次边界、锁定后输入正确密码、锁定期内输入正确密码。错误推测补漏连续两次快速点击登录按钮会不会产生重复提交、弱网环境下登录超时的提示是否友好、前后端对密码加密策略不一致会不会导致登录失败。一个看似简单的登录功能认真拆下来七八十条用例很正常这还没算上权限、审计、多端登录这些扩展场景。所以当有人说“登录功能有什么好测的”我心里就知道这个人还没真正理解测试用例设计的深度。3. 用例编写规范与结构组织3.1 用例字段怎么设计用例管理平台上字段乱得一塌糊涂是很多团队的常态。有的团队用例编号全靠手打改一个就全乱了有的团队不写前置条件执行的人根本不知道从什么状态开始有的团队预期结果写“界面显示正常”什么叫正常每个人理解都不一样。用例字段设计其实是有标准答案的至少在核心字段上应该保持一致。我建议的用例核心字段包括用例编号、所属模块、用例标题、优先级、前置条件、测试数据、操作步骤、预期结果、实际结果、用例状态。用例编号遵循“模块-功能-序号”的规则比如“LOGIN-001”人可读又方便追溯。前置条件一定要写清楚环境、数据、状态比如“用户已注册且未锁定”。测试数据单独列出来方便执行时替换。操作步骤用带编号的列表每步尽量是一个独立的操作动作。预期结果要可观察、可验证不要写“系统正常”这种废话要写“页面展示成功提示并跳转到首页URL中携带会话标识”。实际结果和状态是执行阶段填写的但字段要在用例设计时就留好否则后面统计数据的时候无从下手。这里特别提醒一下优先级字段。用例优先级不要拍脑袋我一般按两条维度判断这个功能对用户的核心价值影响有多大出问题后的影响面有多广。核心链路、资金相关、数据安全相关的用例一律P0这类用例失败必须阻塞发版。次要功能的正常流程是P1异常分支和边缘场景是P2非常罕见的兼容性组合是P3。优先级不清的后果就是回归的时候大家按顺序从头跑结果P2P3跑完了P0的还没跑到效率低且风险大。3.2 用例步骤怎么写才不会产生歧义用例步骤的写法是最容易被低估的。很多用例写“输入正确的用户名和密码”执行的人就会困惑正确的用户名是什么是已经注册的某个固定账号还是本次测试前需要先注册的账号如果用例设计者不在旁边这条用例根本无法执行。我的经验是操作步骤要遵循“动作加对象加数据加预期”的格式比如“输入手机号13800138000密码Test123456点击登录按钮验证页面跳转到首页”。每个输入框对应的数据写清楚每个按钮对应的动作写清楚预期结果跟在操作后面写。不要怕啰嗦用例不是给人表演文采的是给人照着执行的。另外还有一个容易忽视的点步骤里不要夹带多个检查点。比如“点击支付按钮验证支付弹窗出现再验证支付成功页面展示”这一条步骤其实包含两个验证点如果第二个验证点失败了这条用例到底算不算失败记录结果的时候会非常纠结。一个操作、一个检查点是步骤划分的黄金原则遇到复杂的验收场景就拆成连续的多条步骤。3.3 用例库的组织与命名用例一多组织混乱的问题就来了。尤其是没有目录结构的平台成百上千条用例堆在一个层级里想找一条历史用例跟大海捞针一样。我习惯按照“产品线-模块-子功能-用例”的四层结构组织用例库比如“电商App-购物车-删除商品-删除单个商品成功”。这样的结构还有一个额外好处当新需求来了你可以快速判断当前用例库里哪些用例需要改动哪些可以复用维护的工作量评估就准了。命名上也有讲究。用例标题尽量写成“前置条件加动作加预期”的浓缩版比如“已登录用户在商品详情页点击立即购买跳转到确认订单页”而不是“购买商品测试”。前者看一眼标题就知道这条用例在测什么、怎么测后者还要打开用例内容才能确认。团队里几十个人写用例命名规则不统一最后维护成本一定爆炸。还有一个我强烈建议的做法给用例打标签。按测试类型打“功能”“接口”“性能”“兼容性”“安全”标签按需求来源打需求编号按是否需要自动化打“可自动化”标签。标签用好了后续做自动化用例筛选、回归范围圈定都有现成的数据源比事后再去翻用例内容高效太多。4. 从手工用例到自动化用例的转化4.1 哪些用例值得自动化自动化测试这几年越来越热pytest、appium这些框架也确实成熟但有一个很现实的问题很多人把手工用例一股脑全自动化结果自动化用例比手工用例维护起来还痛苦。实际上自动化不是目的自动化是手段哪些用例值得自动化我心里有一杆秤。我判断的标准是三条第一条操作重复且稳定比如每次发版都要回归的登录、注册、支付流程这种用例跑一百遍结果都一样自动化收益极高第二条执行频率高比如冒烟测试用例集每次构建都要跑手工跑一次十几分钟自动化跑一次三分钟长期下来节省的时间非常可观第三条数据准备和清理成本低如果一个用例的前置数据需要复杂的组合条件自动化脚本光准备数据就要写几百行那还不如手工测。反过来界面频繁改版、偶发性不稳定、需要人工视觉判断的用例比如UI样式、动效流畅度强行自动化只会让维护成本爆炸。我见过最离谱的情况是团队把视觉走查的用例也自动化结果前端改了个按钮颜色自动化用例就挂了一片排查半天发现根本不是功能问题最后自动化用例被领导认为“天天挂”信任彻底崩了。自动化用例的选型一定要克制先算清楚投入产出比。4.2 自动化用例的转化原则手工用例转自动化不是把Excel里的步骤翻译成代码那么简单。手工用例是人去执行人可以临场判断、随机应变自动化用例是机器去执行一切输入、判断、顺序都必须预先定义清楚。所以转化过程有几个核心原则任何一个违背了自动化用例的质量都堪忧。第一条是断言必须明确。手工用例预期结果写“页面跳转到首页”人可以看URL、看元素内容做综合判断自动化脚本必须把断言拆成具体的检查点URL是否包含某个路径、关键元素是否可见、接口返回码是否为200。一个自动化用例往往包含多个断言断言写得不全等于只验证了流程走通没验证结果正确。第二条是数据必须隔离。自动化用例执行不能依赖前一条用例的执行结果每条用例自己创建数据、自己清理数据我通常用pytest的fixture机制来做数据初始化和清理用例之间的数据相互独立这样单条失败不会污染后面的用例。第三条是必须幂等同一个用例跑十次和跑一次结果一样如果用例依赖执行次数累计的数据那大概率测出来的结果都是偶然的。这里提一下pytest的组织方式因为它确实是用例设计的优秀实践。pytest天然面向测试用例做了分层test_开头的函数是一条用例类是一种聚合conftest.py放共享的fixturemarker标记用例属性。手工用例里的“前置条件”对应fixture“测试数据”对应参数化parametrize“预期结果”对应assert断言。这种结构反过来也会倒逼你重新审视手工用例设计的是否合理。appium做移动端自动化时的思路类似每个测试类对应一个功能模块setup里做启动和登录teardown里做数据清理每条用例只关注自己的一小块业务逻辑。4.3 用例在自动化框架里的落地从手工用例到自动化用例文档层面的映射也很重要。我建议自动化用例和手工用例保持双向可追溯自动化脚本的注释里写明对应的手工用例编号手工用例的标签里标上“已自动化”。这样团队在评审和排期时一眼就能看出自动化覆盖了多少哪些核心用例还是纯手工状态。这个映射关系看起来简单但真的坚持做下去的团队并不多大多数是自动化用例写完了手工用例还在原地两套资产逐渐脱节最后各说各话。落地过程中最常见的一个坑是自动化用例跑挂了根本定位不了问题。这时候如果你打开脚本发现用例名是英文加数字的组合注释也没有日志只有一堆断言信息想定位到具体的业务步骤都困难。我的做法是给自动化用例加上打桩日志每一步操作都输出当前动作和关键数据这样一旦失败日志就像一条带路标的地图直接告诉你卡在哪一步、当时的输入是什么、期望和实际差在哪里。很多团队自动化用例维护成本高不是框架的问题是脚本可读性的问题这一点值得反复强调。5. 用例评审、执行与维护用例的“下半场”5.1 用例评审怎么开才有价值很多团队的用例评审就是测试人员把用例念一遍开发产品都在埋头看手机最后问一句“有意见吗”没人说话就通过了。这么开评审会用例的作用根本没发挥出来因为评审的核心目的不是过流程而是通过用例确认三方对需求理解一致尽早暴露需求漏洞和设计风险。有效的用例评审我总结出三个关键动作。第一评审前必须把用例提前发给参会人让大家有时间看而不是现场第一次读到用例。第二评审现场不要一条一条念要按业务场景串着讲讲“用户在这个场景下会经历什么、系统应该怎么响应”讲完之后再展开异常分支。这样产品能判断业务逻辑是否完整开发能判断实现方案是否可行测试能判断验证点是否充分三方视角是对齐的。第三评审结论里明确记录需要修改的需求点和用例点指定责任人而不是“之后再对”。没有结论的评审等于白开。评审时还有一个容易被忽略的点要用例评审去校验需求的完整性。如果测试人员在梳理用例时发现某些业务规则在需求文档里根本没写清楚这本身就是问题。比如取消订单时优惠券是否退回文档没写开发和测试按各自理解去做测试用例无论怎么写都只有50%的概率对齐真实业务意图。这种情况必须当场提出来而不是自己猜一个补上。5.2 执行过程中的用例管理用例执行不是大笔一挥打个勾就完事。执行过程中用例状态的管理直接决定你发布前对质量风险的判断是否可信。首先每条用例执行完必须如实标记状态通过、失败、阻塞、跳过都要写清楚原因。我最反感的一种状态叫“通过但有疑问”说明执行的人自己也不确定结果是否符合预期这种情况下执行结果宁可标记为失败去拉开发确认也不要糊弄过去。其次失败用例必须有对应的缺陷记录关联用例和Bug之间建立起链接回归的时候只需要看关联的Bug列表就能知道哪些失败用例已经修复需要复测。第三执行过程中遇到环境问题导致用例阻塞要及时标记环境原因而不是硬跑因为环境故障时用例的失败结果不具备参考价值混在真正的功能缺陷里会污染整个质量报告。执行顺序也值得讲究一下。我的建议是按优先级和依赖关系排先跑冒烟用例集冒烟失败就直接打回后面的全量回归根本不需要启动。冒烟通过了再跑P0用例P0全部通过才是安全感的来源。P1P2按功能模块逐个执行。这种分层执行的好处是质量风险是逐级暴露的你可以随时判断“现在这个版本到底能不能提测”而不需要等全部跑完才发现核心链路早就断了。5.3 用例维护与清理如果说用例设计考验的是测试思维用例维护考验的就是纪律性。很多团队的用例库最后变成了一座垃圾堆就是因为缺少维护机制需求变更了用例不改功能下线了用例不删导致用例库里一半的用例已经和当前系统状态对不上新人接手看这些用例学到的全是错误信息。我的维护机制是三句话需求变更时必须同步评估用例这是硬性要求需求评审时就确认相关模块的用例负责人功能迭代后至少每两个版本做一轮用例清理把废弃的、重复的、已经无法执行的用例标记失效或者直接删除每次版本结束做一次用例覆盖率回顾看这次新增的需求是否都有对应用例已自动化的用例状态是否更新。这听起来像流程工作但实际价值非常大因为它保证了用例库永远反映系统的真实状态任何时候拉出来的都是可信的资产。还有一个很实际的经验用例更新要写变更记录。谁在什么时候改了哪条用例、改成什么了要留痕。否则出现“这条用例以前是这么写的后来被改了”的扯皮时没有任何依据。简单在平台里加一行备注也好这个习惯能省掉很多不必要的争执。6. 常见问题与排查技巧实录6.1 用例设计阶段的典型失误这里我把这些年见过的用例设计问题集中盘点一下每一条都是踩过坑或者看过别人踩坑总结出来的。第一个问题是用例粒度失控。一种是粒度太粗一条用例覆盖了十几个操作步骤和七八个检查点执行失败后根本无法定位是哪一步出的问题另一种是粒度太细一个登录功能拆出两百条用例大量重复覆盖相同逻辑执行时间爆炸维护成本也承受不住。粒度的标准我自己的把握是一条用例至少有一个明确的核心验证目标附加检查点不超过两个步骤尽量在十步以内。超过这个量级就要考虑拆分。第二个问题是只盯着功能流程忽略了数据状态。很多用例设计时默认数据是“干净的”比如用户已注册、账户有余额、商品有库存。但实际系统里数据状态千奇百怪用户有未支付的订单、账户余额为负、商品刚好只有一件库存这些边界状态才是缺陷高发区。用例设计时要专门针对数据状态做变体而不是只测理想状态。第三个问题是环境依赖没有写清楚。用例里不写清楚“需要哪个环境、什么版本、什么权限”执行的人换了环境就会得出完全不同的结果。环境信息不一定每个字段都要写但涉及强环境依赖的场景至少要在前置条件里说明。6.2 用例执行中的常见问题执行阶段的问题同样不少。一个是“执行顺序错乱导致的假失败”用例A创建了订单用例B又来创建相同编号的订单导致冲突但此时A已经跑过了B一执行就失败。这个问题的根因是用例设计时没有做数据隔离定位方式也比较固定看失败时报错是不是数据重复、看前序用例是不是有相同数据的创建操作找到后把用例数据改成全局唯一即可。第二个常见问题是“环境变化导致用例集体失败”。早上用例还好好的下午全挂了第一反应不应该是怀疑所有功能都坏了而是先看环境状态测试环境是不是刚重新部署过、数据库是不是被重置了、依赖的mock服务是不是挂了。我遇到这种情况的排查顺序是先跑一个最简单的冒烟用例如果它都失败大概率是环境问题先拉开发确认环境状态不要一个个用例去排。第三个问题是“偶发性失败怎么处理”。一条用例这次跑通过下次跑失败再跑又通过这种稳定性问题最折磨人。我的建议是偶发失败绝对不允许直接标记为通过一定要保留失败现场。抓日志、保留截图、记录执行时间点然后结合服务端日志分析是不是超时、并发、时序问题。如果暂时定位不到根因就单独拉一个缺陷单跟踪千万不要因为“复现不了”就草草关闭。6.3 用例维护的坑和避坑经验维护阶段最大的坑是“只加不删”。很多团队每轮迭代都在新增用例但很少回头看哪些用例已经不再适用。结果用例库膨胀到几千条回归一次要跑一整天没人愿意跑执行率越来越低最终用例库沦为摆设。我每季度至少安排一次用例治理专项按模块清点一遍找出“死用例”删掉或者标记失效这个动作虽然短期看起来没什么产出但长期省下来的执行和维护成本非常可观。另一个坑是“需求变了但用例没跟着变”。最典型的情况是旧用例描述的是旧逻辑新功能已经上线了用例里还写着旧的操作步骤。新人执行时按照步骤操作发现系统根本没有这个按钮第一反应通常是“Bug”结果排查半天发现是功能改版了用例没同步更新。这种情况非常消耗团队信任解法只有一个把“需求变更同步更新用例”定为强约束需求评审、提测、上线三个节点都检查用例状态而不是想起来才去改。我最后想分享一个我在实际项目中屡试不爽的技巧每一条用例你都要问自己一句“这条用例如果失败了能不能有人看着它立刻知道产品出了什么问题”。如果答案是“不能”说明这条用例设计得有问题要么是断言不够明确要么是场景不够关键要么是和用户价值脱节了。我每次用这个标准筛一遍存量用例都能筛掉一批低价值用例也总能发现几个自己当初拍脑袋凑数的。测试用例这个东西本质上就是一次一次逼迫自己把业务逻辑想清楚的过程想清楚了用例自然就写得干净想不清楚再多的方法论和工具也帮不了你。
