CN113360396A - 一种软件性能压测方法及装置 - Google Patents

Abstract

本发明涉及计算机技术领域，更具体的说，涉及一种软件性能压测方法及装置。本方法，包括以下步骤：S1、获取应用列表、需求和迭代列表；S2、创建压测项目，关联对应的应用、需求和/或迭代信息；S3、根据资源池可用资源是否满足需求，进行硬件资源调配；S4、根据应用及分配的硬件资源，进行应用部署；S5、根据模板创建压测脚本或复用已有压测脚本，生成压测代码；S6、根据压测代码，创建压测场景，执行压测，生成单场景压测报告；S7、选择需要的压测场景生成压测汇总报告，对压测执行历史进行多维度分析，硬件资源进行回收。本发明从流程自动化的角度进行软件压测，大大节省了整个压测的准备、执行、报告梳理及分析的时间。

Description

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

技术领域

本发明涉及计算机技术领域，更具体的说，涉及一种软件性能压测方法及装置。

背景技术

现有的Pos(销售终端)相关服务、支付相关服务和聚合API(应用程序编程接口)等业务在上线之前都需要做性能评估或容量评估，才能清楚的知晓相关业务在对应硬件资源或不同配置参数下的业务承载量。

压测，即压力测试，是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。

中国发明专利CN 202010073434.X公开了一种应用程序压测方法、装置、计算机设备和存储介质。所述方法包括：通过接收压测服务器发送的压测速度配置信息，该压测速度配置信息用于指示多个不同批次压测的压测速度，该压测速度用于表征单位时间内访问待测应用程序的第一后台服务器集群的次数；然后根据该目标压测设备的性能分别对多个不同批次压测的压测速度进行调整，得到多个不同批次压测的调整压测速度；最后根据多个不同批次压测的调整压测速度，分别对该第一后台服务器集群进行多个不同批次的压测，得到压测结果集合，该压测结果集合用于确定该第一后台服务器集群的并发性能。上述专利的压测方式与业务需求、研发迭代没有进行关联，与整个研发、测试流程相对比较割裂，难以匹配整体研发测试需求。

目前的性能测试方式，主要存在如下问题：

1)大部分压测方式为基于单点的负载机的压测；

2)在整个测试流程中，压测需求缺少上下文(比如需求、迭代等)关联，无法在整个测试流程中体现关联关系；

3)仅关注压测的执行，并没有从压测流程自动化的角度进行考虑及分析。压测过程并没有关联业务需求或研发迭代；

4)仅关注单次压测结果的分析，并没有从整体及多维的角度，对压测的历史数据进行分析。

发明内容

本发明的目的是提供一种软件性能压测方法及装置，解决现有技术的压测方式难以匹配多种业务需求和研发迭代的问题。

为了实现上述目的，本发明提供了一种软件性能压测方法，包括以下步骤：

S1、获取应用列表、需求和迭代列表；

S2、创建压测项目，关联对应的应用、需求和/或迭代信息；

S3、根据资源池可用资源是否满足需求，进行硬件资源调配；

S4、根据应用及分配的硬件资源，进行应用部署；

S5、根据模板创建压测脚本或复用已有压测脚本，生成压测代码；

S6、根据压测代码，创建压测场景，执行压测，生成单场景压测报告；

S7、选择需要的压测场景生成压测汇总报告，对压测执行历史进行多维度分析，硬件资源进行回收。

在一实施例中，所述步骤S1，进一步包括：

通过调用应用资源管理平台接口获取应用列表，并存储在数据库中；

通过调用Teambition开发平台接口获取需求和迭代列表；

通过数据库表记录需求、迭代列表与应用的对应关系。

在一实施例中，所述步骤S2，进一步包括：

压测项目信息通过数据库记录；

压测项目信息，包括所需部署应用及对应的资源要求。

在一实施例中，所述步骤S3，进一步包括：

S31、判断资源池可用资源是否满足需求，如果资源池可用资源不满足需求，则进入步骤S32，如果资源池可用资源满足需求，则进入步骤S33；

