CN113553267A

CN113553267A - 应用性能测试方法、设备、介质及计算机程序产品

Info

Publication number: CN113553267A
Application number: CN202110840833.9A
Authority: CN
Inventors: 陈运权; 许治华; 金清华; 罗伟涌; 陈睿扬
Original assignee: China Merchants Bank Co Ltd
Current assignee: China Merchants Bank Co Ltd
Priority date: 2021-07-22
Filing date: 2021-07-22
Publication date: 2021-10-26

Abstract

本申请公开了一种应用性能测试方法、设备、介质及计算机程序产品，分别获取目标应用在压力端、服务器端、应用端的应用数据；基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常；若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案。本申请可以根据目标应用在压力端、服务器端及应用端的应用数据，对压力端、服务器端及应用端进行逐层分析，以准确地确定目标应用是否在各端中存在性能异常，并在确定存在性能异常时，快速定位性能异常对应的性能问题，最后根据性能问题生成相应的应用性能优化方案，有效提高应用性能测试的质量与效率。

Description

应用性能测试方法、设备、介质及计算机程序产品

技术领域

本申请涉及通信技术领域，尤其涉及一种应用性能测试方法、设备、介质及计算机程序产品。

背景技术

随着互联网技术特别是移动互联网技术的发展，计算机软件***的用户量和访问量均出现了指数级的增长，对软件的可靠性、稳定性、兼容性等非功能性要求日益迫切。为满足***非功能性要求，软件***架构从以往简单的单体应用逐步向复杂的分布式、微服务等架构转变，给软件***的性能瓶颈分析定位带来了巨大的挑战。针对微服务架构下软件应用的性能瓶颈分析定位成为软件研发体系中不可或缺的一环，常见软件性能测试或***性能优化在欠缺平台或***支持的情况下，需要性能相关人员利用工具来压测、监控、分析定位软件的性能瓶颈，由于过于依赖实施人员的测试技能水平，无法保证测试的质量和效率，使得当前应用性能测试的质量与效率较低。

发明内容

本申请的主要目的在于提供一种应用性能测试方法、设备、介质及计算机程序产品，旨在解决当前应用性能测试的质量与效率较低的技术问题。

为实现上述目的，本申请实施例提供一种应用性能测试方法，所述应用性能测试方法包括：

分别获取目标应用在压力端、服务器端、应用端的应用数据；

基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常；

若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案。

优选地，所述基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常的步骤包括：

获取预设测试规则；

根据所述预设测试规则与各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常。

优选地，所述预设测试规则包含压力端测试规则、服务器端测试规则与应用端测试规则；

所述根据所述预设测试规则与各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常的步骤包括：

将所述目标应用在所述压力端的应用数据与所述压力端测试规则进行对比，确定所述目标应用是否在所述压力端存在性能异常；

将所述目标应用在所述服务器端的应用数据与所述服务器端测试规则进行对比，确定所述目标应用是否在所述服务器端存在性能异常；

将所述目标应用在所述应用端的应用数据与所述应用端测试规则进行对比，确定所述目标应用是否在所述应用端存在性能异常。

优选地，所述预设测试规则还包含链路端测试规则，所述将所述目标应用在所述服务器端的应用数据与所述服务器端测试规则进行对比，确定所述目标应用是否在所述服务器端存在性能异常的步骤包括：

获取所述目标应用在链路端的应用数据；

将所述目标应用在所述链路端的应用数据与所述链路端测试规则进行对比，确定所述目标应用是否在所述链路端存在性能异常；

将所述目标应用在所述服务器端的应用数据与所述服务器端测试规则进行对比，确定所述目标应用是否在所述服务器端存在性能异常。

优选地，所述若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案的步骤包括：

若存在性能异常，则对存在性能异常的目标端进行问题定位，得到目标端的性能问题；

根据所述性能问题生成目标应用在所述目标端的应用性能优化方案。

优选地，所述根据所述性能问题生成目标应用在所述目标端的应用性能优化方案的步骤包括：

将所述性能问题与预设数据库中的预设性能问题进行问题匹配；

将所述预设数据库中与所述性能问题匹配的预设性能问题确定目标性能问题；

从所述预设数据库中获取所述目标性能问题对应的应用性能优化方案作为所述目标应用在所述目标端的应用性能优化方案。

优选地，所述分别获取目标应用在压力端、服务器端、应用端的应用数据的步骤包括：

基于预设压力测试工具获取目标应用在压力端的应用数据；

基于预设服务器组件获取所述目标应用在服务器端的应用数据；

基于预设信息采集器获取所述目标应用在应用端的应用数据。

进一步地，为实现上述目的，本申请还提供一种应用性能测试设备，所述应用性能测试设备包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的应用性能测试程序，所述应用性能测试程序被所述处理器执行时实现上述的应用性能测试方法的步骤。

进一步地，为实现上述目的，本申请还提供一种存储介质，所述存储介质上存储有应用性能测试程序，所述应用性能测试程序被处理器执行时实现上述的应用性能测试方法的步骤。

进一步地，为实现上述目的，本申请还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述的应用性能测试方法的步骤。

本申请实施例提供一种应用性能测试方法、设备、介质及计算机程序产品，分别获取目标应用在压力端、服务器端、应用端的应用数据；基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常；若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案。本申请可以根据目标应用在压力端、服务器端及应用端的应用数据，对压力端、服务器端及应用端进行逐层分析，以准确地确定目标应用是否在各端中存在性能异常，并在确定存在性能异常时，快速定位性能异常对应的性能问题，最后根据性能问题生成相应的应用性能优化方案，有效提高应用性能测试的质量与效率。

附图说明

图1为本申请应用性能测试方法实施例方案涉及的硬件运行环境的结构示意图；

图2为本申请应用性能测试方法第一实施例的流程示意图；

图3为本申请第一实施例中***的结构示意图；

图4为本申请应用性能测试方法第二实施例的流程示意图；

图5为本申请应用性能测试方法第三实施例的流程示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

