CN107193749A - 测试方法、装置及设备 - Google Patents

Abstract

本发明实施例提供一种测试方法、装置及设备，通过本发明实施例的方法可以得到目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力，且在整个测试过程中，无需人工参与，均是自动化完成的，进而使得测试的自动化程度较高，节省了人工成本。在得到目标数据引擎在每单位时间内处理完毕的业务处理请求的数量之后，测试设备需要将目标数据引擎的环境参数、目标数据引擎在每单位时间内处理完毕的业务处理请求的数量以及目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量汇总并生成测试并生成测试报告，以及显示在测试设备的屏幕上，以方便技术人员对本次测试的情况进行查看并分析。

Description

测试方法、装置及设备

技术领域

本发明实施例涉及计算机应用技术领域，尤其涉及一种测试方法、装置及设备。

背景技术

当前，随着交易模式的多样化以及大众消费观念的逐渐改变，数据库的应用领域不断扩大，现代的数据引擎中的数据量的海量扩展也对数据引擎在某一数量的业务仓库的情况下的处理能力提出了更高的要求。

为了确定数据引擎的处理能力是否能够满足大量请求同时并发的业务需求，需要对测试数据引擎测试，以得到数据引擎在某一数量的业务仓库的情况下的处理能力，进而在数据引擎在某一数量的业务仓库的情况下的处理能力无法满足大量请求同时并发的需求的情况下对数据引擎进行完善，从而使得数据引擎能够满足大量请求同时并发的业务需求。

然而，目前并未存在测试数据引擎在某一数量的业务仓库的情况下的处理能力的方法，进而无法得到数据引擎在某一数量的业务仓库的情况下的处理能力，因此，如何得到数据引擎在某一数量的业务仓库的情况下的数据处理能力是一个亟待解决的技术问题。

发明内容

本发明实施例提供一种设备方法、装置及设备，用以解决现有技术中无法得到数据引擎在某一数量的业务仓库的情况下的数据处理能力的问题。

第一方面，本发明实施例中提供了一种测试的方法，所述方法包括：

利用预先设置的环境参数，配置目标数据引擎的环境参数；

根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

其中，所述根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，包括：

在预先设置的数据引擎的类型、业务仓库数量与数据之间的对应关系中，查找是否存在与所述数据引擎的类型和所述业务仓库数量相对应的数据；

响应于存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，将与所述数据引擎的类型和所述业务仓库数量相对应的数据确定为所述目标数据；

响应于不存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，根据所述数据引擎的类型和所述业务仓库数量生成目标数据。

进一步地，所述根据所述数据引擎的类型和所述业务仓库数量生成目标数据之后，还包括：

将所述数据引擎的类型、所述业务仓库数量以及所述目标数据组成一条记录，并存储在所述对应关系中。

其中，所述获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量，包括：

获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的种类的数量；

获取每一个业务处理请求对应的数据库事务的数量；

根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量。

其中，所述根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量，包括：

根据所述种类的数量和所述数据库事务的数量，按照如下公式计算在每单位时间内处理完毕的业务处理请求的数量：

在上述公式中，A为所述种类的数量，B为所述数据库事务的数量，C为基准tpc指标值对应的预设比例，D为CPU保留30％的处理能力冗余。

第二方面，本发明实施例中提供了一种测试装置，所述装置包括：

配置模块，用于利用预先设置的环境参数，配置目标数据引擎的环境参数；

第一获取模块，用于根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

分配模块，用于获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

第二获取模块，用于获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总模块，用于汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

其中，所述第一获取模块包括：

查找单元，用于在预先设置的数据引擎的类型、业务仓库数量与数据之间的对应关系中，查找是否存在与所述数据引擎的类型和所述业务仓库数量相对应的数据；

确定单元，用于响应于存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，将与所述数据引擎的类型和所述业务仓库数量相对应的数据确定为所述目标数据；

生成单元，用于响应于不存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，根据所述数据引擎的类型和所述业务仓库数量生成目标数据。

