分析性能测试（性能测试描述）

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

本文目录一览：

• 1、性能测试分析

• 2、如何进行性能测试与分析

• 3、性能测试分析实践分享！

• 4、软件性能测试分析的几种方法

• 
  

性能测试分析

如下图系统场景中，可以按照系统性能资源因素分为 CPU，内存，网络，IO 等四块区域来进行监控分析定位

度量方法：

衡量标准：注意 =50%，告警 =70%，严重 =90%

度量方法：

衡量标准：

运行的队列大于1时，证明已经有一定的负载了，不过这个计数也不绝对，需进一步分析其他的资源情况来断定是否 CPU 已经满负荷动作。

度量方法：

（9）通过perf 工具去捕获处理器的错误信息，需处理器支持

衡量标准：需处理器支持

衡量标准：注意=50%，告警 = 70%，严重 = 80%

度量方法：

衡量标准：

（1）so 数值大，且 swapd 已经占比很高，内存肯定已经饱和。

（2）sar 命令次缺页多意味已经在不停地和 swap 打交通，证明内存已经饱和

（3）当内存不够用会触发内核的 OOM 机制

度量方法：

衡量标准：有计数

度量方法：

衡量标准：

度量方法：

衡量标准：统计的丢包有计数证照已经满了

度量方法：

衡量标准：错误有计数

度量方法：

衡量标准：注意 = 40%, 告警 = 60%, 严重 =80%

度量方法：

衡量标准：IO 已经有满载嫌疑

度量方法：

衡量标准：有信息

如何进行性能测试与分析

“为什么我上线系统的性能和性能测试的结果相差很大呢？”这是一些用户会经常碰到的问题。当然产生这个问题的原因很多，下面我用一个很典型的例子来说明一下。一个用户登录界面，要求用户输入用户名、密码点击登录，登录系统。程序的处理流程如下：根据输入的用户名、密码生成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、原因解析 ：

出现TPS波动较大问题的原因一般有 网络波动 、 其他服务资源竞争 以及 垃圾回收问题 这三种。

2、排查方法：

2.1 压力测试环境一般都是在内网或局域网内进行，可通过监控网络的出入流量来排查；

2.2 其他服务资源竞争也可能造成这一问题，可以通过top命令或服务梳理方式来排查在压测时是否有其他服务运行；

2.3 垃圾回收问题相对来说是最常见的导致TPS波动的一种原因，可以通过GC监控命令来排查，命令如下：

1、原因解析：

出现该类问题，常见的原因有 短连接导致的端口被完全占用 以及 线程池最大线程数配置较小或超时时间较短 导致。

2、解决方案：

1、原因解析：

2、解决方案 ：

性能测试结果分析是性能测试过程中的最后一步，也是一个非常重要的部分，以系统的思路进行分析，可以一层一层剥离问题表象，找到真正的性能瓶颈并进行优化，提升整体服务性能。

软件性能测试分析的几种方法

”。这里强调以下内容：

(1) 充分准备以下内容：硬件设备、软件环境、网络条件、基础数据

(2) 充分准备测试场景、典型的场景包括操作序列、并发用户数量条件、用例。

该部分包括使用到上述测试方法：性能测试方法、可靠性测试、压力测试、失效恢复测试

2. 规划性能

3. 发现缺陷

这个环节中是交付给用户的主要工作成果。需要多和开发人员作沟通、多次迭代发现问题、根据用户的需求定义与缺陷的涉及范围、制定一个解决缺陷的优先级。由于软件永远有BUG这一真理，所以发现缺陷不是一次就能结束的工作。比较适合作为服务外包。持续进行。

4. 性能调优

一个标准的性能调优过程是：

(1) 确定基准环境、基准负载和基准性能指标。

(2) 调整系统运行环境和实现方法，执行测试。

(3) 记录测试结果、进行分析

在J2EE性能测试中有很多常见的错误，比如：对于某些建立在J2EE/EJB技术上的应用，在服务启动的时候，没有注意到测试之前首先进行一段时间的预热。这是因为JAVA语言的hot-spot技术特性决定的，这种技术允许weblogic第一次运行应用的时候将字节码编译为本地代码并执行，这样在后续的执行过程中执行过程会大大加快，但第一次由于存在一个编译过程会比较慢。如果使用这个时间来作为基准那么就容易得出错误的结论。 关于分析性能测试和性能测试描述的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 分析性能测试的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于性能测试描述、分析性能测试的信息别忘了在本站进行查找喔。