S32、发起资源需求申请，完成资源申请后自动加入资源池；

S33、根据压测项目对应的应用、需求和/或迭代信息，自动化分配硬件资源给压测项目。

在一实施例中，所述步骤S4，进一步包括：

调用部署平台接口，传递应用及硬件资源信息，发起部署流程，获取部署成功或失败信息。

在一实施例中，所述步骤S4，进一步包括：

如果部署失败，根据匹配的失败原因，选择对应脚本处理后再次进行部署；

如果没有匹配到失败原因，则接收外界输入新增失败原因及对应的处理脚本。

在一实施例中，所述步骤S5，进一步包括：

根据不同的压测类型，编写示例代码生成代码模板，在创建压测脚本时自动复制模板代码。

在一实施例中，所述步骤S6中创建压测场景，进一步包括，配置不同的压测参数；

所述压测参数包括虚拟用户数、负载机个数、测试时长和采样间隔；

所述步骤S6中单场景压测报告为压测图表；

所述压测图表包括性能图表和应用服务器监控图。

在一实施例中，所述步骤S7中对压测执行历史进行多维度分析，进一步包括：

从应用维度分析压测频率；

从需求和迭代角度分析压测指标变更及趋势；

从接口维度分析应用的接口压测覆盖情况。

为了实现上述目的，本发明提供了一种软件性能压测装置，包括：

存储器，用于存储可由处理器执行的指令；

处理器，用于执行所述指令以实现如上述任一项所述的方法。

为了实现上述目的，本发明提供了一种计算机可读介质，其上存储有计算机指令，其中当计算机指令被处理器执行时，执行如上述任一项所述的方法。

本发明提供了一种软件性能压测方法和装置，从流程自动化的角度(压测前、压测中、压测后)进行软件压测，支持云上和云下的软件性能测试，支持压测应用资源的自动分配和自动部署，支持不同类型的压测场景组合，并生成不同类型的压测报告，并支持汇总报告的邮件通知，对压测数据进行多维度分析。

附图说明

本发明上述的以及其他的特征、性质和优势将通过下面结合附图和实施例的描述而变的更加明显，在附图中相同的附图标记始终表示相同的特征，其中：

图1揭示了根据本发明一实施例的软件性能压测方法流程图；

图2揭示了根据本发明一实施例的软件性能压测方法的详细流程图；

图3揭示了根据本发明一实施例的软件性能压测装置的原理框图；

图4揭示了根据本发明一实施例的软件性能压测装置的功能模块图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释发明，并不用于限定发明。

软件业务或中间件相关的性能测试，包括但不限于http接口、rpc接口，数据库，缓存等的压测评估。

本发明提供了一种软件性能压测方法和装置，从流程自动化的角度(压测前、压测中、压测后)进行软件压测。

压测前，应用资源的自动分配和自动部署，压测中不同类型的压测报告自动生成，压测后支持汇总报告邮件发送及多维度压测数据分析。

压测流程以自动化的形式进行，可以很好的节省压测准备、执行、报告梳理及分析的时间，可以更好的支持常态化压测。

压测历史的多维度分析，可以使业务相关人员更好的了解开发迭代对业务的影响。

图1揭示了根据本发明一实施例的软件性能压测方法流程图，如图1所示，本发明提出的软件性能压测方法，涉及到压测项目创建，资源自动分配及回收方式，应用自动部署方式，场景设计方式、报告指标分类及不同的报告类型，具体包括以下步骤：

S1、获取应用列表、需求和迭代列表；

S2、创建压测项目，关联对应的应用、需求和/或迭代信息；

S3、根据资源池可用资源是否满足需求，进行硬件资源调配；

S4、根据应用及分配的硬件资源，进行应用部署；

S5、根据模板创建压测脚本或复用已有压测脚本，生成压测代码；

S6、根据压测代码，创建压测场景，执行压测，生成单场景压测报告；

S7、选择需要的压测场景生成压测汇总报告，对压测执行历史进行多维度分析，硬件资源进行回收。

下面详细说明本发明的每一步骤。

S1、获取应用列表、需求和迭代列表。

