性能测试结果分析（性能测试总结）

本篇文章给大家谈谈性能测试结果分析，以及性能测试总结对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享性能测试结果分析的知识，其中也会对性能测试总结进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、性能测试结果分析：CPU占用率降低表示什么？
• 2、loadrunner关于吞吐量的性能测试结果分析
• 3、如何进行性能测试与分析
• 4、如何写软件测试性能测试用例和结果分析？
• 5、性能测试报告模板
• 6、zmq的pub/sub模式下inproc,ipc,tcp,epgm的通信性能测试结果以及分析(二)

性能测试结果分析：CPU占用率降低表示什么？

cpu占用率降低，表示有进程结束，释放了资源。

譬如，某系统启动数据采集后的cpu 占用率，比关闭数据采集时高。分析原因：
（1）未开启数据采集时，可能一直有采集进程进行扫描；启动数据采集后，采集到数据后可能会触发关闭某些进程，使cpu降低。
（2）推测导致性能缺陷：关闭数据采集的开关（方法）存在问题，导致关闭不彻底，关闭后仍有进程在运行。

验证推测结论的正确性：
（1）关闭数据采集时，监控有哪些进程；
（2）开启数据采集后，监控有哪些进程；
（3）通过对比，找到因自身结束而导致cpu降低的进程。
（4）通知开发进行性能调优

loadrunner关于吞吐量的性能测试结果分析

第一步性能测试结果分析：在整个测试场景的执行过程中性能测试结果分析，测试环境是否正常。如果在测试过程中出现过异常，那么这样得出的结果往往不准确，无须进行分析。
例如，在测试执行过程中，测试机的CPU利用率经常达到100%、测试环境的网络不稳定、一些系统参数配置不正确等等，这样得出的测试结果没有必要进行分析，应该重新设置测试场景或调整测试环境，再次执行测试。
第二步：测试场景的设置是否正确、合理。测试场景的设置是否正确对测试结果有很大的影响。因此，当测试出现异常时，我们要对场景设置进行分析。
一些新手在使用Controller执行测试时，可能会同时在一台PC上加载全部虚拟用户——例如同时加载1000个虚拟用户，如果客户端来不及处理，就 会有很多虚拟用户因不能初始化而失败。失败的根本原因不是被测试的应用服务器不能处理，而是压力根本没有传输过去。正确的做法是增加更多的 Generator或逐步加压，使测试场景运行起来。
第三步：测试结果是否直接暴露出系统的一些问题。对测试场景的整个执行过程，没有必要对压力下系统运行正常的结果进行分析，因为这样的结果不能反映出系统 的性能问题，应该进一步调整场景(比如增大压力)进行测试。在测试过程中使系统表现不正常的测试场景生成的结果则要进行深入分析。实际上，分析能够反映性 能问题的测试结果才是性能分析阶段的主要工作。
测试结果直接暴露系统存在性能问题的情形很多，例如在测试过程中一些用户事务响应时间过长、系统支持的最大并发用户数过低、系统的应用服务器CPU利用率 过高或内存不足等。对这类测试结果，性能测试人员需要借助Analysis对其进行深入分析，以发现一些潜在的性能问题。

如何进行性能测试与分析

