想象你是一个积木城堡的总质检员。每一块积木单独检测都完美无缺，可孩子把城堡搭起来不到三分钟，塔尖就“哐当”一声掉下来了。问题出在哪里？不是某块积木有裂纹，而是两块积木之间的凹槽与凸起没有对齐——接口的尺寸、朝向、咬合力全都不匹配。软件世界也一样：每个模块都有自己的单元测试，都绿得发亮，可当用户服务把 user_id 传给订单服务时，一个给字符串、一个要整数，系统当场崩溃。集成测试，就是那个专门蹲在模块接缝处抓妖怪的质检员：它不管单个零件好不好，只管零件之间的接口是否一致、数据是否传得对、状态是否协同。怎么抓妖怪也有讲究：从城堡尖往下验还是从地基往上验、要不要请“替身积木”帮忙、测试数据要不要单独备一份、服务之间要不要提前签“接口合同”……这些正是集成测试实践的完整地图。准备好了吗？我们一起把积木城堡搭稳。

岗位关联

学会集成测试，你就成了团队里“确保系统真正连起来能转”的那个人——无论做 AI 模型服务对接、微服务拆分还是 CI 流水线建设，它都能把交付风险扼杀在代码合入之前。

目录
  1. 可视化演示
  2. 集成测试概览
  3. 测试策略选择
  4. 测试替身运用
  5. 数据与环境
  6. 契约测试实战
  7. 微服务集成
  8. CI 集成自动化
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示自顶向下、自底向上与三明治集成测试策略的模块集成顺序，动态演示Stub桩模块与Driver驱动模块的使用，交互切换策略观察差异。

本节配有交互动效（进入视口后自动加载，约 3KB）。

集成测试策略：模块协作验证 青色为当前集成模块（正在测试） 绿色为已测试模块（集成完成） 橙色为Stub桩模块（临时替代） TopDown: API->Svc->DAO (Stub replaces lower) 自顶向下策略从主控模块开始，使用Stub临时替代未开发下层模块，优先验证核心控制流程

集成测试概览

小时候搭积木城堡，每块积木孤零零看都完好无损，可拼起来塔尖总往下掉。反复检查才发现，两块积木的凹槽和凸起根本没对齐。软件世界也一样：每个模块单测全绿，一凑到一起就报错。问题不在某个模块内部，而藏在模块之间的“接缝”里——这就是集成测试要抓的妖怪。

如果把单元测试比作“检查每一块积木是否完整”，那集成测试就是“把两块积木拼起来，检查咬合是否严丝合缝、传力是否顺畅”。它处于单元测试和端到端测试之间：单元测试只管单个函数和类的内部逻辑，端到端测试模拟真实用户走完整流程，而集成测试专注于模块与模块之间的接口一致性、数据传递和状态协作。

一个典型场景：用户服务返回用户信息，订单服务调用它取 user_id。两边各自单测都过，但用户服务返回的是字符串 "123"，订单服务却期待整数 123。集成测试会真实创建两个服务实例，让订单服务发起真正的调用，从而暴露类型不匹配、字段缺失、状态不同步等问题。实践中常用“模块对”维度度量覆盖程度：

城堡不会因为某块积木漂亮就屹立不倒，关键是每一条接缝都经得起推敲。集成测试覆盖率就是接缝质检清单——清单越完整，倒塔的风险越小；每修好一条接缝，就离一座牢靠的城堡更近一步。

集成覆盖率=∣Etested∣∣Eall∣\text{集成覆盖率} = \frac{|E_{\text{tested}}|}{|E_{\text{all}}|}
  1. 连接集合 $E_{\text{all}}$系统中全部模块间连接（接口调用、消息传递）的集合，相当于城堡所有“待质检的接缝”。
    Eall={e1,e2,…,em}E_{\text{all}} = \{e_1, e_2, \dots, e_m\}
  2. 已验证连接 $E_{\text{tested}}$已通过集成测试验证过的连接子集，是质检清单上画了勾的那部分接缝。
    Etested⊆EallE_{\text{tested}} \subseteq E_{\text{all}}
  3. 基数符号 $|\cdot|$统计一个集合中元素的数量，即“有几条接缝”。
    ∣Etested∣=∑e∈Etested1|E_{\text{tested}}| = \sum_{e \in E_{\text{tested}}} 1
  4. 覆盖率比值已验证接缝数除以全部接缝数，比值越高，城堡倒塔风险越低。
    ∣Etested∣∣Eall∣=已验证接缝数全部接缝数\frac{|E_{\text{tested}}|}{|E_{\text{all}}|} = \frac{\text{已验证接缝数}}{\text{全部接缝数}}

