1.性能测试导致应用服务器或数据库服务器CPU为100%

在性能测试过程中，应用服务器或数据库服务器的CPU为100%是比较常见的情况。其主要特征为：进行小并发的简单查询或添加等性能测试，而应用服务器或数据库服务器的CPU的利用率为100%。

如果应用服务器的CPU利用率为100%，则说明被测程序存在问题，需要调整。此时可以与技术经理协调，来对被测代码进行检查。

如果数据库服务器的CPU利用率为100%，则说明访问数据库频度很高或数据库执行任务频度较高，需要与技术经理协调，查看代码中是否存在频繁调用数据库的情况。

如果应用服务器为Linux服务器，则还要关注一下Load Average的值。Load Average是 CPU的 Load，它所包含的信息不是 CPU的使用率状况，而是在一段时间内 CPU正在处理以及等待 CPU处理的进程数之和的统计信息，也就是 CPU使用队列的长度的统计信息。因此正常的Load Average应小于CPU个数 * 核数 *0.7。

2.应用服务器内存泄露及内存溢出

在性能测试过程中，应用服务器中最常见的一种问题就是内存泄露甚至内存溢出的问题下面分别介绍一下内存泄露和内存溢出：

n 内存泄露

主要特征：进行负载测试或稳定性测试时，若为java应用，则应用服务器的内存呈持续上扬趋势。若为.net应用，IIS中会规定使用内存的大小，所以从应用服务器上很难看出内存是否泄露。但我们可以通过监控应用服务器中IIS所占用的内存大小及内存变化趋势来进行判断。

n 内存溢出

主要特征：进行负载测试或稳定性测试时，若为java应用，则应用服务器出现内存溢出错误。若为.net应用，IIS中会规定使用内存的大小，所以从应用服务器上很难看出内存是否溢出。但可以通过LoadRunner中的平均响应时间曲线和监控的内存曲线进行判断：若发生内存溢出，则LoadRunner中的平均响应时间曲线和监控的内存曲线均会出现突然大幅度下降的情况。此时在IIS中，也可以找到相应的错误信息。

3.性能测试过程中，响应时间较慢

这里的响应时间较慢是指针对软件需求规格说明书中规定的平均响应时间而言的。判断响应慢有如下几种情况：

n 测试脚本中是否有think_time：

检查性能测试脚本中是否有think_time；如果有，则需要将think_time语句全部删除，再进行测试；如果么有，则需要进行下一步的核查

n 应用是否采用连接池建立数据库连接：

需要检查被测应用系统是否采用连接池的方式来进行数据库的连接。如果不是采用连接池方式，则需要改成连接池方式后再次测试。如果采用的是连接池方式，则需要进行下一步的核查。

n 相应表是否建立索引：

需要检查测试场景中对应的数据库表是否建立了索引。正常情况下是检索条件的字段都建议创建索引。如果没有建立索引，则需要建立索引后再次测试。如果已经创建了索引，则需要进行下一步的核查。

n 执行的SQL是否过长

需要检索执行的SQL是否过长：SQLSERVER数据库可使用自带sql profiler工具对执行的SQL进行监控；而ORACLE数据库则使用v$sql 即可查到数据库中执行的SQL。例如：select   sql_text   from   v$sql   where   rownum <3;如果执行的SQL过长，就需要架构组对它进行优化；如果执行的SQL并不长，则需要将问题提交给架构组，让架构组来分析造成平均响应时间较慢的原因。

4.稳定性测试中CPU出现上扬趋势

稳定性测试中出现CPU上扬趋势时，应按照以下方法进行识别：

运行几个小时后，CPU有上扬趋势。如不明显，可将测试结果中的CPU单独展现出来，这样CPU的趋势会更加明显。

选中需要展示的指标，然后点击红框标识的按钮（show only selected），如图 1，就可以将选择的指标单独展示出来。如图 2。

图 1选择指标点击红框标识的按钮（show only selected）

图 2 单独展示CPU指标

如果CPU曲线上扬，则需要将问题提交给架构组，让架构组分析造成此问题的原因。

5.性能测试过程中，应用出现错误

在性能测试过程中，每次做完一个脚本的测试时，除了将测试结果保存下来以外，还要去应用中查看日志中是否有错误。如果有错误，则要提交给架构组，让架构组分析造成此问题的原因。