1. 先从“高效”说起到底什么样的用例才算高效做测试这行写用例几乎是每天的必修课。但说实话我见过太多测试同学把“写用例”变成一种流水线作业需求评审一过开始对着功能清单逐条罗列一条登录能写出十几条用例界面上的每个输入框都恨不得拆成“为空、超长、含特殊字符、正确输入”四件套。最后用例数量是上去了评审也过了但一到版本迭代用例库就成了摆设——没人更新、没人看、跑回归也跑不完。这不是高效这是“高产”的假象。高效测试用例的定义我的理解是四个维度同时达标覆盖高、执行快、维护省、能定位。覆盖高既能覆盖正常主流程也能覆盖边界和异常路径但又不是靠“堆数量”来实现覆盖而是靠分析方法把有限的用例组合出最大的覆盖范围。执行快用例步骤简洁前置条件干净不依赖复杂的测试数据准备能在短时间内跑完一轮冒烟或回归。维护省需求变更时你能在十分钟内找到受影响的是哪几条用例而不是在几百条用例里挨个翻。这一点在快速迭代的团队里比什么都重要。能定位用例失败时测试结果能告诉开发是哪个功能点、哪个条件出了问题而不是报错信息指向不明、大家来回猜。换句话说高效用例的价值不在于“写了多少条”而在于“每一条有没有单独存在的必要”。如果一个功能点别人用8条用例就能覆盖到和你20条用例同样的风险那剩余的12条就是负担。我自己在评审用例时最常问的一句话就是这条用例删掉我们的测试风险会变大吗如果不会那它就是冗余的。这篇文章会从需求拆解、用例设计方法、编写规范、评审标准、维护策略几个角度把我这些年写用例、审用例、用用例跑回归的实操经验拆开来讲。适合刚入行的测试新人快速建立体系也适合写了两三年用例但总感觉“差点意思”的同学参考对照。2. 写用例之前需求拆解比用例设计本身更重要很多人觉得写用例难其实难的不是用例而是需求没吃透。拿到需求文档直接开始写用例等于带着一张模糊的地图去陌生的城市走哪算哪出了问题再回头补。而高效用例的前提是先做一轮完整的需求拆解。2.1 需求拆解的三层结构功能需求、业务规则、数据约束我习惯把需求拆成三层来看第一层是功能需求也就是用户能直接感知到的操作行为。比如“用户可以通过手机号登录系统”“用户可以修改个人资料”这一层解决的问题是系统到底提供什么能力第二层是业务规则这是最容易被测试忽略、也最容易出问题的部分。比如“新用户注册后7天内可享受首单优惠”“订单金额超过一定阈值需要走审批流程”这些规则往往分散在需求文档、产品沟通记录甚至开发代码里需要测试主动去挖。我见过很多漏测事故都是因为业务规则没有被用例覆盖而不是功能本身有问题。第三层是数据约束包括字段类型、长度、格式、取值范围、必填与否。数据约束通常是后续等价类和边界值分析的基础素材拆得越清楚后面设计用例越顺手。2.2 把需求翻译成“规则清单”再动手拿到需求后我建议先别急着打开用例管理工具而是拿一张白纸把所有能想到的规则列出来。比如一个搜索功能规则清单可能是这样的搜索关键词必填为空时前端拦截并提示最大支持50个字符超出后不允许输入支持模糊匹配和精确匹配两种模式搜索结果默认按相关度排序可按上架时间、销量筛选无搜索结果时展示空状态页面和推荐内容搜索历史只保留最近10条这份清单不需要讲究格式关键是穷尽。列完规则之后再对照每条规则去设计用例你会发现清晰很多。这个习惯我坚持了多年它最大的好处是用例设计变成了“翻译”而不是“创造”。你不必临场苦想该测什么只需要把每一条规则翻译成可验证的测试场景即可。2.3 需求信息不完整时正确姿势是“主动补位”现实工作里需求文档永远赶不上变化。产品描述模糊、开发有历史逻辑、运营临时加需求这些都是常态。遇到这种情况我的处理原则是用例里明确标注“待确认项”而不是默默跳过。比如某个字段的边界值未知我先按行业常见规则比如手机号11位、密码8-16位设计用例同时在用例备注里标明“此处边界值待产品确认评审时讨论”。等需求评审会一开这些待确认项就是你要问的问题清单。这样做的好处是你不会因为需求不完整而卡住进度也不会因为想当然而漏掉关键规则。3. 用例设计的核心方法这些分析方法比经验可靠很多测试同学的经验论是“我凭感觉知道哪里容易出问题”。但感觉这个东西不稳定换个项目、换个系统可能就不灵了。真正高效的做法是用系统的分析方法把可能出问题的点穷举出来。下面这几种方法是我日常使用频率最高的按重要程度排个序。3.1 等价类划分把无限输入拆成有限代表等价类划分的核心思想是如果一组输入对程序的处理逻辑来说是等价的那么只需要选一个代表来测试就够了。比如一个录入年龄的输入框业务规则是“18-60岁有效”那么输入25和输入48在程序逻辑里没有本质区别测一个就行。实际操作中我通常把等价类分成三类来梳理有效等价类满足业务规则、能被程序正常处理的输入。比如年龄在18-60之间的整数。无效等价类不满足业务规则、程序应当拒绝的输入。比如年龄为0、负数、大于60的数字、非数字字符。边界等价类有效区和无效区的交界点比如17、18、60、61。这套方法解决的是“测不完”的问题。输入是无限的但处理逻辑分支是有限的每个分支覆盖一个代表值就能以最低成本达到覆盖目的。3.2 边界值分析Bug最爱住在“临界点”测试界常说的“80%的Bug出在边界附近”不是没有道理。原因在于开发在写条件判断时最容易出错的就是和、和的边界混淆。比如判断年龄是否有效开发写成了age 18 age 60那18岁就被拦在门外了。做边界值分析时我常用的套路是“上点、离点、内点”上点边界上的点比如18和60离点离边界最近的点比如17和61或者按开闭区间取上点一侧最近值内点有效范围内的任意一点比如30不要小看这个方法。一次我在测试一个订单金额字段时开发设定“订单金额必须大于0且不超过9999.99”我特意测了0.01、0、9999.99、10000.00四组数据结果真的抓到了0被当作有效金额提交的Bug。边界值分析不复杂但它是性价比最高的用例设计方法之一。3.3 场景分析法从用户操作路径倒推用例功能点测试的局限在于单点正常不等于流程通畅。用户的真实使用往往是一连串操作的组合。场景分析法就是跳出单点从用户操作路径去设计用例。以购物车下单为例核心路径是“加购→购物车→提交订单→支付→支付成功→订单完成”。但依赖这条路径还有不少分支和异常路径加购后直接清空购物车再结算提交订单时商品库存不足支付过程中取消支付支付成功但回调超时重复提交同一订单场景设计的关键是分清楚哪些是主流程、哪些是备选流、哪些是异常流。通常主流程用例一定要保证通过备选流要覆盖主要分支异常流则重点验证系统的容错处理。3.4 判定表与正交法搞定组合爆炸有时候一个功能有多个条件每个条件又有多个取值组合起来数量爆炸。比如一个筛选功能有品牌5个、价格区间4档、排序方式4种光组合就是5×4×480种情况全部写成用例是不可能的也不必要。这种场景有两种处理思路判定表法适用于条件少但逻辑规则复杂的场景。把每个条件取值为“真/假”列出所有组合对应的预期结果优先覆盖结果不同的组合。正交试验法适用于条件多、但两两组合即达标的场景。从全量组合里抽取一组正交组合保证任意两个条件的取值组合都出现一次大大压缩用例数量。实际操作中我认为普通项目用判定表加场景分析就够覆盖大部分了。正交法的数学推导比较费精力适合条件特别多且用例数量要求严格的项目一般不作为日常首选。4. 用例落地的编写规范结构清晰才能“跑得快、修得快”设计方法决定用例“测什么”编写规范决定用例“能不能顺畅执行”。我审过不少用例很多设计思路其实不错但写出来的用例一到执行就卡壳——步骤描述不明确、前置条件没交代、预期结果含糊。这属于“设计好了没写明白”。4.1 一套标准的用例字段到底包含什么我建议每个用例至少包含以下字段缺一个都不完整字段要求反面案例用例编号与需求模块挂钩比如LOGIN_001无编号或随机编号关联需求写明所属需求ID或模块空着不填前置条件执行前需要准备的数据、环境、状态写“无”或含糊带过测试步骤编号列出操作步骤一条用例一个完整路径大段叙述分不清操作顺序测试数据明确输入的具体数值或文件写“随便填一个数字”预期结果可验证的、具体的期望表现写“页面正常显示”优先级P0-P3作为回归筛选依据全部P1等于没分这里想重点强调“测试步骤”和“预期结果”的关系。一步操作最好对应一个预期结果不要写“输入账号密码点击登录”然后把预期结果写在最后。因为一旦用例执行失败分步验证能立刻定位是哪一步出了问题而整段式写法只能靠猜。4.2 用例间要独立不要“连环套”我见过一些老测试写的用例习惯把上一条用例的结果当作下一条的前置条件。比如用例A验证“新增用户成功”用例B直接默认“存在一个已新增用户”。这样设计最大的坑是一条用例失败后面的用例连坐全挂排查成本成倍上升。正确做法是每条用例的前置条件尽量独立可复现。如果确实需要已存在的数据就在前置条件里明确写清楚“事前需预置一个状态为X的数据记录”同时提供数据准备的SQL或者造数命令。遇到需要登录态的接口用例统一通过token或者公共测试账号来准备而不是依赖某条用例的运行顺序。4.3 预期结果描述要“可判断”写预期结果最忌讳的用语是“正常”“成功”“无异常”。这三个词在评审时看着没问题拿到手上执行时完全不知道怎么判定。比如“点击保存保存成功”——什么叫保存成功弹窗提示列表刷新数据库有记录还是接口返回200可执行性强的预期结果应当描述为“点击保存后页面弹出『保存成功』提示且列表页出现刚才录入的记录”。每一项都是肉眼可见、或者可以通过工具验证的状态。做到这一步用例的可执行性和可判断性就都上来了。4.4 数据驱动把测试数据和用例步骤分开优秀的用例结构应该把数据和步骤分离。步骤描述的是“操作路径”数据是操作路径上的参数。比如“在搜索框输入关键词点击搜索校验搜索结果”是一条通用步骤而关键词的具体取值正常词、超长词、特殊字符单独管理。这样做的好处显而易见数据复用。一条步骤可以被多组数据复用不用为每组数据复制一条用例维护方便业务数据变了只改数据文件步骤不用动。在接口自动化测试里这种做法几乎是标配手工测试用例里也同样适用。5. 用例评审与维护别让用例库变成“一次性用品”写完用例只是第一步真正让用例发挥长期价值的是评审把关和持续维护。5.1 评审时重点挑这四类问题用例评审不是走过场我一般带着四个目标去看有没有漏测对照需求规则清单逐条勾选重点看边界、异常、权限、兼容相关场景有没有覆盖到。有没有无效用例执行结果对测试目标没有贡献的用例该删就删。比如纯重复的多浏览器兼容用例如果项目目标明确只支持某一款浏览器就不必为凑覆盖率而硬加。有没有冗余用例两条用例覆盖的是同一个逻辑分支保留更精简的一条即可。优先级是否合理P0用例应该是主流程和核心规则P1是重要功能分支P2/P3放低频和边缘场景。优先级分错回归的时候按优先级筛选就不准了。5.2 需求变更时用例该如何“跟着变”需求迭代是常态但很多团队的用例库在需求变更后就彻底失联了。我认为用例跟随需求变更的正确姿势是“变更当天同步不积压”。每轮迭代结束前花一个番茄钟对用例库做一轮体检新增了哪些功能、砍掉了哪些逻辑、改了哪些规则。对应到用例库就是三条操作——新增、禁用、修改。新增功能补充对应模块的新用例哪怕功能还没完全提测先把用例设计跟上。砍掉的功能不是删除而是禁用并打上“废弃”标记。因为你不知道这个功能会不会在下一个季度加回来而且清空历史数据会丢追溯依据。改规则优先修改原有用例而不是新建替代用例。一条用例的演进记录比散落的新旧两版更有价值。5.3 分层管理冒烟、回归、全量各司其职按执行频率把用例库分层是控制回归成本最有效的做法之一。冒烟层P0核心主流程用例大概占总量10%-15%每次跑一版控制在10分钟内执行完。回归层P1主流程加关键业务规则占30%-40%每次版本发布前必跑。全量层P2/P3覆盖边界、异常、低频场景每周或每月跑一次。分层管理的价值在于日常迭代用不到全量库你不需要在每次发布前把几千条用例拉出来跑一遍这样就大幅压缩了执行时间。同时也避免了一个经典痛点用例库又大又全但没人愿意付出那么高的执行成本最后干脆不跑回归了。5.4 定期清理“僵尸用例”时间久了用例库里会出现大量“从来没人跑”的用例。它们还挂在系统里但既不在冒烟层也不在回归层只是占着位置让用例总数虚高。我每年会做一次用例库大扫除主要看两类半年内没有执行记录的用例、执行了但从来没有失败过的用例。前者可能是被废弃但没清理的存量后者可能是覆盖目标已消失的“历史遗留”。杀僵尸用例的底气在于一个不被执行的用例无论写得多好都等于不存在。与其让它们躺在库里制造虚假的覆盖率不如删掉或归档让用例库保持精简和真实。6. 写用例时的常见坑和我的对应解法最后一章列几个我踩过的、以及帮别人review时经常看到的坑顺便附上解法希望能帮大家绕过去。6.1 “一条用例测多个功能点”典型表现用例步骤写了“输入账号密码登录进入首页点击某个菜单再修改一条数据保存”预期结果里同时包含了登录成功、菜单跳转正确、数据修改成功三件事。执行失败时到底哪一步出了问题你只能凭眼力和运气去猜。解法很简单一条用例只测一个完整场景。如果登录只是前置条件就把它放到前置条件字段里写清楚步骤从登录后的操作开始。6.2 只测“应该发生”的不测“不该发生”的新手写用例往往习惯验证“正确操作得到正确结果”忽略了负向场景。但负向场景恰恰是Bug的高发区。核心规则是每个关键功能的用例至少要覆盖一条“非法输入被拒绝”的负向用例。刚入行时我写过一段时间的用例一个功能清一色的“正向验证”结果那个功能上线后被用户提交了诡异特殊字符系统直接报错。从那以后我写用例必问自己一个问题如果用户不按套路操作会发生什么6.3 用例编写时机过晚有些团队的习惯是等开发提测了才补用例结果用例设计变成了“对着实现写验证脚本”本质上是在帮开发确认代码没写错而不是在检验需求对不对。我的建议是用例设计在需求评审阶段就启动开发提测前用例至少要完成80%。这并不是要求大家提前把所有细节敲定而是先把用例框架和主要场景铺出来当作需求评审的讨论素材。等到提测后再补边界和异常场景执行前完成终版。这样做还有个隐藏好处早期用例能提前暴露出需求矛盾省掉后期返工的痛苦。6.4 预期结果写成“系统抛出异常提示”这种写法只说了程序的输入输出类型没有具体到文本内容。每个异常分支的提示语、颜色、位置、页面跳转都应该写明多写一行字的事执行时能省不少沟通成本。我在实际项目管理中还养成了一个习惯每轮版本结束后挑5条线上故障案例反推用例库。看看这个线上问题对应的场景在用例库里有没有覆盖如果没有就补上有但没执行到就查为什么。这样做一轮用例质量就会有明显提升两三轮下来漏测率肉眼可见地下降。测试用例这件事说难不难说简单也不简单。它是一门需要持续打磨的手艺工具和平台都是次要的关键是你愿不愿意在设计阶段多花一倍的时间去换执行和回归阶段省下的三倍时间。我自己最大的体会是一份好的用例库不是写出来的是改出来的——在一次次评审、一轮轮迭代、一回回故障复盘里慢慢长成了它该有的样子。
