导读

这篇文章主要给大家分享精品课测试团队为保证大促稳定性，在最近一年半时间的所做的一些尝试和探索。比如，如何准确预估开闸瞬间的用户流量，如何更好地进行性能优化后的验证和回测，如何解决夜深人静压测的尴尬等等。值得欣慰的是，经过持续测试和优化，精品课的所有服务，在几十亿规模的交易流量下，都表现出了很好的稳定性和可靠性。

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

编辑/ 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. 群策群力，产出了一份完善的压测作战手册作为后续大型活动压测任务的指导性文档。

后续展望

1. 压测日常化→关于压测执行这部分，后续我们会与开发运维一起，部署一套压测专属环境，建立日常压测流程及标准，在新的变更上线前尽早发现和优化性能问题，避免临时抱佛脚。

2. 无人值守压测→ 目前每次全链路测试，我们都需要压测执行的测试和研发人员线上实时关注监控报警等，以便及时发现和定位问题，后续希望在压测时接入我们的各种服务和接口报警系统，达到问题自动发现和产出报告的效果。

3. 相关工具的易用性拓展，提供给开发自主回测→上面提到的一些工作，仍然存在大量的人工操作，目前我们正在做进一步的工具开发，包括 diff 工具增加结果展示的对比和统计，流量回放 web 操作页面等等。

4. 性能瓶颈分析工具→ 当前出现性能问题时一般是靠研发人员进行人工定位和排查，后续会调研能否利用 apm 系统做一些问题初步分析的事情。

5. 工具集成化，赋能其他业务线。

-END-