作者简介：

• 樊诗呈，来自货拉拉/技术中心/质量保障部，测试专家，主要负责货拉拉风控领域的质量保障和效能建设工作。
• 张小宁，来自货拉拉/技术中心/质量保障部，资深测试工程师，主要负责实时风控的质量保障和效能建设工作。

1. 背景与挑战

随着货拉拉业务的迅猛扩展，识别和规避风险的能力变得尤为关键。在货拉拉，我们的风控系统通过深入洞察业务的多元判断策略，每日对亿级流量进行严密的监测，精准识别并果断阻断任何潜在的高风险行为，确保我们的业务安全稳健地发展。然而，风控策略判定【注①】的准确性，取决于风控所获取的特征【注②】信息，这些特征信息源自上游服务向风控传入的原始字段信息，以及风控对已有字段进行清洗和补全【注③】的信息。为了确保风控策略能有效地识别和规避业务风险，防止策略误判和漏判，我们首要的任务就是保障风控特征的质量。

注①：风控策略判定即为风控系统针对本次接收到的请求中的各种特征字段信息进行组装，将组装后的特征字段信息进行条件匹配，并根据条件匹配的结果判断是否进行下一步动作的能力。
注②：特征即风控获取到的各种辅助于策略条件判断的信息，它们来源于本次调用，上游请求风控消息中的字段信息，以及在这些信息的基础上，通过服务调用、代码函数处理、统计数据、条件匹配等方式，进行清洗和补全所获取到的字段信息。
注③：补全即在现有的字段信息基础上，通过服务调用、代码函数处理、统计数据、条件匹配等方式获取更多字段信息的动作。

1.1 特征质量保障的重点

根据需求中风控代码和数据的变更方式不同，风控的需求可分为三类，每种类型的需求测试的侧重点也会有所不同。

• 风控代码存在变更
  在风控代码有变更的情况下，风控系统存在功能特征的变更。此类需求中，特征的质量保障主要围绕【特征改动的影响范围】和【特征逻辑处理的正确性】两个方面。

• 风控代码不存在变更，风控配置存在变更
  在风控代码无变更的情况下，风控系统无功能特性的变更。因为配置是灵活可变的，只要确保依赖数据准确，即可保障此次变更风险可控。此类需求中，特征的质量保障主要围绕【特征改动的影响范围】和【特征取数的准确性】两个方面。

• 风控代码和配置不存在变更，新业务接入风控
  风控不存在任何变更，但风控线上策略判定的准确性，强依赖接入业务数据的准确性。此类需求中，特征质量保障主要围绕【特征取数的准确性】进行考虑。

1.2 特征质量保障的难点

我们已经明确了特征质量保障的重点主要在三个方面，即识别特征改动的影响范围、验证特征逻辑处理的正确性和保障特征取数的准确性。然而，由于风控系统的特性、风控测试的局限性和测试资源的稀缺，我们在保障特征质量方面仍面临以下挑战：

• 在识别特征改动的影响范围上，风控测试没有抓手

  • 策略、特征和补全之间的依赖关系盘根错节，缺乏可视化的呈现使得梳理其影响范围变得既耗时又易于遗漏。
  • 特征变更牵一发而动全身，导致测试回归工作量大，并且效率低。

• 在验证特征逻辑处理的正确性上，风控测试能效较低

  • 风控获取的特征数据往往依赖各种外部数据源，想要构造符合条件的特征数据，需要额外的学习成本。
  • 风控系统处于交互链路的下游，想要对风控系统进行测试，需要从上游业务进行触发。
  • 风控特征配置繁多，测试在回归老功能时，往往需要重新了解旧特征的构造方式。

• 在保障特征取数的准确性上，风控测试相对被动

  • 风控系统本身不对上游数据质量进行合规性校验，并且风控生产核心策略不会在测试环境配置，会导致上游数据质量问题往往上线后才能发现。
  • 因风控处于交互链路下游，且对接方众多，当上游业务改动时，风控测试难以及时获知上游字段错漏问题。

2. 方案与目标

针对特征保障的重点和难点，我们采用了三种解决方案：

• 识别特征改动的影响范围：梳理风控系统数据间的关联，进行可视化呈现，并通过精准测试提高测试效率。

• 验证特征逻辑处理的正确性：标准化特征数据的构建，降低造数成本，提高测试效率。

• 保障特征取数的准确性：建设拦截上游不合规数据的能力，从被数据质量问题影响，转化为主动发现拦截问题。

