prod）配置差异你怎么管理？

👔 Raina面试官： dev、test、staging、prod 配置差异你怎么管？

🙋 候选人：

核心是同一份代码，不同配置注入；差异可清单化、可 diff。
用环境变量、config center（Nacos/Apollo）、K8s ConfigMap/Secret 管理差异；禁止 hardcode prod 地址。维护 env 对照表：DB 连接、第三方 key、feature flag、限流阈值。测试关注：staging 是否足够像 prod（数据量级可小，但架构和中间件版本应一致）。
secrets 不进 Git；test 用 mock 或 sandbox key。发布前 diff staging vs prod 配置（脱敏），漏配一项可能 staging 全绿 prod 挂。

👔 Raina面试官： 开发在 dev 测过了，测试还要全量吗？

🙋 候选人：

要，因为配置和数据不同，行为可能不同。
dev 证明能跑；test/staging 证明能发。至少回归 P0 + 配置敏感项（支付 sandbox vs prod endpoint 切换）。

测试环境经常不稳定，你会怎么推动改善？

👔 Raina面试官： 测试环境老不稳定，你怎么推动改善？

🙋 候选人：

先用数据说话，再要 ownership，别只抱怨。
收集：环境不可用时长、flaky case 比例、根因分类（部署失败、磁盘满、中间件挂、数据被清）。可视化周报给 TL/运维。推动：健康检查 + 自动重启、部署标准化、环境负责人 rotation、test 数据隔离、staging 跟 prod 同构。
测试侧也要自律：不手工改共享库、长压测错峰、清理脚本别误删。短期可设环境就绪门禁—— smoke 不过不开始当日测试。

👔 Raina面试官： 领导说克服一下，没资源怎么办？

🙋 候选人：

量化因环境浪费的人天，比要 headcount 有时更有效。
提议最小改动：每日 morning smoke bot、失败 @oncall；或买托管 test env。把 unstable env 风险写进 release risk register，让决策层知道快的代价。

微服务架构给测试带来什么挑战？

👔 Raina面试官： 微服务架构给测试带来哪些挑战？

🙋 候选人：

最大变化是从单体端到端变成多服务协作，失败点和服务边界都变多了。
挑战包括：依赖链长，一个服务 mock 不全就测不准；环境要起 N 个服务 + 中间件；数据分散在多库，一致性难验；版本独立发布，组合爆炸；异步和 eventual consistency 增加 flaky。
应对上我会分层：单服务契约/接口测试、集成测试（真实依赖或 testcontainers）、少量 E2E 覆盖黄金路径；配合 service virtualisation 和 staging 全链路。测试设计要画依赖图，知道测的是哪一层。

👔 Raina面试官： E2E 是不是越少越好？

🙋 候选人：

对，E2E 贵且脆，保留 P0 用户旅程即可。
其余用契约测试 + 集成测扛 coverage。微服务下全 UI E2E 覆盖一切会维护地狱；金字塔在分布式里更重要。

服务间调用失败、熔断、降级怎么测？

👔 Raina面试官： 服务间调用失败、熔断、降级你怎么测？

🙋 候选人：

要主动注入故障，不能等自然挂。
失败：mock 下游 500/timeout/connection reset，验上游重试次数、超时时间、错误码转换。熔断：连续失败 N 次后是否 open、open 期间 fast-fail、half-open 探测恢复。降级：返回兜底数据/缓存/静态页，核心路径仍可用；非核心功能可 gracefully 失败。
用 chaos 工具（Toxiproxy、WireMock fault、K8s 网络 delay）或 test hook。断言用户可见行为 + 监控指标（circuit state、fallback rate）。

👔 Raina面试官： 降级测多了怕掩盖真 bug 怎么办？

🙋 候选人：

分场景：故障注入套件专门测降级；正常回归关掉 fault。
CI 分 job：regression 全绿；resilience job 注入故障。还要验降级时有日志/告警，运维能感知，不是静默吞错。

分布式事务（TCC、Saga、本地消息表）测试关注点是什么？