通过调用应用资源管理平台接口获取应用列表，并保存在数据库中。

在本实施例中，直接通过应用接口api获取应用列表，数据库为mysql。

举例来说，应用列表如表1所示。

表1

通过调用Teambition(简称TB)开发平台接口获取需求和迭代列表。

Teambition是阿里巴巴旗下工作学习套件，包含网盘、待办、文档、日历、项目等丰富应用，为每个人每天的工作、学习和生活提供必备工具。

通过数据库表记录TB项目的需求、迭代列表与应用的对应关系，从而TB数据和应用数据可以关联起来。

关联关系的示例如下：

TB项目为“扫码基础”，项目id为5e468316f293180021f0c3f8；

应用为tdbp-baseplatform，对应id为1，tdbp-biptd，对应id为2，则数据库记录表如下表2所示：

表2

TB开放平台接口如下：

获取迭代接口api为

https://open.teambition.com/help/docs/5eb5431641b191001bcda967；

获取需求接口api为

https://open.teambition.com/help/docs/5eb5431341b191001bcda960；

获取任务类型api为

https://open.teambition.com/help/docs/5e3a2585328b9a001bb8255f。

迭代信息包含迭代名称、迭代开始和结束时间等，主要使用到的是迭代名称。

需求信息与此类似，通过任务列表获取任务，通过任务类型api获取任务类型为“需求”的模板Id。通过模板Id在任务中筛选需求。

S2、创建压测项目，关联对应的应用、需求和/或迭代信息。

在有压测需求时，首先创建压测项目，在创建项目时选择关联的应用、需求和迭代，并填写压测相关的说明信息，内容如功能模块“项目创建”中描述。

项目信息会通过数据库记录，压测项目信息包括所需部署应用及对应的资源(CPU、内存、磁盘)要求，为资源自动分配做准备。

本实施例中提出的资源自动分配方式，通过关联应用及资源需求，并通过匹配资源池的方式进行资源自动分配。在项目关闭后，资源进行自动回收。自动化流程可以很大的节省压测资源的准备时间。

举例来说，压测项目信息，可以包括以下信息：

项目名称：签名服务压测项目编号：feature_tdbp-125(关联迭代编号tdbp-49)；

项目所属部门：甲部门开发负责人：张三测试负责人：李四上线时间：2020-08-08功能测试完成时间：2020-08-07；

应用名称：tdbp-baseplatform所需资源：规格：4C8G120G机器数：2；

tdbp-biptd所需资源：规格：8C16G150G机器数：1；

测试目的：统计签名服务TPS情况；

中间件：redis部署地点：阿里云协议：http数据库类型：mysql数据库连接池类型：C3P0；

连接池大小：最小值1-最大值10JVM配置：-Xms256m；

数据库中项目表，包含上面示例数据信息。

S3、根据资源池可用资源是否满足需求，进行硬件资源调配。

项目创建后，平台自动发起资源调配，进一步包括：

S31、判断平台资源池可用硬件资源是否满足需求，如果资源池可用资源不满足需求，则进入步骤S32，如果资源池可用资源满足需求，则进入步骤S33；

S32、发起资源需求申请，完成资源申请后自动加入硬件资源池；

S33、根据压测项目对应的应用、需求和/或迭代信息，自动化分配硬件资源给压测项目。

硬件资源分配后，状态自动标记此资源为占用。

项目关闭后，资源自动回收，状态自动标记为空闲。

自动化资源分配的流程如下，资源池已有机器信息存放在数据库资源表中。

举例来说，数据库资源表如表3所示。

表3

上述表格中，符号“**”，为避免隐私未写或者还有类似的值。

根据步骤S2中，feature_tdbp-125签名服务压测的项目需求，平台查找到项目需要的机器信息为4C8G120G，2台，8C16G150G 1台，根据此硬件资源需求，查询数据库资源表进行资源匹配，剩余资源个数满足需求，则分配资源给此项目，分配信息记录在资源分配历史表里，主要记录哪些项目的哪些应用分配了哪些资源及使用的开始时间及结束时间。

