交易系统的全链路压力测试方法及存储介质[发明专利]

(19)中华人民共和国国家知识产权局
(12)发明专利申请
(10)申请公布号 (43)申请公布日 (21)申请号 201910455892.7
(22)申请日 2019.05.29
(71)申请人 兴业证券股份有限公司
地址 350001 福建省福州市鼓楼区湖东路
268号证券大厦
(72)发明人 范兴元　许斌　陈耀鹏　孙文广　
黄巍炜　张应通　庄春平　
(74)专利代理机构 福州市景弘专利代理事务所
(普通合伙) 35219
代理人 林祥翔　徐剑兵
(51)Int.Cl.
H04L 12/26(2006.01)
G06Q 40/04(2012.01)
(54)发明名称
交易系统的全链路压力测试方法及存储介
质
(57)摘要
一种交易系统的全链路压力测试方法及存
储介质，其中方法包括如下步骤，获取用户操作
生成的请求信息，根据所述请求信息生成压力测
试脚本，将压力测试脚本运行于全链路待测系
统，按照预设比率配置不同接口的压力测试脚本
流量，并实时监控全链路待测系统的预设参数；
所述全链路待测系统为提供证券交易服务的生
产环境架构或模拟生产环境架构。

本发明技术方
案通过借助现有软件，通过对不同页面的判断检
测，能够解决现有产品下不同功能页面特征判断
的问题，从而针对证券交易软件的不同页面功
能，有的放矢地解决软件行情监控、交易功能测
试及资讯服务监控的技术问题。

权利要求书1页 说明书6页 附图2页CN 110380922 A 2019.10.25
C N 110380922
A
1.一种交易系统的全链路压力测试方法，其特征在于，包括如下步骤，获取用户操作生成的请求信息，根据所述请求信息生成压力测试脚本，将压力测试脚本运行于全链路待测系统，按照预设比率配置不同接口的压力测试脚本流量，并实时监控全链路待测系统的预设参数；所述全链路待测系统为提供证券交易服务的生产环境架构或模拟生产环境架构。

2.根据权利要求1所述的交易系统的全链路压力测试方法，其特征在于，还包括步骤，监控用户操作生成的请求信息的多条链路流量请求，筛选其中核心链路的流量请求脚本，根据核心链路的流量请求脚本配置不同接口的压力测试脚本流量。

3.根据权利要求1所述的交易系统的全链路压力测试方法，其特征在于，还包括步骤，获取业务日志中请求信息的链路流量信息，根据所述链路流量信息生成链路流量模型，根据链路流量模型将压力测试脚本运行于全链路待测系统。

4.根据权利要求1所述的交易系统的全链路压力测试方法，其特征在于，获取前端活跃度排行为前预设个数的用户，获取其操作生成的请求信息；
其中所述活跃度排行包括交易次数排行、交易额排行或APP有效操作数排行。

5.根据权利要求1所述的交易系统的全链路压力测试方法，其特征在于，
所述预设参数包括每秒事务数、每秒请求数、虚拟用户数、每分钟虚拟用户数、事务时间或资源使用率。

6.一种交易系统的全链路压力测试存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序在被运行时执行包括如下步骤，获取用户操作生成的请求信息，根据所述请求信息生成压力测试脚本，将压力测试脚本运行于全链路待测系统，按照预设比率配置不同接口的压力测试脚本流量，并实时监控全链路待测系统的预设参数；所述全链路待测系统为提供证券交易服务的生产环境架构或模拟生产环境架构。

7.根据权利要求6所述的交易系统的全链路压力测试存储介质，其特征在于，所述计算机程序在被运行时还执行包括步骤，监控用户操作生成的请求信息的多条链路流量请求，筛选其中核心链路的流量请求脚本，根据核心链路的流量请求脚本配置不同接口的压力测试脚本流量。

8.根据权利要求6所述的交易系统的全链路压力测试存储介质，其特征在于，所述计算机程序在被运行时还执行包括步骤，获取业务日志中请求信息的链路流量信息，根据所述链路流量信息生成链路流量模型，根据链路流量模型将压力测试脚本运行于全链路待测系统。

9.根据权利要求6所述的交易系统的全链路压力测试存储介质，其特征在于，所述计算机程序在被运行时执行步骤获取前端活跃度排行为，前预设个数的用户，获取其操作生成的请求信息；
其中所述活跃度排行包括交易次数排行、交易额排行或APP有效操作数排行。

