CI/CD 流水线里测试应该放在哪些阶段？

👔 Raina面试官： CI/CD 流水线里测试应该放在哪些阶段？

🙋 候选人：

• 典型分层：commit → PR → merge → deploy staging → prod，每段测不同东西。
• PR：lint、单元测试、契约测试、轻量 API smoke（分钟级）。Merge 后：构建镜像、集成测试、部署 test env 跑自动化回归。Staging：全量 E2E、性能抽样、安全扫描。Prod：smoke + synthetic monitoring + canary 观察。
• 原则：越快越靠前；越贵越靠后。失败 fast 阻断下游。测试和 DevOps 一起定义 pipeline yaml，不是测完再扔过墙。

👔 Raina面试官： 流水线太长开发抱怨怎么办？

🙋 候选人：

• 拆required checks vs nightly，PR 只跑受影响模块（test impact analysis）。
• 并行 job、缓存依赖、flaky 测试修或 quarantine。用数据证明 long pipeline 比 hotfix 便宜。

什么是测试门禁（Quality Gate）？你会设哪些规则？

👔 Raina面试官： 测试门禁 Quality Gate 是什么？你会设哪些规则？

🙋 候选人：

• Quality Gate 是发布前必须满足的自动化质量阈值，不达标不能晋级。
• 常见规则：P0/P1 自动化 100% pass；代码覆盖率不低于基线（或 diff coverage）；无 open critical bug；SAST/依赖漏洞无高危；性能指标不超 budget；契约测试 pass；staging smoke pass。
• 要可执行：接 SonarQube、CI status check、Jira release blocker。规则分硬门禁（block）和软门禁（warn+人工 sign-off）。避免指标 vanity——100% 行覆盖但无断言没意义。

👔 Raina面试官： 业务说要发，门禁红了怎么办？

🙋 候选人：

• 走例外流程：书面 waiver、风险 owner、回滚预案。
• 测试职责是透明呈现风险，不是当橡皮图章。每次 waiver 记 post-release review，看是否该升级门禁。

代码合并前（PR / MR）的测试策略是什么？

👔 Raina面试官： PR/MR 合并前的测试策略你怎么定？

🙋 候选人：

• PR 阶段求快反馈 + 测到改动相关风险。
• 必跑：单元测试、静态检查、相关模块 API/契约测试。按 changed files 选测（monorepo 尤其重要）。可选：预览环境 deploy + 关键 path manual/auto smoke。要求：PR 描述 linked ticket、测试说明测了什么、截图/trace。
• Reviewer 含测试：看 test code 是否跟 prod code 一起提交。无测试的 bugfix 要问 regression case。大 PR 拆小，否则测不全。

👔 Raina面试官： 开发说小改动不用测，你怎么处理？

🙋 候选人：

• 可以少测但不能不测，至少 smoke + 相关单测。
• 一行改配置可能全站挂。用 incident 案例说明；小改动走 fast path 不是 no test path。

蓝绿发布、金丝雀发布对测试有什么要求？

👔 Raina面试官： 蓝绿发布和金丝雀发布，对测试有什么要求？

🙋 候选人：

• 两种都是降低发布风险，测试要覆盖双版本共存和流量切换。
• 蓝绿：绿环境全量回归通过再切流量；测切换瞬间 session 粘滞、DB migration 兼容两版本、回滚一键切回。金丝雀：5%→20%→100% 每步观察 error rate/latency/business KPI；测 canary 用户特定功能、新旧 API 混调。
• 测试参与：准备 canary 验证 checklist、 synthetic case 打 canary 实例、对比 baseline 指标。Feature 只在 canary 开的路径要单独 case。

👔 Raina面试官： 金丝雀期间用户投诉增加了算谁的问题？

🙋 候选人：

• 看canary 指标是否超阈值，超就自动 rollback。
• 测试提前定义 rollback 触发条件（error +50%、P0 case fail），写进 runbook，别发布后临时争论。

基础设施即代码（IaC）和环境一致性怎么保证？

👔 Raina面试官： IaC 和环境一致性怎么保证？

🙋 候选人：

• IaC（Terraform/Pulumi）让环境可版本化、可 diff、可重复 apply。
• 保证：test/staging/prod 用同一 module 不同 tfvars；PR 里 terraform plan review；drift detection 定期扫。测试受益：环境起得快、跟 prod 同构；验收 staging apply 结果 + smoke。
• 测试要懂基本：知道 RDS/K8s namespace 从哪来，环境挂时看 pipeline 不是 ssh 乱改。推动手工改 infra走 IaC，否则 test 和 prod 又漂移。

👔 Raina面试官： 测试需要会写 Terraform 吗？

🙋 候选人：

• 不必须写，但要会读 plan、会提 test env 需求。
• 比如需要独立 namespace + 复制 prod 中间件版本。跟 DevOps 协作时 speak the same language。

测试环境自动化的部署和回滚你怎么验证？

👔 Raina面试官： 测试环境自动化部署和回滚你怎么验证？

🙋 候选人：

• 部署回滚本身是一级可测试对象，要有 drill。
• 部署验：pipeline 绿、health check 过、版本号/tag 正确、DB migration 成功、配置注入对。回滚验：切上一镜像/helm revision、migration downgrade（若支持）、数据是否兼容旧代码、session 不大面积失效。
• 定期 game day：故意 deploy 坏包看 rollback 时间和 smoke。记录 RTO。测试在 deploy 后跑 smoke suite 作为 gate；rollback 后再跑同一 smoke 确认恢复。

