风控决策系统其本质是获取数据—>变量计算—>风控打分（使用数据分析方式建立风控模型和决策引擎）—>输出审核结论。融合到业务中，要根据不同产品线、不同用户定义，路由到相对应的变量、数据源、数据模型、决策引擎进行计算……内部逻辑复杂，产品需求繁多，每一个变量改动/新增，模型迭代，决策引擎规则调整或代码结构优化，都可能会影响系统稳定性，对软件版本迭代质量的保障任务也非常艰巨。今天简单介绍笔者测试风控决策系统（API测试、自动化测试、生产监控）的一些内容和心得体会。
接口测试：业务流程知识打扎实
风控决策结论的计算被解耦到数个接口（API），这些API各负责一块功能的实现。接口（API）测试，初接触时可能会觉得很简单，三五个参数，post/get提交，有预期结果返回不就ok了吗？实则不然，要想完美保障接口每一次版本迭代的质量，覆盖全面的测试用例必不可少，通常我们会从如下几个方面设计接口测试中设计用例:
- 入参/响应结果功能测试：
不同入参（必填/非必填、边界值、异常值等）响应内容准确性
接口响应时间、接口性能…… - 数据准确性校验：
与数据库表或来源接口核对准确性逻辑计算：mock/白盒测试……
- 日志测试：
日志完整性、级别正确性异常时日志记录、日志监控机制
- 集成测试/系统测试：
各业务流程联调测试测试结果反馈开发/需求方验收 等
自动化测试，提升测试效率
除了完善的用例设计及执行，风控决策系统需求多迭代快，每次迭代不仅要验证新增/变更模块的相关测试，也需完成所有模块及集成测试的回归，全靠纯手工测试是无法完成的，所以我们对于功能稳定、有大量重复测试任务的模块，采用了自动化脚本来完成测试。
测试点：接口返回数据与表数据一致性。
这个需求变量多数据量大，人工测试效率低，我们选择JMeter脚本批量调接口、校验数据。相关Jmeter组件及用法:
- 接口请求设置：
Sampler—http请求：配置接口请求内容
断言（检查点）—BeanShell断言/响应断言 - 接口入参参数化：
配置元件—CSV Data Set Config：csv实现入参参数化，自动大批量跑 测试数据
- 表数据查询设置：
配置元件—JDBC Connection Configuration：数据库连接配置
Sampler—JDBC Request：sql脚本 - 变量提取：
后置处理器—正则表达提取器：提取接口响应、sql返回结果变量
后置处理器—BeanShell Postprocessor - 数据校验：
断言—BeanShell断言：校验待比对变量的一致性
测试点：大量跑测试数据，提取所有风险变量（上千）及模型相关输入输 出变量与预期值验证。
痛点：中间变量只记日志，人工核对数据准确性难度大。
自动化测试思路如下：
考虑脚本的开发成本，我们使用最为简洁的python实现。我们将自动化脚本持续集成到接口自动化测试平台，每次版本迭代时自动回归并产生测试报告，很大提高了测试效率。
生产监控，保障线上稳定
系统的稳定除了需求迭代期对测试质量的保障，还需要我们对生产环境的运行情况进行实时质量监控。站点发布更新时，如何确保发布正常？依赖接口/数据库突发异常，如何实时捕获？ 我们通过日志监控（Celery Flower/ CAT/ELK等）来及时的发现这些问题。日志测试是我们接口测试中非常重要的一项，每一次service的调用，每一次数据库的访问，都应该有日志，以供系统异常时有信息可追溯。
日志监控告警可以及时发现接口功能的异常，但对于一些数据异常却很难发现，我们使用质量监控平台DQ对调用审核量、审核结论计算时效等一些关键指标进行了数据监控。
每隔10分钟统计各产品线近10分钟内进入审核的流量，以及成功跑出审核结论的平均时效，与阈值（近3天同时间段平均值）对比，如上图（非真实数据，仅展示效果），在40分时，我们就会及时收到审核量、平均时效数据异常的告警。采集周期及阈值标准调整都可以在DQ平台用sql灵活配置实现。
如上图调用审核量减少，可从以下方向确认原因：风控系统是否能正常调用？调用方是否出现bug？APP端是否有控制流量？反之，若调用量激增，是否产品在做营销推广？或有“羊毛党”薅羊毛？耗时突然增加：系统是否有任务积压等等。通过数据监控，我们可以及时发现隐蔽的生产问题，降低故障影响。
怎样做好数据监控，监控哪些数据、监控的每个数据背后的意义，这些都需要对业务流程知识有充分的积累。监控发现的问题如何精准判断其影响程度，快速分析定位原因？这主要基于日常问题分析的积累。
写在最后
以上只是风控决策系统质量保障之一角，简言之，对于一个复杂系统的测试，我们不仅需要吃透系统相关的业务流程知识，还需要善于使用测试工具、测试脚本等来提高测试覆盖率与测试效率，也需要对质量风险点、数据质量做好实时监控以保障系统的稳定运行。
Lily