CN113360368B - 一种软件性能测试的方法和装置 - Google Patents

Abstract

本发明公开了一种软件性能测试的方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：对待测试版本的主干代码进行扫描；若主干代码中存在影响性能因素，则为待测试版本部署测试环境，并生成性能测试场景；在测试环境中执行性能测试场景，并按测试策略调整初始场景参数，得到待测试版本的测试结果。该实施方式降低了能够不再对所有的待测试版本进行性能测试，减少软件开发过程中执行性能测试的次数，降低软件开发成本；以及能够自动完成性能测试，提高测试效率，减小软件质量风险。

Description

一种软件性能测试的方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种软件性能测试的方法和装置。

背景技术

随着互联网的快速发展，各类软件的版本更新非常频繁，在软件开发生命周期中，多采用敏捷的方式来应对。

性能测试在软件生命周期开发中成本占很大比重，整个性能测试过程纯人工操作，过程繁杂且需要大量人力和物力，在这种情况下，如果频繁执行性能测试，将会导致软件开发成本增高；且易出现测试进度跟不上版本变更速度的情况，导致某些版本无法进行性能测试，即测试用例无法执行，潜在的软件质量风险较大，无法保证服务质量。

发明内容

有鉴于此，本发明实施例提供一种软件性能测试的方法和装置，能够不再对所有的待测试版本进行性能测试，减少软件开发过程中执行性能测试的次数，降低软件开发成本；以及能够自动完成性能测试，提高测试效率，减小软件质量风险。

为实现上述目的，根据本发明实施例的一个方面，提供了一种软件性能测试的方法。

本发明实施例的一种软件性能测试的方法包括：

对待测试版本的主干代码进行扫描；

若所述主干代码中存在影响性能因素，则为所述待测试版本部署测试环境，并生成性能测试场景；

在所述测试环境中执行所述性能测试场景，并按测试策略调整所述性能测试场景的初始场景参数，得到所述待测试版本的测试结果。

可选地，所述影响性能因素是架构变动、性能脚本变动或参数配置变动；以及

若所述主干代码中存在影响性能因素，则为所述待测试版本部署测试环境，并生成性能测试场景，包括：

若所述主干代码中存在所述架构变动、所述性能脚本变动或所述参数配置变动，则对所述主干代码进行测试环境部署，并加载铺底数据；

为所述待测试版本生成至少一个性能测试场景。

可选地，为所述待测试版本生成至少一个性能测试场景，包括：

将各个性能测试脚本添加到执行任务队列；

利用执行引擎按照先进先出策略从所述执行任务队列中调用所述性能测试脚本，并将同一次调用的所述性能测试脚本组合成一个性能测试场景；

将所述性能测试场景发送到至少一个测试服务器。

可选地，在所述测试环境中执行所述性能测试场景，并按测试策略调整所述性能测试场景的初始场景参数，得到所述待测试版本的测试结果，包括：

设置每个所述性能测试场景的初始场景参数；其中，所述初始场景参数包括所述性能测试脚本的执行时间、初始并发数、初始思考时间和初始迭代间隔；

在所述测试环境中执行所述性能测试场景，并按测试策略调整所述初始并发数、所述初始思考时间和所述初始迭代间隔；

收集执行结果，得到所述待测试版本的测试结果。

可选地，按测试策略调整所述初始并发数、所述初始思考时间和所述初始迭代间隔，包括：

对每个所述性能测试场景进行基准测试，得到基准吞吐量和基准CPU使用率；

根据所述基准CPU使用率和CPU阈值调整所述初始并发数；

根据所述基准吞吐量和预期吞吐值调整所述初始思考时间或所述初始并发数；以及

按照压力发起频率调整所述初始迭代间隔。

可选地，所述方法还包括：

根据所述测试结果计算所述待测试版本的性能测试指标；其中，所述性能测试指标包括事务响应时间、吞吐量、事务成功率、事务失败率、以及服务器的资源使用情况；

基于所述事务响应时间、所述吞吐量、所述事务成功率、所述事务失败率、以及所述服务器的资源使用情况分析所述待测试版本的性能趋势和预估缺陷。

为实现上述目的，根据本发明实施例的另一方面，提供了一种软件性能测试的装置。

本发明实施例的一种软件性能测试的装置包括：

扫描模块，用于对待测试版本的主干代码进行扫描；