测试策略选择

搭一座金字塔城堡，你可以从塔尖往下搭，也可以先垒地基再往上，还可以从中间某一层放手、上下同时开工。三种搭法各有各的麻烦和优势，集成测试的策略选择也如出一辙。

自顶向下：先集成最上层控制模块，通过“桩件”代替尚未实现的底层模块。好处是主流程骨架最早成型，能尽早看到用户入口的集成效果；缺点是底层细节被隐藏，深层问题发现得晚，而且桩件数量大。自底向上恰好相反：先无桩集成叶子模块再向上，底层行为验证充分，但顶层控制流到很晚才被验证，需要“驱动器”来主动调用底层。

三明治策略取中庸之道：以中间层（通常是业务逻辑层）为锚点，向上用桩件、向下用驱动器，上下同时集成。它在替身数量和验证深度之间取得平衡，但对数据设计与环境编排要求更高。选型没有绝对最优，要结合依赖方向、模块稳定性和关键风险点：

搭金字塔时人们常说“看地基稳不稳”，但也有人担心“塔尖歪了最后才发现”。没有完美策略，只有与团队节奏、模块成熟度匹配的取舍——这正是集成测试策略的微妙之处。

Ctotal=∑i=1n(Cdouble(mi)+Clink(mi))C_{\text{total}} = \sum_{i=1}^{n} \big( C_{\text{double}}(m_i) + C_{\text{link}}(m_i) \big)
  1. 模块 $m_i$第 $i$ 个待集成模块，对应城堡上的一块待拼接积木。
    mi∈{m1,m2,…,mn}m_i \in \{m_1, m_2, \dots, m_n\}
  2. 替身成本 $C_{\text{double}}(m_i)$为它准备测试替身（桩件或驱动器）付出的成本，请替身演员总要付片酬。
    Cdouble(mi)=桩/驱动器的实现与维护成本C_{\text{double}}(m_i) = \text{桩/驱动器的实现与维护成本}
  3. 连接成本 $C_{\text{link}}(m_i)$真实连接相邻模块、验证接口所花费的成本，是把两块积木真正按在一起的力量。
    Clink(mi)=环境搭建+数据准备+执行验证C_{\text{link}}(m_i) = \text{环境搭建} + \text{数据准备} + \text{执行验证}
  4. 求和 $C_{\text{total}}$对 $n$ 个模块求和得到该策略的总成本，选择总成本低且关键风险可控的方案。
    Ctotal=Cdouble(m1)+Clink(m1)+⋯+Cdouble(mn)+Clink(mn)C_{\text{total}} = C_{\text{double}}(m_1) + C_{\text{link}}(m_1) + \dots + C_{\text{double}}(m_n) + C_{\text{link}}(m_n)

测试替身运用

拍电影时主角档期冲突，剧组会请替身演员走位，等主角本人到场再拍特写。集成测试里也有“替身演员”——当某个依赖模块还没开发完成，或者测试环境里不好部署真实依赖时，我们就让一个测试替身顶上去。

最常见的替身有三种。桩对象（Stub）像“只念台词的替身”——被调用时返回预设数据，不关心过程；模拟对象（Mock）像“带了场记本的替身”——不仅顶班，还记录是否被正确调用、传参是否正确；伪对象（Fake）则是一个轻量但真实的实现，比如用内存数据库代替正式数据库，行为可信、成本却低很多。

选择替身的核心原则是“够用就好”：验证数据返回用 Stub，验证交互顺序用 Mock，需要真实行为但不想部署重型依赖时用 Fake。替身逼真度越高越接近真实，但实现和维护成本也越高：

