2、负载目标计算

　　与项目管理中的SMART原则类似，业务场景需转换成可量化、可衡量、可实现的负载目标才能进行性能测试，而负载目标要根据不同场景分别计算。根据上阶段收集到“原始”数据，本阶段可计算或指定出各种间接和直接的负载目标值，一般负载目标多从两种角度考虑：

　　2.1 前端角度

　　在线用户数量：间接负载目标值，可理解为所有能操作被测交易的用户（柜员）数量。

　　平均操作时间（思考时间）：间接负载目标值，与在线用户数量一同计算业务并发数量。

　　业务并发数量：典型场景中集中操作（不是绝对并发）交易的用户（柜员）数量。

　　2.2 后端角度

　　每秒交易数量（TPS）：根据日志计算出的被测系统应承受的每秒交易数量。

　　交易响应时间（TRT）：与TPS对应，负载场景下交易应达到的响应时间。

　　吞度量（Throughout）：LoadRunner中吞度量是以每秒收到的字节数计算，其实TPS也是吞吐量的一种，根据不同被测系统计算对应的吞吐量。

　　系统并发数量：区别于业务并发数量，系统并发数量更趋近于绝对并发。对长连接系统来说系统并发就等于允许的连接数，对短连接系统来说更多取决于架构。

　　被测系统CPU、Mem、Disk等指标值：多为指定值，如CPU利用率不高于80%等。

　　前端负载目标需要通过大量、广泛的业务和日志统计才能得出，如需记录下高峰时段操作交易的用户数量、估算用户状态比例、统计操作习惯等，由于考虑到人的因素，因此前端负载很难计算精确。前端负载目标适合交易关联不大、操作用户分散、无具体业务量要求的系统，如内控管理、培训考核、网银主页等（以B/S架构为主）。

　　后端负载目标则比较容易计算，如当前某省对公汇兑类交易日均8万笔，则TPS=80000/（6*60*60）=3.7笔/秒（对公按6小时计算）；核心系统联机交易平均响应时间在3秒以下等。后端负载目标适合交易关联度大、操作用户相对集中、有具体业务量要求的系统，以银行核心业务系统为主。

　　三、测试环境设计

　　1、硬件环境设计

　　大部分性能测试的硬件环境与生产相去甚远，受品牌、型号、部署方式（集群个数减少，软负载均衡代替硬负载均衡）等多种因素限制，无法直接将测试环境下的性能结果向生产环境做比例放大，因此硬件环境设计主要关注应用架构与生产环境一致（如应用、数据库服务器必须为集群方式），尽量减少性能测试中的硬件资源瓶颈（如数据库存储必须为SAN，发压与被测系统间网络带宽必须为1000M）。

　　2、软件环境设计

　　软件测试环境可从两个方面考虑：

　　2.1 基础配置

　　确认操作系统、中间件、数据库和被测系统的版本与补丁与生产环境一致，但操作系统、中间件、数据库的内部参数应根据测试硬件环境做适当调整，可参考生产中的设置比例。

　　数据库分区、索引等必须与生产或预计投产时一致。

　　2.2 外联系统

　　尽量减少外联系统，因为外联系统越多，测试链条越长，环境越难维护，问题越难定位。可适当在被测系统中做挡板程序，模拟与外联系统的应答，但必须保证被测系统中的逻辑分支没有被屏蔽。

　　3、铺底数据策略

　　性能铺底数据量的大小和分布情况会对测试结果产生极大影响，是场景设计阶段的重中之重！测试前对铺底数据的构造可从以下四个方面考虑：

　　3.1 表分区情况

　　确认测试环境与生产环境（或预计投产后）的表分区和索引分区规划一致，结合表清理策略确认典型场景中各分区、各表中的数据存量大小和分布情况。

　　3.2 表清理策略

　　确认生产环境（或预计投产后）的数据库表（尤其业务热表）清理和备份策略，与表分区情况配合，预铺数据并确保测试数据库表中数据存量与生产保持同一量级。

　　3.3 表维护策略

　　确认当前生产数据库表（尤其热表）和索引统计值更新、rebuild和reorg等操作的频度，在数据预铺中适当更新统计值，切勿在测试环境中频繁执行统计值更新等操作，造成虚假的性能表现。

　　如下图，更新统计值后表和索引的相关信息会统计正确，性能将得到一定程度的提升。

　　3.4 合理的业务数据

　　确认铺底数据中的柜员、行部、角色、权限、待处理任务等业务数据是否符合实际情况，切勿为图省事而创建超级行部、全能柜员和过量的待处理任务。