10.根据权利要求6所述的交易系统的全链路压力测试存储介质，其特征在于，
所述预设参数包括每秒事务数、每秒请求数、虚拟用户数、每分钟虚拟用户数、事务时间或资源使用率。

权　利　要　求　书1/1页CN 110380922 A
交易系统的全链路压力测试方法及存储介质
技术领域
[0001]本发明涉及金融软件优化检测领域，尤其涉及一种交易系统的全链路压力测试方法及存储介质。

背景技术
[0002]现有的压力测试经常是基于测试环境执行，测试内容常是单个系统系统的事务响应时间和系统所在的应用服务器资源消耗情况，仅能测出单系统性能情况，而证券交易系统通常由N个系统、N个网关、N个中间件、N个后端服务、N个数据库等组合而成，传统的单系统事务压力测试不能满足证券交易系统在牛市时候的业务需要。

我们发现在股市牛市时，经常出现交易系统反应缓慢或无法登录、登录超时情况，现象和原因有以下几点。

[0003]1)测试环境的压测数据良好，但到生产上，遇到流量大的时候，系统出现宕机或反应超时等现象。

[0004]2)离线上还是有很大差距，测试环境与生产环境有较大的出入，所以压测环境的压测结果数据纯粹是仅供参考，并不能够作为线上环境的指导数据，只有直接在线上环境实施压测才是唯一的明道。

[0005]3)我们在整个业务流程中，最大的困难在于评估从用户登录到完成全部交易的整个链条中，核心页面和交易关键交易的实际承载能力。

如果得到了各个系统的实际承载能力，就可以在路由网关进行相关交易限流控制，来防止在大并发来了以后系统出现宕机。

在证券牛市市场中一旦系统宕机就会导致灾难性的后果，而且就算运维短时间重启了起来恢复了运行，但是可能过了一会儿过程系统承载量又出现宕机情况，基于出现大面积瘫痪，重启后又瘫痪情况。

[0006]在活动开始的瞬间，从CDN、网关接入、前端、缓存、中间件、后端服务、数据库整个交易链路都会面临巨大的访问压力，这个时候系统服务除了受自生的影响，还依赖于其他关联系统的情况，并且影响会一直蔓延，只要有一个节点出现故障，那么故障在上下游系统经过层层累加后会造成的影响谁都说不清楚，所以最好的办法就是模拟完全的真实情况来做到提前心里有数。

验证的最好办法就是让事件提前发生，通过全链路压测就可以提早发现问题。

[0007]目前压力测试主要是通过loadRunner、jemeter等压力工具来完成，但是现有的压力测试工具操作复杂，一般是要求测试人员首先根据被测试系统设置相应的测试场景，然后再根据测试场景编写测试脚本，对测试人员的专业技能要求较大，没有脚本编程基础的测试人员短时间内很难独立针对具体的压力测试场景编写压力测试脚本，实现压力测试。

[0008]基于以上，我们需要做“操作简单、测试脚本容易编程”的“全链路压力测试”，所谓全链路压力测试，就是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。

发明内容
[0009]为此，需要提供一种能够解决自动化测试的效率及有效性问题的优化方法。

[0010]为实现上述目的，发明人研发了一种交易系统的全链路压力测试方法，包括如下步骤，获取用户操作生成的请求信息，根据所述请求信息生成压力测试脚本，将压力测试脚本运行于全链路待测系统，按照预设比率配置不同接口的压力测试脚本流量，并实时监控全链路待测系统的预设参数；所述全链路待测系统为提供证券交易服务的生产环境架构或模拟生产环境架构。

[0011]具体地，还包括步骤，监控用户操作生成的请求信息的多条链路流量请求，筛选其中核心链路的流量请求脚本，根据核心链路的流量请求脚本配置不同接口的压力测试脚本流量。

[0012]进一步地，还包括步骤，获取业务日志中请求信息的链路流量信息，根据所述链路流量信息生成链路流量模型，根据链路流量模型将压力测试脚本运行于全链路待测系统。

[0013]进一步地，获取前端活跃度排行为前预设个数的用户，获取其操作生成的请求信息；
[0014]其中所述活跃度排行包括交易次数排行、交易额排行或APP有效操作数排行。

[0015]可选地，所述预设参数包括每秒事务数、每秒请求数、虚拟用户数、每分钟虚拟用户数、事务时间或资源使用率。