👔 Raina面试官： TCC、Saga、本地消息表这些分布式事务，测试关注什么？

🙋 候选人：

共同关注正常提交、异常补偿、幂等与最终一致，每种模式侧重点不同。
TCC：Try 资源预留、Confirm 提交、Cancel 释放；测 Confirm/Cancel 失败重试、悬挂（Try 后长时间不 Confirm）。Saga：正向链 + 逆向补偿链；测某步失败后续是否按序补偿、补偿失败是否进人工。本地消息表：业务写 + 消息同本地事务；测 relay 重发、重复投递、消费失败重试。
都要测：网络分区、服务重启 mid-transaction、重复请求。断言最终各服务数据一致，中间态可接受但要可观测。

👔 Raina面试官： 怎么验最终一致？

🙋 候选人：

用对账脚本 + 超时轮询断言：订单已支付则库存必扣、积分必加。
设 max wait（如 30s）轮询直到一致或 fail。记录中间态日志便于开发查 compensation 卡在哪。

如何测试服务的幂等性和重试机制？

👔 Raina面试官： 服务的幂等性和重试机制你怎么测？

🙋 候选人：

幂等测同一业务键多次调用，副作用只发生一次；重试测失败后可安全再调。
设计：带 Idempotency-Key / 业务单号的 create、支付、扣库存接口，连发 3 次相同请求，断言 DB 一行、余额只扣一次。重试：mock 第一次 timeout 第二次 200，或返回 409 表已存在。还要测乱序：重试比首次响应先到（要用真实异步或 delay mock）。
GET 天然幂等也要测副作用 GET（如确认收货误设计成 GET）。文档写非幂等的接口禁止 blind retry。

👔 Raina面试官： 客户端重试和服务端幂等谁负责？

🙋 候选人：

服务端必须幂等或 dedupe，客户端重试是常态（网络抖动）。
测试验收标准放服务端：无 key 的写接口要标风险。网关层 duplicate request filter 也可测。

服务注册与发现（Nacos、Consul 等）对测试有什么影响？

👔 Raina面试官： Nacos、Consul 这种注册发现，对测试有什么影响？

🙋 候选人：

服务地址从静态配置变成动态，测试环境要模拟注册、上下线、多实例。
影响：compose/K8s 里服务名解析；本地直连 IP 和走 discovery 行为可能不同。要测：新实例注册后流量是否可达、实例下线是否摘流、健康检查失败是否踢出、灰度/metadata 路由是否正确。
集成测试应用真实 registry（Nacos test namespace），避免全静态 hosts——否则上线才发现 discovery 配置错。多版本共存时测 consumer 能否发现正确 provider 版本。

👔 Raina面试官： 测试环境 registry 挂了怎么办？

🙋 候选人：

验缓存列表降级 + 告警，不是测试盲区。
部分客户端有本地缓存继续调；完全不可调应 fail fast 有明确错误。这跟 resilience 测试一起覆盖。

API 网关层需要测哪些点？

👔 Raina面试官： API 网关层你会测哪些点？

🙋 候选人：

网关是流量入口，鉴权、路由、限流、协议转换都要测。
鉴权：Token/JWT/API Key 缺失、过期、篡改、越权路由。路由：path/host/header 规则是否到正确 upstream；灰度权重；404 未知路由。限流熔断：超 QPS 返回 429、按用户/IP 维度。协议：HTTP→gRPC、WebSocket 透传、request/response 改写。
还有：超时配置、CORS、请求体大小限制、WAF 规则、access log 是否带 trace_id。很多接口问题其实是网关层，测试要会 curl 直连 upstream 对比经网关结果。

👔 Raina面试官： 网关和下游重复鉴权，测哪层？

🙋 候选人：

两层都测，但分工明确：网关拦非法流量，下游防 bypass（直连 internal）。
安全测试要试绕过网关打内网 IP；网关测过的鉴权 case 下游可抽样。

链路追踪（Trace）对测试和问题定位有什么帮助？