生成模块，用于在所述主干代码中存在影响性能因素，则为所述待测试版本部署测试环境，并生成性能测试场景；

调整模块，用于在所述测试环境中执行所述性能测试场景，并按测试策略调整所述性能测试场景的初始场景参数，得到所述待测试版本的测试结果。

可选地，所述影响性能因素是架构变动、性能脚本变动或参数配置变动；以及

所述生成模块还用于：

若所述主干代码中存在所述架构变动、所述性能脚本变动或所述参数配置变动，则对所述主干代码进行测试环境部署，并加载铺底数据；

为所述待测试版本生成至少一个性能测试场景。

可选地，所述生成模块进一步用于：

将各个性能测试脚本添加到执行任务队列；

利用执行引擎按照先进先出策略从所述执行任务队列中调用所述性能测试脚本，并将同一次调用的所述性能测试脚本组合成一个性能测试场景；

将所述性能测试场景发送到至少一个测试服务器。

可选地，所述调整模块还用于：

设置每个所述性能测试场景的初始场景参数；其中，所述初始场景参数包括所述性能测试脚本的执行时间、初始并发数、初始思考时间和初始迭代间隔；

在所述测试环境中执行所述性能测试场景，并按测试策略调整所述初始并发数、所述初始思考时间和所述初始迭代间隔；

收集执行结果，得到所述待测试版本的测试结果。

可选地，所述调整模块进一步用于：

对每个所述性能测试场景进行基准测试，得到基准吞吐量和基准CPU使用率；

根据所述基准CPU使用率和CPU阈值调整所述初始并发数；

根据所述基准吞吐量和预期吞吐值调整所述初始思考时间或所述初始并发数；以及

按照压力发起频率调整所述初始迭代间隔。

可选地，所述装置还包括分析模块，用于：

根据所述测试结果计算所述待测试版本的性能测试指标；其中，所述性能测试指标包括事务响应时间、吞吐量、事务成功率、事务失败率、以及服务器的资源使用情况；

基于所述事务响应时间、所述吞吐量、所述事务成功率、所述事务失败率、以及所述服务器的资源使用情况分析所述待测试版本的性能趋势和预估缺陷。

为实现上述目的，根据本发明实施例的又一方面，提供了一种软件性能测试的电子设备。

本发明实施例的一种软件性能测试的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例的一种软件性能测试的方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读存储介质。

本发明实施例的一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例的一种软件性能测试的方法。

上述发明中的一个实施例具有如下优点或有益效果：因为采用对待测试版本的主干代码进行扫描；若主干代码中存在影响性能因素，则为待测试版本部署测试环境，并生成性能测试场景；在测试环境中执行性能测试场景，并按测试策略调整初始场景参数，得到待测试版本的测试结果的技术手段，所以克服了频繁执行性能测试导致软件开发成本较高，且存在测试进度跟不上版本变更速度的情况，导致某些版本无法进行性能测试，潜在的软件质量风险较大的技术问题，进而达到不再对所有的待测试版本进行性能测试，减少软件开发过程中执行性能测试的次数，降低软件开发成本；能够自动完成性能测试，提高测试效率，减小软件质量风险的技术效果。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的软件性能测试的方法的主要步骤的示意图；

图2是根据本发明一个可参考实施例的软件性能测试的方法的实施框架的示意图；

图3是一种性能测试结果对比展示的示意图；

图4是一种BUG分布分析的示意图；

图5是根据本发明一个可参考实施例的软件性能测试的方法的主要流程的示意图；

图6是根据本发明实施例的软件性能测试的装置的主要模块的示意图；

图7是本发明实施例可以应用于其中的示例性系统架构图；

图8是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

需要指出的是，在不冲突的情况下，本发明的实施例以及实施例中的技术特征可以相互结合。

性能测试是通过自动化的测试工具模拟各种正常、峰值以及异常负载条件来对系统的各项性能指标的测试。通常，软件的性能测试包括：

1)性能测试准备：测试环境准备，脚本准备；

2)测试执行：基准测试、负载测试、容量测试和异常场景测试；

3)测试结果分析报告。