替身终究是替身，主角不在场时可以救场，但杀青前必须让真实演员走一遍镜头。集成测试同理：替身用于加速和隔离，最终要在预发布环境里用真实依赖做一次完整的集成验证。

Fdouble=∣Bmatch∣∣Ball∣∈[0,1]F_{\text{double}} = \frac{|B_{\text{match}}|}{|B_{\text{all}}|} \in [0, 1]
  1. 全部场景 $B_{\text{all}}$真实模块被调用时可能涉及的全部行为场景集合。
    Ball={正常返回,参数异常,超时,返回空值,… }B_{\text{all}} = \{\text{正常返回}, \text{参数异常}, \text{超时}, \text{返回空值}, \dots\}
  2. 匹配场景 $B_{\text{match}}$替身能正确模拟的行为场景子集，是“替身演得像”的部分。
    Bmatch⊆BallB_{\text{match}} \subseteq B_{\text{all}}
  3. 逼真度比值匹配场景数除以全部场景数，得到 0 到 1 之间的逼真度分数。
    Fdouble=∣Bmatch∣∣Ball∣=1 表示完全仿真F_{\text{double}} = \frac{|B_{\text{match}}|}{|B_{\text{all}}|} = 1 \text{ 表示完全仿真}
  4. 权衡区间 $[0,1]$逼真度趋近 1 时替身几乎等于真实模块，但成本也趋近真实模块——性价比往往在中段最佳。

数据与环境

同一道红烧肉，换一口锅、换一批五花肉，味道都可能不一样。测试也一样：同一个集成测试，数据库里多了一条脏数据、环境变量配错了，结果就天差地别。想让测试“可复现”，必须先把数据和环境管好。

数据准备有三板斧：种子数据（每次测试前把数据库重置到固定基线）、数据工厂（在测试中按需构造合法业务数据）、事务回滚（测试结束后回滚写入）。三者结合，测试用例之间就不会互相“踩脚印”。环境管理上最怕“大家共用一个测试库”，正确姿势是每个开发者或每条流水线获得独立数据库或容器环境，配置项与代码一起纳入版本管理，部署时自动注入。

数据泄漏会带来指数级的污染风险，比想象中更可怕：

后厨要保证“每一次端出的菜味道一致”，靠的是统一的备料标准和独立的灶台。测试团队要保证“每一次集成测试结果一致”，靠的同样是标准化的数据和隔离的环境。

Pclean=(1−Lleak)nP_{\text{clean}} = (1 - L_{\text{leak}})^{n}
  1. 泄漏率 $L_{\text{leak}}$单次测试运行时数据泄漏到共享环境的概率，相当于后厨洒了一滴油到隔壁灶台的概率。
    0≤Lleak≤10 \le L_{\text{leak}} \le 1
  2. 运行次数 $n$连续执行的测试用例数量，每次执行都是一次新的“碰运气”。
    n=用例数n = \text{用例数}
  3. 连乘 $(1-L)^{n}$所有 $n$ 次执行都保持环境干净的概率——每次不泄漏才会干净。
    (1−Lleak)n=(1−L)×(1−L)×⋯×(1−L)⏟n 次(1 - L_{\text{leak}})^n = \underbrace{(1-L) \times (1-L) \times \dots \times (1-L)}_{n \text{ 次}}
  4. 指数风险即使单次泄漏率只有 1%，跑 70 个用例后干净概率约 $(0.99)^{70} \approx 0.5$——环境接近一半概率被污染，所以隔离不是可选项而是必选项。

契约测试实战

两家零件厂合作造城堡：A 厂生产塔尖，B 厂生产塔身。双方如果不开会，只凭各自想象，运到工地必然装不上。聪明做法是开工前先签合同：塔尖底部尺寸多少、卡扣方向朝哪。软件里的“合同”就是接口契约。

契约测试专门验证“消费者期望的接口”和“提供者实际提供的接口”是否一致。其中消费者驱动契约（Consumer-Driven Contract，简称 CDC）更进一步：由消费者团队把期望写成契约文件，提供者团队在 CI 中持续运行契约测试来验证自己是否满足——需求方直接把“验收标准”摆出来，提供者不用猜。

