如果您按照XMeter的简明教程做完一次性能测试，就会得到类似下图的标准测试报告，其中汇集了各类性能度量数据。
那么，怎样解读这些图表和数据，准确评价您的被测应用的性能表现呢？其实很简单，我们结合例子为您逐个介绍这些度量指标。
首先，可以切换到“测试信息”页签，回顾一下本次测试的内容。核对您刚才运行的测试(包含哪些的页面操作)，虚拟的用户数，期望的测试持续时间，以及实际的开始结束时间。
回到“测试报告”页签，从“虚拟用户数”图表中可以清楚到看到，测试的1000个虚拟用户是在1分钟内逐渐进入系统的吧，整个测试持续了3分钟。 【注】爬坡行为（ramp-up）可以在提交XMeter执行任务时指定。
报告的前面部分是本次测试的汇总信息。您也许注意到，这些数值在测试执行时是不断更新的，反映到目前为止的系统状态，测试结束时数值定格，反映出整个测试的状况。
平均吞吐量：每秒完成的页面操作请求数 (即throughput，吞吐率)。【注】各类页面由上传的JMeter脚本定义，可以是典型的HTTP请求，也可以是其它类型的JMeter取样器(sampler)。
最大活跃虚拟用户数：系统曾经达到的最多并发用户数。这个值通常应该等于测试指定的用户数，除非脚本中有特殊的控制，让一部分用户先于其他用户结束执行。
平均、最大、最小响应时间：所有页面的平均响应时间，单位是秒或者毫秒 （单个页面的响应时间有表格提供）
请求响应码成功率：所有页面的成功响应所占的比例，比如 HTTP 200 OK或 3xx重定向，代表成功的请求，那些返回500 internal server error 或 404 page not found的请求则视为失败。
验证点成功率：如果脚本使用了验证点 (比如JMeter响应断言)，则统计验证点的成功率，否则这个值等同于响应码成功率。
平均请求大小：所有请求返回内容的平均大小。
本例中，请求的成功率是100%，平均响应时间1秒，服务器每秒处理了438个请求，看起来还不错。但是注意到最大响应时间53.9秒，说明有个别请求回来得非常慢，这需要结合统计方差和更多的日志去分析。
报告中部的几张图展示了随时间变化的页面响应时间，系统吞吐量，系统用户数，返回码成功率，网络下载流量的变化趋势。以页面响应时间为例，图上每条曲线表示一种页面请求，可以单击图例（文字部分）选择要显示的页面，多选可以点击的同时按下Ctrl或Cmd键（Mac）
本例中，关键操作/user_login的平均响应时间维持在1.5秒左右，是比较理想的结果。
“返回码成功率”的图上看到有点错误，对应/user_validat操作，99.5556%表示在这个采样间隔（缺省5为秒）发生过错，但数量很小，可能是大并发下偶然的连接超时，稍候我们再介绍如何从XMeter日志取得明确的错误信息。
“网络下载流量”图可以看出哪些页面操作耗费较多的网络带宽。本例中，最上面的深绿色线代表的操作加载了大量html内容，所以耗费的流量也最多（12.88KB/s)。
报告最后的部分是“测试数据明细”，可以查看按页面统计的响应时间，吞吐量，请求返回响应的大小，成功率和标准方差。（其中标准方差值越小，说明采样的样本间差异越小，系统表现也越稳定。）
点击表头的列名（比如平均响应时间，吞吐量）可以排序，方便找到哪些页面响应最慢，哪些错误率最小等等。
【注】将各页面的平均请求大小(KB/s)与吞吐量的乘积相加，近似可得测试中消耗的网络带宽。如果发现该值接近被测系统实际的对外带宽，可能要考虑增大带宽资源，以防网络传输的瓶颈影响测试结果。
分析完测试报告图表，我们转到“测试日志”页面。
可以在线查看XMeter后台JMeter容器的日志，采样用户与服务器正常交互以及出错时的日志(包含HTTP请求和响应的详细内容）。当然，您也可以下载打包的日志文件离线分析。
回到上面提到的/user_validat操作返回码错误，从sample_error.log可以看到这一个偶然的错误，的确是服务器连接被重置了。由于大量的并发访问时只出现一次这样的错误，所以我们可以忽略不计。
至此，我们介绍了XMeter性能测试报告的主要方面。
目前，我们还在不断完善报告内容，提高用户体验。您有任何好的意见建议可以告诉我们，谢谢！
网友评论