进一步地，所述第一获取模块还包括：

存储单元，用于将所述数据引擎的类型、所述业务仓库数量以及所述目标数据组成一条记录，并存储在所述对应关系中。

其中，所述第二获取模块包括：

第一获取单元，用于获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的种类的数量；

第二获取单元，用于获取每一个业务处理请求对应的数据库事务的数量；

计算单元，用于根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量。

其中，所述计算单元用于：

根据所述种类的数量和所述数据库事务的数量，按照如下公式计算在每单位时间内处理完毕的业务处理请求的数量：

在上述公式中，A为所述种类的数量，B为所述数据库事务的数量，C为基准tpc指标值对应的预设比例，D为CPU保留30％的处理能力冗余。

所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

在一个可能的设计中，测试装置的结构中包括处理器和存储器，所述存储器用于存储支持测试装置执行上述第一方面中测试方法的程序，所述处理器被配置为用于执行所述存储器中存储的程序。所述测试装置还可以包括通信接口，用于测试装置与其他设备或通信网络通信。

第三方面，本发明实施例提供了一种计算机存储介质，用于储存测试装置所用的计算机软件指令，其包含用于执行上述第一方面中测试方法为测试装置所涉及的程序。

在本发明实施例中，通过上述实施例的方法可以得到目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力，且在整个测试过程中，无需人工参与，均是自动化完成的，进而使得测试的自动化程度较高，节省了人工成本。

进一步地，在得到目标数据引擎在每单位时间内处理完毕的业务处理请求的数量之后，测试设备需要将目标数据引擎的环境参数、目标数据引擎在每单位时间内处理完毕的业务处理请求的数量以及目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量汇总并生成测试并生成测试报告，以及显示在测试设备的屏幕上，以方便技术人员对本次测试的情况进行查看并分析。其次，还可以将业务仓库的数量以及客户端的数量同时添加在测试报告中，方便技术人员对本次测试的情况进行查看并分析。

本发明的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了根据本发明一个实施例的测试系统的结构示意图；

图2示出了根据本发明另一个实施例的测试方法流程示意图；

图3示出了根据本发明一个实施例的测试装置的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

在本发明的说明书和权利要求书及上述附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1是根据一示例性实施例示出的一种测试系统的结构示意图，参见图1，该测试系统包括测试设备1、数据引擎2和多个客户端3，测试设备1与每一个客户端3分别通信连接，测试设备1与数据引擎2通信连接，每一个客户端3分别与数据引擎2通信连接。

图2是根据一示例性实施例示出的一种测试方法的流程图，如图2所示，该方法用于图1所示的测试设备1中，该方法包括以下步骤。

在步骤S101中，利用预先设置的环境参数，配置目标数据引擎的环境参数；

在本发明实施例中，数据引擎有很多，例如Mysql、Postgresql、Hive、Impala、GreenPlum以及SparkSQL等等。技术人员事先可以从多个数据引擎中选择一个数据引擎，测试设备将技术人员选择的数据引擎作为目标数据引擎。

其中，技术人员事先会将所有的数据引擎的标识均存储在测试设备中存储的数据引擎标识列表中，因此，在本发明实施例中，技术人员可以在数据引擎标识列表中选择目标数据引擎的标识，并提交给测试设备。测试设备获取技术人员从数据引擎标识列表中选择的数据引擎的标识，并将选择的数据引擎的标识对应的数据引擎作为目标数据引擎。

在本发明实施例中，目标数据引擎的环境参数包括：数据引擎可连接的客户端的最大数量、数据引擎与客户端之间的最大握手时间、数据引擎的工作线程数量、数据引擎的网络接口的带宽以及数据引擎的系统缓存大小等等。

