📚 课程目录第2章合规规则基础

2. 合规规则基础

在合规规则测试与自动回归的实战中，第一步不是写用例，而是把“规则”本身看清楚。合规规则并不是一段孤立的校验代码，它通常来自外部监管要求、内部制度或合同条款，经过业务翻译、技术表达、上线运行、变更退役等阶段，最终才成为系统里可执行、可测试的逻辑。测试人员如果只盯着接口返回和页面提示，很容易漏掉规则来源、版本差异和生命周期变化带来的回归风险。因此，本节先建立合规规则的完整认知框架。

一、合规规则的类型与来源

合规规则可以从两个维度理解：一是“管什么”，二是“谁提出”。按管控对象，常见类型包括准入类、额度类、频率类、地域类、身份类、时效类、披露类和反洗钱类等。按来源，则可分为外部监管规则、行业规范、内部制度、合同约定和风控策略。不同类型和来源，决定了规则的稳定性、解释空间和测试优先级。

规则类型	典型来源	示例	测试关注点
准入类	监管办法、内部制度	未完成风险测评不得购买高风险产品	边界值、状态前置条件
额度类	监管限额、合同约定	单日累计转账不超过5万元	累计口径、时间窗口
频率类	风控策略、行业规范	同一手机号1小时内最多发送5次验证码	并发、时钟漂移
地域类	监管要求、业务策略	特定地区用户限制开立某类账户	地区编码、数据同步
披露类	消费者保护规定	产品页面必须展示风险提示	文案完整性、展示时机

从测试视角看，外部监管规则通常刚性最强，变更少但解释严；内部制度和风控策略则更灵活，变更频繁，容易成为自动回归的重点。合同约定往往带有客户差异，需要关注参数化和多租户场景。

二、合规规则的表达形式

规则从“自然语言”到“可执行逻辑”，中间存在多种表达形式。常见的有：制度条款、决策表、规则引擎DSL、SQL校验、代码硬编码、配置项和接口契约。不同表达形式对测试的影响差异很大。

自然语言条款：可读性强，但存在歧义，需要测试人员主动澄清“累计”“同一用户”“自然日”等口径。
决策表：条件与动作清晰，适合组合覆盖，但条件爆炸时用例数量会迅速上升。
规则引擎DSL：可配置、可热更新，测试需要关注规则版本、优先级和冲突。
SQL/代码：执行确定，但变更成本高，容易隐藏边界条件。
配置项：灵活但易被误改，自动回归必须覆盖配置读取和默认值。

示例：一条“单日累计转账限额”规则，在制度中写作“个人客户单日累计转账不得超过5万元”，在规则引擎中可能表达为：

rule "daily_transfer_limit"
when
  $t: TransferRequest(amount > 0)
  $sum: Number() from accumulate(
    TransferRequest(customerId == $t.customerId, status == "SUCCESS"),
    sum($t.amount)
  )
then
  if ($sum + $t.amount > 50000) {
    reject("DAILY_LIMIT_EXCEEDED");
  }
end

测试时必须确认：累计是否包含失败交易、是否按自然日、是否区分渠道、金额单位是元还是分。

三、规则生命周期与自动回归切入点

合规规则不是静态的，它经历“提出—评审—设计—上线—运行—变更—退役”的生命周期。每个阶段都有测试介入点，而自动回归的价值在变更和运行阶段最突出。

在“设计”阶段，测试应建立规则与用例的双向追踪：每条规则至少对应一个正向用例、一个边界用例和一个拒绝用例。在“上线”阶段，自动回归基线应固化规则版本、参数快照和期望结果。在“运行”阶段，一旦规则变更，先做差异影响分析，再触发相关回归集，而不是全量重跑。

四、测试挑战与常见误区

合规规则测试的难点，往往不在技术，而在语义和变更。常见挑战包括：规则口径模糊、规则冲突、优先级不明确、参数分散、版本不一致、数据累计口径复杂、以及外部规则更新滞后。自动回归若只覆盖主流程，很容易在边界和组合场景失效。

误区一：把规则测试等同于接口测试。接口返回正确，不代表规则口径正确，例如“累计”是否跨渠道、是否含退款。

误区二：规则变更后只测变更点。实际上，规则优先级、参数默认值和上下游数据都可能受影响。

误区三：自动回归用例长期不维护。规则退役后用例仍执行，造成误报，最终团队失去信任。

复盘建议：为每条合规规则建立“规则卡片”，记录来源、类型、表达形式、生效时间、参数、关联用例和回归标签。规则变更时，先更新卡片，再触发对应回归集。这样既能保证可追溯，也能让自动回归真正服务于合规风险控制。

理解规则的类型、来源、表达形式和生命周期，是设计高质量测试用例和自动回归策略的前提。只有把规则当作有版本、有来源、有语义的生命体来管理，后续的用例建模和回归实战才不会沦为“碰运气”的点击验证。