非功能需求测试

一句话

你以为性能测试是上线前的一场彩排；第 9 章说它该是流水线里一个会亮红灯的阶段。核心命题：把容量、性能、安全这些「-ility」从形容词变成带阈值、可自动判定的验收条件，复用已有的验收测试脚本把它们做成一道关卡。作者甚至反对「非功能需求」这个名字——它们不是可选的边角料，而是横切所有功能的跨职能需求（cross-functional requirements）。

Glossary · 术语表

坐标

本章属 Part II「部署流水线」，位置在 Ch8「自动化验收测试」之后、Ch10「部署与发布」之前：Ch8 教你把「功能对不对」自动化，本章教你把「够不够快、扛不扛得住、安不安全」自动化，用的还是同一批脚本。 它上承 Ch4「测试策略」里那个象限——面向技术、用于评价产品的测试；对应现实里的问题是：流水线上那个被所有人跳过的「性能测试阶段」，为什么总是形同虚设。

这章要解决什么

这类需求有两种死法，方向相反。

一种是不测。 需求写成「系统要快」「要支撑大量用户」——没有数字就没有判据，于是它永远排在功能后面，最后由真实用户来测。另一种是过度工程：为想象中的一百倍流量提前上分库分表、上消息队列、上缓存三层，用交付速度换一个从未到来的峰值。书的立场是中间那条：跨职能需求要在立项阶段就和功能需求一起分析、排优先级、写进待办清单，然后用测试把它钉住。

不解决的代价是发现得太晚。举个有量级的例子：一个 2000 万注册、日活 200 万的电商，人均每日 30 次请求 ≈ 700 QPS 均值，大促峰值按 8 倍算 ≈ 5600 QPS。上线后压不住，一查是商品页每次渲染触发 41 次数据库查询（一次列表 + 40 次逐条取详情）。这不是「调个参数」能解决的——它是数据访问方式的问题，而数据访问方式往往在第一周就定型了。容量问题几乎总是架构问题，越晚发现，改动半径越大。

核心内容，讲透

① 先把要求写成能判对错的一句话

本章最实操的一条：每个跨职能需求都要落成「场景 + 度量 + 阈值」三件套。「系统要快」写成：在 1000 并发用户、商品库 500 万条的条件下，下单接口 p95 < 800ms、错误率 < 0.1%，持续 60 分钟。 三个要素缺一不可——没有场景，数字无意义；没有阈值，机器判不了红绿。

这里有个容易被跳过的判据：阈值必须来自业务，不是来自「上次测出来是多少」。否则它会随系统一起退化——每次超了就把阈值往上抬，关卡就变成了橡皮图章。

② 容量、吞吐量、响应时间：三个被混用的词

这是本章最值钱的一页概念。三者不是同义词，关系藏在一条曲线里：随着并发上升，吞吐量先近似线性增长，到某个点后被资源（CPU、连接池、锁）顶住而走平，再往上甚至回落；而响应时间在同一个点开始陡峭上翘。 容量就定义在这个拐点上——在响应时间仍不越线的前提下能吃下的最大吞吐量。

为什么这个区分要紧：饱和区之后，你多发的请求不会变成吞吐，只会变成排队。 一个已经在拐点右侧的系统，表面看 CPU 打满、吞吐还在、其实每个用户都在等——这正是「服务没挂但没人用得了」的成因。

③ 容量问题从哪里来

书把源头指向代码与架构里的几类常见做法，每一类都值得当成 review 时的检查项：

• 话太多的远程调用（chatty remoting）：把本地对象的用法搬到网络上。量级感：进程内一次方法调用约几纳秒，同机房一次 RPC 约 0.5–1ms，跨大洲一个来回约 150ms——差了六个数量级，循环里藏一次远程调用就是灾难。
• 数据库往返：上面那个 41 次查询就是典型的 N+1。一页 50 条、每次 0.5ms，纯等待就 25ms，还没算连接池排队。
• 锁与串行化：吞吐曲线走平的物理原因经常就是一把全局锁——加机器完全不管用。
• 会话状态：把用户状态留在应用服务器内存里，既涨内存又逼你做黏性会话，横向扩容直接失效。
• 对象分配与垃圾回收：高分配率会把停顿打到响应时间的尾部；平均值看不出来，p99 一看一个准。

④ 容量测试怎么造：复用验收测试，录在服务层

本章最省力的一招：别为压测另写一套脚本，把 Ch8 的验收测试拿来放大。 验收测试已经表达了「一个真实用户会怎么用系统」，压测需要的只是「同时来一万个」。