“为什么性能测试结果分析我上线系统的性能和性能测试的结果相差很大呢性能测试结果分析？”这是一些用户会经常碰到的问题。当然产生这个问题的原因很多性能测试结果分析，下面我用一个很典型的例子来说明一下。一个用户登录界面，要求用户输入用户名、密码点击登录，登录系统。程序的处理流程如下：根据输入的用户名、密码生成SQL语句，select roleID from usertable where username='用户名' and password='密码'，把这条语句发给ORACLE数据库，从数据库中查询数据，如果查询的roleID不为空则是合法用户允许登录，否则不允许登录系统。 这是一个非常简单的系统。性能测试人员用LOADRUNNER录制脚本，然后用逐步加压的方式来运行脚本，TPS、ORACLE的命中率、资源占用都很理想。性能测试人员就陷入了一种盲目的乐观情绪中，就认为系统性能没有问题，结果在实际运行中系统性能与性能测试中的性能相差很大，为什么会出现这种情况呢，下面我们来分析一下：首先我们来了解一下ORACLE的运行机制：从客户端发送一条SQL语句到ORACLE服务端，ORACLE要对SQL语句进行解析、执行、返回结果。 并且ORACLE有一个LRU（最近最常使用的语句）机制，把最近最常使用的SQL语句保存到共享内存SGA中的libary cache中，下一次再有这样的请求它就不解析了，直接从共享内存中使用。假如我们使用的SQL语句是select roleID from usertable where username='AAA' and password='123'，在我们加压的时候它就解析一次或很少的几次，其性能测试结果分析他的请求就会从共享内存中取得，并且返回的结果也会保存到BUFFER CACHE中，这样系统的测试结果当然就是很好的。但在实际工作中，用户名和密码是各种各样的，而ORACLE解析的条件又要求非常苛刻，SQL语句有一点不同它就认为是不同的SQL语句就要重新进行解析，而解析非常耗费系统资源，所以在实际运行中系统的性能和性能测试的结果相差很大。通过这个例子我们可以看出我们没有把真正的压力压到点上，也就是进行的不是有效性能测试。　如何进行有效性能测试呢？一定要仔细地分析你要进行测试系统的架构、技术体系，LOADRUNNER只是一个加压工具，它对 ORACLE的监控也非常的不好，不要盲目的相信LOADRUNNER.一定要充分重视测试的调研和设计工作，如果能在测试前拿到系统开发的各种文档是最好的，如果没有也要充分调研业务人员、开发人员、系统运维人员，了解系统的技术架构、业务组成、业务流程、业务频度、数据量等要素，这样才能进行有效性能测试

如何写软件测试性能测试用例和结果分析？

1. 测试目的.... 4
2. 测试地点.... 4
3. 测试环境.... 4
3.1. 服务器、客户端环境.... 4
3.2. 测试工具.... 4
4. 测试规模及限制.... 5
5. 测试过程说明.... 5
5.1. 测试模型.... 5
5.2. 测试案例.... 5
5.3. 测试场景.... 6
6. 测试结果.... 7
6.1. 平均响应时间.... 7
6.2. 差错率统计.... 8
6.3. 主机系统资源消耗.... 10
7. 性能测试总结.... 10
8. 大数据量业务测试数据.... 10
8.1. 测试参数.... 10
8.2. 测试结果.... 11

这是我的性能测试报告的目录，你可以参考一下，具体项目还是根据实际情况及需求编写性能测试用例，主要考虑用户的接受程度，比如：某一段时间的登陆量，最大同时在线用户，最大允许数据响应时间等。

性能测试报告模板

xxx项目 性能测试报告模板

1、概况

1.1测试背景

简要描述与测试项目相关的一些背景资料，如项目上线计划、测试需求等。

1.2测试目的

在大用户量、数据量的超负荷下，获得服务器运行时的相关数据，从而进行分析，查看xx 网站是否符合需求。

1.3测试范围

本次测试主要是对xx 网站系统的性能测试。

1.4测试指标

指标 建议值

CPU占用 服务器CPU占用率70%以内：优秀70%-85%：一般85%以上：差

内存占用 服务器内存占用率70%以内：优秀70%-85%：一般85%以上：差

事务通过率 99.5%以上：优秀98.6%-99.5%：一般98.0%-98.6%：轻微隐患97.5%及以下：严重隐患

TPS 每秒成功完成的事务请求数，反应系统处理能力。业务量越大，TPS值越大

I/O 处理业务过程中磁盘存取数据的利用率，反应磁盘的处理能力，利用率越低，磁盘处理性能越好，一般建议在80%以下

2. 测试工具及环境

2.1测试环境

描述测试环境的物理架构，可以用物理架构图来展示。

2.2基本配置

2.3测试工具

a.压测工具：

b.监控工具：

3、测试内容

3.1单场景基准测试模型

描述测试场景，比如登录、注册等。采用单用户无其他压力情况下，查看平均响应时间

3.2单场景容量测试模型

描述测试场景，比如登录、注册等。人数逐步递增，持续XXX，查看各性能指标，获得最大并发数

3.3混合场景容量测试模型

描述测试场景，可以用图表形式说明。

4、测试结果与分析

4.1单场景基准测试模型

a.测试结果数据

b.测试问题及结果分析

对测试的结果及发现的性能问题进行总结，分析。例如：

相关图表来进行性能分析

描述对测试中限制性指标的因素

对测试指标的结果与目标进行对比

