做了这么多年测试我见过太多“看起来写了、实际上没用”的测试用例文档躺在上线流程的附件里没有人看打开一看步骤含糊、预期结果写“页面正常显示”跑完不知道到底算不算通过。测试用例本该是团队沟通的契约、回归执行的蓝图但现实中常常演变成应付流程的“废纸”。这些年我慢慢把一套管理测试用例的规范沉淀了下来从字段设计到Playwright自动化落地都包含在内。它解决的核心问题只有一个让人和机器都能用同一份用例把“该测什么、怎么测、测到什么程度算过”说清楚。这篇内容适合刚接触用例设计的新人也适合被历史用例坑到怀疑人生的自动化测试负责人。1. 为什么很多测试用例写得像“废纸”先别急着谈规范写法。我踩过最大的坑就是在一堆“规范模板”里反复改格式却忘了先搞清楚用例到底是干什么用的。测试用例不是给领导看的汇报材料它是把“需求期望”翻译成“可验证行为”的中间件。如果这个翻译过程出了偏差后面所有执行、统计、自动化都会跟着跑偏。1.1 常见的三种“坏味道”用例第一种是“念头式”用例。比如“验证用户能正常登录”不写明用哪个账号、密码多少、网络环境、期望跳转到哪个页面。执行的人要么自己去猜要么直接忽略。第二种是“小说式”用例。前置条件写了三页步骤从操作系统版本写到浏览器缓存路径真正的核心场景反而没覆盖。第三种是“结论式”用例。压根没有步骤只有一句“确认功能正常”。这类用例在评审时没人能挑战因为谁都看不懂但执行时也谁都不想碰。我自己的经验是如果一份用例拿给一个完全不了解需求的实习生他看完能独立判断“测试结果是否符合预期”这份用例才算合格。否则无论模板多精美本质上都是废纸。1.2 规范的本质是降低团队协作成本很多团队一提到规范就想到“加字段”“加流程”结果反而把用例变成了填表负担。真正的规范应该服务于两类读者一类是执行用例的人可能是手工测试也可能是自动化脚本另一类是评审用例的人开发、产品、其他测试。规范要做的事情不是限制大家发挥而是统一“说什么”和“怎么说”。我通常把测试用例规范拆成三个层次来建设计规范解决“测什么”表达规范解决“怎么描述”执行规范解决“怎么就算过”。三个层次管的事情不同标准也不同。下面逐个展开后面再用Playwright的实际案例说明怎么落地。2. 设计规范先拆场景再写步骤很多人拿到需求就打开Excel开始写用例写完一条算一条最后零零散散几十条覆盖率却很低。正确的顺序应该是先做场景建模再转成用例。2.1 用例颗粒度一条用例只验证一个核心目标判断颗粒度是否合适就看“这条用例失败时你能不能立马定位是哪个环节出的问题”。如果一条用例包含了“注册新用户→登录→修改头像→发布动态→退出”只要最后一步失败你得花半天排查到底是哪一步崩了。这不叫用例这叫操作手册。我推荐的颗粒度标准是一条用例覆盖一个业务路径的单一目标。登录注册拆开下单和支付拆开权限验证和功能验证拆开。当然这里说的“单一目标”不等于最小操作像“注册→登录→进入首页”可以合并因为它的核心目标是验证注册后的首次登录链路中间步骤都是为了这个目标服务的。用一句话概括用例的标题应该能回答“我要验证什么”。2.2 场景优先级用功能风险而不是功能数量决定顺序不是所有功能都值得写同等深度的用例。资源有限必须砍需求时砍的应该是低风险场景而不是高风险的。我给用例定优先级时参考三个维度故障影响面、用户使用频率、历史缺陷密度。支付、登录、权限这类影响面大或者出过事故的必须覆盖主流程、异常流程、边界值活动页文案这类影响面小的一条冒烟用例就够。很多团队习惯按“模块功能点”逐條编写但我建议先列业务场景清单给每个场景打三个维度的分排序后再写用例。这么做的坏处是前期有点慢好处是避免在边缘功能上浪费时间。提示优先级不是一成不变的每次版本迭代后应该重新评估一次。尤其是那种“上上次版本出过bug”的功能即使很小也要升一级。2.3 设计用例时必带的“四要素”不管用什么模板每条用例的核心字段就四个前置条件、操作步骤、预期结果、测试数据。其他字段编号、模块、用例名称、优先级、关联需求都是辅助信息。前置条件要写清“进入此用例前系统处于什么状态”。比如“用户已登录且账号余额为100元”而不是“用户登录”。操作步骤要能按顺序执行不能出现“根据情况”这种弹性描述。预期结果必须可验证比如“充值成功后页面跳转到余额页右上角余额显示为100.00元”而不是“充值成功提示”。测试数据要单独列出来不要埋藏在步骤文字里方便后续做数据复用和隔离。这套四要素听起来朴素但很多历史用例就死在这上面。比如前置条件写“管理员登录”步骤写“进入用户管理页点击禁用”预期结果写“该用户被禁用”。问题在哪没有明确“哪个管理员账号”“哪个用户”“是否处于启用状态”“禁用后该用户还能不能登录”。我后来强制团队在用例里必须把数据写具体比如“使用admin01账号登录对用户zhangsan当前状态为启用执行禁用操作预期该用户登录时提示‘账号已被禁用’”——这么写之后测试执行效率提升很明显因为不用再反复找人确认。3. 表达规范让人和机器都容易读用例是给人看的也是给机器跑的如果要转自动化。表达规范就是在这两者之间找平衡。太口语化机器解析困难太格式化人看着累。3.1 命名公式动作对象前置条件/期望结果我用的用例命名公式是操作对象 操作动作 特定前置条件 期望结果四选三。像“登录页-输入已注册账号密码-点击登录-跳转首页”就很明确。简洁版本是“成功登录-已注册账号”但我会建议至少保留动作和期望结果。不要出现“测试一下登录功能”这种名字。登录功能如果支持邮箱登录、手机号登录、第三方授权登录至少要拆成三条用例分别命名清楚。命名做好之后搜索用例变得容易自动化脚本的用例标题也能直接关联测试报告维护成本低很多。3.2 用例编号模块化便于追溯而不是增加负担用例编号不是流水号它是定位系统。我用的是“模块代码-功能代码-序号”结构例如LOGIN-001表示登录模块的001号用例。模块代码用文档目录维护不要随便造。模块多了以后这种结构化编号在筛选、导出、关联缺陷时能省大量时间。编号还有一个隐性作用帮助控制用例膨胀。如果LOGIN下的用例超过80条说明登录模块的用例颗粒度过细或者场景重复了该做一次清理了。3.3 标签体系优先级、自动化状态、需求追溯现在的用例管理系统比如TestRail、PingCode、禅道基本都支持标签或自定义字段。我建议至少保留这三类标签优先级P0/P1/P2/P3、自动化状态未自动化/已自动化/自动化失败、迭代版本号。标签最大的价值是后续统计。“这个版本P0用例通过率多少”“新增用例有多少转成了自动化”“自动化用例多久开始腐化”——这些问题都能通过标签回答。否则每次汇报测试报告都得临时翻数据库效率极低。另外建议标签值用统一枚举别写自由文本不然“高优先级”和“P0”混在一起没法归类。4. 执行规范步骤、数据、断言的硬性要求设计表达再好如果执行环节含糊用例还是废纸。这里说的“执行”包括手工执行和自动化执行。我见过团队手工测试时用例步骤描述得清清楚楚一转Playwright就完全不是同一种写法——结果自动化的用例人类看不懂人类的用例机器跑不了。规范必须兼顾两者。4.1 步骤描述的可操作性标准操作步骤里的每个动词都必须是“可以触发某种状态变化的动作”例如点击、输入、滑动、滚动、上传、下载。禁止出现“确认”“检查”“确保”这类无法执行的动词。像“确认页面正常显示”该写成“查看页面右上角存在用户名预期为zhangsan”。对于手工用例步骤里要写明“在哪做”“做什么”“用什么数据”。对于要转自动化的用例步骤最好能对应到某种固定定位策略。我在团队里推行过一种做法手工用例的步骤和自动化脚本的步骤保持同样的自然语言描述然后自动化代码注释里带上用例编号。这样一来出问题时你可以从自动化报错反向找到设计用例从设计用例反向溯源需求。4.2 断言规范断言“业务结果”而不是“过程现象”我觉得测试断言最大的问题是按“UI表现”来写。比如“点击保存后出现绿色提示条”这个断言跑一百遍都过但用户真正想要的是“保存后的数据在数据库里存在”。UI表现可以是补充断言但核心断言一定要绑在业务结果上。根据我的经验按优先级整理断言可以让用例更稳定、更有说服力断言层级示例说明核心状态断言数据库中存在新订单状态为待支付最重要的业务结果页面结果断言订单列表第一条显示单号xxx用户可见的变化辅助交互断言按钮变为“已提交”且不可点击防止重复提交等副作用自动化测试里尤其要少用“页面存在某个元素”这种断言因为它很容易依赖定位器。宁可等待接口响应后断言数据也不要为了省事只检查了一个弹窗。Playwright的expect可以配合response拦截这一点我后面细说。4.3 测试数据准备与清理规范数据问题一直是测试用例执行不稳定的头号原因。手工执行时上一个执行人留下的脏数据会让下一个人的用例失败自动化执行时数据残留会造成重复、越权、权限错乱等诡异问题。我目前使用的规范是这样数据准备必须在用例内部完成用例不能依赖系统里“碰巧存在”的某个账号。比如需要已登录用户就通过API注册一个临时账号需要商品库存就通过接口创建测试商品。用例结束后的数据清理放在后置动作里。清理失败要能准确告警不能默默吞掉。某些场景下数据需要保留比如订单记录那就作为独立测试数据用例明确定义保留规则。测试数据与用例步骤分离。不要在一大段步骤中用“随便一组数据”来替代。数据分析整理成数据表标明每个字段的作用。代码里体现为独立的testData文件。有人会问API准备数据会不会增加很多额外代码确实会。但从长期稳定性看非常值得因为用例的可重复执行性比“少写几行请求代码”重要得多。5. Playwright场景下的用例规范落地我会拿Playwright来举例子因为它现在基本是Web自动化测试的事实标准尤其是它的用例结构、自动等待、断言API都足够现代。下面这些规范不是Playwright独有的但Playwright让它们执行起来更顺手。5.1 用describe和test组织用例结构即规范Playwright的test.describe对应模块分组test对应用例。我会把用例编号写进test的标题里例如test.describe(登录模块 LOGIN, () { test(LOGIN-001 输入已注册账号密码点击登录跳转首页, async ({ page }) { // ... }); });看到这个标题测试报告里可以直接定位到需求。在配置文件中我会让每个测试文件对应一个模块文件名和用例编号的模块代码保持一致比如login.spec.ts里只放LOGIN-*的用例。这样即使项目很大找用例也像翻字典一样快。5.2 定位器规范稳定优先语义明确自动化用例中定位器是最容易“破坏规范”的地方。团队里新人经常写page.locator(div:nth-child(2) span:nth-child(3))这种选择器在页面微调后必挂。我规定的优先级是用户可见文本getByText、getByRole标签关联的labelgetByLabel表单占位符getByPlaceholder自定义>