本文讨论的是基于字符终端型的银行核心业务系统。银行核心业务系统由于其复杂的业务流程，以及特殊的终端字符形式，与一般的B/S结构、C/S结构系统有较大的差异，其性能测试方法也存在很多的不同。下面就我对银行核心业务系统的理解，以及利用LoadRunner进行银行核心业务系统性能测试的相关经验，介绍一下有关银行核心业务系统的性能测试内容、测试方法，以及测试过程中的注意事项等。

　　测试内容

　　◆ 联机业务

　　联机业务主要是有关的柜台业务，如卡/折业务、贷款业务等。对联机业务的测试，主要是关注以下内容：

　　● 不同并发用户数（终端数）下，核心业务系统的处理能力，包括交易数/秒、交易成功率等；

　　● 不同并发用户数（终端数）下，各服务器端的资源利用情况，如数据库服务器、应用服务器、前置服务器端的CPU利用率、可用内存等；

　　● 不同并发用户数（终端数）下，各常用交易的响应时间情况；

　　● 一定并发用户数（终端数）下，系统长期运行的稳定性等。

　　◆ 批量业务

　　批量业务主要是结息相关的批处理业务。对批量业务的测试，主要是关注以下内容：

　　● 结息的账户数，包括活期户数、卡数、一本通数、贷款户数等；

　　● 结息的时间，包括起始时间、终止时间。

　　● 特殊交易

　　特殊交易主要是指日始签到、日终轧账等业务。对特殊交易的测试，主要是关注以下内容：

　　● 不同并发用户数（终端数）下，核心业务系统对日始签到、日终轧账的处理能力，包括登录柜员数/秒、轧账柜员数、登录成功率、轧账成功率等；

　　● 不同并发用户数（终端数）下，日始签到、日终轧账时各服务器端的资源利用情况，如数据库服务器、应用服务器、前置服务器端的CPU利用率、可用内存等；

　　● 不同并发用户数（终端数）下，日始签到、日终轧账的响应时间情况。

　　测试方法

　　◆ 联机交易

　　● 对核心业务系统进行负载测试

　　按照确定的测试功能及用户分布情况，模拟不同数量的柜员并发执行联机交易，得到各执行交易的响应时间、每秒的交易数、成功的交易数、失败的交易数，以及各服务器的CPU、内存利用情况等。

　　● 对核心业务系统进行疲劳测试

　　按照确定的测试功能及用户分布情况，模拟一定数量的柜员并发执行联机交易，连续运行一段时间，得到成功的交易数、失败的交易数，以及各服务器的CPU、内存利用情况等，从而得出系统长时间运行的稳定性。

　◆ 批量业务

　　启动核心业务结息操作，利用软件系统中的日志记录功能，记录验证结息的开始时间和结束时间，得到核心系统对结息的处理效率。

　　◆ 特殊交易

　　● 日始签到

　　模拟不同数量的柜员并发执行签到操作，记录响应时间、每秒的签到柜员数、成功的签到柜员数、失败的签到柜员数，以及各服务器的CPU、内存利用情况等。

　　● 日终轧账

　　模拟不同数量的柜员并发执行轧账操作，记录响应时间、每秒的完成轧账的柜员数、成功的轧账柜员数、失败的轧账柜员数，以及各服务器的CPU、内存利用情况。

　　注意事项

　　软件性能测试的大部份工作主要集中在测试前的准备工作上，银行核心业务系统也不例外，而且由于其特殊特点，准备工作中还需要注意一些事项，如：

　　（1）测试前需要准备一定数量的数据，为了保证不影响测试结果，需要在准备数据中注意以下事项：

　　◆ 每个存折、卡账号对应的钱数足够多，防止该账号余额不足，而不能再连续进行取款等操作，影响测试结果；

　　◆ 每个柜员对应的尾箱的钱数足够多，防止该柜员因为尾箱现金不够而导致不能进行取款、销户等操作，影响测试结果；

　　◆ 在非结息日事先选择一些账户进行存、取款业务操作，然后在结息日进行结息操作。脚本准备。

　　（2）利用LoadRunner准备测试脚本过程中，需要根据核心业务系统，选定终端类型、调整键盘选项等。

　　（3）另外在测试场景运行前，需要在LoadRunner的Countroler中选中RTE用户类型，否则虚拟用户会一直处于挂起状态，LoadRunner默认是没有选中该用户类型的。

　　以上对银行核心业务系统的性能测试内容、测试方法、测试中的注意事项等进行了简单的总结，由于经验有限，而且银行核心业务系统包含的内容繁多，以上只是对一些简单业务的性能测试进行了讨论，如有不当之处，请批评指正。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/