但有个关键限定：录制要录在服务 / API 层，不要录在 UI 层。 原因有二——UI 脚本一改按钮就碎，维护成本吃掉整个收益；而且浏览器本身很重，用 UI 驱动压测，你的注入器先扛不住。这条今天仍然成立，只是名字变了：我们叫它「协议级压测」。

⑤ 测试环境的失真：这一章最容易被略过、也最该记住的一节

书承认现实：很少有团队养得起一套和生产完全同构的压测环境。 但它同时警告，缩比环境的数字不能线性外推。失真来自几处，每一处都会往「过于乐观」的方向偏：

• 数据量：10 万行的表几乎全在内存里，10 亿行要真去翻索引——B-tree 多一两层，每次查询多一两次磁盘往返。
• 缓存命中率：小数据集下命中率接近 100%，生产上可能只有 80%，那 20% 的穿透打到数据库上就是数倍放大。
• 拓扑与网络：单机上的「调用」在生产里是跨机架、跨可用区的一个来回。
• 共享资源：测试环境里你独占数据库，生产上它同时被十几个服务和一堆批作业分食。
• 第三方用桩：桩总是毫秒级返回、从不超时——而真实依赖抖动正是生产事故的常见起点。

务实的结论：缩比环境是「回归检测器」，不是「容量预测器」。它擅长回答「这次比上次慢了吗」，不擅长回答「我们能扛多少 QPS」。后一个问题只有同构环境或生产本身答得了。

⑥ 安全也是一种跨职能需求

本章把安全和容量并列，理由一致：都是不写成自动化关卡就会被无限期推迟的东西。 落到流水线上是三件可自动化的事——静态分析（每次提交就跑，扫 SQL 注入、硬编码密钥这类模式）、依赖扫描（查已知漏洞的库版本）、渗透测试（人工为主、周期性做）。判据和容量测试一样：能给出明确红绿的，放进流水线；只能给出报告的，别假装它是关卡。

关键权衡与选型

第一个选择：拿什么环境测。这决定了你的数字能承诺什么。

书写于 2010 年，默认第二行；第三行当时被视为不可接受，今天反而是大厂主流——见下一节。

第二个选择：用什么驱动负载。

第三个选择：测哪一种——四类测试抓的是不同的 bug，别混为一谈：负载测试问「预期峰值下达标吗」；压力测试问「超载后在哪崩、是优雅降级还是雪崩」；浸泡测试（跑 8–24 小时）抓内存泄漏、连接泄漏、日志撑爆磁盘；尖峰测试抓冷缓存和自动扩容的滞后。只跑第一种是最常见的偷懒——而真正打垮系统的通常是后三种。

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

这一章的主张今天已经成了默认配置，只是换了词：我们说 SLO 而不说「阈值」，说「性能测试即代码」而不说「复用验收测试」，说「协议级压测」而不说「录在服务层」。本章点名的 JMeter 至今仍在 Apache 基金会维护，而它的继任者们把「进流水线」这件事直接写进了产品定位。

另一条值得记住的实证是指标口径：Amazon 在 Dynamo 论文（SOSP 2007）中明确主张内部服务的 SLA 按 p99.9 而非平均值来定——因为平均值会把最慢的那批用户（往往正是买得最多、数据最多的那批）整个藏起来。

易错点与争议

• 用平均响应时间当阈值。 平均 200ms 完全可能对应着 5% 的用户等了 3 秒。阈值要用 p95 / p99，并同时看错误率——只看时间，会把「快速失败」当成性能优异。
• 把缩比环境的数字乘一乘就当容量。 前面五种失真全都朝乐观方向偏，乘法的误差通常不是 20%，而是好几倍。
• 把容量测试塞进提交阶段。 一轮动辄几十分钟，会直接撞破 Ch7 给提交阶段定的十分钟预算，最终的结果是所有人开始跳过它。它应当是验收测试之后一个独立、可按需或定时触发的阶段。
• 「压测通过 = 上线安全」。 压测用的负载形状来自历史；真正击垮系统的往往是没被建模的形状——重试风暴、缓存集体失效、上游超时后的同时重连。这是本章方法的固有边界，不是执行不力。
• 时代局限。 2010 年的默认前提是固定容量的机房，所以「容量」是个物理数字。云弹性把它变成了成本问题，但没有取消它：自动扩容有几十秒到几分钟的滞后，有状态的数据层更是扩不动——尖峰测试因此比当年更重要。
• 被后来者推翻的一条。 本章默认「压测必须在类生产环境做」，隐含「不能在生产上做」。十年后的主流实践恰恰相反：把故障和负载注入生产、在真实条件下验证，成了成熟团队的标配。本章的方法没错，但它的适用边界比作者想象的窄。

要点