前言

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

1、测试内容

◆ 联机业务

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

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

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

● 不同并发用户数(终端数)下，各种常用交易的响应时间情况;

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

◆ 批量业务

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

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

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

● 特殊交易

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

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

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

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

2、测试方法

◆ 联机交易

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

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

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

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

◆ 批量业务

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

◆ 特殊交易

● 日始签到

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

● 日终轧账

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

3、注意事项

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

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

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

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

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

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

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

以上对银行核心业务系统的性能测试内容、测试方法、测试中的注意事项等进行了简单的总结，由于银行核心业务系统包含的内容繁多，以上只是对一些简单业务的性能测试进行讨论。

感谢每一个认真阅读我文章的人！！！

如果下面这些资料用得到的话可以直接拿走：

1、自学开发或者测试必备的完整项目源码与环境

2、测试工作中所有模板（测试计划、测试用例、测试报告等）

3、软件测试经典面试题

4、Python/Java自动化测试实战.pdf

5、Jmeter/postman接口测试全套视频获取

我个人整理了我这几年软件测试生涯整理的一些技术资料，包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。如果在学习或工作中遇到问题可以直接进群询问，群里也会有大神帮忙解答， 欢迎在评论区留言或私信我谢谢。