根据不同的业务需求，同一数据引擎的环境参数往往在不同的情况下需要改变，例如，在每天11点～13点以及17点～19点时，数据引擎接收业务处理请求的数量较多，因此，在这个时间段需要增加数据引擎的系统缓存大小、数据引擎的工作线程数量以及数据引擎的网络接口的最大输入带宽，以提高数据引擎的每单位时间内能够处理完毕的业务处理请求的数量，进而提高处理接收到的多个业务处理请求的处理效率。然而，在每天除11点～13点以及17点～19点以外的其他时段，数据引擎接收业务处理请求的数量较少，为了节省系统资源，可以适当减少数据引擎的系统缓存大小、数据引擎的工作线程数量以及数据引擎的网络接口的最大输入带宽等。

其中，单位时间可以为1分钟、2分钟或者1小时等等，本发明实施例对此不加以限定。

在本发明实施例中，技术人员往往需要在不同的环境参数下测试不同的数据引擎在每单位时间内能够处理完毕的业务处理请求的数量。对于任意一个数据引擎，技术人员事先可以在测试设备中设置在测试该数据引擎时的环境参数，例如，将该数据引擎的引擎标识与设置的该环境参数组成一条记录，并存储在测试设备存储的引擎标识与环境参数之间的对应关系中。对于其他每一个数据引擎，同样如此。

因此，在确定出目标数据引擎之后，测设设备可以根据目标数据引擎的引擎标识，在引擎标识与环境参数之间的对应关系查找对应的环境参数，然后利用查找到的环境参数配置目标数据引擎的环境参数。

其中，在本发明实施例中，对于任意一个数据引擎，在该数据引擎的环境参数中，可以以“key-value”的形式存储参数名和参数值，例如：“连接数＝500”，“缓存大小＝200MB”等等。对于其他每一个数据引擎，同样如此。

在本发明实施例中，在利用获取的环境参数配置数据引擎的环境参数时，测试设备可以向数据引擎送配置指令，配置指令包括获取的环境参数。数据引擎接收该配置指令，从该配置指令中提取出该环境参数，并根据该环境参数修改本地的环境参数。

例如，获取该环境参数中的参数名，以及该参数名对应的参数值，判断该参数值是否与本地的该参数名对应的参数值相同，如果不同，则利用该参数值替换本地的该参数名对应的参数值，如果相同，则不做处理。

在步骤S102中，根据目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在目标数据引擎中；

在本发明实施例中，技术人员事先会在本地设置业务仓库的数量，根据不同的数据引擎的类型和业务仓库的数量生成的数据是不同的，进而对数据引擎的测试结果也是不同的。

测试设备可以获取技术人员事先在本地设置的业务仓库的数量，以及获取目标数据引擎的类型，再根据目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在数据引擎中。

其中，可能在此次测试目标数据引擎之前曾经测试过目标数据引擎，例如，技术人员对之前的测试结果不满意，需要重新再次测试而已。

由于每当测试某一数据引擎在某一数量的业务仓库的情况下的数据处理能力时，都要根据该数据引擎的引擎标识和该业务仓库的数量生成数据，并存储在该数据引擎中，由于生成一次数据会耗费较长的时间，导致对数据引擎的测试效率较低，以及会耗费测试设备中较多的系统资源。

因此，在根据某一数据引擎的引擎标识和某一数量的业务仓库生成数据时，为了下次在测试该数据引擎在该数量的业务仓库的情况下的数据处理能力时，能够提高测试效率以及节省测试设备中的系统资源，测试设备可以将该测试引擎的引擎标识、该数量以及生成的该数据组成一条记录，并存储在本地存储的引擎标识、业务仓库数量与数据之间的对应关系中。

如此使得之后如果需要再次在测试该数据引擎在该数量的业务仓库的情况下的数据处理能力时，无需实时根据该数据引擎的类型以及该业务仓库的数量生成数据，而是可以直接从本地存储的引擎标识、业务仓库数量与数据之间的对应关系中查找与该数据引擎的引擎标识和该业务仓库的数量相对应的数据，并存储在该数据引擎中。

