作者：梁冬冬

风险系统复杂且又庞大，质量如何保障需要我们付出一点一滴的努力来浇灌系统之花

一、大促备战，求有序，求稳定：

大促是每年例行高考，把人和系统的各项能力激发，衡量系统健壮，容错性；凌晨 3 点的身影就像一束光，夺目耀眼；今年的大促与往年不同，倡导绿色，节能减排，降本增效，把各种资源做到利用最大化，产生更大的价值，让大促备战产生了一丝温度

1）压测备战时间表（统筹整体，从 4.21-6.23 我们把剧本编制到细枝末节，是一条生命线）

2）服务器扩容缩容计划（节能减排，把资源利用合理化，让价值体现最佳）

3）系统优化清单（风险策略的不断增加、迭代，对系统是实时的挑战，通过不断优化系统，让系统轻松应对大促）

3）压测目标与评估（精准预估流量，通过流量复制形式生成相关压测数据，保证数据的还原程度，压测轮次减少，压测质量不减，反而增强）

4）压测接口清单表（计划压测接口，压测轮次，分层分次，仅仅有条）

5）大促备战准则与规范（备战规范是我们的方向标，准绳，像大海中的指南针指引方向不能偏航）

6）备战注意事项（把常规事项罗列清晰，把事情做到最佳）

7）监控与看板（系统风险的兜底方案，我们监控的有力保障，最短的时间发现、定位、解决问题）

8）备战待办事项清单（把大促工作相关待办项罗列清晰，有条不紊的进行展开）

9）备战会议室与运营（因为疫情，我们把战场分成线上，线下相结合，提前做好准备工作，打一场胜仗）

二、预警监控，求全面，求精准：

预警监控是质量的最后一道关卡，同时也是质量的兜底方案，我们格外重视建设这块的能力。

预警全面性：预警分为业务预警、系统预警、资源预警三大类，业务预警在三层最上端，也是对业务结果的检验检测，经过我们长期对业务数据分析，对预警的阈值不断调优，对预警的等级分层等，业务预警的覆盖度不断显著提升；整体配置预警 1000+，业务预警的覆盖度稳步提升，同比去年提升 56% 左右，整体覆盖了核心场景。

1）梳理业务结果数据（对业务细化，业务熟悉度更高）

2）接入风险洞察系统（通过数据源接入到实时风险洞察实时计算平台）

3）配置数据集（通过 sql 配置不同的数据加工逻辑）

4）设置相关告警阈值（通过线上数据分析，得出精准的阈值结论）

5）手机相关接受人，预警等级，预警方式，预警信息等（把相关的干系人，预警的等级方式统一配置齐全）

6）测试预警触达（验证预警的有效性）

7）预警启用（启用后，正式运营告警）

8）通过设置预警机器人相关核心预警项，增强预警的监督与及时性（通过机器人运营，把应用负责人跟预警强关联起来，力保发现的线上问题，在最短的时间内通知到干系人，处理以及监督解决）

预警的精准度：提升预警的精准度，是为了及时发现以及精准定位线上问题 以及 降低预警运营成本最有效的方案；通过我们一年多来研究业务预警，把风险系统的业务预警拆分成多层，通过四分算法等机制已经形成了一套标准化、统一化、流程化的预警运营的方案，至今事故级别预警精准度达到 100%，准事故级别预警达到 99.6% 左右，高危级别预警在 76% 左右。

1）事故级别预警（精准度缺失无法容忍 block 级别）

2）准事故级别预警（精准度容忍略微缺失，精准度至少在 99% 以上）

3）高危级别预警（高危级别预警类比系统精细化预警，容忍精准度缺失，讲究覆盖度与精准度的平衡，精准度要求在 80% 以上）

3）高危级别预警（精细化运营类的告警，容忍有精准度缺失，80% 以上）

三、自动化覆盖度，求效率，求变化

在不变中求变，在变化中不变；交付的质量与交付的效率本身是一件冲突的事，可以把冲突的事做成不冲突，要客服种种的困难，不达目的不放弃的精神

移动端篇：设备指纹是风险侧技术能力建设的重要工具以及手段，设备指纹会以 SDK 或者 JS 的方式嵌入到业务的 app 或者页面里，获取相关的风险信息，达成风险识别的能力；设备指纹的自动化涉及到两个方面：

1）设备指纹的稳定性：通过调研线上崩溃的区域，容易发生崩溃 orANR 的部分多数是来自于数据接口的交互导致崩溃，前期通过对业务的调用链路梳理，把相关崩溃风险的区域，做成了 UI 自动化，通过脚本控制手机，执行相关的业务逻辑操作，通过循环次数 以及 运行时间控制重复操作来模拟操作，校验是否会出现崩溃等异常情况；这块我们已经通过封装开源的工具，把执行脚本，采集相关 logcat 相关的崩溃或 ANR 信息打印到测试报告内，通过发邮件的方式，最终收集相关的报告结果，大大提升了测试的效率的同时提升了设备指纹的稳定性；

2）设备指纹的自动化：设备指纹自动化采用 UI 模拟方式进行自动化，自动化有主控 master 通过分发的形式，把测试任务下达给每一台设备，最终形成分布式的执行自动化的效果，大大提升了自动化的执行效率，同时也提升了设备指纹的设备兼容性；

