一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

一种系统压力性能测试的方法和装置与流程

2021-12-07 21:05:00 来源:中国专利 TAG:


1.本发明涉及计算机技术领域,尤其涉及一种系统压力性能测试的方法和装置。


背景技术:

2.服务系统容量测试可以准确、高效地给出系统是否达标并发现系统问题,进而确定系统的优化方向并指导系统的扩容决策。服务系统容量验证主要包括:服务请求量的预估、系统容量预估和扩容、扩容后的服务容量验证几个部分。验证系统容量是否可以支撑峰值流量,常用的方法是对服务系统做端到端的性能测试。目前,现有的系统容量测试数据多是通过收集并修改请求日志的方法来获得的,即:使用线下日常请求产生的测试数据或者补充一些人造的假数据以增加测试数据等。
3.在实现本发明过程中,发明人发现现有技术中至少存在如下问题:
4.日常请求的测试数据较少,在保证时效性的前提下,不能满足模拟峰值流量场景;人造请求数据的顺序和间隔时间往往是固定的,需要较长的数据生产和验证时间,才能保证数据服务实际请求情况,且当调整请求的特征时,需要修改代码重新生产测试数据,花费大量时间。


技术实现要素:

5.有鉴于此,本发明实施例提供一种系统压力性能测试的方法和装置,能够使同一用户的多次请求保序、同一用户的多次请求的间隔时间仿真、并且保证了请求的有效和时效性、且在执行测试的过程中调整请求数据的特征,满足了测试人员对测试的灵活性的要求,缩短了整个测试的时间,提高了测试效率。
6.为实现上述目的,根据本发明实施例的一个方面,提供了一种系统压力性能测试的方法。
7.一种系统压力性能测试的方法,包括:将在线请求数据复制到映射模型中;使用所述映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试。
8.可选地,使用所述映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型包括:获取每个请求数据对应的用户标识和预设的规约模型的个数;使用所述映射模型将每个请求的用户标识对所述规约模型的个数进行取模,以将同一用户的请求数据进行整合;按照请求顺序,将同一用户的请求数据串行发送到同一规约模型。
9.可选地,所述特征调整包括:调整请求数据的流量大小、调整请求数据的组成成分的比例、调整请求的间隔时间、调整每秒请求数、调整连接数。
10.可选地,若所述特征调整为调整请求数据的流量大小,则使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试包括:预设一个虚拟用户标识集合;使用所述规约模型获取所述请求数据对应的用户标识,并将所述用户标识映射到所述虚拟用户标识集合中的虚拟用户标识;对所述请求数据进行复制,并将复制的请求数据与映射的
虚拟用户标识相关联来调整请求数据的流量大小,以进行系统压力性能测试。
11.可选地,若所述特征调整为调整请求数据的组成成分的比例,则使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试包括:使用所述规约模型获取预设的请求数据的组成成分类别以及每个组成成分的预期比例;将所述请求数据映射到不同的组成成分类别;通过放大部分类别的组成成分来调整请求数据的组成成分的比例,以进行系统压力性能测试。
12.可选地,使用后补偿机制来调整请求数据的组成成分的比例以动态调整请求数据的组成成分的比例。
13.可选地,若所述特征调整为调整请求的间隔时间,则使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试包括:使用所述规约模型延迟部分请求的发送时间,来调整请求的间隔时间,以进行系统压力性能测试。
14.可选地,通过延迟请求时间在前的请求,正常发送请求时间在后的请求,来缩短请求的间隔时间;通过延迟发送请求时间在后的请求,正常发送请求时间在前的请求,来增加请求的间隔时间。
15.根据本发明实施例的另一方面,提供了一种系统压力性能测试的装置。
16.一种系统压力性能测试的装置,包括:请求复制模块,用于将在线请求数据复制到映射模型中;请求映射模块,用于使用所述映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;请求调整模块,用于使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试。
17.可选地,所述请求映射模块还用于:获取每个请求数据对应的用户标识和预设的规约模型的个数;使用所述映射模型将每个请求的用户标识对所述规约模型的个数进行取模,以将同一用户的请求数据进行整合;按照请求顺序,将同一用户的请求数据串行发送到同一规约模型。
18.可选地,所述特征调整包括:调整请求数据的流量大小、调整请求数据的组成成分的比例、调整请求的间隔时间、调整每秒请求数、调整连接数。
19.可选地,若所述特征调整为调整请求数据的流量大小,则所述请求调整模块还用于:预设一个虚拟用户标识集合;使用所述规约模型获取所述请求数据对应的用户标识,并将所述用户标识映射到所述虚拟用户标识集合中的虚拟用户标识;对所述请求数据进行复制,并将复制的请求数据与映射的虚拟用户标识相关联来调整请求数据的流量大小,以进行系统压力性能测试。
20.可选地,若所述特征调整为调整请求数据的组成成分的比例,则所述请求调整模块还用于:使用所述规约模型获取预设的请求数据的组成成分类别以及每个组成成分的预期比例;将所述请求数据映射到不同的组成成分类别;通过放大部分类别的组成成分来调整请求数据的组成成分的比例,以进行系统压力性能测试。
21.可选地,使用后补偿机制来调整请求数据的组成成分的比例以动态调整请求数据的组成成分的比例。
22.可选地,若所述特征调整为调整请求的间隔时间,则所述请求调整模块还用于:使用所述规约模型延迟部分请求的发送时间,来调整请求的间隔时间,以进行系统压力性能测试。
23.可选地,通过延迟请求时间在前的请求,正常发送请求时间在后的请求,来缩短请求的间隔时间;通过延迟发送请求时间在后的请求,正常发送请求时间在前的请求,来增加请求的间隔时间。
24.根据本发明实施例的又一方面,提供了一种系统压力性能测试的电子设备。
25.一种系统压力性能测试的电子设备,包括:一个或多个处理器;存储装置,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现本发明实施例所提供的系统压力性能测试的方法。
26.根据本发明实施例的再一方面,提供了一种计算机可读介质。
27.一种计算机可读介质,其上存储有计算机程序,所述程序被处理器执行时实现本发明实施例所提供的系统压力性能测试的方法。
28.上述发明中的一个实施例具有如下优点或有益效果:通过将在线请求数据复制到映射模型中;使用映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;使用规约模型对请求数据进行特征调整以进行系统压力性能测试,即可使同一用户的多次请求保序、同一用户的多次请求的间隔时间仿真、并且保证了请求的有效和时效性、且在执行测试的过程中调整请求数据的特征,满足了测试人员对测试的灵活性的要求,缩短了整个测试的时间。本发明通过复制线上流量与测试执行阶段动态调整请求特征相结合,来准确、保真、高效地模拟用户行为。本发明复制线上流量与测试执行阶段动态调整请求特征相结合的方案,直接跳过线下数据生产阶段,提高了测试效率。
29.上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
30.附图用于更好地理解本发明,不构成对本发明的不当限定。其中:
31.图1是本发明一个实施例的性能测试的实现流程示意图;
32.图2是根据本发明实施例的系统压力性能测试的方法的主要步骤示意图;
33.图3是本发明一个实施例的系统压力性能测试的实现原理示意图;
34.图4是根据本发明实施例的系统压力性能测试的装置的主要模块示意图;
35.图5是本发明实施例可以应用于其中的示例性系统架构图;
36.图6是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。
具体实施方式
37.以下结合附图对本发明的示范性实施例做出说明,其中包括本发明实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本发明的范围和精神。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。
38.每年在电商大促活动期间,用户访问和业务量都会剧增,这对电商平台相关的服务系统带来了严峻的挑战。为了服务好大促活动,研发部门需要在大促前完成:服务请求量的预估、系统容量预估和扩容、扩容后的服务容量验证。服务系统容量验证是要准确和高效
的给出系统是否达标、发现问题,来确定系统的优化方向,指导系统的扩容决策。
39.验证系统容量是否可以支撑大促峰值流量,常用的方法是对服务系统做端到端的性能测试。互联网系统,特别是电商服务,需要模拟以下几个特征,保持与实际一致,来保障测试结果的准确、可靠度:
40.(1)请求的有效性和时效性,保证系统按照完整的逻辑来处理请求;
41.(2)单个用户的多个请求的顺序和间隔时间,模拟真实用户按一定逻辑顺序和间隔时间请求服务,只有这样,服务系统工作方式跟生产中才能一致;
42.(3)请求的组成比例尽可能和大促时比例一致,也是保证测试准确的重要因素,因为访问系统请求有多种类型,且处理它们服务所需要时间长短不一;
43.(4)要求请求达到一定数量级来模拟大促峰值流量,请求数量受测试执行时间、性能测试的qps和请求是否可以重复等因素影响。
44.现有生产性能测试请求数据的技术不能很好的模拟大促时的请求特征:
45.(1)同一用户的多次请求,可能落在多个机器上,分布于多个文件系统中。这样很难做到保证顺序的提取测试请求;保证请求的间隔时间更是不可能;
46.(2)集群的性能测试一般在大促前1