本发明实施例的软件性能测试的方法将日常手动性能测试流程方法，根据数据知识原理及操作系统原理，来实现压测的自动化，具体地，首先，在性能测试版本的选择时，代码变更扫描组件会对下载的主干版本进行代码扫描；其次，压力测试引擎能够根据基准测试结果和服务器资源值与指标进行动态增加或者减少压力，达到完全自动化测试能力；最后，根据测试结果判断系统性能拐点，并预测性能瓶颈和解决方案。

图1是根据本发明实施例的软件性能测试的方法的主要步骤的示意图。

如图1所示，本发明实施例的软件性能测试的方法主要包括以下步骤：

步骤S101：对待测试版本的主干代码进行扫描。

由于频繁执行性能测试会导致软件开发成本增高，为控制执行性能测试的次数，可以先对待测试版本的主干代码进行扫描，从而确定该待测试版本是否需要性能测试。性能测试可以在持续集成框架(Jenkins)内实施，同样，待测试版本的主干代码可以通过Jenkins内添加的各种工具获取到。Jenkins是一个广泛用于持续构建的可视化web工具，可以很好的支持各种语言的项目构建，也完全兼容多种第三方构建工具，同时跟svn(一种开放源代码的版本控制系统)、git(一种开源的分布式版本控制系统)能无缝集成，也支持直接与知名源代码托管网站直接集成。Jenkins主要用于，持续、自动地构建/测试软件项目，以及监控一些定时执行的任务。

步骤S102：若主干代码中存在影响性能因素，则为待测试版本部署测试环境，并生成性能测试场景。

为控制执行性能测试的次数，本发明实施例的软件性能测试的方法仅对有性能影响的改动做性能测试，具体地，对于待测试版本的主干代码，如果中存在影响性能因素，则需要做性能测试，否则不需要。做性能测试，需要部署测试环境，例如部署虚拟机、服务器、数据库和运行环境等等，同时要生成性能测试场景，每个性能测试场景对应一种测试，例如基准测试、配置测试、负载测试和稳定性测试等。

在本发明实施例中，步骤S102可以采用以下方式实现：若主干代码中存在架构变动、性能脚本变动或参数配置变动，则对主干代码进行测试环境部署，并加载铺底数据；为待测试版本生成至少一个性能测试场景。

对于主干代码中是否存在影响性能因素，可以根据预先定制的代码规则、代码评审(Review)或代码检查工具确定。其中，Review是软件每次上线前进行的代码评审工作，通过代码评审来确认是否存在影响性能因素；代码检查工具可以是FindBugs等，FindBugs是一个开源的静态代码分析工具，基于LGPL开源协议，无需运行就能对代码进行分析的工具，FindBugs自带多种检测器。影响性能因素可以是架构变动、性能脚本变动或参数配置变动。其中，架构变动可以是连接池变动、存储发生变动(例如cache变成redis)、或主要业务流程发生变动等；主要性能脚本变动可以是容器变动(例如arrayList变动linkedList)、数据结构算法变动、或循环等。

铺底数据又称存量数据，是为了模拟待测试版本已经达到的业务量而提前预埋在测试环境中的数据。一般情况下，对于已经上线的软件，铺底数据可由生产数据经过脱敏等安全预处理得到；对于新建软件，铺底数据根据业务人员估计的数量需求通过工具或脚本生成，对于有获取多年后性能指标任务的项目，多年后的铺底数据应通过SQL插入或通过工具模拟产生。

此外，每个性能测试场景在执行后能够得到一组数据，要判断待测试版本的性能拐点或者性能容量最大值等，往往需要多组数据。作为一种优选的实施方式，可以为一个待测试版本生成多个性能测试场景。

在本发明实施例中，为待测试版本生成至少一个性能测试场景的步骤可以采用以下方式实现：将各个性能测试脚本添加到执行任务队列；利用执行引擎按照先进先出策略从执行任务队列中调用性能测试脚本，并将同一次调用的性能测试脚本组合成一个性能测试场景；将性能测试场景发送到至少一个测试服务器。

