CN106095688A - 一种软件性能测试方法及装置 - Google Patents

Abstract

本申请公开了一种软件性能测试方法，用以解决现有技术中软件性能测试的结果不准确的问题。该方法包括：获取线上软件系统接收到的第一业务请求；将获得的第一业务请求转换成预定格式的请求数据，并存储到数据库中；根据所述数据库中存储的请求数据，和预设的第二业务请求生成规则，生成第二业务请求；利用生成的第二业务请求，进行软件性能测试。本申请还公开了一种软件性能测试装置。

Description

一种软件性能测试方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种软件性能测试方法及装置。

背景技术

随着互联网技术的飞速发展，网民的数量越来越多，对互联网服务端软件系统性能的要求也越来越高。比如，当服务端的并发用户数量超过系统的承受能力时，可能会出现系统响应变慢等情况，导致用户的体验较差。

开发人员可以通过对软件系统进行软件性能测试来测试软件系统的性能，对软件系统进行软件性能测试是通过性能测试工具来进行的。所述性能测试工具可以模拟用户通过客户端对服务端的访问行为，并发地向服务端发起大量的业务请求，同时检测服务端的运行情况，以获得服务端的承受能力，如可以承受多大的并发请求数量，判断软件系统是否符合预期要求。

现有技术中，在进行软件性能测试时，开发人员会根据经验，编写测试时使用的业务请求，然后由软件性能测试系统将编写好的业务请求，并发地发送给被测试软件系统进行软件性能测试。由于开发人员编写的业务请求，无法完全涵盖被测试软件线上真实运行时会接收到的业务请求，导致软件性能测试时无法得到被测试软件在线上真实运行时可能会出现的性能问题，从而导致软件性能测试的结果不准确。

发明内容

本申请实施例提供一种软件性能测试方法，用以解决现有技术中软件性能测试的结果不准确的问题。

本申请实施例还提供一种软件性能测试装置，用以解决现有技术中软件性能测试的结果不准确的问题。

本申请实施例采用下述技术方案：

一种软件性能测试方法，包括：

获取线上软件系统接收到的第一业务请求；

将获得的第一业务请求转换成预定格式的请求数据，并存储到数据库中；

根据所述数据库中存储的请求数据，和预设的第二业务请求生成规则，生成第二业务请求；

利用生成的第二业务请求，进行软件性能测试。

一种软件性能测试装置，包括：

线上业务请求获取单元，用于获取线上软件系统接收到的第一业务请求；

请求数据存储单元，用于将获得的第一业务请求转换成预定格式的请求数据，并存储到数据库中；

第二业务请求生成单元，用于根据所述数据库中存储的请求数据，和预设的第二业务请求生成规则，生成第二业务请求；

性能测试单元，用于利用生成的第二业务请求，进行软件性能测试。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过获取线上软件系统接收到的第一业务请求，并利用根据第一业务请求生成的请求数据，生成第二业务请求，然后利用第二业务请求进行性能测试，从而可以模拟线上真实的场景，以便发现被测试软件在线上真实运行时可能会出现的性能问题。相对于现有技术中利用开发人员根据经验编写的业务请求进行软件性能测试，提高了软件性能测试结果的准确性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例1提供的一种软件性能测试方法的实现流程示意图；

图2为本申请实施例2提供的一种软件性能测试方法的实现流程示意图；

图3为本申请实施例3提供的一种软件性能测试装置的具体结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

为解决现有技术中软件性能测试的结果不准确的问题，本申请实施例1提供一种软件性能测试方法。本申请实施例提供的软件性能测试方法的执行主体可以是软件性能测试系统，例如，对服务端进行性能测试的软件性能测试系统，等等。

为便于描述，下文以该方法的执行主体为软件性能测试系统为例，对该方法的实施方式进行介绍。可以理解，该方法的执行主体为软件性能测试系统只是一种示例性的说明，并不应理解为对该方法的限定。

该方法的实现流程示意图如图1所示，包括下述步骤：

步骤11：获取线上软件系统接收到的第一业务请求；