契约文件描述请求方法、路径、参数、响应结构，验证时提供者逐条对照。契约测试速度快、隔离性强，尤其适合微服务场景。契约匹配程度可用集合关系精确描述：

有了合同，两家工厂可以各自按节奏生产，不必天天互相等待。契约测试让服务团队“各干各的、按时对账”，把联调期的争吵提前消化在自动化验证里。

Pcompat=∣Cconsumer∩Pprovider∣∣Cconsumer∣P_{\text{compat}} = \frac{|C_{\text{consumer}} \cap P_{\text{provider}}|}{|C_{\text{consumer}}|}
  1. 消费者期望 $C_{\text{consumer}}$消费方期望的全部接口行为集合，是合同上列出的所有承诺。
    Cconsumer={calc_total,discount,get_user,… }C_{\text{consumer}} = \{\text{calc\_total}, \text{discount}, \text{get\_user}, \dots\}
  2. 提供者能力 $P_{\text{provider}}$提供方实际支持的全部接口能力集合，是工厂真正能生产的东西。
    Pprovider={calc_total,discount,get_user,… }P_{\text{provider}} = \{\text{calc\_total}, \text{discount}, \text{get\_user}, \dots\}
  3. 交集 $\cap$既被期望又被支持的行为，也就是合同里的条款真正被兑现的部分。
    Cconsumer∩Pprovider={x∣x∈Cconsumer 且 x∈Pprovider}C_{\text{consumer}} \cap P_{\text{provider}} = \{x \mid x \in C_{\text{consumer}} \text{ 且 } x \in P_{\text{provider}}\}
  4. 兼容度 $P_{\text{compat}}$比值等于 1 时消费者完全满意；小于 1 说明存在未被满足的期望，需要提供者补上能力。

微服务集成

把城堡升级成城堡群：住人塔楼、粮仓塔楼、瞭望塔之间用吊桥连接。单独的塔楼都没问题，但一场大风后吊桥卡住了——塔与塔之间的连接才是薄弱环节。微服务集成测试做的就是检查这些“吊桥”。

微服务的“吊桥”有两种：同步的 HTTP/RPC 调用，和异步的消息队列。集成测试要验证：调用方传参符合被调方期望、返回结果能正确解析、超时与重试机制生效、消息发布和消费顺序正确。依赖越多，桥越多，验证路径越复杂，于是要用依赖图来设计集成范围：节点是服务，边是调用关系。

实践中还有两个高价值手段：链路追踪（一次请求跨多个服务的轨迹一目了然，定位集成问题快很多）和故障注入（故意让某个下游返回 500 或超时，验证上游降级逻辑）。依赖复杂度可以量化：

城堡群要成为真正的联防体系，每一座吊桥都得在大风天经得起考验。微服务集成测试正是那场“人工大风”——把故障和异常提前吹进系统，看看桥到底稳不稳。

Vcyc=∣E∣−∣V∣+1V_{\text{cyc}} = |E| - |V| + 1
  1. 节点集合 $V$依赖图中的服务节点集合，$|V|$ 是服务数量，也就是城堡群里塔楼的个数。
    V={订单服务,推荐服务,用户服务,… }V = \{\text{订单服务}, \text{推荐服务}, \text{用户服务}, \dots\}
  2. 边集合 $E$服务间的调用关系集合，$|E|$ 是调用边数量，也就是吊桥的数量。
    E={(订单→用户),(推荐→订单),… }E = \{(\text{订单}\to\text{用户}), (\text{推荐}\to\text{订单}), \dots\}
  3. 回路数计算$|E| - |V| + 1$ 是依赖图中的“回路数”，即循环依赖的环路数量。
    Vcyc=∣E∣−∣V∣+1=环的个数V_{\text{cyc}} = |E| - |V| + 1 = \text{环的个数}
  4. 环检测意义结果大于 0 说明存在环，环上的服务互相依赖，集成测试要优先覆盖这些链路——环是吊桥中最容易“堵车”的位置。

CI 集成自动化