资源自动化分配结束。

S4、根据应用及分配的硬件资源，进行应用部署。

资源分配后，根据应用及分配的机器资源，发起自动部署。

调用部署平台接口，传递应用及硬件资源信息，自动发起部署流程，获取应用部署成功或失败信息。

平台对部署失败原因进行分类，每种失败原因对应的解决方式由脚本自动处理。

如果部署失败，则自动匹配失败原因并通过对应脚本自动处理，然后进行部署重试。

如果没有匹配到对应的失败原因，则人工介入在解决后，接收外界输入新增失败原因及对应的处理脚本。

本实施例中提出的资源自动部署方式，通过关联应用及资源，自动调用部署接口进行应用部署，并通过重试策略处理部署失败的应用。自动化部署方式可以减少人工部署成本，根据失败原因分类及匹配，减少人工处理部署问题的成本。

举例来说，自动化部署流程如下：

feature_tdbp-125项目中应用tdbp-baseplatform分配到资源的ip为192.168.0.1,192.168.0.2；

应用tdbp-biptd分配到的资源ip为192.168.0.3，JVM配置：-Xms256m，部署地点为阿里云；

平台调用部署平台接口：应用名称、ip、jvm、环境为参数，部署平台根据传递的信息发起部署任务(默认为部署最新上线的代码分支)，并将部署结果返回给本发明对应的压测平台。

对于部署失败原因分析，失败原因表中记录各种失败的原因，比如部署平台返回500服务器不可用；503服务占时不可用；这两种设置重试时间为5分钟，5分钟后重新发起自动部署。

如果没有匹配到对应的失败原因，则人工介入，并在解决后新增失败原因及处理脚本。

自动触发部署流程结束。

S5、根据模板创建压测脚本或复用已有压测脚本，生成压测代码。

相关应用部署成功后，根据模板创建压测脚本，脚本创建后，会根据模板自动生成压测代码。

压测人员可以根据模板代码和需求修改代码，代码完成后，平台支持代码调试，以查看代码编写是否正常。

如果有代码历史，可以通过复制形式复用已有代码，使代码调试更便捷。

平台支持创建多个脚本。

代码模板示例如下：

根据不同的压测类型，编写示例代码，在创建脚本时自动复制模板代码。

S6、根据压测代码，创建压测场景，执行压测，生成单场景压测报告。

代码编写完成后，以项目维度，根据代码创建压测场景，配置不同的压测参数。

比如，压测参数包括虚拟用户数、负载机个数、测试时长和采样间隔等信息。

场景配置后，开始执行压测，在压测执行结束后，自动生成单场景压测报告。

本实施例中，单场景压测报告为压测图表，压测图表包括性能图表和应用服务器监控图。压测人员可以从多个维度分析压测数据。数据指标自动生辰，而不是通过命令形式获取指标数据并分析，大大减少数据分析时间。

性能图表包括每秒事务数(TPS，Transaction Per Second)、平均时间(ms)、虚拟用户数和错误数指标在运行区间的趋势图。

应用服务器监控图表包括每台应用服务机器的负载，CPU，内存和网络，磁盘IO及JVM在运行区间的趋势图。

S7、选择需要的压测场景生成压测汇总报告，对压测执行历史进行多维度分析，硬件资源进行回收。

根据压测需求，平台支持创建多个压测场景。

场景测试完成后，通过选择选择一个或多个场景，组合成一个或多个压测汇总报告。

平台支持报告通过邮件发送给对应的干系人。

在压测完成项目关闭后，资源进行自动回收。

对于压测执行历史，可以从多个维度进行分析，进一步包括：

从应用维度分析压测频率；

从需求和迭代角度分析压测指标变更及趋势；

从接口维度，分析应用的接口压测覆盖情况。

通过关联应用及需求，可以从业务的维度，对压测数据进行分析。对于压测执行历史，可以从多个维度进行分析。业务或技术人员可以从全局的角度分析应用的性能。

举例来说，对于应用维度分析压测频率(多应用)，横坐标为时间跨度，纵坐标为应用，值为时间跨度的压测次数、压测场景数及具体压测时间。

