自动化验收测试

一句话

验收测试（acceptance test）问的不是「代码写对了没有」，而是「用户要的价值有没有交付」。反直觉的是：这一章名义上讲测试，实质上讲需求——它最大的一笔收益发生在写代码之前，在分析师、测试、开发和客户一起把「怎样算做完」写成一条条可执行的验收标准（acceptance criteria）的那个小时里。而它能不能活过三个月，只取决于一件事：你有没有把「验什么」和「怎么点」拆成不同的层。没拆，几千条测试会被界面的每一次微调拖垮，团队最后集体决定弃用；拆了，同样几千条能跑十年。

Glossary · 术语表

坐标

本章在 Part II「部署流水线」里紧接 Ch7：Ch5 画出了从提交到生产的整条传送带，Ch7 放大第一格（提交阶段），本章放大第二格——制品通过提交阶段之后要走的那道验收关。往上，它继承 Ch4 测试策略的四象限，专门承接「业务面 · 支持团队」那一格；往下，Ch9 接手非功能验收（容量、安全），Ch12 展开这里只点了一下的测试数据管理。现实里它对应的是：Cucumber / FitNesse / Concordion 那类工具，Selenium 与它的后代 WebDriver、Playwright、Cypress，以及 AWS 流水线里那个「尽可能像生产」的 gamma 环境。

这章要解决什么

提交阶段绿了，只说明「这次改动没有明显砸锅」。它完全没有回答「用户要的东西做出来了没有」——单元测试是开发者写给自己的，它验证的是「代码按我想的方式运行」，而不是「我想的方式是对的」。这两者的差距，正是返工成本最高的一类缺陷：功能做完了、代码也没 bug，但做的不是客户要的那件事。

旧世界靠人工验收补这个缺口，算笔账就知道为什么撑不住：一个中等规模的业务系统主干场景大约 150~250 个，人工完整回归一轮通常要 2 名测试跑 2~3 天。一年发 12 次版是 50~70 人日；而持续交付的目标是随时可发布，一年发几百次——人工回归在这个频率下不是贵，是算术上不可能。更糟的是它的失效方式：人做第 5 遍重复检查时的注意力远不如第 1 遍，手工回归恰恰是「越需要它可靠时越不可靠」的那类活。

本章还必须回应一个很硬的反对意见，作者开篇就把它摆了出来：「验收测试太贵、写完维护不起」。作者的回答不是否认，而是承认——写得不对的验收测试确实贵到养不起——然后用整章篇幅讲怎么写才不贵。所以这一章的真正主题是可维护性，不是覆盖率。

核心内容，讲透

验收标准是需求活动，不是测试活动

本章第一个、也最容易被跳过的主张：验收标准必须在这条需求开工之前写出来，而且由分析师、测试、开发、客户一起写——它同时是需求说明、验收清单，以及最终那段自动化测试的骨架。为什么坚持「开工前」？因为写验收标准的过程本身就是一次高强度的需求澄清。当你被迫把「支持优惠券」写成「给定一张满 100 减 20 的券、当客户下了一笔 95 元的单、那么券不可用且提示还差 5 元」时，含糊立刻现形。这类分歧在开工前发现，成本是改一句话；等功能做完再发现，成本是返工。本章最大的一笔收益，发生在任何测试代码被写下之前。

与之配套的是责任归属：本章明确反对把验收测试外包给独立的 QA 团队——写代码的人不为绿灯负责，红灯就会变成「别人的问题」然后堆积。这与 Ch3「红了停线」是同一条纪律。测试人员的价值也随之转移：不再是手工重复点击，而是定义验收标准、做探索性测试，这两件事机器都干不了。

分层：本章的核心手艺

如果这一章只能记住一张图，就是这张。验收测试要分成三层（第四层是被测应用本身）：

规矩在中间那道墙：①、② 两层只许出现业务与领域的词汇，「点击 id 为 btn-submit 的按钮」这类话只许出现在 ③ 里，而且只出现一次。收益可以量化：登录页从「用户名 + 密码」改成「手机号 + 验证码」，没分层则凡是需要先登录的测试全要改——通常是整套测试的 80% 以上；分层之后改动落在驱动层那一个 login() 方法上，上面几千条一个字都不用动。验收测试的维护成本，几乎完全由「界面细节被复制了多少份」决定。

从哪一层驱动系统：能不走界面就别走界面