如图1所示，图1是本申请实施例方案涉及的硬件运行环境的应用性能测试设备结构示意图。

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本申请的说明，其本身没有特定的意义。因此，“模块”、“部件”或“单元”可以混合地使用。

本申请实施例应用性能测试设备可以是PC，也可以是平板电脑、便携计算机等可移动式终端设备。

如图1所示，该应用性能测试设备可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的应用性能测试设备结构并不构成对应用性能测试设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作***、网络通信模块、用户接口模块以及应用性能测试程序。

在图1所示的设备中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的应用性能测试程序，并执行以下操作：

进一步地，所述基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常的步骤包括：

获取预设测试规则；

进一步地，所述预设测试规则包含压力端测试规则、服务器端测试规则与应用端测试规则；

进一步地，所述预设测试规则还包含链路端测试规则，所述将所述目标应用在所述服务器端的应用数据与所述服务器端测试规则进行对比，确定所述目标应用是否在所述服务器端存在性能异常的步骤包括：

获取所述目标应用在链路端的应用数据；

进一步地，所述若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案的步骤包括：

优进一步地，所述根据所述性能问题生成目标应用在所述目标端的应用性能优化方案的步骤包括：

进一步地，所述分别获取目标应用在压力端、服务器端、应用端的应用数据的步骤包括：

基于预设压力测试工具获取目标应用在压力端的应用数据；

为了更好的理解上述技术方案，下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。

参照图2，本申请第一实施例提供一种应用性能测试方法的流程示意图。该实施例中，所述应用性能测试方法包括以下步骤：

步骤S10，分别获取目标应用在压力端、服务器端、应用端的应用数据；

本实施例中应用性能测试方法应用于Java微服务应用性能瓶颈定位分析***，为方便描述，后续将Java微服务应用性能瓶颈定位分析***简称为***，参照图3，图3为本申请第一实施例中***的结构示意图，***中包含用于进行数据采集的数据采集层、用于进行数据分析的数据分析层以及用于进行性能诊断的智能诊断层，数据采集层通过压测平台、Agent以及Arthas分别采集应用在压力端、应用服务器端以及JVM端的应用数据；数据分析层则预先根据专家经验生成包含阈值规则与趋势识别的预设测试规则，以数据采集层采集的应用数据进行性能测试；若确定存在性能异常，智能诊断层则进行问题定位，并根据定位的性能问题生成优化方案。其中，Java是一门面向对象的编程语言，具有简单性、面向对象、分布式、健壮性、安全性、平***立与可移植性、多线程、动态性等特点，微服务(或微服务架构)是一种云原生架构方法，Java微服务应用即为基于Java与微服务架构的应用，应用性能瓶颈可以理解为应用的性能缺陷，因此***可以用于进行基于Java与微服务架构的应用的性能缺陷的定位及分析。

可以理解地，在完成软件研发得到Java微服务应用后，为了确保该应用在上线时具备较好的性能以提高用户的使用体验，需要对该应用进行性能测试，确定该应用是否存在性能瓶颈，若不存在则可以将该应用上线；而若在测试后发现该应用存在性能瓶颈，则需要先对该应用产生性能瓶颈进行定位来确定对应的性能问题，再针对性能问题形成应用性能优化方案，最后将应用性能优化方案推送给性能测试人员和开发人员参考，以便于性能测试人员和开发人员对该应用进行优化。

具体地，针对需要进行性能测试的应用，先将该应用作为目标应用部署于服务器并运行，再对运行的目标应用进行场景模拟，以根据目标应用在该场景下的运行信息对目标应用的性能进行测试。

进一步地，在目标应用的运行过程中，***调用数据采集层，通过数据采集层从压力的源头获取目标应用在大并发情况下业务全流程的监控数据，即分别获取目标应用在压力端、服务器端、应用端的应用数据，本实施例中目标应用在压力端的应用数据包括压测数据及其波动曲线，目标应用在服务器端的应用数据包括资源消耗数据及其曲线，目标应用在应用端的应用数据包括JVM(Java Virtual Machine，Java虚拟机)性能数据及其曲线。其中，压力端通过压测平台集成开源压力测试工具Jmeter获取并发数、场景配置、并发请求及其错误率、性能黄金指标曲线等应用数据；服务器端通过不同的服务器agent组件获取环境检查及环境配置信息，例如ServerBaseInfo[Hardware，Software，Configurations]配置信息；JVM应用端通过arthas获取CPU(central processing unit，中央处理器)消耗前十的类及方法、线程状态、GC日志、堆栈状态等，Arthas(阿尔萨斯)是阿里巴巴开源的Java诊断工具。

步骤S11，基于预设压力测试工具获取目标应用在压力端的应用数据；

步骤S12，基于预设服务器组件获取所述目标应用在服务器端的应用数据；

步骤S13，基于预设信息采集器获取所述目标应用在应用端的应用数据。