执行任务队列用于临时存放性能测试脚本，每个性能测试脚本可以是一个事务及其预期结果，事务是一组密切相关的操作组合。例如用户登录测试脚本，预期结果：能够显示最近几次、截止某一日期用户登录情况，以及能够显示当前系统最近重启的情况。可以采用redis中的sort set技术创建脚本执行任务的排队机制，每个性能测试脚本设计一个set队列的key。执行任务队列中的性能测试脚本可以利用执行引擎采取先进先出策略(FIFO)进行调用，所有调用的key组合在一起就形成一个混合的性能测试场景。每个key的执行时间先后顺序可以相同，也可以不同。场景执行完后，从set队列中移除脚本信息，并更新redis中的数据。执行引擎可以是Apache JMeter，Apache JMeter是一款纯java编写负载功能测试和性能测试开源工具软件，用于对软件做压力测试。先入先出队列(First InputFirst Output，FIFO)这是一种传统的按序执行方法，先进入的指令先完成并引退，跟着才执行第二条指令。

步骤S103：在测试环境中执行性能测试场景，并按测试策略调整性能测试场景的初始场景参数，得到待测试版本的测试结果。

在经过步骤S102的准备后，可以开始性能测试，即在测试环境中执行性能测试场景，且在执行性能测试场景的过程中，按测试策略调整初始场景参数，从而实现动态加压。所得到的测试结果能够反映待测试版本的情况。

在本发明实施例中，步骤S103可以采用以下方式实现：设置每个性能测试场景的初始场景参数；在测试环境中执行性能测试场景，并按测试策略调整初始并发数、初始思考时间和初始迭代间隔；收集执行结果，得到待测试版本的测试结果。

初始场景参数包括性能测试脚本的执行时间、初始并发数、初始思考时间和初始迭代间隔。其中，性能测试脚本的执行时间包括执行开始时间和执行结束时间；初始并发数是控制流量最主要参数，包括并发用户数、在线用户数或系统用户数等；初始思考时间是每个操作后的暂停时间，或者叫操作之间的间隔时间；初始迭代间隔是脚本循环迭代间的间隔时间。

在本发明实施例中，按测试策略调整初始并发数、初始思考时间和初始迭代间隔的步骤可以采用以下方式实现：对每个性能测试场景进行基准测试，得到基准吞吐量和基准CPU使用率；根据基准CPU使用率和CPU阈值调整初始并发数；根据基准吞吐量和预期吞吐值调整初始思考时间或初始并发数；以及按照压力发起频率调整初始迭代间隔。

基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。初始并发数是控制流量最主要参数，可以根据基准CPU使用率和CPU阈值、以及基准吞吐量和预期吞吐值调整初始并发数，具体地，可以根据CPU阈值与CPU使用率的比值调整初始并发数，CPU阈值可以根据操作系统性能来确定，例如CPU阈值为60％，1用户时，基准CPU使用率为10％，则调整初始并发用数为Y＝60％/10％，或者，可以比较基准吞吐量和预期吞吐值来调整初始并发数，如果基准吞吐量大于预期吞吐值则减少初始并发数、如果基准吞吐量小于预期吞吐值则增加并发数。初始思考时间起到微调吞吐量的作用，如果基准吞吐量大于预期吞吐值则可以减少初始思考时间(即增加了待测试版本的吞吐量)、如果基准吞吐量小于预期吞吐值则可以增加初始思考时间(即减少了待测试版本的吞吐量)。其中，预期吞吐值可以根据实际情况设置，也可以利用某些测试模型估算得到。

对测试结果进行分析能够进一步得到待测试版本的平均响应时间、服务器资源占用情况、可靠性、可扩展性、发现引起系统问题的原因、关注采用何种技术提高系统性能、以及软硬件配置是否合适(容量规划、硬件选型)等。

在本发明实施例中，步骤S103之后还可以根据测试结果计算性能测试指标；基于事务响应时间、吞吐量、事务成功率、事务失败率、以及服务器的资源使用情况分析待测试版本的性能趋势和预估缺陷。

性能测试指标包括事务响应时间、吞吐量、事务成功率、事务失败率、以及服务器的资源使用情况。其中，事务响应时间是指从发送一个请求到接收到服务器返回的响应数据这段时间就是响应时间；吞吐量是指单位时间内系统处理的客户端请求的数量；事务成功率是指单位时间内系统可以成功完成多少个定义的事务，事务成功率在一定程度上反应了系统的处理能力；事务失败率主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。服务器的资源使用情况主要包括CPU使用率、内存使用率、I/O使用率、网络流入/流出量或磁盘使用率等，CPU使用率指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85％；内存使用率＝(1-空闲内存/总内存大小)*100％，一般至少有10％可用内存，内存使用率可接受上限为85％；I/O使用率即磁盘I/O:磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用％Disk Time(磁盘用于读写操作所占用的时间百分比)度量磁盘读写性能；网络流入/流出量：一般使用计数器BytesTotal/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内，网络流入/流出量用于判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。

