CN113971130A - 软件性能测试方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供了一种软件性能测试方法、装置、电子设备及存储介质，可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景。方法包括：获取测试任务对应的初始进程数量与性能测试脚本；根据初始进程数量，创建初始进程数量个测试进程，并在每个测试进程中调用性能测试脚本，启动性能测试；根据至少一个预设性能指标，周期性采集至少一个性能数据，并确定至少一个性能数据是否处于预设压力范围；在至少一个性能数据不处于预设压力范围的情况下，调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果。通过本申请，能够提高性能测试的效率；并能够将测试压力自适应地保持在设定范围，提高性能测试的准确性。

Description

软件性能测试方法、装置、设备及存储介质

技术领域

本申请涉及自动化测试技术，尤其涉及一种软件性能测试方法、装置、设备及存储介质。

背景技术

目前，相关技术的软件系统性能测试方法中，通常需要根据特定的多进程编程方法，专门编写多进程测试脚本以实现多进程场景下的性能测试，从而降低了性能测试的效率。并且，在长时间的性能测试下，被测设备可能出现系统资源占用或释放不及时等问题，从而导致被测设备的实际工作压力可能出现上升或下降，达不到性能测试期望的压力标准，进而降低了性能测试的准确性。

发明内容

本申请实施例提供一种软件性能测试方法、装置、设备及存储介质，能够利用常规自动化测试脚本实现多进程的性能测试，提高实现性能测试效率；并能够在长时间的性能测试下，将测试压力自动保持在设定范围，从而提高性能测试的准确性。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种软件性能测试方法，包括：

获取测试任务对应的初始进程数量与性能测试脚本；

根据所述初始进程数量，创建初始进程数量个测试进程，并在每个测试进程中调用所述性能测试脚本，启动性能测试；

根据至少一个预设性能指标，周期性采集至少一个性能数据，并确定所述至少一个性能数据是否处于预设压力范围；

在所述至少一个性能数据不处于所述预设压力范围的情况下，调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果。

本申请实施例提供一种软件性能测试装置，包括：

获取模块，用于获取测试任务对应的初始进程数量与性能测试脚本；

执行模块，用于根据所述初始进程数量，创建初始进程数量个测试进程，并在每个测试进程中调用所述性能测试脚本，启动性能测试；

采集模块，用于根据至少一个预设性能指标，周期性采集至少一个性能数据，并确定所述至少一个性能数据是否处于预设压力范围；

调节模块，用于在所述至少一个性能数据不处于所述预设压力范围的情况下，调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果。

上述装置中，所述采集模块，还用于在到达当前采集周期时，确定所述每个测试进程中是否存在非运行状态的性能测试脚本；在不存在非运行状态的性能测试脚本的情况下，根据至少一个预设性能指标进行数据采集，得到所述至少一个性能数据。

上述装置中，所述执行模块，还用于所述确定所述每个测试进程中是否存在非运行状态的性能测试脚本之后，在存在非运行状态的测试脚本情况下，确定是否达到预设测试终止条件；在未达到预设测试终止条件的情况下，在测试进程中重新调用所述性能测试脚本；

所述采集模块，还用于采集得到所述至少一个性能数据。

上述装置中，所述执行模块，还用于所述确定是否达到预设测试终止条件之后，在达到预设测试终止条件的情况下，结束性能测试，得到性能测试结果。

上述装置中，所述执行模块，还用于确定所述至少一个性能数据是否处于预设压力范围之后，在所述至少一个性能数据处于所述预设压力范围的情况下，不进行进程数量的调整，等待下一采集周期。

上述装置中，所述调节模块，还用于在所述至少一个性能数据高于所述预设压力范围的情况下，删除第一预设数量个测试进程；或者，在所述至少一个性能数据低于所述预设压力范围的情况下，增加第二预设数量个测试进程；根据所述至少一个预设性能指标，重新采集至少一个性能数据进行判断，直至所述至少一个性能数据处于所述预设压力范围的情况下，处于所述预设压力范围的情况下，得到所述调整后的进程数量；

所述执行模块，还用于根据调整后的进程数量继续进行性能测试，直至达到预设测试终止条件的情况下，结束测试，得到所述性能测试结果。

本申请实施例提供一种电子设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的软件性能测试方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的软件性能测试方法。

本申请实施例提供一种计算机程序产品，包括计算机程序或指令，其特征在于，所述计算机程序或指令被处理器执行时，实现本申请实施例提供的软件性能测试方法。

本申请实施例具有以下有益效果：

本申请实施例通过创建初始进程数量个测试进程，并在每个测试进程中调用性能测试脚本，实现了利用非多进程的测试脚本，实现多进程测试任务的测试场景，减少了编写多进程测试脚本的工作量，提高了常规测试脚本的复用性，从而提高了性能测试效率。并且，通过周期性地检测至少一个性能数据是否处于预设压力范围，进而对进程数量进行调整，实现了根据设备实时性能，动态地管理测试进程数量，从而自适应地保持测试压力，提高了性能测试的准确性。