3）接口测试篇：风险系统偏底层服务居多，决策业务的是否有风险之本。在风险侧展开接口自动化是为了更好的支撑业务，同时也是为了保障质量。为了响应公司的号召，为了达成支持业务最大化，今年开始陆续把自建的平台关闭，关停了一些 ROI 低的工作，把相关的业务自动化测试用例，陆续有条不紊的迁移到更佳优秀的接口测试平台上，把自研开发平台的人力加到业务支撑，接口的自动化今年覆盖度从年初的 18% 到年中的 40% 左右，实现了主流程链路的覆盖，业务使用率达到 32% 左右，从行云里的数据来看，上半年无论是从测试交付的周期还是吞吐量都有较大的改善，真正的做到了自动化赋能业务，业务交付显著增长的结果；

4）精准评估需求影响范围：需求评审、以及测试用例的评审是拉齐研发，测试，产品对需求认知的一场不错的会议，所以今年 P0P1 级别需求都要求强制用例评审，评审用例的同时，把大家的信息拉通，达成一致；今年，在需求评审会里，增加了一个环节，就是通过我们自研的针对增量代码的（本次需求）链路分析，以及影响的方法范围，产出一份血缘关系图，在需求评审的同时，可以精准的圈定影响的范围，让影响范围更加量化，可度量；

5）度量测试质量：作为质量负责人，更关心的是如何管理好质量，那么质量团队每个人测试质量的好与坏，或许也是需要度量，可把控；今年推进测试代码覆盖率的执行，通过字节码的方式，在测试人员执行用例的同时，可以精准的定位出来，测试用例覆盖代码的行数，来评估测试是否都覆盖全面，事后知道可度量，可追溯；

6）策略测试自动化：策略测试是风险侧独有的一种测试场景，策略是分析师长期积累的结晶，精华，是风险人的智慧，策略质量的好与坏是对系统有牵绊的。今年通过与策略效能组共建测试平台，达成了从策略包测试，自动生成案例，再到策略包接口的流量复制，通过线上天然的流量验证策略配置的准确性，已经形成了一套方法论并落地，今年会加大推广力度实现策略测试一体化，平台化，智能化；

7）混沌工程：混沌工程为大促而生，今年 618 非同寻常，主战场为线上线下相结合，在各种的不确定性中我们寻求系统的更加的稳定，健壮。今年引入了混沌工程，把一些核心依赖接口的超时，缓存异常，DB 宕机，服务器资源各种异常模拟复现，预知了系统风险，大促稳中求稳，不断求新；

8）UI 自动化测试篇：UI 自动化历经数年，UI 自动化已经相对稳定，但业务的日新月异，对前端的不断变更，对 UI 自动化运营是个不小的难题。综合看，风险测的 UI 自动化达成的主要是不频繁修改的，主流程的，达成覆盖度 100%。非核心场景的，经常变更的，由手工执行，做好 UI 的用力分层，分类至关重要；

四、质量卡点与风险识别，求全面，求质量

设置质量卡点，是质量体系的线上化的一种方式，说的直白点就是把风险侧质量体系相关的规范准则，通过线上化的形式，设置卡点或者实时预警，通过卡点或及时触达来规避流程、操作风险等

质量卡点是我们重中之重，组之大器，红线，底线，不可逾越。今年我们优化了多处准则规范，为了增强大家的质量意识，形成有效的规范规则，有效的保障质量。

1）上线监控：无论是 Jone、jdos、JCI 上线都需要走严格的审批上线，杜绝顺风车，AB 异常审批，不经过测试等等上线审批异常行为，通过把 JDOS 审批流信息接入风险洞察系统，配置了相关的实时监控，把异常行为监控一览无余，杜绝踩踏质量红线

2) 效率监控：测试交付的效率，交付的吞吐量是度量测试效率的重要指标之一，需要实时的发现问题，解决问题，做到每一个需求，每个人数据透明化，今年也是把效能交付周期配置了相关预警，当交付周期长时，相关的预警会触达效能小组的相关人，告知效率风险，有人对应跟进分析，给出结果；

3）缺陷与用例监控：测试用例，缺陷都是测试人员的产出物，通过监控分析这些数据，对以后识别系统好与坏，以及测试人员执行的情况最有利的支撑。

4）核心系统上线评审：核心系统上线评审是对系统上线的敬畏，今年核心系统上线，我们都会组织架构师、负责人等相关干系人一起评审业务，代码，以及影响范围；增加一道上线评审，规避质量风险发生；

5）测试用例强制评审：需求评审、以及测试用例的评审是拉齐研发，测试，产品对需求认知的一场不错的会议，所以今年 P0P1 级别需求都要求强制用例评审；

6）配置相关风险：配置变更、迁移变更、规则修改、策略变更等等，配置类的发布是最容易忽视的区域，也是今年要纳入测试的范畴的点，配置要经过测试并通过审批流程后方可上线；

7）排期风险：资源投入、倒排期、外部依赖、缺陷处理时间等等，都需要我们关注，要保证项目需求进度无风险，按时交付，力保业务；

8）安全合规风险：数据泄露、泄露用户信息、诱导用户、敏感数据等等都是风险合规的重中之重，需要我们在测试业务的过程中识别出来这种风险，提出风险，规避风险；

9）客户自损类风险：风险策略拦截、企业授信放款、AB 系统衔接、规则漏洞等等都会产生相关的风险，在系统层面把控风险尤为重要

10）系统风险：系统上线风险、系统不稳定、性能不达标、依赖接口异常等等，在功能测试后，要全面评估系统的影响面影响 的种类，提前做好预发预案；

还有未考虑到的方面，欢迎大家补充交流