系统性能测试方法及装置、设备及存储介质与流程

本公开涉及计算机技术领域，尤其涉及一种系统性能测试方法及装置、设备及存储介质。

背景技术：

随着业界对系统性能压力测试的重视程度越来越高，性能压力测试也越来越频繁。要想拿到系统的性能极限数据和性能随并发用户增长的变化趋势，就需要不断增加用户负载，通过多个轮次的负载压力测试获得系统性能极限和负载与性能变化的规律。

现有的系统性能测试方式为固定一个负载压力进行一个轮次的性能测试，出了测试结果之后，再增加负载并进行下一轮压测。如此反复重复这个过程，直到达到系统性能极限。现有的测试方式需要执行多次测试，比较繁琐。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本公开的目的在于提供一种系统性能测试方法及装置、设备及存储介质，能够实现系统性能测试的自动化。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种系统性能测试方法，其特征在于，包括：建立测试任务；根据任务配置文件，生成至少一个负载配置文件；根据所述至少一个负载配置文件，对应生成所述测试任务的至少一个测试子任务；分别生成各测试子任务的至少一个构建队列；基于对各测试子任务的至少一个构建队列的执行状态扫描结果，分别确定各测试子任务的执行状态；基于对所述至少一个测试子任务的执行状态扫描结果，确定所述测试任务的执行状态；以及当所述测试任务的执行状态为已完成时，根据所述至少一个测试子任务的执行结果，生成所述测试任务的执行结果。

根据本公开的一实施方式，上述方法还包括：将建立的所述测试任务保存在任务记录表中；分别将生成的各测试子任务保存在子任务记录表中；当各测试子任务的执行状态发生变化时，将所述测试子任务的执行状态更新到所述子任务记录表中；以及当所述测试任务的执行状态发生变化时，将所述测试任务的执行状态更新到所述任务记录表中。

根据本公开的一实施方式，基于对各测试子任务的至少一个构建队列的执行状态扫描结果，分别确定各测试子任务的执行状态包括：当所述至少一个构建队列的执行状态均为已完成时，确定所述测试子任务的执行状态为已完成。

根据本公开的一实施方式，基于对所述至少一个测试子任务的执行状态扫描结果，确定所述测试任务的执行状态包括：当所述至少一个测试子任务的执行状态均为已完成时，确定所述测试任务的执行状态为已完成。

根据本公开的一实施方式，所述任务配置文件包括：初始并发用户数、并发用户数增长步长。

根据本公开的一实施方式，当生成的所述至少一个负载配置文件的数量为多个时，不同的负载配置文件中的并发用户数不同，且以所述并发用户数增长步长增长。

根据本公开的一实施方式，对所述至少一个构建队列的扫描及对所述至少一个测试子任务的扫描均为定时扫描。

根据本公开的另一个方面，提供一种系统性能测试装置，其特征在于，包括：任务建立模块，用于建立测试任务；文件生成模块，用于根据任务配置文件，生成至少一个负载配置文件；子任务生成模块，用于根据所述至少一个负载配置文件，对应生成所述测试任务的至少一个测试子任务；队列生成模块，用于分别生成各测试子任务的至少一个构建队列；子任务状态确定模块，用于基于对各测试子任务的至少一个构建队列的执行状态扫描结果，分别确定各测试子任务的执行状态；任务状态确定模块，用于基于对所述至少一个测试子任务的执行状态扫描结果，确定所述测试任务的执行状态；以及结果生成模块，用于当所述测试任务的执行状态为已完成时，根据所述至少一个测试子任务的执行结果，生成所述测试任务的执行结果。

根据本公开的再一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述方法。

根据本公开的又一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述方法。

本公开的实施例所提供的系统性能测试方法，根据配置文件，生成测试任务的测试子任务，并生成各测试子任务的构建队列，基于对各测试子任务的构建队列的扫描结果，确定各测试子任务的执行状态；基于测试子任务的执行状态的扫描结果，确定测试任务的执行状态；当测试任务的执行状态为已完成时，生成执行结果。该方法能够在测试过程中自动增加负载压力，实现系统性能测试过程中的自动化。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据一示例性实施方式示出的一种系统性能测试方法的流程图。