可以理解地，本实施例中***包含压力发起端(具体为压测平台)、服务器监控端(具体为agent监控)、应用监控端(具体为arthas监控)，因此，在分别获取目标应用在压力端、服务器端、应用端的应用数据时，***调用数据采集层中预设的压力测试工具-压测平台，通过压测平台获取目标应用运行时在压力端的并发数、场景配置、并发请求及其错误率、性能黄金指标曲线等应用数据，其中，压测平台基于Jmeter开源工具二次开发，兼容Jmeter工具的脚本、测试数据、测试场景和测试结果，能实时展示并发压力端的并发数的变化趋势曲线、交易的平均响应时间曲线、***吞吐量TPS的曲线、业务交易统计数据(包括成功率、失败率)等。用户可通过普通Java IDE工具开发业务脚本生成jar文件，也可以通过Jmeter开发jmx脚本，将上述文件或脚本导入到压测平台，在压测平台配置测试数据参数文件，根据业务需要准备与生成环境类似或相近的测试环境，亦可直接使用生产环境或灰度环境。用户可在压测平台上以手动或定时任务的方式自动执行脚本/场景，数据采集层采集用户配置的并发数、并发数增长规则、并发时间等规则参数，根据Jmeter压力机执行结果，绘制压力端黄金指标曲线，以此实现全链路监控平台根据业务关键路径上子***或应用之间的调用情况，监控各个节点的时延，用以辅助判断从压力端到应用端全流程的压力传递情况。对于常见的简单前端UI-后端App-数据库Database三层架构的***，或单体部署的***，直接监控应用、数据库的资源指标即可确定性能瓶颈点的位置。而若***部署较为复杂，如微服务部署的***，或***之间调用复杂的场景下，如何确定业务关键路径的瓶颈点成为最为棘手和关键的问题。因此，在数据分析层工作处理之前，数据采集层会提前进行环境检查，并初步分析黄金指标曲线和交易日志错误率，排除压力端可能的性能评级，接下来数据分析层会同时监控关键路径上多个微服务服务器的资源消耗，结合链路时延和业务调用拓扑图，可以清晰的预警哪个节点出现压力异常或业务交易报错。作为第一层次的分析结论，第二层将深入分析可能的瓶颈节点，基于监控平台和arthas获取的当前节点JVM信息(线程数据、GC数据、堆/非对内存使用)，应用的类和方法CPU耗时，来进一步下钻分析可能存在性能瓶颈的代码段，而目前大多数Java应用性能瓶颈分析方法只部分实现了第二层，其中GC为Garbage Collection，即垃圾回收。具体地，***通过数据采集层中的压测平台获取压力机(单台或分布式多台)服务器资源[CPU，Memory，Network]使用情况曲线及异常报错占比曲线等应用数据，其中CPU指标包括[运行队列中进程数量，用户进程消耗的CPU时间百分比，内核进程消耗的CPU时间百分比，I/O(输入与输出)等待消耗的CPU时间百分比，CPU处于空闲状态时间百分比，每秒产生的上下文切换次数]，Memory指标包括[空闲物理内存大小，物理内存大小，空闲交换空间大小，交换空间总大小，文件句柄数]，Network指标包括[established状态连接数，time_wait状态连接数，close_wait状态连接数]。压力机端黄金指标，包括压测场景相关的并发数及分布情况曲线(与压测场景相关)，与Jmeter设置相关的并发数量、压力持续时间，压力间隔时间。压力机端响应时间及分布情况曲线(包括成功请求和失败请求)。以此得到目标应用在压力端的应用数据。

同时，***通过预设的服务器组件-agent监控组件获取微服务部署架构中与压测链路相关的各微服务节点耗时曲线等应用数据，包括业务***关键路径(***部署架构拓扑)、路径各节点耗时、耗时占比、耗时趋势曲线等。以及服务器资源利用率及变化趋势，应用服务器资源[CPU，Memory，I/O，Network]使用情况曲线及异常指标曲线，其中CPU/Memory/Network指标与压力端指标相同，I/O指标包括[每秒读字节数(K)，每秒写字节数(K)，平均I/O队列长度，平均每次设备I/O操作的等待时间(毫秒)，平均每次设备I/O操作的服务时间(毫秒)，一秒中内用于I/O操作的百分比，每秒的I/O读写次数]。应用服务器操作***级参数，如Linux的TCP相关参数，指标包括[net.ipv4.tcp_tw_reuse，net.ipv4.tcp_tw_recycle，net.ipv4.ip_local_port_range，net.ipv4.tcp_max_tw_buckets，openfiles]。以此得到目标应用在服务器端的应用数据。其中，服务器监控组件分为一键环境检查和服务器资源消耗两个维度监控交易的压力传递情况。在发起并发压力之前，服务器agent监控组件对被测环境的软硬件及其参数配置进行一键环境检查，常见的参数可参考采集层指标规则库描述；在压测过程中，agent监控业务全流程关键路径上服务器资源的消耗。服务器agent监控组件涉及到agent执行脚本、agent调度命令、agent指标等，其中agent指标由用户预先配置在指标规则库，agent执行脚本会根据对应服务器的不同有差异，常见的应用服务器有RS6000，X86物理机/虚拟机，操作***类型有AIX、Linux、Windows，常用命令有sar/top/iostat/vmstat/netstat/RM调用/CMD命令行等。在执行脚本之前，需要检查相应服务器的脚本命令环境，服务器用户等。agent调度命令在压测平台压力场景中配置，可选择监控的指标、监控的频率、预警规则等。所有服务器agent采集到服务器资源信息后，统一汇总到监控平台，展示服务器资源消耗随并发压力的变化曲线。

***还通过预设信息采集器-arthas监控获取服务器JVM级相关环境配置信息，JVM参数信息包括[GC算法，JDK版本，Xms配置，Xmx配置]。以及获取应用级相关资源利用率及变化趋势，包括线程、GC、类调用情况、dump日志等，其中包括：线程信息，线程堆栈信息，TOP 10(前十)线程CPU消耗及占比，线程指标包括[当前线程总数，线程状态分布，线程CPU使用率，线程CPU使用率排行，线程堆栈信息]。还获取内存信息、使用率及变化曲线，指标包括[堆内存使用率，eden区使用率，survivor区使用率，老年代使用率，非堆内存使用率，代码缓存区使用率，元数据区使用率，类压缩空间使用率]。还获取JVM已加载类、方法统计信息、执行次数(成功/失败)，指标包括[类名，方法名，总执行次数，执行成功次数，执行失败次数，平均执行耗时，执行失败率]。还获取单应用节点代码级调用链路上的性能开销和调用链路占比，指标包括[调用的类名，调用的方法名，调用耗时，调用方法的栈信息]。还获取GC统计信息及GC曲线，指标包括[minorGC次数，minorGC耗时，youngGC次数，youngGC耗时，fullGC次数，fullGC耗时]。以此得到目标应用在应用端的应用数据。其中，应用端监控agent基于arthas开源工具二次开发，可通过调用arthas的接口，获取JVM指标数据(即目标应用在应用端的应用数据)。应用端Dashboard监控面板展示应用综合监控数据，调用arthas.dashboard接口获取，包括活动线程状态、线程数、线程优先级等线程相关信息，各项堆、非堆内存使用率、GC执行情况等内存相关信息。针对具体的线程和类的CPU消耗情况，调用arthas.thread接口查看服务器CPU使用率及CPU使用率排行靠前的线程信息，调用arthas.profiler获取火焰图查看CPU消耗较高的类。调用arthas trace接口，根据类名、方法名获取具体耗时，统计调用链路上所有的性能开销，跟踪调用链路情况。调用arthasmonitor接口，查看具体类、方法的执行次数，执行成功率等。