由于直接从本地存储的引擎标识、业务仓库数量与数据之间的对应关系中查找与该引擎标识和该业务仓库数量相对应的数据的过程只需耗费少量的时间以及只需耗费测试设备中较少的系统资源。

因此，相比于实时根据该数据引擎的类型以及该业务仓库的数量生成数据，直接从本地存储的引擎标识、业务仓库数量与数据之间的对应关系中查找与该引擎标识和该业务仓库数量相对应的数据不仅可以提高测试效率，且可以节省测试设备中的系统资源。

所以，在本步骤中，测试设备可以在预先设置的数据引擎的类型、业务仓库数量与数据之间的对应关系中，查找是否存在与数据引擎的类型和业务仓库数量相对应的数据；

响应于存在与数据引擎的类型和业务仓库数量相对应的数据，将与数据引擎的类型和业务仓库数量相对应的数据确定为目标数据；

响应于不存在与数据引擎的类型和业务仓库数量相对应的数据，根据数据引擎的类型和业务仓库数量生成目标数据。

进一步地，为了之后继续又一次在测试目标数据引擎在该数量的业务仓库的情况下的数据处理能力时，能够提高测试效率以及节省测试设备中的系统资源，在根据数据引擎的类型和业务仓库数量生成目标数据之后，测试设备还需要将目标数据引擎的类型、该业务仓库数量以及目标数据组成一条记录，并存储在上述对应关系中。

在步骤S103中，获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向目标数据引擎发送业务处理请求；该业务处理请求用于请求处理存储在目标数据引擎中的目标数据；

在本发明实施例中，在测试目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力时，需要多个客户端同时向目标数据引擎发送业务处理请求，客户端的数量需要足够多，这样才能使得目标数据引擎能够满负荷工作，也即，才能给目标数据引擎足够大的压力，进而才能准确地测试出测试目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力。

其中，技术人员事先会将与测试设备通信连接的每一个客户端的标识均存储在测试设备中存储的客户端标识列表中，因此，在本发明实施例中，技术人员可以从测试设备存储的客户端标识列表中选择多个客户端的标识，并提交给测试设备。测试设备获取技术人员从客户端标识列表中选择的客户端的标识。并将业务处理请求和测试起始时刻分别分配给每一个客户端标识相对应的客户端。

对于任意一个客户端，在该客户端接收到业务处理请求和测试起始时刻时，该客户端就会实时监测本地的当前时刻，并在本地的当前时刻到达该起始时刻时，向目标数据引擎发送业务处理请求。目标数据引擎接收该客户端发送的业务处理请求，并根据业务处理请求对存储的数据进行处理，得到数据处理结果，并向该客户端返回该数据处理结果。其中，目标数据引擎还需要获取在得到数据处理结果时本地的当前时刻，并作为处理完毕该业务处理请求时的结束时刻，以及获取该业务处理请求的类型，并将该结束时刻与该业务处理请求的类型发送至测试设备。对于其他每一个客户端，同样如此。

在步骤S104中，获取目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

其中，本步骤可以通过如下流程实现，包括：

11)、获取目标数据引擎在每单位时间内处理完毕的业务处理请求的种类的数量；

在本发明实施例中，由于每当目标数据引擎处理完毕一个业务处理请求，就会将处理完毕该业务处理请求时的结束时刻以及该业务处理请求的类型发送至测试设备，测试设备接收目标数据引擎发送的该结束时刻以及该业务处理请求的类型。

当目标数据引擎处理完毕最晚一个业务处理请求之后，就会向测试设备发送处理完毕最晚一个业务处理请求时的结束时刻以及最晚一个业务处理请求的请求类型。

当测试设备接收到目标数据引擎发送的最晚一个完毕时刻和最晚一个业务处理请求类型时，

在接收到的最晚的结束时刻与接收到的最早的一个结束时刻之间的时间段中的任意一单位时间，确定在该单位时间内处理完毕的每一个业务处理请求的类型，统计不同的类型的数量。对于其他每一单位时间，同样如此。然后统计在每一单位时间内处理完毕的业务处理请求的种类的数量。

