先说一个我真实的评审经历。有一次同事提交了一条用例标题叫“修改密码”前置条件栏是空的操作步骤写着“按正常流程修改密码”预期结果写着“修改成功”。我当时盯着这条用例看了三遍最后也不知道执行完它能证明什么——是用新密码能登录旧密码失效还是修改过程中短信验证码校验过没过全都不清楚。这种用例不是个例在很多团队里测试用例的数量一直在涨但质量并没有跟着涨。大家嘴上说测试用例是测试工作的核心资产实际写起来却像是在应付差事。这篇内容我打算把测试用例编写规范这件事彻底讲透从一条用例的基本结构到设计方法怎么选到用例库怎么组织、怎么复用、怎么评审再到用例如何为自动化测试铺路每一层我都会结合自己踩过的坑来讲。适合谁看刚入行的测试新人、带团队的测试负责人、以及那些觉得自己用例“写了但好像没什么用”的同学都能从中找到可以马上落地的建议。1. 用例没有规范的团队都在靠“人肉记忆”硬撑我先抛一个观点测试用例如果只是写给自己看那怎么写都无所谓。但用例的绝大部分价值在于“别人能看懂、别人能执行、别人能判断结果”在于回归、交接、自动化、审计、甚至培训时反复使用。一旦脱离了个人记忆用例就必须有规范。没有规范的用例库本质上是一堆只有作者本人能解释的半成品。我在一些项目里见过特别典型的情况同一个功能三个测试工程师各写了一套用例步骤和预期结果完全对不上迭代三个月后用例库里躺着一百多条“看起来还能用”的用例但没人说得清哪些还在验证当前版本的行为新人接手项目看用例库像看天书只能追着老员工一个个问。这些问题的根源不是大家不努力而是缺少一套统一的编写约定。所以规范的核心目的就是把用例从“个人笔记”变成“团队资产”。要实现这个转变首先得从一条用例的内部结构下手。1.1 先看反例一条“能跑但没用”的用例长什么样我们把刚才那条“修改密码”的用例展开来看。假设它是这么写的用例标题修改密码前置条件无操作步骤进入个人信息页点击修改密码输入新密码点击确认预期结果修改成功这条用例能不能执行能。但执行完能得到什么结论很难说。因为“修改成功”这个预期结果没有给出可判定的依据执行的人根本不知道应该观察什么。更关键的是这里缺了好几个信息修改密码前需不需要验证旧密码需不需要短信验证码新密码有没有复杂度要求修改之后原登录态会不会失效这些问题不写清楚用例执行时全靠执行人临场发挥。再举一个登录功能的例子。很多用例会这样写“输入正确的用户名和密码点击登录预期结果登录成功。”这句话看上去没错但严格来说它无法指导执行。什么叫“正确的用户名”是任意一个已注册的用户还是指定测试环境里某个固定用户“登录成功”的判定是什么——是URL变了、页面出现了用户名、还是接口返回了特定状态码如果不定义清楚执行人很可能走到“这环境里没有这个用户”就卡住了。1.2 用例的原子结构应该怎么写一条合格的测试用例至少要包含下面这些字段缺任何一个都会在实际使用中带来问题字段要求说明用例编号唯一、稳定、可追溯推荐格式模块-级别-序号例如LOGIN-P0-001用例标题一句话说明验证点采用“验证[场景]下[功能]的[结果]”句式前置条件可复现的环境、数据、状态明确已有数据、初始状态、外部依赖操作步骤从用户视角每步只做一个动作可被另一个人原样执行不依赖经验预期结果可判定的观察点分层描述界面结果、接口结果、数据结果至少写一层优先级P0/P1/P2标记用例在回归中的重要性关联需求需求编号或链接用于追溯需求和覆盖率统计前置条件是最容易被敷衍的部分但它恰恰决定了用例能不能复现。我的习惯是前置条件里必须写清楚“数据从哪来”和“系统处于什么状态”。比如验证登录前置条件可以这样写已注册一个状态正常的用户用户名test_user_001密码Test123456该用户无锁定、无禁用标记浏览器使用无痕模式确保没有残留登录态操作步骤也必须具体到“别人拿着就能执行”的程度。有些同学喜欢写“输入任意合法手机号”这等于把决策权甩给了执行人。正确做法是写死测试数据或者明确数据生成规则——“输入一个长度为11、以1开头、未经注册的手机号”。预期结果的写法是区分测试工程师水平的关键之一。我建议按三层来描述至少覆盖一层界面层页面跳转到哪个URL、弹窗文案是什么、按钮置灰还是可点接口层哪个接口被调用返回code是多少响应体的关键字段是什么数据层数据库表里对应记录的值是否变化缓存是否更新拿登录来说完整的预期结果可以是界面层3秒内跳转到系统首页右上角显示用户昵称接口层调用login接口返回code0token字段非空数据层用户状态表last_login_time更新为当前时间这样一条用例任何人执行完都能明确回答“过还是没过”。而能够稳定回答“过还是没过”正是用例规范的底层价值。2. 从需求到场景用例设计不是枚举是风险建模说完了单条用例的写法再往上一层看那么多条用例是怎么设计出来的很多测试新手容易陷入一个误区就是把所有可能的输入都试一遍试图用数量堆出质量。这是典型的“用例枚举病”。真正的用例设计本质上是对需求做风险建模——把需求分成主流程、分支、异常、边界找出最可能出问题的点用最小代价覆盖它们。具体到设计方法我们常用的无非是等价类、边界值、场景法、判定表、正交实验这几种。关键不是背名词而是知道每种方法解决什么问题、在什么场景用最划算。2.1 等价类与边界值最便宜的方法最先做等价类划分的核心思路是把无穷输入集划分成有限类别同一类别里的不同输入在系统看来是等价的。边界值则是等价类的补充——很多缺陷恰恰发生在输入范围的边缘。举一个最常见的例子一个订单金额输入框业务规则是“金额需在1到10000元之间保留两位小数”。用等价类划分我们可以得到有效等价类1 金额 10000例如 100.50无效等价类一金额小于1例如 0.99无效等价类二金额大于10000例如 10000.01无效等价类三非数字输入例如 abc无效等价类四小数位数超过两位例如 100.001边界值则在有效等价类边缘附近取值0.99、1.00、1.01、9999.99、10000.00、10000.01。这样一组用例下来覆盖密度比随机输入要高得多。我自己的经验是先在需求评审阶段把等价类和边界值用例草拟出来通常不到两个小时就能出一版。这个动作能快速暴露需求里那些“约等于”“左右”“大概”之类的模糊描述比如“金额不超过一万”到底是小于等于一万还是小于一万当场就能逼产品经理说清楚。2.2 场景法把用户当“笨人”来设计单元化的输入验证只能证明“每个点没问题”但很多严重缺陷只有在完整业务链路里才会暴露。场景法就是从用户真实使用角度把多个功能点串成完整的业务流来设计用例。举个例子一个电商购买流程主路径场景可以是用户登录搜索商品加入购物车进入结算页填写收货地址选择支付方式提交订单支付成功订单状态变为已支付但光有主路径远远不够。真实用户绝不会按你预设的路走他们会中途关闭页面、重复点击提交、切换网络、修改地址后又返回。所以场景法还要覆盖分支场景和异常场景支付中途取消订单状态是否保持待支付支付成功后网络断掉前端是否提示“支付结果确认中”重复点击提交订单按钮是否产生重复订单支付回调延迟订单状态是否在轮询后自动更新场景法的核心是把每个真实用户会走的路径都当作“一张图”每张图对应一套用例。我在写用例时习惯先画出主路径图当然不用画工具图脑图即可再逐条标注分支和异常。这样既能保证不遗漏也能在评审时直接对着业务流说明覆盖情况沟通效率很高。2.3 组合类方法条件不独立时判定表和正交实验才有意义当输入条件之间存在组合关系时比如多个开关、多个状态叠加简单的等价类覆盖是在赌运气这时候要用判定表或正交实验。判定表的思路是结构化地列出所有条件的组合以及对应的动作。假设一个优惠券发放规则用户是新客A、订单金额超过100元B、使用指定支付方式C三个条件都满足时发放满减券。判定表会把A、B、C的8种真假组合全部列出来逐条核对发券逻辑。这样设计出来的用例不会因为漏看某个条件组合导致线上优惠券被薅。正交实验则是多因子多水平时的简化方案。当因子太多全量组合数量爆炸时用正交表选出一组有代表性的组合用较少用例覆盖主要因子效应。这个方法适合兼容性测试、配置矩阵测试这类场景。不过我要提醒一句正交实验适合“因子间交互影响不大”的场景如果条件之间牵一发动全身还是老老实实用判定表。优先级划分这块不少团队是凭感觉定的结果就是所有用例都是P2回归时全跑一遍又跑不完。我建议按风险和业务价值量化至少给出下面这套标准优先级定义判定标准回归要求P0核心主流程与安全相关主流程不可用、资金/数据错误、越权发布前必须全绿P1重要功能与主要异常场景主要功能降级、无绕过的异常阻断发版验证必跑P2边界、兼容、探索性场景体验问题、极小概率场景按排期执行P0用例一定不要多。如果P0用例超过二三十条说明你的P0定义有问题——精挑细选出来的核心流程每条都要能回答“这条挂了系统还配发版吗”这个问题。3. 用例库的分层与复用迭代多了用例不是越多越好用例写多了以后团队会遇到一个比“不会写”更麻烦的问题用例库越来越庞大维护成本和执行成本同时上涨老用例没人敢动新用例不断堆叠最后整个用例库变成“食之无味、弃之可惜”的鸡肋。我见过最夸张的一个项目经过三年迭代后用例库里有三千多条用例但一次迭代回归根本跑不完也没人知道哪些用例已经和现在的需求脱节。要解决这个问题不能靠某个人的责任心必须从用例库的组织结构入手。3.1 用例库的分层结构决定了回归效率我推荐的做法是把用例分成几个明确的层级而不是全部放在一个平面上L1 - 冒烟用例每个迭代的核心主流程大概10~30条执行时间控制在半小时以内用于环境验证和快速反馈。L2 - 功能细测用例覆盖每个功能模块的完整用例集包含主流程、主要分支、主要异常用于版本验收。L3 - 专项用例异常、安全、性能、兼容性、边界探索类用例不随每次回归全量执行而是按专项计划轮询执行。R - 回归基准用例从L1和L2中挑选出的、验证历史核心能力的用例集合每个迭代回归时执行。这个分层的好处是当发布压力来临时你可以快速选择“跑哪些用例”而不是“所有用例都跑”。我在多个项目里实践后回归时间通常能从两三天压缩到半天到一天。优先级和层级是两个维度的东西但要保持一致。我习惯用标签来管理例如给用例打上smoke、regression、p0这样的标记方便在测试管理工具或代码仓库里直接筛选。用例的编号里也可以体现层级比如CORE-L1-001、ORDER-L2-023一眼就能看出用途。3.2 复杂迭代中的用例维护机制很多团队的用例维护是被动式的——需求变了、测试发现用例挂了才想起来改。这种模式在高速迭代的团队里根本扛不住因为需求变更的速度远快于用例更新的速度一个月下来用例库就面目全非了。我的经验是把用例维护当成迭代的固定环节来管理而不是“有空再做”的杂活。具体做法有三条第一关联需求双向追溯。每条用例必须关联需求编号或用户故事需求变更通知发出后系统里自动找出所有关联用例由用例负责人逐一确认是否需要更新。这个动作必须在需求收敛后一周内完成。第二定期体检存量用例。每个迭代末尾用例负责人要过一遍与本次变更相关的旧用例还能用的保留语义模糊的重写覆盖已失效功能的直接废弃。与其维护一百条模糊用例不如维护三十条精准用例。第三结构化数据生成。用例里的测试数据不要散落在步骤里而要用参数化方式管理。比如登录用例的数据统一放在test_data/login_data.json里用例步骤只写“使用账号A登录”具体账号密码由数据文件控制。这样环境变化时只需要更新数据文件不需要改几十条用例。还有一个很容易被忽略的问题用例执行时“挂掉”了并不代表产品有Bug也可能是用例过时了。每次用例执行失败必须做一个根因归类——是代码缺陷、环境问题、数据污染还是用例本身过时。这四类原因的处理方式完全不同。如果团队能坚持把这个分类统计做三个月你就能清楚地看到用例库到底是变得越来越准确还是越来越失真。3.3 跨项目复用的边界在哪里复用是件好事但“什么都想复用”会走向另一个极端。我见过有人把项目A的完整用例库复制到项目B只改了系统名称结果执行时大量用例因为业务规则不同而失败最后反而没有人信任这份用例了。跨项目复用真正靠谱的边界是“能力相同、规则相同”的部分。典型的例子包括统一的账号体系登录、注销、密码找回、多端登录互踢通用的权限模型角色管理、用户授权、越权访问标准化的上传下载能力文件类型校验、大小限制、并发上传这些模块在不同项目里规则高度一致适合抽成“公共用例集”由平台或公共组统一维护。而业务规则差异大的部分比如订单状态流转、审批流配置、计费规则必须由项目各自编写最多复用用例模板不能复用具体用例内容。还需要留意用例的“环境依赖”。公共用例集最好设计成与具体环境解耦比如测试数据用参数占位执行时由脚本注入环境变量。否则一旦跨项目、跨环境使用前置条件里的IP、账号密码全都失效复用就成了一句空话。4. 用例评审与入库质量门禁比“人人都写”更重要很多团队把用例评审做成流水账产品经理、开发、测试大家坐在会议室用例作者照着文档一条条念念到一半所有人都走神了。评审变成了“过场”质量门禁就是形同虚设。我的观点是用例评审不是流程负担而是最便宜的Bug发现手段。在用例评审阶段发现需求歧义修改成本是一个沟通成本等开发完了再发现是返工成本等上线后被用户发现那就是事故成本。所以用例评审值得认真做关键是找到正确的切入角度。4.1 评审的发起时机和人员配置不是所有用例都需要全员评审。我给团队定的规则是新增功能用例需要产品经理、开发、用例作者三方评审重点澄清需求歧义大版本的回归用例集筛选测试负责人、资深测试评审重点保证覆盖无遗漏单点修改的用例更新用例作者自审 测试负责人抽查即可评审时最好用“基于需求的提问式评审”而不是“逐条念稿式评审”。每个用例过完评审者要问自己这条用例的执行结果能证明需求中的哪一条验收标准如果回答不上来说明这条用例与需求脱节要么删掉要么重写。我建议评审前先让用例作者填写一张简单的自查表内容包括预期结果是否可判定前置条件是否可复现是否覆盖了主路径、分支、异常三层场景P0用例是否标记清楚。评审就围绕这张表展开能把平均时间压缩到原来的一半。4.2 评审时重点检查的七个问题这几年我在评审中积累了七条必查项基本能筛掉八成不合格用例前置条件是否可复现依赖的数据和环境是否明确别人拿起来就能执行吗操作步骤是否只有单一动作如果一步里有“输入账号、选择城市、点击搜索”三个动作失败时你无法定位是哪一步出了问题。预期结果是否包含可观测断言不要写“页面正常”要写“出现提示文案X请求返回code0列表展示N条数据”。是否有逆向用例除了验证“该做的做了”是否验证了“不该做的做不了”比如无权限访问、非法参数、重复提交。数据是否会被历史数据污染用例依赖的数据在重复执行多次后还能不能保持初始状态。是否清理测试现场用例执行后是否离开脏数据比如创建的订单、注册的账号是否需要清理。是否与已有用例重复如果新增用例和旧用例验证的是同一个规则应该合并而不是再开一条。其中第七点特别值得强调。很多用例库的膨胀就是不断有人重复添加功能相同的用例只是换了测试数据或页面文案。评审时要主动去重能从源头保持用例库的整洁。4.3 用数据度量用例质量质量不能只靠感觉要建立几个可以统计的指标放在迭代复盘里持续关注需求覆盖率已有关联用例的需求数除以需求总数目标是100%这代表需求的每一条验收标准都有对应的验证。单功能用例密度平均每个功能点对应的用例数我个人认为健康范围是4到8条。太少说明覆盖粗太多说明碎片化。用例有效执行率执行通过的用例数除以总执行数。如果长期低于70%优先反思用例是否过时、环境是否稳定。自动化率P0和P1用例中已实现自动化的比例目标根据团队资源定但P0主干建议不低于80%。有一次我让团队成员统计这个有效执行率发现某个模块长期只有50%多一查才发现在过去两个大版本里该模块的交互已经被产品重做过两轮但用例库只更新了20%。这个数据直接把维护积压问题暴露了出来。5. 用例和自动化测试的咬合好脚本的前提是“可断言的用例”现在很多团队都在提自动化测试从Playwright到Selenium从UI自动化到接口自动化工具五花八门。但大家逐渐发现一个尴尬的事实自动化脚本写了不少维护成本高、失败频繁最后沦为一堆“天天飘红”的CI任务。问题往往不在脚本本身而在用例源头上。自动化脚本本质上是把用例翻译成代码如果用例本身没有清晰的步骤和可断言的预期结果脚本翻译出来也就是一堆软绵绵的检查。所以用例编写规范直接决定了自动化测试的上限。5.1 哪些用例适合自动化不是所有用例都适合自动化盲目追求100%自动化率是本末倒置。我给团队定的筛选标准很朴素执行频率高的用例优先自动化比如每次发版都要跑的P0冒烟用例步骤稳定、不依赖大量人工判断的用例优先自动化比如接口字段校验、页面跳转依赖复杂数据准备的用例除非数据能脚本化准备否则自动化性价比很低这里特别提醒一个反直觉的现象自动化跑得越多用例维护成本越高。所以自动化的正确策略不是“把手工用例全部脚本化”而是“精选核心用例脚本化把手工精力留给探索性测试”。每次看到有人花两周把一个基本没人用的模块自动化了我都替他心疼时间。5.2 可自动化用例的编写要点如果一条用例要被自动化它的写法有一些额外要求。首先是操作步骤里的输入必须确定不能写“输入任意合法手机号”要写“输入指定手机号13800138000”脚本才能落地。其次预期结果要划分出“中间态断言”和“终态断言”。比如测试一个表单提交中间态断言是点击提交后按钮变为loading态且不可再次点击终态断言是页面跳转后的列表中出现新记录。交互变化是UI自动化最容易漏掉也最容易稳定的断言点一定不要只写终态结果。第三对页面元素的选择要写“稳定标识”。如果用例步骤里写“点击右上角的设置按钮”脚本怎么写选择器最佳实践是给关键元素加上>