为了达成上述目标，我们开发了特征测试平台，平台基于风控判责、实时风控、数据工厂、mock 平台和风控需求的数据，建设了精准测试、场景测试和全域风控的能力，使我们能够在需求的各个阶段进行质量和效率的提升。同时，全域风控也让我们能够全程保障风控的数据质量。

3. 风控特色的精准测试

风控判定结果取决于风控策略的条件判断，而风控策略的条件判断又高度依赖特征字段信息，这些特征可能又引用其他特征信息或补全动作。因此，当需求中涉及特征的新增或改动时，我们需要评估所有引用该特征的数据是否会受影响。由于风控判责系统无法直接展示特征之间的依赖和引用关系，通常需要通过人工统计或编写复杂的 SQL 来检索特征的依赖，以评估影响和测试范围。从测试角度来看，每个需求平均需要 4 小时 进行回归和影响范围梳理，以及设计测试用例，同时也需要 4 小时 进行回归测试。这个过程中也容易出现遗漏或错误。
为了更准确地识别和验证特征改动的影响，提升测试效率，我们构建了一套能展示策略、特征、补全之间依赖和引用关系的全局关系网。并且我们通过实现对数据和代码变更的监测，结合场景化测试的能力，建设了具有风控质量保障特色的精准测试能力。

3.1 全局关系网

全局关系网的建立，需要从解析风控数据开始。我们通过接口调用，拿到所有的策略、特征和补全信息，对这些信息进行单向解析，并找到这些信息之间的引用关系，从而建立双向数据引用关系，保存在数据库中。

3.1.1 双向引用树的绘制

我们期望在前端页面上，能直观的呈现检索节点的双向引用关系，为此我们选择在前端绘制包含以下三个部分的关系树：

• 中心节点，即检索节点，展示当前检索节点的信息；

• 左子树，即被引用关系树，展示当前节点被其他节点引用的关系【... <- 祖 <- 父 <- 检索节点】；

• 右子树，即引用关系树，展示当前节点引用其他节点的关系【检索节点 -> 子 -> 孙 -> ...】。

为此，我们选用了支持 Vue2、Vue3、React 的关系数据展示组件库 relation-graph。使用 relation-graph 绘制双向树，需要创建 nodes 节点 和 lines 连线的数组，用于定义节点，以及各节点之间的关系。同时，为了明确左子树和右子树展示的信息和层级，我们还需要定义好层级区间，将中间节点定义为 0，左子树的区间是 (-∞,0)，右子树的区间是 (0,∞)。
树节点的追加【代码已简化，只保留核心逻辑】：

/**
 * 追加节点
 * @param id 节点id
 * @param hierarchy 节点层级
 * @param nodeType 节点类型 dataCompletion、feature、strategy
 * @param relateType 查询层级类型 0 子节点、1 父节点
 */
let nextHierarchy = hierarchy + 1;
let preHierarchy = hierarchy - 1;
let currentHierarchy = relateType === 0 ? nextHierarchy : preHierarchy;
let newJsonData = { nodes: [], lines: [] };
let node = {
  id: 'feature-' + currentHierarchy + item.id,
  data: { hierarchy: currentHierarchy },
};
let line = {
  from:
    relateType === 0 ? id : 'feature-' + currentHierarchy + item.id,
  to:
    relateType === 0 ? 'feature-' + currentHierarchy + item.id : id,
  isReverse: relateType !== 0,
};
newJsonData.nodes.push(node);
newJsonData.lines.push(line);
// 追加节点
this.$refs.seeksRelationGraph.appendJsonData(newJsonData, (seeksRGGraph) => {});

3.1.2 检索关系网

建设了全局关系网之后，我们可以在特征测试平台，检索任意 策略、特征、补全，并找到其关联的节点关系。检索关系网展示如下：

通过全局关系网的建立，和检索关系网的能力，我们可以检索任意节点，展示受到影响的数据，从而 快速识别影响范围，保障测试用例设计不遗漏。让回归用例梳理的时间从 4 小时 降低到 5 分钟。

3.2 精准测试

尽管我们已经建立了全局关系网，但变更识别仍然是风控测试的难题。有时，由于意料之外的配置变更或未被通知的代码修改，我们的测试可能无法及时识别和进行回归验证。为了解决这个问题，我们考虑采用精准测试的方法。
在大多数情况下，精准测试依赖于源代码的变更监测，并结合相关的分析算法来确定变更的影响范围，从而降低变更风险，提升测试效率。然而，对于风控特征而言，代码变更的精准测试只是其中一面，我们还需要拥有数据变更的精准测试能力。因此，我们通过建立全局关系网，监测数据和代码的变动，并结合场景化执行的能力，探索了一条具有风控质量保障特色的精准测试之路。

