实施测试策略

一句话

你以为「测试策略」是决定测多少、谁来测、覆盖率定几成，其实这一章问的是另一个问题：每一类风险，该由谁在什么时候、用多大代价去回答？答案有两半。第一半是分类——用「面向业务 / 面向技术」×「支持开发过程 / 评判已有产品」两条轴把测试摊成四个象限，每格的问题与自动化命运都不同：能重复、答案二值的交给机器天天跑；靠好奇心去发现「你根本没想到的问题」的（探索性、易用性）留给人。第二半是落地顺序——新项目、中途项目、遗留系统三种起点，先补哪一类完全不同。全章立场一句话：测试不是一个阶段，是贯穿始终的活动；质量是全队的事，不是测试组的事。

Glossary · 术语表

坐标

Part I「基础」的收尾章，也是第 3 章欠下的债的偿还：持续集成要求「一套全面的自动化测试」，本章回答那套测试到底该长什么样、谁写、跑在哪。往后，第 5 章的部署流水线会把这四类测试排成先后关卡（第 7 章提交阶段跑单元测试、第 8 章展开自动化验收测试、第 9 章处理非功能测试）。今天的对应物：测试金字塔之争、Google 的 small / medium / large 测试分级、契约测试（contract testing）、以及「灰度 + 可观测性」这种把验证右移到生产的做法。

这章要解决什么

先摆个场景。30 人团队做支付网关，两周一版，测试排在发布前最后三天：6 名测试工程师照着一张 400 条的手工回归清单从头点一遍，一轮两天，紧张时就「挑重点跑」。三处结构性漏水：

• 反馈延迟被拉到最大。缺陷平均在写下后两周才被发现，那时作者早已切换上下文——正是第 1 章那条「发现越晚越贵」的曲线。
• 成本随功能数线性上涨。功能翻倍，手工回归从两天变四天，而发布周期还想缩短。手工回归是唯一一种做过的功课不能存档、每轮都要重付全款的测试。
• 结论不可复现。「测过了」到底测了哪 370 条、跳过哪 30 条，下一轮无人可考。

不解决会怎样？项目末期长出一个工期不可测的「测试阶段」黑洞——和第 3 章那个「集成阶段」黑洞是同一种病：本该每天做一点的事，攒到最后一次性结算。但本章同样反对另一个极端：全押自动化也不行，机器只会验证你事先写下的断言，而真正贵的缺陷往往是没人想到要写断言的那些。所以解法不是「自动化一切」，而是先分类，再决定每一类的命运。

核心内容，讲透

一、第一个断言：测试不是一个阶段

原书开宗明义：测试是一项跨职能（cross-functional）、贯穿全程的活动，质量由全队负责，而不是丢给下游的测试部门。落到动作上有三条：测试人员从第一天参与写验收条件，与分析师、开发一起把「怎样算做完」定死在开发之前；「完成」的定义里包含「测试通过」；缺陷一旦逃逸到后期或生产，先写一个能复现它的自动化测试再去修，否则同一个坑一定被踩第二次。

更根本的理由是这套测试网给的东西：改动的勇气。没有它，重构就是赌博，团队会自然选择「绕着走、复制一份改」。这与第 3 章互为因果：CI 让你天天集成，测试网让你敢天天集成。

二、四象限：一张图把「谁来测、为什么测」摊开

本章的骨架是 Brian Marick 提出、后由 Crispin 与 Gregory 在《Agile Testing》中推广的测试象限。两条轴各问一个问题：这个测试面向业务（用领域语言写，客户看得懂）还是面向技术（只有开发看得懂）？它支持开发过程（动手之前 / 之中写，防止缺陷被引入）还是评判已有产品（做出来之后跑，去发现你没想到的问题）？

三、支持开发的两类：自动化的主力

面向技术那一格是开发者的安全网：单元测试（几千个在几分钟内跑完，红了几乎能直接定位到函数）、组件 / 集成测试（连着真实依赖一起测，慢一个数量级，但能抓住单元测试看不见的接线问题）、部署测试（冒烟测试）——部署完立刻跑的一小把检查，只问「服务活着吗、配置连对了吗」，成本最低、收益最高，却最常被忘。

面向业务那一格是自动化功能验收测试：用业务语言写（「给定余额为 0，当用户下单，则被拒绝并提示充值」），在开发之前写好并当作验收条件，跑在尽量接近生产的环境上。它一身两职——既是「做完没有」的判据，也是此后永久的回归网。原书的态度很清醒：这是四类里最贵、最脆、最难维护的一类，要造数据、拉起整套环境、跨越界面。所以数量要克制（数十个而非数千个），只覆盖最有价值的业务路径，并分层写——业务意图一层、驱动应用的技术细节另一层，界面一改不至于全线飘红。

四、评判产品的两类：机器替不了的那一半