城堡工厂里最怕的场面是：工人各自埋头干，临到交付日才把零件堆到广场上拼装，结果一拼就散架。持续集成（CI）的思路恰恰相反：每一次代码提交都自动触发拼装——跑编译、跑单元测试、跑集成测试，出了问题当场亮红灯。

集成测试在 CI 流水线里的位置很有讲究：它通常排在编译和单元测试之后、端到端测试和部署之前。流水线分成多个阶段，集成测试是其中最重要的“质量关卡”：代码没有通过集成测试，就不允许合入主干，也不允许进入下一步构建。为了让关卡不拖慢节奏，实践中要并行执行测试（按模块或服务拆分到多台机器）、控制测试粒度（能契约测试就不起真实服务）、建立失败阈值（关键链路失败即阻断）。

反馈时间直接决定迭代速度，是 CI 设计中最需要盯紧的数字：

自动装配车间里，传送带不停转，质检工位红灯一亮就停住整条线。CI 里的集成测试就是那个质检工位——它也许增加了每次提交的等待，但换来的是城堡永远可以随时交付的底气。

Tfeedback=Tbuild+Ttest+TreportT_{\text{feedback}} = T_{\text{build}} + T_{\text{test}} + T_{\text{report}}
  1. 构建时间 $T_{\text{build}}$从提交代码到构建出可测产物所需时间，相当于把散落零件转运到装配线上的时间。
    Tbuild=编译+打包+产物上传T_{\text{build}} = \text{编译} + \text{打包} + \text{产物上传}
  2. 测试时间 $T_{\text{test}}$集成测试用例实际执行时间，是质检工位逐个检查接缝的时长。
    Ttest=用例总数×平均单例耗时并行机器数T_{\text{test}} = \frac{\text{用例总数} \times \text{平均单例耗时}}{\text{并行机器数}}
  3. 报告时间 $T_{\text{report}}$结果汇总、通知到开发者的时间，是质检结果传到工长手里的速度。
    Treport=日志收集+结果聚合+消息推送T_{\text{report}} = \text{日志收集} + \text{结果聚合} + \text{消息推送}
  4. 反馈闭环三项合计就是开发者从提交到得知“过了还是挂了”的总时长，目标是把它从分钟级压缩到秒级——流水线越快，城堡越稳。

AI 应用场景

AI 推理服务接口契约测试

阶段：模型部署与集成（CI/CD）

解决的问题：数据团队训练模型、服务团队开发推理 API，两边独立推进，传统方式等到联调才发现请求与响应的字段结构不一致，返工成本极高。契约测试让消费方先把期望写成契约，提供方在 CI 中持续验证，把“积木接缝”问题消灭在早期。

具体案例：某公司推荐系统有特征服务（提供方）和排序服务（消费方）。排序团队用 Pact 定义特征请求契约，特征服务每次构建都跑契约验证，接口字段从 feature_list 改为 features 当天就被契约测试拦截，避免了上线事故。

AI 数据管道集成验证

阶段：数据工程与特征工程

解决的问题：特征处理模块输出给模型训练组件时，字段名、类型、数量稍有出入就会拖垮训练任务。传统方式靠人工写交接文档，训练时才爆雷。持续集成中加入数据管道集成测试，每次提交自动验证“管道出口”与“训练入口”的一致性。

具体案例：某团队的特征工程流水线输出 Parquet 文件给训练组件，集成测试脚本每次提交时检查列名集合、类型映射和行数范围，之后训练任务启动失败的次数下降了 80%。

微服务高可用故障注入

阶段：服务稳定性保障（SRE）

解决的问题：AI 服务被大量上游调用，某个下游依赖超时或返回异常时，是否会引起雪崩？传统做法等线上故障再复盘，风险太大。集成测试中做故障注入，主动模拟下游失效，验证降级与重试逻辑，相当于“大风天提前吹一吹吊桥”。

具体案例：某云厂商的鉴权服务在集成测试时注入 500 错误和 2 秒超时，发现推荐服务会重复重试 7 次并拖垮线程池。修复后重试次数降为 2 次并加入熔断开关，线上高峰期 P99 延迟下降 40%。

