1.1 为什么要装测试灯：测试的层次与目的

本节摘要：测试不是"写几个断言"，而是按软件结构分层的红绿灯体系——单元、集成、系统三层各管一段风险，越底层越便宜越该装得多。本节给出分层目的的坐标，为理解单元与集成测试的边界铺好第一块地板。

一个红灯值多少钱

先讲一个不算罕见的下午。某团队改了订单模块一个"金额四舍五入"的函数，同事 A 记得付款模块也用到它，同事 B 拍胸脯说没问题。合进主干一周后，线上六千多笔订单金额被多算了三分钱。之所以拖了一周才发现，是因为没有任何一层测试会在改完那个函数时自动把红灯亮起来——那支团队把所有验证都压在最后的端到端人工回归上，而人工回归根本不会覆盖"四舍五入和支付侧"这个交叉点。

这个案例想说明一件朴素的事：红灯亮得越晚，账单越贵。理论上越早发现问题，修复成本几乎指数下降。可在工程现实里，"早"不是靠喊口号实现的，而是靠把灯装在合适的位置——离改动发生的地方足够近。

软件不是一块铁板，测试要分层

一段线上代码从"改一行"到"用户看到"，中间隔着好几道关卡。我们按风险把它们分层，每一层配一盏或几盏灯：

• 单元层：针对函数、方法、类这类最小可测试零件。改动发生在这里，所以这里的灯能在你保存文件的瞬间就验一次。
• 集成层：针对零件之间的接缝——接口、数据库读写、进程间通信。零件各自没问题，接缝处才是事故高发地带。
• 系统层（含端到端）：针对完整业务流程在真实或接近真实环境里的走通。最接近用户视角，也最贵、最慢。

这三层不是割裂的三个文件夹，而是同一条"业务风险"从细到粗的三个观测尺度。改动往往先在单元层翻船，单元灯亮得快；漏过去了，集成灯再拦一程；还漏，系统灯做最后兜底。层越往下，灯火越便宜，也因此我们愿意装得越多。

下面这张图把三层的目的是什么、各拦哪类故障放大了看。

分层的目的不止"分类"

分层测试真正的作用，是把"质量责任"分解到一个人一天能负担的粒度上。单元层让你每敲个函数都有一张安全网，集成层让两个人同时改相邻模块时不至于互踩，系统层让发版前的最后防线不至于裸奔。这不是理论洁癖，而是一笔朴素的账：把贵而慢的验证留给少而关键的场景，把廉而快的验证铺满日常，整体诊断能力反而更强。

💡 一条可带走的判据：判断一段代码改完该测在哪层，就反问"它离外部世界（磁盘、网络、时钟、进程）有多近"。贴着这些的就是要往集成层放，纯内存里算的就是单元层。这条判据在第 4 章会反复用。

测试的四个目的，别只盯一个

很多人把"测试"等同于"证明能跑"，其实测试至少有四个目的，优先级各不相同。第一是回归防护——防止改坏已经好的东西，这是最高频的价值。第二是行为规约——把"这函数该干什么"写成一串能自动验证的契约，当文档用。第三是设计反馈——写测试的过程中暴露耦合，倒逼重构。第四才是传统意义上"找 bug"的初验。一支成熟团队里，前两个目的撑起大部分工作，第三个是副产品，第四个反而相对少——因为多数逻辑层的 bug 早被前两个拦掉了。

四个目的有个共同前提：灯要会自动亮。这就是为什么我们总强调自动化——人工点一遍灯既不快也不可重复，等于没装。

一次"到底该怨谁"的分诊

把上面四层放到一次真实事故里看会格外清楚。背景：某订单模块把"商品缺货但已下单"自动标记为主线，同事在小版本里改了库存判断，没跑单元测试直接合上。上线后一批订单在"到货通知"时误发"缺货取消"。

操作：先跑单元层——库存判断那条纯逻辑的测试立刻红了，因为接口入参从"库存数"变成了"货架上可售数"，调用的模块还在按旧口径传。这个红灯同时在报"初验"（新口径没验证）和"回归防护"（旧行为被改坏）。

结果：因为测试把问题定位到"库存判断与下游传参口径不一致"，而非整段全链路黑盒，五分钟就锁定了那一行改动。

解读：灯的价值正在于它分层——把"改错了哪一段"从"整个功能坏了"里剥出来。变式：若团队只有端到端冒烟，这个 bug 可能要到真实下单才能被发现，修复成本翻几倍。

分层测试的一条"坏账规律"

实践中还有一种规律值得留意：测试层的迁移成本会随时间复利。开始只靠手工验，积累几年后，补底层测试要从零理解一堆没人维护的老逻辑，成本高到让人放弃；反过来，从一开始就按金字塔铺底层，边改边补，成本永远被摊平在每次改动里。这就是为什么"等有时间再补测试"往往是伪命题——时间永远不来，债却越滚越利。这也是后面各章反复强调"随改动补测""接进 CI 自动拦"的底层原因：把质量成本分摊到日常，而不是攒成一次可怕的大额账单。

一套灯该怎么起步装

务实的话说在前面：谁也不会一夜之间把三层灯全点亮，那是理想终态。起步的次序可以这样走。第一周只挑"跑得最勤、改得最苦"的那一小片纯逻辑，画最小闭环——一个函数、一条断言、一条红线，务必让它三秒内能验。第二周把"回归防护"里最高频的十条手工检查固化成用例，从此不必每次发版前都人肉点一遍。到了第三、四周，再考虑在接缝和端到端冒烟各留一把少而关键的灯。

之所以强调从最小闭环起步，是因为灯这东西有个"装了就散"的诱惑：一次性铺一大堆用例却没人真正常跑它们，等于只有绿灯、没有守灯人。与其这样，不如先装几盏每天都真能被触发的灯，让"改动经过必然闪红"变成肌肉记忆，再慢慢加厚。唯一要警惕的是过度设计——为了一句"打印日志"也硬塞一个断言，那不叫质量，那叫数字游戏。

有人会问："那我这阶段到底先押单元层还是先押端到端？"答案看你现在最疼的坑在哪。若每天被"改完不知道坏没坏"折磨，就押靠近改动处的单元层，反馈最省钱；若三不五时上线才发现整条链断了，就先押一条能走通主流程的端到端冒烟，先止血要紧。优先级永远跟随当前最大的失血点，而不是跟随金字塔的形状。

本节要点回顾

• 分层即风险分层：单元、集成、系统三层各管一段，越底层越便宜越该装得多。
• 合同期位：灯亮得越晚，修复越贵；把灯装在离改动近的层值回票价。
• 四个目的：回归防护、行为规约、设计反馈、初验，别只盯"证明能跑"。
• 判据先行：先问"被测代码离外部世界多近"，再看该放哪层。
• 自动化是前提：不能自动亮的灯等于摆设。