本申请实施例中，所述业务请求为用于使得软件系统处理某项业务的请求。比如，对于账号登录请求而言，软件系统在响应该请求时，便会处理账号登录业务。对于WEB服务端而言，所述业务请求为超文本传输协议(HyperText Transfer Protocol，HTTP)请求。

在对被测试软件系统进行测试时，为了尽可能真实地模拟线上运行时的场景，使软件性能测试时的结果更接近线上真实结果，在本申请实施例中，可以直接使用线上软件系统接收到的业务请求，为了便于描述，将线上软件系统接收到的业务请求称为第一业务请求。所述线上软件系统为与被测试软件系统相同的软件系统，或对被测软件系统进行优化前的系统。

在实际应用中，可以通过对线上软件系统的服务端口进行监听，即可获得线上软件系统接收的第一业务请求。在监听过程中，可以对端口接收到的所有业务请求进行筛选，只获取性能测试需要的业务请求。

步骤12：将获得的第一业务请求转换成预定格式的请求数据，并存储到数据库中；

直接利用线上软件系统接收到的业务请求，对被测试系统进行测试，只能通过查看被测试系统对硬件的使用情况，来对被测试系统进行测试。本申请实施例中，在后续进行软件性能测试时，为了全面地检测被测试软件的性能，性能测试模块会利用预定格式的请求数据，生成第二业务请求，然后利用第二业务请求对被测试软件进行测试。那么，本申请实施例中，可以将获得的第一业务请求，转换成性能测试模块可以利用的预定格式的请求数据。

本申请实施例中，将获得的第一业务请求转换成预定格式的请求数据，具体可以是，将第一业务请求中的请求接口、请求方式、参数值等数据进行提取，然后转换为JSONArray格式的数据。

在实际应用中，可以将得到的请求数据进行存储，以便后续软件性能测试时使用，那么，在将获得的第一业务请求转换成预定格式的请求数据时，可以对获得的第一业务请求执行序列化操作，对业务请求进行序列化，指将业务请求转换为便于存储的预定格式的请求数据的过程。

本申请实施例中，在将请求数据进行存储时，可以将得到的请求数据保存到数据库中。该数据库比如可以是Redis数据库，那么，可以以键(key)-值(value)对的形式将请求数据持久化到Redis数据库中。具体地，可以以业务请求的录制时间、主机名和接口名等数据为key，以根据业务请求生成的JSON Array为value，对请求数据进行保存。

步骤13：根据所述数据库中存储的请求数据，和预设的第二业务请求生成规则，生成第二业务请求；

基于上述存储方式将第一业务请求转换成预定格式的请求数据并存储后，在进行软件性能测试时，只需从存储有请求数据的数据库中，获取请求数据，然后根据预设的第二业务请求生成规则，即可生成第二业务请求。如果该数据库为Redis数据库，那么，可以利用Jedis读取Redis中的请求数据，作为性能测试的请求物料，生成第二业务请求。

本申请实施例中，可以将存储有请求数据的数据库中存储的请求数据，还原为步骤11中获取到的第一业务请求。由于第二业务请求所请求的主机为被测试软件系统所在的主机，与第一业务请求所请求的主机可能不同，则第二业务请求与第一业务请求的区别可以仅为主机名不同。那么所述业务请求生成规则，可以根据对第一业务请求进行序列化的规则确定。此处生成第二业务请求的过程，即为对存储有请求数据的数据库中存储的请求数据进行反序列化，得到线上软件系统接收到的业务请求的过程。

本申请实施例中，第一业务请求可能是触发软件系统执行多项业务操作的请求，如果只期望测试被测试软件系统执行其中某一项业务操作的性能，那么，可以只利用第一业务请求中、用于触发被测试软件系统执行期望测试的业务操作的请求数据，生成第二业务请求。

本申请实施例中，在对被测试软件系统进行软件性能测试时，可能会用到线上的第三方平台的业务，那么，可以在第二业务请求中添加用于和真实用户发起的业务请求进行区别的标识，以便于第三方平台可以区别测试用的业务请求和真实用户的业务请求。

