很多人看LoadRunner结果时，第一眼只盯TPS，看到曲线上下起伏就觉得系统不稳。其实TPS只是现象，真正有用的是先把曲线调出来，再和并发、响应时间、错误和资源类图一起对着看。OpenText官方说明里已经把这条路写得很清楚，Analysis里可以手工打开事务图，也可以把多张图做关联分析；而事务监控图本身就区分了成功事务每秒数、失败停止事务每秒数和总成功事务每秒数。

　　一、LoadRunner怎么查看TPS曲线

　　先别急着看结论，先把图开对。LoadRunner里和TPS最直接对应的不是一个笼统的“性能曲线”，而是事务类图里的【Transactions per Second Passed】和【Total Transactions per Second Passed】。前者更适合看单事务趋势，后者更适合看整场压测的总体事务完成速率。官方也说明，如果脚本里没有定义transaction，或者运行时根本没有transaction在执行，这类在线事务图就不会显示有效数据。

　　1、在Analysis里打开事务图

　　测试跑完进入Analysis后，先看左侧graph tree，再点菜单【Graph】→【Add New Graph】。官方示例是这样打开平均响应时间图的，事务类图也是同一路径，只是要在【Transactions】分类下选择对应图表。这个入口是最稳的，不容易把在线图、离线图和摘要页混在一起。

　　2、优先看两条TPS曲线

　　如果你要看单个业务事务的波动，先开【Transactions per Second Passed】。如果你想看整场压力下系统每秒总共完成了多少成功事务，就开【Total Transactions per Second Passed】。官方对这两张图的定义非常直接，一张看每个事务的成功速率，另一张看所有成功事务的总速率。

　　3、用图例先筛事务

　　图开出来以后，不要让所有事务一起挤在一张图里。官方示例里提到，可以在legend里点某个transaction高亮，也可以用过滤功能只看目标事务。这样做的好处是，TPS波动来自哪个业务动作，会比看一堆重叠曲线清楚很多。

　　二、LoadRunner TPS波动过大先看哪些指标

　　TPS波动大时，最怕只看一张图。官方文档一直在强调“比较”和“关联”这两个动作，因为单独看TPS，你只能知道它在波动，只有把相关图叠起来，才能知道波动是负载变化、系统变慢，还是错误把事务打断了。

　　1、先看Running Vusers

　　这是排查顺序里的第一张图。官方说明，Running Vusers图显示当前各负载机上正在运行的虚拟用户数量和状态；如果TPS的起伏和并发用户爬升、回落同步，那通常先怀疑加压节奏、脚本pacing或用户状态切换，而不是立刻怀疑服务端。官方还专门给了把Running Vusers和响应时间图做关联分析的操作。

　　2、再看Transaction Response Time

　　如果TPS掉下去的同时，事务响应时间明显抬高，这通常比“单纯的TPS起伏”更值得警惕。官方说明事务监控图本来就是配合事务速率和响应时间一起看的，Analysis里也支持把两张图合并做Correlate或Auto Correlate。

　　3、再盯Errors和Error Statistics

　　官方明确写到，错误数在某一时间段突然升高，往往就是性能问题信号；运行时图里还有Error Statistics和Vusers with Errors，能看出错误是脚本位置问题、负载机问题，还是应用侧报错。很多TPS大幅下坠，根子不是慢，而是失败事务突然变多。

　　4、Web协议场景再看Throughput和Hits Per Second

　　官方对这两张图的解释很直接，Hits Per Second看每秒HTTP请求量，Throughput看每秒收到的数据量，并且都建议拿来和事务响应时间对照。若TPS波动同时伴随Hits或Throughput的异常峰谷，说明波动很可能和请求量变化、返回数据体积变化或服务端处理能力有关。

　　5、最后看Connections

　　这一张很容易被漏掉，但官方给的提示很有价值。如果Connections到了平台期，而事务响应时间却突然升高，官方认为这往往意味着连接数不够，增加连接可能会明显改善响应时间。换句话说，TPS起伏有时不是业务逻辑抖，而是连接池、套接字或中间件连接能力先撞到了顶。

　　三、LoadRunner里怎样判断TPS波动是不是异常

　　真正要下结论时，不要只问“波动大不大”，而要问“它和什么一起波动”。官方给的工具其实已经够用了，关键是按顺序把图叠起来看。

　　1、TPS跌、并发稳、响应时间升

　　这种组合更像系统瓶颈，因为负载没明显掉，事务完成速率却下来了，而且响应时间还在变差。先查服务端资源、数据库等待和连接数，通常比先回头改脚本更有效。这个判断建立在官方对Running Vusers、TRT和Connections图的定义之上。

　　2、TPS跌、错误升、失败事务增

　　这种情况通常先查错误来源。因为官方已经把Errors、Failed transactions和Error Statistics分开列出来了，说明TPS下跌很多时候不是“慢”，而是“失败得更多”。这时要先看报错时间点和报错类型，再决定是脚本问题还是应用问题。

　　3、TPS波动但响应时间稳定

　　这类情况不一定是坏事。若响应时间没明显恶化，错误也没抬头，而Running Vusers、Hits或Throughput本身就在变化，那更可能是压测模型、业务节拍或脚本事务划分带来的自然起伏，不宜只凭TPS抖动就判定系统异常。这个判断同样符合官方强调“合并图表做相关分析”的思路。

　　总结

　　LoadRunner怎么查看TPS曲线，LoadRunner TPS波动过大先看哪些指标，关键都不在“看没看到波动”，而在“会不会把波动和别的图放在一起看”。先在Analysis里通过【Graph】→【Add New Graph】打开【Transactions per Second Passed】或【Total Transactions per Second Passed】，再按顺序对照Running Vusers、Transaction Response Time、Errors、Throughput、Hits Per Second和Connections。这样看，TPS曲线就不再只是一个会上下抖动的数字，而会变成你判断负载模型、应用瓶颈和环境异常的入口。