在本发明实施例中，由于事先创建了多个业务仓库，对同一类业务仓库中的数据进行处理的业务处理请求为同一类型的业务处理请求。

12)、获取每一个业务处理请求对应的数据库事务的数量；

在本发明实施例中，对于任意一个种类的业务请求，目标数据引擎对该业务请求处理时，往往需要对数据库执行多次操作，每一次操作为一个数据库事物。对于其他每一种类的业务请求，同样如此。

13)、根据种类的数量和数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量。

其中，在本发明实施例中，可以根据种类的数量和数据库事务的数量，按照如下公式计算在每单位时间内处理完毕的业务处理请求的数量：

在上述公式中，A为种类的数量，B为数据库事务的数量，C为基准tpc指标值对应的预设比例，D为CPU保留30％的处理能力冗余。

其中，C可以为10～15之间的任意数值。

在步骤S105中，汇总目标数据引擎的环境参数、目标数据引擎在每单位时间内处理完毕的业务处理请求的数量以及目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

在本发明实施例中，通过上述实施例的方法可以得到目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力，且在整个测试过程中，无需人工参与，均是自动化完成的，进而使得测试的自动化程度较高，节省了人工成本。

进一步地，在得到目标数据引擎在每单位时间内处理完毕的业务处理请求的数量之后，测试设备需要将目标数据引擎的环境参数、目标数据引擎在每单位时间内处理完毕的业务处理请求的数量以及目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量汇总并生成测试并生成测试报告，以及显示在测试设备的屏幕上，以方便技术人员对本次测试的情况进行查看并分析。其次，还可以将业务仓库的数量以及客户端的数量同时添加在测试报告中，方便技术人员对本次测试的情况进行查看并分析。

进一步地，在得到目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力之后，如果之后还需要测试得到目标数据引擎在其他业务仓库数量的业务仓库的情况下的数据处理能力，为了防止此次在测试目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力时存储的目标数据和产生的临时文件对下一次测试目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力时造成干扰，测试设备可以删除在目标数据引擎中存储的目标数据和产生的临时文件。

图3是根据一示例性实施例示出的一种测试装置的结构示意图。参照图3，该装置包括：

配置模块11，用于利用预先设置的环境参数，配置目标数据引擎的环境参数；

第一获取模块12，用于根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

分配模块13，用于获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

第二获取模块14，用于获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总模块15，用于汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

其中，所述第一获取模块12包括：

查找单元，用于在预先设置的数据引擎的类型、业务仓库数量与数据之间的对应关系中，查找是否存在与所述数据引擎的类型和所述业务仓库数量相对应的数据；

确定单元，用于响应于存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，将与所述数据引擎的类型和所述业务仓库数量相对应的数据确定为所述目标数据；

生成单元，用于响应于不存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，根据所述数据引擎的类型和所述业务仓库数量生成目标数据。

进一步地，所述第一获取模块12还包括：

存储单元，用于将所述数据引擎的类型、所述业务仓库数量以及所述目标数据组成一条记录，并存储在所述对应关系中。

其中，所述第二获取模块14包括：

第一获取单元，用于获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的种类的数量；

第二获取单元，用于获取每一个业务处理请求对应的数据库事务的数量；

计算单元，用于根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量。

其中，所述计算单元用于：

根据所述种类的数量和所述数据库事务的数量，按照如下公式计算在每单位时间内处理完毕的业务处理请求的数量：

在上述公式中，A为所述种类的数量，B为所述数据库事务的数量，C为基准tpc指标值对应的预设比例，D为CPU保留30％的处理能力冗余。

在本发明实施例中，通过上述实施例的方法可以得到目标数据引擎在该业务仓库数量的业务仓库的情况下的数据处理能力，且在整个测试过程中，无需人工参与，均是自动化完成的，进而使得测试的自动化程度较高，节省了人工成本。