步骤S20，基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常；

在获取到目标应用在压力端、服务器端、应用端的应用数据后，***先调用数据分析层对获取到的应用数据进行清洗和标准化整理，再获取用于根据应用数据测试应用是否存在性能异常的预设测试规则，并根据预设测试规则与各应用数据，分别确定目标应用是否在压力端、服务器端、应用端存在性能异常，其中预设测试规则包含压力端测试规则、服务器端测试规则与应用端测试规则。具体地，***先将目标应用在压力端的应用数据与压力端测试规则进行对比，确定目标应用是否在压力端存在性能异常。在压力端测试完成后，再将目标应用在服务器端的应用数据与服务器端测试规则进行对比，确定目标应用是否在服务器端存在性能异常；进一步地，在服务器端测试完成后，再将目标应用在应用端的应用数据与应用端测试规则进行对比，确定目标应用是否在应用端存在性能异常，由此实现从整体层面诊断业务全流程中可能的性能瓶颈节点，再针对局部节点级别，抓取分析瓶颈节点上的JVM监控数据，结合业务逻辑，进一步深入下钻到源代码级别，定位分析源代码的性能瓶颈代码段的测试方式，可快速定位出目标应用发生性能异常的节点。

步骤S30，若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案。

若经测试目标应用是否在压力端、服务器端、应用端中的一端或多端存在性能异常，***则将存在性能异常的一端或多端确定为目标端，再通过智能诊断层对目标端的性能异常进行准确的定位，以此定位出目标端存在的性能问题。在定位出目标端的性能问题后，***再根据确定的性能问题生成相应的应用性能优化方案，并将应用性能优化方案推送给性能测试人员和开发人员参考，以便于性能测试人员和开发人员对该应用进行优化。

可以理解地，若在完成性能测试后确定目标应用在各端都不存在性能异常，***则结束当前的应用测试流程。

本实施例提供一种应用性能测试方法、设备、介质及计算机程序产品，分别获取目标应用在压力端、服务器端、应用端的应用数据；基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常；若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案。本申请可以根据目标应用在压力端、服务器端及应用端的应用数据，对压力端、服务器端及应用端进行逐层分析，以准确地确定目标应用是否在各端中存在性能异常，并在确定存在性能异常时，快速定位性能异常对应的性能问题，最后根据性能问题生成相应的应用性能优化方案，有效提高应用性能测试的质量与效率。

进一步地，参照图4，基于本申请应用性能测试方法的第一实施例，提出本申请应用性能测试方法的第二实施例，在第二实施例中，所述基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常的步骤包括：

步骤S21，获取预设测试规则；

步骤S22，根据所述预设测试规则与各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常。

可以理解地，本实施例中在对目标应用进行性能测试之前，***调用数据分析层并基于项目实践的历史经验数据和专家经验库，提炼潜在的性能瓶颈点及对应的参数阈值规则，形成用于判断目标应用在各端是否存在性能异常的预设测试规则，使得在基于目标应用在各端的应用数据，分别确定目标应用是否在压力端、服务器端、应用端存在性能异常时，可以直接获取预设测试规则来结合目标应用在各端的应用数据判断是否存在性能异常，其中，预设测试规则包含压力端测试规则、服务器端测试规则与应用端测试规则。具体地，在本实施例中，先根据预设测试规则中的压力端测试规则与目标应用在压力端的应用数据，确定目标应用在压力端是否存在性能异常，以在测试到目标应用在压力端存在性能异常时进行性能问题定位并生成对应的解决方案；在压力端测试完毕后，***根据预设测试规则中的服务器端测试规则与目标应用在服务器端的应用数据，确定目标应用在服务器端是否存在性能异常，以在测试到目标应用在服务器端存在性能异常时进行性能问题定位并生成对应的解决方案；进一步地，在服务器端测试完毕后，***根据预设测试规则中的应用端测试规则与目标应用在应用端的应用数据，确定目标应用在应用端是否存在性能异常，以在测试到目标应用在应用端存在性能异常时进行性能问题定位并生成对应的解决方案。通过先后测试目标应用是否在压力端、服务器端、应用端存在性能异常，实现在目标应用压力的传递路径上，分别从压力端、服务器端、应用端逐层分析，从服务器级、虚拟机级、应用级、线程级、代码级逐级下钻，以定位最终的性能问题和瓶颈点，从而可以快速确定目标应用在各端是否存在性能异常。

进一步地，所述根据所述预设测试规则与各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常的步骤包括：

步骤S221，将所述目标应用在所述压力端的应用数据与所述压力端测试规则进行对比，确定所述目标应用是否在所述压力端存在性能异常；

步骤S222，将所述目标应用在所述服务器端的应用数据与所述服务器端测试规则进行对比，确定所述目标应用是否在所述服务器端存在性能异常；

步骤S223，将所述目标应用在所述应用端的应用数据与所述应用端测试规则进行对比，确定所述目标应用是否在所述应用端存在性能异常。