[0016]一种交易系统的全链路压力测试存储介质，所述存储介质存储有计算机程序，所述计算机程序在被运行时执行包括如下步骤，获取用户操作生成的请求信息，根据所述请求信息生成压力测试脚本，将压力测试脚本运行于全链路待测系统，按照预设比率配置不同接口的压力测试脚本流量，并实时监控全链路待测系统的预设参数；所述全链路待测系统为提供证券交易服务的生产环境架构或模拟生产环境架构。

[0017]进一步地，所述计算机程序在被运行时还执行包括步骤，监控用户操作生成的请求信息的多条链路流量请求，筛选其中核心链路的流量请求脚本，根据核心链路的流量请求脚本配置不同接口的压力测试脚本流量。

[0018]进一步地，所述计算机程序在被运行时还执行包括步骤，获取业务日志中请求信息的链路流量信息，根据所述链路流量信息生成链路流量模型，根据链路流量模型将压力测试脚本运行于全链路待测系统。

[0019]具体地，所述计算机程序在被运行时执行步骤获取前端活跃度排行为，前预设个数的用户，获取其操作生成的请求信息；
[0020]其中所述活跃度排行包括交易次数排行、交易额排行或APP有效操作数排行。

[0021]具体地，所述预设参数包括每秒事务数、每秒请求数、虚拟用户数、每分钟虚拟用户数、事务时间或资源使用率。

[0022]区别于现有技术，上述技术方案通过借助现有软件，通过对不同页面的判断检测，能够解决现有产品下不同功能页面特征判断的问题，从而针对证券交易软件的不同页面功能，有的放矢地解决软件行情监控、交易功能测试及资讯服务监控的技术问题。

附图说明
[0023]图1为本发明具体实施方式所述交易系统的全链路压力测试方法流程图；
[0024]图2为本发明具体实施方式所述全链路压力测试的实施方法流程图。

具体实施方式
[0025]为详细说明技术方案的技术内容、构造特征、所实现目的及效果，以下结合具体实施例并配合附图详予说明。

[0026]在本文所要说明的技术方法中，为了解决交易系统测试的问题，如图1所示，我们提供一种交易系统的全链路压力测试方法，包括如下步骤，S100获取用户操作生成的请求信息，S102根据所述请求信息生成压力测试脚本，S104将压力测试脚本运行于全链路待测系统，S106按照预设比率配置不同接口的压力测试脚本流量，并实时监控全链路待测系统的预设参数；所述全链路待测系统为提供证券交易服务的生产环境架构或模拟生产环境架构。

具体地，用户在进行交易系统操作的时候，各终端会收到很多用户操作指令，该指令就会相应地触发系统的行为，我们通过编写压力测试脚本来记录请求信息，同时也相当于在模拟用户的操作行为，压力测试脚本可以针对于不同的业务操作，如买卖股票、挂单、撤单、显示行情、登录、注销等许许多多的操作，这些业务操作在生产环境终究对应着全链路系统的各个业务端口，业务端口又分为若干子接口，我们发现在实际应用中，小比例的接口承担了大部分的流量，因此通过预设比率模拟这种流量比例，最终能够达到满足更加接近真实生产环境的需求。

最后，实时监控全链路待测系统的预设参数，当发现参数问题之后可以及时做到调整、反馈。

通过上述步骤设计，我们的技术方案最终达到了在交易系统中进行全链路压力测试的效果。

[0027]在某些具体的实施例中，还包括步骤，监控用户操作生成的请求信息的多条链路流量请求，筛选其中核心链路的流量请求脚本，根据核心链路的流量请求脚本配置不同接口的压力测试脚本流量。

在我们的方案中，核心链路与非核心链路可以自主定义，在具体的实施方案中，技术人员可以在实际运行时进行核心链路、非核心链路的选择，比如关闭某些非核心链路以满足测试需求，也可以根据筛分结果在非核心链路输入少量压力测试脚本，在核心链路输入大量压力测试脚本，都能够达到预设的效果。

[0028]在其他一些进一步的实施例中，还包括步骤，获取业务日志中请求信息的链路流量信息，根据所述链路流量信息生成链路流量模型，根据链路流量模型将压力测试脚本运行于全链路待测系统。

这里的业务日志包括终端系统日志、APP系统日志和数据库日志等等，在其中记录请求信息被生产环境接收后的系统响应的各链路的流量分配信息，从而根据该流量信息生成链路流量模型，链路流量模型记载了系统中个链路对业务操作响应时的个链路的流量分配信息。

因此当需要运行压力测试脚本的时候，便可以根据之前步骤生成的链路流量模型分配压力测试脚本的流量。