3.2.1 数据变更监测

对于数据变更的监测，通常的做法是由变更方主动回调，或者由监测方轮询识别。主动回调的优势是快速、实时，然而风控判责系统本身并不支持这种变更通知的方式，采用这种方案，系统需要针对性改造。而监测方轮询识别的方式，虽然不够实时，但对系统的侵入性小，实现成本也较小。不是回调能力不够好，只是轮询更具性价比，所以我们最终采用的方案，是由特征测试平台主动轮询风控判责系统的数据接口，并根据对比 updated_at（更新时间）字段判断数据是否有变更。
数据变更监测【代码已简化，只保留核心逻辑】：

/**
 * 根据查询风控接口的数据，查询特征测试平台的数据表
 * 1.根据风控数据ID查询，如果查询有值，则意味着此记录已存在，如果无值，则意味着此记录为新增数据；
 * 2.如果记录已存在，则对比更新时间，如果更新时间不相等，则意味着此记录为修改数据；
 */
Integer zeusId = zeusApiModel.getZeusId();
ZeusApiModel findZeusApi = findByZeusId(zeusId);
// 如果查询有值
if (findZeusApi.getId() != null) {
    // 如果更新时间相等，则跳过
    if (zeusApiModel.getZeusUpdate().equals(findZeusApi.getZeusUpdate())) {
        return true;
    }
    // 不相等则更新
    zeusApiModel.setId(findZeusApi.getId());
    return false;
} else {
    // 如果查询无值，则新增
    addZeusApi(zeusApiModel);
    return false;
}

3.2.2 代码变更监测

在风控判责系统中，特征信息依赖补全动作，而补全动作的逻辑则是通过代码实现。要识别代码变更对特征的影响，所需要做的就是监测补全代码的变更。为此，我们想到了增量代码扫描，在货拉拉，我们已有一套基于 jacoco 的增量代码扫描平台。该平台会在服务部署后，自动扫描代码变更，获取变更的类和方法，并对执行代码进行染色。该平台的原理，本文不进行赘述。我们特征测试平台做所的工作，就是将补全和代码进行配置关联，同时定期扫描增量代码报告，根据报告的变更类和方法匹配到相应的补全信息。
根据 jacoco 增量代码 url 获取类和方法地址【代码已简化，只保留核心逻辑】:

public List<String> getClassPathByUrl(String url) {
    // 增量代码的类地址集合
    List<String> classList = new ArrayList<>();
    // 发送请求，获取html数据
    String html = sendGet(url);
    Document doc = Jsoup.parse(html);
    // 解析出title，初始title为分支名称，后续title为包地址
    String title = "";
    String classTitle = "";
    if (doc.title().contains("release")) {
        title = doc.title();
    } else {
        classTitle = doc.title();
    }
    // 获取类名
    Elements classElementsList = doc.select("a.el_class");
    for (Element classNode : classElementsList) {
        classList.add(classTitle + "." + classNode.text());
    }
    // 获取包名，并继续请求
    // 此处有嵌套循环，请注意
    Elements packageElementsList = doc.select("a.el_package");
    for (Element packageNode : packageElementsList) {
        String urlNext = url + "/" + packageNode.text() + "/index.html";
        classList.addAll(getClassPathByUrl(urlNext));
    }
    return classList;
}

3.2.3 被引用关系树的遍历

现在，我们已经拿到数据变更和代码变更所影响的风控特征或补全，接下来需要做的，就是遍历双向引用树中的左子树，即被引用关系树，拿到我们所需测试的特征或补全场景。在这里，我们使用的是广度优先搜索的算法来实现遍历。

广度优先搜索即层序遍历，按照树的层次结构一层一层遍历，每个节点只访问一遍。

我们利用 Queue 先进先出的特性，LinkedHashMap 有序遍历和 Key 值唯一的特性，实现被引用关系树的广度优先遍历。
以下图节点关系为例。遍历步骤如下：

1. 遍历检索 节点 A，从 links 集合里找到 from 节点 B 和 节点 C，将 B、C 插入队列，queue(B,C)，同时将 节点 A put 进 LinkedHashMap 中；

2. 节点 B 出队，从 links 集合里根据 to B，找到 from 节点 D 和 节点 E，将 D、E 插入队列，同时将 节点 B put 进 LinkedHashMap 中；