举例来说，从需求和迭代角度分析压测指标变更及趋势：横坐标为迭代编号(tdbp-1，tdbp-3)，纵坐标为场景，展示压测接口的场景指标数据曲线。

举例来说，从接口维度分析应用的接口压测覆盖情况：比如应用有10个接口，横坐标为时间，纵坐标为接口名称，在某个时间段内，接口是否有压测。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

图3揭示了根据本发明一实施例的软件性能压测装置的原理框图，软件性能压测装置可包括内部通信总线301、处理器(processor)302、只读存储器(ROM)303、随机存取存储器(RAM)304、通信端口305、以及硬盘307。内部通信总线301可以实现软件性能压测装置组件间的数据通信。处理器302可以进行判断和发出提示。在一些实施例中，处理器302可以由一个或多个处理器组成。

通信端口305可以实现软件性能压测装置与外部的输入/输出设备之间进行数据传输与通信。在一些实施例中，软件性能压测装置可以通过通信端口305从网络发送和接收信息及数据。在一些实施例中，软件性能压测装置可以通过输入/输出端306以有线的形式与外部的输入/输出设备之间进行数据传输与通信。

软件性能压测装置还可以包括不同形式的程序储存单元以及数据储存单元，例如硬盘307，只读存储器(ROM)303和随机存取存储器(RAM)304，能够存储计算机处理和/或通信使用的各种数据文件，以及处理器302所执行的可能的程序指令。处理器302执行这些指令以实现方法的主要部分。处理器302处理的结果通过通信端口305传给外部的输出设备，在输出设备的用户界面上显示。

举例来说，上述的软件性能压测方法的实施过程文件可以为计算机程序，保存在硬盘307中，并可记载到处理器302中执行，以实施本申请的方法。

软件性能压测方法的实施过程文件为计算机程序时，也可以存储在计算机可读存储介质中作为制品。例如，计算机可读存储介质可以包括但不限于磁存储设备(例如，硬盘、软盘、磁条)、光盘(例如，压缩盘(CD)、数字多功能盘(DVD))、智能卡和闪存设备(例如，电可擦除可编程只读存储器(EPROM)、卡、棒、键驱动)。此外，本文描述的各种存储介质能代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可以包括但不限于能存储、包含和/或承载代码和/或指令和/或数据的无线信道和各种其它介质(和/或存储介质)。

图4揭示了根据本发明一实施例的软件性能压测装置的功能模块图，如图4所示，本发明提出一种软件性能压测装置400，支持云上和云下应用的压测，前端主要由八大功能模块组成，具体包括权限管理模块401、项目管理模块402、资源管理模块403、部署管理模块404、脚本管理模块405、场景管理模块406、报告管理模块407及数据分析模块408。

八大功能模块说明如下：

权限管理模块401，平台自动记录登录的人员信息，根据功能设计角色，通过配置人员的角色来实现授权。

项目管理模块402，主要通过项目的维度关联需求、迭代及压测。

项目创建时需要关联产品需求或迭代，应用名称、开发负责人、功能测试完成时间、上线时间、测试目的、测试范围和测试环境等信息。

测试范围包括测试链路、中间件及接口等信息。

环境信息包括部署地点、开发语言、协议(比如http，tcp或者不同的rpc协议)、数据库类型(包括oracle，mysql等数据库类型)，数据库连接池类型及相关配置参数等信息。

资源管理模块403，记录已有的机器资源；

机器资源包括机器的ip、实例id(针对云资源)、操作系统、CPU，内存、磁盘、开机状态及用途。

部署管理模块404，主要记录应用的部署信息。

脚本管理模块405，对项目的压测脚本进行管理。

场景管理模块406，根据压测脚本，配置压测场景，压测并生成压测报告。

报告管理模块407，场景管理中，选择不同的压测场景生成报告，并可以通过邮件发送。

数据分析模块408，从不同的维度进行数据分析，包括应用压测频率分析、应用压测接口分析和接口指标数据分析。

