# 1. 消费者驱动契约(CDC)的核心价值与权衡是什么？在什么组织架构下 CDC 能发挥最大效益？ A CDC 可以在任何组织架构下都发挥最大效益 B CDC 以消费者定义的显式契约消除隐性依赖，支持微服务独立部署与快速反馈，但需承担契约维护成本，在多团队独立部署的微服务组织中收益最大 ✓ 正确答案 C CDC 完全替代集成测试，无需其他验证 D CDC 只适用于单体应用
# 2. 契约测试中'消费者驱动'与'提供者驱动'两种模式的差异和适用场景？ A 两种模式契约产生方与变更方向完全相同 B 契约方向不影响测试设计 C 提供者驱动一定比消费者驱动更好 D 消费者驱动由消费方定义契约并优先保障其兼容性，提供者驱动由提供方定义规范统一契约，二者责任归属与适用场景不同 ✓ 正确答案
# 3. 契约测试与系统验证的关系，契约测试能否替代端到端系统验证？两者的覆盖盲区如何互补？ A 契约测试基于 mock 验证单接口契约，无法覆盖真实网络/配置/部署等集成因素，因此是 E2E 的补充而非替代，二者互补 ✓ 正确答案 B 契约测试可以完全替代端到端验证 C 端到端测试一定比契约测试重要 D 契约测试与 E2E 覆盖盲区完全相同
# 4. 契约过期(Stale Contract)如何检测与处理？契约版本管理与弃用(Deprecation)策略如何设计？ A 过期契约无需处理，可永久保留 B 弃用后应立即删除契约，无需过渡期 C 通过消费者版本与 tag 检测契约是否活跃，对废弃契约自动清理，并采用弃用期+迁移窗口的兼容过渡策略，配合 can-i-deploy 管理生命周期 ✓ 正确答案 D 契约版本管理与接口版本无关
# 5. 契约测试在微服务架构中的价值，解决了哪些传统集成测试难以解决的问题？ A 契约测试仍然需要完整环境才能运行 B 契约测试只能发现功能缺陷，无法支持部署决策 C 契约测试通过显式契约与本地 mock 验证，实现服务解耦、快速反馈与独立部署，解决传统集成测试的环境依赖与慢反馈问题 ✓ 正确答案 D 微服务场景下传统集成测试已足够，无需契约测试
# 6. Pact 的异步消息契约，消息队列场景下的消费者驱动契约如何设计与验证 A 消息契约描述消息 payload 的结构与内容，消费者定义契约、提供者验证，并关注序列化格式与字段兼容性 ✓ 正确答案 B 消息契约与 HTTP 契约完全相同，都验证请求-响应 C 消息场景无需契约测试，直接联调即可 D 消息契约只验证消息 key，不验证 payload
# 7. Pact(Broker) 与 Spring Cloud Contract 的差异与选型依据是什么？从生态、语言支持、维护模式三个维度对比。 A 两者语言支持完全相同 B Pact 只能用于 Java 项目 C Pact 多语言且消费者驱动、Broker 生态完善，Spring Cloud Contract 提供者驱动且与 Java/Spring 深度集成，选型应结合技术栈与契约驱动方向 ✓ 正确答案 D Spring Cloud Contract 支持所有语言
# 8. 提供者(Provider)契约的'需求侧'用例如何设计？如何确保契约覆盖所有消费者的实际使用场景？ A 契约应覆盖提供者全部接口的任何参数 B 契约只需覆盖成功场景，无需错误场景 C 精确匹配所有字段值，越严格越好 D 契约应来源于消费者真实使用场景，用宽松匹配（类型/正则）避免过严，并聚合多消费者保证覆盖完整 ✓ 正确答案
# 9. 服务虚拟化(Service Virtualization)与契约测试的边界是什么？两者在微服务测试中的协同方式？ A 两者功能完全相同，可互换 B 契约测试能替代真实服务运行 C 服务虚拟化能验证接口契约是否匹配 D 服务虚拟化模拟依赖行为解决"依赖不可用"，契约测试验证接口契约一致性，二者可结合（基于契约桩生成虚拟服务）协同推进 ✓ 正确答案
# 10. 契约测试在 CI/CD 流水线中的集成模式，消费者端和提供者端各自应在哪个阶段验证契约？ A 提供者验证无需 Broker 中的消费者契约 B 消费者在 CI 测试阶段运行契约测试并发布契约到 Broker，提供者在验证阶段拉取契约验证，can-i-deploy 在发布前做门禁决策 ✓ 正确答案 C can-i-deploy 与契约测试无关 D 消费者契约测试必须等提供者在线才能运行
# 11. API 安全测试，认证、授权、速率限制、输入验证的系统化测试方法？ A 只需测试认证即可，授权与限流无关 B 应系统化覆盖认证（401/凭据）、授权（越权/IDOR/最小权限）、速率限制（429/隔离）与输入验证（注入/路径遍历），结合 OWASP 与模糊测试 ✓ 正确答案 C 输入验证可以完全信任客户端 D 速率限制只能测试是否触发，无需测试绕过
# 12. Pact Broker 的契约版本管理和 can-i-deploy 工具在发布决策中的作用？ A can-i-deploy 与版本验证结果无关 B can-i-deploy 只能由人工执行，无法集成 CI C tag 只用于展示，不影响部署判定 D Pact Broker 用版本与 tag 管理契约和验证结果，can-i-deploy 在发布前判定该版本是否满足已部署消费者的契约，作为发布门禁 ✓ 正确答案
# 13. 契约测试的维护成本治理，契约数量膨胀、废弃契约清理与过期检测如何制度化 A 契约越多越好，无需清理 B 契约数量膨胀无法治理 C 过期契约可无限保留，不影响验证 D 应通过契约粒度规范、废弃契约自动清理（依据版本/tag/部署状态）与过期检测制度化，实现契约生命周期管理，控制成本 ✓ 正确答案
# 14. Schema Registry（Avro/Protobuf 演进）与协议兼容性验证，向后/向前兼容如何测试 A schema 演进无需考虑兼容性 B 向后兼容与向前兼容含义相同 C Schema Registry 用兼容模式（BACKWARD/FORWARD/FULL）校验 Avro/Protobuf 演进，向后兼容保护旧数据、向前兼容保护旧客户端，需测试字段增删/类型变更/字段号复用等场景 ✓ 正确答案 D 字段号可以随意复用不影响兼容性
# 15. 契约测试的失败排查，Provider 验证失败时如何区分实现缺陷与契约本身过时？ A 验证失败一定是实现缺陷，直接修提供者 B 验证失败一定是契约过时，直接更新契约 C 应先看失败断言与消费者真实需求，判断是实现缺陷（修实现）还是契约过时（更新契约），避免盲目修一方 ✓ 正确答案 D 失败排查无需考虑消费者意图
# 16. 契约测试的局限性，哪些类型的缺陷无法通过契约测试发现？需要配合哪些其他测试类型？ A 契约测试能发现所有类型的缺陷 B 契约测试基于 mock 无法发现真实集成、性能、安全与跨服务流程问题，需配合 E2E、性能、安全等测试覆盖盲区 ✓ 正确答案 C 契约测试能验证性能与容量 D 契约测试能发现跨服务事务问题
# 17. API 性能测试，如何设计覆盖缓存命中、数据库查询、网络延迟的测试场景？ A 只需做整体压测即可，无需分因素 B 网络延迟不需测试，因为生产环境网络稳定 C 缓存命中对性能无影响 D 应分别设计缓存命中/未命中、数据库查询（慢查询/连接池）与网络延迟场景，采集响应时间与吞吐定位瓶颈，并设置性能基线 ✓ 正确答案
# 18. 验收标准(AC)到测试用例的映射方法，如何确保每个 AC 都有对应的验证用例？ A AC 无需结构化，直接凭经验写用例即可 B 应把 AC 拆分为可验证断言，用追踪矩阵将每个 AC 映射到至少一个用例，并通过覆盖率检查确保无遗漏 ✓ 正确答案 C 一个 AC 只需一个测试用例即可，不必覆盖边界 D 追踪矩阵只用于记录，不影响覆盖完整性
# 19. 契约测试的用例表达，Pact 中 interaction 的匹配规则（正则、类型匹配）如何设计避免过度严格？ A 对可变值用类型匹配、对固定格式用正则匹配、对集合用最小结构，验证结构/类型/格式而非具体值，可避免过度严格导致的误报 ✓ 正确答案 B 对所有字段都应做精确值匹配，越严格越好 C 正则匹配会锁死字段值，无法容忍变化 D 类型匹配只校验值，不校验类型
# 20. 多语言生态下的契约测试，Pact-JVM/Pact-Python/Pact-JS 的互操作与 Broker 集成？ A Pact-JVM 生成的契约只能被 Pact-JVM 验证 B 各语言 Pact 实现遵循统一契约格式与 Pact Specification，通过 Pact Broker 共享契约与验证结果，实现跨语言互操作 ✓ 正确答案 C Broker 无法跨语言集成 D 不同语言必须使用不同的 Broker
# 21. 契约测试与 API 版本管理的结合，契约变更如何与接口版本、迁移窗口联动？ A 破坏性变更应提升版本并设迁移窗口，在窗口内新旧契约并存、验证向后兼容，消费者迁移后再清除旧契约 ✓ 正确答案 B 契约变更无需考虑版本，直接改即可 C 迁移窗口只是建议，无需契约验证 D 契约变更与接口版本无关
# 22. 异步/事件驱动的契约测试，消息契约在 Kafka 场景下的发布订阅验证如何设计？ A Kafka 消息契约与 HTTP 契约完全相同 B 消息契约只验证 topic 名，不验证 payload C Kafka 场景无需契约测试，直接联调即可 D 消息契约描述生产者发布/消费者订阅的消息 payload 结构与内容，验证双方契约一致，并关注 schema 兼容与真实投递 ✓ 正确答案
