一、项目背景

第二代银行XX业务集中平台2014年升级项目对其原有框架结构和业务流程没有任何修改，只是新增了银行本、汇票和网银落地等几支交易，扩展了全国业务集中的范围。

但相对于我之前参与的第一代银行XX业务集中平台来说它的变化还是很大的：

1、为了应对全国集中带来的数据库操作瓶颈，它将业务切分的操作单拿出来做了个“录入中心系统”，系统的处理不再归银行XX业务集中平台负责。

2、对审录、复核等中心操作也做了分库分表，尽量将争抢频繁的操作分散开来，大大减少了数据库锁的争用。

二、测试策略

第二代银行XX业务集中平台系统已经在生产环境运行了很长时间，交易量稳定并且可得到确切数值，因此我们决定将测试的关注点放在新增交易对原有交易和系统资源占用的影响对比上。

基准测试场景：选取目前生产上交易量大、业务重要、工作流程复杂的代表交易,按当前生产TPS预估未来3年的TPS，按比例发起各交易的混合场景，记录下此时的资源占用情况。

对比测试场景：在基准场景下加入新增的交易，同样以未来3年的TPS为目标，观察此时对基准交易TPS和TRT的影响，对各服务器资源消耗的影响。

三、测试环境和数据

性能测试资源申请尽量贴近生产，我们共申请了4台4C8G的PC Server做IBM Websphere Application Server做应用服务器，对外提供WebService调用，2台4C8G的PC Server做异步处理服务器，1台IBM AIX小型机做数据库服务器（这里我们没有按生产配置搭建2台数据库服务器，因为生产上的2台数据库服务器硬件配置、建表配置等都是一致，只是做压力分担，而目前生产的压力也还不大），前端再配置了一个F5对应用服务器做负载均衡。

目前生产上每天对流水表进行备份清理，因此测试前的铺底数据量不需太多，待处理的任务数每个中心也只预留了一千多笔，混合场景开始后新的待处理任务将通过脚本产生。网点和中心按10个省的规模准备，这对柜员、角色、权限、中心对应提出了很高的要求。

四、测试执行

根据新增交易，测试共编写了6个新的WebService脚本，网点业务发起的脚本中只有一个“提交”请求，请求中省市、行部、柜员需一一对应，中心受理的脚本中分别包含“获取”和“提交”2个串行请求，因为这2个请求在客户端上是一个界面完成的，不可分割，并且“获取”请求将会获取到一笔有唯一编号的待处理任务，并将此编号放到“提交”请求中一起提交。这2个请求会在数据库多个流程表上加锁，因此在并发量大的情况下会造成较严重的数据库锁争用，是性能测试关注的重点。

测试过程中执行了多轮的基准和对比混合场景，由于银行XX业务集中平台系统在生产上运行的已经相当稳定，而新增的几个业务交易量还不大，因此没有发现特别严重的性能问题。

五、测试结果

本次测试共历时2.5个月，完成了测试方案和计划编写、测试环境和数据申请、测试计划和测试策略执行、测试结果汇总分析、测试报告编写等工作。测试中共发现了3处性能问题：应用日志读写频繁导致交易TPS上不去；系统流量控制未放开导致大并发下交易报错；数据库流水表少建一个索引，导致中心获取提交交易TPS上不去。3个问题均修改解决。