聊到测试用例这个话题我脑子里冒出来的第一件事就是刚入行那会儿战战兢兢地写了人生第一份测试用例结果被老测试组长批得一文不值。他说了一句话我记到现在你的用例不是在测软件是在给开发写操作手册。后来我在不同的项目里摸爬滚打从功能测试做到测试管理又带过好几届新人发现一个问题特别普遍——很多人张口闭口提测试用例但真要问一句测试用例的要素是什么你怎么保证用例不遗漏能答利索的人真不多。至于设计测试用例的万能公式这六个字在行业里传得很广有人当它是段子有人当它是真经。我今天就把这层窗户纸捅破把我自己的经验和踩过的坑全部摊开聊一聊。这篇文章会从测试用例的核心要素讲起再把所谓的万能公式拆成一套你能直接拿去用的实操方法最后配上六大经典设计方法和一份避坑实录。不管是刚入门的新人、写了大半年用例还找不到章法的功能测试还是准备整理团队测试规范的测试负责人这篇文章都适合你。我尽量不拽术语能用大白话讲清楚的地方绝不含糊但该给的专业细节一个都不会少。1. 测试用例到底是个什么东西1.1 为什么你写的用例总被嫌弃先聊一个所有测试人都绕不开的场景你拿到一个需求吭哧吭哧写了二十条用例自认为覆盖很全面结果一到测试执行发现开发随手一个操作就把系统搞崩了而你的用例清单里压根没这条路径。问题出在哪儿不在于你不够细心而是你压根没搞清楚测试用例的本质是什么。测试用例本质上是一纸契约它约定的不是一个操作动作而是输入、条件、期望结果这三者之间的一组映射关系。它要让执行用例的人可能是你、可能是新人、也可能是外包在完全不了解业务背景的前提下按照步骤就能判断系统是不是符合预期。很多新手把用例写成了操作手册每个步骤写得极其细致唯独漏掉了最关键的东西预期的业务结果。这就是为什么你的用例会被嫌弃。再往深了说测试用例是测试人员的工作输出物也是测试团队和生产团队之间的沟通语言。开发拿到你的用例能知道你要测什么维度产品经理拿到你的用例能确认需求是否被完整落地验证将来接手这个模块的同事靠你的用例就能快速了解系统行为。所以一份好用例永远不是写给自己看的草稿本而是写给所有人看的说明书验收单。1.2 用例设计价值从会执行到会设计很多测试新人有个误区以为会执行用例就等于会测试。你让他去照着用例点一遍他能给你点出花来但让他独立负责一个新模块的测试设计他当场就懵了。这两者之间的差距就是执行思维和设计思维的差距。执行思维关注的是每一步怎么点设计思维关注的是这个功能有哪些行为需要被验证。我见过一个特别典型的新人测一个导出功能他把所有正常导出路径都测了一遍就宣布测试完成。结果上线后用户反馈导出任务在后台跑着的时候用户又提交了一个新的导出请求系统直接把前面的任务覆盖了数据全丢。这个场景在用例里完全没覆盖到因为新人压根没去思考已存在一个进行中的任务这个前置条件。这就是用例设计真正的价值所在它强迫你在动手测之前把系统可能出现的所有状态、所有输入、所有分支全部在脑子里推演一遍。通过设计用例你不是在找bug你是在模拟整个系统的行为画像。而这个画像能否画得完整取决于你对下面要讲的测试用例要素和设计方法到底掌握了几分。2. 测试用例的核心要素一条好用例必须具备的关键字段2.1 八大基础要素逐个拆解不同公司、不同测试管理平台里的用例字段可能长得不太一样有的叫用例标题有的叫场景名称但剥掉皮肉骨子里都是一套东西。我自己沉淀出一套八大要素去要求团队照着这份清单写至少不会出大问题。如果是纯手工测试最基本的用例要素是编号、标题、前置条件、测试步骤、输入数据、预期结果。如果放在测试管理平台比如某禅道、某Jira、某TestLink一般还会加上所属模块、优先级、用例类型、创建人、关联需求这些。我一个个说用例编号唯一标识一条用例一般用项目简称-模块-序号来组。比如LOG-PC-LOGIN-001一看就知道是登录模块的第一条PC端用例。编号这事儿没技术含量但有强迫症的意义——评审的时候你直接说编号对方马上翻到对应用例不用你口播半天。用例标题一句话讲清楚这条用例要验证什么行为。这最常见的问题是写得像一团浆糊比如验证登录功能这种标题你根本看不出它测的是正确密码登录还是密码错误登录。我要求团队写标题用一个句式验证xxx条件下执行yyy操作得到zzz结果例如验证输入正确用户名和密码点击登录按钮后成功进入首页。前置条件执行这条用例之前系统必须处于什么状态、需要什么数据准备。很多新手轻视前置条件两条用例连着执行这条失败的下一条也跟着失败回头定位了半天发现是上一条用例污染了环境。前置条件没写清楚执行的人是没法顺畅干活的。测试步骤按顺序列出触发测试行为的具体操作。这里有个度的问题步骤太粗就说登录系统没法执行步骤太细移动鼠标到输入框左键单击输入a再输入b...就成了操作手册维护成本巨大。我一般要求步骤写到可唯一执行的程度比如输入账号输入密码点击登录按钮谁看了都不会做错。测试数据这一条要跟步骤拆开看。测试数据指的是用例中使用的具体输入值比如用户名是zhangsan密码是Abc123456。设计的时候不光要写值本身还要写明这个值属于哪一类数据有效等价类、边界值等这样用例评审的时候别人才能理解你为什么选这个数。预期结果这是整条用例的灵魂。没有预期结果的用例执行起来全凭执行者的心情判断对不对。预期结果要写可观察、可判定的结果既要包含界面表现页面出现登录成功提示、跳转首页也要包含数据变化数据库写入一条登录日志、状态流转用户状态变为已登录。优先级高/中/低跟风险直接挂钩。核心功能、频繁使用场景、曾经出过bug的模块用例优先级就高边缘场景、低频操作优先级就低。有了优先级回归测试才知道先执行谁。用例类型功能测试、接口测试、UI测试、兼容性测试等。这个字段在大型项目里很有用筛选执行的时候效率很高。2.2 用例要素的常见通病和标准案例我把团队里最常见的要素丢失场景给你列一下你拿去当反面教材也好当自查清单也好。先看一个反面案例这是我随手从过去项目里脱敏后还原的用例标题用户名密码错误登录前置条件空步骤输入账号输入密码点登录预期结果提示错误这条用例最大的问题有四个第一标题没有说清楚错误是哪种错账号错密码错还是都错第二没有前置条件如果当前系统已经处于登录态呢那点登录根本不会出现第三没有写测试数据12345和Abc123456不同的错法系统提示可能完全不同第四预期结果里提示错误太模糊到底弹窗提示还是页面内联提示提示文案是什么都不清楚。再看我要求的标准写法用例标题验证输入正确用户名和正确密码点击登录按钮后成功进入系统首页前置条件用户账号已注册系统处于未登录状态登录页已打开测试步骤#1 输入已注册的用户名zhangsan#2 输入正确的密码Abc123456#3 点击登录按钮测试数据用户名zhangsan有效等价类、密码Abc123456有效等价类预期结果#3 之后页面跳转至首页右上角显示用户昵称张三数据库 user_login_log 表新增一条记录登录状态接口返回 code0你对比一下就知道差距在哪儿了。要写出一份标准用例脑子里始终绷紧一根弦任何一个执行用例的人能不能不猜、不问、不打开源码就照着用例把这条跑完并且知道对不对。如果答案是能这要素就合格了。如果哪一步要靠猜那这个要素必须改。3. 设计测试用例的万能公式到底长啥样3.1 公式的本质不是公式是穷举逻辑万能公式这个词我最早是在一次内部技术分享会上听一个大佬提到的。当时底下新人眼睛放光等着大佬掏出来一个能套遍所有项目的公式结果大佬在白板上写了三行字很多人当场泄气。那三行字我现在还记得正常路径 异常分支 边界数据 完整用例集听起来像废话对不对但后来我做了这么多年越品越觉得这句话其实已经把整个测试设计的底层逻辑全讲透了。所谓的万能公式真正的价值不在于给你一套机械填写的模板而是给你一种穷举思维你每设计一条用例都必须自问三个问题——第一这件事在正常条件下应该怎么表现第二这件事在异常条件下会不会出问题第三数据在边界值附近时系统是什么反应如果这三类路径都覆盖到了你的用例清单基本上就不会出现大的漏测。所有看似高深的测试设计方法——等价类、边界值、场景法、判定表、错误推测——本质都是在帮你从正常路径、异常分支、边界数据这三个桶里捞东西。你先建好这三个桶的骨架再把具体的方法当筛子往每个桶里套就不会手忙脚乱。3.2 通杀型的四步套用流程光知道三句话还不够我给你的不是概念而是一个落地流程。基于我的经验我管它叫需求四拆法第一步拆功能点。拿到需求文档先别想着写用例先把需求拆成功能点清单。以登录功能为例功能点至少包括用户名密码校验、登录成功跳转、登录失败提示、验证码校验、记住我、忘记密码跳转、登录接口防暴力破解。每个功能点就是一张独立的用例清单。第二步拆业务场景。功能点拆完后把每个功能点放进用户的实际使用流程里去看。别只盯着功能本身要问自己用户在什么情境下会走到这个功能点。比如登录功能至少要考虑首次登录、退出后再次登录、多端互踢后登录、长时间未操作后登录、异地登录。每一个情境都可能引出新的用例。第三步拆输入变化。这一步是灌入测试数据的过程也就是后面要讲的等价类和边界值。针对每个输入项把所有可能的数据类型、取值范围、特殊字符、为空、超长、输入格式非法全部列出来然后标记出哪些属于有效等价类、哪些属于无效等价类再单独把每个等价类的边界值拉出来生成边界值用例。第四步拆异常与逆向。这是大多数用例遗漏最严重的一步。你要站在搞破坏的角度问自己如果用户不按正常逻辑操作会怎样比如直接篡改URL跳越权限页、断网后点击提交、快速双击提交按钮、在结果返回前刷新页面。每想到一个异常场景就补一条异常用例。看到没有这四步走下来万能公式就不再是一句空话而是一条可操作的生产流水线了。你在实际项目中哪怕只悟透这四步的八成用例覆盖率就能超过团队里大多数人了。3.3 用登录功能现场演示套用公式产出用例光讲抽象流程你可能还是不太得劲。我就拿登录这个被写了无数遍依然有人写漏的功能现场给你套一遍公式。按照需求四拆法第一轮功能点拆解我已经在上一节列过了。接下来我直接进入第二、第三步把能想到的用例主线全部列出来正常路径输入正确用户名密码、输入正确验证码、点击登录成功进入首页。这是主流程必须保证绿色通过。场景变体登录成功后刷新页面登录态是否保持退出登录后按浏览器返回按钮是否会回到已登录页面在A设备登录后在B设备再次登录A设备是否被踢下线。输入变化用户名和密码分别套用有效等价类和无效等价类。有效等价类包括正常注册的账号无效等价类包括未注册账号、密码错误的账号、包含非法字符的账号、账号为NULL的情况。边界值上则要覆盖用户名长度的最小值和最大值比如数据库定义用户名长度为20那就测20位、21位、0位、1位。异常与逆向登录接口连续输错密码5次锁定账号防暴力破解登录成功后直接访问登录页看是否还能重复登录在弱网环境下点击登录按钮抓包看请求是否被重复提交登录页停留半小时再提交验证会话是否过期。这一圈下来登录功能轻轻松松就能铺出三十到五十条用例。很多人连一半都写不到就是因为在场景、输入、异常这三个桶里他只填了正常输入这一格。4. 六大经典用例设计方法把公式落实到颗粒度4.1 等价类划分法把无穷输入切成有限集合等价类划分是我最推荐新手先掌握的入门方法也是万能公式里填充测试数据那一桶最核心的工具。它的底层逻辑一句话就能说明白既然无法穷举所有输入那就把输入数据按照相同的测不测都一样的性质分成若干组每一组只需取一个代表值来测。以手机号输入框为例需求规定11位以1开头第二位为3/5/7/8/9。手写几十万个手机号去测显然是疯了但按等价类思路就很简单有效等价类包含以13开头的11位号码以15开头的11位号码等无效等价类包含12位号码10位号码以0开头的11位号码包含字母的号码空值等。每类挑一个数据测基本就能确认系统在这个输入域上的行为是否正常。使用等价类划分时有几个注意点第一有效等价类和无效等价类要一次各测至少一条用例现实中好多人只测有效等价类对无效等价类视而不见这只验证了系统正常时正常完全没有验证系统被乱搞时是否还能兜得住。第二空值永远是一个独立的无效等价类尤其是文本框空值和非空非法值的处理逻辑往往不同你不能用非空非法值的数据代替空值去测。第三同一等价类里如果出现了代表值测不过去的情况不要急着归咎于数据问题先确认这批数据是不是真的属于同一个等价类有些数据的边界性质可能被你漏掉了。4.2 边界值分析法bug最爱藏身的缝如果说等价类是大面积扫雷那边界值就是精确排雷。长期的测试经验反复证明程序在处理边界数据时出错概率远高于处理普通数据原因是开发在写代码时最容易忽略边界处的判断条件比如小于等于写成了小于或者 和 差了一个等号这种逻辑错误用普通数据测根本测不出来非得到边界值上才露馅。我举一个经典的年龄输入框需求要求年龄在18到60岁之间包含18和60。边界值分析要求你测这些值18下边界、17下边界减1、19下边界加1、60上边界、59上边界减1、61上边界加1再配合等价类补一条18到60之间的正常值比如30和超出范围的无效值比如0、150。这一组数据从最小值-1、最小值、最小值1、正常值、最大值-1、最大值、最大值1全部覆盖边界判断逻辑有没有写错一测一个准。这里我要特意指出一个很多人不知道的细节边界不只是数值大小还包括数量的边界时间的边界状态切换的边界。比如批量上传文件系统限制最多50个文件那49、50、51个文件就是边界值再比如优惠券有效期到23:59:59那在这一秒之前和之后提交订单就是边界场景。所以每次拿到一个需求你不要只盯着数字输入框找边界要多想想还有哪些地方存在数量限制、时间限制、状态切换限制那些地方全是边界值分析法的用武之地。4.3 因果图与判定表法处理条件组合的利器当一个功能的执行结果由多个条件组合决定时等价类和边界值就不太够用了。你拿三个判断条件每个条件有成立/不成立两种状态组合起来就有8种情况等价类划分只能告诉你每个条件怎么取值没法告诉你组合起来的系统行为对不对。这时你需要因果图和判定表。判定表的操作流程非常清晰第一步列出对应的条件桩和动作桩第二步计算组合数量每个条件的状态数相乘第三步填入所有组合第四步整理重复动作并简化。一般测试管理工具好多都支持把判定表直接生成用例但我在实际项目中更倾向于自己手工画一遍因为画的过程能逼你想清楚每个组合的商业含义。举个例子一个订单系统规定会员用户且订单金额满100元可享受8折优惠非会员金额满100元享受9折金额不足100元不打折。三个条件分别是是否会员是/否金额是否满100是/否组合出来4种情况对应3种动作。画好判定表4条用例全部覆盖不怕漏。这个例子比较简单但真实项目里动辄五六个条件、几十种组合用手工脑子记是记不住的判定表是唯一靠谱的工具。要特别提醒条件多的时候组合数会爆炸增长。六个条件双值组合是64种十个条件是1024种全测显然不现实。这时候就要学会踢掉无效组合比如已登录且未登录这种自相矛盾的条件再把剩下的有效组合按业务重要程度排优先级挑核心组合出用例其余组合可以靠接口自动化去补充覆盖别一头扎进组合的汪洋大海里溺死。4.4 场景法从用户视角串联用例场景法是我个人最喜欢、也是和万能公式里业务场景那一桶最为贴合的方法。它的出发点不是功能点或条件组合而是用户的故事——用户从进入系统到做完一件事整个过程中经历了哪些页面、操作和状态流转。场景法认为测试不应该只测一个个孤立的功能点而应该把这些点串成一条完整的业务链路。场景法最常用的模型叫基本流 备选流。基本流是用户完成业务最顺利的那条路径比如订机票搜索航班、选择航班、填写乘客信息、支付、出票成功备选流是各种偏离基本流的路径比如订机票过程中支付超时、乘客信息填写错误、航班已售罄。每一条备选流都可能在某个节点跟基本流相交也可能独立成流。实操起来我习惯先画场景流和节点图不用Mermaid就用最简单的文字清单然后每一个场景节点生成一条或者多条用例。这里有个关键点场景法测的是流程通的通不通不是细节对不对。很多新人用场景法写用例写着写着就回去抠单个输入框的边界值把场景流给丢掉了。我的建议是把两类用例分开场景流用例只管流程通不通——页面能不能跳转、状态能不能流转、数据能不能传下去——至于输入框的边界合法性让等价类和边界值的用例去覆盖两条腿各走各的路合拍才能走远。4.5 正交实验法当组合爆炸时找到最小覆盖上一节说判定表在条件多时组合会爆炸那有没有办法在组合数大到无法全测时用最少的用例覆盖最多的组合有就是正交实验法。这个方法源于统计学里的正交试验设计核心是在保证任意两个因素的所有组合至少出现一次的前提下大幅缩减用例数量。举个例子一个搜索功能有四个因素搜索关键词类型3种、排序方式3种、筛选条件3种、搜索范围3种全组合是3的4次方等于81种情况。用正交表比如L9(3^4)正交表拉出来只需要9次试验就能保证这4个因素两两位级的组合全部被覆盖到。这9条用例相比81条全组合覆盖率是天壤之别但覆盖效率极高非常适合用于配置项组合、兼容性组合这类条件多但不需要全排列的场景。实际项目中我不会让每个人都去啃统计学公式更常用的方式是直接用现成的正交表或者用测试设计工具比如微软的PICT自动生成正交组合。我尤其推荐PICT把因素和取值填进去几分钟就能导出一份覆盖良好的正交用例集。但我要给一个诚实的提醒正交法追求的是两两组合全覆盖不代表全部组合无遗漏它适合的是覆盖率换时间的场景如果条件组合中存在极高风险的业务逻辑该用判定表全组合覆盖的还是要老老实实用判定表。4.6 错误推测法靠经验直觉去找茬名字看起来玄乎说白了就是根据过去的经验、系统的特点以及人类的直觉去猜系统最容易在哪些地方出问题。这几位在前面所有方法里排不上号因为等价类、边界值、场景法这些都有明确的规则可循但错误推测法更多靠的是测试人员的第六感不过第六感不是凭空来的背后是对业务、对系统架构、对开发人员代码习惯的深刻理解。我在这里分享三个我压箱底的经验区你可以直接往这些区域投放错误推测用例一切有清零、重置、恢复默认功能的地方。用户一旦执行重置操作之前所有的自定义配置都会消失这类数据丢失是最常见的线上投诉来源。一切有复制粘贴操作的地方。用户从外部文档复制带格式的内容粘贴进网页输入框经常导致格式异常、长度超限或者脚本注入几乎所有产品都在这上面栽过跟头。一切有连续点击和快速操作的地方。按钮防重复提交、操作响应延迟、双击导致的双重数据插入都是开发极易遗漏的高频bug。错误推测法的用例一般没有专门的工具辅助全靠你自己在平时测试和线上问题中积累坏味道清单。我自己的习惯是准备一个个人知识库笔记随便用什么笔记工具每遇到一个线上bug立刻把它归类记录等到写新项目的用例时拉出来过一遍把跟新系统相关的场景直接转成错误推测用例。这个方法用久了你的用例设计直觉会越来越敏锐。5. 完整实操从拿到需求到用例落库的全流程5.1 需求分析与功能点识别前面讲了那么多方法现在把它们组装成一条完整的工作流水线。你拿到一份需求文档不管是PRD还是原型图还是口头描述第一步永远是需求分析。这一步不做后面全是乱打。需求分析阶段你要带着问题去读文档这个需求的目标用户是谁核心业务流程是什么涉及哪些数据对象有哪些状态变化有哪些异常场景是文档里没写但明显存在的我经常会在需求评审会之前就把这些问题列成一份清单打印出来带着问题去会上找产品经理和开发对答案。比如如果用户在支付环节点击取消订单积分还算不算如果上传的文件大小刚好卡在10MB限制上系统是接受还是拒绝这类一问一个准的问题就是我需求分析的全部价值所在。需求分析完成后开始做功能点拆解。我的习惯是用一张思维导图任何工具都行不局限在什么品牌从功能模块再拆分到具体功能点每个功能点下面挂出操作流程涉及字段关联状态异常分支四个分支。这张思维导图就是你后续写用例的地图没有地图就盲目开工大概率会在写用例写到一半时突然发现漏了一个功能点整体返工。5.2 用例编写与要素填充技巧地图有了接下来是动手写用例。从最优做法上讲我强烈建议你按模块分批写每写完一个模块的用例就自查一遍别攒到最后一口气输出几百条再回头检查那时候你根本记不清自己的思路脉络自查效果大打折扣。写用例的过程我按前面讲的八大要素逐一填充。有一个我反复强调的细节预期结果一定要掰开揉碎写清楚。很多测试专家会把预期结果拆成界面层预期和数据层预期两层来写。界面层预期是用户能直接看到的页面出现提示语、页面跳转到XXX数据层预期是用户看不到但系统内必须发生的数据库订单状态从待支付变为已支付日志里增加一条操作记录。两层都写了用例才算真正完整。在填充测试数据的环节你要时刻提醒自己每一条数据都要能注明出处。这个数据属于哪个等价类这个边界值是依据需求的哪条规定推出来的如果用例评审时被问到这个数据为什么选它你得能拿出依据。说不出来只能说明你设计用例时是拍脑袋而不是按方法推导出来的。5.3 用例评审与维护更新用例写完不是终点评审是接下来必走的一关。我在团队里推行的是三方评审测试同事互评负责开发的工程师参加需求产品也在场。测试同事负责挑方法维度的刺等价类分得对不对、边界值有没有漏开发人员负责挑实现维度的刺这个场景系统根本不会出现、那个场景数据流根本传不到产品人员负责挑需求维度的刺这个操作路径和需求评审时说的不一样。评审通过的用例号我习惯记录在一个用例评审跟踪表里每条用例的评审结论一一对应哪些通过、哪些要改、哪些删掉一目了然。千万不要相信嘴上的通过了没有落地的跟踪记录过两周谁都不记得当时改了什么。评审通过后用例进入了维护阶段。这个阶段最重要的一条守则需求一变用例立刻变。很多团队的用例库变成了僵尸库就是因为版本迭代了好几轮用例还是最初那一版执行的时候只能不断跳过失效的用例最后整个用例库形同虚设。我要求团队维护用例时做到需求变更单发出后三天内相关用例更新到新版本这个节奏虽然苛刻但长期坚持下来用例库的活性和准确性会远远好于其他团队。6. 常见问题与避坑实录我把踩过的坑全倒给你6.1 用例设计最容易翻车的四个习惯写这一节的时候我脑子里快速过了一遍这些年带过的所有项目和新人挑出四个最高频的翻车现场希望对号入座后你能提前躲开。第一个坑是把用例写成操作手册。症状是步骤极细细到把鼠标移到输入框点击左键输入这种级别几十条用例下来操作步骤占了80%的篇幅唯一的预期结果就是操作成功。这种用例看似完备实则无用执行人看半天根本不知道重点在哪而且需求一旦变化改用例的工程量能把人逼疯。正确的做法是步骤到动作级就停了输入账号、输入密码、点击按钮三步完事。中间那些移动鼠标点击输入框的低级操作是自动化脚本关心的事不是测试用例关心的事。第二个坑是只测正常流不测异常流。我前面反复强调过正常路径只是三个桶里的其中一个异常分支和边界数据必须和它一样重要。可现实是很多新人在时间紧任务重时第一刀砍的就是异常场景用例理由往往是时间不够了先把正常功能保证了吧。这个理由我完全不认同正常流程是开发自测都会覆盖的路径测试的价值恰恰在于把开发想不到的角度给覆盖住你把异常场景全砍了相当于把整个测试砍掉了大半的含金量。第三个坑是用例没有优先级一把抓。我曾经收到过一个新人写的两百多条用例密密麻麻全是中优先级问他哪个模块最核心、哪条用例必须优先回归他答不上来。没有优先级的用例在执行回归和评估风险时完全没法用。正确的做法是设计用例时同步评估核心功能、高危模块、历史bug集中的区域一律高优先级低频、边缘、影响面小的场景给中低优先级。时间不够时先从高优先级开始砍这永远是正确的止损策略。第四个坑是用例只覆盖新功能从不回归旧功能。这其实是很多团队的通病版本迭代时所有测试资源都扑向新需求老功能靠开发自测和线上用户发现问题。新功能有bug影响的是增量老功能回归不到位影响的却是存量存量用户规模大概率比新增用户大一旦老功能被改挂线上事故的规模往往更难看。所以我在排测试计划时有个不成文的规矩每个迭代至少要留出三到四成的测试时间做全量回归专门跑上一版本的高优先级用例。6.2 一份好用例的执行现场映射讲完坏习惯我给一份好用例是怎么在实际执行中发光的正面案例。有一次团队负责的一个核心交易系统发版开发在优化一处并发扣减库存的逻辑自测和代码评审都做得挺顺。上线前我刚好闲着把库存扣减相关的旧用例翻出来跑了一遍回归结果在一组边界用例上当场暴露了问题库存剩余数量等于1时两个请求同时进来系统把库存扣成了-1。开发当场看日志都愣了——这个边界判断他觉得自己改过但改的时候恰好把等于的判断条件给挪丢了。这个案子完美印证了边界值分析的价值也印证了老用例回归老功能的必要性。如果那天我没跑老用例线上第一笔并发订单就会给用户展示一个库存不足却下单成功的诡异状态损失虽然未必巨大但口碑和信任的折损是看不见的。这也是我为什么一直跟团队强调用例库不是用来给测试管理平台凑数的它是你关键时刻保命的护身符平时看着没事一出事就是大救星。6.3 用例颗粒度拿不准时到底怎么选最后聊一个大家反复纠结的问题用例到底写多细算合适我评判的标准特别简单——往下问一句执行人是否需要他无法掌握的信息。如果这条用例的执行人是个入职一个月的新人他照着用例能不能顺利完成操作并做出正确判断如果能颗粒度就合适如果不能就是你该补细节的地方。颗粒度还取决于一个变量用例的使用寿命。如果是用于一次性的探索性测试颗粒度可以放粗重点记录策略和思路就好。如果是用于多次回归的长期资产颗粒度就要偏细数据、前置条件、预期结果一个都不能少。如果是用于自动化脚本的转化蓝本那颗粒度还要进一步收紧每一个操作步骤都必须是可以直接映射成脚本动作的原子操作。颗粒度这种东西没有绝对的好与坏只有跟你的使用场景匹不匹配。你只要想清楚这条用例将来被谁用、用几次、用来干什么颗粒度自然就清楚了。我个人在实际操作中还有一个压箱底的小技巧写用例时永远要假设自己三个月后会失忆什么都不记得。你每写一条用例心里默念一遍三个月后的我看这条用例能不能看懂事情的原委。这个简单的心态切换帮我封掉了无数条当时写的时候明白事后看的时候一脸懵的坏用例。这个技巧我建议所有被用例维护折磨过的人都可以试一下亲测好用。