进一步地，在确定目标应用是否在压力端、服务器端、应用端存在性能异常时，***可以通过数据分析层根据压测场景、压测黄金指标趋势变化、***日志错误率等指标数据，进行多层次性能问题分析和定位。以及根据***架构、***环境配置等基础场景，一方面绘制***监控的拓扑图，识别***的业务基准规则；另一方面，结合业务关键路径、***调用关系图谱，根据黄金指标曲线趋势和业务关键路径监控指标趋势，基于专家经验库规则，识别可能的性能瓶颈点，深入下钻到应用核心指标库，定位应用具体的性能瓶颈。

具体地，***先根据预设测试规则中的环境配置规则对目标应用的环境配置进行测试，具体地，环境配置规则包括应用端JVM参数配置、应用服务器参数配置、应用配置文件、应用数据库之间参数配置。针对应用端JVM参数配置，如Xms，Xmx，XX:MetaspaceSize，Xss等参数，可通过测试前环境检查，与基准测试和经验推荐值比较，判断参数设置是否合理。针对应用服务器参数配置，可解析应用的application.yml文件，获取应用与中间件(例如kafka、redis等)、******的连接串配置，基于性能基准和业务要求，判断连接数、工作线程池、超时时间等参数设置是否合理。针对数据库参数配置，本实施例中以Oracle数据库为例，解析连接串设置，检查的内容包括负载均衡模式，超时尝试次数、sga内存大小、pga内存大小、pga使用限制、sessions数量、共享缓存区大小等参数是否基于性能基准值在合理的配置范围内。基于上述环境配置规则与当前配置环境数据确定环境配置是否合理，若环境配置不合理，则根据不合理的环境配置参数生成环境配置优化方案推送给开发人员与测试人员，以便开发人员或测试人员对环境配置参数进行调整。

在环境配置测试完成后，***先将目标应用在压力端的应用数据与压力端测试规则进行对比，具体地，压力端测试规则主要从黄金指标曲线与压力机资源相关性、黄金指标曲线的趋势、业务场景之间的占比等入手。首先，分析压力端并发数、间隔时间、压力机分布等配置，如大并发压力下，压力端的的资源消耗过高，对各项性能黄金指标的影响；随着并发压力增大，平均响应时间增长曲线是否同步；压力机、应用服务器端的连接数是否同步增加；TPS曲线是否存在波动，波动是否存在规律性。以此来判断，压力机的软硬件配置、应用的连接数配置是否满足性能要求。其次，基于测试设计的考虑，从基准测试场景入手，分析基准测试场景黄金指标波动曲线，对比压力增大单交易业务场景、多交易混合场景下指标的波动曲线，以此判断业务、数据之间是否存在相互影响。基于上述压力端测试规则与目标应用在压力端的应用数据的对比，确定目标应用是否在所述压力端存在性能异常，若目标应用在压力端的应用数据不满足压力端测试规则则确定存在性能异常，以在测试到目标应用在压力端存在性能异常时进行性能问题定位并生成对应的解决方案。

在压力端测试完成后，***获取目标应用在链路端的应用数据，先将目标应用在链路端的应用数据与链路端测试规则进行对比，确定目标应用是否在链路端存在性能异常，若目标应用在链路端的应用数据满足链路端测试规则，则确定不存在性能异常，若目标应用在链路端的应用数据不满足链路端测试规则，则确定目标应用在链路端存在性能异常。在链路端测试完成后再将目标应用在服务器端的应用数据与服务器端测试规则进行对比，确定目标应用是否在服务器端存在性能异常，若目标应用在服务器端的应用数据满足服务器端测试规则，则确定不存在性能异常，若目标应用在服务器端的应用数据不满足服务器端测试规则，则确定存在性能异常，以在测试到目标应用在服务器端存在性能异常时进行性能问题定位并生成对应的解决方案。

在服务器端测试完成后，***将目标应用在应用端的应用数据与应用端测试规则进行对比，具体地，由于在常见的项目和场景中，应用端的性能问题占比达到了50％以上，一般包括：程序设计问题、参数设置不合理、并发错误、内存溢出、线程锁、内存泄露、负载不均衡等。因此应用端的分析思路主要从CPU热点、内存使用率、磁盘I/O等方面入手。例如，分析CPU热点，首要判断CPU使用率与阈值区间的比较。若CPU消耗过高，判断CPU消耗是否与压力增加有关，查看GC曲线及内存使用率，判断是否存在内存泄露造成频繁fullGC；进一步获取CPU消耗热点线程，判断是否为业务相关线程，查看CPU消耗热点类和方法，追踪热点方法调用链路，分析调用链路上所有的性能开销；若CPU消耗过低，对比压测前后工作线程变化与并发数的关系，查看线程状态是否存在阻塞，阻塞线程数量是否逐渐增加，定位阻塞的线程、类和方法，判断是否因为死锁造成阻塞线程增加，cpu消耗较低，还是因为线程之间存在过度同步的方法，阻塞线程数量保持稳定，然而CPU消耗较低。例如，内存使用率超过阈值区间，判断堆内存的配置值是否合理，若堆内存值配置合理，查看压测区间是否存在频繁fullGC，堆内存增长较快，辅助堆栈dump日志，判断是否存在内存泄露或堆栈溢出问题；若GC曲线无异常，堆内存使用率无明显变化，可以进一步分析占用堆内存较高的实例信息。例如，I/O诊断思路和方法，分析服务器磁盘使用率、IOPS、吞吐量和响应时间的关系，确认I/O问题的来源，通过文件句柄数量判断是否文件***出现性能问题；对比每秒读K字节数和每秒写K字节数与基准性能指标，是否达到磁盘硬件限制；通过pidstat判断操作磁盘进程是否为业务进程，定位与业务相关的磁盘文件。基于上述应用端测试规则与目标应用在应用端的应用数据的对比，确定目标应用是否在应用端存在性能异常。若目标应用在应用端的应用数据满足上述应用端测试规则，则确定不存在性能异常，若目标应用在应用端的应用数据不满足应用端测试规则，则确定存在性能异常。

