农商银行新一代综合柜面业务系统性能测试报告(doc
商业银行综合业务模拟实验报告
商业银行综合业务模拟实验报告实验报告本学期教务处为我们安排了商业银行综合业务模拟实验，在实验操作过程中，我们发现问题、解决问题，逐渐理解和掌握了银行日常业务的处理，包括个人储蓄业务和对公业务的处理；对现代商业银行的架构、运营模式有了一定的认识。
在这十几周的学习中，我们将银行经营管理的理论与实践相结合，系统地实践、体验和学习银行业务的相关业务,拓展了知识面，提高了我们学习、判断、操作、分析等各个方面的能力。
接下来按实验操作过程对相关业务的操作情况进行描述分析。
（一）个人储蓄业务一、储蓄柜员初始操作操作内容：登陆个人储蓄系统→修改密码和学号并增加尾箱→用尾箱登录在开始银行模拟业务前，老师给我们每个人分配了一个个人账号。
我们可以用此账号作为用户名登陆模拟系统，然后进入“信息中心”修改个人资料并增加尾箱，同时设置尾箱密码以及登录密码，这样方可保证每位柜员都有属于自己的操作空间，避免他人修改银行业务的相关数据。
本次模拟实验采取实名制，我们每个人都要在个人资料中填写自己的真实姓名，以便日后老师查看各位同学的实验进度以及得分。
修改完后，每次登陆后右边信息栏中就会出现自己的相关信息。
在本模块操作中一定要牢牢记住自己的柜员号以及所设置的密码，否则就无法登陆银行模拟系统进行业务操作，这样就只能重新申请一个柜员号。
二、储蓄柜员日初操作操作内容：凭证领用→重要空白凭证出库→现金出库→凭证综合查询→重要空白凭证查询银行柜台工作人员进行日初业务处理首先应领用凭证。
凭证及现金出库到柜员个人钱箱后才能进行柜员的日常业务操作。
我们必须注意到凭证“开始号码”与“结束号码”不能与其他柜员领取的号码相同。
自己领取的凭证号码应记下，以便接下来的业务操作使用。
在实验过程中，若我们想了解凭证的使用情况，则可以进行凭证综合查询和重要空白凭证查询。
三、储蓄日常业务操作之个人储蓄业务操作内容：开普通客户和一卡通客户→为普通客户和一卡通客户开活期储蓄账户并进行存取款、销户操作→开整存整取账户、部分提前支取→开定活两便账户并销户→开零存整取账户、存款并销户→开存本取息账户、取息并销户→开通知存款账户、支取部分款项并销户→普通支票账户开户、预开户、存款、取款、结清、销户→开教育储蓄账户、存款、销户→一卡通、凭证、新旧系统凭证替换、挂失、解挂、新旧凭证对照新增在本实验中听到了很多之前从未接触过的专业名词，如：一卡通、整存整取、定活两便、零存整取、存本取息等。
柜面业务系统实验报告
柜面业务系统实验报告1. 引言柜面业务系统在现代银行营运中起着至关重要的作用。
它是银行内部与客户之间进行金融业务交流和处理的关键平台。
本次实验旨在了解柜面业务系统的基本功能和流程，并对其进行实际操作，以加深对该系统的理解。
2. 实验目的1. 了解柜面业务系统的功能和流程；2. 掌握柜面业务系统的操作方法；3. 体验柜面业务系统在实际业务中的应用。
3. 实验过程3.1 柜面业务系统介绍柜面业务系统是银行内部的核心系统之一，它包括开户、存款、取款、转账、查询等多种功能，能够为客户提供便捷、高效的金融服务。
3.2 系统登录步骤：打开柜面业务系统应用，在登录界面输入用户名和密码，成功登录系统。
3.3 开户操作步骤：选择开户功能，填写客户信息，包括姓名、id号、联系电话等，并选择开户类型。
提交后，系统生成账号，并打印开户单据。
3.4 存款操作步骤：选择存款功能，输入账号和存款金额，确认无误后，提交存款申请。
系统将完成资金划拨并生成存款单据。
3.5 取款操作步骤：选择取款功能，输入账号和取款金额，确认无误后，提交取款申请。
系统将完成资金划拨并生成取款单据。
3.6 转账操作步骤：选择转账功能，输入转出账号、转入账号和转账金额，确认无误后，提交转账申请。
系统将完成资金划拨并生成转账单据。
3.7 查询操作步骤：选择查询功能，输入账号或id号，系统将显示客户的基本信息、账户余额等。
4. 实验结果通过实验操作，成功完成柜面业务系统的开户、存款、取款、转账和查询等功能。
系统表现稳定、功能完善，能够满足日常柜面业务的需求。
5. 实验总结柜面业务系统是现代银行不可或缺的一部分。
通过本次实验，我进一步了解了柜面业务系统的功能和操作流程，并学会了如何运用该系统处理日常金融交易。
在实际操作中，我也明白了系统的重要性和便利性。
然而，柜面业务系统也存在一些潜在的问题，例如操作过程中的繁琐性和安全性的考虑等。
希望能够不断完善柜面业务系统，提升用户体验。
银行测试总结汇报
银行测试总结汇报测试总结汇报：银行业务系统测试一、引言银行业务系统是现代金融机构的核心系统之一，涉及到客户信息管理、账户管理、交易处理、风险控制等关键业务。
为确保系统的稳定性、可靠性和安全性，对银行业务系统进行全面的测试工作显得尤为重要。
本文对银行业务系统测试的主要内容和结果进行总结和汇报。
二、测试目标和策略1. 测试目标：通过测试，确认银行业务系统在不同情况下能够正常运行，并满足业务需求和系统性能要求。
2. 测试策略：采用组合测试策略，包括功能测试、性能测试、安全性测试和用户体验测试等。
三、测试执行情况1. 功能测试：对系统各项功能进行了详细的测试，包括账户开户、存款、贷款、转账、查询等操作。
经过多轮测试，没有发现功能缺陷。
2. 性能测试：通过模拟高并发场景和大数据量的操作，对系统的响应时间和吞吐量进行了测试。
在满足业务负载的情况下，系统响应时间符合性能要求。
3. 安全性测试：通过黑盒测试和白盒测试，对系统的数据安全性和权限管理进行了验证。
经过测试，系统在账户信息保密、数据传输安全等方面达到了预期的安全要求。
4. 用户体验测试：以真实用户为基础，通过用户调研和问卷调查等方式，对系统的易用性和用户体验进行了评估。
大部分用户对系统的界面设计和操作流程表示满意。
四、测试结果和问题总结1. 测试结果：经过全面的测试，银行业务系统的功能、性能、安全性和用户体验等方面都达到了预期的要求，具备上线的条件。
2. 问题总结：在测试过程中，发现了少量的问题，包括界面布局不完美、某些操作流程略显复杂等。
这些问题已经反馈给开发团队，并得到了及时修复。
五、测试改进建议1. 增加自动化测试覆盖范围，提高测试效率。
2. 进一步加强系统的安全性测试，包括漏洞扫描、渗透测试等。
3. 加强性能测试的负载能力，并针对瓶颈进行优化。
4. 定期开展用户体验测试，及时了解用户需求和反馈。
六、总结通过测试工作，我们对银行业务系统进行了全面、深入的检测，确认其功能、性能、安全性和用户体验等方面符合预期要求。
系统功能测试报告
系统功能测试报告功能测试报告文件标识：无编制人：XXX审核人：XXX批准人：XXX版本号：1.0编制日期：2021年5月1日审核日期：2021年5月5日批准日期：2021年5月10日___目录：1.基本信息2.测试环境2.1 服务器2.2 客户机3.测试说明4.功能缺陷汇总及分析1.基本信息本报告是针对___的产品进行的功能测试报告，旨在评估该产品的功能是否符合设计要求。
2.测试环境2.1 服务器测试使用的服务器为XXX，操作系统为Windows Server 2016，配置为XXXX。
2.2 客户机测试使用的客户机为XXX，操作系统为Windows 10，配置为XXXX。
3.测试说明测试过程中，我们按照产品设计要求进行了各项功能测试，包括但不限于XXX、XXX、XXX等功能。
测试过程中未发现明显的功能缺陷。
4.功能缺陷汇总及分析经过测试，我们发现产品存在以下功能缺陷：1.XXX功能在XXX情况下无法正常使用。
2.XXX功能在XXX情况下会出现数据丢失的问题。
我们对以上缺陷进行了分析，并提出了解决方案。
我们将在下一版本中修复这些问题。
4.1 缺陷汇总4.1.1 版本 & 状态本文档记录了产品的缺陷情况，包括版本号和当前状态。
缺陷的版本号指的是在哪个版本中发现的问题，状态指的是缺陷目前的处理状态，包括已解决、未解决、已关闭等。
4.1.2 严重程度缺陷的严重程度分为五个等级：致命、严重、一般、轻微、建议。
致命级别的缺陷指的是会导致系统崩溃或无法正常工作的问题，严重级别的缺陷指的是会影响系统功能或导致数据丢失的问题，一般级别的缺陷指的是会影响用户体验或功能不完善的问题，轻微级别的缺陷指的是一些小问题，建议级别的缺陷指的是一些改进和优化的建议。
4.1.3 模块 & 严重程度缺陷还按照模块进行分类，并标注严重程度。
每个模块的缺陷都有对应的严重程度，以便产品团队更好地了解问题所在。
4.1.4 缺陷分类 & 状态缺陷还按照分类进行归类，并标注当前状态。
信用社(银行)对综合业务系统运行情况进行调研情况汇报
信用社（银行）对综合业务系统运行情况进行调研情况汇报省联社＃＃办事处：根据省联社＃＃办事处《关于开展综合业务系统有关调研的通知》要求，为全面了解农村信用社综合业务系统运行状况，加强综合业务系统的风险防范，进一步完善综合业务系统的运行机制，我社认真开展了此次专项调研活动，在综合业务系统运行过程中存在的一些问题，给信用社带来了诸多不便，特提出如下建议并予以解决：一、总的概况综合业务系统自2007年上线以来，运行状况良好，目前信用社资产、负债及所有者权益日益扩大，通存通兑、代收代发等功能的应用促进存款大幅度增长，出现了存贷两旺的上升趋势，给农村信用社带来了良好的发展契机。
二、系统在运行过程中存在和发现的问题（一）综合业务系统中单位存款账户对账功能欠缺。
单位存款账户管理现状：一是经检查发现大部单位存款法人对账流于形式，如某财政所会计懒于对账，所长从不过问，有的将盖好公章的6-7张空白对账单用于联社检查。
扰乱了我们检查的视线。
这是容易诱发类同江西省鄱阳县财政9400万元大案的关节，二是信用社对账人员不分离，柜员记账的不得对账，只能由会计主管对账，各网点对账后应复印一份报告联社财务管理部门，财务管理部门应定期电话复查余额。
《人民币银行账户管理办法》规定：1、基本存款账户，主要经营活动的转账收付、现金结算要通过基本存款账户办理，工资、奖金等现金的支取，应通过该账户办理，可进行任何操作。
2、一般存款账户可以办理现金缴存，但不得办理现金支取，3、专用存款账户中的“收入汇缴资金户”除向其基本存款账户划缴款项外，只收不付，不得支取现金；“业务支出账户”除基本账户划入款项外，只付不收，且可以支取现金。
4、临时存款账户的有效期限最长不得超过2年，可以支取现金（验资账户在验资期间只收不付）为此建议：1、综合业务系统中“单位存款账户”应设计密码确认对账，由对方法人或法人派人轮流输入密码对账。
2、综合业务系统中“单位存款账户”应设计主任、财务或分管的部门经理、分管领导用密码及指纹仪审批功能（按金额大小审批）。
银行综合柜面业务系统课程实践报告
《银行综合柜面业务系统》课程实践报告学年第学期起始周班级学生系(部)年月日（一）业务介绍银行柜面业务主要分为：对私业务、对公业务、结算业务、中间业务、以及外币业务。
对私业务一、银行内部组织架构每一个银行都有自己的组织结构特点，一般首先是这样区分,有总行,分行,支行之分。
总行,分行做的主要是行政类的,管理类的职位,除去个别部门外,都不会具体做业务。
形成的“总行—一级分行—二级分行—县级支行—分理处”的层级管理模式。
二、银行凭证和钱箱介绍银行凭证分重要凭证和普通凭证两大类。
重要凭证主要指金融活动中使用的票据（如汇票、本票、支票等）和卡片（如借记卡、信用卡）等。
普通凭证主要指金融活动充当过程记录的单据，如通用记账凭证、财务凭证等钱箱是金融收银系统中主要的硬件配件之一，和收款机结合使用，作用就是放置现金。
每一位新到的银行柜员都要申请钱箱。
三、银行实际凭证流处理领取属于自己的柜员号和凭证号四、用户管理1、修改柜员密码，激活柜员号：拥有属于自己的柜员号。
柜员通过凭证流得到自己的柜员号和凭证号，但初始的密码相同，因此需要对自己的柜员号进行密码的修改及激活。
交易代码为1262 通用模块——特殊业务——操作员管理——密码修改。
2、增加尾箱：用柜员号申请自己的钱箱。
分别输入尾箱号和尾箱名称（尾箱名称默认为自己的名字）交易代码为137 通用模块——增加尾箱——钱箱管理五、凭证流柜员组长（会计部主管）1、凭证领用：柜员组长将柜员入库的凭证上缴到总行，总行再将新的凭证下发到柜员组长。
交易代码为1251 通用模块——特殊业务——凭证管理——凭证领用。
2、凭证出库：柜员组长将从总行领到的凭证下发到柜员手中交易代码为1313、凭证调配：凭证调配下发下发到普通柜员交易代码为133重要空白凭证是指空白支票、存单、存折、联行报单等重要凭证，一般重要空白凭证都使用编号管理。
严格执行重要空白凭证双人分管制度，严格登记、盘结制度，严格控制请领数量，严格按照要求发放、使用，严格按照要求进行清点和管理。
银行分行新综合柜面系统上线总结
跨上高台阶步入新境界-------ⅩⅩ银行分行新综合柜面系统上线总结ⅩⅩ分行在接到ⅩⅩ银行总行大集中项目指挥中心将于ⅩⅩ年9月11日至9月14日实施系统切换上线的命令以后，立即向全分行员工发出了“令行禁止，现场督导；强化责任、任务到人；统筹安排，确保稳定；人员部署，后勤保障。
”的号召，强调分行全体员工一定不惜一切代价，同心协力，克难攻坚，确保数据安全移植、新系统成功上线。
上线前的三天时间里，全分行全体员工均放弃休息，24小时时刻待命，指令员登陆RTX和指挥系统，时刻关注总行下达的动态和指令，不停地对各支行下达各项指令，终于在9月12日移植成功，9月13日内部员工试营业，9月14日以新系统对外正式营业，当日对公众宣告了ⅩⅩ分行新综合柜面系统顺利上线的消息。
这次切换上线和前三轮演练是有区别的，各支行、各条线部门必须要严格按指挥中心下发指令规定的时间和要求完成各项切换任务，严格按照经过评审和演练验证的操作步骤执行切换任务，任务完成后要填写任务单存档，不准未接通知随意、擅自提前执行操作指令。
为确保系统上线切换期间各项工作得到有效落实，分行领导均分片到支行现场督导。
各支行、各条线部门按照分行下发的分时表上报了切换上线人员值班表，要求任务分配到人，责任到人。
做到上线工作和日常工作两不误，确保业务稳定、人员稳定、思想稳定。
分行提前做好了系统切换期间的员工就餐、住宿和交通等后勤保障，做好网点客户解释准备工作，以及突发事件应急处置预案。
周六、周日本来是法定假日休息时间，可是ⅩⅩ分行的领导和员工一个人也没有在家休闲娱乐，全在单位加班，不管是指挥中心还是各支行，RTX指令不停地下发，委派会计主管微信群里不时发出新消息，手机的铃声不断地响起，大家都在为上线忙里忙外、不停工作。
9月11日14点，各支行每隔半小时检查柜面业务办理情况（各类对账及差错处理、查询查复、第三方签退等），15:30，再次做了细致检查，看是否有挂账，如有挂账则手工入客户账。
银行系统测试总结
银行系统测试总结银行系统测试总结一、测试背景为了更好地提供金融服务，满足客户的需求，我公司开发了一套全新的银行系统。
为了确保系统的稳定可靠，我们组成了一支测试团队，对系统进行了全面的测试工作。
本篇总结将就测试过程、测试方法以及测试结果进行详细的分析。
二、测试过程1. 测试目标明确在测试开始之前，我们明确了测试的目标和范围。
目标主要是确保系统的功能、性能和安全性能。
范围包括系统的各个模块以及不同用户的使用场景。
2. 测试计划制定为了高效地推进测试工作，我们制定了详细的测试计划。
计划中包括测试的时间安排、测试的具体内容以及负责人的分工等。
3. 测试用例编写我们根据系统的需求文档、用户故事和功能说明等，编写了详细的测试用例。
用例覆盖了各个功能点以及可能出现的异常情况。
4. 环境搭建为了进行测试，我们搭建了一套独立的测试环境。
环境包括数据库、应用服务器、客户端等。
通过搭建测试环境，我们能够模拟真实的使用场景，以确保测试的有效性。
5. 功能测试在功能测试阶段，我们按照测试计划中的用例，对系统的各个功能进行了测试。
通过手工操作和自动化工具的结合，我们发现并修复了系统中的一些问题，确保了系统在各种场景下的功能正常运行。
6. 性能测试为了评估系统的性能，我们进行了一系列的性能测试。
通过模拟大量的并发用户操作，我们发现了系统在高负载情况下的瓶颈，并进行了相应的优化。
7. 安全测试在安全测试阶段，我们通过漏洞扫描、代码审查等手段，对系统进行了全面的安全检测。
我们发现了系统中一些潜在的安全问题，并及时提出解决方案，保障了系统的安全性。
8. 总结与反思在测试结束之后，我们进行了总结与反思。
我们发现了测试工作中的不足之处，并提出了相应的改进措施。
通过总结与反思，我们不断提高测试工作的质量和效率。
三、测试方法在测试过程中，我们采用了多种测试方法，包括黑盒测试、白盒测试、灰盒测试等。
通过不同的测试方法，我们能够全面地评估系统的稳定性、可靠性和安全性能，提供更准确的测试结果。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
农商银行新一代综合柜面业务系统性能测试报告(doc 29页)北京农商银行新一代综合柜面业务系统性能测试报告性能测试计划文档编号保密等级作者最后修改日期审核人最后审批日期批准人最后批准日期修订记录目录1测试简介 (1)1.1项目背景 (1)1.2测试目标 (1)1.3测试范围 (1)1.4性能测试指标要求 (2)2测试方案 (3)2.1压力模型 (3)2.2交易选择 (4)2.3测试脚本 (5)2.4资源监控 (6)2.5测试场景 (7)3测试环境 (9)3.1网络拓扑图 (9)3.2软硬件配置 (9)3.3测试工具 (12)4测试实施情况 (12)4.1测试时间和地点 (12)4.2参加测试人员 (13)4.3测试实施进度 (13)5测试结果 (14)5.1基准测试 (14)5.1.1测试结果145.1.2分析图表145.2并发测试 (15)5.2.1测试结果155.2.2分析图表166数据分析 (33)7系统评价 (35)8测试遗留问题 (35)9附录 (36)9.1性能测试记录表 (37)9.20210交易处理脚本 (37)11.1项目背景为解决原有字符终端柜面系统不能处理非线性数据（如图像）的缺陷、解决业务中的柜员离柜问题，并对交易前端的功能性梳理和整合，北京农商银行将实施现有字符终端向图形终端的改造，实施新一代综合柜面业务系统项目。
在新一代综合柜面业务系统全面推广上线前，需要对新系统平台进行性能测试，获取系统的并发处理能力、交易响应时间等性能指标。
1.2测试目标本次性能测试的测试目标为：➢获取新一代综合柜面业务系统在测试环境中的性能指标数据➢发现性能瓶颈，协助开发人员进行性能调优，对系统上线提供性能建议和评估1.3测试范围新一代综合柜面系统的架构示意图如下图所示，图中红线虚框为本次性能测试的范围，包括ABS处理平台的后台应用服务器和数据库服务器。
1.4性能测试指标要求2测试方案2.1压力模型本次性能测试采用如下的简易压力模型：➢通过LoadRunner模拟图形终端各柜员向ABS平台发起交易压力➢通过测试环境中的核心业务系统响应柜面交易请求2.2交易选择根据和开发组的沟通，选择如下前端处理比较复杂的典型交易：2.3测试脚本根据上述的系统架构示意图，通过LoadRunner的Socket协议录制柜面前端向柜面系统应用服务器发起的柜面交易，发现Socket 交互次数（一组send和receive算一次交互）特别多（0210交易51次Socket交互），而且脚本回放时报接收报文长度不匹配错误。
新柜面系统开发组提供了一个测试用的Jar 包，将图形前端ABC和后台应用服务器ABS之间的通讯过程进行了封装，通过解析描述型的交易数据文件后向后台提交交易，为此，使用LoadRunner的Java协议，测试脚本中通过调用Jar包中的对象提交柜面交易。
使用此测试脚本方案暂时也有如下缺点：➢无法实现交易数据的参数化➢脚本中只能定义各柜面交易执行全过程的长事务，无法对交易中各阶段进行分解分析（比如页面控件响应时间、交易提交响应时间、打印响应时间等）➢测试脚本中无法获取交易执行结果：交易提交后不返回响应特征码，从测试脚本中无法判断交易执行的情况，需要分析后台日志文件或数据库流水表分析交易是否成功（性能测试交易量巨大可能会引起大量的交易结果分析工作量）➢LoadRunner统计分析数据失真（因失败交易也当成成功交易进行统一分析）2.4资源监控根据压力测试模型，本次性能测试需要监控如下主机的一些性能指标数据：❖新柜面系统应用服务器主机（Linux操作系统）✓C PU – CPU Utilization（CPU使用率%）✓M emory –Paging rate（内存页交换速率）✓I/O – Disk Traffic（磁盘交换速率）❖新柜面系统数据库服务器主机（AIX操作系统）✓C PU – CPU Utilization（CPU使用率%）✓M emory –Paging rate（内存页交换速率）✓I/O – Disk Traffic（磁盘交换速率）❖LoadRunner控制器和压力产生器主机（Windows XP操作系统）✓C PU–% Total Processor Time（总的CPU使用率）✓M emory – Available Mbytes（物理内存的可用数，单位 Mbytes）✓M emory – Page Faults/sec（页面错误导致的页交换计数）✓I/O – %Disk Time（磁盘驱动器读写请求已用时间所占百分比）主机资源指标数据监控的方法：➢优先通过LoadRunner进行监控➢通过操作系统内部指令（如top、vmstat等）2.5测试场景设计如下类型的测试场景：➢基准测试：获取系统处理各典型交易在无压力情况下单笔交易的耗时，为并发场景提供一个基本数据参考。
➢并发测试：检验服务器端对每个典型交易多个并发用户的处理能力，获取系统处理性能指标值。
各测试场景设置信息如下：注：根据全行柜面终端数约2800的统计数据，最大并发数为终端数的10%～15%（经验值），选择最大300并发的场景。
33.1网络拓扑图本次性能测试环境的网络拓扑图如下：（其中核心系统使用测试环境中的172.16.12.6主机）LR3.2软硬件配置3.3测试工具4测试实施情况4.1测试时间和地点时间： 2011年10月08日— 2011年10月21日地点：北京农商银行空港办公区3楼测试机房4.2参加测试人员参加本次性能测试的人员包括：➢王鹏：测试经理，性能测试总体协调➢高伟：开发组支持，测试脚本录制和调试➢王晓华：性能测试专家，制订方案、指导测试➢王时磊：性能测试工程师，测试工具、测试场景准备、测试执行4.3测试实施进度5测试结果5.1基准测试5.1.1测试结果使用测试工具LoadRunner运行测试脚本，统计出测试结果如下（TPS、ART、CPU%均为平均值）：在无压力的情况下，0210（个人客户信息建立）的平均交易响应时间为418ms，其中该交易包括如下完整的交易处理过程（可参见附录2中0210交易处理脚本）：➢输入交易码后，获取Frame框架显示内容➢各输入场输入数据时与后台系统的交互➢提交交易，获取核心系统返回结果5.1.2分析图表测试工具LoadRunner Analysis的TPS图表：测试工具LoadRunner Analysis的ART图表：5.2并发测试5.2.1测试结果使用测试工具LoadRunner运行测试脚本，统计出测试结果如下（TPS、ART、CPU%均为平均值）：编号场景名称并发用户数交易总数成功交易数失败交易数交易成功率TPS（笔/秒）ART（秒）应用服务器CPU %数据库服务器CPU %1 BF_0210_10_10m 10 11,451 11,451 0 100.00% 19.0 0.524 12.9% 3.4%2 BF_0210_20_10m 20 15,532 15,532 0 100.00% 25.7 0.779 17.5% 6.4%3 BF_0210_30_10m 30 15,967 15,966 1 99.99% 26.4 1.136 18.2% 7.3%4 BF_0210_40_10m 40 15,987 15,987 0 100.00% 26.4 1.497 18.0% 7.7%在并发场景时，出现了如下两种交易失败导致交易成功率不高：1)并发数达到50时，ABS交易流水表出现记录状态为"x"的记录（未收到核心系统对交易的处理结果），并发数为10、20、30、40时基本正常2)并发数达到100及以上时，ABS交易流水表中记录数小于LoadRunner 中记录的实际发送的交易笔数（部分交易数据丢失，未发往核心系统）另外，从表中可以看出：➢在当前测试环境配置下，新柜面系统的最大处理能力约为40tps➢在50并发时，0210交易的平均交易响应时间为1.452秒➢在各并发场景下，应用服务器和数据库服务器的CPU占用率均不高5.2.2分析图表❖场景BF_0210_10_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_20_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_30_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_40_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_50_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_100_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_150_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_200_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_250_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线❖场景BF_0210_300_10m结果分析图1)交易吞吐量TPS-虚拟用户数量VU合并曲线2)交易响应时间ART-虚拟用户数量VU合并曲线3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线6数据分析对并发场景，根据不同并发数对主要性能指标（TPS、ART、CPU%）进行图表分析如下：从图中可以看出：➢随着并发用户数增加，TPS缓慢增加。