3. 节点 C 出队，从 links 集合里根据 to C，找到 from 节点 E 和 节点 F，将 E、F 插入队列，同时将 节点 C put 进 LinkedHashMap 中；

4. 节点 D 出队，由于 links 集合里不存在 to D，因此将 节点 D put 进 LinkedHashMap 中；

5. 节点 E 出队，由于 links 集合里不存在 to E，因此将 节点 E put 进 LinkedHashMap 中；

6. 节点 E 出队，由于 LinkedHashMap 中已存在 节点 E，因此直接替换；

7. 节点 F 出队，由于 links 集合里不存在 to F，因此将 节点 F put 进 LinkedHashMap 中；

8. 遍历 LinkedHashMap，执行节点对应的场景。

实现逻辑如下【代码已简化，只保留核心逻辑】：

LinkedHashMap<String, RiskNode> linkedHashMap = new LinkedHashMap();
Queue<RiskNode> queue = new LinkedList<>();
queue.add(startNode);
while (!queue.isEmpty()) {
    RiskNode node = queue.poll();
    linkedHashMap.put(node.getName(), node);
    ArrayList<RiskNode> nextNodes = getNextNodes(lines, node);
    if (!nextNodes.isEmpty()) {
        for (RiskNode nextNode : nextNodes) {
            queue.add(nextNode);
        }
    }
}

执行推送效果如下：

图：数据变更精准测试

图：代码变更精准测试

至此，风控测试依托精准测试能力，能 快速感知数据和代码改动和改动影响，并让单次影响的回归时间从 4 小时 降低到 10 分钟。

4. 风控特征场景化测试

风控的业务需求，在风控系统内实际上就是对补全、特征和策略的变更和处理。然而，因为风控依赖数据来源复杂、风控处于链路下游业务难以触达等问题。经统计，不包含学习成本的情况下，单个补全的验证时间在 10 分钟，单个特征的验证时间在 20 分钟，单条策略的验证时间在 2 小时。验证过程繁琐，还容易错漏。
抛开现象看本质，在特征类需求中，我们将整个测试过程分为风控测试阶段、集成测试阶段和回归测试阶段。在风控测试阶段，我们主要关注特征本身的逻辑；在集成测试阶段，我们主要关注整体业务链路的逻辑；在回归测试阶段，我们主要关注特征变更对其他功能的影响。为此，我们开发了风控直达测试、场景化测试、历史场景回测、需求场景库等能力，重新解构了特征需求的测试，明确了各阶段的职责，提升了我们的测试效率。

4.1 风控直达测试

在风控测试阶段，我们需要专注于关注特征本身的逻辑，为此，我们需要解决两个问题，即绕过上游业务触发风控，和绕过依赖数据源构造数据。

4.1.1 快捷测试

由于风控的接口信息、特征的构造信息、补全的配置信息均在风控系统上配置。为了进行快捷测试，我们首先需要拉取风控系统的配置数据，解析出入参信息，在测试时，不通过上游业务请求直接触达风控，此外，为了充分提高人效，还需要具备自动断言的能力，其过程如下：

测试效果如下：

4.1.2 补全 mock

特征获取外部数据源信息的手段是通过补全，在风控判责系统中，补全是通过内部编写的代码来调用外部服务。我们想要绕开外部数据源构造特征数据，就需要对补全调用外部系统的代码进行 mock。在货拉拉，我们已有 java 服务专用的 mock 平台，其原理是通过 jvm-sandbox 对源码进行字节码增强，从而实现 mock 代码的注入。我们不需要重复造轮子，只需要对 mock 平台的接口进行封装，根据风控使用的特性，简化整体的配置流程。

4.2 场景化测试

在集成测试阶段，已保障风控逻辑无问题的情况下，我们需要关注整体链路的逻辑。为此，我们需要从上游业务触发来完成测试场景，并且构造符合特征要求的外部数据。整个测试过程复杂且繁琐，导致我们测试能效较低。
根据我们的分析，风控往往存在于业务特定的环节，这就意味着触发风控的场景虽然繁杂，但每种场景大体是固定的步骤。而风控需要获取的外部数据，常常也是调用外部服务已有的接口。所以我们想到了利用自动化测试的思想来提升我们的测试效率。我们主要引用了三种自动化测试技术。

• 基于组件的自动化

  我们使用组件化的思想，将依赖外部的每一个动作，封装成一个组件，测试同学无需关心组件内部的实现逻辑。
  例如：扭转订单状态流程，封装成订单状态流转组件。

