性能测试需求分析 业务PV量，响应时间、QPS、TPS
一、 性能测试需求分析
1.1 性能测试需求内容
性能测试需求应包括以下内容：
a) 测试场景及用例，用例访问URL；
b) 目标接口方法的入参、出参；
c) 外部依赖的服务细节；
d) 关键数据: 数据量、高峰业务PV量
e) 预期性能指标：响应时间、QPS、TPS等
性能测试需求模板表格参考如下：
性能测试(1) ---性能测试需求收集
1.2 预期性能指标1.2.1数据量
测试环境的数据量，应该跟线上环境保持一致，至少要在一个数量级。
举例有，中文站线上的每秒登录用户数据量平时为20个，特殊情况下，每秒为10万，那么测试环境要保证正常情况下在20个左右，至少是十的数量级，性能测试特殊情况下，要准备十万级的数据量，模拟最高并发用户数据量。
1.2.2高峰业务PV量
1) 二八法
若80%的访问量集中在20%的时间里，可用此分析方法，其图形就是一个正态分布图，如下。
具体计算公式为：
tps = (24小时的PV值*80%)/（24*3600*20%）
举例有，假如中文站每日的访问量为500万，其中19:00-23：40，访问量为400万，其余时间段的访问量很平坦，而且其余时间段的总访问量为100万，那么就可以用二八法，其计算公式为 tps = (500万*0.8)/(24*3600*0.2)。
2）简单峰值法
若在每天的某一时段里有很大的访问量，其他时间相对较少，可以用简单峰值法，其实二八法只是简单峰值法的一个特例。
具体计算公式为：
tps =(24小时的PV值)/（峰值时间段中的小时数*3600）
举例有，假如中文站每日的访问量为500万，其中17:00-24:00这个时间段里面访问量为450万，其他时间段的访问量很平缓，那么，我可以用简单峰值法近似计算，其计算公式为 tps = 500万/（（24-17）*3600）
3）无峰值法
若24小时里的访问量都是平稳波动的，没有峰值，那么可以采用无峰值计算方法，图形如下。
具体计算公式为：
tps= (24小时的PV值)/（24*3600）
举例有，假如中文站每日的访问量为500万，每小时的访问量都为20万左右，那么，可以用无峰值法来近似计算，其计算公式为 tps = 500万/(24*3600)。
1.2.3吞吐量
指软件系统在每单位时间内能处理多少事务/请求/单位数据等，
其与tps的近似计算公式为：（单位为秒）
tps = 这段时间内的总样本数/（最后一个请求完成的时刻-第一个请求发起的时刻）
可以这样举例，假如，在17：58的0 秒发起第一个请求，在18:02分0秒完成最后一个请求，在这4分钟整的期间，共处理的总的样本数为1000个，那么，可以这样近似计算：
tps = 1000/（4*60）
值得注意的是，因为每个请求之间的空闲值也包含在内了，故tps是有误差的，而且tps是个平均值。
来源：
需求收集之后，我们已经从性能需求文档中提取出了业务性能测试指标，主要包括PV到TPS的转换以及响应时间要求，接下来我们需要进行进一步的需求分析过程。
1了解系统架构、明确压力流向
例如统一订购平台的系统架构图：
理解架构图中各个节点的功能与交互关系，通过系统架构图我们能看到压力的入口，即oop应用。请求从oop发起，从udb取到会员数据后，通过dubbo接口，调用订购服务层提供的各种服务，订购服务层所需数据全部从对应cache中取。因此，主干压力流向可得知：
Oop—>udb
Oop—>dubbo—>订购服务层—>cache
然后结合需求文档，根据具体业务场景，确定各分支压力流向，比如有的业务场景需要从pc2取得用户的服务记录，有的业务场景需要付款则需要去帐户中心取得帐户信息，则新增的压力流向如下：
Oop—>dubbo—>pc2—>cache
Oop—>dubbo—>帐户中心
针对每一个测试场景，都要根据系统架构图进行上述分析，明确了各场景的压力流向，即明确了性能测试过程中的监控对象。
监控对象确定后，需要进一步分析明确测试重点，如上例，我们关注的重点是网站的oop应用，因为平台的udb、pc2，crm的服务订购中心，都有各自做过接口性能测试。或者有的所用应用功能是线上已有的，并没有修改变动，如帐户中心。明确测试重点，将有助于我们进行测试环境相关的测试策略的选择。
2 明确测试环境2.1 服务器数量确定
根据系统架构图，我们得到了项目中所涉及的环境。众所周知，测试环境越接近生产环境，则测试结果越精确。但通常我们会碰到服务器资源紧张，或者所用应用为外部门的外围环境，搭建方法复杂。此时我们面临两种选择，要么使用功能环境，要么mock掉该环境。建议不要选择前者，可以多个压力流向小的应用公用一台性能服务器。
2.2 服务器配置确定
还是一条不变的原则：测试环境软硬件配置尽量与生产环境保持一致。
机器的性能需求：32位or64位；4核or8核；是否要求同一网段
测试环境软件架构确定（jdk、apache、jboss版本、jvm参数）：与线上环境一致，重点关注jvm参数配置，确保与线上一致。
性能测试关注的主要硬件配置及OS参数如下表：
主机/ip
硬件配置
操作系统及参数调整
10.20.133.165
统一订购层应用服务器
机型
PowerEdge 1950
Linux 2.6.18-92.el5
64位操作系统
CPU
Intel(R) Xeon(R) CPU E5410 @ 2.33GHz * 8
内存
10G
网络
1000M
应用服务器配置检查中常用的linux指令：
查看机型: dmidecode --type 1|grep "Product Name"
查看CPU: cat /proc/cpuinfo
查看内存：free -mt
红框内即为本机内存总量
查看网卡：
1）ifconfig 检查服务器连接的哪块网卡（ethx）
上图红框内即为当前活动的网卡
2）ethtool ethx 检查网卡详细信息（ethx为ifconfig检查出来的网卡编号，如上图就为eth0）
上图红框内即为当前网卡带宽（双工模式）
查看操作系统：
uanme -a 查看所有信息
uname -o, --operating-system GNU/Linux
-r, --kernel-release 2.6.18-128.el5（操作系统内核版本）
-i, --hardware-platform x86_64（硬件版本）
-o, --operating-system x86_64（操作系统版本）
3 关键业务数据量分析3.1 数据量需求确认
1) 数据量是指的性能测试需要考虑的数据总量和数据类型。
例如在offer数据量为30w的DB中查询和在offer数据量为1000w的DB中查询，性能表现一定是不一样的。我们需要考虑，现阶段的数据量等级和未来发展趋势下的数据量等级。有的时候数据量也是程序分支逻辑，所以这点就必须详细考虑了。
2) 存储分布指的数据源的分布情况，是分布式分布还是单台分布；是search分布还是DB分布，等等。例如offer拆分项目的性能测试就需要综合考虑Oracle单表、Oracle16张表、mysql128张表的使用场景
3) 基本要求：测试数据库数据量要与线上数据量保持一个数量级。
3.2 造数据方法确定
根据数量级的需要，可以采用不同的方法，大致有以下几种：
1） 找DBA帮忙导线上/测试库数据；
2） 用datafactory/sql直接插数据库；（查看datafactory文档）
界面如图，具体使用方法问google
3） 用jmeter/LR/ruby等脚本走正常业务流造数据。（查看各脚本录制方法）
3.3划分测试场景、明确测试用例
测试用例的产生需要考虑以下几方面：
1) 测试页面和业务逻辑，也就是业务对应的功能点
注意，性能测试的测试用例也需要专一性，也就是对应单个测试功能点。
因为我们监控的是每个事物的响应时间，功能点需要单一。
2) 压力持续时间
压力持续时间指的是给服务器施加多长时间的压力。
这个时间，我们会结合测试场景，对压力时间做一定的控制。
ü 如果测试的是高峰场景，时间一般最少为1个小时；
ü 如果测试的是稳定性场景，时间一般最少要求8小时；
3) 并发数
不要混淆并发和TPS的关系。
并发数指的是同时有多少用户（线程）在对服务器施加压力，是量化的给服务器的压力；而TPS指的是服务器每秒钟能够处理的事物数，是服务器处理能力的体现。
来源：
1.1 性能测试需求内容
性能测试需求应包括以下内容：
a) 测试场景及用例，用例访问URL；
b) 目标接口方法的入参、出参；
c) 外部依赖的服务细节；
d) 关键数据: 数据量、高峰业务PV量
e) 预期性能指标：响应时间、QPS、TPS等
性能测试需求模板表格参考如下：
性能测试(1) ---性能测试需求收集
1.2 预期性能指标1.2.1数据量
测试环境的数据量，应该跟线上环境保持一致，至少要在一个数量级。
举例有，中文站线上的每秒登录用户数据量平时为20个，特殊情况下，每秒为10万，那么测试环境要保证正常情况下在20个左右，至少是十的数量级，性能测试特殊情况下，要准备十万级的数据量，模拟最高并发用户数据量。
1.2.2高峰业务PV量
1) 二八法
若80%的访问量集中在20%的时间里，可用此分析方法，其图形就是一个正态分布图，如下。
具体计算公式为：
tps = (24小时的PV值*80%)/（24*3600*20%）
举例有，假如中文站每日的访问量为500万，其中19:00-23：40，访问量为400万，其余时间段的访问量很平坦，而且其余时间段的总访问量为100万，那么就可以用二八法，其计算公式为 tps = (500万*0.8)/(24*3600*0.2)。
2）简单峰值法
若在每天的某一时段里有很大的访问量，其他时间相对较少，可以用简单峰值法，其实二八法只是简单峰值法的一个特例。
具体计算公式为：
tps =(24小时的PV值)/（峰值时间段中的小时数*3600）
举例有，假如中文站每日的访问量为500万，其中17:00-24:00这个时间段里面访问量为450万，其他时间段的访问量很平缓，那么，我可以用简单峰值法近似计算，其计算公式为 tps = 500万/（（24-17）*3600）
3）无峰值法
若24小时里的访问量都是平稳波动的，没有峰值，那么可以采用无峰值计算方法，图形如下。
具体计算公式为：
tps= (24小时的PV值)/（24*3600）
举例有，假如中文站每日的访问量为500万，每小时的访问量都为20万左右，那么，可以用无峰值法来近似计算，其计算公式为 tps = 500万/(24*3600)。
1.2.3吞吐量
指软件系统在每单位时间内能处理多少事务/请求/单位数据等，
其与tps的近似计算公式为：（单位为秒）
tps = 这段时间内的总样本数/（最后一个请求完成的时刻-第一个请求发起的时刻）
可以这样举例，假如，在17：58的0 秒发起第一个请求，在18:02分0秒完成最后一个请求，在这4分钟整的期间，共处理的总的样本数为1000个，那么，可以这样近似计算：
tps = 1000/（4*60）
值得注意的是，因为每个请求之间的空闲值也包含在内了，故tps是有误差的，而且tps是个平均值。
来源：
需求收集之后，我们已经从性能需求文档中提取出了业务性能测试指标，主要包括PV到TPS的转换以及响应时间要求，接下来我们需要进行进一步的需求分析过程。
1了解系统架构、明确压力流向
例如统一订购平台的系统架构图：
理解架构图中各个节点的功能与交互关系，通过系统架构图我们能看到压力的入口，即oop应用。请求从oop发起，从udb取到会员数据后，通过dubbo接口，调用订购服务层提供的各种服务，订购服务层所需数据全部从对应cache中取。因此，主干压力流向可得知：
Oop—>udb
Oop—>dubbo—>订购服务层—>cache
然后结合需求文档，根据具体业务场景，确定各分支压力流向，比如有的业务场景需要从pc2取得用户的服务记录，有的业务场景需要付款则需要去帐户中心取得帐户信息，则新增的压力流向如下：
Oop—>dubbo—>pc2—>cache
Oop—>dubbo—>帐户中心
针对每一个测试场景，都要根据系统架构图进行上述分析，明确了各场景的压力流向，即明确了性能测试过程中的监控对象。
监控对象确定后，需要进一步分析明确测试重点，如上例，我们关注的重点是网站的oop应用，因为平台的udb、pc2，crm的服务订购中心，都有各自做过接口性能测试。或者有的所用应用功能是线上已有的，并没有修改变动，如帐户中心。明确测试重点，将有助于我们进行测试环境相关的测试策略的选择。
2 明确测试环境2.1 服务器数量确定
根据系统架构图，我们得到了项目中所涉及的环境。众所周知，测试环境越接近生产环境，则测试结果越精确。但通常我们会碰到服务器资源紧张，或者所用应用为外部门的外围环境，搭建方法复杂。此时我们面临两种选择，要么使用功能环境，要么mock掉该环境。建议不要选择前者，可以多个压力流向小的应用公用一台性能服务器。
2.2 服务器配置确定
还是一条不变的原则：测试环境软硬件配置尽量与生产环境保持一致。
机器的性能需求：32位or64位；4核or8核；是否要求同一网段
测试环境软件架构确定（jdk、apache、jboss版本、jvm参数）：与线上环境一致，重点关注jvm参数配置，确保与线上一致。
性能测试关注的主要硬件配置及OS参数如下表：
主机/ip
硬件配置
操作系统及参数调整
10.20.133.165
统一订购层应用服务器
机型
PowerEdge 1950
Linux 2.6.18-92.el5
64位操作系统
CPU
Intel(R) Xeon(R) CPU E5410 @ 2.33GHz * 8
内存
10G
网络
1000M
应用服务器配置检查中常用的linux指令：
查看机型: dmidecode --type 1|grep "Product Name"
查看CPU: cat /proc/cpuinfo
查看内存：free -mt
红框内即为本机内存总量
查看网卡：
1）ifconfig 检查服务器连接的哪块网卡（ethx）
上图红框内即为当前活动的网卡
2）ethtool ethx 检查网卡详细信息（ethx为ifconfig检查出来的网卡编号，如上图就为eth0）
上图红框内即为当前网卡带宽（双工模式）
查看操作系统：
uanme -a 查看所有信息
uname -o, --operating-system GNU/Linux
-r, --kernel-release 2.6.18-128.el5（操作系统内核版本）
-i, --hardware-platform x86_64（硬件版本）
-o, --operating-system x86_64（操作系统版本）
3 关键业务数据量分析3.1 数据量需求确认
1) 数据量是指的性能测试需要考虑的数据总量和数据类型。
例如在offer数据量为30w的DB中查询和在offer数据量为1000w的DB中查询，性能表现一定是不一样的。我们需要考虑，现阶段的数据量等级和未来发展趋势下的数据量等级。有的时候数据量也是程序分支逻辑，所以这点就必须详细考虑了。
2) 存储分布指的数据源的分布情况，是分布式分布还是单台分布；是search分布还是DB分布，等等。例如offer拆分项目的性能测试就需要综合考虑Oracle单表、Oracle16张表、mysql128张表的使用场景
3) 基本要求：测试数据库数据量要与线上数据量保持一个数量级。
3.2 造数据方法确定
根据数量级的需要，可以采用不同的方法，大致有以下几种：
1） 找DBA帮忙导线上/测试库数据；
2） 用datafactory/sql直接插数据库；（查看datafactory文档）
界面如图，具体使用方法问google
3） 用jmeter/LR/ruby等脚本走正常业务流造数据。（查看各脚本录制方法）
3.3划分测试场景、明确测试用例
测试用例的产生需要考虑以下几方面：
1) 测试页面和业务逻辑，也就是业务对应的功能点
注意，性能测试的测试用例也需要专一性，也就是对应单个测试功能点。
因为我们监控的是每个事物的响应时间，功能点需要单一。
2) 压力持续时间
压力持续时间指的是给服务器施加多长时间的压力。
这个时间，我们会结合测试场景，对压力时间做一定的控制。
ü 如果测试的是高峰场景，时间一般最少为1个小时；
ü 如果测试的是稳定性场景，时间一般最少要求8小时；
3) 并发数
不要混淆并发和TPS的关系。
并发数指的是同时有多少用户（线程）在对服务器施加压力，是量化的给服务器的压力；而TPS指的是服务器每秒钟能够处理的事物数，是服务器处理能力的体现。
来源：