图2是根据一示例性实施方式示出的另一种系统性能测试方法的流程图。

图3是根据一示例示出的一种系统性能测试方法的流程图。

图4是根据一示例性实施方式示出的一种系统性能测试装置的框图。

图5是根据一示例性实施方式示出的一种电子设备的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1是根据一示例性实施方式示出的一种系统性能测试方法的流程图。

本公开实施例提供的方法可以由任意具备计算处理能力的电子设备执行。如图1所示，方法10包括：

在步骤s102中，建立测试任务。

在步骤s104中，根据任务配置文件，生成至少一个负载配置文件。

任务配置文件例如可以为原始脚本文件，原始脚本文件例如可以是可扩展标记语言(extensiblemarkuplanguage，xml)格式。解析原始脚本文件，识别其中的初始并发用户数、并发用户数增长步长、加压时长等属性，将这些属性开放为可配置项，设定属性后可以自动生成负载配置文件。

在一些实施例中，当生成的至少一个负载配置文件的数量为多个时，不同的负载配置文件中的并发用户数不同，且以并发用户数增长步长增长。

例如可以设置初始并发用户数为5，步长间隔为10，那么生成并发用户数分别为5、15、25、35、45的不同负载量的负载配置文件。

在步骤s106中，根据至少一个负载配置文件，对应生成测试任务的至少一个测试子任务。

建立的测试任务会相应生成一个任务id，任务id可根据上述的负载配置文件生成不同负载量的测试子任务，每个测试子任务会生成一个运行id。例如，新建一个测试任务，该测试任务下包含5个不同负载量的测试子任务，负载量分别如上述为：5、15、25、35、45。保存该任务后，如还可以将测试任务存储到数据库的任务记录表中，测试子任务会存储到数据库的子任务记录表中，两者如可以通过任务id关联。

在步骤s108中，分别生成各测试子任务的至少一个构建队列。

根据任务记录表和子任务记录表生成各测试子任务的构建队列。在实际做测试时，发压机可以有多台，针对一个运行id会生成多条构建记录。例如，有3台发压机时，针对每个运行id(即针对每个测试子任务)相应生成3条构建记录。

在步骤s110中，基于对各测试子任务的至少一个构建队列的执行状态扫描结果，分别确定各测试子任务的执行状态。

当各测试子任务开始执行时，将其对应的各构建队列的执行状态设置为执行中，同时调度测试工具开始发压；例如可以配置一个扫描工具，对该测试子任务对应的至少一个构建队列分别进行扫描，如可以定时扫描，获取该测试子任务的至少一个构建队列的执行状态扫描结果。当该执行状态扫描结果表示至少一个构建队列的执行状态均为已完成时，确定该测试子任务的执行状态为已完成。

在步骤s112中，基于对至少一个测试子任务的执行状态扫描结果，确定测试任务的执行状态。

同样地，如可以通过配置的另一个扫描工具对至少一个测试子任务分别进行扫描，如定时扫描，获得对至少一个测试子任务的执行状态扫描结果。当该扫描结果表示至少一个测试子任务的执行状态均为已完成时，确定测试任务的执行状态为已完成。

在步骤s114中，当测试任务的执行状态为已完成时，根据至少一个测试子任务的执行结果，生成测试任务的执行结果。

当测试任务的执行状态被标记为已完成时，会自动收集该测试任务下所有测试子任务的结果文件，并整合成压测报告。

本公开的实施例所提供的系统性能测试方法，根据配置文件，生成测试任务的测试子任务，并生成各测试子任务的构建队列，基于对各测试子任务的构建队列的扫描结果，确定各测试子任务的执行状态；基于测试子任务的执行状态的扫描结果，确定测试任务的执行状态；当测试任务的执行状态为已完成时，生成执行结果。该方法能够在测试过程中自动增加负载压力，实现系统性能测试过程中的自动化。

