很多人一提到性能测试，第一反应就是把脚本录完、把并发拉高、把结果图导出来，好像这样就已经完成了测试。真正有价值的LoadRunner性能测试，并不是只看系统有没有慢下来，而是先搞清楚性能测试到底在测什么，再把运行过程中的事务、虚拟用户、吞吐量、命中率、错误率和资源曲线放到同一套逻辑里解释。

　　一、LoadRunner性能测试基本概念

　　理解LoadRunner性能测试基本概念，关键不是背几个术语，而是先弄清楚每个术语在测试里分别承担什么作用。很多人之所以报告写不清，不是因为不会操作工具，而是因为并发、事务、吞吐量和响应时间这些指标在脑子里本来就是混着的。

　　1、先分清虚拟用户和真实用户不是一回事

　　（1）LoadRunner里的Vuser是用来模拟用户行为的执行单元，它并不等于真实世界里某一个完整用户画像；

　　（2）同样是100个Vuser，不同脚本、不同Think Time、不同Pacing，压出来的系统负载可能完全不同；

　　（3）所以做LoadRunner性能测试时，不能只盯着并发数，而要看这些虚拟用户到底在按什么节奏跑业务。

　　2、事务是性能测试里最重要的观察单位

　　（1）在LoadRunner性能测试里，事务用来标记登录、查询、提交、支付这类关键业务动作；

　　（2）官方Analysis文档把Average Transaction Response Time作为核心图表之一，说明事务响应时间本身就是分析重点；

　　（3）也就是说，性能测试不是笼统地看系统慢不慢，而是看关键事务在不同压力下怎么变化。

　　3、吞吐量和命中率反映的是流量形态

　　（1）官方监控说明中专门列出Throughput、Hits per Second、HTTP Responses per Second等图表，这些指标描述的是系统接收和返回流量的节奏；

　　（2）吞吐量更偏向数据量，命中率更偏向请求次数，两者不能互相替代；

　　（3）如果只看响应时间，不看Throughput和Hits，很多流量型瓶颈根本看不出来。

　　4、性能测试本质上是在观察负载变化和系统反应

　　（1）官方SLA说明把Running Vusers、Throughput、Hits per Second、Transactions per second都纳入评估维度，说明系统表现必须结合负载水平来看；

　　（2）同一个响应时间，在低负载下可能是异常，在高负载下可能仍属正常；

　　（3）所以LoadRunner性能测试的基本概念，最终都要回到一个问题上，就是系统在什么压力下开始明显变差。

　　二、LoadRunner性能测试报告

　　LoadRunner性能测试报告，真正难写的地方不是把图贴出来，而是把图表、参数、异常点和业务结论串成一段让人能看懂的话。官方Analysis说明提到，Summary report会列出场景统计，并链接Running Vusers、Throughput、Transaction Summary和Average Transaction Response Time等图表，这也说明一份像样的LoadRunner性能测试报告，本来就不该只剩几张截图。

　　1、报告开头先交代测试边界

　　（1）要写清楚本次LoadRunner性能测试测的是什么系统、什么环境、什么业务流程、多少并发、跑了多久；

　　（2）还要说明脚本数量、事务范围、加压方式和运行时设置，否则后面的图表就没有解释基础；

　　（3）边界不清的报告，看起来数据很多，实际最容易失去说服力。

　　2、报告主体要围绕核心图表展开

　　（1）Average Transaction Response Time用来看关键事务在压力变化时是否明显恶化；

　　（2）Running Vusers用来看当前压力水平，Throughput和Hits per Second用来看流量强度，HTTP Responses per Second用来看状态码与错误分布；

　　（3）这些图必须配合着看，不能单独抽一张就下结论。

　　3、结果解读不能只写平均值

　　（1）很多人写LoadRunner性能测试报告时，只会抄一个平均响应时间，但平均值最容易把峰值抖动和局部崩溃掩盖掉；

　　（2）真正该看的，是响应时间在哪个时间段开始上升、是否和并发增长同步、是否伴随吞吐下降或错误增加；

　　（3）报告写到这里，才开始真正接近“分析”而不是“抄表”。

　　4、结论必须回扣业务和容量判断

　　（1）一份合格的LoadRunner性能测试报告，最后要回答系统在当前目标并发下能不能稳定支撑业务；

　　（2）如果不能，还要说明瓶颈更像出在应用、数据库、网络还是资源配置；

　　（3）只有把结果转换成容量结论和优化方向，这份报告才有真正使用价值。

　　三、LoadRunner性能测试结果怎么形成有效判断

　　把概念、场景参数、图表变化和资源表现一层层扣起来，看系统是在什么负载点开始出现明显退化，再判断这种退化是暂时波动，还是已经越过可接受边界。

　　1、先把负载和结果放在同一时间轴上

　　（1）把Running Vusers和Average Transaction Response Time关联起来看，能最直观地判断负载上升和响应变慢之间是否同步；

　　（2）如果并发没明显增加，响应时间却突然抖高，就不能简单归因于压力；

　　（3）这一步能先把“负载导致的问题”和“环境异常导致的问题”分开。

　　2、再把流量和错误一起看

　　（1）如果Throughput和Hits继续增长，但HTTP响应异常码也同步增加，说明系统已经开始用错误来换吞吐；

　　（2）如果吞吐反而下降，说明系统可能已经进入瓶颈区间；

　　（3）这类判断比只看单个事务慢了多少，更接近真实容量边界。

　　3、最后把图表语言翻译成业务语言

　　（1）报告里不能只说响应时间上升了多少秒，而要说在多少并发下，哪些核心业务开始影响用户体验；

　　（2）不能只说Hits per Second降了，而要说明系统在峰值访问下是否还能保持主要流程可用；

　　（3）把图表翻译成业务判断之后，LoadRunner性能测试结果才真正能给研发、运维和管理层使用。

　　总结

　　LoadRunner性能测试基本概念LoadRunner性能测试报告，真正高效的做法不是背术语、贴图表、抄平均值，而是先把Vuser、事务、吞吐量、命中率和响应时间这些基本概念理顺，再把它们放进场景设计、运行过程和Analysis报告里统一解释，最后回到系统容量和业务可用性上形成结论。