进一步地，在得到目标数据引擎在每单位时间内处理完毕的业务处理请求的数量之后，测试设备需要将目标数据引擎的环境参数、目标数据引擎在每单位时间内处理完毕的业务处理请求的数量以及目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量汇总并生成测试并生成测试报告，以及显示在测试设备的屏幕上，以方便技术人员对本次测试的情况进行查看并分析。其次，还可以将业务仓库的数量以及客户端的数量同时添加在测试报告中，方便技术人员对本次测试的情况进行查看并分析。

在一个可能的设计中，测试装置的结构中包括处理器和存储器，所述存储器用于存储支持测试装置执行上述图1所示的测试方法的程序，所述处理器被配置为用于执行所述存储器中存储的程序。

所述程序包括一条或多条计算机指令，其中，所述一条或多条计算机指令供所述处理器调用执行。

所述处理器用于：利用预先设置的环境参数，配置目标数据引擎的环境参数；

根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

本发明实施例提供了一种计算机存储介质，用于储存测试装置所用的计算机软件指令，其包含用于执行上述图1所示的测试方法为测试装置所涉及的程序。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

本发明公开A1、一种测试方法，包括：

利用预先设置的环境参数，配置目标数据引擎的环境参数；

根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

A2、如A1所述的方法中，所述根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，包括：

在预先设置的数据引擎的类型、业务仓库数量与数据之间的对应关系中，查找是否存在与所述数据引擎的类型和所述业务仓库数量相对应的数据；

响应于存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，将与所述数据引擎的类型和所述业务仓库数量相对应的数据确定为所述目标数据；

响应于不存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，根据所述数据引擎的类型和所述业务仓库数量生成目标数据。

A3、如A2所述的方法中，所述根据所述数据引擎的类型和所述业务仓库数量生成目标数据之后，还包括：

将所述数据引擎的类型、所述业务仓库数量以及所述目标数据组成一条记录，并存储在所述对应关系中。

A4、如求A1所述的方法中，所述获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量，包括：

获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的种类的数量；

获取每一个业务处理请求对应的数据库事务的数量；

根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量。

A5、如A4所述的方法，所述根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量，包括：

根据所述种类的数量和所述数据库事务的数量，按照如下公式计算在每单位时间内处理完毕的业务处理请求的数量：

在上述公式中，A为所述种类的数量，B为所述数据库事务的数量，C为基准tpc指标值对应的预设比例，D为CPU保留30％的处理能力冗余。

本发明还公开了B6、一种测试装置，包括：

配置模块，用于利用预先设置的环境参数，配置目标数据引擎的环境参数；

第一获取模块，用于根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

分配模块，用于获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

第二获取模块，用于获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总模块，用于汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

B7、如B6所述的装置中，所述第一获取模块包括：

查找单元，用于在预先设置的数据引擎的类型、业务仓库数量与数据之间的对应关系中，查找是否存在与所述数据引擎的类型和所述业务仓库数量相对应的数据；

确定单元，用于响应于存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，将与所述数据引擎的类型和所述业务仓库数量相对应的数据确定为所述目标数据；

生成单元，用于响应于不存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，根据所述数据引擎的类型和所述业务仓库数量生成目标数据。

B8、如B7所述的装置中，所述第一获取模块还包括：

存储单元，用于将所述数据引擎的类型、所述业务仓库数量以及所述目标数据组成一条记录，并存储在所述对应关系中。

B9、如B6所述的装置中，所述第二获取模块包括：

第一获取单元，用于获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的种类的数量；

第二获取单元，用于获取每一个业务处理请求对应的数据库事务的数量；

计算单元，用于根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量。

B10、如B9所述的装置中，所述计算单元用于：

根据所述种类的数量和所述数据库事务的数量，按照如下公式计算在每单位时间内处理完毕的业务处理请求的数量：

在上述公式中，A为所述种类的数量，B为所述数据库事务的数量，C为基准tpc指标值对应的预设比例，D为CPU保留30％的处理能力冗余。

Claims (10)

1.一种测试方法，其特征在于，所述方法包括：