对于预设测试规则，举例说明，对于一台常见的2个cpu，8G内存配置的虚拟机，部署一个TCP协议的挡板应用服务，在同一个机房万兆网卡联通的压力机访问，预期能达到的最优TPS指标、响应时间指标、错误率指标等，此时虚拟机的TCP参数配置，连接数配置等，可以作为一个基准的测试规则项。类似的，对于一个常见配置2个cpu，8G内存的Oracle RAC库配置，单表被测数据容量在亿级别以上，有无索引，单条/批量查询语句、***语句等基准访问的最优黄金指标曲线，此时数据库的sga/pga/db_pool_size等参数的设置也可以作为基准参数库指标。另外，单个业务交易场景，并发数逐渐增加的测试数据，也可以作为混合业务场景、异常业务场景等其他场景的基准指标数据。

在确定某个疑似性能瓶颈应用节点之后，通过***级、JVM级、代码级逐层下钻分析来定位根因。这里常见的专家经验规则主要包括CPU耗时、内存消耗、I/O消耗等异常分析方法。本申请实例分析规则如下：

监控疑似存在性能瓶颈节点应用服务器的CPU消耗情况，若应用服务器CPU使用率高于阈值范围，但性能黄金指标曲线不达标或趋势存在不规则波动。可通过监控JVM堆内存使用情况和GC的次数耗时来辅助判断。若压测过程中，出现频繁fullGC且堆内存使用率随着压力增加而增长较大，可获取堆内存使用增长较大，占堆内存使用率较高的TOP 5热点线程和热点方法，也可获取堆dump日志来定位具体性能瓶颈的代码段，从而确定是否存在内存泄露或堆栈溢出的代码段，若对比业务逻辑和堆dump日志，不存在内存泄漏或堆栈溢出，可再次检查JVM参数配置是否合理，是否满足业务逻辑需求。若GC统计中在正常阈值范围内，且GC和堆内存使用率曲线趋势平稳，则通过arthas.thread接口获取获取CPU消耗高的TOP 5线程，通过arthas.trace接口查看各线程对应方法耗时，arthas.monitor接口查看类和方法的调用情况，输出平均TOP 5方法平均耗时，最终结合业务场景分析定位性能瓶颈代码段。若应用服务器CPU使用率过低，且随着并发压力增加，CPU使用率无明显增加趋势，则对比压力增加前后应用服务器工作线程数的变化。若线程数变化远小于并发数，可诊断为工作线程参数设置不合理；若工作线程数变化与并发数趋近，则判断是否存在阻塞状态的线程。若无阻塞状态线程，则回溯源头，是否压力传导过程中出现阻塞。若存在阻塞状态的工作线程，且随着并发压力增加，阻塞线程数增加，可诊断为出现了死锁，分析线程dump日志可以确定造成死锁的根源。若随着并发压力增加，阻塞线程数稳定，则输出阻塞线程信息及线程间同步方法，从而定位到代码级别，可诊断为线程间出现了过度同步的问题。

针对堆内存使用率曲线随着并发数的增加出现增长或无规则波动，造成性能黄金曲线不达标的情况，主要存在两方面疑似性能瓶颈点，一个是JVM参数设置，与基准黄金指标下参数配置对比，是否存在参数设置不合理；另一个属于代码级别，匹配堆使用率增长曲线与并发数、黄金指标曲线之间的关联关系和相似度，如相似度超过阈值范围，判定业务逻辑造成内存使用率超限，展示TOP 5实例和线程，结合业务场景逻辑分析，从业务层面来优化；如相似度低于阈值范围，辅助GC频率、堆内存增长趋势，判定可能存在内存泄露问题，可结合堆dump日志定位具体的代码段。

针对磁盘性能瓶颈问题，在并发压测之前，一键环境检查阶段，可以匹配性能黄金指标要求和磁盘硬件性能、容量是否满足，从而判断硬件是否达到性能瓶颈。查看磁盘监控指标IOPS/吞吐量/响应时间等，在未达到磁盘硬件性能瓶颈的情况下，通过pidstat获取监控指标，判定是应用进程读写磁盘还是***进程读写磁盘，常见应用进程读写磁盘与应用日志有关，***进程读写磁盘与磁盘基准参数配置有关。

进一步地，所述将所述目标应用在所述服务器端的应用数据与所述服务器端测试规则进行对比，确定所述目标应用是否在所述服务器端存在性能异常的步骤包括：

步骤S2221，获取所述目标应用在链路端的应用数据；

步骤S2222，将所述目标应用在所述链路端的应用数据与所述链路端测试规则进行对比，确定所述目标应用是否在所述链路端存在性能异常；

步骤S2223，将所述目标应用在所述服务器端的应用数据与所述服务器端测试规则进行对比，确定所述目标应用是否在所述服务器端存在性能异常。

可以理解地，在完成压力端的性能测试后，还需要先对链路端进行性能测试才能进行服务器端的性能测试，因此***还需要获取服务器端上传的目标应用在链路端的应用数据，目标应用在链路端的应用数据可以包含网络数据、丢包数据、响应时间、网络带宽等，同时获取预设测试规则中用于进行链路端性能测试的链路端测试规则，将目标应用在链路端的应用数据与链路端测试规则进行对比，具体地，由于链路端测试规则一方面在于网络抖动、丢包、响应超时引起黄金曲线无规则波动，网络带宽对吞吐量的限制；另一方面在于定位业务关键路径各个节点的处理极限，即分析关键路径上节点的性能短板。因此，针对网络延时出现异常波动，如压测期间，微服务之间出现调用时间超过阈值区间，可通过网络基础资源分析，基于微服务之间调用时间曲线的趋势，对比排除网络故障问题；对于网络抖动的状况，一般伴随着响应时间大幅度波动或丢包现象，出现交易异常；网络带宽占用率可以用来判断是否达到了最大硬件带宽限度。而针对业务关键路上各节点的监控指标，对比各节点耗时占比情况，结合各节点资源消耗情况是否达到了性能瓶颈点，重点分析两类节点：一类是节点业务处理逻辑简单但耗时占比较高；一类是节点资源消耗相对低。基于上述链路端测试规则与目标应用在链路端的应用数据的对比，确定目标应用是否在链路端存在性能异常，若目标应用在链路端的应用数据满足链路端测试规则，则确定不存在性能异常，若目标应用在链路端的应用数据不满足链路端测试规则，则确定存在性能异常。便于在测试到目标应用在链路端存在性能异常时进行性能问题定位并生成对应的解决方案。

