2. 负载指标
    抛开视角的选择，单从终测试指标来说，对于一个软硬件环境固定的应用程序，只有一个负载指标是固定的，那是大事务处理能力 ? 通常以TPS衡量。随着负载的增加，被测应用将会逐渐达到大事务处理能力，若应用足够健壮，则负载继续增加，应用的事务处理能力也不会骤然下降。因此性能测试的目标是确定被测应用的大事务处理能力。以事务处理能力反推，将逐渐捋清TPS、TRT、并发用户数量、在线用户数量等负载目标的关系和估算。
    1、TPS
    Transaction的粒度会直接影响TPS的计算，因此Transaction定义时要保证粒度适当：
    C/S架构联机类应用中一笔交易往往会流经多层前置应用，需要确定压力发起工具所在位置，建议跨过前端直压被测应用，此时一个Transaction代表一支后台交易。
    B/S架构经管类应用中一个页面操作可能会和后台有多次交互，建议以页面上的操作为Transaction划分基准，但要保证Transaction内的交互操作在前端是不可再拆分的。
    LoadRunner发起压力时Action内的语句是反复迭代的，而LR计算TPS仅看1秒内执行了几次Transaction，如果Action内有多个Transaction则各事务的TPS都一样，反应不出各事务的真实处理能力，因此建议Action内只定义一个或尽量精简的Transaction.
    由此TPS才可以准确表示被测应用的事务处理能力。
    通过获取生产日志、参考相似系统等方式能够得到具体交易（事务）数量的被测应用程序，以TPS为负载目标是直接也准确的。但要注意，若以TPS为目标，则前端配置的并发数量不再代表并发人数，而是并发提交事务的数量。TPS和TRT的计算关系将在下面详述。
    2、TRT
    TRT指TPS稳定时（不一定是大时）的平均事务响应时间，不关注个别事务，它和TPS关系紧密，随TPS的变化而变化。当负载增加时TRT会逐渐增大，直至事务阻塞，交易超时。
    TPS × TRT = 并发提交事务的数量。如果以TPS=20为目标，且此时TRT=2秒，则并发提交事务的数量=20×2=40笔。如果1个用户单位时间内提交1笔事务，则可等于有40个并发用户数量。
    设定好目标TPS后要同时兼顾TRT的表现，若TRT明显超出业务要求，即使达到负载目标也是无效的。TRT无固定的好坏标准，一般来说对OLTP的联机应用，从前端提交到返回不应高于3秒，后台应用程序和数据库的处理应在1秒左右。对OLAP的在线分析系统或一般网站可遵循3/5/8原则，或更长。
    3、并发用户数量
    通常理解并发用户数量是LoadRunner里设置的VUser数量，通过梯度增加VUser，对比TPS变化即可找到被测应用的大并发用户。但我却认为并发用户数量不等于LoadRunner中设置的VUser数量。受交易响应时间、thinktime、pacing和集合点等因素影响，VUser数量不能直接体现被测应用负载能力。假设同样10个VUser并发一次，如果A程序的响应时间是1秒，则A程序的TPS=10/1=10.而B程序的响应时间是5秒，则B程序的TPS=10/5=2.同样在混合场景中用VUser比例体现不同应用的负载比例也是错误的，混合场景下由于各交易相互影响，单交易负载时响应快的很可能现在出现阻塞，前端VUser的比例根本无法准确控制后端应用的压力。
    因此我更愿意将"并发用户数量"和"并发提交事务数量"挂钩，体现被测应用实际负载：单位时间内n个用户并发向被测应用提交n个事务请求（n是相同的）。VUser的数量和发起设置只是实现并发用户数量的一种手段。
    4、在线用户数量
    在线用户数量与并发用户数量、TPS、TRT间没有固定的换算公式，我不提倡10%这样的粗糙比例，对联机类应用在线用户是每天签到的柜员数量，对经管类应用是月末、季末时所有登录系统的用户数量。在线用户数量可以从需求人员或生产管理员处获得大概数值，但不能通过性能测试倒推出在线数量。
    四、负载目标选择
    1. 有明确交易量的应用
    通过上面对各种典型负载指标的分析可以看出，以TPS衡量的事务处理能力是准确的负载目标。通过生产日志或相似系统的交易量可以算出TPS均值、峰值。根据2/8原则和业务扩展可估算更高的峰值。银行的联机类应用属于典型的有明确交易量的应用系统。
    LoadRunner中可以通过设置Run-Time Settings的Pacing为At fixed intervals， every 1 sec，来控制每次迭代执行时间为1秒。如果迭代脚本里只定义一个Transaction，且TRT小于1秒，则VUser数量=并发用户数量=TPS，可以通过调节VUser数量方便控制负载目标。注意，如果迭代中包含多个Transaction，或TRT随着TPS目标的增加而变大，则需以TPS目标为基础，实时调整VUser数量和这里every N sec里的间隔时间。
    2. 无明确交易量的应用
    无明确交易量的被测应用建议以确定大事务处理能力为目标。设置Pacing为As soon as the previous iteration ends，删除thinktime，部署发压工具和被测应用在同一网段，无网络瓶颈，让VUser能对被测应用产生大负载。弱化VUser数量听上去的意义，递增直到达到被测应用的大事务处理能力或其他性能指标阀值（如成功率或TRT）。新业务和经管类Web应用属于无明确交易量的应用系统。
    3. VUser的意义
    尽管建议在确定负载目标时弱化VUser的意义，但测试中还要注意一种情况，如果被测应用有具体的操作用户数量，如只有签到或登录的用户才能提交交易，则VUser的数量不能高于实际注册用户数量。按照大用户数量加压，以需求要求的TRT为目标调优被测应用，尽量提高TPS.