Python 演示

python90 行
"""迷你契约测试演示: 验证消费者与提供者之间的接口契约 运行:    python contract_test_demo.py"""  class Stub:    """测试替身: 桩对象, 返回预设值"""     def __init__(self, name, value):        self.name = name        self.value = value     def call(self, method, args):        print(f"    [Stub] {self.name} 被调用, 返回 {self.value}")        return self.value  class Contract:    """接口契约: 记录消费者对提供者的每条期望"""     def __init__(self, name):        self.name = name        self.expectations = []     def expect(self, method, args, returns):        self.expectations.append((method, args, returns))        return self  class Provider:    """服务提供者: 真实实现与替身注入的门面"""     def __init__(self, name, impl, double=None):        self.name = name        self.impl = impl        self.double = double     def call(self, method, args):        if self.double is not None:            return self.double.call(method, args)        fn = self.impl.get(method)        if fn is None:            raise RuntimeError(f"提供者缺少方法 {method}")        return fn(*args)  def verify_contract(contract, provider):    """逐条校验契约期望, 返回是否全部通过"""    passed = 0    total = len(contract.expectations)    for method, args, expected in contract.expectations:        try:            actual = provider.call(method, args)            ok = (actual == expected)        except Exception as exc:            ok = False            print(f"  [异常] {contract.name}::{method}: {exc}")        if ok:            passed += 1        else:            print(f"  [失败] {method}{args} 期望 {expected} 实际 {actual}")    print(f"契约通过率: {passed}/{total}")    return passed == total  impl = {    "calc_total": lambda *a: sum(a),    "discount": lambda price, rate: price * (1 - rate),} contract = (Contract("价格服务")    .expect("calc_total", (3, 5), 8)    .expect("discount", (100, 0.2), 80)) print("[1] 真实提供者验证")real_provider = Provider("价格服务", impl)verify_contract(contract, real_provider) print("[2] 替身注入 (下游未就绪)")stub_provider = Provider("价格服务", impl, double=Stub("价格桩", 999))verify_contract(contract, stub_provider) print("[3] 提供者实现有缺陷 (接口不兼容)")buggy_provider = Provider("价格服务", {    "calc_total": lambda *a: sum(a) + 1,    "discount": lambda p, r: p * (1 - r),})verify_contract(contract, buggy_provider)
目的：用 60 行代码演示契约测试的核心流程——先由消费者签订契约，再由提供者逐条验证；同时展示替身注入如何让测试提前运转。
  1. self.expectations.append((method, args, returns))把“期望调用”记入契约清单，相当于把合同条款逐条写下来
  2. if self.double is not None:替身注入点：有替身就走替身，不碰真实实现
  3. fn = self.impl.get(method)从提供者的实现字典中查找方法，找不到就抛异常
  4. actual = provider.call(method, args)真正调用提供者，拿到实际返回值
  5. ok = (actual == expected)用“实际返回 == 契约约定”判定一致性，这是验证的核心动作
  6. return passed == total全部通过才返回 True，作为 CI 质量门禁的开关
  7. stub_provider = Provider(..., double=Stub("价格桩", 999))演示替身注入后契约被破坏：替身返回 999，而契约期望 8，立刻被抓住

常见误区

误区“我已经给每个模块写了厚厚的单元测试，再把它们多跑几遍，不就是集成测试了吗？反正都是执行代码、检查结果，没必要额外设计一套东西。”

正解单元测试检查的是“积木本身是否有裂纹”，集成测试检查的是“两块积木的凹槽凸起是否对齐”。把单元测试多跑几遍，等于把同一块积木反复看十几遍，却不曾把它们拼在一起——接口不匹配、状态不同步这类接缝问题，单测再多也暴露不了。两种测试的对象、环境、数据要求都不同，必须分别设计。

为何常见：初学者从单元测试入门，天然觉得“测代码就是测函数”，忽略了模块之间交互这个独立维度，误以为规模变大就能覆盖新问题。

误区“替身能隔离依赖、加快测试，那我把能 Mock 的全 Mock 掉，测试又稳又快，肯定是最佳实践。”