附图说明

图1是本申请实施例提供的软件性能测试系统架构的一个可选的结构示意图；

图2是本申请实施例提供的软件性能测试装置的一个可选的结构示意图；

图3是本申请实施例提供的软件性能测试方法的一个可选的流程示意图；

图4是本申请实施例提供的软件性能测试方法的一个可选的流程示意图；

图5是本申请实施例提供的软件性能测试方法的一个可选的流程示意图；

图6是本申请实施例提供的软件性能测试方法的一个可选的流程示意图；

图7是本申请实施例提供的软件性能测试方法的一个可选的流程示意图；

图8是本申请实施例提供的实际场景中软件性能测试系统的一个可选的结构示意图；

图9是本申请实施例提供的一种性能测试系统中的任务配置模块和任务执行模块的协同工作过程示意图；

图10是本申请实施例提供的一种性能测试系统中的自适应调节模块的工作过程示意图一；

图11本申请实施例提供的一种性能测试系统中的自适应调节模块的工作过程示意图二。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

目前，相关技术的软件性能测试方法，通常是通过进行脚本测试录制或开发，然后通过稳定性系统进行脚本执行，并对执行过程进行监控的方式。一般而言，其实现方式是利用已有的性能测试工具(如Jmeter)或自主开发系统来实现。

然而，相关技术的性能测试对于脚本的格式要求较高，通常需要标记特定格式参数或者配置，以便稳定性系统采集指标，即使可以使用不同语言编辑或录制脚本，但脚本的格式通常是固定的。并且，普通的自动化测试脚本，因为无法满足稳定性的编写格式，或者未按多进程编程方法进行脚本编写，而无法作为性能测试的脚本，因此如果需要在性能测试中实现多进程并发的场景，通常需要具备较高编程水平的测试人员在脚本中按多进程编程方法进行编写，从而降低了性能测试的效率。

另一方面，相关技术的性能测试方法或系统，通常都是以测试脚本启动执行阶段设置的脚本或者进程数量为标准，以固定的负载即任务数量完成性能测试。在长时间性能测试过程中，可能出现资源占用不释放，导致被测设备的实际工作压力不断上升，比如测试原定压力80％，但由于资源不释放或其他故障，导致被测设备的工作压力可能上升到90％。可以看出，虽然测试初始设置的任务数量是固定的，但长时间测试后，被测设备上仍然可能出现工作压力上升或者下降的情况，无法将压力一直保持在测试期望的范围内，如长时间保持中央处理器(Central Processing Unit，CPU)90％的占用率进行测试，从而难以保证压力测试的效果，进而降低了性能测试准确性。

本申请实施例提供一种软件性能测试方法、装置、设备和计算机可读存储介质，能够提高软件性能测试的效率和准确性。本申请实施例可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。下面说明本申请实施例提供的电子设备的示例性应用，本申请实施例提供的电子设备可以实施为智能手机、智能手表、笔记本电脑，平板电脑，台式计算机，机顶盒，移动设备(例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备)、智能语音交互设备、智能家电和车载终端等各种类型的用户终端，也可以实施为服务器。下面，将说明电子设备实施为服务器时示例性应用。

参见图1，图1是本申请实施例提供的软件性能测试系统100的一个可选的架构示意图，终端400(示例性示出了终端400-1与终端400-2)通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。

终端400-1归属于测试人员，终端400-1上运行由软件性能测试客户端410-1，用于接收测试人员下发的性能测试脚本与测试配置参数，并通过网络300上传至服务器200。

服务器200，用于将接收到的性能测试脚本保存在数据库中，并根据测试脚本的存放地址与测试配置参数生成性能测试任务，将性能测试任务以测试请求的形式，通过网络300发送至终端400-2，并通过包含性能测试任务的测试请求，驱动终端400-2上的性能测试客户端410-2根据性能测试任务执行性能测试操作。

终端400-2，用于对服务器200下发的测试请求进行解析，从中获取测试任务对应的初始进程数量与性能测试脚本；根据初始进程数量，创建初始进程数量个测试进程，并在每个测试进程中调用性能测试脚本，启动性能测试；根据至少一个预设性能指标，周期性采集至少一个性能数据，并确定至少一个性能数据是否处于预设压力范围；在至少一个性能数据不处于预设压力范围的情况下，调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果。

终端400-2，还用于将性能测试结果发送至服务器200，由服务器200将性能测试结果保存在数据库500中，和/或转发至终端400-1，在终端400-1的性能测试客户端410中显示。

在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、智能语音交互设备、智能家电和车载终端等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。

在一些实施例中，终端400-1也可以直接与终端400-2连接，终端400-1根据初始进程数量与性能测试脚本生成测试任务，将测试任务直接下发至终端400-2，以使终端400-2根据测试任务对应的初始进程数量与性能测试脚本执行本申请实施例中的软件性能测试方法。