4.2单场景容量测试模型

测试结果数据(给出测试指标结果数据)

测试问题及结果分析

对测试的结果及发现的性能问题进行总结，分析。例如：

合并相关图表来进行性能分析

描述对测试中限制性指标的因素

对测试指标的结果与目标进行对比

4.3混合场景压测模型

a.测试结果数据

给出测试指标结果数据及图表

b.测试问题及结果分析

对测试的结果及发现的性能问题进行总结、分析。例如：

对相关的数据和图表进行分析

描述对测试中限制性指标的因素

对测试指标的结果与预期进行对比

最后:【可能给你带来帮助的教程】

点击免费领取软件测试资料 ，也可以来性能测试结果分析我的学习基地吹吹水交流心得

这一些资料，对做【软件测试】的朋友而言应该是较为完整了，这类学习资料也陪伴我走过了最艰难的路程，希望也可以帮助到你性能测试结果分析！万事要尽早，尤其是技术行业，一定要提升技术功底。

zmq的pub/sub模式下inproc,ipc,tcp,epgm的通信性能测试结果以及分析(二)

将结果整理如图：

[if !vml]

[endif]

            （epgm后面四个时间因为过大，没有放进图中）

       通过对比，我们可以看出：

[if !supportLists]1.    [endif]四种方式的传输时间都随pub端发送消息的空间大小的增加而增加，在消息超过512kb之后，传输时间的增加速度变大，且tcp和ipc这两种方式最为明显。

[if !supportLists]2.    [endif]三种通信方式中，inproc 的速度远小于其他两种，特别是随着消息字节数增加，其性能优势愈发明显。

[if !supportLists]3.    [endif]比较tcp ，ipc和epgm ，可以看出在字节数小于65536的大多数情况下，三者差距不大。

[if !supportLists]4.    [endif]综合来看，inproc 的通信性能在当前情景下最有优势。

结果分析

对于以上的测试结果中inproc通信性能优势，通过参考 http://api.zeromq.org/4-2:zmq-inprocd 说明，可知zmq inproc是在单个进程中的不同线程之间传输。也就是说，不同的线程之间共享使用同一个ZMQ 环境上下文，如下，将新创建的上下文传递给子线程。

 

[if !vml]

[endif]

   已知zmq 通信用于node 和node之间，可以是主机或者是进程。结合以上inproc的特点，可以表明，对于一个采用inproc 的sub端来说，它会与同一进程中不同线程中的节点通信。而对于采用ipc 的传输来说，它会与同一主机不同进程上的节点通信，对于tcp 的sub端来说会与其他远程主机（本次测试都在本机）上的节点通信。

因此，使用inproc或ipc这样的传输，在正确的上下文中使用它们时，这两者比tcp传输速度更快，更高效。
Epgm采用的是udp协议对数据进行传输，而udp的设计传输极限不超过65535个字节，因此会在传输层进行数据分包，间隔一段时间再发送, 所以再字节数超过65535的测试中，时间都远超其他几种。

一些想法

基于zmq的特点，实际上在大多数情况下的远程服务器之间的传输，都只需要使用TCP传输，可以使用多对套接字。因为这样的应用场景，相对与socket的1对1 的关系，ZMQ 可以用N：M 的关系，在开发上zmq省略的细节，降低了开发难度。因此，如果要通过网络与其他计算机通信，请使用TCP。 

而在上文的测试中表明了inproc使用在同一个进程的线程之间，ipc表示本地进程之间，tcp表示远程进程之间。 因此，如果我们的场景是在多个不同的进程之间切换，但都在同一个逻辑服务器实例上，那么IPC传输可能是最佳选择。如果是在同一个进程之间，那么inproc 更为适合。Zmq的sub/pub可以在同一进程中，也可以在多个进程中（在远程和同一服务器实例中都可以）。我们可以根据应用场景的不同进行选择。

参考官方文档，可以知道epgm常用在mutilecasts的模式下。测试中也提示了我们使用过程中的注意事项，例如一次性传输数据超出限制，如果存在有多个发送端，某pub端发送的一次数据量过大，则可能出现sub端收到的包顺序混乱的情况。 关于性能测试结果分析和性能测试总结的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 性能测试结果分析的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于性能测试总结、性能测试结果分析的信息别忘了在本站进行查找喔。