# 1. Feature Flag（功能开关）的测试策略，如何验证开关开/关两种状态下的系统行为？ A 开关测试与功能测试无关，属于运维配置工作 B 只需要测试开关开启状态下的功能即可，关闭状态是默认行为无需测试 C 开关测试必须覆盖开/关两种状态、默认值、缓存失效与切换边界，并纳入自动化回归 ✓ 正确答案 D 只要开关默认值为关闭，就不存在任何线上风险
# 2. Feature Flag 的组合爆炸问题，多个 Flag 同时存在时如何设计有效的测试组合？ A 对所有 Flag 做 2^n 次全组合穷举测试 B 只测试组合数量最少的情况，减少工作量 C 放弃组合测试，只测单个 Flag 的开和关 D 采用成对组合（Pairwise）方法，并对有依赖关系的 Flag 做重点全组合覆盖 ✓ 正确答案
# 3. Feature Flag 的生命周期测试，如何检测"僵尸 Flag"（已上线但未清理的开关）？ A 可通过静态代码扫描、运行期评估日志与配置审计三方比对来发现并清理 ✓ 正确答案 B 僵尸 Flag 无害，无需检测和清理 C 只能通过人工 review 代码发现，无法自动化 D 僵尸 Flag 只存在于 Flag 平台配置中，与代码无关
# 4. Feature Flag 平台（LaunchDarkly/Unleash/OpenFeature）的测试集成，如何验证 Flag 评估逻辑的正确性？ A 只验证 SDK 是否能拉取到配置即可 B 只依赖真实生产环境黑盒测试，不写任何自动化 C 用测试桩验证拦截逻辑，再与真实平台联调核对分群/百分比/默认值等规则 ✓ 正确答案 D 评估逻辑是平台内部实现，无法也不需要测试
# 5. Feature Flag 的灰度发布测试，如何验证百分比放量、用户分群和地域定向的正确性？ A 只需确认开关能打开即可 B 只在地域维度上验证一次 C 只验证白名单用户能否命中 D 命中率接近配置比例、同时同一用户多次评估结果一致 ✓ 正确答案
# 6. Feature Flag 的性能影响测试，Flag 评估的延迟和缓存策略如何验证？ A 缓存命中路径延迟虽高，但无需优化 B Flag 评估永远走远程拉取，性能最准 C 性能测试只关注功能正确，与缓存无关 D 应分别测量本地缓存命中与远程拉取两条路径的延迟，并验证缓存失效与故障降级的兜底 ✓ 正确答案
# 7. Feature Flag 的多维度（用户/灰度/百分比）组合如何设计正交测试矩阵？ A 正交表用少量用例覆盖任意两两因子的组合，再对高风险依赖补充用例 ✓ 正确答案 B 正交矩阵能覆盖所有因子组合，无需补充用例 C 正交矩阵与全组合等价，没有节省成本 D 正交矩阵只能用于单维度，不适用于多 Flag
# 8. Flag 配置变更如何纳入测试范围，配置审计与快速回滚的验证手段有哪些？ A 回滚后需要重启服务才能生效 B 线上改 Flag 配置无需测试，随时可改 C 配置审计只记录操作人即可，无需记录变更前后值 D 配置应纳入版本管理与审计，并验证一键回滚的即时性与幂等性 ✓ 正确答案
# 9. Flag 之间的依赖与联动，父子开关、级联开关与互斥开关的测试设计，开关组合状态如何保证覆盖？ A 只测各自独立开关，忽略联动 B 互斥开关同时开启也没关系，系统自动处理 C 对依赖相关的 Flag 做合法/非法组合全覆盖，并校验配置侧非法组合 ✓ 正确答案 D 只测父开关，子开关无需测试
# 10. Flag 配置的环境一致性，开发、测试与生产环境间 Flag 默认值与人群差异如何管理，环境漂移如何检测？ A 各环境配置完全独立，无需管理 B 以生产配置为基线进行比对，显式记录差异，并用发布门禁校验一致性 ✓ 正确答案 C 只要默认值一致即可，人群规则无需关心 D 环境漂移无法检测，只能人工抽查
# 11. Feature Flag 的安全测试，如何防止通过 API 探测未发布的 Flag 状态？ A 让 Flag 名称保持原样，便于排查 B 只对部分接口做鉴权，其余放开 C 对管理/SDK 端点做鉴权与密钥校验，收敛响应与日志中的 Flag 敏感信息，并主动渗透探测 ✓ 正确答案 D 未发布 Flag 无需保护
# 12. 长期存在的 Flag 产生的"死代码"如何通过测试覆盖发现并清理？ A 直接删除所有 Flag 相关代码，无需验证 B 用静态引用扫描与覆盖率分析定位死分支，清理后跑全量回归确认无引用残留 ✓ 正确答案 C 死代码不影响系统，无需清理 D 只删除 Flag 配置，不删代码
# 13. Flag 与 A/B 测试的关系？ A 两者完全等价，可以互换 B A/B 测试不需要随机分组 C Flag 负责功能发布与流量控制，A/B 负责随机分流与效果度量，二者常协同使用 ✓ 正确答案 D Flag 必须做显著性检验才能使用
# 14. Flag 配置推送链路的测试，SDK 拉取、网络中断、版本落后与本地默认值如何验证？ A 只验证 SDK 能成功拉取配置即可 B 本地默认值无关紧要 C 网络中断时直接抛错即可 D 网络中断走缓存、无缓存走默认值、版本落后与非法配置安全降级，且不阻塞业务 ✓ 正确答案
# 15. Flag 值的类型与校验测试，布尔/字符串/JSON 值的合法性校验与非法值降级？ A 直接抛异常，让业务崩溃引起注意 B 把非法值作为合法值返回 C 忽略非法值，继续使用上一份配置并静默 D 安全降级为对应类型的默认值，记录告警且不污染缓存 ✓ 正确答案
# 16. Feature Flag 的审计与合规，谁在何时改了什么 Flag、生效范围如何追溯？ A 完整记录操作人、时间、变更前后值、生效范围，日志不可篡改且权限变更也可追溯 ✓ 正确答案 B 只记录谁改过 Flag，不记录值和范围 C 审计日志可被覆盖或删除，只要有人记录即可 D 任何人都能改生产 Flag，只要事后补记录
# 17. 无 Flag 时代的切换改造测试，老系统去开关化的灰度切换与回退如何验证？ A 只验证新逻辑即可，老逻辑无需保留 B 用差分测试验证新旧逻辑等价，并演练一键回退后行为与数据一致 ✓ 正确答案 C 回退会破坏数据一致性，无法验证 D 改造后无需测试，直接全量放量
# 18. Flag 切换的原子性测试，并发请求跨开关切换瞬间的新旧逻辑混用如何验证，如何保证行为一致？ A 请求处理过程中多次读取开关值，取最新值 B 切换时必须重启服务 C 在请求入口一次性读取开关值并贯穿整个请求生命周期，用并发+切换压测验证无混用 ✓ 正确答案 D 新旧逻辑混用不影响正确性