本申请实施例中，第二业务请求的来源信息可以由测试人员自行定义。比如，当期望测试被测试软件系统在响应由安卓客户端发来的业务请求的性能时，可以在生成第二业务请求时，将第二业务请求的来源信息全部定义为安卓客户端。

本申请实施例中，所述第二业务请求和所述第一业务请求，可以是触发被测试软件系统处理相同业务的请求，具体而言，所述第二业务请求和第一业务请求中的请求数据可以相同。那么，利用第二业务请求进行软件性能测试时，得到的软件性能测试结果，可以等同于利用第一业务请求进行软件性能测试的结果，由于第一业务请求为线上软件系统接收到的请求，那么利用第二业务请求进行软件性能测试，可以全面覆盖线上真实环境中的各种业务请求，更加全面地对被测试软件系统进行测试，尽可能地预见被测试软件系统在线上环境中可能出现的性能问题。

步骤14：利用生成的第二业务请求，进行软件性能测试。

本申请实施例中，利用生成的第二业务请求，进行软件性能测试的过程主要包括如下子步骤：

子步骤S101：并发地向被测试软件系统发送预定数量的第二业务请求；

本申请实施例中，所述预定数量为测试人员预先设定的数量，在进行软件性能测试时，测试人员往往会预估被测试软件系统在上线后，可能会接收到的业务请求的数量，然后确定软件性能测试时的并发业务请求数量。软件测试时并发的业务请求数量，即为软件系统的并发用户数量。

需要说明的是，开发人员会根据上次软件性能测试的结果，调整本次软件性能测试时的所述预定数量，以便得到被测试软件系统能够承受的最大并发用户数。在软件性能测试时，如果被测试软件系统的响应时长小于预设的响应时长，则说明被测试软件系统能够承受本次测试的并发业务请求数，可以在下次测试时调大并发业务请求数的值，直至得到被测软件系统的最大并发用户数量。

本申请实施例中，在并发地向被测试软件系统发送预定数量的第二业务请求后，可以认为，被测试软件系统的并发用户数量即为所述预定数量。

由于线上软件系统接收到的并发第一业务请求的数量，可能尚未达到被测试软件系统的最大并发业务请求数量，因此无法获知被测试软件系统的性能瓶颈。那么，可以并发地发送预定数量的第二业务请求，来对软件系统进行性能测试。

或者，线上的被测试系统接收到的并发第一业务请求的数量达到了被测试软件系统的最大并发业务请求量，现在要测试的是优化后的被测试软件系统。那么，同样可以并发地发送预定数量的第二业务请求，来对优化后的被测试软件系统进行性能测试。

子步骤S102：获取各性能指标数据；

所述各性能指标数据，分别反映所述被测试软件系统的部分或全部模块各自在响应所述第二业务请求时的性能。所述各性能指标数据，是被测试软件系统通过执行预先注入被测试软件系统的监控代码得到的。

所述监控代码所实现的功能，包括：对所述部分或全部模块的运行情况进行监控，并根据监控结果，生成所述各性能指标数据。

软件系统在接收到业务请求时，往往会调用不止一个模块，来响应该业务请求，完成整个业务处理过程。单个模块指能够执行至少一个操作步骤的代码，在实际应用中，开发人员可以根据测试需要将被测试软件系统划分为多个模块。

本申请实施例中，可以通过检测被测试软件系统在对第二业务请求进行响应时，各个模块的性能指标数据，来确定被测试软件系统的性能。在实际应用中，各个模块的性能指标数据包括下述至少一种：各个模块执行操作耗费的时长、各个模块执行操作的错误率。

比如对于账号登录请求而言，软件系统在响应账号登录请求时，会经过至少三个步骤：首先接收用户输入的账号密码，然后校验账号密码是否正确，最后将登录结果反馈给用户终端，至此完成整个业务处理过程。如果上述三个步骤中，某一步骤耗费的时长大于预设的时长阈值，则说明执行该步骤的模块的处理性能较低，需要对该模块进行性能优化。或者，如果上述三个步骤中，某一步骤执行操作的错误率大于预设的错误率，则说明执行该步骤的模块的处理性能较低，需要对该模块进行性能优化。