[0029]为了更好地进行生产环境的压力测试，在进一步的实施例中，获取用户信息步骤具体进行，获取前端活跃度排行为前预设个数的用户，获取其操作生成的请求信息。

活跃用户的操作全，指令多，选取预设排名靠前的相关用户的操作生成请求信息更有利于压力测试的进行。

本实施例中所述活跃度排行包括交易次数排行、交易额排行或APP有效操作数排行。

[0030]下面的实施例中还介绍一种全链路压力测试的实施方法，通过如下步骤进行，如图2所示，包括步骤S200：基础信息配置
[0031]压力测试平台可配置标的服务器的日志读取信息、压力链路相关信息、压力指标预警配置、其它配置。

[0032]日志读取信息包含服务器IP、端口、读取日志路径；
[0033]链路配置信息包含服务器IP、端口、网关、中间件、接口、后端服务、数据库等信息；[0034]压力指标预警配置指CPU消耗配置、内存消耗配置等性能指标配置；
[0035]其它配置包含活跃用户排行前名次设置等。

[0036]步骤S210：获取活跃用户信息
[0037]一键拉取活跃用户信息：从生产数据库中拉取交易次数排行前N名的用户(也可人工设置相关账号，以下统称活跃用户)，记录下用户资金账号等相关信息并发送至监控模块。

[0038]步骤S220：监控活跃用户自动生成链路压力初始脚本和流量脚本
[0039]根据活跃用户资金账号(支持修改)，系统自动录制下前端APP活跃用户的交易行为和数据库交易信息生成多条业务交易链路初始压力脚本。

(通过对生产日志的大数据分析，发现大约20％的接口占用了80％的流量，因此通过活跃用户行为确定交易业务链路。

) [0040]同时系统拉取活跃用户的APP系统日志和数据库日志，生成流量脚本，并自动发送至“发压机”(流量模拟组件)
[0041]步骤S230：多交易链路压力脚本模板建成和日志流量建模
[0042]S230-1：压力脚本模板生成
[0043]根据“业务交易链路初始脚本”对压力脚本进行筛选、分解、参数化、设定事务名称等操作，生成多条交易链路压力脚本模板，交易链路压力脚本模板已包含交易中各事务脚本信息(包含事务名称、事务请求、请求回执等)。

[0044]S230-2：日志流量建模
[0045]根据活跃用户APP系统日志和数据库日志，经过平台解密，生成前端APP用户流量基础数据，以供后期压力测试时放大流量使用。

[0046]步骤S240：环境准备(环境设置)
[0047]包含一键备份数据库、公告编辑与发布、开启与关闭某些服务、变量赋值(目标服务器的IP和端口、接口、数据库、后端服务)、前端交易用户密码重置等，最大限度地模拟生产环境。

[0048]步骤S250：预测试
[0049]在压力服务平台创建预测试任务名称，选定交易链路压力模板，开启预测试。

预测试主要是验证环境情况、事务脚本、流量模拟等功能是否正常。

只有预测试通过后，才能正式压力测试，为正式压力测试做数据参考准备。

[0050]步骤S260：真实压力测试开启(并发设置与开启)
[0051]创建测试任务名称，关联预测试任务，选择测试链路压力模板脚本(会默认加载预测试任务的压力链路脚本，可修改)、创建虚拟用户数(并发设置)、选择流量数据和流量模式(放大倍数设置和分配方式，分配方式有自动分配和固定比例)、异常监控指标选择(多选)、选择预警人员、压力模式选择(递增、持续模式、瞬间完成)。

[0052]流量模式：
[0053]放大倍数：支持1-100倍放大。

[0054]分配方式：自动分配是根据交易链路压力事务数而自动分配，固定比例则是分摊“发压机”的流量，如一个任务或多个任务同时开启，每个任务包含不同的交易链路，可为每个链路设置比例值，则发压机会自动为链路分配比例流量。

[0055]压力模式：
[0056]1)递增压力模式：每N秒递增M倍流量进行压力的模式；
[0057]2)平行模式：持续压力使用，以固定流量持续N秒的模式进行压力。

[0058]3)瞬间完成模式：以固定流量进行一次压力行为，完成就结束压力生成报告。

[0059]步骤S270：测试监控与异常处理
[0060]压测开始时，自动触发了压测验证检查、压测进展播报、收集压测监控/告警等数据，来检测服务是否异常，并根据配置来终止压测，能够故障时及时止损。

