关于测试:有道精品课全链路测试的改进和思考

33次阅读

共计 2613 个字符,预计需要花费 7 分钟才能阅读完成。

导读

这篇文章次要给大家分享精品课测试团队为保障大促稳定性,在最近一年半工夫的所做的一些尝试和摸索。比方,如何精确预估开闸霎时的用户流量,如何更好地进行性能优化后的验证和回测,如何解决夜深人静压测的难堪等等。值得快慰的是,通过继续测试和优化,精品课的所有服务,在几十亿规模的交易流量下,都体现出了很好的稳定性和可靠性。

作者 / 有道精品课测开小组

编辑 / Ein

背景

相似于电商平台的 618,双 11 大促,在线教育平台也存在两个重要的工夫节点:04 月春续暑秋,10 月秋续寒春,产研侧须要针对销售策略与售卖预期,提供续报工具、数据核算、流程买通等多方面的反对。作为测试人员,在保障性能可用的根底上,还要通过全链路压测的伎俩,维持流量突增十几倍的状况下零碎的高可用状态,演练各种降级、限流、熔断、监控、应急计划,竭力保障流量最高峰也不呈现问题,即便呈现问题也能迅速的发现 - 定位 - 解决 - 复原。

具体实际

整体指标

一句话:保障开闸霎时及流动期间零碎整体稳定性。

进一步细化能够蕴含以下几点:

  1. 容量布局:以整体流量和业务指标为根底,估算出每个子系统须要满足的容量大小,联合压测状况,对系统进行适当的扩容和优化,确保零碎可能满足业务流量压力。
  2. 流量管制及降级:零碎须要避免流量超过可撑持的容量,对超出设计的流量进行限流,对超负荷 or 异样的服务及时进行降级。这里次要验证:限流和降级策略的合理性和可用性。
  3. 监控:测试现有监控伎俩是否能正当发现和裸露问题,以便对问题及时预警,做到早发现,早治理。
  4. 演练预案:对系统可能面临的问题要进行全面的预演,比方根底服务异样,机房故障等等劫难模仿的伎俩来测验零碎体现以及筹备正当的解决计划。

流程


图①根本测试流程


图②问题发现及定位

常见问题解决方案分享

压测模型确定

模型,次要包含 2 个方面:门路、指标。

门路:次要指的是理论流动中用户的操作门路,转化到服务即对各接口串行或者并行调用形式、调用程序等。次要是通过从产品侧获取 sop 进行抓包转化失去。

指标,次要指的是各场景中各种操作的占比与工夫,那从测试维度来看,就是每个接口的 QPS, RT 等数据。

  • 能够说模型的准确性间接关乎压测的成败,去年咱们的模型中漏掉了退换课接口,然而这个接口存在比较严重的性能问题,间接触发了零碎的级联故障,影响很大。如何获取精确的模型,咱们考究“取之于理论,用之于理论”。即获取前一次续报流动的理论调用情景,通过数据荡涤与整顿,联合本次的预估数据量及 sop,量化本次压测的指标。可参考下图:
  • 通过咱们的自研工具,实现日志主动解析、接口列表补充、压测场景确定等工作。一部分解决流程如下:(备注:npt 为杭研的压测平台简称)
  • 将 SOP 转化为接口门路。传统形式是抓包后,人工筛选、比照、整顿抓包后果,再将接口变更状况手动同步到压测平台,该工作较繁琐且反复。这部分咱们提炼成 web 工具后,仅须要上传抓包文件,就能够失去场景级别的接口增减状况,并反对“场景级别的接口列表保护”、“设置接口黑名单”、“接口一键导入压测平台”等性能,成果展现:
  • 最终成果:不论是接口列表或者量级,咱们压测模仿的流量跟理论流量简直是统一的。

    数据结构

    数据是压测执行的前提条件,比方咱们须要特定格局虚构用户文件作为申请参数,再比方某一批用户只有领有某些课程权限,能力算作无效用户,那么就须要给用户批量预置某些课程权限。针对这种情景,次要解决方案是:通过自研平台开发了批量操作的 web 工具,比方加课程权限,发放优惠券,通过多线程执行工作,在较短的工夫内实现无效用户的筹备,包含数据库更新、redis 缓存刷新等,实现工具复用,升高造数老本。

    环境

    之前留给压测的工夫比拟缓和,为了保障测试后果的可靠性,咱们间接应用线上环境压测,同时为了升高业务影响,只能在凌晨中午进行测试,导致测试周期很长,相干人员都比拟疲乏。通过沟通,开发和运维侧帮助搭建了专属压测环境,服务部署独立实例、redis,kafka 等相干中间件加 prefix 进行数据偏移,外围组件 mysql 独自部署实例,为了解决测试环境 mysql 数据量不够的问题及数据清理的问题,研发调研了 mysql 一键同步及回滚工具,流程如图:

成果:外围电商业务 80% 的问题都能够在测试环境发现及验证,不必再熬夜线上测试。

对于性能回测

  • 在压测过程中,性能优化是必不可少的,那么疾速实现优化后的接口性能验证是性能测试能持续进行的重要保障;理论遇到过很多种须要进行性能回测的场景,比方:须要批改接口自身逻辑,例如单查改为批量查问等;更换数据源,例如从查问 es 改为查问 doris 等,这里手工回测和咱们现有的接口自动化回测都具备肯定的局限性,所以咱们引入了流量剖析 +diff 计划,测试高效并且覆盖率高。
  • 外围指标是:比照数据量多,比照速度快,操作简略不便,应用流程:
  • 对于数据比照,满足咱们要求的第三方库有很多,比方常见的 deepDiff、difflib、json-diff、json_tools 等,都有各自侧重点。其中 DeepDiff 能够比照字段、字符串等可迭代的对象,针对对象的深层差别,反对递归查找所有更改,同时反对比照的格局也很多,包含 JSON、XML、图片等,因为性能比较完善并且满足咱们的需要,咱们最终实现选用了 deepDiff 库。

总结

收益

  1. 通过多轮压测,发现了大于 20 个的性能问题和优化项,在最初理论开闸期间,零碎体现优良,业务方反馈很好。
  2. 整个零碎的稳定性有显著晋升,日常故障率明显降低。
  3. 集思广益,产出了一份欠缺的压测作战手册作为后续大型流动压测工作的指导性文档。

    后续瞻望

  4. 压测日常化→对于压测执行这部分,后续咱们会与开发运维一起,部署一套压测专属环境,建设日常压测流程及规范,在新的变更上线前尽早发现和优化性能问题,防止长期抱佛脚。
  5. 无人值守压测→ 目前每次全链路测试,咱们都须要压测执行的测试和研发人员线上实时关注监控报警等,以便及时发现和定位问题,后续心愿在压测时接入咱们的各种服务和接口报警零碎,达到问题主动发现和产出报告的成果。
  6. 相干工具的易用性拓展,提供给开发自主回测→下面提到的一些工作,依然存在大量的人工操作,目前咱们正在做进一步的工具开发,包含 diff 工具减少后果展现的比照和统计,流量回放 web 操作页面等等。
  7. 性能瓶颈剖析工具→ 以后呈现性能问题时个别是靠研发人员进行人工定位和排查,后续会调研是否利用 apm 零碎做一些问题初步剖析的事件。
  8. 工具集成化,赋能其余业务线。

-END-

正文完
 0