在进行软件性能测试时，还可以根据软件系统的响应时长来评估软件系统的性能，所述响应时长指，从向软件系统发送业务请求到接收到软件系统的反馈所耗费的时长。

本申请实施例中，可以在被测试软件系统的代码中注入监控代码，对所述部分或全部模块的运行情况进行监控，并根据监控结果，生成所述各性能指标数据。比如，该监控代码可以记录代码开始执行操作的时刻，也可以记录代码结束操作的时刻，然后即可得到整个操作执行过程耗费的时长。开发人员可以在期望监控的模块的代码中，注入监控代码，即可监控该模块的性能指标。

在监测所述被测试软件系统在对每个第二业务请求进行响应时，各个模块执行操作耗费的时长后，可以将被测试软件系统中各个模块在对同一第二业务请求进行处理时耗费的时长存储到数据库的同一条数据记录中，该条数据记录的主键的值为该第二业务请求的唯一标识。该数据库可以是分布式时序数据库，比如可以是InfluxDB。利用分布式时序数据库，可以使用与时间有关的相关函数对数据库中的时间进行分析，比如得到各个模块执行操作的平均耗时、最短耗时、最长耗时、总计耗时等数据。

在得到各个模块执行操作的平均耗时、最短耗时、最长耗时、总计耗时等数据后，可以将本次软件性能测试中，被测试软件系统中各个模块的执行操作耗费的时间进行展示。

子步骤S103：根据所述各性能指标数据，确定被测试软件系统的性能。

本申请实施例中，在得到各性能指标数据后，便可以根据所述各性能指标数据，确定被测试软件系统的性能。进而，根据被测试软件系统的性能，即可确定处理性能低的模块，处理性能低的模块指对业务请求进行处理时耗费的硬件资源超出开发人员预期的模块，如果软件系统中某个模块占用的硬件资源过多，那么在硬件资源紧张的情况下，将会导致该模块的处理速度变慢，进而导致整个软件系统的处理速度变慢，执行操作的错误率升高，该处理性能低的模块即为软件系统性能的瓶颈。

对于各个模块执行操作耗费的时长而言，在得到各个模块执行操作的平均耗时、最短耗时、最长耗时、总计耗时等数据后，可以将各个模块中执行操作耗费的时长大于预设时长的模块，作为处理性能低的模块，即精准地定位到了被测试软件中处理性能低的模块。该预设时长的具体值，可以由测试人员根据经验值来设定。比如，可以将处理操作平均耗时大于3秒的模块作为处理性能低的模块。

在得到处理性能低的模块后，开发人员便可以有针对性地对确定的软件系统中处理性能低的模块进行性能优化。

需要说明的是，本申请实施例中，还会记录被测试软件在当前并发请求数时，对第二业务请求的响应时间，以及响应错误率等信息。所述响应时间，为从向被测试软件系统发送业务请求到接收到业务请求返回的结果所耗费的时长。所述响应错误率，为被测试软件系统返回错误结果的数量占总业务请求数量的比例。

对业务请求的响应时间和响应错误率可以反映被测试系统是否达到了最大并发用户数量。具体的，如果被测试软件系统的响应时间小于预设的响应时间，则说明被测试软件系统能够承受本次测试的并发业务请求数，可以在下次测试时调大并发业务请求数的值。同样，如果被测试软件系统的响应错误率小于预设的错误率阈值，则可以在下次测试时调大并发业务请求数的值。直至得到被测软件系统的最大并发用户数量。如果被测试软件系统的最大并发用户数量小于开发人员预期的最大并发用户数量，则开发人员会对被测软件系统中的代码进行性能优化，以便被测试系统的最大并发用户数量符合开发人员的预期。