👔 Raina面试官： 回滚了但 migration 不能降怎么办？

🙋 候选人：

• 这是forward-only migration，测试要验新版本代码 rollback 时仍兼容已升级 schema。
• 发布策略改为 expand-contract；回滚 drill 必须包含这类场景，否则假回滚。

Feature Flag 发布策略测试怎么配合？

👔 Raina面试官： Feature Flag 发布测试怎么配合？

🙋 候选人：

• Flag 把部署和发布解耦，测试要覆盖 on/off/灰度 三种状态。
• 每个 flag：OFF 旧行为不变；ON 新行为符合 spec；部分用户 ON 时不影响 OFF 用户。测 flag 服务挂了 default 是 safe（通常 off）。还有：flag 依赖（A on 才 B on）、清理 dead flag 后代码路径。
• 自动化用 override header / test env API 强制 flag 状态。Canary 常靠 flag，测试 case 绑定 flag name 进 tracking plan。

👔 Raina面试官： Flag 太多测不过来怎么办？

🙋 候选人：

• 跟产品对齐flag 生命周期：temporary flag 必须有 expiry 和测试 owner。
• 永久 config 别滥用 flag。组合 explosion 用 pairwise 或只测 release 涉及的 flag 子集。

制品晋级（Artifact Promotion）流程中测试角色是什么？

👔 Raina面试官： 制品晋级流程里测试角色是什么？

🙋 候选人：

• 制品晋级是同一 build artifact 从 test → staging → prod，不再重新打包。测试负责证明该 artifact 在目标环境合格。
• 角色：在 test/staging 对晋级 artifact 跑对应层级测试（非 PR 包而是 release candidate）；签 off QA gate；确认 version 一致、非 rebuild。阻止staging 测 A 包、生产发 B 包。
• 参与晋级 checklist：smoke pass、regression pass、known issue 清单、rollback artifact 已就绪。CI 里 artifact digest 绑定，测试报告引用 digest 可追溯。

👔 Raina面试官： 紧急 hotfix 跳过 staging 行吗？

🙋 候选人：

• 极少数行，要等价验证：最小 smoke + 监控加强 + 快速 rollback。
• 测试不是拦 hotfix，是定义最低验证条和 post-release 补测。每次 skip 要 postmortem 看流程是否改进。

流水线失败时，怎么快速判断是测试问题还是构建问题？

👔 Raina面试官： CI 流水线红了，你怎么快速判断是测试挂了还是构建/环境问题？

🙋 候选人：

• 我有一套从外到内、先环境后代码的排查顺序，通常几分钟能定位大类。
• 第一步看失败阶段：compile/build 阶段挂——大概率是依赖、编译、Docker 镜像或配置问题，跟测试脚本无关。test 阶段挂——再往下看。第二步看失败模式：如果是大面积、多 job 同时失败，优先怀疑环境（DB 连不上、服务未就绪、密钥过期）；如果只有某一个 suite 或新增 case 失败，更像测试或代码回归。
• 第三步本地复现：同一 commit checkout 下来跑失败用例。本地也挂且是断言失败 → 测试或业务 bug；本地通过但 CI 挂 → 环境差异（时区、数据、并行竞争）。第四步看最近变更：git log 里最后是改了 Dockerfile 还是改了测试脚本，往往一眼能对上。

👔 Raina面试官： 有没有更省事的自动化手段？

🙋 候选人：

• 有。分阶段门禁 + 失败分类标签：build、deploy、smoke、regression 拆开，哪段红就进哪段的 runbook。
• CI 里加 pre-test health check（ping 依赖服务、检查 schema 版本），health check 失败直接标 environment 不让测试背锅。历史趋势也有用——某条 flaky case 最近 30% 失败率，一眼就知道是测试稳定性问题不是构建问题。

DevOps 文化下测试工程师的职责边界是什么？

👔 Raina面试官： DevOps 文化下，你觉得测试工程师的职责边界在哪？会不会什么都得干？

🙋 候选人：

• 边界要清晰：测试对质量结果负责，对基础设施会用会提需求，但不替代 DevOps/SRE 做平台建设。
• 测试该做的：定义质量门禁、维护自动化测试资产、参与流水线设计（测什么、何时跑、失败怎么处理）、推动测试左移（单测/契约测试覆盖率）。可以写 CI 里测试相关的 stage 配置、维护测试环境数据，但不必独自扛 K8s 集群运维、监控告警体系搭建。
• DevOps 该做的：环境即代码、部署流水线、可观测性基建、发布策略落地。测试和 DevOps 的交界是 quality gate——测试定标准，DevOps 把 gate 嵌进 pipeline，双方共同维护红灯能不能发版这条线。

👔 Raina面试官： 小团队没人专职 DevOps，测试要不要顶上？

🙋 候选人：

• 可以阶段性承担，但要设上限。
• 比如学会改 Jenkinsfile 里测试 stage、会 docker-compose 起依赖服务，这些是提效技能。但集群扩容、网络策略、安全合规如果也压给测试，长期会两头空。我的做法是：能自助解决 80% 测试环境问题的脚本化能力要有，超出能力圈的基建需求走工单或 OKR 明确分工。