在一些实施例中，测试人员也可以直接在终端400-2上进行测试任务的配置，以使终端400-2根据测试任务对应的初始进程数量与性能测试脚本执行本申请实施例中的软件性能测试方法。或者，在一些实施例中，图1中的终端400-1与终端400-2也可以实施为服务器形式，即对服务器类型的电子设备进行软件性能测试。以上几种实施方式可根据实际情况进行选择，本申请实施例不作限定。

参见图2，图2是本申请实施例提供的终端400-2的结构示意图，图2所示的终端400-2包括：至少一个处理器410、存储器450、至少一个网络接口420和用户接口430。终端400-2中的各个组件通过总线系统440耦合在一起。可理解，总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统440。

处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口430包括使得能够呈现媒体内容的一个或多个输出装置431，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口430还包括一个或多个输入装置432，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器450可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器250可选地包括在物理位置上远离处理器410的一个或多个存储设备。

存储器450包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器450旨在包括任意适合类型的存储器。

在一些实施例中，存储器450能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统451，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块452，用于经由一个或多个(有线或无线)网络接口420到达其他计算设备，示例性的网络接口420包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

呈现模块453，用于经由一个或多个与用户接口430相关联的输出装置431(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；

输入处理模块454，用于对一个或多个来自一个或多个输入装置432之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图2示出了存储在存储器450中的软件性能测试装置455，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块4551、执行模块4552、采集模块4553和调节模块4554，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。

将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的软件性能测试方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。

在一些实施例中，终端或服务器可以通过运行计算机程序来实现本申请实施例提供的软件性能测试方法。举例来说，计算机程序可以是操作系统中的原生程序或软件模块；可以是本地(Native)应用程序(APP，Application)，即需要在操作系统中安装才能运行的程序，如社交应用APP或者消息分享APP；也可以是小程序，即只需要下载到浏览器环境中就可以运行的程序；还可以是能够嵌入至任意APP中的小程序或者网页客户端程序。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件。

将结合本申请实施例提供的电子设备的示例性应用和实施，说明本申请实施例提供的软件性能测试方法。

参见图3，图3是本申请实施例提供的软件性能测试方法的一个可选的流程示意图，将结合图3示出的步骤进行说明。

S101、获取测试任务对应的初始进程数量与性能测试脚本。

本申请实施例提供的软件性能测试方法可以应用于对电子设备的软件系统进行自动化测试、压力测试、稳定性测试等场景，具体的根据实际情况进行选择，本申请实施例不作限定。

本申请实施例中，电子设备在接收到下发的测试任务的情况下，获取测试任务对应的初始进程数量与性能测试脚本。其中，初始进程数量为测试任务中配置的性能测试所需启动的进程数量的初始值。性能测试脚本可以包含以非多进程编写方式实现的、常规的自动化测试脚本。通过本申请实施例中的方法，对于非多进程测试脚本，能够按照测试任务中指定的初始进程数量，生成多进程测试任务的测试场景，从而解决常规的非多进程测试脚本无法复用在多进程场景的性能测试中的问题，大大提高软件性能测试的效率

在一些实施例中，测试人员可以在测试任务配置设备上进行测试参数配置，通过测试请求的形式下发测试任务，电子设备可以通过预设的接口接收到测试任务对应的测试请求，并从测试请求中解析出测试任务对应的测试参数，其中，测试参数可以包含测试任务对应的初始进程数量与性能测试脚本。

这里，测试任务配置设备可以是电子设备本身，也即直接在电子设备上进行测试任务的配置与执行，也可以是与电子设备以有线或无线的方式连接的其他设备，具体的根据实际情况进行选择，本申请实施例不作限定。

在一些实施例中，电子设备还可以获取测试任务对应的其他测试参数，如测试任务名称、预设测试总时长、测试压力指标、性能监控间隔，以及测试脚本存放地址等等参数，以根据相应的测试参数对性能测试的测试过程或测试目标等进行配置，具体的根据实际情况进行选择，本申请实施例不作限定。

S102、根据初始进程数量，创建初始进程数量个测试进程，并在每个测试进程中调用性能测试脚本，启动性能测试。

本申请实施例中，电子设备可以根据测试任务中指定的初始进程数量，创建或生成对应数量的测试进程，并将性能测试脚本作为每个测试进程的执行对象，在每个测试进程中调用性能测试脚本，并执行性能测试脚本中包含的测试操作，启动对电子设备的性能测试。

在一些实施例中，电子设备可以通过执行预先实现的多进程测试脚本，根据多进程测试脚本中预先实现的多进程创建操作，根据初始进程数量创建出多个测试进程，并在每个测试进程中执行对性能测试脚本的调用，从而实现根据常规的非多进程形式编写的测试脚本，实现多进程的性能测试场景，提高测试脚本的复用性。这里，多进程测试脚本可以是以多进程编码方式预先实现的，并且，在每个进程中实现了对性能测试脚本调用的测试脚本。

在一些实施例中，性能测试脚本的脚本语言可以包括但不限于python、shell、工具命令语言(Tool Command Language，TCL)、C语言、JAVA、JAVAS cript、C++、Go(Golang)语言等，具体的根据实际情况进行选择，本申请实施例不作限定。

在一些实施例中，电子设备也可以通过其他方式预先实现多进程功能，如通过调用预先实现并封装的多进程功能接口等等方式，实现多进程的性能测试场景。具体的根据实际情况进行选择，本申请实施例不作限定。

S103、根据至少一个预设性能指标，周期性采集至少一个性能数据，并确定至少一个性能数据是否处于预设压力范围。

本申请实施例中，电子设备在启动了多进程的性能测试的情况下，根据预设采集周期，对电子设备上的至少一个性能数据进行周期性地采集，并将采集得到的至少一个性能数据与每个性能数据对应的预设压力范围进行对比，以确定至少一个性能数据是否处于预设压力范围。

本申请实施例中，预设压力范围表征软件性能测试所期望在被测设备上保持施加的测试压力，也即对被测设备在性能测试过程中所表现出的预设性能指标的期望数值范围。

在一些实施例中，预设压力范围可以是软件性能测试期望的预设压力值对应的数值范围，以扩大性能保持的适用范围，如预定压力值的正负5％或者10％范围内，具体的根据实际情况进行选择，本申请实施例不作限定。

在一些实施例中，至少一个预设性能数据可以包括但不限于：CPU占用率，内存占用率，IO读取速率，网络性能，磁盘占用率中的至少一个数据，具体的根据实际情况进行选择，本申请实施例不作限定。

本申请实施例中，为了持续将测试压力保持在稳定的范围，电子设备周期性地采集至少一个性能数据，以持续对电子设备的性能进行检测。

在一些实施例中，采集周期可以是电子设备上默认设置的性能数据的采集时间间隔，也可以根据测试人员在测试任务中配置的采集时间间隔来设定，具体的根据实际情况进行选择，本申请实施例不作限定。

本申请实施例中，电子设备可以在采集到至少一个性能数据的情况下，实时判断至少一个性能数据是否处于预设压力范围；或者，电子设备也可以将采集到的至少一个性能数据进行保存，示例性地，以数据库、报表或文件等形式进行保存，进而根据预设检测周期，周期性地获取最新保存的至少一个性能数据，并对至少一个性能数据与预设压力范围进行比对，确定至少一个性能数据是否处于预设压力范围。

这里，电子设备可以对上述的采集周期与检测周期进行分别设置，同时，其时间精度可以精确到小时、分钟、秒等级别，具体的根据实际情况进行选择，本申请实施例不作限定。

S104、在至少一个性能数据不处于预设压力范围的情况下，调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果。

本申请实施例中，在至少一个性能数据不处于预设压力范围的情况下，说明当前的测试进程数量在电子设备上施加的测试压力无法满足测试要求，电子设备对当前的测试进程的数量进行调整，并根据调整后的进程数量执行对待测设备的性能测试，并在性能测试过程中周期性地进行上述性能数据的检测和进程数量的调整，直至性能测试结束，得到性能测试结果。

本申请实施例中，电子设备可以根据至少一个性能数据与预设压力范围之间的数值大小关系，相应地增加或减少测试进程的数量，以调节电子设备上的运行压力，使之满足性能测试的标准并始终保持在预设压力范围内。

在一些实施例中，基于图3，如图4所示，S104可以通过S1041-S1044来实现，将结合各步骤进行说明。

S1041、在至少一个性能数据高于预设压力范围的情况下，删除第一预设数量个测试进程。

本申请实施例中，在至少一个性能数据高于预设压力范围的情况下，说明当前电子设备的运行性能，如资源占用等状态超出了性能测试期望或允许的压力范围。示例性地，软件性能测试期望测试得到电子设备的CPU占用率保持在70％的状态下的无故障运行时间，若测试过程中检测到CPU占用率达到了90％，说明当前测试进程数量过多，使得电子设备的CPU占用率无法达到测试要求。电子设备删除第一预设数量个测试进程，以降低电子设备的负载，进而降低如CPU占用率等至少一个性能指标对应的性能数据。

S1042、在至少一个性能数据低于预设压力范围的情况下，增加第二预设数量个测试进程。

本申请实施例中，在至少一个性能数据低于预设压力范围的情况下，说明当前测试进程数量过少，达不到性能测试对电子设备的负载要求，电子设备增加第二预设数量个测试进程，以提高电子设备的负载，进而提高至少一个性能指标对应的性能数据。

这里，需要说明的是，S1041和S1042是并列的流程分支，在实际执行中根据至少一个性能数据与预设压力范围的数值高低关系，选择对应的分支执行。以及，上述的第一预设数量与第二预设数量可以相同，也可以不同，具体的根据实际情况进行选择，本申请实施例不作限定。

S1043、根据至少一个预设性能指标，重新采集至少一个性能数据进行判断，直至至少一个性能数据处于预设压力范围的情况下，得到调整后的进程数量。

本申请实施例中，调整进程数量之后，电子设备以新的负载状态执行测试任务，则其性能数据也会发生变化。电子设备根据至少一个预设性能指标，重新采集至少一个性能数据，并将最新的至少一个性能数据与预设压力范围进行对比，如果仍不处于预设压力范围内，继续以S1041或S1042中的方法对进程数量调整，以上述过程迭代地对至少一个性能数据进行判断，以及对进程数量进行调整，直至至少一个性能数据处于预设压力范围的情况下，完成对进程数量的调整，得到调整后的进程数量。

S1044、根据调整后的进程数量继续进行性能测试，直至达到预设测试终止条件的情况下，结束测试，得到性能测试结果。

本申请实施例中，电子设备可以根据调整后的进程数量继续进行性能测试，并在每个采集周期到来时进行至少一个性能数据的采集与判断，进而进行进程数量的调整，直至达到预设测试终止条件的情况下，结束测试，得到性能测试结果。

这里，预设测试终止条件可以是测试持续时长达到预设测试总时长，也可以是电子设备的测试过程数据，如无故障运行时间、故障报错次数等达到预设测试目标，或发生预期类型的故障等等，具体的根据实际情况进行选择，本申请实施例不作限定。

在一些实施例中，电子设备可以根据测试结果生成测试报告，将测试报告发送至测试项目的相关用户，或者保存在数据库中。

可以理解的是，本申请实施例通过创建初始进程数量个测试进程，并在每个测试进程中调用性能测试脚本，实现了利用非多进程的测试脚本，实现多进程测试任务的测试场景，减少了编写多进程测试脚本的工作量，提高了常规测试脚本的复用性，从而提高了性能测试效率。并且，通过周期性地检测至少一个性能数据是否处于预设压力范围，进而对进程数量进行调整，实现了根据设备实时性能，动态地管理测试进程数量，从而自适应地保持测试压力，提高了性能测试的准确性。

在一些实施例中，在S104中完成性能测试后，还可以在长时间性能测试后的电子设备上进行功能测试，以验证其各项功能是否正常。

在一些实施例中，基于图3或图4，参见图5，图3中的S103可以通过S1031-S1032来实现，将结合各步骤进行说明。

S1031、在到达当前采集周期时，确定每个测试进程中是否存在非运行状态的性能测试脚本。

本申请实施例中，电子设备根据预设的采集周期，在到达当前采集周期时，检查每个测试进程中的性能测试脚本是否都处于运行状态。

在一些实施例中，当前测试时长为T1，性能测试脚本的单次脚本运行的标准时间为T2，且T2小于T1，采集周期为T3，以T1为24小时，T2为5分钟，T3为10分钟，即每10分钟检测一次为例，由于性能测试脚本是以多进程的方式并发执行的，可能由于系统资源分配不均导致每个性能测试脚本实际运行时间可能出现延长，即T2’大于5分钟；因此，不同测试进程中运行的性能测试脚本的运行结束时间可能不一致；电子设备可以以在T3时间到达时，检测每个测试进程中的性能测试脚本是否都处于运行状态，以得到电子设备上的实时真实负载情况。

S1032、在不存在非运行状态的性能测试脚本的情况下，根据至少一个预设性能指标进行数据采集，得到至少一个性能数据，并确定至少一个性能数据是否处于预设压力范围。

本申请实施例中，在不存在非运行状态的性能测试脚本的情况下，也即每个测试进程中的性能测试脚本都在运行中的情况，电子设备根据至少一个预设性能指标进行数据采集，得到至少一个性能数据，并确定至少一个性能数据是否处于预设压力范围。

在一些实施例中，电子设备可以在至少一个性能数据落入预设压力范围的情况下，确定至少一个性能数据处于预设压力范围；否则，在至少一个性能数据高于或低于预设压力范围的情况下，确定至少一个性能数据不处于预设压力范围。

在一些实施例中，在实际测试中，电子设备也可以根据预设的测试策略，对至少一个性能数据高于预设压力范围的情况进行重点检测，也即在至少一个性能数据高于预设压力范围的情况下，确定至少一个性能数据不处于预设压力范围，仅在至少一个性能数据高于预设压力范围的情况下进行进程数量的调整；在至少一个性能数据落入预设压力范围内，以及至少一个性能数据低于预设压力范围的情况下，均确定为至少一个性能数据处于预设压力范围，不进行进程数量的调整。或者，电子设备也可以对至少一个性能数据低于预设压力范围的情况进行重点检测，也即在至少一个性能数据低于预设压力范围的情况下，确定至少一个性能数据不处于预设压力范围，仅在至少一个性能数据低于预设压力范围的情况下进行进程数量的调整；在至少一个性能数据落入预设压力范围内，以及至少一个性能数据高于预设压力范围的情况下，均确定为至少一个性能数据处于预设压力范围，不进行进程数量的调整。具体的根据实际情况进行选择，本申请实施例不作限定。

在一些实施例中，基于图5，S1031之后，还可以执行S1033-S1034，如图6所示，将结合各步骤进行说明。

S1033、在存在非运行状态的测试脚本情况下，确定是否达到预设测试终止条件。

本申请实施例中，在存在非运行状态的测试脚本情况下，电子设备首先确定当前的测试状态是否达到了预设测试终止条件。

S1034、在未达到预设测试终止条件的情况下，在测试进程中重新调用性能测试脚本，并采集得到至少一个性能数据。

本申请实施例中，在未达到预设测试终止条件的情况下，说明性能测试还未完成，需要继续在电子设备上进行测试，电子设备在测试进程中重新调用测试脚本，进而根据至少一个预设性能指标进行数据采集，得到至少一个性能数据，进而执行S104继续进行性能测试。

这里，电子设备可以针对未运行状态的测试脚本对应的部分测试进程，进行性能测试脚本的重新调用执行，也可以将当前存在的全部测试进程中重新启动对性能测试脚本的调用执行，具体的根据实际情况进行选择，本申请实施例不作限定。

在一些实施例中，基于图6，如图7所示，S1033之后，还可以包括S1035，将结合各步骤进行说明。

S1035、在达到预设测试终止条件的情况下，结束性能测试，得到性能测试结果。

本申请实施例中，在达到预设测试终止条件的情况下，如当前测试时间达到预设测试总时长时，说明电子设备可以完成了测试任务期望达到的测试时长，电子设备可以结束性能测试，根据测试过程数据，得到性能测试结果。

可以理解的是，本申请实施例中，电子设备可以根据预设的采集周期获取测试过程中的性能数据，根据性能数据持续对电子设备的性能状态进行检测，以将性能数据保持在预设压力范围内，提高性能测试的准确性。并且，电子设备可以通过在采集周期到达时检测性能测试脚本的运行状态，及时调起结束运行的测试脚本，保证性能测试的正常进行，从而进一步提高了性能测试的准确性与稳定性。

在一些实施例中，S103之后，当电子设备确定至少一个性能数据处于预设压力范围的情况下，说明电子设备的性能满足测试要求，电子设备不进行进程数量的调整，等待下一采集周期到来时再进行判断。

下面，将结合图8-图11，说明本申请实施例在一个实际的应用场景中的示例性应用。

根据上述软件性能测试方法的描述，本申请实施例提供一种可应用于实际软件测试场景的，支持多进程和压力自适应的性能测试系统，如图8所示。其中，电子设备上运行有待测软件与性能测试系统，性能测试系统包括：

任务配置模块800，用于接收用户输入的测试参数，将测试参数进行保存，并根据测试参数生成并下发测试任务。其中，测试参数包括但不限于：测试任务名称，测试时长，测试进程数量，稳定性测试脚本，功能验证脚本，测试压力指标(如对象、范围等)，性能检测间隔，测试地址，测试通知对象(不同角色的用户，如测试执行人，测试负责人等)。

在一些实施例中，测试参数可以利用内存缓存的形式保存，还可以利用报表、文件、数据库等形式进行保存，具体的根据实际情况进行选择，本申请实施例不作限定。

任务执行模块801，用于执行下发的测试任务，包括：按测试进程数量拉起多个进程，根据自适应调节模块增加或删除进程数量等等。

在一些实施例中，基于图8所示的系统结构，上述任务配置模块800和任务执行模块801的协同工作过程可以如图9所示。任务配置模块800设置多进程数量，并上传稳定性测试脚本至数据库。这里稳定性测试脚本即为上述的性能测试脚本，任务执行模块801从数据库中读取稳定性测试脚本，并根据设置的多进程数量，拉起对应数量的测试进程，在每个测试进程中，调用稳定性测试脚本执行测试操作。

在一些实施例中，也可以将任务执行模块801部署在电子设备之外的其他设备上，具体的根据实际情况进行选择，本申请实施例不作限定。

继续参考图8，其中，性能采集模块802，用于在电子设备采集待测软件所在环境系统的性能数据，包括但不限于：CPU占用率，内存占用率，IO读取速率，网络性能，磁盘占用率等。

在一些实施例中，上述的性能采集模块802除采集环境系统的性能指标外，还可以同时采集对应的测试进程数量，从而得到测试进程数量和压力负载的变化关系，以用于进一步的测试结果分析与软件性能优化。

自适应调节模块803，用于判断调整稳定性测试的压力负载，使得稳定性测试系统的压力保持在一个指定的压力范围内，如测试设定CPU保持在80％的占用率，则该模块会按照设定的性能监控间隔，每次判断一次CPU占用率是否满足这一指标，通过增加或删除测试任务的进程，达到压力适配的效果。

功能验证模块804，用于稳定性测试结束后，通过执行功能验证脚本，验证待测软件的基本功能是否正常。

测试报告模块805，用于以测试报告的形式输出测试结果，同时根据测试参数中的测试通知对象，以通过邮件等方式通知相关人员。

在一些实施例中，可以通过linux系统命令的方式实现上述的任务执行模块801与性能采集模块802，或者也可以考虑通过python等开源模块，如ansible、saltstack等实现，具体的根据实际情况进行选择，本申请实施例不作限定。

在一些实施例中，基于图8所示的系统结构，自适应调节模块803的工作过程可以如图10所示，包括S201-S211，如下：

S201、在达到设定的检测间隔的情况下，唤醒检测服务；

S201中，检测间隔相当于预设的采集周期。

S202、检测稳定性测试脚本是否在运行中。

S202中，自适应调节模块通过检测服务，检测每个测试进程中的稳定性测试脚本是否在运行中。如果均在运行中，执行S203；否则，执行S210。

S203、采集性能数据。

S204-1、判断性能数据是否高于压力指标。

S204-1中，压力指标相当于上述的预设压力范围。若是，执行S205-1，否则，执行S206-1。这里，也可以以单个数值的形式进行预设压力的设置。

S205-1、删除一条测试进程。

S205-1中，自适应调节模块删除一条测试进程，进而继续跳转至S203进行性能数据的重新采集以及与压力指标的再次对比。

S206-1、判断性能数据是否低于压力指标。若是，执行S207-1，否则，执行S208。

S207-1、新建一条测试进程。

S207-1中，自适应调节模块新建一条测试进程，进而继续跳转至S203进行性能数据的重新采集以及与压力指标的再次对比。

S208、检测服务休眠。

S208中，自适应模块将检测服务进入休眠状态，等待下一时间间隔被唤醒。

S209、判断当前测试时长是否在预设的测试总时长内，若是，执行S210，否则，执行S211。

S210、脚本重新执行。

S210中，在当前测试时长还在预设的测试总时长内的情况下，电子设备重新按多进程数量拉起测试脚本，并跳转至S203继续执行测试任务。

S211、功能验证。

S211中，当前测试时长超过测试总时长，说明达到了上述的预设测试终止条件。电子设备结束稳定性测试，通过功能测试模块运行功能测试脚本，检查功能是否正常，得到功能验证结果。

在一些实施例中，基于图10，如图11所示，自适应模块也可以通过执行S204-2，先进行性能数据是否低于压力指标的判断，并在确定低于压力指标的情况下，执行S205-2，新建一条测试进程；在确定为不低于压力指标的情况下，执行S206-2，进行性能数据是否高于压力指标的判断。在确定高于压力指标的情况下，执行S207-2，删除一条测试进程。图11中的步骤说明与图10中对应步骤的说明一致，此处不再赘述。

在一些实施例中，图10中的自适应模块可以采取保持工作压力高于压力指标的方案来实现负载压力自适应保持，即在执行了S204，并确定性能数据不高于压力指标的情况下，不再进行进程数量的调整，执行S208。或者，也可以采取保持工作压力低于压力指标的方案，即在执行了S204，并确定性能数据不低于压力指标的情况下，不再进行进程数量的调整，执行S208。具体的根据实际情况进行选择，本申请实施例不作限定。

可以理解的是，本申请实施例实现了在无需编写专门的多进程测试脚本的情况下，通过稳定性测试系统自动地协助测试者实现多进程任务测试，降低了测试人员编写脚本能力的要求；并使得普通的自动化脚本可以用于长时间稳定性测试，而不用额外地增加代码或者脚本，从而提高了性能测试的效率。并且，实现了在长时间测试下，软件工作压力始终保持在一定范围内的稳定性测试场景，避免了因为任务数量始终固定，导致长时间测试后，软件工作压力上升或者下降的情况，从而提高了性能测试的准确性与稳定性。

下面继续说明本申请实施例提供的软件性能测试装置455的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器450的软件性能测试装置455中的软件模块可以包括：

获取模块4551，用于获取测试任务对应的初始进程数量与性能测试脚本；

执行模块4552，用于根据所述初始进程数量，创建初始进程数量个测试进程，并在每个测试进程中调用所述性能测试脚本，启动性能测试；

采集模块4553，用于根据至少一个预设性能指标，周期性采集至少一个性能数据，并确定所述至少一个性能数据是否处于预设压力范围；

调节模块4554，用于在所述至少一个性能数据不处于所述预设压力范围的情况下，调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果。

在一些实施例中，所述采集模块4553，还用于在到达当前采集周期时，确定所述每个测试进程中是否存在非运行状态的性能测试脚本；在不存在非运行状态的性能测试脚本的情况下，根据至少一个预设性能指标进行数据采集，得到所述至少一个性能数据。

在一些实施例中，所述执行模块4552，还用于所述确定所述每个测试进程中是否存在非运行状态的性能测试脚本之后，在存在非运行状态的测试脚本情况下，确定是否达到预设测试终止条件；在未达到预设测试终止条件的情况下，在测试进程中重新调用所述性能测试脚本；

所述采集模块4553，还用于采集得到所述至少一个性能数据。

在一些实施例中，所述执行模块4552，还用于所述确定是否达到预设测试终止条件之后，在达到预设测试终止条件的情况下，结束性能测试，得到性能测试结果。

在一些实施例中，所述执行模块4552，还用于确定所述至少一个性能数据是否处于预设压力范围之后，在所述至少一个性能数据处于所述预设压力范围的情况下，不进行进程数量的调整，等待下一采集周期。

在一些实施例中，所述调节模块4554，还用于在所述至少一个性能数据高于所述预设压力范围的情况下，删除第一预设数量个测试进程；或者，在所述至少一个性能数据低于所述预设压力范围的情况下，增加第二预设数量个测试进程；根据所述至少一个预设性能指标，重新采集至少一个性能数据进行判断，直至所述至少一个性能数据处于所述预设压力范围的情况下，处于所述预设压力范围的情况下，得到所述调整后的进程数量；

所述执行模块4552，还用于根据调整后的进程数量继续进行性能测试，直至达到预设测试终止条件的情况下，结束测试，得到所述性能测试结果。

需要说明的是，以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图3-7中示出的方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，本申请实施例通过创建初始进程数量个测试进程，并在每个测试进程中调用性能测试脚本，实现了利用非多进程的测试脚本，实现多进程测试任务的测试场景，减少了编写多进程测试脚本的工作量，提高了常规测试脚本的复用性，从而提高了性能测试效率。并且，通过周期性地检测至少一个性能数据是否处于预设压力范围，进而对进程数量进行调整，实现了根据设备实时性能，动态地管理测试进程数量，从而自适应地保持测试压力，提高了性能测试的准确性。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

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

获取测试任务对应的初始进程数量与性能测试脚本；

根据所述初始进程数量，创建初始进程数量个测试进程，并在每个测试进程中调用所述性能测试脚本，启动性能测试；

根据至少一个预设性能指标，周期性采集至少一个性能数据，并确定所述至少一个性能数据是否处于预设压力范围；

在所述至少一个性能数据不处于所述预设压力范围的情况下，调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果。

2.根据权利要求1所述的方法，其特征在于，所述根据至少一个预设性能指标，周期性采集至少一个性能数据，包括：

在到达当前采集周期时，确定所述每个测试进程中是否存在非运行状态的性能测试脚本；

在不存在非运行状态的性能测试脚本的情况下，根据至少一个预设性能指标进行数据采集，得到所述至少一个性能数据。

3.根据权利要求2所述的方法，其特征在于，所述确定所述每个测试进程中是否存在非运行状态的性能测试脚本之后，所述方法还包括：

在存在非运行状态的测试脚本情况下，确定是否达到预设测试终止条件；

在未达到预设测试终止条件的情况下，在测试进程中重新调用所述性能测试脚本，并采集得到所述至少一个性能数据。

4.根据权利要求3所述的方法，其特征在于，所述确定是否达到预设测试终止条件之后，所述方法还包括：

在达到预设测试终止条件的情况下，结束性能测试，得到性能测试结果。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述确定所述至少一个性能数据是否处于预设压力范围之后，所述方法还包括：

在所述至少一个性能数据处于所述预设压力范围的情况下，不进行进程数量的调整，等待下一采集周期。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果，包括：

在所述至少一个性能数据高于所述预设压力范围的情况下，删除第一预设数量个测试进程；或者，在所述至少一个性能数据低于所述预设压力范围的情况下，增加第二预设数量个测试进程；

根据所述至少一个预设性能指标，重新采集至少一个性能数据进行判断，直至所述至少一个性能数据处于所述预设压力范围的情况下，得到所述调整后的进程数量；

根据调整后的进程数量继续进行性能测试，直至达到预设测试终止条件的情况下，结束测试，得到所述性能测试结果。

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

获取模块，用于获取测试任务对应的初始进程数量与性能测试脚本；

执行模块，用于根据所述初始进程数量，创建初始进程数量个测试进程，并在每个测试进程中调用所述性能测试脚本，启动性能测试；

采集模块，用于根据至少一个预设性能指标，周期性采集至少一个性能数据，并确定所述至少一个性能数据是否处于预设压力范围；

调节模块，用于在所述至少一个性能数据不处于所述预设压力范围的情况下，调整测试进程的数量，根据调整后的进程数量执行性能测试，得到性能测试结果。

8.一种电子设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至6任一项所述的方法。

9.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于被处理器执行时，实现权利要求1至6任一项所述的方法。

10.一种计算机程序产品，包括计算机程序或指令，其特征在于，所述计算机程序或指令被处理器执行时实现权利要求1至6任一项所述的方法。

Images