# 1. 金丝雀发布（Canary Release）的测试验证，如何设计指标对比（错误率、延迟、业务指标）来判断金丝雀健康？ A 金丝雀版本无需对比，直接看是否崩溃 B 只看错误率一个指标，超过阈值即回滚 C 只凭人工观察新版本是否报错 D 金丝雀组与基线组同口径、同时窗对比，结合技术指标与业务指标，用显著性与阈值分级判定 ✓ 正确答案
# 2. 蓝绿部署（Blue-Green）的测试，如何验证切换瞬间的零停机和数据一致性？ A 切换时直接切 DNS，不做预热 B 只要切换快就一定是零停机 C 持续打流验证无中断，并验证新旧版本共享数据源与会话状态时的数据一致性及回切能力 ✓ 正确答案 D 数据一致性无法验证，只能切换后人工检查
# 3. 渐进式交付（Progressive Delivery）的自动化回滚，如何定义回滚触发条件并验证回滚正确性？ A 回滚触发条件只需看一个指标瞬时值即可 B 用可量化指标+连续恶化/健康失败定义触发条件，并验证回滚的及时性、幂等性与回滚后指标恢复 ✓ 正确答案 C 回滚只能人工执行，无法自动化 D 回滚后无需验证系统是否恢复
# 4. 渐进式交付中流量切分的正确性测试，分流一致性、用户粘性与扩量后的重新分桶问题 A 同一用户在不同请求间进入不同组是正常的 B 扩量后用户重新分桶是预期行为，无需关注 C 只验证流量比例接近即可，无需关心用户粘性 D 需验证同一用户粘性一致、扩量后不产生组别漂移、各桶分布均匀 ✓ 正确答案
# 5. A/B 测试的统计验证，如何确保实验组和对照组的流量分配正确？如何检测样本污染？ A 只验证两组用户数大致相等即可 B 样本污染无法检测，只能接受 C 验证分组随机均衡、同一用户不跨组、分组标识稳定，并通过属性分布与唯一性检测污染 ✓ 正确答案 D 用户属性变化导致跨组是正常现象
# 6. 多版本并行运行时的兼容性测试，新旧版本共享数据库/消息队列时的数据格式兼容如何验证？ A 只保证新版本能解析新数据即可 B 并行版本必须做版本统一，否则必然出错 C 数据格式兼容无法测试 D 验证新增/变更/废弃字段的兼容，让新旧版本都能安全解析同一数据，并测试 Schema 演进 ✓ 正确答案
# 7. 渐进式交付，金丝雀、灰度与逐步放量？ A 金丝雀是最小流量探路，逐步放量是阶梯式扩大流量，灰度是整体渐进框架，三者协同构成渐进式交付 ✓ 正确答案 B 金丝雀是全部流量同时切换 C 三者完全等价，只是叫法不同 D 逐步放量不需要观测指标
# 8. 多地域/多数据中心渐进发布的测试差异，区域配置同步、跨区数据一致性与回滚范围 A 只有一个区域发布，其它区域无需处理 B 区域配置同步、跨区数据最终一致性、回滚范围（单区/全量）可精确控制 ✓ 正确答案 C 回滚只能全量进行，无法单区操作 D 各区域数据必须强一致，不允许异步
# 9. 渐进式交付与 A/B 实验的协同，功能开关+实验分流的双开关矩阵如何测试？ A 两个开关完全独立，无需关注交互 B 建模开关×实验的组合矩阵，验证开关关闭时实验被抑制、数据口径只统计开关开启且入组的流量 ✓ 正确答案 C 实验分组不受开关状态影响 D 只需测开关开启+实验的情况
# 10. 多版本并存的数据库兼容，渐进发布期间的 Schema 演进与回滚数据兼容如何验证？ A 采用扩展式演进（新增字段有默认值、类型可互转），并验证回滚后旧版本能正确读取新 Schema 数据 ✓ 正确答案 B 回滚后旧版本无法读取新数据也没关系 C Schema 演进与代码发布无关 D 一次性直接改 Schema 类型，无需兼容
# 11. 金丝雀的流量阶梯与观测设计，放量比例阶梯、每档停留时长与指标观察窗口如何确定，指标恶化如何分级处理？ A 观察窗口与样本量无关 B 每档停留时长越短越好，尽快放量 C 按阶梯放量，每档停留时长覆盖完整业务周期以保证样本量，并按绿/黄/红分级处理指标恶化 ✓ 正确答案 D 指标恶化一律立即回滚，无需分级
# 12. 金丝雀发布的业务指标对比，除错误率与延迟外，转化率、收入等业务指标如何纳入放量决策，数据口径如何对齐？ A 同口径、同时窗、同人群对齐对比，结合显著性判断并用基线组排除外部干扰 ✓ 正确答案 B 直接看业务指标高低即可，无需对比 C 业务指标只作为参考，不参与决策 D 业务指标波动大，无法用于放量决策
# 13. Feature Flag 与 A/B 测试的灰度对比框架 A Flag 和 A/B 各用一套独立分流，互不相关 B 框架只负责放量，不负责度量 C 灰度对比无需考虑指标口径一致性 D 用统一的分流标识、指标口径与回滚机制，让开关控制与实验度量协同并对齐 ✓ 正确答案
# 14. 金丝雀发布测试数据收集与回滚触发器设计 A 数据收集须覆盖金丝雀/基线两组同口径指标，触发器用阈值+恶化窗口判定，并测试防误触发与防漏触发 ✓ 正确答案 B 触发器只依赖人工判断，无需数据 C 数据延迟不影响回滚及时性 D 数据收集与触发器互不相关
# 15. 渐进式交付工具（Argo Rollouts/Flagger）的测试集成，如何验证分析（Analysis）模板的正确性？ A 模板语法正确即可，无需验证决策 B 校验模板结构，注入正常/临界/恶化数据验证判定，并做端到端集成验证放量与回滚 ✓ 正确答案 C 模板错误只会导致放量慢，无实际风险 D 模板只影响展示，不影响放量
# 16. 渐进式交付的平台与流程，灰度发布、金丝雀与按用户分组的发布策略如何落地，需要哪些平台能力与回滚机制支撑？ A 只要平台能切流量即可 B 分流、指标观测、门禁自动化、回滚机制与审计可视化等平台能力，配合标准放量流程 ✓ 正确答案 C 回滚机制无需平台支持，纯人工操作 D 按用户分组无需平台支持
# 17. 金丝雀发布的指标采样偏差，流量不均、样本量不足时如何避免误判？ A 看指标瞬时值，波动即回滚 B 确保样本量充足、用置信区间与显著性判断、按流量归一化对齐、多指标联合 ✓ 正确答案 C 样本量不足时直接按比例放大判断 D 指标波动大时应立即回滚，避免风险
# 18. 渐进式交付的终止条件测试，全量放量 vs 回滚的判定指标与人工兜底流程？ A 明确全量/回滚的判定指标，用三态数据验证判定准确，并验证人工兜底可覆盖自动判定且可审计 ✓ 正确答案 B 人工兜底无需权限与审计 C 终止条件不需要测试，发布时临时判断 D 全量与回滚只靠人工经验决定
# 19. 渐进式交付的回滚演练，定期演练数据回滚、路由回切与缓存清理，演练发现的问题如何修复与再验证？ A 定期演练数据回滚、路由回切与缓存清理，发现问题修复后再演练验证，直至回滚路径可靠 ✓ 正确答案 B 演练只需要验证路由切换即可 C 演练一次通过后就无需再演练 D 缓存清理与回滚无关
