# 1. CI/CD 中质量门禁(Quality Gate)的设计原则，如何平衡门禁严格度和交付速度？ A 通过分级门禁（硬阻断+软提示）、按阶段递增严格度、保证可解释与快速反馈，平衡严格度与交付速度 ✓ 正确答案 B 门禁越严格越好，能拦住所有问题 C 门禁只要测试通过即可，无需考虑其他 D 门禁严格度应固定不变
# 2. 质量门禁的核心指标，代码覆盖率、静态分析、测试通过率、性能基线的阈值设定？ A 覆盖率阈值应设得越高越好 B 性能基线一旦设定就永不调整 C 静态分析阈值无需设定 D 应组合覆盖率、静态分析、测试通过率、性能基线等指标，按风险分级、结合历史基线并区分新代码与存量代码设定阈值 ✓ 正确答案
# 3. Flaky Test（不稳定测试）隔离策略，如何检测 flaky 测试（多次运行统计）？隔离机制（quarantine 队列、标签过滤）如何避免阻塞 CI？ A flaky 测试应直接删除，无需处理 B 通过多次运行统计识别 flaky，用 quarantine 队列与标签过滤将其移出主门禁，避免阻塞 CI 并持续跟踪修复 ✓ 正确答案 C flaky 测试对 CI 无影响 D 只能靠人工逐一排查 flaky
# 4. 质量门禁的分级设计，合并门禁、发布门禁与生产门禁的检查项与严格度差异 A 所有门禁的检查项与严格度都应相同 B 合并门禁重快速反馈、发布门禁重全量把关、生产门禁重真实指标观测，越靠近上线越严格 ✓ 正确答案 C 生产门禁不需要任何检查 D 合并门禁应执行最全面的测试
# 5. 测试影响分析(Test Impact Analysis)在 CI 中的应用，如何根据代码变更范围只运行受影响的测试子集？工具支持（Jest --changedSince、pytest-testmon、Bazel 的 affected 测试选择）？ A 影响分析会降低测试覆盖率 B 影响分析无法自动化 C 影响分析必须每次运行全量测试 D 通过代码变更与测试的依赖关系只运行受影响测试子集，工具如 Jest --changedSince、pytest-testmon、Bazel affected 支持，但需全量回归兜底防漏测 ✓ 正确答案
# 6. 并行测试执行(Parallel Test Execution)的设计，测试间依赖识别、共享状态隔离、并行粒度（文件级/用例级/分片级）的取舍？ A 并行测试无需考虑测试间依赖 B 所有测试都可直接并行执行 C 需识别测试间依赖并隔离共享状态，再按文件/用例/分片粒度并行，权衡负载均衡与隔离复杂度 ✓ 正确答案 D 并行粒度越大越稳定
# 7. 测试结果缓存(Test Result Caching)的原理与实践，Turborepo/Jest/Nx 如何基于输入哈希跳过未变更的测试？缓存失效的边界条件？ A 测试结果缓存一定会产生错误结果 B 基于输入哈希，输入未变则复用结果，工具如 Turborepo/Jest/Nx 支持；但需处理环境、依赖、非确定性等缓存失效边界条件 ✓ 正确答案 C 缓存命中无需验证输入一致性 D 测试结果缓存无法缩短 CI 时间
# 8. 门禁失败的可解释性，门禁结果如何关联到具体变更、用例与责任人，缩短定位时间 A 门禁只需显示"失败"即可 B 门禁失败无法定位原因 C 把门禁结果关联到具体变更、用例、堆栈日志与责任人，让失败可追溯可定位，缩短修复时间 ✓ 正确答案 D 可解释性会增加门禁复杂度而无价值
# 9. 硬门禁 vs 软门禁，哪些指标必须阻断、哪些只提示，如何分级设计避免团队博弈？ A 所有指标都应设为硬门禁 B 硬门禁可以不解释失败原因 C 软门禁没有意义 D 构建失败、测试失败、高危安全等应设硬门禁阻断，改进类指标设软门禁提示，并通过透明规则、可解释、闭环与规则评审避免博弈 ✓ 正确答案
# 10. 门禁的时间预算与反馈速度，门禁检查链路的耗时预算如何分层设计，慢门禁如何拆分为异步检查？ A 所有门禁检查都应同步执行以保证完整 B 按"越快越靠前"分配耗时预算，同步门禁跑快速检查，慢检查（全量 E2E、性能、安全）拆分为异步兜底，兼顾反馈与完整 ✓ 正确答案 C 慢门禁应直接删除 D 时间预算与反馈速度无关
# 11. 门禁的增量基线策略，新代码与存量代码的覆盖率、静态分析阈值如何差异对待，如何防止存量债务永久豁免？ A 新代码与存量代码应使用完全相同的阈值 B 存量代码质量无需任何约束 C 新代码执行严格阈值、存量代码设不退化底线，并通过债务台账与分阶段收敛防止存量债务永久豁免 ✓ 正确答案 D 新代码可以随意放宽阈值
# 12. 质量门禁的演进，从固定阈值到基于历史数据的动态门禁？ A 固定阈值门禁是最优的、无需演进 B 动态门禁完全不需要人工判断 C 动态门禁基于历史数据建立相对基线并自动更新阈值，比固定阈值更贴合实际、减少僵化与博弈 ✓ 正确答案 D 历史数据无法用于门禁设计
# 13. Monorepo 中的质量门禁设计，如何为多包/多项目仓库设计差异化的覆盖率要求和门禁策略？变更范围感知的门禁触发？ A Monorepo 中所有包都应使用相同的门禁标准 B Monorepo 必须全量执行所有门禁 C 应为多包设置差异化覆盖率与门禁策略，并基于依赖图实现变更范围感知的触发，只检查受影响包 ✓ 正确答案 D 变更范围感知无法实现
# 14. 门禁的维护，误报与噪音？ A 误报不影响门禁可信度 B 门禁告警越多越好 C 误报与噪音会损害门禁可信度导致团队绕过，应通过校准规则、分级告警、修复 flaky、建立维护闭环来降低误报与噪音 ✓ 正确答案 D 误报是无法避免的，无需处理
# 15. 门禁的度量，通过率与拦截缺陷？ A 门禁通过率越高越好 B 应组合通过率、拦截缺陷数、误报率、逃逸率等指标，全面评估门禁有效性与可信度并持续改进 ✓ 正确答案 C 拦截缺陷数越多就说明门禁越好 D 门禁度量没有价值
# 16. 门禁的豁免流程，如何平衡紧急发布？ A 通过受控豁免（授权、可追溯、分级、带补偿、事后复盘）为紧急发布开通道，同时守住质量底线 ✓ 正确答案 B 紧急发布时完全绕过门禁即可 C 门禁绝不允许任何豁免 D 豁免后无需任何跟踪
# 17. 质量门禁与特性开关的配合，未完成功能如何不阻塞门禁，同时保证不误放未成熟代码？ A 未完成功能必须等完成才能合入主干 B 门禁应拦截所有未完成功能 C 特性开关可以默认开启未完成功能 D 用特性开关解耦"合入"与"发布"，未完成功能默认关闭通过门禁，门禁校验 flag 默认关闭与配置一致性，防止误放 ✓ 正确答案
# 18. 门禁数据的沉淀与复盘，门禁拦截的缺陷如何反哺测试用例与代码规范？ A 沉淀拦截缺陷并复盘，反哺补充测试用例与固化代码规范，形成"发现→吸收→预防"的闭环 ✓ 正确答案 B 门禁拦截缺陷后无需记录 C 门禁数据只用于报告 D 复盘缺陷无法改进测试
# 19. 门禁规则的配置治理，阈值与规则的修改如何走评审与审计，避免为上线临时放宽门禁被滥用？ A 门禁规则可被任何人随时修改 B 临时放宽门禁无需审批 C 门禁规则一旦设定就不可修改 D 门禁阈值与规则的修改应走评审、审计、版本化与限期特批流程，防止为上线临时放宽被滥用 ✓ 正确答案