在链路端测试完成后，***将目标应用在服务器端的应用数据与服务器端测试规则进行对比，具体地，将服务器资源[CPU,Memory,I/O,Network]使用情况曲线及异常指标曲线等应用数据与服务器端测试规则进行对比，确定目标应用是否在服务器端存在性能异常，若目标应用在服务器端的应用数据满足服务器端测试规则，则确定不存在性能异常，若目标应用在服务器端的应用数据不满足服务器端测试规则，则确定存在性能异常。以在测试到目标应用在服务器端存在性能异常时进行性能问题定位并生成对应的解决方案。

本实施例通过预设测试规则与目标应用在各端的应用数据，分别确定目标应用是否在压力端、服务器端、应用端存在性能异常，实现在压力的传递路径上，分别从环境配置、压力端、链路端、应用端逐层分析，从服务器级、虚拟机级、应用级、线程级、代码级逐级下钻，定位最终的性能问题和瓶颈点，可以快速确定目标应用在各端是否存在性能异常。

进一步地，参照图5，基于本申请应用性能测试方法的第一实施例，提出本申请应用性能测试方法的第三实施例，在第三实施例中，所述若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案的步骤包括：

步骤S31，若存在性能异常，则对存在性能异常的目标端进行问题定位，得到目标端的性能问题；

步骤S32，根据所述性能问题生成目标应用在所述目标端的应用性能优化方案。

在分别确定目标应用是否在压力端、服务器端、应用端存在性能异常后，若发现目标应用是否在压力端、服务器端、应用端中的一端或多端存在性能异常，则将压力端、服务器端、应用端中存在性能异常的一端或多端确定为目标端，其中服务器端还可以包含基于其上传的数据进行测试的链路端。进一步地，***针对目标端的性能异常进行问题定位，具体地，***调用智能诊断层将目标端的性能异常情况与各端的性能问题进行匹配，由此确定与该性能异常情况对应的性能问题，作为导致目标端发生性能异常的性能问题。进一步地，***将确定的性能问题与预设数据库中的预设性能问题进行问题匹配，先将预设数据库中与性能问题匹配的预设性能问题确定目标性能问题，再从预设数据库中获取目标性能问题对应的应用性能优化方案作为目标应用在目标端的应用性能优化方案。

进一步地，所述根据所述性能问题生成目标应用在所述目标端的应用性能优化方案的步骤包括：

步骤S321，将所述性能问题与预设数据库中的预设性能问题进行问题匹配；

步骤S322，将所述预设数据库中与所述性能问题匹配的预设性能问题确定目标性能问题；

步骤S323，从所述预设数据库中获取所述目标性能问题对应的应用性能优化方案作为所述目标应用在所述目标端的应用性能优化方案。

在确定出目标端的性能问题后，***确定的性能问题输入至预设数据库中，根据输入的性能问题在预设数据库中进行问题匹配，查找是否存在与该性能问题对应的应用性能优化方案。可以理解地，预设数据库中预先设置有各种性能问题以及与各种性能问题一一对应的应用性能优化方案。因此，***可以先将性能问题作为检索关键字在预设数据库的各预设性能问题中查找是否存在该性能问题匹配的预设性能问题，若存在则将该预设性能问题确定为目标性能问题，并直接查找与目标性能问题对应的应用性能优化方案，将与目标性能问题对应的应用性能优化方案确定为目标应用在目标端的应用性能优化方案。可以理解地，若目标端为一端，例如为应用端，则获取目标应用在应用端的应用性能优化方案；而若目标端为多端，例如服务器端与应用端，则分别获取目标应用在服务器端以及应用端的应用性能优化方案。

可以理解地，本实施例中性能异常包括压力端异常、网络链路异常(即链路端异常)、应用服务器级资源异常以及应用级资源异常。其中，常见的压力端异常分成压力端资源消耗异常，压力端性能黄金指标曲线异常(存在各种波动现象)。针对压力端资源消耗异常，一方面确定压力是否符合业务场景需求，资源消耗异常是因正常并发增大引起还是因脚本、数据、配置等方面因素引起，压力机的资源配置是否需要扩展，能否扩展分布式压力机来缓解资源瓶颈；另一方面，针对脚本、数据、配置等方面的问题，可以对比正常情况下基准测试的指标曲线，从解决确定脚本、数据、配置的问题。如脚本自身的性能问题，数据分布不合理，并发数和并发数增长引起的曲线波动和异常。

网络链路异常一般来说，主要从网络延迟、网络抖动/丢包、网络带宽等硬件层面和服务器TCP/HTTP协议参数配置等软件层面来解决。网络延迟、网络抖动/丢包等常见的网络可以通过ping、trace route等命令跟踪网络基准情况，也可以通过路由器、交换机等网络节点抓包分析来定位硬件层面是否存在网络异常。对于网络带宽这类硬件需求，可以通过提前预估计算，分析业务场景的峰值网络带宽需求，对比路由器标称的贷款大小来定位是否硬件层面出现瓶颈。针对网络协议参数配置的问题，一方面可以通过提前环境检查，列出参数指标与基准参数配置之间的差异来分析；另一方面，可以辅助后续应用服务器的连接数、压力端并发数等线程数以及线程状态的变化来定位分析。一般的解决方案是通过调整参数配置，对比测试来确定最优的参数。