正解替身是拍戏时的站位演员，不是主角本人。全剧组都靠替身走位，最后剪出来的片子没法看——测试同理：Mock 过多等于整条调用链都在演“预设剧本”，没有验证真实集成行为，接口不一致照样漏过去。正确姿态是“隔离不稳定或未就绪的依赖”，对核心链路的真实模块尽量用真实现。

为何常见：Mock 让测试从不稳定变稳定，这种“短期确定性”让人上瘾，容易忽略替身行为与真实行为的偏差才是最大的不确定来源。

误区“测试数据都是假的，测不出真实问题。我把生产库的数据复制一份到测试环境，数据又全又真实，肯定能发现更多 bug。”

正解生产数据里藏着脏值、异常格式、隐私字段和不可复现的时间状态，直接复制会造成三大问题：隐私合规风险、断言难写（数据无法预期）、环境被真实数据污染后无法复位。正确做法是数据工厂按需构造、种子数据固定基线、敏感字段脱敏，在“真实感”和“可控性”之间找平衡。

为何常见：人天生相信“眼见为实”，觉得真实数据更权威，却忽略了测试的第一原则是“可预期、可复现”。

误区“既然契约测试能快速发现接口不兼容，而且不需要启真实服务，那我以后只跑契约测试就够了，集成测试可以省了。”

正解契约只覆盖“协议层面”——请求和响应的结构对不对；但数据库事务能否回滚、消息消费顺序、超时后的状态收敛、缓存与数据库的一致性，这些需要真实运行环境配合的交互，契约测试统统管不了。契约测试像“核对图纸尺寸”，集成测试像“真正把零件装起来转一圈”，两者是互补关系而非替代关系。

为何常见：契约测试因为快、隔离、自动化程度高，容易给人“万能”的错觉；实际它擅长的是接口协议验证，而不是全局行为验证。

面试题

Q1. 集成测试与单元测试最大的区别是什么？

单选题 · easy

  • A.单个函数的逻辑正确性
  • B.模块间接口与协作正确性← 正确答案
  • C.用户端到端操作流程顺畅
  • D.代码覆盖率是否达到指标

答案：B。单元测试盯的是“单块积木有没有裂纹”，集成测试盯的是“积木之间的凹槽凸起是否对齐”。选项 A 是单元测试的目标，C 是端到端测试的目标，D 是测试度量手段而非目的。只有 B 准确描述了集成测试的核心——验证模块间的接口与协作。

Q2. 自顶向下集成策略的主要劣势是什么？

单选题 · mid

  • A.需要构建大量底层桩件← 正确答案
  • B.可以完全避免测试数据准备
  • C.无法测试真实用户交互
  • D.对模块耦合度提出高要求

答案：A。自顶向下从塔尖往塔基搭，底层模块还没实现，必须用大量桩件顶替，这是它最大的成本来源，也是 A 正确的原因。B 明显错误，任何集成测试都离不开数据准备；C 是端到端测试关注点；D 与策略本身无关。这也解释了为什么底层模块多的项目要慎用自顶向下。

Q3. 关于自底向上集成策略，下列说法正确的是？

单选题 · easy

  • A.从顶层模块开始逐步向下集成
  • B.顶层模块最后才被真正验证← 正确答案
  • C.全程无需任何类型的替身
  • D.比自顶向下成本一定更低

答案：B。自底向上从地基往上搭，底层模块最先被真实集成和验证，而最上层的控制模块要到流程最后才被真正验证，B 正确。A 是自顶向下的描述；C 错误，因为顶层未完成时需要驱动器代替；D 的“一定更低”过于绝对，成本取决于具体依赖结构。

Q4. Stub（桩对象）与 Mock（模拟对象）的核心区别是什么？

单选题 · mid

  • A.Stub 断言交互而 Mock 返回数据
  • B.Stub 返回数据而 Mock 断言交互← 正确答案
  • C.Stub 用于集成而 Mock 用于单元
  • D.Stub 是真实模块而 Mock 是替身