上述性能测试指标的计算可以参考现有的技术方案实现，本发明实施例不予赘述，通过性能测试指标可以对待测试版本的性能趋势和预估缺陷进行分析，其中，性能趋势的分析可以采用图文的形式直接地展现，且在分析性能趋势时，如果性能下降可以发出预警；预估缺陷(BUG)的分析包括可能出现的BUG及其归属类型、出现原因和解决方案，以及对所有BUG进行统计等。

根据本发明实施例的软件性能测试的方法可以看出，因为采用对待测试版本的主干代码进行扫描；若主干代码中存在影响性能因素，则为待测试版本部署测试环境，并生成性能测试场景；在测试环境中执行性能测试场景，并按测试策略调整初始场景参数，得到待测试版本的测试结果的技术手段，所以克服了频繁执行性能测试导致软件开发成本较高，且存在测试进度跟不上版本变更速度的情况，导致某些版本无法进行性能测试，潜在的软件质量风险较大的技术问题，进而达到不再对所有的待测试版本进行性能测试，减少软件开发过程中执行性能测试的次数，降低软件开发成本；能够自动完成性能测试，提高测试效率，减小软件质量风险的技术效果。

为了进一步阐述本发明的技术思想，现结合具体的应用场景，对本发明的技术方案进行说明。

在应用本发明实施例的软件性能测试的方法时，可参照如图2所示的框架实施，具体地：

第一部分：持续集成服务，由三部分组成：

1.编译构建服务：

本部分是性能测试环境常态化的基础，包括性能测试版本的选择、下载主干代码、编译、打包和部署。

2.代码变更扫描组件：

本专利编译构建服务部分重点在性能测试版本的选择。代码变更扫描组件会根据下载的主干版本进行代码扫描。扫描出来符合性能测试标准的版本进行自动化部署。选择时有如下几个步骤及条件：

第一步：选择主干版本；

第二步：代码变更扫描组件扫描主干代码，如果代码中有影响性能因素，就需要回归测试。影响因素可以通过代码review发现、通过工具平台发现、或基于平台的定制规则发现，影响因素为：

架构变动：连接池变动、存储发生变动(cache变成redis)、主要业务流程发生变动；

主要性能脚本变动：容器变动(例如arrayList变动linkedList)、数据结构算法变动、循环等；

其他变动：参数配置发生变动等；

3.应用管理部署服务：

对符合性能测试条件的版本进行环境部署。

第二部分：压力测试引擎，主要包括两部分：

1.执行性能测试

可以采用redis中的sort set技术创建执行任务队列，每个性能测试脚本设计一个set队列的key，采取FIFO先进先出策略，实现脚本执行任务的排队机制。所有的key组合在一起就形成一个混合性能测试场景。每个key的执行时间先后顺序可以相同，也可以不同。场景执行完后，从set队列中移除脚本信息，并更新redis中信息；

性能测试脚本：在性能测试时Jmeter调用执行任务队列中的性能测试脚本，并将每次调用的所有性能测试脚本组合成一个性能测试场景。如果跨多个压力机且采用分布式服务，将性能测试场景发送到各个服务器中，所有压力机由一台中央控制机统一监控执行；

性能测试数据：正常回归测试的测试数据基本保持不变，性能测试数据包括铺底数据和参数化数据两大类，其中，

铺底数据又称存量数据，是为了模拟待测试版本已经达到的业务量而提前预埋在测试环境中的数据。一般情况下，对于已经上线的软件，铺底数据可由生产数据经过脱敏等安全预处理得到；对于新建软件，铺底数据根据业务人员估计的数量需求通过工具或脚本生成，对于有获取多年后性能指标任务的项目，多年后的铺底数据应通过SQL插入或通过工具模拟产生；

参数化数据是指在性能测试执行过程中虚拟用户进行业务操作所需要发送的数据，即性能测试脚本中要用到的参数化数据。参数化数据由性能测试实施人员在性能调研或方案阶段提出具体的需求，由环境人员或开发人员提取为文件后提供给性能测试实施人员使用。为避免参数化数据不正确导致大量非正常事务失败，需要对提交的所有参数化数据进行正确性校验，剔除错误数据，数据量较大时建议编写数据分拣脚本并执行对应场景来完成参数化数据的校验和分拣工作；

