作者:梁冬冬

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

一、大促备战,求有序,求稳定:

大促是每年例行高考,把人和系统的各项能力激发,衡量系统健壮,容错性;凌晨 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)系统风险:系统上线风险、系统不稳定、性能不达标、依赖接口异常等等,在功能测试后,要全面评估系统的影响面影响 的种类,提前做好预发预案;

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


↙↙↙阅读原文可查看相关链接,并与作者交流