10｜你测的模块依赖别的团队的服务，怎么协作和测试？

开场先讲依赖测试的两个难点：不可控（依赖团队的服务你没有支配权，他们的排期和质量你说了不算）、不可见（下游服务的实现你不了解，出了问题难定位）——难点先摆出来，后面的手段才有针对性。

回答思路

第一步：讲测试策略的选择

• 联调测试：真实依赖，测集成效果，但受制于对方环境和排期
• 挡板 mock：模拟依赖的返回，测自己的逻辑，快速且可控但测不到真实交互
• 契约测试：双方约定接口契约，各自按契约测试，工具验证兼容性——微服务的主流实践

三种策略的组合使用（主流程 mock 提速、关键集成场景联调、长期合作用契约防漂移），策略组合讲出来就是老手。

第二步：讲跨团队协作的机制

• 依赖的提前申报：迭代排期时就报依赖需求，进对方的排期而不是临时求人
• 接口文档的先行：开发和测试一起和对方对齐接口定义，变更互相通知
• 联调窗口的约定：约好时间大家一起调，不来回扯皮
• 问题责任的界定：联调问题按契约分责，谁不符合契约谁修——契约文档是仲裁依据

第三步：讲异常场景的专项

依赖服务挂了你的系统怎么办——降级逻辑、超时处理、重试机制，这些容错设计恰恰要用 mock 来模拟依赖异常才能测到。异常场景是依赖测试的精华所在，能主动讲的人不多。

收尾：给格局

跨团队依赖的本质是组织问题（康威定律：系统的依赖结构映射组织的沟通结构）——测试在中间做的对齐和留痕，实际是在为组织的信息流补路。这个视角收尾很显深度。

考察重点

维度	说明
企业动机	微服务时代没有模块是孤岛（跨团队依赖是测试的日常），这题考察依赖治理的测试策略（mock/联调/契约）和跨团队协作能力——契约测试讲得出的候选人直接加分，说明有微服务实战
过线标准	三种测试策略及组合 + 协作机制
区分度	讲契约测试、讲依赖异常的容错测试的是微服务环境的老兵
加分项	康威定律的收尾视角
减分项	「等他们好了我们再测」，被动等待既无策略也无推进

来源

整理自知识星球帖《面试情报 10｜测试流程与团队协作 20 题》，返回题库。