如何测试一个你完全不熟悉的业务模块？
👔 Raina面试官： 突然让你测一块完全没接触过的业务，你怎么快速上手？
🙋 候选人：
- 我的路径是先搞清业务目标和主流程，再下钻规则和异常。
- 读 PRD 和原型，画用户旅程图；找产品或业务方做 30 分钟 walkthrough；看历史缺陷和线上反馈了解坑点；对照数据库表结构理解数据怎么流转。
- 第一周偏探索性测试摸底，第二周再系统化补用例。不懂就问，问题清单比假装懂更重要。
👔 Raina面试官： 业务方很忙理你，怎么办？
🙋 候选人：
- 用具体场景提问代替请介绍一下——比如退款 partial refund 规则是什么，比空泛的讲讲业务高效。
- 同时读操作手册、培训材料、客服工单分类，从用户视角反推业务规则，再拿假设找业务确认。
多角色、多状态的业务流程你怎么保证测全？
👔 Raina面试官： 多角色多状态的流程，你怎么保证不遗漏？
🙋 候选人：
- 用角色×状态×动作三维矩阵梳理，再按风险裁剪。
- 先列所有角色（申请人、审批人、财务等）和对象状态（草稿、审批中、驳回、完成），画 swimlane 流程图标注每步谁操作。状态迁移表覆盖合法/非法跳转，角色矩阵覆盖各角色可见可操作范围。
- P0 走通主路径全角色，P1 覆盖常见分支和驳回重提，P2 覆盖异常和权限。
👔 Raina面试官： 组合爆炸测不完怎么办？
🙋 候选人：
- 用风险优先级 + pairwise 减组合，但核心状态迁移和越权场景不能砍。
- 和历史缺陷、资金/合规相关路径加权。自动化固化回归集，手工负责新规则和边界探索。
前端和后端对同一功能理解不一致，测试怎么介入？
👔 Raina面试官： 前后端对同一功能理解打架了，测试怎么介入？
🙋 候选人：
- 测试当对齐枢纽：复现差异、摆证据、拉三方定标准。
- 分别按前端交互和后端接口文档各测一遍，记录差异点（字段名、枚举值、空值处理、错误码）。组织 short meeting 产品一锤定音，结论更新到 AC 和接口文档。
- 测试不站队，用可复现的步骤和截图/响应 JSON 说话。
👔 Raina面试官： 联调前就发现文档不一致，还要等开发联调吗？
🙋 候选人：
- 不用干等，可以Mock 接口按文档测前端，Postman 按文档测后端，先把各自是否符合规格验清楚。
- 这样联调时问题范围更小——是集成问题还是单方实现偏差，定位更快。
缓存、消息队列、定时任务这类看不见的逻辑你怎么测？
👔 Raina面试官： 缓存、MQ、定时任务这种看不见的逻辑，你怎么测？
🙋 候选人：
- 思路是触发输入 + 观测副作用，不能只看 UI。
- 缓存：改数据后查列表是否即时更新，清缓存后是否回源 DB；TTL 过期验证。MQ：发消息看消费者是否处理、失败是否重试/进死信、幂等是否重复消费。定时任务：改系统时间或提供手动触发入口，查 DB/日志确认执行结果和漏跑告警。
- 需要测试环境能看 Redis、MQ 控制台、任务调度日志，否则只能黑盒猜。
👔 Raina面试官： 异步逻辑测试最难的是什么？
🙋 候选人：
- 是时序和最终一致性——不能期望立刻生效，要有轮询或等待策略，并设超时判定失败。
- 我会给异步用例加观测点：消息 ID、traceId、数据库状态字段，方便失败时查链路而不是反复盲点刷新。
数据一致性在功能测试中怎么验证？
👔 Raina面试官： 功能测试里数据一致性你怎么验证？
🙋 候选人：
- 核心是看同一业务事实在多处的表现是否一致——UI、接口、DB、缓存、下游系统。
- 例：下单成功后，订单列表、详情页、支付记录、库存扣减、积分变动、MQ 消息都要对齐。我会设计 checkpoint：操作后立即查 API 和 SQL，而不只看点界面 OK。
- 分布式场景还要关注：事务失败是否部分写入、补偿是否生效、对账报表能否发现差异。
👔 Raina面试官： 没有 DB 查询权限怎么办？
🙋 候选人：
- 退而求其次用管理后台、对账接口、日志验证；推动给测试只读库权限。
- 关键金融/库存场景没有 DB 验证能力，功能测试可信度会大打折扣，这本身要作为风险报出来。
幂等性是什么？哪些场景必须测幂等？
👔 Raina面试官： 幂等性是什么？哪些场景你必须测幂等？
🙋 候选人：
- 幂等就是同一请求执行多次，结果和执行一次相同，不产生额外副作用。
- 必测场景：支付扣款、下单、退款、发券、积分增减、审批操作、任何可能因网络重试而重复提交的 POST。测法：相同 requestId 或快速双击/并发重放，验证 DB 只有一条有效记录、余额只扣一次。
- 缺少幂等的设计是线上重复扣款高发区，功能测试要主动构造重试场景。
👔 Raina面试官： 怎么模拟重复请求？
🙋 候选人：
- 用Postman 重发、脚本并发、抓包重放、网关层 duplicate 几种方式。
- 最好有唯一业务键（orderId、idempotency-key）可在 DB 查重。没有的话，快速连点 UI 或断网重试也是常见用户行为模拟。
并发操作同一资源（如库存、余额）时，功能测试要关注什么？
👔 Raina面试官： 库存、余额这种并发抢同一资源，功能测试关注什么？
🙋 候选人：
- 关注超卖/透支、数据准确、锁策略、用户体验四方面。
- 功能：10 个并发抢 5 件库存，最终卖出不能超过 5。数据：余额不能为负，流水总和对得上。体验：失败用户收到明确提示而非长时间 spinning。
- 测试可以用 JMeter 轻量并发或脚本同时发请求，不一定上全压测，但要超过单用户 sequential 的视角。
👔 Raina面试官： 功能测试和性能测试在并发这块边界在哪？
🙋 候选人：
- 功能测试验证正确性——会不会超卖；性能测试验证大量并发下的吞吐和延迟。
- 功能侧用小并发（5-20）就够暴露锁缺失；大并发留给性能。但功能测试发现的超卖 Bug 往往比慢更严重。
灰度发布期间，功能测试策略需要怎么调整？
👔 Raina面试官： 灰度发布期间，功能测试策略要怎么调整？
🙋 候选人：
- 灰度期测试要分版本、分人群、可回滚三件事。
- 测试前确认灰度规则——按用户 ID、地域还是比例；准备灰度账号和非灰度账号对照测新旧逻辑。重点回归核心链路和变更点，监控灰度桶内错误率。
- 每扩一批灰度比例，做一轮 smoke + 关键回归；保留快速回滚验证用例。
👔 Raina面试官： 测试环境没法模拟灰度怎么办？
🙋 候选人：
- 推动测试环境配置 Feature Flag 与线上一致，或用 mock 网关路由到不同版本服务。
- 至少要在预发/full 环境走一遍灰度流程；完全测不了的要列为上线风险，加强线上监控和 Canary 告警。
接口测试和功能测试的区别是什么？各自的价值在哪里？
👔 Raina面试官： 接口测试和功能测试区别在哪？各自价值是什么？
🙋 候选人：
- 接口测试验证服务契约和数据逻辑，功能测试验证用户可感知的完整行为。
- 接口测试：绕 UI 直接调 API，快、稳定、易自动化，适合逻辑校验、边界、鉴权、集成。功能测试：含 UI 交互、跳转、兼容、端到端体验，更贴近真实用户。
- 价值互补——接口层把后端测透，功能层 catch 前后端集成和体验问题。只有 UI 测试会慢且 fragile；只有接口测试会漏前端展示和交互 Bug。
👔 Raina面试官： 小团队只能选一个，你优先哪个？
🙋 候选人：
- 优先核心接口自动化 + 关键路径 UI 手工/少量 E2E。
- 接口 ROI 更高；UI 自动化挑主流程 smoke。随着团队成熟再扩 E2E 和 visual regression。
设计接口测试用例时，你会从哪些维度考虑？
👔 Raina面试官： 设计接口测试用例，你会从哪些维度考虑？
🙋 候选人：
- 我按功能、参数、安全、依赖、非功能五维拆。
- 功能：正常 CRUD、业务规则。参数：必填缺失、类型错误、边界、非法枚举。安全：鉴权、越权、注入。依赖：上下游数据准备、事务一致性。非功能：超时、幂等、限流响应。
- 每个接口至少：happy path、主要异常码、鉴权正反例；核心接口加并发和数据校验。
👔 Raina面试官： 接口文档字段可选实际必填，你怎么处理？
🙋 候选人：
- 测出差异后提缺陷更文档，并以实际行为为准补充用例，直到文档和实现一致。
- 这类问题在联调期很常见，测试的价值之一就是逼出并固化真实契约。