地区功能开关测试：国家配置与灰度规则验证

地区功能开关测试要回答的不是“页面有没有变”，而是“这个请求命中了哪条规则、命中的证据是什么”。做法是先定义 Flag 的目标条件与默认行为，再按开放、限制、默认三组地区各跑一遍同一用例，最后核对命中日志和灰度版本。本文只用自有测试环境，代理 IP 仅用于切换出口 IP 地区。

先写清 Flag 的命中条件和默认值

每个 Flag 写清四件事：目标地区、目标用户属性、灰度比例、默认值。默认值必须明确——没命中任何规则时是开还是关，不能靠“应该不会命中”来假设。

默认值写错的典型表现是“该关的却开着”：规则没命中，前端仍从缓存或旧配置读到开启值。目标条件要写成可判定的表达式，例如“地区属于 DE/FR 且账号为付费用户”；条件含糊，测试时就会出现“看起来开了但日志没命中”的争议。地区分组按产品实际开放的名单来切，不要照搬代理服务商的地区列表。

开放、限制和默认地区分别验证什么？

开放组：地区在目标名单内，预期功能开启。限制组：地区不在名单内，预期关闭或降级。默认组：无任何规则命中，预期走默认值。

默认组拆成三个独立用例，并按 Flag 配置预先写明预期值：

1. 固定账号属性，只换到不在名单的地区，验证地区规则未命中后的默认分支；
2. 固定地区，只移除一个用户属性，验证属性缺失时的配置回退；
3. 在测试环境模拟灰度桶缺失或求值异常，验证异常分支、日志和告警。

每条用例只改变一个条件；异常时是否关闭、返回错误或采用默认值，以该 Flag 的风险策略为准。

三组用同一账号状态、同一操作步骤、同一构建，只改地区出口；否则命中差异分不清是地区导致还是账号导致。每组的预期要提前写死：开放组看“功能出现 + 日志 hit”，限制组看“功能隐藏或降级提示 + 日志 no_match”，默认组看“日志显示默认 + 页面与默认值一致”。基础对照固定一种代理类型；只有怀疑 CDN 或风控按出口类型差异化时，固定地区和其他条件另开代理类型对照，不与地区规则结果混在一起。

地区、账号和灰度条件冲突时怎么判断？

当一个请求同时满足多条规则时，要预先定义优先级：地区优先、账号优先还是灰度桶优先。优先级不同，边界用户看到的功能就不同。举例：用户在 DE、账号是免费用户、却又落在 10% 灰度桶里——地区规则说开、账号规则说关、灰度规则说开，最终结果必须能由优先级唯一推出，而不是碰运气。

回退路径逐项按 Flag 的风险策略验收：安全敏感功能通常采用 fail closed；非关键功能可按已配置默认值回退；灰度桶异常按平台规则处理。每种路径都要检查求值结果、日志和告警，不能把所有异常统一假设为关闭或开启。优先级和回退的判定参照代理 IP 测试应该测什么。

用哪些日志和页面证据确认命中结果？

命中证据至少三样：开关求值日志、响应中的功能字段、页面上的版本标记。三者一致才算验证通过；只有页面“看起来开了”，无法证明命中。

灰度版本要记录比例、生效时间和分桶方式。百分比不是“随机开”，同一用户应固定落在同一桶；换设备或清 Cookie 后分桶变化可能符合匿名标识设计，需先确认实际分桶键。验证比例用区分重复性测试与比例测试。先锁定实际分桶属性、context key/kind 和配置版本；匿名标识随 Cookie 变化可能导致重新分桶。预先定义比例容差和统计方法，重复同一批键不会增加独立样本，也不要求人数恰好等于配置比例。将规则 ID、求值上下文、配置版本、命中条件和结果保留在同一张测试表中。

下表三行分别是开放、限制、默认组，每轮另记出口 IP 归属地与代理类型，第三行“默认关却开启”就是默认值或缓存问题：

读法是先看“预期/实际”是否一致，再对“证据”列：实际与预期不符且日志显示 no_match，问题在默认值或缓存；日志显示 hit 但页面没变，问题在前端渲染或缓存。

FAQ

地区与用户属性冲突听谁的？

按预先定义的优先级执行，不能临时改。冲突场景要单独建用例，记录最终命中的规则和证据。

灰度百分比怎么验证？

用固定用户集重复请求，看命中比例是否接近配置值，且同一用户结果是否一致；比例对但用户漂移，说明分桶键不合适。

关 Flag 后缓存和页面残留怎么处理？

先按 SDK 的缓存策略验证关闭开关后的传播和刷新时间，再用清理缓存辅助定位；清缓存不应成为默认验收前提。

灰度验证要按代理 IP 地区一一对应吗？

不用一一对应，按规则里的地区名单各取一个代表即可；同一地区固定一种代理类型，避免出口识别差异干扰命中判断。

需要确认可用出口地区，可查看全球代理支持的出口地区。