1、测试背景
首先确保功能测试覆盖率达到100%，缺陷通过率大于95%，其次做性能测试。银行理财产品有银行兜底，所以卖的很火，银行发产品后客户集中在一段时间抢购，导致系统压力，出现大量失败的交易，所以为了保证系统长期运行的稳定性，针对典型交易做性能测试。
2、测试目标
获取系统的处理性能指标，满足当前生产系统及未来3年的业务发展需要。
发现性能瓶颈，协助开发人员进行性能调优。
3、测试指标
平均事物响应时间ART：
响应时间遵循2、5、8s原则，本次测试响应时间小于等于8s；
并发用户数：
现在高峰日操作人数500人，20%的并发量计算，高峰日并发用户数大于等于100
规划未来2年高峰操作达到600人，20%的并发量，并发用户数大于等于120
规划未来三年操作人数达到700人，20%的并发量，用户数大于等于140。
资源使用指标：
cpu使用率小于等于80%
内存使用率小于等于80%
磁盘交换率小于等于80%
tps值：
每秒处理的业务笔数，80%的交易在20%的时间完成，每天交易量10万笔，一天8小时
tps=80%*100000/（8*3600*20%）=13.89
并发交易成功率：大于等于95%
4、选取典型交易
性能测试主要针对交易量大的交易，如购买、赎回、份额查询。
5、测试工具
loadrunner8.1
nmon监测资源使用率，磁盘、cpu、内存等。
6、测试类型
基准测试
单交易单用户测试，典型交易在无压力情况下获取单笔交易处理的耗时，为之后的并发测试提供一个数据参考，一个用户跑5分钟。
验证测试脚本及测试参数的正确性。
获取单笔交易的性能数据，主要是单笔交易平均响应时间、TPS。
并发测试
主要分为：单交易多用户测试和混合交易多用户测试，由于最后要跑稳定性，本次只做单交易多用户测试。
每个典型交易通过单交易多用户迭代执行，获取性能指标，比如TPS、ART、系统资源使用情况，根据需要进行性能调优。
tps出现拐点时，继续测2组数据，如果这2组数据tps明显下降，此时就测出了最大并发用户数。
备注：交易数据库有当前流水表和历史流水表，所以每次跑场景前删除当前流水表的数据。
稳定性测试
多交易多用户的并发混合模式，对被测系统进行长时间的稳定测试，获取持续加压下的性能指标。考察是否会出现宕机、响应时间变长、交易成功率下降、资源使用率达99%的情况。
选取单交易并发时的最大用户并发数取中间值跑稳定性。
7、测试总结
目前我遇到的瓶颈和解决方式
1、磁盘交换率达到99%；
2、内存使用率5%左右；加大系统进程数并增加并发用户数。
3、内存使用率高达99%；经查看系统实时刷日志，原因是某个可有可无的参数没配置。
4、单交易sql执行时间2s；增加索引。
5、单交易执行时间过长；每次sum金额时，交易太多，执行时间过长，增加一张表每做一条交易sum一次，分担了压力。
6、tps值明显在某个时间点降低，经查询当前流水表数据大于100万条；这个目前无解得对数据库进行调优。
TPS计算：80%的事物在20%的时间内完成
稳定性测试用户数：80%的最大用户数