本发明提供了一种软件性能压测方法和装置，从流程自动化的角度(压测前、压测中、压测后)进行软件压测，流程以自动化的形式进行，大大节省了整个压测的准备、执行、报告梳理及分析的时间。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。

本领域技术人员将可理解，信息、信号和数据可使用各种不同技术和技艺中的任何技术和技艺来表示。例如，以上描述通篇引述的数据、指令、命令、信息、信号、位(比特)、码元、和码片可由电压、电流、电磁波、磁场或磁粒子、光场或光学粒子、或其任何组合来表示。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

上述实施例是提供给熟悉本领域内的人员来实现或使用本发明的，熟悉本领域的人员可在不脱离本发明的发明思想的情况下，对上述实施例做出种种修改或变化，因而本发明的保护范围并不被上述实施例所限，而应该是符合权利要求书提到的创新性特征的最大范围。

Claims (10)

1.一种软件性能压测方法，其特征在于，包括以下步骤：

S1、获取应用列表、需求和迭代列表；

S2、创建压测项目，关联对应的应用、需求和/或迭代信息；

S3、根据资源池可用资源是否满足需求，进行硬件资源调配；

S4、根据应用及分配的硬件资源，进行应用部署；

S5、根据模板创建压测脚本或复用已有压测脚本，生成压测代码；

S6、根据压测代码，创建压测场景，执行压测，生成单场景压测报告；

S7、选择需要的压测场景生成压测汇总报告，对压测执行历史进行多维度分析，硬件资源进行回收。

2.根据权利要求1所述的软件性能压测方法，其特征在于，所述步骤S1，进一步包括：

通过调用应用资源管理平台接口获取应用列表，并存储在数据库中；

通过调用Teambition开发平台接口获取需求和迭代列表；

通过数据库表记录需求、迭代列表与应用的对应关系。

3.根据权利要求1所述的软件性能压测方法，其特征在于，所述步骤S2，进一步包括：

压测项目信息通过数据库记录；

压测项目信息，包括所需部署应用及对应的资源要求。

4.根据权利要求1所述的软件性能压测方法，其特征在于，所述步骤S3，进一步包括：

S31、判断资源池可用资源是否满足需求，如果资源池可用资源不满足需求，则进入步骤S32，如果资源池可用资源满足需求，则进入步骤S33；

S32、发起资源需求申请，完成资源申请后自动加入资源池；

S33、根据压测项目对应的应用、需求和/或迭代信息，自动化分配硬件资源给压测项目。

5.根据权利要求1所述的软件性能压测方法，其特征在于，所述步骤S4，进一步包括：

调用部署平台接口，传递应用及硬件资源信息，发起部署流程，获取部署成功或失败信息；

如果部署失败，根据匹配的失败原因，选择对应脚本处理后再次进行部署；

如果没有匹配到失败原因，则接收外界输入新增失败原因及对应的处理脚本。

6.根据权利要求1所述的软件性能压测方法，其特征在于，所述步骤S5，进一步包括：

根据不同的压测类型，编写示例代码生成代码模板，在创建压测脚本时自动复制模板代码。

7.根据权利要求1所述的软件性能压测方法，其特征在于：

所述步骤S6中创建压测场景，进一步包括，配置不同的压测参数；

所述压测参数包括虚拟用户数、负载机个数、测试时长和采样间隔；

所述步骤S6中单场景压测报告为压测图表；

所述压测图表包括性能图表和应用服务器监控图。

8.根据权利要求1所述的软件性能压测方法，其特征在于，所述步骤S7中对压测执行历史进行多维度分析，进一步包括：

从应用维度分析压测频率；

从需求和迭代角度分析压测指标变更及趋势；

从接口维度分析应用的接口压测覆盖情况。

9.一种软件性能压测装置，包括：

存储器，用于存储可由处理器执行的指令；

处理器，用于执行所述指令以实现如权利要求1-8任一项所述的方法。

10.一种计算机可读介质，其上存储有计算机指令，其中当计算机指令被处理器执行时，执行如权利要求1-8任一项所述的方法。

Images