答案：B。Stub 像只念固定台词的替身，被调用就返回预设数据；Mock 像带着场记本的替身，记录并断言“有没有被正确调用、参数对不对”。B 说反了两者的职责，C 的“用于哪类测试”并非本质区别，D 说反了——两者都是替身，没有哪一个代表真实模块。

Q5. 三明治集成策略的典型特征是什么？

单选题 · hard

  • A.仅依赖自底向上的单向顺序
  • B.同时使用桩件与驱动器两类替身← 正确答案
  • C.用端到端测试替代集成验证
  • D.只对中层模块进行完整集成测试

答案：B。三明治以中间层为锚点，向上集成顶层时用桩件代替高层，向下集成底层时用驱动器调用底层，两类替身同时上阵，B 正确。A 说反了，它是双向推进；C 混淆了测试层级；D 说“只测中层”不对——三层都测，只是顺序和替身安排不同。

Q6. 消费者驱动的契约测试中，接口契约通常由谁定义？

单选题 · mid

  • A.契约由消费者团队负责定义← 正确答案
  • B.契约由提供者团队负责定义
  • C.契约由测试中心统一设计编写
  • D.契约由运维部门规定签署

答案：A。消费者驱动契约的精髓是“需求方写验收标准”——消费者团队把自己的调用期望写成契约文件，提供者团队去验证是否满足。A 正确。B 是传统的提供者定义接口模式，C 和 D 都不符合契约测试的职责划分，运维和独立测试中心不掌握消费方的真实调用场景。

Q7. 以下哪种场景契约测试无法替代集成测试？

单选题 · extreme

  • A.验证跨服务数据格式兼容性
  • B.验证数据库事务回滚一致性← 正确答案
  • C.验证 REST API 请求响应结构
  • D.验证消息队列事件负载结构

答案：B。契约测试擅长验证接口协议层面的匹配，比如格式、结构、字段存在性。但数据库事务回滚涉及真实状态管理、锁、隔离级别等运行时行为，契约完全无法描述和验证，只有真实环境集成测试能覆盖，B 正确。A、C、D 都是契约测试的典型适用场景——它们都能被写进契约文件并自动化校验。

Q8. 以下哪些属于常见的测试替身类型？

多选题 · easy

  • A.桩对象 Stub 返回预设数据← 正确答案
  • B.模拟对象 Mock 验证交互行为← 正确答案
  • C.伪对象 Fake 提供轻量替代实现← 正确答案
  • D.端到端测试可作为测试替身使用

答案：ABC。Stub、Mock、Fake 是三种常见的测试替身，分别擅长返回预设数据、断言交互、提供轻量真实实现，A、B、C 都对。D 错在概念混淆：端到端测试是一种测试层级，不是替身类型——它恰恰需要所有真实模块在位，和“替身顶班”的理念完全相反。

Q9. 集成测试中环境管理的正确做法有哪些？

多选题 · mid

  • A.使用独立数据库避免数据互相污染← 正确答案
  • B.测试前重置数据保证环境干净一致← 正确答案
  • C.生产环境真实数据直接复制用于测试
  • D.配置随代码一起进入版本控制体系← 正确答案

答案：ABD。独立数据库（A）和测试前重置（B）都是保证环境可复现的关键手段，配置随代码入版本库（D）能让环境一键重建。C 是典型误区：生产数据直接复制会带来隐私风险和断言不可预期，正确做法是数据工厂构造、敏感字段脱敏，而不是“图省事直接复制”。

Q10. 以下哪些符合持续集成中集成测试自动化的最佳实践？

多选题 · mid

  • A.并行执行集成测试加快流水线反馈← 正确答案
  • B.失败用例自动阻断本次合入操作← 正确答案
  • C.集成测试仅在发布前集中执行一次
  • D.集成测试失败可以先忽略等待修复

答案：AB。A 通过并行压缩测试时长，B 让失败用例成为“红灯”阻断合入，两者都是 CI 中集成测试自动化的核心实践。C 错在“仅在发布前”——集成测试应在每次合入前执行，而不是攒到发版才验收；D 违背了质量门禁原则，失败用例被忽略就等于门禁形同虚设，问题只会越攒越多。