3.4 集成测试的挑战与解药
本节摘要：集成测试三座大山——慢、脆、贵。本节不以口号搪塞，逐条给出可操作的解药：分档调度、契约测试替换真网络、环境与数据收紧、容器并行。目标是让"慢脆贵"从拦路虎变成可管理的一次性成本。
三座大山从哪来
集成测试披着"真依赖"的光环，也背着同样的代价：真库、真网络、真进程把等待拉长；外部服务环境抖动让结果飘忽；环境、数据、依赖的维护把一个团队拖入运维泥潭。这三样叠加，很多项目就干脆退回到"手工联调"——那才是更贵的方案。解药不是干掉集成测试，而是把它的成本押到可控的频次和范围上。
山一：慢。解药是分档调度
集成测试没必要每条都在每次提交里跑。按速度分档：
- 快档（秒级）：纯内存库 + 高保真替身，进每次 PR 必跑。
- 慢档（分钟级）：容器里的真实实现，跑在深夜或合并前。
- 冒烟档（关键路径）：每环境只留几条全链路主流程，挡大事故。
分档没有消灭慢，但让慢的那批不再卡住每个人的每次提交，从而换回开发者的耐心和敏感度。
山二：脆。解药是契约测试 + 收紧环境
环境的闪红，多半来自外部服务的不可控。两个抓手：
一是用契约测试把"外部服务的接口约定"提前固化。以一对消费者与提供者为对象，分别验证"我的请求格式"和"你的响应承诺"。这样外部服务再改，往往在契约层就亮了红灯，而不是到集成用例里莫名红一次。二是环境收紧：给测试库做专属隔离、固定依赖版本（锁定镜像 tag）、把容易抖的外部调用包一层超时重试的稳定门面。
山三：贵。解药是容器并行与范围收紧
贵主要贵在两处：环境搭建的运维投入，与跑一轮的时间成本。容器技术让环境按需拉起、用完即弃，省掉了手工搭环境这一大块运维费；再配合测试并行（同角色测试分桶同时跑），把时间成本摊平。范围上收紧：只对"单测覆盖不到、又确有高风险"的接缝写集成用例，别把集成层当成回锅单测的垃圾桶。
一个真实排错路径：当闪红找上门
背景：夜间集成套件里一个用例连续三晚第一遍红、重跑就绿。
操作：先做二分定位——把用例里的网络调用换成稳定替身，若立刻绿，说明脆源于外部服务；再查锁定版本的镜像 tag 是否被别人升级过。
结果：发现外部服务发了新版本，升级后行为变了，用例的断言还是旧口径。通过契约测试 + 锁版本提前规避了这一类回归。
解读：先分诊"是自己的锅还是依赖的锅"，再对症下药，比盲目加超时重试更有效。变式：把这类外部依赖统一收进契约层，让接口变更在最前端就扬红灯。
一份能照着抄的闪红排查手顺
闪红次数多了，最怕的是每次都在现场重新推理。与其这样，不如把"如何对待一条闪红"沉淀成一份固定手顺，让团队照着走，减少情绪化决策。手顺大致四步：
- 复现：在本地把用例原样重跑一遍，这一步通常能筛掉七成的环境偶然。
- 分锅：把被测代码接缝里的外部依赖逐个用替身替换，看红还在不在——在，锅就大概率在自己代码；不在，锅在外围依赖。
- 查版本与锁定：确认涉及的镜像 tag、依赖版本、schema 版本是否与用例断言一致，排除"版本漂移型误红"。
- 判顽疾：若三步都查不出，就把这条用例标记为"待观察"，而不是默默 retry 过去——连续三晚以上的闪红，一定有深层根因，靠重试掩盖只会让红灯失信。
这份手顺的落点不在"每次都能秒杀"，而在"让团队不必每次从零开始推理"。闪红不是不速之客，而是可以被编号、被分流、被处置的常规流程。
策略的弹性：别把解药用成本轴刹车
讲完三山的解药，还要补一句纪律：三山的解药都引入了"成本轴"——分档、锁版本、容器都要花功夫维护。于是很容易出现反效果：为了省维护费力，干脆把集成用例越砍越少，砍到最后只剩三条冒烟，名为"控制成本"，实则是把贵而慢的验证重新压回手工联调。判断是否砍过了头，就看那条著名的衡量尺：这个测试集有没有在"单测全绿"的时候抓住过真实接缝缺陷？如果已经很久没抓到过，要么是系统稳定了，要么是它该抓的早被契约测试接走了，后两者都应当被记录而不是被悄悄放任。
所以每隔一段时间，值得主动做一次"集成测试价值审计"：把过去一个季度的红灯记录翻出来，按"自己代码 / 依赖变更 / 环境噪声 / 误红"四类归账。哪类占比高，就把资源往哪类对应的解药倾斜——这比无差别地加用例或砍用例都更有据可依。
一张"要不要写这条集成用例"的判断卡
解药讲得再多，落到每个新增用例，团队还是需要个快判。给一张能贴在会议桌上的判断卡，三个问题，都答"是"才写：
- 这段接缝单测拦不拦得住？（单测能拦就回单测，别往集成层堆）
- 它有没有值得守护的真实风险？（没风险就别为仪式感造一条贵的）
- 当前基础设施跑得起这条吗？（跑不起，先解决环境和数据，再谈用例）
三个问号答下来，该写的一条不会漏，不该写的一条也大概率挡在外面。这张卡的价值在于把"要不要写"从嗓门之争变成一次冷静的三问，尤其是在排期紧张、大家倾向"能砍就砍"的时候，它反而帮剂量之下的理性决策踩住刹车或按下油门，都比随手一拍要稳。
每个季度回头用这张卡把存量集成用例过一遍，也是一次低成本的价值审计——淘汰掉已经不符合三问的旧例，别让它们继续拖慢轮次、占用环境。卡不会永远定案，但它给了"新增"和"退役"同一个客观标尺。
别让"解药"本身活成新的挑战
最后一个小小的提醒：三座大山的解药都打着"治理"的旗号，反而容易被做过头，变成第四座山——"解药恐惧"：为了规避环境脆，干脆把外部依赖全部换成本地内存假实现，跑了十几年绿，美其名曰"更快更稳"，实则已经退化成了一段用真实假想世界的穷凑合。要识别这种"矫枉过正"，就看回那条底线：你还在用真依赖验证真实接缝吗？若答案几乎变成"全靠替身"，那它名义上是集成测试，实质已跌回单元层，甚至跌回没有测试。解药是拿来用的，不是拿来把"真"也一并优化掉的。
本节要点回顾
- 三座大山：慢、脆、贵，都有对应可操作解药。
- 慢→分档：快档进 PR、慢档进夜间、冒烟档兼备。
- 脆→契约+隔离：契约测试固化约定，锁版本、专属环境。
- 贵→容器+并行+收范围：按需拉起、并行摊时间、只留高风险缝。
- 终局计价法：集成层的价值以"拦住单测拦不住的真实缺陷"来计。