性能测试场景：性能测试场景配置，包括执行开始时间和结束时间、发压策略，减压策略，参数选择策略，思考时间设置和迭代间隔设置；

2.收集测试结果

本部分是性能测试的重点，每个性能测试场景在执行后能够得到一组数据，要判断待测试版本的性能拐点或者性能容量最大值等，往往需要多组数据，且每个性能测试场景都需要确定至少3个很重要的场景参数，即初始并发数、初始思考时间和初始迭代间隔，具体地：

在执行性能测试的过程中，按照发压策略、减压策略和参数选择策略动态加压，即对每个性能测试场景进行基准测试，得到基准吞吐量和基准CPU使用率；根据基准CPU使用率和CPU阈值调整初始并发数；根据基准吞吐量和预期吞吐值调整初始思考时间或初始并发数；以及按照压力发起频率调整初始迭代间隔；最后收集执行结果，得到待测试版本的测试结果；其中测试结果包括测试结果数据(例如事务响应时间、吞吐量、事务成功率、事务失败率等)和服务器资源指标结果数据(例如CPU使用率、内存使用率、I/O使用率、网络流入/流出量、磁盘使用率等)两类。

第三部分：测试结果展示

1.服务器资源指标定义

包括常见的性能测试指标：事务响应时间、吞吐量、事务成功率、事务失败率，以及服务器各种资源使用情况，CPU使用率，内存使用率，I/O使用率，网络流入/流

出量，磁盘使用率等；

2.性能测试结果对比展示

以图3为例，

第一阶段：如图3中的A阶段，从基准点到性能拐点的上升阶段，当初始并发数增加，吞吐量基本上呈线性增长，即未达到性能拐点的时候，响应时间基本保持不变；此阶段，初始并发数与吞吐量可以用一次函数Y＝KX(Y表示吞吐量，K表示函数系数并且K>1，X表示初始并发数)，如果K<0，表示显下降趋势，性能衰减；

第二阶段：如图3中的B阶段，通过两个指标数据值曲线叠加，从“性能拐点”到“交汇处”。随着初始并发数不断地增加，性能会变得越来越不稳定，响应时间的跳动也会越来越大，响应时间也会变得越来越大，相应地，吞吐量上不去或者下降，CPU的使用率情况也和吞吐量情况基本一致；

3.性能BUG类型预判及解决方案建议，主要包括三个部分：

a)根据性能瓶颈提出可能出现的BUG，并判断BUG归属类型；

b)根据症状判断原因，并给出相应的解决方案；

c)测试完成后，BUG分布分析(可以参考图4所示的示例)。

此外，在完成一个待测试版本的性能测试后，可以根据应用和接口方法，分类统计每次各项性能指标图表，如果性能下降，则发出预警。

如图5所示，本发明实施例的软件性能测试的方法可参考如下流程实施：

1.扫描主干代码：

可以采取定时任务的形式自动扫描软件的版本更新，并扫描更新版本(即待测试版本)的主干代码；

2.判断是否需要性能测试：

可以通过一系列规则判断主干代码中存在影响性能因素，如果存在则需要做性能测试；

3.自动化部署：

可以通过自动部署程序自动发布到测试环境中；

4.负载测试：

生成性能测试场景，并在测试环境中执行性能测试场景，动态加压并记录测试结果；

5.性能评估：

智能分析性能测试结果，比较待测试版本的性能是否优于软件的上一版本；

6.继续梯度加压负载测试；

7.生成报告：

基于测试结果找出系统拐点和性能问题等，并生成性能测试报告。

图6是根据本发明实施例的软件性能测试的装置的主要模块的示意图。

如图6所示，本发明实施例的软件性能测试的装置600包括：扫描模块601、生成模块602和调整模块603。

其中，

扫描模块601，用于对待测试版本的主干代码进行扫描；

生成模块602，用于在所述主干代码中存在影响性能因素，则为所述待测试版本部署测试环境，并生成性能测试场景；

调整模块603，用于在所述测试环境中执行所述性能测试场景，并按测试策略调整所述性能测试场景的初始场景参数，得到所述待测试版本的测试结果。

此外，所述影响性能因素是架构变动、性能脚本变动或参数配置变动。