应清楚地理解，本公开描述了如何形成和使用特定示例，但本公开的原理不限于这些示例的任何细节。相反，基于本公开公开的内容的教导，这些原理能够应用于许多其它实施方式。

图2是根据一示例性实施方式示出的另一种系统性能测试方法的流程图。

在如图1所示的方法10的基础上，图2所示的方法20还进一步包括以下步骤：

在步骤s202中，将建立的测试任务保存在任务记录表中。

任务记录表用于记录测试任务及测试任务的执行状态，当测试任务下的所有测试子任务均完成时，任务记录表中该测试任务的执行状态更新为已完成。

在步骤s204中，分别将生成的各测试子任务保存在子任务记录表中。

子任务记录表用于记录测试子任务及测试子任务的执行状态，当测试子任务下的所有构建队列的任务均完成时，子任务记录表中该测试子任务的执行状态更新为已完成。

在步骤s206中，当各测试子任务的执行状态发生变化时，将测试子任务的执行状态更新到子任务记录表中。

当测试子任务开始执行时，子任务记录表中该测试子任务的执行状态更新为执行中；当测试子任务完成时，子任务记录表中该测试子任务的执行状态更新为已完成。

在步骤s208中，当测试任务的执行状态发生变化时，将测试任务的执行状态更新到任务记录表中。

当测试任务开始执行时，任务记录表中该测试任务的执行状态更新为执行中；当测试任务完成时，任务记录表中该测试任务的执行状态更新为已完成。

方法20和方法10相同的步骤不再赘述。

图3是根据一示例示出的一种系统性能测试方法的流程图。

如图3所示，系统性能测试方法包括：

在步骤s301中，建立系统性能测试任务。

在步骤s302中，生成负载配置文件。

在步骤s303中，生成测试任务。

在任务记录表中生成新建的系统性能测试任务的测试任务记录。

在步骤s304中，生成测试子任务。

每个测试任务下会有多个负载量不同的测试子任务，会生成多条测试子任务记录，每条测试子任务通过任务id和测试任务关联。

在步骤s305中，生成构建队列。

开始执行测试任务时，会根据当前执行的任务id确定测试子任务的运行id，然后根据任务id和运行id生成构建队列，因为发压机可能有多个，所以会生成多个构建队列，此时会触发构建队列子流程。

在步骤s306中，扫描构建队列。

扫描工具会不断地扫描构建队列。

在步骤s307中，判断构建队列是否执行完成。

当发现某个运行id下所有的构建队列都执行完成时，执行步骤s308；当某个运行id下所有的构建队列没有均执行完成时，执行步骤s306，继续扫描构建队列。

在步骤s308中，更新测试子任务的执行状态。

当某个运行id下所有的构建队列均执行完成时，更新子任务记录表中该条测试子任务的状态。

在步骤s309中，扫描子任务记录表。

同时会有另一个扫描工具不断地扫描子任务记录表。

在步骤s310中，判断测试子任务是否完成。

当发现某个任务id下所有的测试子任务记录均已标记为完成时，执行步骤s311；当某个任务id下的测试子任务记录未都完成时，执行步骤s309，继续扫描子任务记录表。

在步骤s311中，更新测试任务的执行状态。

当发现某个任务id下所有的测试子任务记录均已标记为完成时，更新任务记录表中该条测试任务的状态。

在步骤s312中，收集结果。

当测试任务执行完成时，可以通过结果收集模块整合测试结果。

本领域技术人员可以理解实现上述实施方式的全部或部分步骤被实现为由cpu执行的计算机程序。在该计算机程序被cpu执行时，执行本公开提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中，该存储介质可以是只读存储器，磁盘或光盘等。

此外，需要注意的是，上述附图仅是根据本公开示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

图4是根据一示例性实施方式示出的一种系统性能测试装置的框图。

