★ FEATURED ARTICLE 测试用例这三个词在测试圈里几乎每天都能听到但真让我说点实在的——很多干了三四年的测试写出来的用例依旧让人看不下眼。要么是模板里那几个字段填得七零八落要么是设计思路完全是想到哪儿写到哪儿最要命的是评审会上被人一问“为什么这个场景没覆盖”直接哑火。这篇东西不聊虚的我会把测试用例的要素逐个拆开讲清楚再把那个号称“万能”的设计公式掰碎了给你看最后用一整个登录模块的实操案例带你走一遍完整流程。适合刚入行的测试新人、被用例质量困扰的功能测试也想系统梳理用例设计思路的开发同学读完至少能让你下次写用例时心里有底。1. 测试用例到底是什么——先搞懂它为什么存在1.1 测试用例的本质不是“操作步骤”很多人对测试用例的理解停留在“描述怎么操作软件”的层面。这是个常见的误解而且是很多测试用例质量上不去的病根。测试用例本质上是一份“验收契约”。它约定的不是操作本身而是某个具体条件下系统应当表现出来的、可被验证的行为。换句话说测试用例回答的核心问题是在一个可复现的输入条件下系统的实际输出是否符合预期判定。它同时是执行依据、缺陷复现路径和回归基准这三重身份决定了它必须自洽、完整、可验证。我用一个生活化的类比来说。你去医院做体检体检单上每一项都有“项目名称”“参考范围”“检查结果”三个核心内容。你拿着这张单子到哪个科室、抽几管血、仪器怎么操作这些都是过程真正决定体检有没有价值的是“你有没有把该查的项目查全”“参考范围定得对不对”“结果到底怎么判读”。测试用例就是软件项目的体检单缺了任何一块这张单子都不合格。另一个常被忽视的点是测试用例是给“人”看的不只是给人“执行”的。评审会上测试组长、开发、产品经理都会读你的用例他们未必需要一个字一个字地执行但必须能在几分钟内判断覆盖是否到位、预期是否正确。所以用例的语言要精确避免歧义更忌讳那种“验证系统功能正常”“检查页面是否美观”这类模糊表述。1.2 标准用例的九大要素拆解要素是否必填说明与常见陷阱用例编号必填唯一标识建议按模块类型序号编码如“LOGIN_FUNC_001”方便追溯所属模块必填标识测试范围缺了这个用例在大型项目里根本无法归类用例标题必填一句话描述“测什么”要能从标题反推出步骤和预期的对应关系前置条件必填执行前的系统状态、数据准备、环境要求漏了这步别人根本没法执行测试步骤必填可操作的、有序的输入动作粒度要适中太粗无法复现太细维护成本爆炸测试数据有条件必填包括输入值、账号状态、数据库数据数据选错等价于用例白写预期结果必填可观察、可断言的判定条件用于与“实际结果”对比优先级推荐填P0/P1/P2/P3直接决定回归顺序和执行取舍实际结果与状态执行期填写记录是否通过关联缺陷编号是测试报告的数据来源我给两个最容易翻车的字段单独说下。第一个是“用例标题”。很多新人的标题写成“登录功能测试”“验证密码错误提示”这种标题信息量为零既没说清测什么场景也没说明预期是什么。我推荐的标题公式是“条件动作预期”比如“未注册手机号登录时提示账号不存在”。这种标题自带断言逻辑评审时扫一眼就知道是否覆盖了需求点。第二个是“前置条件”。我见过太多用例写着“用户已注册”但没说账号是什么、密码复杂度多少、是否被锁定过。测试数据一旦不明确执行时每个人用的都是自己的数据结果根本无法对齐。正确的前置条件写法要具体到“存在一个已注册且状态正常的账号用户名xxx密码符合强度规则的Pssw0rd”。2. 万能公式的内核——测试设计的思维框架2.1 所谓万能公式本质是穷举策略的组合“设计测试用例的万能公式”这个说法在测试圈流传很广通常被概括成一句话功能测试 异常测试 边界测试 场景测试 体验测试。有人还会加上兼容性、安全性、性能形成更庞大的组合。但我要负责任地说一句不存在真正意义上“万能”的公式任何公式都只是帮你把“盲目地大海捞针”变成“有结构地动态穷举”。这个公式为什么好用因为它背后的逻辑是对测试对象的五种提问方式功能测试问的是需求文档里说能做的事它到底做不做得到异常测试问的是不该发生的输入和操作系统会不会从容应对边界测试问的是临界值附近系统的判定还是不是需求规定的判定场景测试问的是多步骤连贯操作时流程和状态流转是否顺畅体验测试问的是用户用起来是否顺手反馈是否清晰容错是否友好这五类组合覆盖了质量属性的主维度。实际落地时你会发现绝大多数缺陷都集中在异常和边界两类上而功能测试最容易被开发自测覆盖掉——这点也值得你注意把力气花在别人没测过的地方你的用例才有价值。2.2 设计前的需求拆分三角色思考法万能公式能不能生效第一步不在用例设计而在于需求拆分。我的经验是把需求文档拆成三个视角每个视角问三个问题。第一个视角是“用户视角”。问谁会使用这个功能他们最常走的主路径是哪一条他们最容易犯的错误是什么这一层回答的是业务正确性问题。第二个视角是“业务规则视角”。问需求文档里明确了哪些约束如长度、格式、状态机哪些规则存在隐含条件哪些规则之间是有冲突的这一层回答的是逻辑一致性问题。第三个视角是“系统视角”。问功能依赖哪些数据表和服务网络延迟或超时时会怎样并发操作下会出现什么状态竞争这一层回答的是技术边界问题。我举个实际例子。一个简单的“修改昵称”功能三个视角拆下来你会得到完全不同的测试点用户视角关心“改完个人主页是否立即更新”业务规则视角关心“昵称长度为1到20个字符”“敏感词校验何时触发”系统视角关心“昵称重复时是否给出明确报错”“弱网环境提交失败后数据是否回滚”。不拆分大多数新人只能想到第一层。2.3 优先级和粒度怎么定才合理这是实操中最让人纠结的一环。我给出的参考依据很简单优先级取决于两个维度——业务impact影响面和失败概率。功能主路径、核心数据正确性、支付和权限相关的用例一律设为P0这些场景挂了整个版本都别想上线次要分支、异常容错类设为P1边缘提示语、UI细节、极端低频场景设为P2或P3。注意优先级不是一成不变的上线前回归时P0必须全量执行P1抽测P2按风险决定是否执行这个策略要提前和项目经理对齐。粒度问题上我见过两种极端一种把“打开页面”“输入内容”“点击按钮”拆成三步每步一个用例结果一个功能写了四十条用例另一种把整个业务流程压缩成一条用例中途一个分支失败后面全部无法继续。我建议的粒度判断标准是一条用例应该对应一个可独立验证的业务断言。整条链路流程验证可以单独用场景法覆盖但每个输入输出的核心断言必须能独立运行和失败定位。3. 把公式展开五大经典方法实操解读3.1 等价类划分先搞清楚“同一种输入”是什么意思等价类划分的核心思想是把输入域按“是否触发相同处理逻辑”进行分类从每一个分类中选取代表数据进行测试用最少的数据覆盖尽量多的逻辑分支。这里的关键词是“相同处理逻辑”不是“相似输入值”。举个戳破误区的例子。一个输入框要求填写年龄范围是18到60。新手容易这么划有效等价类取一个“30”无效等价类取一个“17”。实际上“相同处理逻辑”还依赖系统怎么处理这些值如果系统内部对不同年龄段比如18至25、26至45、46至60有差异化营销策略那有效等价类就不能只取一个值必须覆盖每个年龄段区间。所以在划分前建议先看代码分支、配置表和状态机而不是拍脑袋分类。还需要特别提醒的是在考虑等价类时要区分“有效等价类”和“无效等价类”两个集合。有效等价类验证“系统成功响应正确的输入”无效等价类验证“系统合理拒绝错误的输入”。两种都必须测我刚入行时只测有效数据结果系统对非法输入全无拦截上线当天就收到生产问题反馈这个教训印象特别深刻。3.2 边界值分析缺陷最偏爱交界处边界值法本质上是等价类法的一种补充基于大量缺陷集中在输入边界附近这一工程经验。它的实施规则并不复杂选定某个输入条件后取其边界值、比边界稍大一点和稍小一点的值进行测试通常覆盖“上点、离点、内点”三组数据。用年龄输入框18至60为例上点区间边界值本身即18和60离点离边界最近且不在有效区间内的点即17和61内点区间内任意正常点如30这里的难点在“闭区间和开区间的差异”。如果是“大于等于18且小于60”那么18是有效值、17是无效值60是无效值、59是有效值四个边界都要测。很多需求文档写的是自然语言描述不会明确告诉你边界开闭属性这时候要和产品经理确认并在用例中注明边界判定依据。我还想补充一个实战技巧边界不只有“数值边界”还有“长度边界”“数量边界”“时间边界”。输入框允许20个字符19、20、21都是边界值购物车允许添加50种商品49、50、51都要测优惠券有效期截止到某个时间点截止前1秒和截止后1秒是经典边界BUG高发区。3.3 场景法盯着业务流程而不是单个输入框等价类和边界值解决的是“单个输入项”的测试但在真实业务中用户很少只操作一个控件。场景法就是从用户实际操作路径出发将多个功能串联成完整业务流验证系统在流程中的状态流转、数据传递和异常处理。场景法的基础是画业务流程路径。通常包括基本流、备选流和异常流三部分。基本流是最顺利的用户操作路径比如“进入登录页——输入正确账号密码——点击登录——跳转首页”备选流是在基本流基础上发生的合法变更比如“登录成功但首次进入需要修改密码”异常流则是中断或失败路径比如“登录请求超时——页面给出重试入口”。实操中我的做法是先用XMind把需求涉及的业务流程完整画出来标注每个判断节点的分支然后挑用户使用频率最高、业务价值最大的几条路径设计场景用例。场景法用例的预期结果要重点检查“多个环节衔接处的状态一致性”比如提交流程里第二步失败后第一步创建的数据会不会变成垃圾数据——这类问题单点用例根本测不出来。3.4 错误推测法经验主义的黑魔法错误推测法不依赖系统的方法论而是依赖“你对这类系统的常态缺陷有认知”。它的核心是凭经验列出系统最容易出错的地方然后针对性地设计用例。常用清单大致有几类未填写任何值的空提交极长字符串输入包含特殊字符的数据重复提交表单并发点击同一个按钮输入内容包含前后空格登录态过期后继续操作删除关键数据后依赖它的页面切换网络导致的请求中断。每一个都可以展开成多条用例。这里有个自学路径值得分享每轮测试结束后把线上问题、漏测缺陷做归因分析记录“当时要是多个XX用例就不会漏”。我自己会把这类复盘结论沉淀到一个“错误推测检查清单”里每接手一个新项目就对照清单过一遍场景缺陷密度明显改善。这个习惯坚持半年以上你对一类系统的“直觉”会准确很多。3.5 判定表与正交试验参数组合多到头疼怎么办当被测功能受多个条件影响且不同条件组合产生不同结果时等价类加边界值就不够用了。这时候判定表法是主推方案。判定表的核心结构是“条件桩、动作桩、规则组合”。我把一个典型场景说明白假设一个登录校验规则是“用户名存在密码正确账号未锁定允许登录账号锁定或密码错误拒绝登录并提示相应信息”。这就有三个条件理论上2的3次方共8种组合每种组合对应一个动作。判定表可以确保规则没有遗漏而且规则之间的矛盾一目了然。条件数增多后组合数呈指数级膨胀6个条件就是64种组合一一测试不现实。此时用正交试验法从全量组合中选取均匀分散且有代表性的组合来测能用少量用例覆盖大多数缺陷。用哪个方案取决于条件之间的交互强度条件本身相互独立、结果是对每个条件的简单累加时我觉得用正交法条件之间存在跨条件的逻辑推导判定表直接、直观、可复核是最稳妥的选择。4. 完整实操登录功能从需求到用例全流程4.1 需求拆解把一段话变成测试点假设产品给的需求原文是这样的一段描述用户通过手机号和密码登录系统。手机号须为中国大陆11位号码密码为6至20位字符可包含字母、数字和部分特殊字符。连续5次密码错误后锁定账号15分钟。登录成功后跳转个人工作台。拆解的第一步是把隐藏规则找出来。“部分特殊字符”到底指哪些密码是否允许纯数字“15分钟”的计时起点是第5次失败时开始还是第5次失败后立即开始这些都需要在评审时和产品对齐不确认清楚后面没法设计。拆解后我得到以下核心测试点手机号格式校验长度、首位、非法字符密码规则校验长度、字符类型、空值登录成功路径正确手机号正确密码登录失败路径手机号不存在、密码错误、账号锁定锁定策略第5次失败的判定、15分钟计时、锁定期间正确密码登录的返回跳转逻辑不同用户角色登录后的落地页安全和体验错误提示措辞、密码输入可见性、10分钟内会话保持4.2 套用万能公式产出用例我直接把上一章提到的五个维度应用到登录模块产出一组精简但完整的用例框架你在实际项目中照这个思路扩展即可。功能测试用例示例用例标题正确手机号和正确密码登录成功并跳转工作台前置条件存在已注册且状态正常的账号密码符合规则账号未被锁定步骤打开登录页→输入手机号→输入密码→点击登录预期登录接口返回成功页面跳转个人工作台URL含用户标识边界测试用例示例用例标题密码长度为20个字符时登录成功前置条件同一账号密码恰好为20位合法字符步骤输入手机号与密码并提交登录预期登录成功不出现长度校验拦截用例标题密码长度为6个字符时登录成功前置条件同一账号密码恰好为6位合法字符步骤输入手机号与密码并提交登录预期登录成功用例标题密码长度为5个字符时提示密码格式错误前置条件无需预先准备数据步骤输入合法手机号与5位密码并提交预期界面提示“密码长度为6至20位”登录请求不发出异常测试用例示例用例标题连续5次密码错误后账号锁定15分钟前置条件账号A未锁定已知正确密码步骤第1至第5次输入错误密码提交登录→第6次输入正确密码提交预期第5次失败后提示“账号已锁定15分钟”15分钟未到时即使密码正确也拒绝登录15分钟后可正常登录场景测试用例示例用例标题锁定到期后立即登录成功且剩余锁定时间重置前置条件账号进入锁定状态且剩余时间为0步骤等待到点后输入正确密码登录预期登录成功锁定废弃记录处理正确账号状态置为正常体验与安全用例示例用例标题密码输入框默认隐藏明文支持切换显示前置条件进入登录页步骤输入密码后点击“显示/隐藏”图标预期密码明文可见与隐藏可来回切换切换逻辑无卡顿隐藏状态下密文不完整泄露上面这些用例我特意省掉了冗长的“每一个字段都写一遍”的内容重点演示的是如何按思考维度生成用例。实际交付时每一条都要写全要素编号、优先级、数据准备都要标注完整。别偷懒模板字段的完整性直接影响回归时的可执行性。4.3 用例评审和后续维护用例初稿完成后一定要做评审别跳过。评审的重点按顺序是三件事一是确认需求理解没有偏差尤其是边界规则、异常策略这些测试用例的核心显性表达二是确认覆盖没有重大缺口对照需求点逐项打勾是最省时间的方式三是确认用例的可执行性让一个不了解这个模块的新同学试着按照用例操作卡住的地方就是用例需要修改的地方。代码层面之外还有几个环节容易被忽略需求变更时相关用例必须在变更确认后同步更新线上缺陷出现时第一时间反哺用例库把缺失场景补进去每次版本迭代结束后建议挑一个下午专门做用例梳理把废弃用例标记、过时优先级修正、重复用例合并。用例库是你最重要的测试资产但不维护的用例库过期之后就是负债回归时浪费大量时间执行大量过时用例。5. 常见问题与排查技巧实录5.1 用例写太粗或太细到底哪个更致命这个问题经常有人问我的结论很明确太粗更致命。用例太细只是维护成本高太粗则让测试执行过度依赖个人发挥同一份用例换一个人执行结果可能完全不同缺陷复现也无法追溯。“太粗”的典型表现是步骤写成“输入正确的手机号密码登录”预期写成“登录成功”。执行者根本不知道正确手机号和正确密码具体是哪组数据也不知道登录成功后该断言什么页面元素。这种用例在评审时就要打回重写。我之前带过的一个新人写搜索功能用例步骤就是“输入关键词搜索”预期“返回结果正确”。评审会上我问了三句话就把用例问崩了空关键词怎么办关键词首尾有空格怎么处理搜索无结果时的提示文案是什么他很坦诚地回复说没有想过。把这三个问题补进用例用例质量立竿见影地变好。粗与细的平衡核心原则就是断言明确、数据可复现。5.2 前置条件和测试数据最常被忽略的两个要素业内有个很扎心的统计规律大多数用例评审被挑战的用例问题都出在“数据不明确”而不是“步骤缺失”。这是很多人的习惯性盲区以为数据只是数字值本身实际上测试数据至少包含四层信息环境状态、账号身份、数据准备SQL、依赖的第三方桩数据。举个例子“用户已登录”这个前置条件不同场景下差异极大是新注册用户还是老用户是否绑定手机号是否在登录时被强制要求修改密码是否处于灰度名单如果不写清楚执行者用错了数据用例结果根本没有可比性。我的治理办法是建立“公共测试数据池”。给常用基础数据取固定别名比如“标准用户A”“字段超长用户B”“锁定用户C”在团队共享的文档或代码仓库中维护它们的真实值。用例里直接引用别名既节省篇幅又统一口径。5.3 万能公式的适用范围不是全场景最后说个得罪人的实话“万能公式”并不是万能的。它最适用的是面向用户的业务功能测试尤其是 Web 和 App 端的功能验证。但它明显不适合的场景包括纯算法类测试需要结合数学模型做预期公式里的“体验”维度完全失效、底层协议或接口的模糊测试这部分要用专门的数据策略、高频压力与稳定性测试属于性能工程领域不按用例维度设计。就算在功能测试内部公式也需要据项目裁剪。你测的是面向内部管理后台用户体验权重就可以降得很低你测的是技术中台API场景法和体验法基本可以放到次要位置。套公式之前先审视被测对象的质量属性侧重这才是公式正确使用的姿势。从我这些年带项目的经验看测试用例设计能力是测试工程师的核心竞争力中最值得投资的一项。写用例不是体力活而是把模糊的软件行为翻译成明确断言的过程。万能公式能给你一个起点但真正的分水岭在于你是否愿意在每个版本、每个缺陷、每一场评审中持续修正自己的思考维度。下次写用例前先停一下从需求的三视角拆解开始走一遍你产出的用例一定比直接开写要完整得多。
阅读完成 · 觉得有帮助？