在本发明实施例中，所述生成模块602还可以用于：

若所述主干代码中存在所述架构变动、所述性能脚本变动或所述参数配置变动，则对所述主干代码进行测试环境部署，并加载铺底数据；

为所述待测试版本生成至少一个性能测试场景。

在本发明实施例中，所述生成模块602可以进一步用于：

将各个性能测试脚本添加到执行任务队列；

利用执行引擎按照先进先出策略从所述执行任务队列中调用所述性能测试脚本，并将同一次调用的所述性能测试脚本组合成一个性能测试场景；

将所述性能测试场景发送到至少一个测试服务器。

在本发明实施例中，所述调整模块603还可以用于：

设置每个所述性能测试场景的初始场景参数；其中，所述初始场景参数包括所述性能测试脚本的执行时间、初始并发数、初始思考时间和初始迭代间隔；

在所述测试环境中执行所述性能测试场景，并按测试策略调整所述初始并发数、所述初始思考时间和所述初始迭代间隔；

收集执行结果，得到所述待测试版本的测试结果。

在本发明实施例中，所述调整模块603可以进一步用于：

对每个所述性能测试场景进行基准测试，得到基准吞吐量和基准CPU使用率；

根据所述基准CPU使用率和CPU阈值调整所述初始并发数；

根据所述基准吞吐量和预期吞吐值调整所述初始思考时间或所述初始并发数；以及

按照压力发起频率调整所述初始迭代间隔。

在本发明实施例中，所述装置600还可以包括分析模块(图中并未示出)，用于：

根据所述测试结果计算所述待测试版本的性能测试指标；其中，所述性能测试指标包括事务响应时间、吞吐量、事务成功率、事务失败率、以及服务器的资源使用情况；

基于所述事务响应时间、所述吞吐量、所述事务成功率、所述事务失败率、以及所述服务器的资源使用情况分析所述待测试版本的性能趋势和预估缺陷。

根据本发明实施例的软件性能测试的装置可以看出，因为采用对待测试版本的主干代码进行扫描；若主干代码中存在影响性能因素，则为待测试版本部署测试环境，并生成性能测试场景；在测试环境中执行性能测试场景，并按测试策略调整初始场景参数，得到待测试版本的测试结果的技术手段，所以克服了频繁执行性能测试导致软件开发成本较高，且存在测试进度跟不上版本变更速度的情况，导致某些版本无法进行性能测试，潜在的软件质量风险较大的技术问题，进而达到不再对所有的待测试版本进行性能测试，减少软件开发过程中执行性能测试的次数，降低软件开发成本；能够自动完成性能测试，提高测试效率，减小软件质量风险的技术效果。

图7示出了可以应用本发明实施例的软件性能测试的方法或软件性能测试的装置的示例性系统架构700。

如图7所示，系统架构700可以包括终端设备701、702、703，网络704和服务器705。网络704用以在终端设备701、702、703和服务器705之间提供通信链路的介质。网络704可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备701、702、703通过网络704与服务器705交互，以接收或发送消息等。终端设备701、702、703上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备701、702、703可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器705可以是提供各种服务的服务器，例如对用户利用终端设备701、702、703所浏览的购物类网站提供支持的后台管理服务器。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息)反馈给终端设备。

需要说明的是，本发明实施例所提供的软件性能测试的方法一般由服务器705执行，相应地，软件性能测试的装置一般设置于服务器705中。

应该理解，图7中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图8，其示出了适于用来实现本发明实施例的终端设备的计算机系统800的结构示意图。图8示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，计算机系统800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM 803中，还存储有系统800操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线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等等，或者上述的任意合适的组合。

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

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括扫描模块、生成模块和调整模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，扫描模块还可以被描述为“对待测试版本的主干代码进行扫描的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：步骤S101：对待测试版本的主干代码进行扫描；步骤S102：若主干代码中存在影响性能因素，则为待测试版本部署测试环境，并生成性能测试场景；步骤S103：在测试环境中执行性能测试场景，并按测试策略调整性能测试场景的初始场景参数，得到待测试版本的测试结果。