手工的那一格有三件事，价值都来自人。演示（showcase）：迭代末把真实系统跑给客户看，暴露的是「做对了没有」——需求理解错了，多少自动化测试都是绿的。易用性测试：只有人能说出「这个流程我走不下去」。探索性测试：不是乱点，而是一项有目的的创造性活动——边学系统边设计新实验，专门去撞没人写过断言的角落。原书由此点明自动化的真正目的：不是取代测试人员，而是把他们从重复的手工回归里赎出来去做这三件事。

非功能那一格是容量、性能、安全、健壮性。它必须先把要求量化成可判定的阈值（如「峰值 3000 QPS 下 p95 响应时间不超过 200 毫秒」——p95 指把一百次请求按耗时排队、第 95 快的那次），否则没法自动判定通过与否，只能沦为一份没人读的报告。它还需要专门工具与接近生产规模的环境，故排在验收测试之后。

五、测试替身：让测试快而独立的代价

要让上面那些测试跑得快、结果稳，就不能每次都真去调第三方支付、真去发短信——外部依赖慢、不稳、有副作用还可能收费。测试替身就是顶替它们的假货，原书沿用 Gerard Meszaros 的分类：dummy（纯占位）、fake（能跑的简化实现，如内存数据库）、stub（对预设调用返回预设答案）、mock（在 stub 之上还断言「被调用了几次、参数是什么」）。

代价必须说清楚：mock 用得越多，测试越绑死实现细节——测的变成「代码怎么做的」而非「事情做成没有」，一次正当重构就让上百个测试同时变红，团队很快学会不再重构。原书的平衡点是：替身用来隔离，但必须另留一小撮真打外部系统的测试并定期跑，否则你只证明了「我的假设和我的假货自洽」。术语坑：原书的「集成测试」特指与外部系统对接，与今天常说的「集成测试＝跨模块测试」不是一回事。

六、三种起点：从哪开始补

原书不给放之四海的清单，而是按项目状态给策略（详见下节表 3）。最该记住的是遗留系统那条路径：Feathers 的定义是「没有测试的代码就是遗留代码」，所以顺序应是——先把构建与部署自动化（第 2 章），再给即将改动的那一小块写表征测试（characterization test：把它现有的行为原样记录成测试，不管这行为对不对），然后才动手改。这里全局覆盖率是个陷阱：覆盖率是诊断信号，不是目标——一份 100% 覆盖却几乎不带断言的测试套件完全可能存在。

七、把四类测试排进流水线

四象限最终要落到时间轴上：越靠前的关卡越快、越便宜、越该挡住大多数缺陷；越靠后的环境越像生产、覆盖越全、反馈越慢。

关键权衡与选型

表 1 · 四象限速查：各象限的定位、自动化命运与「不做会怎样」

表 2 · 三层自动化测试的经济学：为什么形状必须是金字塔

为什么不能倒过来？一个简单算术：200 个端到端测试、每个有 0.5% 概率随机失败，整套一次全绿的概率只剩 0.995²⁰⁰ ≈ 37%——三次里有两次会红，且多半不是真 bug。红灯一旦常态化，第 3 章那条「红了全队停线」的纪律当场作废。这就是「冰淇淋甜筒」反模式的致命处：它不是慢一点，是让整套测试失去可信度。

表 3 · 三种起点：先补什么、别做什么

表 4 · 依赖怎么处理：四种替身与真实依赖

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

这一章是部署流水线的装料清单：第 5 章给关卡骨架，本章决定每一关里放什么。面试里问「你们的测试策略是什么」，好答案不是报覆盖率数字，而是本章这几条：各层测试的比例与耗时、验收测试由谁在什么时候写、片状测试怎么治、遗留模块怎么起步。

易错点与争议

• 把「测试策略」等同于「覆盖率目标」。覆盖率只说明代码被执行过，不说明它被验证过——一份没有断言的测试套件可以轻松跑到 100%。本章讲的是分类与分工，不是一个数字。
• 冰淇淋甜筒。顶上一大坨手工回归与端到端测试、底下几乎没有单元测试。它的死法不是慢，而是片状失败让整套测试失去可信度（见上面那个 37% 的算术），最终全队学会无视红灯。
• 过度 mock。把每个协作者都 mock 掉，测试就成了实现的镜像：重构一次红一百个，于是没人再重构——测试反而成了变更的阻力。判据很简单：它断言的是「做成了什么」还是「怎么做的」？
• 以为自动化能取代探索性测试。不少团队自动化之后顺手裁掉这一环，等于把「发现未知问题」的能力一起裁了。
• 验收测试的维护成本被系统性低估。写起来一天，环境和数据养起来一年——这才是多数团队放弃它的真实原因。
• 时代局限与后续发展。2010 年成书，书里没有：契约测试（consumer-driven contract，如 2013 年起的 Pact）——用「双方各自跑的一份契约」替掉大量脆弱的跨服务端到端测试；没有片状测试的系统性治理（识别、隔离、限期修复）；也没有「右移」思路——用金丝雀发布与可观测性把一部分验证挪到生产，本质上承认「上线前测不完」。比例之争至今无定论：金字塔、蜂巢、前端圈的「测试奖杯」各有拥趸，通用的只有分层与「越靠前越便宜」。

要点