本申请实施例1提供的软件性能测试方法，通过获取线上软件系统接收到的第一业务请求，并利用根据第一业务请求生成的请求数据，生成第二业务请求，然后利用第二业务请求进行性能测试，从而可以模拟线上真实的场景，以便发现被测试软件在线上真实运行时可能会出现的性能问题。相对于现有技术中利用开发人员根据经验编写的业务请求进行软件性能测试，提高了软件性能测试结果的准确性。

需要说明的是，实施例1所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤11的执行主体可以为设备1，步骤12的执行主体可以为设备2；又比如，步骤11和步骤12的执行主体均为设备1；等等。

实施例2

基于前述实施例1详细叙述了本申请的发明构思，为了便于更好的理解本申请的技术特征、手段和效果，下面对本申请的软件性能测试方法做进一步说明，从而形成了本申请的又一个实施例。

本申请实施例2中的软件性能测试过程与实施例1中所述软件性能测试过程相似，实施例2中没有介绍到的其它一些步骤可以参见实施例1中的相关描述，此处不再赘述。

在对该方案的实现方式进行详细介绍前，先对该方案的实施场景进行简单介绍。

该实施场景中，需要对WEB服务端进行软件性能测试，服务端与客户端之间的通信协议类型为HTTP协议，那么本申请实施例中的业务请求为HTTP请求。

基于上述场景，实施例2中实现软件性能测试的过程如图2所示，包括下述步骤：

步骤21：监听线上的HTTP服务端的服务端口，得到第一HTTP请求；

步骤22：将得到的第一HTTP请求序列化成JSON Array，并保存到Redis数据库中；

步骤23：读取Redis中的JSON Array，并对其进行反序列化，得到第二HTTP请求；

步骤24：向线下的被测试HTTP服务端并发地发送预定数量的第二HTTP请求；

步骤25：监测所述被测试HTTP服务端在对每个第二HTTP请求进行响应时，各个模块耗费的时长；

步骤26：得到各个模块执行操作的平均耗时；

步骤27：将处理操作平均耗时大于3秒的模块作为处理性能低的模块。

本申请实施例2提供的软件性能测试方法，通过获取线上HTTP服务端接收到的第一HTTP请求，并利用根据第一HTTP请求生成的请求数据，生成第二HTTP请求，然后利用第二HTTP请求进行性能测试，从而可以模拟线上真实的场景，以便发现被测试HTTP服务端在线上真实运行时可能会出现的性能问题。相对于现有技术中利用开发人员根据经验编写的业务请求进行软件性能测试，提高了软件性能测试结果的准确性。

实施例3

为解决现有技术中软件性能测试的结果不准确的问题，本申请实施例3提供一种软件性能测试装置。该软件性能测试装置的结构示意图如图3所示，主要包括下述功能单元：

线上业务请求获取单元31，用于获取线上软件系统接收到的第一业务请求；

请求数据存储单元32，用于将获得的第一业务请求转换成预定格式的请求数据，并存储到数据库中；

第二业务请求生成单元33，用于根据所述数据库中存储的请求数据，和预设的第二业务请求生成规则，生成第二业务请求；

性能测试单元34，用于利用生成的第二业务请求，进行软件性能测试。

本申请实施例中，软件性能测试装置的具体实施方式有很多种，在一种实施方式中，所述请求数据存储单元32，具体用于对获得的第一业务请求执行序列化操作，得到预定格式的请求数据；将得到的预定格式的请求数据持久化到数据库中。

在一种实施方式中，所述性能测试单元34，具体用于并发地向被测试软件系统发送预定数量的第二业务请求；

获取各性能指标数据；所述各性能指标数据，分别反映所述被测试软件系统的部分或全部模块各自在响应所述业务请求时的性能；所述各性能指标数据，是被测试软件系统通过执行预先注入被测试软件系统的监控代码得到的；所述监控代码所实现的功能，包括：对所述部分或全部模块的运行情况进行监控，并根据监控结果，生成所述各性能指标数据；

根据所述各性能指标数据，确定被测试软件系统的性能。

在一种实施方式中，所述各个模块的性能指标数据包括下述至少一种：

各个模块执行操作耗费的时长；各个模块执行操作的错误率。

