干了这些年测试我见过太多人把“写用例”当成一件应付差事的事。版本排期出来测试时间只有几天于是大家闷头在用例管理系统里堆条目一条条标题写得像填空题“登录功能测试”“搜索功能测试”“提交订单测试”。评审的时候往投影上一放别人问“这条用例为什么这么设计它的前置条件是什么预期结果怎么断言”你支支吾吾说不出所以然。最后用例文档倒是厚厚一叠回归的时候真正能跑起来的、能发现问题的那几条一只手数得过来。真正的问题在于用例不是文档流水账而是一套决策的物证。你写下的每一条用例都应该能回答三个问题我要验证什么为什么值得验证通过/失败怎么判定做不到这三点用例写得再多也只是僵尸条目既浪费评审时间也干扰回归效率。这篇东西我想从头到尾讲一下我实际写用例的过程——从需求拆解、场景分析到优先级取舍、落成文档再到评审、执行、迭代维护以及从功能用例延伸到接口用例的套路。我会用真实的业务例子来讲尽量说清楚每一步“为什么这么做”而不是只给一个笼统的模板。写用例这件事入门容易写明白不简单但这篇应该能让你少走一些弯路。1. 用例不是流水账而是需求的物证很多测试新人拿到需求文档第一反应就是“赶紧开始写用例”好像写用例是一个从零开始的动作。实际上用例设计的前置工作比写本身重要得多。1.1 需求拆解把一句话变成一张测试点清单我习惯的做法是先把需求文档里的每条功能描述单独拆出来逐句翻译成“可验证的变化”。这个词是我的一个老领导教的听起来玄乎其实很简单任何需求实现后系统总有一个状态、一个页面、一份数据会发生变化。你能观察到这个变化你就能写用例。举个例子。需求原文只有一句话“用户可以设置是否接收消息通知”。听起来很简单对吧但你真要把它写进用例会发现这句话根本没法直接测。它至少要拆出以下几个维度设置入口在哪是全局设置还是某个页面内有单独的开关默认状态是开还是关开关的作用范围是什么是只影响App内推送还是连短信、邮件一起控制修改之后是立即生效还是下次登录生效用户没有登录能不能看到这个开关点了会不会跳登录接收通知的具体行为是什么App内横幅、角标、锁屏推送哪些算“通知”你看一句话就拆出至少六个验证点每个验证点又会衍生出多条用例。拆解的思路是先找需求里的名词和动词。名词是对象用户、通知、设置项动词是行为设置、接收、变更。每出现一个对象和行为的组合就想想这个组合下“可观察到的变化”是什么。1.2 测试点走向用例的颗粒度控制拆出测试点之后接下来是定颗粒度——一个测试点对应几条用例。这个度很难用一句话说清我自己的标准是一条用例应该是“一个独立可执行的验证场景”。什么叫独立可执行就是别人拿到这条用例不需要看你脑补的上下文不需要去翻第几条用例里的环境准备就能按步骤执行并判断结果。从这个标准出发一个测试点拆成多条用例是很正常的。还是用通知开关来说。测试点是“修改开关后立即生效”你可以这么拆用例编号验证场景前置条件优先级NT-001在设置页关闭通知开关后App内不再弹出新消息横幅已登录账号A有一条未读新消息P1NT-002在设置页关闭通知开关后锁屏界面不出现新消息推送已登录账号A应用在锁屏下收到一条新消息P1NT-003在设置页关闭通知开关后角标数字不再增加已登录账号A应用角标当前显示3P2你可能觉得这有点啰嗦同样是“关闭开关”为什么要分三条写因为在移动端横幅、锁屏推送、角标经常走不同的推送通道有的走厂商推送有的走自家长连接某些版本会出现“关了开关横幅没了但角标还在涨”的bug。分开写一方面是为了定位问题方便另一方面是回归时如果有一条挂了你能快速判断是哪个通道出了问题。1.3 需求不明确时的应对把问号写进用例实际项目里需求文档永远不可能把细节写全。你拆解需求时一定会遇到“产品自己也没想清楚”或者“开发说这块按现有逻辑兼容”的情况。这时候最忌讳的是自己在脑子里补一个假设然后按这个假设去写用例。我的做法是在用例里加一个“待确认”标记把不确定的地方明确列出来。比如“该功能对未登录用户是否可见待产品确认当前用例按可见处理”“通知开关关闭后历史已读消息是否清除待开发确认当前用例按保留处理”“修改通知设置的生效时间默认按立即生效设计待后端接口确认”这些批注在用例评审时就是最好的讨论素材。评审不是拿着文档一条条念而是要把这些问号逐项过掉。你会发现很多线上事故和返工根源就是这些需求盲区在开发阶段没人发现测试用例又是按“脑补的正确答案”写的自然测不出来。把问号写进用例等于提前把需求评审中漏掉的问题暴露出来这是用例设计阶段最有价值的工作之一。2. 优先级取舍你不可能把整个宇宙测完但能把最重要的先写对我见过最极端的一份用例给一个简单的用户注册功能写了120多条用例光验证“用户名输入框”就写了20多条——长度、字符集、全角半角、前后空格、特殊字符、超长密码、空密码、错误确认密码……每一条都逻辑正确但没人跑得完。问题出在用例设计的目标是发现bug和控制风险不是在量上取胜。当你把大量低价值用例堆进测试计划核心流程的回归反而会被稀释轻则测试时间不够重则关键路径漏测。2.1 核心链路优先先测“用户一定会走的那条路”写用例之前我会先画一条核心业务链路。以电商订单为例用户用你产品的路径是搜索商品 → 查看详情 → 加入购物车 → 结算 → 提交订单 → 支付 → 收到支付结果。这条链路上任何一个环节出错用户都无法完成购买这是P0中的P0。核心链路的判断标准我一般是这么看的高频大多数用户每次都会走的路径高影响出错会直接导致资金损失、数据丢失、核心业务中断不可绕过没有替代方案断了就断了。按这个标准订单提交流程里的“库存不足提示”“重复提交拦截”“支付回调处理”都是P0因为他们直接影响用户完成下单和支付。而“头像修改后昵称展示位置”这种虽然也在链路上但它是体验类问题撑死算P2。核心链路写完之后才轮到主流程分支、异常分支、边缘场景。很多人顺序是反的先写输入框校验、再写列表翻页、最后想起主流程还没写结果主流程写得毛糙这种用例跑起来就是走过场。2.2 边界值和异常流不是炫技是拦截“脑补出来的正常”新人喜欢把等价类、边界值这些词挂在嘴边但实际写的时候常常只写“正常值”或者反过来把所有非法输入全部罗列一遍分不清重点。我的原则很简单边界值一定要测但优先测那些可能出真实bug的边界而不是教科书式的每个边界都来一条。拿一个“搜索关键词长度上限100字符”的需求来说。常规边界值是0、1、99、100、101。但实际上前端可能已经限制了输入长度你根本输不进101个字符。这时候真正要关注的是后端接口层的边界传101字符会怎样是报参数错误还是直接截断这种问题经常在前后端校验不一致的时候暴露。所以用例要覆盖两种视角前端输入视角和后端入参视角。前端测不到的地方用接口测试补后面我会专门讲接口用例怎么设计。异常流异常场景的优先级我一般按“出问题的概率×出问题后的影响”来排。比如支付场景里的弱网、超时、支付回调丢失概率不低影响极大必须写。而像“用户恶意连续点击支付按钮100次”这种概率低、有兜底逻辑写一条P2就够不用展开到10条。2.3 优先级标定P0/P1/P2/P3怎么分不吵架关于优先级每家公司都有自己的定义我比较认可这样一套优先级定义典型场景质量标准P0核心链路必经之路不通过就发不了版登录、支付、订单提交、核心列表加载必须100%通过P1主流程的异常分支或影响面较大的功能重复提交、库存不足、网络超时、权限校验失败必须95%以上通过P2非主流程的功能逻辑、体验类问题列表空态、文案错误、加载动画、消息排序可小范围遗留有workaroundP3边缘场景、低概率事件极端字符、多端同时操作、弱网超15秒记录不阻塞发版这套分法不一定适合所有项目但它有一个很重要的价值让用例评审有了共同语言。以前评审时产品说“这个功能很重要要多测”开发说“这不会出问题”测试夹在中间谁也说服不了谁。有了量化标准你可以直接问“这个场景属于哪一级影响面有多大你能举例说明用户会遇到吗”讨论会从主观感受变成基于事实的取舍。3. 落到文档一条用例的完整写法别再让执行的人猜设计完毕之后剩下的就是把场景写成文档。这一步看似机械实际上最见功底。很多用例跑不起来、执行效果差根因都是文档本身就写得有歧义。3.1 用例标题一句话说清楚“条件操作期望”不好的用例标题是这样的“登录功能测试”“验证注册页”“订单列表”你以为你写清楚了执行的人打开用例面对三个问题登录功能那么多场景你测的是哪个是正常登录还是密码错误期望结果是什么每一项都要点开详情才能知道执行效率极低。我写标题遵循一个公式前置条件在什么状态下 具体操作做什么 期望结果系统该怎样。举例“未注册手机号登录时页面提示‘账号不存在’停留原登录页”“已登录用户提交订单后重复点击提交按钮只生成一笔订单”“商品详情页库存为0时点击‘立即购买’按钮置灰且不可点击”这样的标题执行的人一眼就知道这条用例在干什么甚至可以不用点开详情直接跑。对自动化测试来说标题还能直接变成测试用例描述一个字段搞定多个需求。3.2 前置条件和步骤的精度控制别写“正常登录”这种废话前置条件是用例里最容易被敷衍的部分。很多人写“已登录状态”“已有一个商品”实际上执行的时候根本没法复现。正确的时间点应该在写用例时就把环境准备想清楚。比如“已注册账号且账号密码已知test_001/123456登录后进入首页”“后台已创建一个待审核状态的店铺店铺IDSP20240001”“测试手机已连接弱网模拟环境带宽限速100KB/s”步骤的颗粒度也值得注意。操作步骤描述得太粗执行的人会无从下手太细又像在教人用计算机。我的经验是写到“一个不可再拆的交互动作”为止。“提交订单”是粗的“点击提交订单按钮”是一个交互动作可以。“输入用户名和密码点击登录”是合法的因为这是连续操作。“输入一些数据进入结算页”不合格因为“一些数据”是模糊的。打开App进入登录页输入已注册手机号13800000000密码Abc123456点击“登录”按钮预期跳转至首页右上角显示用户昵称“测试用户”这是一个我能接受的步骤写法简洁但无歧义。如果你还想更严谨可以把“已注册手机号”也前置到数据准备里说明避免执行者临时去找账号。3.3 预期结果写“现象”不写“正常”两个字我相信你一定见过这种用例“点击保存按钮提示正常”。什么叫正常保存后按钮变灰出现loading跳转到列表页还是弹“保存成功”的toast连预期结果都不清楚执行的人哪怕看到了一个bug也会犹豫然后大概率把用例标记为通过——因为“看起来没什么大问题”。预期结果应该具体到这个程度“点击保存后按钮变为置灰状态页面出现loading2秒后自动跳转至列表页列表第一行展示新保存的记录”“POST /api/order/submit 返回code0订单状态为WAIT_PAY数据库order表中生成一条记录order_no以ORD2024开头”“输入错误的验证码点击登录按钮下方出现红色文案‘验证码错误’不发起登录请求”总之预期结果要能明确判定“通过”还是“不通过”。宁可写得多一点也不要为了省事写“正常”“成功”“正确”这种模糊词。这个习惯尤其重要——如果你以后要把用例转自动化预期结果是断言的唯一依据一个“正常”会让你连脚本都写不出来。4. 写完用例只是开始评审、执行和迭代里的事用例写出来不是终点后面还有评审、执行、回归、维护这些环节才真正决定用例能不能发挥作用。4.1 用例评审怎么避免变成“你读我我读你”的走过场用例评审是测试团队最容易被诟病的环节因为很多评审会真的变成“逐条念用例”念完散会没有任何有效结论。我有几个做法让评审会真正有产出评审之前我会把用例先自走查一遍。怎么自走查就是打开用例管理系统拿一套真实测试数据把每条用例的脑袋思维里跑一遍看步骤是否完整、前置条件是否可复现、预期结果是否可判断。这个动作至少能筛掉三成明显的低级问题比如写错字段、步骤缺失、预期结果没写。评审会上我会先花5分钟讲三个重点这条需求的核心业务链路是什么我在哪里做了取舍为什么有些场景不测我标注了哪些“待确认”项先对齐设计思路再逐条过用例细节。这样做的好处是大家一开始就把注意力放在“需求理解是否一致”上而不是抠一条用例的措辞。最后评审的重点应放在“这条用例验证的是哪个需求点”上而不是“你的用例格式对不对”。当有人提出“你漏了一个场景”正确的思考方式是这个场景是否属于当前需求影响面有多大是否纳入当前版本形成一个“补充/不补充”的明确决定而不是在会议上无限展开。评审记录要有结论不要“回去再想想”。4.2 执行结果记录与缺陷关联让用例成为活资产用例执行最怕的是“为了提交记录而记录”。有些团队回归测试跑完用例状态全部标“通过”但现场能拿出手的缺陷报告基本没有。这样的回归等于白跑。我习惯在每轮执行中保留两个数据用例通过率执行用例总数/通过用例数这个数字直接反映版本质量失败用例关联的缺陷单每条失败用例至少要对应一张可追踪的缺陷单能定位到具体环节。还有一个细节是执行记录要写实际环境。是在哪台设备、哪个系统版本、哪个数据包条件下跑的因为环境不同复现结果会差异很大。比如同一个功能在iOS 17和iOS 18上表现不一样你记录里写清设备型号和系统后面定位问题能省很多时间。4.3 用例维护需求变更后先改用例再测新功能这是我认为最重要的一个习惯也是很多团队做得很差的地方。需求变更是常态但用例不能跟着改。结果就是这个版本用例过期了下一个版本被测的还是旧需求新需求反而没人覆盖。我给自己定了一条规则需求变更后第一步不是去测新功能而是先回答“哪些旧用例失效了、要更新哪些新场景要补充”。举例来说需求从“用户可设置是否接收通知”改成了“用户可分别设置私信、评论、点赞三类通知”。受影响的场景一是旧的“总开关”用例要废弃或改写成新的分类控制逻辑二是要新增“只关闭评论通知时私信和点赞仍能正常推送”的用例三是回归重点从“一个开关是否生效”变为“三个开关的排列组合及互不干扰”。如果这些用例没跟着改直接去测新功能很容易出现老功能回归通过、新功能单独测也通过但组合情况下各种诡异问题。我建议用简单的Excel或测试管理工具维护一个映射表需求变更编号、涉及模块、影响用例编号、新增用例编号、变更日期、测试负责人。每次变更都更新这张表长此以往你的用例库会一直保持与当前需求同步而不是一个躺在角落里发霉的历史文档。5. 接口测试用例从功能用例到自动化用例的跃迁很多人会把功能用例和接口用例当成两个独立的东西但实际工作中它们是同一份需求的一体两面。功能用例测的是用户可见的行为接口用例测的是系统内部的数据流转。谁更会从功能用例反推接口用例谁就能在前后端联调阶段提前发现问题。5.1 接口用例的核心关注点接口用例和功能用例最大的区别是前端页面的很多限制到了接口层是不存在的。前端输入框最多让你输100个字符但调接口时你可以在参数里塞一个5000字符的字符串前端按钮只能点一次但你可以用脚本并发发10个请求。所以接口用例的核心关注点往往是入参边界必填、可选、边界值、超长、特殊字符、错误类型权限校验未登录、无权限、越权访问、token过期业务规则库存不足、余额不足、状态非法、重复提交返回值结构与业务码code、message、data是否符合约定数据落库接口返回成功但数据是否真正写到了数据库字段值是否正确。5.2 从功能用例反推接口用例举一个很典型的场景。功能用例写了“注册时手机号已存在页面提示‘该手机号已注册’”对应的接口用例至少需要覆盖用已注册手机号调用注册接口返回 code1001message“该手机号已注册”用未注册手机号调用注册接口返回 code0并创建新用户不传手机号、手机号为空、手机号超11位、手机号含字母分别返回什么同一个手机号并发注册两次会不会生成两个账号已注册用户用同一个手机号重复注册是否被拒绝。你看第五个场景就是从功能用例里不容易直接想到的。前端页面由于按钮置灰、接口跳转等限制很难触发并发注册。但接口层没有这些限制一旦没做幂等处理就可能产生脏数据。接口用例还有一个值得专门关注的点返回成功但实际没生效。开发经常犯这种错误——接口写了返回code0但业务逻辑在某个条件下直接跳过数据库没更新。所以接口用例的验证不能只看返回值要查库确认数据状态。没有数据库查询权限的测试接口测试的价值会大打折扣。写接口用例时我习惯把请求的样例数据直接贴在用例里包括请求路径、方法、请求头和请求体执行的时候直接复制去调试工具或自动化脚本里跑。这样可以避免执行人员因为“不知道参数怎么构造”而卡住也为后续自动化沉淀了现成的模板。我在实际写用例的过程中发现自己的很多问题都出在“只想着把用例写出来”而不是把用例当作一条“验证某个业务风险的可执行路径”。当你把思维从“覆盖功能点”切换到“覆盖业务风险”的时候用例的数量会自动缩减质量会明显提升。比如遇到一个历史bug反复出现的模块我会在写新用例前翻一下这个模块过去几个月的线上问题记录把那些高频问题场景作为新用例的固定条目而不是每次只按需求文档来。这个过程没有太多捷径就是把每次教训都沉淀成用例。时间长了你会发现真正有用的用例就是那些能拦住线上事故、能在一分钟内判断版本能不能发的用例。至于数量现在反而没人关心了因为大家关心的是回归跑完能不能放心。