• 基于关键字驱动的自动化

  我们使用关键字驱动的思想，将每个组件进一步封装，根据目标步骤封装成对应的关键字。实现元素与对象的分离，描述与实现细节逻辑的分离，脚本与自动化数据的分离。
  例如：订单状态扭转到取消订单步骤，封装成订单状态流转 - 司机取消订单关键字。

• 基于数据驱动的自动化

  我们使用数据驱动的思想，通过配置的数据来控制测试场景执行的流程以及执行的动作。
  例如：完成订单，自定义账单费用场景，将 生成订单、扭转订单 、发送账单、查询订单、补全测试 等步骤通过场景编排的能力封装成一个场景数据记录。
  

4.2.1 组件和关键字

针对风控场景化测试，我们所依赖的组件和关键字，主要分为两类，一类是外部系统功能封装的组件，一类是风控本身测试动作封装的组件。于风控测试来说，外部系统功能封装的组件本是我们难以攻克的难点。所幸，货拉拉有测试共建的数据工厂，货拉拉的测试会在日常工作中，将各自领域的功能封装成组件，通过数据工厂提供给所有人使用。所以我们只需要将数据工厂的组件，配置到我们特征测试平台中，并将其封装成我们需要的关键字即可。

除了上述的外部系统功能组件的关键字封装，平台还提供了 “时延” 关键字，和 “场景测试” 关键字。

4.2.2 场景编排

当我们封装好关键字，再利用场景编排的能力，就可以封装成完整的风控测试场景。在场景编排中，我们主要执行三个步骤：

1. 增加期望的执行步骤，这些步骤是已封装好的关键字，包括功能组件关键字、时延关键字 和 场景测试关键字；
2. 调整执行步骤顺序；
3. 添加场景入参和各步骤入参。 场景编排效果：

4.2.3 场景运行

在场景运行功能中，我们会填入场景编排时生成的入参变量，并将其转化为初始的全局变量，往后执行的每一步都会读取全局变量，并且在执行完成后将当前步骤的出参变量添加到全局变量中。我们利用变量和步骤，对场景进行数据驱动和串联。

4.3 场景回测

在回归测试阶段，风控测试主要的任务，是对 bug 进行回归验证，以及关注本次需求中，特征变更对其他功能的影响。为此，我们开发了历史场景回测功能和需求场景库功能。

4.3.1 历史场景回测

验证 bug 是否被正确修改，首先需要找到 bug 复现的路径。我们考虑到，在其他条件不变的情况下，想要验证 bug 是否被修复，只需要用之前测试失败同样的参数，执行同样的场景。所以，历史场景回测功能需要将之前失败 case 的场景入参、场景步骤 和 执行结果记录下来，并让风控测试能通过同样的场景入参进行测试。

4.3.2 需求场景库

在测试特征类需求时，我们会将需求信息、需求变更的策略&特征&补全信息配置在需求场景库中，这样在回归测试的时候，我们除了通过精准测试，准确识别变更在配置和代码上的影响范围。还能通过特征的检索，查询到历史需求是否会受到影响。

依托于风控直达测试、场景化测试和场景回测的能力，风控测试有效降低了业务学习成本、数据构造成本，让 单补全测试时间由 10 分钟 降低至 1 分钟；单特征首次测试时间由 20 分钟 降低至 5 分钟，重复测试时间由 10 分钟，降低至 2 分钟；单策略首次测试时间由 2 小时 降低至 30 分钟，重复测试时间由 1.5 小时，降低至 10 分钟。

5. 风控全域拦截

风控策略的有效性和准确性，很大程度上取决于上游业务字段的完整和准确，如果上游业务字段缺失，可能会导致风控策略的错判和漏判，影响风控的效果，甚至引发客诉和资损。我们曾经通过给上游测试和开发提供 “风控造数策略”，并在造数策略中配置数据合规校验条件的方式，保障上游调用风控的数据质量。但这种方式需要上游测试、服务开发主动识别调用风控的场景，并使用我们提供的工具和策略，因而存在一定的局限性，出现数据质量问题时，风控测试也难以及时感知。

5.1 全域拦截方案