在一种实施方式中，线上业务请求获取单元31，具体用于通过对线上软件系统的服务端口进行监听，获取线上软件系统接收到的第一业务请求。

在一种实施方式中，所述装置还包括测试结果展示单元35，用于在确定被测试软件系统的性能后，将获取的各项性能指标数据进行展示。

本申请实施例3提供的软件性能测试装置，通过获取线上软件系统接收到的第一业务请求，并利用根据第一业务请求生成的请求数据，生成第二业务请求，然后利用第二业务请求进行性能测试，从而可以模拟线上真实的场景，以便发现被测试软件在线上真实运行时可能会出现的性能问题。相对于现有技术中利用开发人员根据经验编写的业务请求进行软件性能测试，提高了软件性能测试结果的准确性。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种软件性能测试方法，其特征在于，包括：

获取线上软件系统接收到的第一业务请求；

将获得的第一业务请求转换成预定格式的请求数据，并存储到数据库中；

根据所述数据库中存储的请求数据，和预设的第二业务请求生成规则，生成第二业务请求；

利用生成的第二业务请求，进行软件性能测试。

2.如权利要求1所述方法，其特征在于，获取线上软件系统接收到的第一业务请求，具体包括：

通过对线上软件系统的服务端口进行监听，获取线上软件系统接收到的第一业务请求。

3.如权利要求1所述方法，其特征在于，将获得的第一业务请求转换成预定格式的请求数据，并存储到数据库中，具体包括：

对获得的第一业务请求执行序列化操作，得到预定格式的请求数据；

将得到的预定格式的请求数据持久化到数据库中。

4.如权利要求1所述方法，其特征在于，利用生成的第二业务请求，进行软件性能测试，具体包括：

并发地向被测试软件系统发送预定数量的第二业务请求；

获取各性能指标数据；所述各性能指标数据，分别反映所述被测试软件系统的部分或全部模块各自在响应所述第二业务请求时的性能；所述各性能指标数据，是被测试软件系统通过执行预先注入被测试软件系统的监控代码得到的；所述监控代码所实现的功能，包括：对所述部分或全部模块的运行情况进行监控，并根据监控结果，生成所述各性能指标数据；

根据所述各性能指标数据，确定被测试软件系统的性能。

5.如权利要求4所述方法，其特征在于，所述各个模块的性能指标数据包括下述至少一种：

各个模块执行操作耗费的时长；

各个模块执行操作的错误率。

6.如权利要求4所述方法，其特征在于，在确定被测试软件系统的性能后，所述方法还包括：将获取的各项性能指标数据进行展示。

7.一种软件性能测试装置，其特征在于，包括：

线上业务请求获取单元，用于获取线上软件系统接收到的第一业务请求；

请求数据存储单元，用于将获得的第一业务请求转换成预定格式的请求数据，并存储到数据库中；

第二业务请求生成单元，用于根据所述数据库中存储的请求数据，和预设的第二业务请求生成规则，生成第二业务请求；

性能测试单元，用于利用生成的第二业务请求，进行软件性能测试。

8.如权利要求7所述装置，其特征在于：

所述请求数据存储单元，具体用于对获得的第一业务请求执行序列化操作，得到预定格式的请求数据；

将得到的预定格式的请求数据持久化到数据库中。

9.如权利要求7所述装置，其特征在于：

所述性能测试单元，具体用于并发地向被测试软件系统发送预定数量的第二业务请求；

获取各性能指标数据；所述各性能指标数据，分别反映所述被测试软件系统的部分或全部模块各自在响应所述业务请求时的性能；所述各性能指标数据，是被测试软件系统通过执行预先注入被测试软件系统的监控代码得到的；所述监控代码所实现的功能，包括：对所述部分或全部模块的运行情况进行监控，并根据监控结果，生成所述各性能指标数据；

根据所述各性能指标数据，确定被测试软件系统的性能。

10.如权利要求9所述装置，其特征在于，所述装置还包括：

测试结果展示单元，用于在确定被测试软件系统的性能后，将获取的各项性能指标数据进行展示。