一、前提
    近期我跟踪了2个外协人员参与的性能测试项目，沟通中发现大家在制定测试策略时对如何确定负载目标、计算并发用户数量等方面有很多不同方法，本文希望能对各种方法进行探讨，并根据已有经验对策略制定方面给出一些自己的建议。本文被测应用以银行系统为主，压力发起工具以LoadRunner为例。
    二、术语
    单位时间：本文中以1秒为单位时间。
    在线用户数量：访问被测应用的用户数量，但单位时间内用户不会同时对被测服务器发送请求，产生压力。
    并发用户数量：部分书中分狭义和广义两种，狭义指单位时间内同时执行一种操作的用户数量，广义指单位时间内同时执行多种不同操作的用户数量，广义的并发用户操作更接近实际业务环境。但本文中的并发用户数量仅指狭义而言，因为广义是多种狭义的组合。
    TPS:Transaction per Second，每秒事务数量，单位是事务/秒。
    TRT:Transaction Response Time，事务响应时间，指TPS稳定时的平均事务响应时间，单位是秒。
    三、负载目标
    1. 负载视角
    制定测试策略是性能测试的重点，包括测试范围、场景提取、负载目标、发起方式、通过标准等。而负载目标关系整个测试的场景设计、并发配比、结果评判，因此确定负载目标也决定了测试的总体方向。通过了解业务需求，负载目标都会转化为一系列具体的数值，一般可从两方面来划分：
    前端：业务人员更关注前端并发用户数量或在线用户数量，以人数衡量；
    后端：技术人员更关注后端应用服务器和数据库服务器的负载能力，以TPS衡量；
    前端并发用户数量的计算在业界中有很多公式和原则，如2/8原则、10%在线用户数量估算、（在线用户数量*session时间）/监控时间等，但各公式和原则计算出的并发用户数量并不精确，如有10万在线用户的系统不能说仅测试10万*10%=1万并发用户即可。
    后端TPS反应被测应用的实际负载能力，对已有具体业务量的应用可以计算精确，如银行系统中某省行对公交易量日均10万笔，则可精确计算出TPS均值=10万/（6*3600）=4.63笔/秒（对公业务按6小时计算），若被测应用达不到TPS要求则完成不了当日业务。
    同一个被测应用以不同视角估算负载目标，得到的数值可能会有很大差异，因此如何正确选择负载目标，将会直接影响之后的测试方法和场景设计。