最后，报告生成模块收到压测终止事件，汇总各种信息，自动生成包括压测基本信息等多维度信息的压测报告，节省了一些压测后分析的时间。

[0061]1)在压力测试过程中，系统以数据和图表形式实时监控。

[0062]2)运行中的压测监控数据是每隔10s刷新一次，可以实时查看TPS，方便客户的开发或者运维人员第一时间发现和定位性能瓶颈。

[0063]3)如果出现严重的错误，如整个客户系统瘫痪，可以立刻终止当前测试任务，节省VUM。

[0064]4)监控数据包含：TPS、QPS、VU、VUM、吞吐量、事务响应时间。

[0065]5)测试异常监控
[0066]监控过程中，若发现以下异常指标达到配置值则进行报警操作，能自动汇集异常日志发送邮件和提醒短信给测试成员，并强制进行终止压力测试。

[0067]CPU消耗大等于配置值(默认80％)；
[0068]内存消耗大等于配置值(默认80％)
[0069]磁盘IO达到配置值；
[0070]数据库IO达到配置值；
[0071]网络IP达到配置值；
[0072]步骤S280：报告生成
[0073]压力完成后，系统自动生成报告，包含测试任务运行时间、事务响应时间、中间件时间、数据库读取时间、发压机发送流量、系统接收流量、吞吐量、系统资源消耗情况，网关情况。

[0074]步骤S290：还原
[0075]压力测试完成后，需要对环境等进行还原，支持一键还原数据，一键还原用户密码、还原被关闭的测试接口。

[0076]最终完成压力测试。

[0077]测试中监控参数的指标名词解释：
[0078]TPS(Transaction Per Second)每秒钟事务数：每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。

[0079]QPS(Queries Per Second)每秒钟请求数：如果一个脚本共3个请求，跑完一遍算一个事务数。

假如1秒钟，就跑了一遍这个脚本，那么TPS＝1，QPS＝3。

[0080]VU虚拟用户数：线上环境里的每一个操作都是一个真实用户的操作，而在测试环境不可能找来那么多的测试用户，就要用程序模拟真实用户去跑，这就是虚拟用户[0081]VUM每分钟虚拟用户数：这是一个负载参数，
[0082]吞吐量：单位时间内系统处理的客户请求数量。

一般用请求数/秒或者页面数/秒来衡量。

[0083]事务时间：应用系统从客户端请求发出开始到客户端接收到最后一个字节数据所消耗的时间。

[0084]资源使用率：负载下的基础设施资源使用情况，通常包括CPU占用率(用户使用率(％User)，系统(％System))，内存使用率，磁盘I/O，网络I/O(带宽的流入和流出)。

[0085]本发明还设计了一种交易系统的全链路压力测试存储介质，所述存储介质存储有计算机程序，所述计算机程序在被运行时执行包括如下步骤，获取用户操作生成的请求信息，根据所述请求信息生成压力测试脚本，将压力测试脚本运行于全链路待测系统，按照预设比率配置不同接口的压力测试脚本流量，并实时监控全链路待测系统的预设参数；所述全链路待测系统为提供证券交易服务的生产环境架构或模拟生产环境架构。

[0086]进一步地，所述计算机程序在被运行时还执行包括步骤，监控用户操作生成的请求信息的多条链路流量请求，筛选其中核心链路的流量请求脚本，根据核心链路的流量请求脚本配置不同接口的压力测试脚本流量。

[0087]进一步地，所述计算机程序在被运行时还执行包括步骤，获取业务日志中请求信息的链路流量信息，根据所述链路流量信息生成链路流量模型，根据链路流量模型将压力测试脚本运行于全链路待测系统。

[0088]具体地，所述计算机程序在被运行时执行步骤获取前端活跃度排行为，前预设个数的用户，获取其操作生成的请求信息；
[0089]其中所述活跃度排行包括交易次数排行、交易额排行或APP有效操作数排行。

[0090]具体地，所述预设参数包括每秒事务数、每秒请求数、虚拟用户数、每分钟虚拟用户数、事务时间或资源使用率。

[0091]需要说明的是，尽管在本文中已经对上述各实施例进行了描述，但并非因此限制本发明的专利保护范围。

因此，基于本发明的创新理念，对本文所述实施例进行的变更和修改，或利用本发明说明书及附图内容所作的等效结构或等效流程变换，直接或间接地将以上技术方案运用在其他相关的技术领域，均包括在本发明的专利保护范围之内。