2个月,日常用户请求类型组成比例跟大促时候相差很大;
47.(3)为了保证请求时效性,现有技术需要在测试前24小之内开始生产,确保促销券或活动没有失效;而为了保证请求达到千万级别和上亿级别,需要花很长时间生产、传输、存储数据。这样“保证数据的时效性”和“数据要达到一定数量级”互相矛盾,需要平衡;
48.(4)另外,由于大促峰值访问量是日常几倍,甚至十、几十倍,这样日常24小时内抓取的日志中的请求根本无法满足一定数量级。而需要抓取48小时、甚至更长时间的请求数据才能解决数据量的问题,但是会影响数据的时效性。
49.总之,仅使用线下生产测试数据的方式,由于日常请求的测试数据较少,在保证时效性的前提下,不能满足模拟峰值流量场景;人造请求数据的顺序和间隔时间往往是固定的,需要较长的数据生产和验证时间,才能保证数据服务实际请求情况,且当调整请求的特征时,需要修改代码重新生产测试数据,花费大量时间。
50.本发明的实现原理是把性能测试中需要模拟的请求特征,通过“复制线上引流”和“性能测试执行”两个阶段解决。同一用户的多次请求保序、同一用户的多次请求的间隔时间仿真、请求的有效和时效性,这个几个特征通过“复制线上流量”可以轻松解决;其他请求的特征调整,比如:请求类型组成的比例、放大或缩小在线用户请求流量、请求的间隔时间、每秒请求数、并发请求的最大连接数等,放在“性能测试执行”阶段,通过性能测试工具来解决。
51.图1是本发明一个实施例的性能测试的实现流程示意图。如图1所示,在复制线上流量阶段,将在线请求数据复制用于进行性能测试;之后进入性能测试执行阶段,将对复制的在线请求数据进行特征调整以进行性能测试。首先,判断是否需要调整请求数据的组成成分的比例,请求数据的组成成分类别具体可根据请求的参数来进行获取,例如可根据请求参数中包括的终端类型client_type参数来对请求数据进行分类:app(应用程序)请求的请求参数中client_type=app,pc(个人计算机)请求的请求参数中client_type=pc,如此即可将请求数据分为app请求和pc请求。若需要调整比例,则调整在线请求流量组成比例并
扩大在线请求流量;否则,直接扩大在线请求流量。通常情况下,在进行系统性能测试时,需要测试系统容量,而复制的线上流量有限,故而需要对复制的线上流量进行放大处理以尽量准确地模拟现实大促的情况。在扩大在线请求流量之后,判断是否要调整请求的间隔时间,若是,则调整请求的间隔时间,否则,判断是否要调整每秒请求数以及是否要调整最大连接数。在本发明的实施例中,调整每秒请求数qps和调整并发请求的最大连接数等请求特征,并非是本发明的重点,后面将不展开描述。
52.在本发明的实施例中,大部分的请求特征放在性能测试执行阶段进行调整,满足了测试人员的对测试的灵活性的要求;缩短了整个测试的时间,包括:生产数据的时间、重新执行生产数据的时间(现有技术在调整请求特征后,需要重新生产数据)。
53.本发明的动态调整请求特征的系统压力性能测试方法主要包括两个阶段:复制线上流量阶段和性能测试执行阶段。其中,复制线上流量阶段,直接放大日常线上的实时请求,相比线下生产的测试数据,其优势在于,用户请求的顺序、请求的间隔时间、请求多样性、请求的分布等特征上与测试场景(大促)更接近。特别是同一用户的多次请求的间隔时间与真实用户完全一致,这是线下生产测试请求数据难以做到的。性能测试执行阶段,依靠测试工具来实现测试请求特征的调整,测试工具在框架上需要具备这些功能:一个高性能的http或tcp编程框架;支持多进程或多线程的并发处理;使用基于事件驱动的架构,方便扩展;提供api或sdk可以二次编程。
54.在性能测试执行阶段,测试工具主要实现的功能如下:
55.1、相同用户多个请求保序。把相同用户的多个请求处理放到一个测试工具执行进程中。在单工作进程、单线程的环境串行处理请求,同一用户的多个请求,保序、间隔是不被改变的;
56.2、扩大在线用户数。采用替换用户标识id的方式,扩大请求数量,模拟更多用户访问系统;
57.3、调整请求分类组成的比例。把请求映射到不同的分类,根据这些分类的预期比例,采用高效的方式放大某些分类,满足预期比例;
58.4、调整用户请求的间隔时间。由于同一用户的多个请求是在一个单进程单线程的环境下,严格串行执行的;通过延迟发送请求时间在前的请求,正常发送请求时间在后的请求,来缩短间隔时间;反之,延迟发送请求时间在后的请求,正常发送请求时间在前的请求,来增加间隔时间。当然,为了保证间隔时间符合正态分布,增加或缩短的延迟时间可以是一个随机值。
59.下面结合图2和图3来介绍本发明的性能测试方法的具体实现过程。图2是根据本发明实施例的系统压力性能测试的方法的主要步骤示意图;图3是本发明一个实施例的系统压力性能测试的实现原理示意图。
60.如图2所示,本发明实施例的系统压力性能测试的方法主要包括如下的步骤s201至步骤s203。
61.步骤s201:将在线请求数据复制到映射模型中;
62.步骤s202:使用映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;
63.步骤s203:使用规约模型对请求数据进行特征调整以进行系统压力性能测试。
64.根据上述的步骤s201至步骤s203,即可使同一用户的多次请求保序、同一用户的多次请求的间隔时间仿真、并且保证了请求的有效和时效性、且在执行测试的过程中调整请求数据的特征,满足了测试人员对测试的灵活性的要求,缩短了整个测试的时间。
65.如图3所示,在本发明的一个实施例中,通过引流工具go replay或tcp copy等复制在线服务集群的真实用户请求的流量,到由openresty(基于nginx的可伸缩的web平台)集群组成的性能测试工具,通过openresty集群组成了映射(map)模型和规约(reduce)模型,动态调整请求特征高保真的模拟大促时用户的行为;再把请求发送到被测服务集群。
66.goreplay是一款开源的对http或tcp进行流量复制、录制和回放的测试工具。通过简单的配置,可以高效、对线上流量无影响地把线上真实流量复制到测试环境中。
67.openresty是一个基于nginx与lua的高性能web平台,其内部集成了大量精良的lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态web应用、web服务和动态网关。nginx的编程模型可以在单进程、单线程的运行环境下顺序依次处理请求。
68.具体实现时,为了保证相同用户的请求发送到同一个openresty保序,并且支持多个压测任务同时执行,把若干个openresty实例分成2组,分别实现映射(map)模型和规约(reduce)模型,以完成分流、动态调整请求特征的功能。
69.根据本发明的实施例,在使用映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型时,具体可以包括:
70.获取每个请求数据对应的用户标识和预设的规约模型的个数;
71.使用映射模型将每个请求的用户标识对规约模型的个数进行取模,以将同一用户的请求数据进行整合;
72.按照请求顺序,将同一用户的请求数据串行发送到同一规约模型。
73.mapreduce是面向大数据并行处理的计算模型、框架和平台,它隐含了以下三层含义:一个基于集群的高性能并行计算平台;一个并行计算与运行软件框架;一个并行程序设计模型与方法。第一组openresty实例实现映射函数(map)功能,读取和处理请求。一个映射函数(map)是对请求队列中的每一个请求进行指定的操作。在实现上,将每个请求的用户标识id对第二组openresty的实例个数取模,从而把相同用户的请求发送到同一个第二组openresty实例。第二组openresty实例实现规约函数(reduce)功能,规约或者称为简约操作(reduce)是对映射函数(map)处理后的请求集合进行特征调整。
74.在本发明的实施例中,特征调整主要可以包括:调整请求数据的流量大小、调整请求数据的组成成分的比例、调整请求的间隔时间、调整每秒请求数、调整连接数等。
75.根据本发明的一个实施例,若所述特征调整为调整请求数据的流量大小,则使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试包括:
76.预设一个虚拟用户标识集合;
77.使用所述规约模型获取所述请求数据对应的用户标识,并将所述用户标识映射到所述虚拟用户标识集合中的虚拟用户标识;
78.对所述请求数据进行复制,并将复制的请求数据与映射的虚拟用户标识相关联来调整请求数据的流量大小,以进行系统压力性能测试。
79.规约模型接收到映射模型发送过来的请求数据后,对请求数据进行特征调整以用
于进行性能测试。通过第一组openresty集群实现的映射模型,把相同用户的请求数据分发到同一个规约模型作为数据队列的输入。在性能测试的场景下,需要调整请求数据的流量大小时,一般是要将在线请求数据进行流量放大。具体实现方法是:准备一个虚拟用户标识id集合,它跟大促场景下实际用户数在量级上基本一致,例如,可以将用户在网站注册用户名后,系统生成的与每个用户名一一对应的用户id作为此处准备的虚拟用户id,并且选取与大促场景下用户数量级相同的虚拟用户id构成虚拟用户id集合。然后,为每个虚拟用户id进行编号,假设虚拟用户id集合大小为size,则把从0到(size

1)分别映射到每个虚拟用户id。例如:0对应虚拟用户a,1对应虚拟用户b,2对应虚拟用户c,
……
,(size

1)对应虚拟用户size。
80.当需要对某个请求数据进行放大时,首先获取该请求数据的用户id,并把该请求数据的用户id转化为数字型;然后将该数字型的用户id对虚拟用户id集合的大小size取模,映射到一个不同的固定虚拟用户id。这样做的目的是,确保同一个用户的多个请求,被另外一个或者多个用户的id替换,生成新的请求(原有请求保留一份)。比如用户id=a依次有三个请求,当放大三倍的时候,会复制出与虚拟用户id=b、虚拟用户id=c或虚拟用户id=d分别对应的三个请求,共九个新请求。如此,即实现了对在线请求数据流量的扩大。
81.在进行性能测试的过程中,若需要对请求数据流量进行缩小,则可将部分用户id的请求数据屏蔽,以实现对请求数据流量的缩小。如此,即可在保证请求顺序和时间间隔的情况下,进行请求数据流量的大小调整。
82.在本发明的另一个实施例中,若所述特征调整为调整请求数据的组成成分的比例,则使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试包括:
83.使用所述规约模型获取预设的请求数据的组成成分类别以及每个组成成分的预期比例;
84.将所述请求数据映射到不同的组成成分类别;
85.通过放大部分类别的组成成分来调整请求数据的组成成分的比例,以进行系统压力性能测试。
86.在本发明的实施例中,由于nginx等的规约模型是单进程、单线程顺序处理一个队列的请求,只有当一个请求完成才会处理下一个请求,所以可以采用后补偿机制实现调整请求数据的组成比例,同时,它也不会影响队列处理的效率。具体的实现步骤是:首先获取预设的请求数据的组成成分类别以及每个组成成分的预期比例,例如:以请求数据对应的设备类别作为请求数据的组成成分类别,则根据app请求参数client_type=app、pc请求参数client_type=pc即可进行请求数据的组成成分统计,假设app请求的预期比例为70%,pc请求的预期比例为30%。然后,使用计数器统计一批请求(比如1000条)的组成成分的比例,并判断与预期比例是否一致,例如:假设使用计数器统计该批请求的组成成分的比例为app请求为60%(600个),pc请求为40%(400个),则显然与预期比例是不同的。之后,通过放大部分类别的组成成分来调整请求数据的组成成分的比例,以使得请求的组成成分的比例与预期比例一致,在此实施例中,即通过放大app请求的比例以使得请求的组成成分的比例与预期比例一致。为了不影响测试执行的效率,使用后补偿机制来调整请求数据的组成成分的比例以动态调整请求数据的组成成分的比例。即:根据当前批次的请求数据的处理结果来调整请求数据的组成成分的比例,以使得下一批请求按比例进行放大,从而实现了动
态调整请求数据的组成成分的比例,以更准确地模拟线上请求情况。
87.在本发明的又一个实施例中,若所述特征调整为调整请求的间隔时间,则使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试包括:使用所述规约模型延迟部分请求的发送时间,来调整请求的间隔时间,以进行系统压力性能测试。具体地,可以通过延迟请求时间在前的请求,正常发送请求时间在后的请求,来缩短请求的间隔时间;通过延迟发送请求时间在后的请求,正常发送请求时间在前的请求,来增加请求的间隔时间。
88.根据本发明的技术方案,因为直接复制线上流量,用户请求顺序和间隔跟实际情况非常一致,一般情况下,并不需要重新调整用户请求的间隔时间。但是,在不同场景下,有些服务的实现效果也是不同的,例如:在大促场景下,用户需要限时抢购,用户浏览商品的时间比平时短,这导致了用户请求的间隔也会相应缩短。
89.在本发明的第二组openresty集群实现的归约模型里,也实现了调整请求间隔时间的功能。由于同一用户的多个请求是在一个单进程、单线程的环境,严格串行执行的,故而openresty通过延迟发送多个请求中请求时间在前面的请求,正常发送请求时间在后面的请求(按照队列里正常顺序发送),来缩短请求之间的间隔时间;反之,延迟发送请求时间在后面的请求,正常发送请求时间在前面的请求,来增加间隔时间。当然,为了保证间隔时间符合正态分布,延迟时间可以设置成一个随机值。
90.以上,即为本发明的性能过测试的实现过程,相比于现有技术来说,现有技术是通过收集并修改请求日志的方法生成性能测试数据,模拟真实用户行为;而本发明是通过复制线上流量与测试执行阶段动态调整请求特征相结合,来准确、保真、高效地模拟用户行为。本发明“复制线上流量” “测试执行阶段动态调整请求特征”的方案,直接跳过“线下数据生产”阶段,提高了测试效率,也是与现有技术方案的明显区别。
91.根据本发明的另一个方面,提供了一种系统压力性能测试的装置。图4是根据本发明实施例的系统压力性能测试的装置的主要模块示意图。如图4所示,本发明实施例的系统压力性能测试的装置400主要包括请求复制模块401、请求映射模块402和请求调整模块403。
92.请求复制模块401,用于将在线请求数据复制到映射模型中;
93.请求映射模块402,用于使用所述映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;
94.请求调整模块403,用于使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试。
95.根据本发明的一个实施例,请求映射模块402还可以用于:
96.获取每个请求数据对应的用户标识和预设的规约模型的个数;
97.使用所述映射模型将每个请求的用户标识对所述规约模型的个数进行取模,以将同一用户的请求数据进行整合;
98.按照请求顺序,将同一用户的请求数据串行发送到同一规约模型。
99.根据本发明的另一个实施例,所述特征调整包括:
100.调整请求数据的流量大小、调整请求数据的组成成分的比例、调整请求的间隔时间、调整每秒请求数、调整连接数。
101.根据本发明的又一个实施例,若所述特征调整为调整请求数据的流量大小,则请求调整模块403还可以用于:
102.预设一个虚拟用户标识集合;
103.使用所述规约模型获取所述请求数据对应的用户标识,并将所述用户标识映射到所述虚拟用户标识集合中的虚拟用户标识;
104.对所述请求数据进行复制,并将复制的请求数据与映射的虚拟用户标识相关联来调整请求数据的流量大小,以进行系统压力性能测试。
105.根据本发明的又一个实施例,若所述特征调整为调整请求数据的组成成分的比例,则请求调整模块403还可以用于:
106.使用所述规约模型获取预设的请求数据的组成成分类别以及每个组成成分的预期比例;
107.将所述请求数据映射到不同的组成成分类别;
108.通过放大部分类别的组成成分来调整请求数据的组成成分的比例,以进行系统压力性能测试。
109.在本发明的又一个实施例中,使用后补偿机制来调整请求数据的组成成分的比例以动态调整请求数据的组成成分的比例。
110.根据本发明的再一个实施例,若所述特征调整为调整请求的间隔时间,则请求调整模块403还可以用于:
111.使用所述规约模型延迟部分请求的发送时间,来调整请求的间隔时间,以进行系统压力性能测试。
112.在本发明的再一个实施例中,通过延迟请求时间在前的请求,正常发送请求时间在后的请求,来缩短请求的间隔时间;通过延迟发送请求时间在后的请求,正常发送请求时间在前的请求,来增加请求的间隔时间。
113.根据本发明实施例的技术方案,通过将在线请求数据复制到映射模型中;使用映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;使用规约模型对请求数据进行特征调整以进行系统压力性能测试,即可使同一用户的多次请求保序、同一用户的多次请求的间隔时间仿真、并且保证了请求的有效和时效性、且在执行测试的过程中调整请求数据的特征,满足了测试人员对测试的灵活性的要求,缩短了整个测试的时间。本发明通过复制线上流量与测试执行阶段动态调整请求特征相结合,来准确、保真、高效地模拟用户行为。本发明“复制线上流量”与“测试执行阶段动态调整请求特征”相结合的方案,直接跳过“线下数据生产”阶段,提高了测试效率。
114.图5示出了可以应用本发明实施例的系统压力性能测试的方法或系统压力性能测试的装置的示例性系统架构500。
115.如图5所示,系统架构500可以包括终端设备501、502、503,网络504和服务器505。网络504用以在终端设备501、502、503和服务器505之间提供通信链路的介质。网络504可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
116.用户可以使用终端设备501、502、503通过网络504与服务器505交互,以接收或发送消息等。终端设备501、502、503上可以安装有各种通讯客户端应用,例如性能测试类应用、购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件
等(仅为示例)。
117.终端设备501、502、503可以是具有显示屏并且支持网页浏览的各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
118.服务器505可以是提供各种服务的服务器,例如对用户利用终端设备501、502、503所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的性能测试请求等数据进行将在线请求数据复制到映射模型中;使用所述映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;使用所述规约模型对所述请求数据进行特征调整以进行性能测试等处理,并将处理结果(例如性能测试结果、系统改进信息等
‑‑
仅为示例)反馈给终端设备。
119.需要说明的是,本发明实施例所提供的系统压力性能测试的方法一般由服务器505执行,相应地,系统压力性能测试的装置一般设置于服务器505中。
120.应该理解,图5中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
121.下面参考图6,其示出了适于用来实现本发明实施例的终端设备或服务器的计算机系统600的结构示意图。图6示出的终端设备或服务器仅仅是一个示例,不应对本发明实施例的功能和使用范围带来任何限制。
122.如图6所示,计算机系统600包括中央处理单元(cpu)601,其可以根据存储在只读存储器(rom)602中的程序或者从存储部分608加载到随机访问存储器(ram)603中的程序而执行各种适当的动作和处理。在ram 603中,还存储有系统600操作所需的各种程序和数据。cpu 601、rom 602以及ram 603通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。
123.以下部件连接至i/o接口605:包括键盘、鼠标等的输入部分606;包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分607;包括硬盘等的存储部分608;以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至i/o接口605。可拆卸介质611,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器610上,以便于从其上读出的计算机程序根据需要被安装入存储部分608。
124.特别地,根据本发明公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本发明公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分609从网络上被下载和安装,和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(cpu)601执行时,执行本发明的系统中限定的上述功能。
125.需要说明的是,本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd

rom)、光存储器件、磁存储器件、
或者上述的任意合适的组合。在本发明中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、rf等等,或者上述的任意合适的组合。
126.附图中的流程图和框图,图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
127.描述于本发明实施例中所涉及到的单元或模块可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中,例如,可以描述为:一种处理器包括请求复制模块、请求映射模块和请求调整模块。其中,这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定,例如,请求复制模块还可以被描述为“用于将在线请求数据复制到映射模型中的模块”。
128.作为另一方面,本发明还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的设备中所包含的;也可以是单独存在,而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该设备执行时,使得该设备包括:将在线请求数据复制到映射模型中;使用所述映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;使用所述规约模型对所述请求数据进行特征调整以进行系统压力性能测试。
129.根据本发明实施例的技术方案,通过将在线请求数据复制到映射模型中;使用映射模型将同一用户的请求数据,按照请求顺序串行发送到同一规约模型;使用规约模型对请求数据进行特征调整以进行系统压力性能测试,即可使同一用户的多次请求保序、同一用户的多次请求的间隔时间仿真、并且保证了请求的有效和时效性、且在执行测试的过程中调整请求数据的特征,满足了测试人员对测试的灵活性的要求,缩短了整个测试的时间。本发明通过复制线上流量与测试执行阶段动态调整请求特征相结合,来准确、保真、高效地模拟用户行为。本发明“复制线上流量”与“测试执行阶段动态调整请求特征”相结合的方案,直接跳过“线下数据生产”阶段,提高了测试效率。
130.上述具体实施方式,并不构成对本发明保护范围的限制。本领域技术人员应该明白的是,取决于设计要求和其他因素,可以发生各种各样的修改、组合、子组合和替代。任何
在本发明的精神和原则之内所作的修改、等同替换和改进等,均应包含在本发明保护范围之内。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献