根据本发明实施例的技术方案，因为采用对待测试版本的主干代码进行扫描；若主干代码中存在影响性能因素，则为待测试版本部署测试环境，并生成性能测试场景；在测试环境中执行性能测试场景，并按测试策略调整初始场景参数，得到待测试版本的测试结果的技术手段，所以克服了频繁执行性能测试导致软件开发成本较高，且存在测试进度跟不上版本变更速度的情况，导致某些版本无法进行性能测试，潜在的软件质量风险较大的技术问题，进而达到不再对所有的待测试版本进行性能测试，减少软件开发过程中执行性能测试的次数，降低软件开发成本；能够自动完成性能测试，提高测试效率，减小软件质量风险的技术效果。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (9)

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

对待测试版本的主干代码进行扫描；

若所述主干代码中存在影响性能因素，则为所述待测试版本部署测试环境，并生成性能测试场景；

在所述测试环境中执行所述性能测试场景，并按测试策略调整所述性能测试场景的初始场景参数，得到所述待测试版本的测试结果；

所述影响性能因素是架构变动、性能脚本变动或参数配置变动；

若所述主干代码中存在影响性能因素，则为所述待测试版本部署测试环境，并生成性能测试场景，包括：

若所述主干代码中存在所述架构变动、所述性能脚本变动或所述参数配置变动，则对所述主干代码进行测试环境部署，并加载铺底数据；

为所述待测试版本生成至少一个性能测试场景。

2.根据权利要求1所述的方法，其特征在于，为所述待测试版本生成至少一个性能测试场景，包括：

将各个性能测试脚本添加到执行任务队列；

利用执行引擎按照先进先出策略从所述执行任务队列中调用所述性能测试脚本，并将同一次调用的所述性能测试脚本组合成一个性能测试场景；

将所述性能测试场景发送到至少一个测试服务器。

3.根据权利要求1所述的方法，其特征在于，在所述测试环境中执行所述性能测试场景，并按测试策略调整所述性能测试场景的初始场景参数，得到所述待测试版本的测试结果，包括：

设置每个所述性能测试场景的初始场景参数；其中，所述初始场景参数包括所述性能测试脚本的执行时间、初始并发数、初始思考时间和初始迭代间隔；

在所述测试环境中执行所述性能测试场景，并按测试策略调整所述初始并发数、所述初始思考时间和所述初始迭代间隔；

收集执行结果，得到所述待测试版本的测试结果。

4.根据权利要求3所述的方法，其特征在于，按测试策略调整所述初始并发数、所述初始思考时间和所述初始迭代间隔，包括：

对每个所述性能测试场景进行基准测试，得到基准吞吐量和基准CPU使用率；

根据所述基准CPU使用率和CPU阈值调整所述初始并发数；

根据所述基准吞吐量和预期吞吐值调整所述初始思考时间或所述初始并发数；以及

按照压力发起频率调整所述初始迭代间隔。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据所述测试结果计算所述待测试版本的性能测试指标；其中，所述性能测试指标包括事务响应时间、吞吐量、事务成功率、事务失败率、以及服务器的资源使用情况；

基于所述事务响应时间、所述吞吐量、所述事务成功率、所述事务失败率、以及所述服务器的资源使用情况分析所述待测试版本的性能趋势和预估缺陷。

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

扫描模块，用于对待测试版本的主干代码进行扫描；

生成模块，用于在所述主干代码中存在影响性能因素，则为所述待测试版本部署测试环境，并生成性能测试场景；

调整模块，用于在所述测试环境中执行所述性能测试场景，并按测试策略调整所述性能测试场景的初始场景参数，得到所述待测试版本的测试结果；

所述影响性能因素是架构变动、性能脚本变动或参数配置变动；

在所述主干代码中存在影响性能因素，则为所述待测试版本部署测试环境，并生成性能测试场景，包括：

在所述主干代码中存在所述架构变动、所述性能脚本变动或所述参数配置变动，则对所述主干代码进行测试环境部署，并加载铺底数据；

为所述待测试版本生成至少一个性能测试场景。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括分析模块，用于：

根据所述测试结果计算所述待测试版本的性能测试指标；其中，所述性能测试指标包括事务响应时间、吞吐量、事务成功率、事务失败率、以及服务器的资源使用情况；

基于所述事务响应时间、所述吞吐量、所述事务成功率、所述事务失败率、以及所述服务器的资源使用情况分析所述待测试版本的性能趋势和预估缺陷。

8.一种软件性能测试的电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-5中任一所述的方法。

9.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-5中任一所述的方法。