在货拉拉，我们有一套准入准出流水线，所有的需求变更在发布生产前，必须先发布 pre 环境，执行并通过对应的自动化 case，否则将无法发布生产。因此，任何改动都会先在 pre 环境体现。依托于此，我们想到在 pre 环境建设一套风控全域拦截机制。
风控全域拦截是在测试环境中创建全流量管控策略，管理经过风控系统的所有流量，并对这些流量进行字段核查，以捕获不符合风控接口要求的流量。通过返回风控拦截结果码，策略可以阻塞上游服务流程，同时利用拦截策略触发通知，使风控测试人员能够及时发现对接方字段的错误或遗漏，从而促使上游及时的进行修正和优化。这样，我们可以将过去的被动拦截转变为主动发现，避免将数据质量问题遗漏到线上。
整个风控全域拦截的过程分为三个环节：

1. 全域风控策略的设定：根据接口文档，风控测试将文档中的特征按照其重要性和业务属性进行分类，并在风控平台上进行配置，构建相应的全域拦截策略；

2. 风控全域拦截的实施：一旦策略生效，风控系统将接收上游流量，拦截不符合规定的流量，并将其通知给特征测试平台；

3. 风控问题的跟踪和解决：在发现不符合规定的流量后，风控测试将创建跟进单，并根据收集到的信息判断是否存在数据质量问题。

5.2 全域风控策略

全域拦截策略是基于风控条件补全判断机制、策略命中机制以及策略命中处罚机制构建的。我们会根据风控接口文档的要求，补全出数据合规性校验条件。全域拦截策略则进一步组合各类数据合规性条件，业务流量一旦有任何条件不满足，便会触发策略，返回风控拦截结果码，从而阻止请求方的业务。
例如，如果接口文档要求在 user_type = 2 时，ep_id 是必填的，那么合规校验条件特征就会被配置为 user_type == 2 && ep_id is empty。如果上游业务在请求风控时，传入的 user_type 为 2，但却漏传了 ep_id，那么该合规条件特征结果为 true，命中策略，返回拦截结果码。
全域风控策略上线流程：

5.3 问题跟进单

当全域拦截策略拦截到异常流量时，会触发通知发送到飞书。我们的测试团队在收到飞书通知后，会通过创建问题跟进单来及时处理拦截问题。
通过问题跟进单，风控测试能够清晰地了解数据质量状况，添加跟进线索，并推动问题的解决。

5.4 拦截 bug 追踪

在风控全域拦截发现的数据质量问题中，有些问题可能无法立即解决。这类问题通常会被标记为延迟处理并长期存在。对于这类问题，测试团队需要做的是提醒风控策略在线上使用时要谨慎处理无法保证质量的数据，并提醒风控产品定期跟进。因此，我们开发了拦截问题追踪功能。特征测试平台会维护风控接口与负责产品的清单，定期同步全域拦截发现的问题，并将开放状态的问题清单推送给对应接口的产品，以提醒产品团队跟进。

6. 成果与收益

在风控特征质量保障的探索和实践中，我们通过实施精确测试，成功识别并保障了特征变更的影响范围；通过实行场景化测试，提升了测试效率，确保了特征逻辑处理的准确性；此外，我们通过构建风控全域拦截能力，使风控测试能够主动发现数据质量问题，确保了特征数据获取的准确性。这些能力和保障，最终为我们带来了风控需求全流程的效率提升和线上数据质量的提高。

6.1 全流程提效

• 风控场景化测试：100+ 与风控数据绑定的测试场景，2000+ 的执行次数，风控场景化测试给我们带来了 600+ 小时 的人效提升。
• 全流程提效：从用例设计到用例执行，最终到需求验收和上线。特征质量效能建设让风控测试更专注于测试，全流程额外耗费工时从 26 小时 降低到 2.58 小时。

6.2 数据质量提升

• 风控全域拦截机制建立：通过在线下建立 60+ 全域拦截策略，共拦截异常流量 7W+，实施过程中测试创建 80+ 拦截跟进单，发现 40+ 数据质量缺陷。
• 产品文档规范提升：风控全域拦截实施过程中，发现 20+ 产品文档问题。规范产品文档，从源头上降低数据质量问题的发生。
• 线上数据质量提升：风控全域拦截发现问题如果暴露到线上，将会影响风控 8.71% 流量，数据质量的提升，有效降低线上风控错判、漏判的风险。

7. 未来展望

在未来，我们将继续深耕风控特征质量保障，持续提升风控测试的效能。

• 智识 - 引入深度学习能力，自动化判别拦截流量，对异常流量进行自动打标，降低人工识别的成本；
• 智能 - 根据策略关系图和全局关系网，智能生成功能和自动化用例；
• 智测 - 用例与场景绑定，实现场景化断言，结合流量回放能力，达成场景化智测。