利用预先设置的环境参数，配置目标数据引擎的环境参数；

根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，包括：

在预先设置的数据引擎的类型、业务仓库数量与数据之间的对应关系中，查找是否存在与所述数据引擎的类型和所述业务仓库数量相对应的数据；

响应于存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，将与所述数据引擎的类型和所述业务仓库数量相对应的数据确定为所述目标数据；

响应于不存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，根据所述数据引擎的类型和所述业务仓库数量生成目标数据。

3.根据权利要求2所述的方法，其特征在于，所述根据所述数据引擎的类型和所述业务仓库数量生成目标数据之后，还包括：

将所述数据引擎的类型、所述业务仓库数量以及所述目标数据组成一条记录，并存储在所述对应关系中。

4.根据权利要求1所述的方法，其特征在于，所述获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量，包括：

获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的种类的数量；

获取每一个业务处理请求对应的数据库事务的数量；

根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量。

5.根据权利要求4所述的方法，其特征在于，所述根据所述种类的数量和所述数据库事务的数量计算在每单位时间内处理完毕的业务处理请求的数量，包括：

根据所述种类的数量和所述数据库事务的数量，按照如下公式计算在每单位时间内处理完毕的业务处理请求的数量：

<mrow> <mi>t</mi> <mi>p</mi> <mi>m</mi> <mo>_</mo> <mi>c</mi> <mo>=</mo> <mfrac> <mrow> <mi>A</mi> <mo>*</mo> <mi>B</mi> <mo>*</mo> <mi>C</mi> </mrow> <mrow> <mn>1</mn> <mo>-</mo> <mi>D</mi> </mrow> </mfrac> <mo>;</mo> </mrow>

在上述公式中，A为所述种类的数量，B为所述数据库事务的数量，C为基准tpc指标值对应的预设比例，D为CPU保留30％的处理能力冗余。

6.一种测试装置，其特征在于，所述装置包括：

配置模块，用于利用预先设置的环境参数，配置目标数据引擎的环境参数；

第一获取模块，用于根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

分配模块，用于获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

第二获取模块，用于获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总模块，用于汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。

7.根据权利要求6所述的装置，其特征在于，所述第一获取模块包括：

查找单元，用于在预先设置的数据引擎的类型、业务仓库数量与数据之间的对应关系中，查找是否存在与所述数据引擎的类型和所述业务仓库数量相对应的数据；

确定单元，用于响应于存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，将与所述数据引擎的类型和所述业务仓库数量相对应的数据确定为所述目标数据；

生成单元，用于响应于不存在与所述数据引擎的类型和所述业务仓库数量相对应的数据，根据所述数据引擎的类型和所述业务仓库数量生成目标数据。

8.根据权利要求7所述的装置，其特征在于，所述第一获取模块还包括：

存储单元，用于将所述数据引擎的类型、所述业务仓库数量以及所述目标数据组成一条记录，并存储在所述对应关系中。

9.一种计算机存储介质，其特征在于，所述计算机存储介质存储有一条或多条计算机指令，所述计算机指令被执行时实现如权利要求1-5中任一项权利要求所述的方法。

10.一种设备，其特征在于，包括存储器和处理器；其中，

所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令供所述处理器调用执行；

所述处理器用于：

利用预先设置的环境参数，配置目标数据引擎的环境参数；

根据所述目标数据引擎的类型和预先设置的业务仓库数量获取目标数据，并存储在所述目标数据引擎中；

获取业务处理请求和测试起始时刻，并分别分配给预设的多个客户端中的每一个客户端，以使每一个客户端分别在该测试起始时刻时向所述目标数据引擎发送业务处理请求；所述业务处理请求用于请求处理存储在所述目标数据引擎中的目标数据；

获取所述目标数据引擎在每单位时间内处理完毕的业务处理请求的数量；

汇总所述环境参数、所述数量以及所述目标数据引擎在处理业务处理请求的过程中所占的系统资源的数量。