本章第二个关键判断，很多人第一次读会觉得矛盾：验收测试必须测「整个已部署的系统」，但入口应当尽量选在界面之下——通过应用对外的公共 API（也就是界面在背后调用的那一层）驱动它。

理由是速度与脆性的乘积。走界面的一条测试通常要 3~15 秒（等渲染、等异步加载），同一件事从公共 API 驱动往往只要 100~300 毫秒——差一到两个数量级；更要命的是脆：一次前端框架升级、一次布局调整就能让一批测试集体变红，而业务其实一点没坏。

那界面本身谁来测？本章的态度是：界面里若含业务逻辑，第一件该做的事是把逻辑挤出界面，剩下的纯展示部分留少量界面测试盯着。这条建议在今天的前端时代反而更贴切——现代前端堆着大量逻辑，正解依然是让它可被独立测试，而不是把几千条端到端测试架在浏览器上。

为什么不要录制回放

录制回放工具的卖点很诱人：不用写代码，点一遍就有测试。本章明确反对把它当验收测试的主力，三条理由都很硬：

• 它要求应用先做完。验收标准本该在开工前定义、随开发逐步变绿；录制回放只能事后补，直接废掉了本章最大的那笔收益。
• 它把界面细节焊进每一条脚本。录出来的脚本满是坐标、控件 id、页面顺序——正是图 1 里第 ③ 层该关起来的东西，而且复制了几百份。界面一改，全部作废。
• 它产出的东西没人读得懂。脚本表达的是「点了哪儿」而不是「业务上要什么」，于是既当不了可执行规格，失败时也说不出哪条业务规则被破坏了。

本章也留了一个诚实的例外：面对没有任何测试、又必须先改起来的遗留系统，用它临时织一张粗网兜底是合理的过渡——但那是脚手架，不是地基。

验收阶段怎么跑：制品、环境、冒烟、并行

验收阶段在流水线里的形态本章也定得很死：

四个要点，每个都有理由：

• 用提交阶段产出的同一份制品（Ch5 的「只构建一次」）。为验收重新编一次，等于验的不是将要上线的那个东西。
• 部署到生产类环境，用与生产完全相同的部署脚本。这带来一个常被忽略的副产品：你的部署流程本身每天被自动演练很多次，等真正上生产那天，这套脚本已经跑过上千遍了。
• 先跑部署测试（冒烟）。验收阶段的失败有很大一部分根本不是应用缺陷，而是环境配错、服务没起、依赖不通。几条极简检查先确认「环境是活的」，能把大量红灯一眼定性成环境问题，省下漫长的误诊。
• 红了就停线，整个团队负责。这里比提交阶段更难守：验收测试慢、失败原因杂，最容易演变成「先挂着回头再看」——而挂着的红灯会迅速蔓延成全员无视。

关于时长，本章不给「十分钟」那样的硬数字，只给相对约束：验收阶段慢得起，但必须短到一天能跑很多轮。工程上的答案就是并行——按业务场景切片撒到多台机器上，总耗时取决于最慢的那一片而不是所有片之和。这条路能走多远，§6 里 LMAX 的公开数字给了一个上限参考。

状态与测试数据：验收测试最脏的地方

单元测试可以假装世界不存在，验收测试不能——它跑在一个有数据库、有历史数据的真实系统上。状态是验收测试一切诡异失败的源头：跑第二遍时用户名已存在、上一条测试留下的订单污染了统计、两条测试并行时抢同一个账号。本章给了三种应对姿势，并明确了偏好：

• 测试隔离（推荐）：每条测试自造所需数据，用带随机后缀的唯一键（如 user-7f3a91）。代价是要提供造数据的手段，收益是可以任意并行、任意顺序跑——而并行是解决「慢」的唯一出路，所以这两件事其实是同一件事。
• 自适应测试：不断言绝对值，只断言相对变化（「下单后该客户的订单数比之前多 1」）。适合必须在有存量数据的环境里跑，代价是断言变弱、写法更绕。
• 测试排序：固定顺序、后一条吃前一条留下的状态。本章不推荐——它堵死了并行，而且一条失败会引发下游全线红。

头号反模式是全组共用一份「大胖测试数据库」：起步很快，然后随时间腐坏——没人记得哪条数据是给谁用的，没人敢删，最后它自己变成要维护的遗产。测试数据的完整讨论在 Ch12。

异步、时间与外部系统