应用服务器级别资源若存在性能瓶颈，可以从硬件和软件两个层面来解决。硬件层面，可通过扩展单机服务器CPU/MEMORY/磁盘等，或从架构层面扩展多个应用服务器来解决。针对软件层面的性能瓶颈，大多在于服务器的参数配置问题，类似于压力机端服务器资源瓶颈，主要是网络协议相关参数，文件句柄参数等，通过逐一调整参数，对比测试获取最优参数配置。

应用级别的性能瓶颈是性能瓶颈分析诊断过程中较为常见的场景，这里着重分析程序设计方面的问题，常见的应用瓶颈及其解决方案有：架构设计不合理，通过压测过程中，CPU热点方法、线程状态、类和方法的调用链路，分析出业务全流程关键路径，绘制业务调用关系拓扑图，确定路径设计合理性，给出架构设计或业务逻辑调整解决方案。程序代码设计存在线程锁，可分析线程数量、线程状态及其变化趋势，确定线程之间的同步和关联关系，调整线程之间的耦合性。内存泄露，可结合TOP堆内存占用实例、TOP堆内存占用类和方法，gc频率及耗时，定位到具体的代码段。可通过手动回收资源或调整代码逻辑***自动资源回收来解决。内存溢出，可结合热点CPU方法、堆dump日志、TOP堆内存占用类和方法，定位异常代码段及异常原因，分析堆栈大小与使用情况，可通过调整JVM参数设置或代码调用方式减少栈层级来解决。线程安全，随着并发压力的增加，结合应用日志，分析业务交易错误场景，查看线程状态及CPU消耗热点类和方法，确定线程间交互的代码逻辑段，改写非线程安全的共享数据区。参数设计不合理，常用参数主要与服务器资源相关，或******连接相关，如网络连接数、数据库连接数、******连接或工作线程数等，一般解决方案是逐一调整参数设置，对比不同参数条件下性能表现，结合基准性能参数配置，确定合理的参数配置项。日志问题，常见日志问题主要是日志级别、日志频率、日志规范等问题，与***参数配置相关，调整日志参数，结合日志规范性要求(如循环日志文件，日志归档，与业务逻辑无关日志不开启等)，对比测试不同条件下性能表现，确定合理的日志配置项。死循环，较为常见的表现是应用CPU消耗随着并发数持续增长，交易业务性能无明显表现，可通过CPU热点方法、TOP堆内存使用类和方法等定位异常代码段，改写或调整代码逻辑来解决。负载不均衡，可以通过监控各服务器资源消耗，结合应用热点CPU方法，确定是服务器级别的负载不均衡，还是应用实现级别的负载不均衡。针对服务器级别的负载不均衡，主要是分析路由算法和路由分发机制，从路由层入手解决；针对应用级别的负载不均衡，分析热点线程，确定造成不均衡的线程根源问题，可通过调整线程池或线程之间逻辑关系来解决。

例如，若通过监控目标应用的CPU消耗、线程状态、线程数量等应用数据，判定出目标应用的某个代码段出现了死锁问题，可直接定位死锁的代码段，生成并推送死锁的改进策略。

本实施例若存在性能异常，则对存在性能异常的目标端进行问题定位，得到目标端的性能问题，并根据性能问题生成目标应用在目标端的应用性能优化方案。可以在确定存在性能异常后快速、准确地进行问题定位，并根据定位得到的性能问题生成应用性能优化方案以推送给性能测试人员和开发人员参考，以便于性能测试人员和开发人员对该应用进行优化，提升目标应用上线和运维的效率和质量。

此外，本申请还提供一种介质，所述介质优选为计算机可读存储介质，其上存储有应用性能测试程序，所述应用性能测试程序被处理器执行时实现上述应用性能测试方法各实施例的步骤。

此外，本申请还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述应用性能测试方法各实施例的步骤。

在本申请应用性能测试设备、计算机可读存储介质和计算机程序产品的实施例中，包含了上述应用性能测试方法各实施例的全部技术特征，说明和解释内容与上述应用性能测试方法各实施例基本相同，在此不做赘述。

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

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是固定终端，如物联网智能设备，包括智能空调、智能电灯、智能电源、智能路由器等智能家居；也可以是移动终端，包括智能手机、可穿戴的联网AR/VR装置、智能音箱、自动驾驶汽车等诸多联网设备)执行本申请各个实施例所述的方法。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims

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

2.如权利要求1所述的应用性能测试方法，其特征在于，所述基于各所述应用数据，分别确定所述目标应用是否在所述压力端、所述服务器端、所述应用端存在性能异常的步骤包括：

获取预设测试规则；

3.如权利要求2所述的应用性能测试方法，其特征在于，所述预设测试规则包含压力端测试规则、服务器端测试规则与应用端测试规则；

4.如权利要求3所述的应用性能测试方法，其特征在于，所述预设测试规则还包含链路端测试规则，所述将所述目标应用在所述服务器端的应用数据与所述服务器端测试规则进行对比，确定所述目标应用是否在所述服务器端存在性能异常的步骤包括：

获取所述目标应用在链路端的应用数据；

5.如权利要求1所述的应用性能测试方法，其特征在于，所述若存在性能异常，则根据存在性能异常的目标端的性能问题，生成所述目标应用在所述目标端的应用性能优化方案的步骤包括：

6.如权利要求5所述的应用性能测试方法，其特征在于，所述根据所述性能问题生成目标应用在所述目标端的应用性能优化方案的步骤包括：

7.如权利要求1-6任一项所述的应用性能测试方法，其特征在于，所述分别获取目标应用在压力端、服务器端、应用端的应用数据的步骤包括：

基于预设压力测试工具获取目标应用在压力端的应用数据；

8.一种应用性能测试设备，其特征在于，所述应用性能测试设备包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的应用性能测试程序，所述应用性能测试程序被所述处理器执行时实现如权利要求1-7中任一项所述的应用性能测试方法的步骤。

9.一种介质，所述介质为计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有应用性能测试程序，所述应用性能测试程序被处理器执行时实现如权利要求1-7中任一项所述的应用性能测试方法的步骤。

10.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1-7中任一项所述的应用性能测试方法的步骤。