👔 Raina面试官： 链路追踪对测试和问题定位有什么帮助？

🙋 候选人：

Trace 把一次请求跨服务的 span 串成故事，定位从猜变成看。
测试价值：断言 critical path 是否经过预期服务、耗时是否超标、是否有 error span。失败 case 附 trace_id 给开发，比贴十段日志快。回归时可对比同接口 span 数量/耗时是否异常增多（可能多了 hidden RPC）。
问题定位：用户说下单慢，用 trace_id 看卡在支付还是库存；404 看路由到哪个 pod。测试推动 trace 在 ingress 生成并透传，否则各服务 log 对不上。

👔 Raina面试官： 测试要会看 Jaeger/Zipkin 吗？

🙋 候选人：

要会基本查询：按 trace_id、service、duration 过滤。
不用会部署，但要会从 response header 拿 trace_id 在 UI 里点开。集成到测试报告里，flaky 分析效率会高很多。

版本兼容性测试在微服务场景下怎么做？

👔 Raina面试官： 微服务场景下版本兼容性测试怎么做？

🙋 候选人：

关键是契约向后兼容 + 多版本组合矩阵。
Consumer-driven contract（Pact）：consumer 期望 vs provider 实际。API 版本：v1 client 调 v2 server 是否仍工作；字段只增不减、枚举扩展。部署顺序：先扩 provider 再升 consumer 还是并行——按 release note 测 rollback 组合。
staging 做 canary：10% 新 order-service + 旧 payment-service 跑 E2E。Breaking change 必须有 deprecation 窗口和 feature flag 双写期测试。

👔 Raina面试官： 组合爆炸测不完怎么办？

🙋 候选人：

用风险矩阵：只测有变更的服务及其直接上下游。
全量 N×N 不现实；契约测试在 CI 卡接口层，E2E 只跑受影响链路。记录 compatibility matrix 每 release 更新。

消息队列（Kafka、RabbitMQ、RocketMQ）消费逻辑怎么测？

👔 Raina面试官： Kafka、RabbitMQ 这些 MQ 消费逻辑你怎么测？

🙋 候选人：

MQ 测试要生产消息 → 等待消费 → 断言副作用，并控制异步时序。
单测：mock consumer handler 逻辑。集成：往 test topic/queue 发消息，poll DB/下游接口验结果。关注：序列化格式、header 传递、consumer group 再平衡、死信队列（DLQ） poison message。
不同 MQ：Kafka 分区有序、offset commit 时机；RabbitMQ ack/nack/requeue；RocketMQ 延迟消息、事务消息——按产品用的特性设计 case。测试环境隔离 topic，避免污染 prod。

👔 Raina面试官： 异步怎么避免测试 flaky？

🙋 候选人：

用轮询断言（awaitility）+ 合理 timeout，别固定 sleep 5 秒。
消费完成后写 status 表或发 callback，测试 poll 直到 done。超时 fail 时 dump consumer lag 和 DLQ 便于排查。

消息重复消费、消息丢失、顺序消费怎么验证？

👔 Raina面试官： 消息重复消费、丢失、顺序消费你怎么验证？

🙋 候选人：

三类问题对应三种注入手段和断言。
重复消费：同一 message_id 发两次或 replay offset，断言业务幂等（订单不重复创建）。丢失：模拟 consumer crash before ack、broker 故障——用对账（发送计数 vs 处理计数）、业务状态机不完整订单告警。顺序：同 key 发到同一分区，并发消费验 FIFO；乱序场景是否可接受或有无补偿。
还要测：生产端事务消息、at-least-once 语义下 consumer 必须幂等。监控 consumer lag spike 作为测试环境健康指标。

👔 Raina面试官： 怎么区分丢失还是消费慢？

🙋 候选人：

看lag、DLQ、发送/消费 audit 表三件套。
lag 涨但 eventually 消费完是慢；offset 跳过或 DLQ 无记录且业务缺失是真丢。测试报告写清语义是 at-most-once 还是 at-least-once，预期不同。