在完成JMeter测试脚本执行后，首先要做的就是判断收集到的测试数据是否真实有效。实际性能测试中有很多情况会导致测试数据失效，例如，运行JMeter的机器性能存在瓶颈、网络拥塞，甚至于测试脚本本身设计存在问题，等等，对无效的测试数据进行分析，纯粹是浪费时间。那么该如何判断测试数据是否有效呢？

（1）分析在整个性能测试执行期间，测试环境是否稳定正常。如果测试环境在性能测试执行过程中出现过异常，那么测试数据就会受到“污染”，由此得到的分析结果也变得毫无价值。

例如，测试期间运行JMeter的机器CPU占用率经常达到100%（或者内存占用很高）、测试网络出现拥塞导致响应延迟、待测系统参数配置错误（JDBC连接池等）......

（2）检查JMeter测试脚本参数设置是否合理，检查JMeter运行模式是否合理。JMeter测试脚本参数的设置非常重要，它会直接影响测试数据的准确性。例如，有初学者经常将线程组的参数Ramp-Up Period(in seconds)设置为0或者1。如此一来，JMeter就会瞬间启动该线程组下的全部虚拟用户，会为待测服务器施加巨大的压力。轻则导致服务器响应时长超长，重则导致部分虚拟用户等待响应超时而报错。正确的做法应该是逐步加压，而不是瞬间达到目标压力。另外初学者还容易犯的一个错误，就是以GUI模式运行大量并发测试。相对于费GUI模式而言，GUI模式对机器CPU和内存的占用会高得多。对于大并发量测试，最好采用非GUI模式。

（3）检查测试结果是否暴露出了系统瓶颈。没有必要在一切正常的测试结果上纠缠不止，应该重点关注异常的测试结果。如果测试结果显示一切正常，那么首先要考虑的是并发用户数是否足够多，对待测服务器施加的压力是否足够大。另外还需要考虑，待测系统是否存在什么机制屏蔽掉了大部分压力，例如，禁止同一个用户多次执行某项操作，或者多次查询同一组数据时使用缓存技术。对于这类情况，需要理清实际情况多加分析，以避免漏掉本该发现的性能测试缺陷。

确定测试结果有效后，接下来就需要对待测试数据进行深入分析了。而面对庞杂的原始数据，该如何进行分析呢？

如图12-1所示。

对一个软件应用系统而言，最终用户不会去关心系统的内部架构、技术实现等内部细节，他们只关心系统是否正确，是否响应及时。而且当系统出现性能下降时，最直观的表现就是响应时长边长。因此应该首先从原始测试数据中查看系统响应时长，判断它是否满足用户的期望，以此作为性能分析的起点。如果系统响应时长不满足用户期望，则说明系统的性能出了问题。发现系统存在性能问题后，就需要进一步分析那个环节出了问题。

目前的企业级B/S架构应用系统的架构颇为复杂，甚至存在不同企业的架构体系大不一样的情况。不过万变不离其宗，不同B/S架构应用系统的基本构成还是相似的。

如图12-2所示为B/S架构应用系统的基本构成。从图中可以看出，用户从客户端发出的请求数据包经网络到达应用服务器，在由应用服务器处理后转交数据库处理，最终响应结果由原路返回。在整个处理过程中，可以吧响应时长分为两段：一段是Ts，即服务器响应时长，包括应用服务器和数据库服务器的响应时长；另一段是Tn，即网络响应时长。

JMeter是开源性能测试工具，自然也无法如LoadRunner一般设计得非常完备，JMeter工具本身无法区分Ts和Tn，它只能统计总响应时长。不过测试人员可以用其他办法来加以区分，例如，使用最简单的ping收获Tn，再用响应时长减去Tn即可得到Ts。此刻，我们已经将响应时长分成了两部分，当然也就能将问题细分成两种网络瓶颈问题和服务器瓶颈问题。

接下来还需要对服务器瓶颈问题进一步细分为：应用服务器瓶颈问题和数据库服务器响应问题。要进一步分析问题根源，需要动态监视应用服务器和数据服务器。