验收测试跑在真实系统上，就必须面对真实系统的三件麻烦事：

• 异步：下单之后确认邮件不是同步返回的。正确做法是带超时的轮询——每隔一小段时间查一次，直到成立或超时失败，而不是散落各处的固定 sleep。固定等待要么白等（拖慢整套）要么不够（变成不稳定测试），两头不讨好。
• 时间：「30 天后过期」「月末结算」这类逻辑不能靠真等。要把「现在几点」做成系统可控的东西，让测试能把时钟拨到任意时刻。
• 外部系统：第三方支付、征信、物流通常慢、不稳，甚至没有测试实例，本章的做法是用桩顶替。但必须诚实记账：桩掉的那部分就没被验证，所以要另有一组针对真件的集成测试，在别的阶段或按较低频率跑。

关键权衡与选型

表 1 · 一条验收测试该从哪一层驱动系统

表 2 · 验收标准怎么落成可执行的东西

表 3 · 验收测试的状态（测试数据）怎么处理

表 4 · 验收阶段太慢了怎么办

表 5 · 一项检查到底该放哪一关

五张表背后是同一条判据：验收阶段的每一分钟都很贵，所以只买那些「必须让整个系统串起来才能证明」的东西。能在提交阶段用毫秒验完的，别放进来；机器答不了的，别硬塞给机器。

为什么重要 / 落到真实系统

这一章的主张今天全都变成了默认实践，只是换了名字：驱动层长成了业界通用的 Page Object 模式；Given/When/Then 长成了 Cucumber / SpecFlow / Behave 一整个工具家族；Selenium 的 WebDriver 接口成了 W3C 标准，Playwright、Cypress 是同一条路上的后来者；「生产类环境 + 冒烟先行」则变成了云上流水线标配的预发环境与部署后健康检查。

但今天最值得讨论的，是它引发的那场争论：端到端验收测试到底该有多少？正反两方都留下了公开可核实的数字。

面试与架构评审里这是高频考点。被问到「你们的端到端测试怎么做」，能拿分的答法不是报工具名，而是四个事实：有没有独立的驱动层（界面一改要动多少条测试）？套件跑一轮多久、并行度多少？失败里环境问题占多大比例、怎么和业务缺陷分流？不稳定的那些是隔离限期修，还是无限重跑？

易错点与争议

• 最常见的死法：把验收测试写成 UI 脚本。控件 id、页面顺序被复制进几百条测试，一次改版全线飘红，团队修了两周后决定「先禁用一部分」——从此这套东西进入不可逆的衰亡。验收测试的存亡由分层决定，不由数量决定。
• 把验收测试外包给独立 QA 团队。本章明确反对。写代码的人不为绿灯负责，红灯就成了别人的问题；正确的做法是整个交付团队共同拥有，测试人员的精力转向定义验收标准与探索性测试。
• 「BDD 剧场」。用了 Cucumber，写了一堆 Given/When/Then，但业务方从来不读——这层自然语言就成了开发者写给自己看的额外胶水。判据很简单：过去三个月，有没有非开发角色真的读过或改过这些文件？没有的话，直接用编程语言写 DSL 更划算。
• 用无限重跑治不稳定。验收测试天生比单元测试更容易抖（Google 的数据说明了原因），于是「失败自动重跑三次」成了很多团队的默认配置——它同时也掩盖了真实的并发与时序缺陷。正解仍是隔离 + 限期修 + 统计不稳定率。
• 争议：端到端测试该有多少。Google 说 10%，LMAX 跑 11,000 条，两边都不是胡说。差别在三个变量：有没有 DSL 与驱动层兜住维护成本、机器成本能不能承受、领域是否要求端到端正确性（金融撮合与内容网站的答案本就不同）。诚实的结论是：没有 DSL 和分层的团队，Google 的建议对你是对的；有了它们，LMAX 那条路才走得通。
• 时代局限。本书写于 2010 年，早于容器与云——当年「生产类环境」贵得要命，今天用容器编排几分钟就能拉起一套，本章的许多妥协可以放宽。另一方面，本书成书时还没有消费者驱动的契约测试（consumer-driven contract testing，如 Pact）：在今天的微服务架构下，跨服务的端到端验收测试有相当一部分可以被契约测试替代——各服务独立验证「我承诺的接口没变」，比把几十个服务全拉起来跑一遍便宜得多。这是本章之后最重要的一次方法论补充。

要点