我刚入行那会儿写过一份自以为很周全的测试用例结果被测试组长批了三十多处第一句评语是这不是测试用例这是操作说明书。后来自己带团队一周要看几十份用例我才慢慢理解他说的意思——测试用例从来不是步骤的堆砌它是产品行为的一份可执行契约也是整个质量保障体系里最容易被低估、却最值得打磨的东西。这篇内容写给三类人刚入行不知道怎么下笔的测试新人写了很多用例但总被开发说“测不出来 bug”的进阶工程师以及准备把手动用例转成 Playwright 自动化脚本、或者用 Tessy 这类嵌入式工具批量导入 Excel 用例的团队。我会按照自己平时写用例的真实流程来讲动笔之前想什么、字段怎么设计、方法怎么选、期望结果怎么写才算有用最后给一份登录模块的完整模板并延伸到自动化和用例资产管理。全程没有空话都是可以直接抄作业的东西。1. 测试用例到底是什么——它不是文档而是一份可执行的契约很多人一打开用例模板就开始填“步骤 期望结果”填完一百条自我感觉良好。但这类用例有个通病它只描述了“操作路径”没有描述“判断标准”。你写“点击保存按钮保存成功”执行的人看着系统弹了个“保存成功”就点了通过——结果数据库里的记录根本没写进去或者写完了一条脏数据。问题就出在用例本身没有把“成功”定义清楚。我现在的理解是测试用例是产品行为的可执行契约。它要回答的问题不是“怎么操作”而是“系统在这个输入下应该表现出什么行为并且用什么证据证明这个行为是对的”。比如登录用例的期望结果不该是“登录成功”而应该是“页面跳转到 /home右上角展示用户昵称测试用户同时数据库 session 表新增一条记录token 过期时间等于当前时间加 24 小时”。这样写开发和测试对“成功”的理解才不会出现偏差。用生活化的类比来说用例更像菜谱而不是购物清单。购物清单只告诉你需要买什么菜谱则会告诉你每样菜怎么切、放多少盐、炒到什么颜色出锅、出锅标准是什么。测试用例的价值密度恰恰体现在后半部分——那些可验证的“出锅标准”。还有一个经常被忽略的事实测试用例的核心价值在“回归”。上线那一刻它只是在执行真正发挥作用是三个月后、半年后当你需要在半小时内确认这次改动有没有把老功能弄坏的时候。一份只有操作步骤没有判断标准的用例在回归时就是废纸——执行人只能靠猜来判断结果对不对猜出来的结论你敢信吗所以每次有人问我“写用例最快的办法是什么”我的回答都是先别急着写想想三个问题——这个功能给谁用、输入是什么、系统应该吐出来什么。想清楚这三件事用例就完成了一半。2. 动笔之前我写用例前一定会做的四步准备写用例最高频的失败原因不是格式问题而是需求没吃透。我以前见过一个同事对着原型页面写用例写了四十条全部关于按钮颜色和布局结果最核心的“优惠金额计算”一条都没有——因为原型页面上根本没画计算规则他也就没写。这告诉我们用例的输入不是页面是需求本身。我的准备工作固定分为四步每一步都有明确产出。2.1 收集信息不止看需求文档第一步是收集信息。除了需求文档和原型我还会拉着开发要接口文档、数据库表结构去找产品问清楚那些不会写进需求的隐含规则。比如“手机号登录”看起来很简单但隐含规则可能有一大堆手机号格式校验是前端做还是后端做未注册手机号是提示“用户不存在”还是统一提示“用户名或密码错误”验证码有效期是 5 分钟还是 1 分钟发送验证码有没有 60 秒冷却限制这些东西需求文档里往往都不写但不问清楚用例后面全是坑。我还一定会去翻一遍历史 bug 记录。每家公司都有那么几个反复出问题的模块历史缺陷就是最好的用例素材库。我之前在一家电商公司测结算模块翻历史缺陷发现“使用优惠券后订单金额为 0 时仍然可以提交”这个 bug 出现过两次我就把这条加进了用例的回归集合后来果然又拦下一次。2.2 把需求拆成可测的功能点第二步是把需求拆解成“可测的单元”。做法很简单需求里的一句话拆成系统需要判断的每一个动作。例如需求写“支持手机号登录”我可以拆出这些测试点手机号格式校验位数、字符集、首位数字未注册手机号的处理密码错误处理密码连续错误次数与账号锁定规则验证码发送、过期、重发规则如果走验证码登录登录成功后的页面跳转和数据写入已登录状态下再次访问登录页的处理这样拆完你会发现“登录”这个一句话需求实际有 7-8 个可测单元每个单元再往下展开才是具体用例。不要跳步直接写用例因为跳步大概率会漏掉某个分支。2.3 按正向、反向、非法三层铺开第三步是给每个功能点铺场景我习惯分成三层正向流程、反向分支、非法输入。正向流程是用户按正常路径操作能成功反向分支是用户操作不完整或条件不满足比如密码错、账号锁定非法输入是输入超长、空值、特殊字符、格式错误等。这三层不是三份文档而是在同一份用例里交错铺开。很多新人写用例只写了正向和部分反向非法输入层完全空白这是覆盖率低下的主要原因。2.4 给用例定优先级第四步是定优先级。我习惯用“影响面 × 发生可能性”来定核心业务链路、发生频率高、影响范围大的用例是 P0异常分支、边界条件是 P1兼容性、体验类问题是 P2。优先级的意义不只是排序它决定了回归测试时哪些用例必须执行、哪些可以跳过。没有优先级标注的用例集在时间紧张的时候根本无法决策只能全做或者全不做这是团队效率的大敌。做完这四步你的纸上应该有一张功能点覆盖矩阵。这个时候再打开测试用例模板才算真正准备好。3. 八个字段背后的取舍逻辑为什么这些字段一个都不能少市面上的测试用例模板字段大同小异常见的核心字段是用例编号、用例标题、前置条件、测试数据、操作步骤、期望结果、优先级、实际结果。很多新手嫌字段多直接精简成“步骤 结果”结果维护时叫苦不迭。我逐个说一下每个字段存在的理由以及怎么填才有价值。3.1 用例编号可追溯的起点用例编号不只是流水号它是整个追溯体系的主键。我常用的命名规则是模块缩写_场景编号例如TC-LOGIN-001再在用例管理工具里关联需求编号。这样当你发现某个用例失败了能立刻反查它对应的是哪条需求、影响哪个功能。没有编号的用例在 Excel 里排序一次就废了。3.2 用例标题一句话说清楚“测什么”用例标题的黄金标准是不点开详情只看标题就知道这条用例在测什么。所以不要写“登录功能测试”要写“密码连续输错 5 次后账号被锁定第 6 次输入正确密码仍被拒绝”。标题要把前置条件、测试数据、预期行为浓缩成一句话它是用例列表里最重要的索引信息。3.3 前置条件区分“环境状态”和“数据准备”前置条件是最容易被新手忽略的字段。它的作用不是写“系统正常”而是明确这条用例运行的环境状态和数据状态。比如“账号 test_user 已存在且未被锁定”“系统当前时间处于活动期间内”“数据库中订单状态为待支付”。前置条件写清楚用例才具备可重复执行的基础否则执行到一半发现环境不对前面所有步骤都白做。3.4 测试数据参数化的思想从小就开始测试数据字段要具体到可以直接执行的值而不是“输入一个存在的手机号”。比如“手机号 13800138000密码 Test123”同时我建议大家从手动用例开始就养成“变量 取值”的习惯像“用户名 ∈ {有效值空值超长值特殊字符}”这就是最朴素的参数化思想。等将来转自动化这个习惯会帮你省掉大量重构成本。3.5 操作步骤粒度越小越好操作步骤的粒度没有一个强制标准但有一条原则每一步只做一个主操作并且包含定位信息。很多人写步骤只写“点击保存”执行人打开页面半天找不到保存按钮在哪。更好的写法是“点击页面右上角蓝色保存按钮”。其实这就是自动化的定位器思想——手动阶段把步骤写清楚转自动化时直接能翻译成选择器。3.6 期望结果整个用例的灵魂期望结果是八个字段里最重要、最容易被写废的一个。我见过最多的写法是“系统提示错误”“保存成功”“页面跳转”这些全是废话因为“提示错误”没有提示什么文案“保存成功”没有说你观察到什么才算成功。期望结果必须满足三个要求可判定、无歧义、可验证。我会在第六章专门展开讲这一块这里先记住结论期望结果是你判断用例通过与否的唯一依据写得不具体执行人就是在赌。3.7 优先级和实际结果优先级前面讲过这里补一句执行层面的实际结果字段不要在测试执行时跳过它是 bug 报告的第一手材料。你实际看到的现象、实际数据、错误截图都比事后回忆可靠得多。我见过很多团队把实际结果留空出了问题回头翻什么证据都没有最后只能重测一遍这个习惯非常坏。4. 设计方法怎么选等价类、边界值、场景法、判定表的组合实战测试用例设计方法教科书上写了一堆但很多人学完不知道什么时候用哪个。我的经验是方法不是互相独立的一份合格的用例集通常是三四种方法叠加出来的。下面我用登录模块这个大家最熟悉的场景把每种方法的作用范围讲清楚。4.1 等价类划分先圈定“值”的范围等价类解决的是“输入值怎么选”的问题。测试不可能穷举所有输入所以把输入域划分为若干个互不相交的“等价类”在每个等价类中取一个代表值覆盖率即可。例如用户名字段要求 3-20 个字符有效等价类就是 3-20 字符的合法字符串无效等价类包括少于 3 字符、多于 20 字符、包含非法字符、纯空格等。每个等价类取一个代表值就构成了一条用例。这里有个常见误区认为等价类取一个值就万事大吉。事实上等价类是在“同一类错误”的前提下才成立的理论如果某类输入在底层走了不同的代码路径你就该拆成两个等价类而不是硬套。比如“空字符串”和“null”在多数编程语言里走的分支完全不同必须分别设类。4.2 边界值分析绝大多数缺陷都挤在边界上边界值法几乎是等价类法的最佳搭档它的经验依据是程序的缺陷往往集中在输入域的边界而不是“正常范围”的中部。用户名字段长度 3-20那么 2、3、20、21 这四个值就是必须覆盖的边界至于 7 个字符这种中间值从等价类角度取一次即可。边界值不只用于长度还用于数值范围、时间范围、金额累计等一切有数值界限的地方。我测一个优惠券系统时优惠金额上限是 100 元我专门测了 99.99、100.00、100.01 三个值结果 100.00 这个“刚好等于上限”的用例暴露了一个浮点精度 bug开发自己都很意外。4.3 场景法从“单个输入”走向“完整用户旅程”等价类和边界值关注的是单个输入点的输入输出关系但用户不是一个个输入框去操作的他们是在走一条完整的流程。场景法按照“事件流”组织用例主事件流是用户最常用的路径备选事件流包括异常路径和分支路径。登录场景的主事件流是打开登录页 → 输入正确账号密码 → 点击登录 → 进入首页。备选事件流包括密码错误、账号锁定、找回密码、发送验证码失败、登录成功后回跳原页面等。场景法最有价值的地方是能发现“跨步骤的组合状态”比如“连续输错 3 次密码 → 点击忘记密码重置密码 → 用新密码重新登录成功”这个完整链条等价类法和边界值法都测不出这个组合场景只有场景法能。4.4 判定表当条件和动作组合爆炸的时候判定表适合“多个输入条件每个条件两种状态对应不同输出”的场景。比如登录的条件有记住密码是/否、新设备是/否、短信验证码开启是/否——3 个条件就是 8 种组合判定表可以把每一种组合对应的期望行为列出来不漏不重。用判定表要注意不是所有条件都值得做全组合。条件超过 5 个比如 2 的 5 次方就是 32 种组合时要结合业务风险忽略掉影响小的组合只对核心组合做全覆盖。这时候可以配合正交试验法用最少的用例覆盖最多的组合。4.5 错误推测法把踩过的坑固化下来错误推测法不是一种“科学”的方法它完全依赖测试人员的经验和在这个产品上踩过的坑。常见的推测点包括空值、超长字符串、全角半角字符、首尾空格、复制粘贴、重复点击提交、弱网超时、跨页面返回后数据是否还在等。我的做法是维护一份“个人缺陷模式清单”每踩到一个新坑就记一笔例如“富文本内容提交时使用了 script 标签需要验证转义”。积累一段时间后你会发现写用例时很多异常分支根本不用想扫一眼清单就全带上了。错误推测法和前面几种方法的关系是等价类、边界值负责做成系统的网格错误推测负责在地图上的高危区域优先仔细侦察。5. 登录模块完整示例从需求拆解到可直接套用的用例表下面我按前面讲的思路把登录模块的核心用例完整列出来。这组用例是我在实际项目中整理的简化版格式可以直接复制到 Excel 或任意用例管理工具中。为了演示我把“测试数据”列也保留在表里。用例编号用例标题前置条件测试数据操作步骤期望结果优先级TC-LOGIN-001有效用户名和正确密码可登录成功系统已部署账号 test_user 状态正常用户名 test_user / 密码 Test123打开登录页输入用户名输入密码点击登录页面跳转到 /home 首页右上角显示昵称“测试用户”数据库 session 表新增记录且过期时间为 24 小时后P0TC-LOGIN-002密码错误时提示“用户名或密码错误”同上用户名 test_user / 密码 Wrong123打开登录页输入用户名和错误密码点击登录页面出现红色提示“用户名或密码错误”用户名输入框保留原内容密码框被清空URL 不变P0TC-LOGIN-003未注册用户名登录时统一提示错误系统已部署用户 u_notexist 不存在用户名 u_notexist / 密码 Test123同 002提示与 002 完全一致不区分“用户名不存在”防止账号枚举P1TC-LOGIN-004用户名为空时登录按钮不可提交打开登录页即可用户名空 / 密码任意打开登录页不输入用户名直接点击登录登录按钮不可点击或点击后提示“请输入用户名”页面不跳转P1TC-LOGIN-005密码连续输错 5 次后账号被锁定测试账号 lock_test 初始未被锁定用户名 lock_test / 密码依次输入 5 次错误值连续提交 5 次错误密码第 6 次输入正确密码提交第 5 次提交后提示“账号已锁定请 24 小时后再试或找回密码”第 6 次即使密码正确也提示锁定P0TC-LOGIN-006登录时输入内容含首尾空格可正常登录账号 test_user 状态正常用户名 test_user / 密码 Test123 输入含首尾空格的用户名和密码点击登录登录成功系统自动去除首尾空格跳转首页P2TC-LOGIN-007勾选记住登录后 7 天内免登录账号 test_user 状态正常用户名 test_user / 密码 Test123勾选“记住登录”登录成功关闭浏览器重新打开站点无需输入密码直接进入首页cookie 中登录凭证有效期 7 天P1TC-LOGIN-008登录提交时网络中断提示异常无特殊前置用户名 test_user / 密码 Test123登录页填写正确账号断网点击登录页面提示“网络连接异常请稍后重试”不跳转恢复网络后再次点击登录成功P1TC-LOGIN-009用户名输入脚本内容按普通文本处理无特殊前置用户名scriptalert(1)/script/ 密码任意将脚本内容粘贴到用户名框点击登录页面不执行脚本、不弹出 alert按普通错误输入处理并提示错误P1TC-LOGIN-010用户名字段长度边界值2/3/20/21 字符无特殊前置用户名分别为 2、3、20、21 字符的正常字符串依次输入 2、3、20、21 个字符的用户名输入对应密码点击登录2 和 21 字符时提示格式错误3 和 20 字符时正常进入密码校验流程P2这十条用例看起来简单但覆盖逻辑并不简单。001 和 002、003 覆盖了等价类的有效和无效分支010 覆盖了边界值005 和 007 来自场景法中的账号状态切换008、009 来自错误推测法004 是空值这种最常见的缺陷模式。关于 003也许有人会质疑“提示和 002 一致”这条我特意把它加进来是因为很多团队在这个细节上吃过亏。如果系统直接提示“用户名不存在”攻击者就能扫描出哪些账号是真实注册过的。作为测试工程师合规要求我们不允许出现这种账号枚举漏洞所以哪怕产品没有明确要求这条用例也应保留。6. 期望结果写得好不好决定了这副安全网有没有网眼这一章专门讲期望结果因为它太重要又太容易被写废。我审用例时先看期望结果——期望结果烂的用例步骤写得再漂亮我也不会让它过评审。下面我用真实案例来对比。低质量期望结果我在无数项目里见过“系统提示错误”——提示的是什么文案在哪个位置出现什么颜色和样式都没说。“保存成功”——保存到哪个表刷新后数据还在吗条数是否唯一都没说。“页面跳转”——跳到哪个地址旧页面关没关浏览器前进后退行为是什么都没说。高质量期望结果是这样写的页面顶部出现红色提示文案“用户名或密码错误”用户名输入框保留输入内容密码输入框被清空浏览器地址栏仍为 /login无跳转行为。点击“保存”后接口 POST /api/order 返回 200响应体 orderId 为新生成的 12 位数字刷新列表页后可以看到编码为 SO20241111001 的新订单状态为“待支付”。登录成功后浏览器地址变为 https://example.com/home右上角显示昵称“测试用户”退出按钮可见同时调用 GET /api/user/info 接口返回 200 且响应体 nickname 等于“测试用户”。可以看出来高质量期望结果分三层UI 层用户看到的变化、接口层网络请求和响应、数据层数据库/存储的变化。我一直建议测试人员在写期望结果时至少包含两层。UI 层能证明用户界面表现正确数据层能避免“界面成功但数据没写进去”的假通过。举一个我实际踩过的例子一个支付模块的用例期望结果写着“订单支付成功后显示支付完成”执行人也点了通过。但后来生产环境发现有一批订单实际上没支付成功、却在页面上显示支付完成——原因是前端拿到支付回调的成功标志就展示了结果而数据库里的支付状态更新失败了。这就是典型的只写了 UI 层、没写数据层的后果。从那以后我把支付类用例的期望结果统一改成“页面显示支付成功 数据库 ord_pay_status 字段更新为 2 支付流水表新增一条 pay_id 记录”三层齐全这类问题再没漏过。期望结果里还要注意“可判定”这个细节不要用“很快”“正常”“正确”这种主观词要写可测量的指标。例如“登录响应时间不超过 3 秒”而不是“登录速度很快”。执行人不需要有专业背景看到描述就能给出明确结论这才算合格。如果你觉得每次写三层期望结果太啰嗦我提供一个折中模板“用户观察到的现象UI 系统返回的数据接口 关键数据的最终状态库/存储”。写的时候结合用例优先级P0 用例写成三层P1 至少写成两层P2 可以只写 UI 层加轻量描述。7. 自动化来了怎么办用 Playwright 把用例变成可执行的断言现在很多团队都在做自动化回归Playwright 是前端测试里很热门的选择。但我想先说一个容易搞反的事不是“把以前手动的用例转录成代码”而是“按自动化的要求重新设计用例”。手动用例允许环境不稳定、允许步骤里有模糊描述、允许执行人“看情况判断”。自动化不行机器没法“看情况”它需要的是确定性的输入、确定性的步骤、确定性的断言。7.1 手动用例转自动化的选择标准先过一个筛选哪些手动用例值得转自动化我的标准三条——大概率会回归、核心业务路径、执行成本高。像登录、加购、支付、结算这种每个版本都要回归的路径优先转。像“用户名字段长度 20 和 21 字符的边界比较”执行成本也不高但回归频率低自动化优先级就往后放。反而不建议自动化的类型强依赖真实第三方数据的场景除非你能稳定 mock、需要人工视觉判断的审美类场景、每次执行都需要动态准备复杂数据的场景。硬转自动化只会得到一个三天两头因为环境原因挂掉的测试套件维护成本远超收益。7.2 用例标题直接成为测试用例名转换时最省力的做法是保留手工用例的编号和标题让自动化脚本和手工用例一一对应。例如登录模块的手动用例TC-LOGIN-002转成脚本就是// 对应手工用例 TC-LOGIN-002密码错误时提示“用户名或密码错误” import { test, expect } from playwright/test; test(TC-LOGIN-002 密码错误时提示“用户名或密码错误”, async ({ page }) { await page.goto(https://example.com/login); await page.getByLabel(用户名).fill(test_user); await page.getByLabel(密码).fill(Wrong123); await page.getByRole(button, { name: 登录 }).click(); // 期望结果第一层UI 层 await expect(page.getByText(用户名或密码错误)).toBeVisible(); await expect(page.getByLabel(用户名)).toHaveValue(test_user); await expect(page.getByLabel(密码)).toHaveValue(); // 期望结果第二层接口层 const loginResponse await page.waitForResponse(**/api/login); expect(loginResponse.status()).toBe(401); });这段代码基本就是把第 6 章的高质量期望结果原样翻译成断言。如果手工用例的期望结果写得含糊转自动化时你会卡在“到底该断言什么”上无从下手。反过来期望结果写得具体转自动化其实就是体力活。7.3 自动化用例要对“稳定性”重新建模手动用例里不太在意的细节自动化里全是坑。比如数据独立性自动化用例不能依赖手动测试留下的数据状态每条用例要自己创建数据或清理数据。我一般用 API 直接预置数据而不是靠 UI 一步步搭环境。可重入性用例执行失败后重跑要保证能回到初始状态。所以前置条件里的“账号锁定”这种有状态的数据自动化里要专门准备一个可以被锁定、也能被解锁的隔离测试账号。等待策略Playwright 自带自动等待但 click 之前如果网络慢还是可能触发“页面重定向导致的元素丢失”。遇到这种情况我会在关键跳转后用expect(page).toHaveURL(...)确认当前页面再去操作后面的元素。网络异常流手动用例里的“断网”场景自动化里用page.route()拦截并让请求失败来模拟。稳定性优先于覆盖率。一个不稳定的自动化套件在 CI 里天天误报最终会被团队弃用。我的经验是宁可维护 30 条跑 100 次都稳定的用例也不要 100 条跑一次挂一次的用例——后者不仅没有减轻负担反而让团队对自动化彻底失去信心。8. 用例的资产管理评审、维护以及 Tessy 工具场景下的 Excel 整理术写完了用例是不是就万事大吉了远没有。测试用例是资产资产就要管理。我看到不少团队用例库用得乱七八糟同一个需求有几十条一模一样的老用例需求改了用例不更新最后干脆没人看。这一章讲我怎么把用例库从“一次性文档”变成“活资产”。8.1 用例评审查的不是格式是风险用例写完后我建议再组织一轮评审评审对象不一定只有测试最好拉上产品和开发。评审时我主要看五件事有没有漏掉核心链路的关键分支对着功能点拆分清单逐项打钩。期望结果是否三层齐全是否可判定。有没有重复用例同一场景同一数据在多个用例里反复出现。优先级标得是否合理P0 用例是不是真的高影响面。用例是否依赖一个不确定的外部环境比如实时汇率、当前时间。评审不是过堂目的是提前发现用例盲区。我见过最有效的评审方式是让评审人随机挑三条用例现场按用例执行一遍不许看系统实现只看用例描述能不能指导他判断结果。一次就能测出用例质量的大问题。8.2 维护规则用例跟着需求走不跟着感觉走需求变更是用例维护的主要驱动力。我的维护规则很简单需求变更时先把旧用例标记为“废弃”再写新用例不要在原用例里改来改去。因为当一条用例的标题、数据、期望结果有一半被改过的时候它已经是一条新用例了保留旧痕迹只会让历史追溯混乱。执行频率统计也是一个好用的维护手段。用例管理工具里一般都有“最近三个月被执行次数”这种数据。执行次数为零且不在任何回归集合里的用例基本可以标记废弃。用例库最怕的不是缺用例而是堆了一堆没人敢删的僵尸用例——它们会淹没真正需要关注的用例增加回归成本。8.3 Tessy 等工具场景下为什么 Excel 整理方式决定了导入效率嵌入式测试领域常用 Tessy 这类工具做单元级测试用例它的用例通常通过 Excel 表格批量导入。这个场景和 Web 测试完全不同用例的对象不是页面而是被测函数期望结果不是 UI 现象而是函数的输出参数、全局变量变化和桩函数行为。我的同事们刚用 Tessy 时最常犯的错是在 Excel 里把用例写得像功能测试报告。后面折腾几次后我们固定了一套表头结构按这个整理导入基本不报错列名填写样例说明TC_IDTC_CALC_001唯一用例标识Tessy 用它做映射被测函数int calc(int a, int b)函数签名必须与工程中完全一致输入参数a1; b2分号分隔多个参数变量名必须匹配全局变量初值g_flag0被修改的全局变量在这里设初值桩函数行为mock_net_send return 0配置桩函数返回值按工具要求写期望输出return3; g_flag1预期返回值与关键全局变量终值覆盖目标MC/DC可选指定动态覆盖目标这份表头用过之后我总结了 Excel 整理的几条经验不要用合并单元格。Tessy 导入时合并单元格会造成数据错位宁可在多行里重复写用例标题。变量名与函数签名严格一致。Excel 里写的参数名和工程代码里不一致时导入直接失败这个报错排查起来非常痛苦。桩函数配置单独一列别杂在期望输出里。混在一起会让人分不清“这是我们要设的桩还是期望的结果”。每个用例独立一行不要为了省事把多个输入组合塞进一个单元格。参数化不是让你把它们挤在一起而是多行多用例。嵌入式用例的维护和 Web 用例同理函数签名一改Excel 里的被测函数列要同步更新否则下次导入就会拿到一片红线报错。建议每次提测前专门检查一次这两个列能省掉整个下午的排障时间。另外多说一句别指望工具能替你设计用例。Tessy 能把 Excel 变成可执行的测试但 Excel 里的内容有没有覆盖到函数的边界和异常分支还得靠测试人员按第 4 章的方法去设计。工具只负责执行设计依然是人的事。我自己带团队时最常用来检验用例质量的一句话是如果明天换一个完全没参与过需求的人来执行这份用例他能不看代码、不问开发就判断出系统行为对不对吗如果能这份用例就是合格的。这也是我给所有测试新人的第一个目标——先把“判断标准”写到别人照着做也能一眼看出毛病再谈那些更花哨的东西。