参考图4，系统性能测试装置40包括：任务建立模块402、文件生成模块404、子任务生成模块406、队列生成模块408、子任务状态确定模块410、任务状态确定模块412及结果生成模块414。

其中，任务建立模块402用于建立测试任务。

文件生成模块404用于根据任务配置文件，生成至少一个负载配置文件。

子任务生成模块406用于根据至少一个负载配置文件，对应生成测试任务的至少一个测试子任务。

队列生成模块408用于分别生成各测试子任务的至少一个构建队列。

子任务状态确定模块410用于基于对各测试子任务的至少一个构建队列的执行状态扫描结果，分别确定各测试子任务的执行状态。

任务状态确定模块412用于基于对至少一个测试子任务的执行状态扫描结果，确定测试任务的执行状态。

结果生成模块414用于当测试任务的执行状态为已完成时，根据至少一个测试子任务的执行结果，生成测试任务的执行结果。

在一些实施例中，装置40还包括任务保存模块，用于将建立的测试任务保存在任务记录表中；子任务保存模块，用于分别将生成的各测试子任务保存在子任务记录表中；子任务状态更新模块，用于当各测试子任务的执行状态发生变化时，将测试子任务的执行状态更新到子任务记录表中；以及任务状态更新模块，用于当测试任务的执行状态发生变化时，将测试任务的执行状态更新到任务记录表中。

在一些实施例中，子任务状态确定模块410还用于当至少一个构建队列的执行状态均为已完成时，确定测试子任务的执行状态为已完成。

在一些实施例中，任务状态确定模块412还用于当至少一个测试子任务的执行状态均为已完成时，确定测试任务的执行状态为已完成。

在一些实施例中，任务配置文件包括：初始并发用户数、并发用户数增长步长。

在一些实施例中，当生成的至少一个负载配置文件的数量为多个时，不同的负载配置文件中的并发用户数不同，且以并发用户数增长步长增长。

在一些实施例中，对至少一个构建队列的扫描及对至少一个测试子任务的扫描均为定时扫描。

本公开的实施例所提供的系统性能测试装置，根据配置文件，生成测试任务的测试子任务，并生成各测试子任务的构建队列，基于对各测试子任务的构建队列的扫描结果，确定各测试子任务的执行状态；基于测试子任务的执行状态的扫描结果，确定测试任务的执行状态；当测试任务的执行状态为已完成时，生成执行结果。该装置能够在测试过程中自动增加负载压力，实现系统性能测试过程中的自动化。

需要注意的是，上述附图中所示的框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图5是根据一示例性实施方式示出的一种计算机系统的结构示意图。需要说明的是，图5示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图5所示，计算机系统800包括中央处理单元(cpu)801，其可以根据存储在只读存储器(rom)802中的程序或者从存储部分808加载到随机访问存储器(ram)803中的程序而执行各种适当的动作和处理。在ram803中，还存储有系统800操作所需的各种程序和数据。cpu801、rom802以及ram803通过总线804彼此相连。输入/输出(i/o)接口805也连接至总线804。

以下部件连接至i/o接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至i/o接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(cpu)801执行时，执行本公开的系统中限定的上述功能。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括发送单元、获取单元、确定单元和第一处理单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，发送单元还可以被描述为“向所连接的服务端发送图片获取请求的单元”。

作为另一方面，本公开还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：

建立测试任务；

根据任务配置文件，生成至少一个负载配置文件；

根据所述至少一个负载配置文件，对应生成所述测试任务的至少一个测试子任务；

分别生成各测试子任务的至少一个构建队列；

基于对各测试子任务的至少一个构建队列的执行状态扫描结果，分别确定各测试子任务的执行状态；

基于对所述至少一个测试子任务的执行状态扫描结果，确定所述测试任务的执行状态；以及

当所述测试任务的执行状态为已完成时，根据所述至少一个测试子任务的执行结果，生成所述测试任务的执行结果。

以上具体地示出和描述了本公开的示例性实施方式。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。