性能测试案例02-信用卡申请审批系统

一、重点关注

1.  如何进行银行等特殊领域应用系统性能测试设计工作
2.  如何实施银行等特殊领域大型应用系统性能测试工作
3.  如何对银行等特殊应用系统的性能进行综合分析

二、项目背景

1、第一次系统上显示,银行安排了三次用户测试,结果均以系统崩溃告终。因此在项目进行重新开发时,首先对前一次开发的系统进行了详细的分析,以吸取上一次的教训。

2、经过架构设计、操作系统、数据库等相关领域专家共同分析,一致认为系统失败的主要原因是数据库设计的不合理:大量数据存储在一张核心表上,关键的业务操作时都针对同一张表进行。当大量不同类型的用户同时使用系统时,将会导致很多数据库事务不能并发进行,甚至发生死锁,直接表现就是数据库响应速度逐渐变慢。大量的数据库请求逐步占有越来越多的系统资源,最终导致数据库系统崩溃。

3、而数据库结构属于底层的系统结构设计,在程序开发完成后,几乎不能进行大的修改,因此三次测试,均以失败告终。

4、在这种背景下,用户就明确提出首先保证系统能够通过性能测试。

5、重新开发的系统为J2EE架构,采用Weblogic作为中间件服务器、Oracle作为数据库服务器。

三、性能测试策略

本系统属于特殊应用领域并且用户特别关注的应用系统。因此应该在系统架构设计阶段启动性能测试工作。

四、测试需求分析与规划

通过分析需求文档以及和用户沟通。

1.  系统的核心业务环节是电话核实与初级人工审核,大部分的信用卡申请都是通过这两个环节处理完成,少量的申请需要更高一级的领导来进行审批

2.  信用卡系统由于系统用户数目较多,而且业务吞吐量较大,因此在并发用户和业务处理能力方面是性能测试的重点。

3.  根据以往历史记录,预计每年发卡量不低于100万张的业务目标

4.  信用卡部门每年大约有265个工作日。

5.  平均每天需要审批通过3788份信用卡申请

6.  如果按照50%的申请通过率,卡中心每天大约要处理7576份申请。

根据上面得到的信息,对使用系统的人员做出下面的假设:

1.  在熟练操作的前提下,假设录入一份申请时间约为3分钟,则一个人每小时可以录入20份申请,8小时可以录入160份申请,预计卡中心需要48个人才能完成每天7576份申请信息的录入工作。

2.  在熟练操作的前提下,估计每份申请的电核与人工审核时间分别约为1分钟(由于用户操作越慢,压力越小,即使处理时间高于1分钟也不会影响测试结果),则一个人每小时可以处理60份申请,8小时可以处理480份申请。预计卡中心每天需要32个人进行电话核实与人工审核,才能来处理完每天7576份申请记录。

3.  对于整个应用系统,每小时需要处理约为948份申请。

信用卡系统用户构成:

在架构设计阶段,得到目标系统的如下信息:

1.  系统为了减轻录入数据时的压力,录入功能成为一个独立的系统存在。具体做法是先把录入的申请记录存储在独立的数据库中,当数据达到一定数量时把这些申请记录导入到XML文件中,然后应用系统在特定的时间把XML文件读入到自己的数据库中。系统申请录入的48人将由自动录入功能来代替,不需要模拟人工录入场景。

2.  系统稳定性方面设计目标是8小时连续工作,24小时步司机。这要求强度测试至少要对系统施压8小时。

3.  系统历史数据要在运行1年后才可以导出备份。这要求大数据量测试需要模拟一年以上的数据量进行测试,即系统要有200万条以上的历史记录。

五、性能测试计划及评审

测试计划

测试目的及范围

1.  压力测试目的
    评估信用卡申请审批系统的处理能力,包括性能和稳定性等。

2.  压力测试范围
    包含用户正常处理业务时的并发测试、系统有一定历史记录的并发测试、最大用户测试等内容,业务要涵盖数据自动录入、电话核实、人工审批等内容

测试方案简介

  1. 测试目标 对于整个应用系统,每小时需要处理约为948份申请。因此以下所讲解的压力测试都给予这个处理量来设计测试方案。

  2. 测试人员安排

  3. 测试岗位功能

  4. 测试岗位人员

  5. 测试结果检查 测试场景是否全部通过

  6. 监控资源 测试过程中主要通过LR监控Windows的系统资源。WebServer和Oracle则通过打开其自身监控工具进行资源监控。

  7. 测试场景设计 测试场景设计思路是先进行“单元模块压力测试“,然后进行多个模块的”集成压力测试“,最后进行全面的强度和大数据量测试。模拟的并发人数参考上面的测试需求分析。

测试计划评审结果

六、性能测试场景

各个案例的测试时间没有特殊说明,均为1小时

所有案例均通过测试工具LR8.0执行

所有案例均可以转化为人工执行的案例,只要把相应的操作换成真人即可。

  1. 电话核实压力测试、

    测试目的:电话核实业务独立承受压力情况

  2. 人工核实压力测试 测试目的:测试人工核实业务独立承受压力情况

    数据录入、电话核实、人工核实并发 测试目的:测试数据录入、电核、人工核实业务同时并发时系统的性能

    申请录入、全部审核业务并发1小时 测试目的:所有日常审核工作同时并发

    申请录入、全部审核业务并发8小时 测试目的:所有日常审核工作同时并发

    * 极限测试1:系统运转30个工作日时的数据量并发1小时
    

    * 极限测试2:系统运转30个工作日时的数据量并发8个小时
    

    *  极限测试3:系统运转半年时的数据量并发1小时
    

    *  极限测试4:系统运转半年时的数据量并发8小时
    

    *   极限测试5:系统运转一年时的数据量并发1小时
    

    *   极限测试6:系统运转一年时模拟一个工作日的业务
    

    *   极限测试7:最大用户测试
    

七、性能测试实施

测试程序开发

参数化

性能测试实施记录

性能测试场景调整

用户现场阶段的性能测试执行过程中,对测试场景进行了调整。调整用例主要是为了节省测试时间,满足客户的测试进度要求。

  1. 数据导入、全部审批业务并发1H

    测试目的:测试自动化录入数据时,日常审批工作的虚拟用户同时并发时系统的响应能力。 历史数据:系统无历史数据 测试场景描述:自动录入数据的同时,所有用户进行审核操作,统计1个小时内总的业务吞吐量。

  2. 系统运转半年时的数据量并发1H 测试目的:测试自动录入数据时,日常审批工作的虚拟用户同时并发时系统的响应能力。 历史数据:系统存在100万条历史数据,通过程序预先自动录入 测试场景描述:自动录入数据的同时,所有用户进行审核操作,统计1个小时内总的业务吞吐量。

  3. 系统运转一年时的数据量并发1小时 测试目的:测试自动化数据录入时,日常审批工作的虚拟用户同时并发事系统的响应能力。 历史数据:系统存在200万条历史数据,通过程序预先自动录入 测试场景描述:自动录入数据的同时,所有用户进行审核操作,最后统计1个小时内总的业务吞吐量。

  4. 系统运转一年时的数据量并发8个小时 测试目的:测试自动录入数据时,所有日常审批工作的虚拟用户同时并发时系统的响应能力。 历史数据:系统存在200万条历史数据,通过程序预先自动录入 测试场景描述:自动录入数据的同时,所有用户进行审核操作,最后统计8个小时内总的业务吞吐量。

  5. 最大用户测试 测试目的:测试系统最大并发用户数 历史数据:系统存在200万条历史数据,通过程序预先自动录入 测试场景描述:

    -自动录入数据的同时,不断增大用户数目和业务吞吐量 -LR的测试场景选择目标分析方式,通过工具自动分析最大并发用户数目。

八、性能测试结果分析

开发阶段的性能分析

  1. 电话核实业务性能测试分析
  2. 数据录入、电话核实、初级审批组合测试结果分析
  3. 8小时强度测试结果分析

用户现场测试的性能分析

  1. 电话核实、初级人工审批业务并发1小时结果分析 业务吞吐量以及处理效率分析 Weblogic 相关分析 Oracle相关分析

  2. 电话核实/人工审批业务并发1小时压力测试(100万历史数据) 业务吞吐量以及处理效率分析 Weblogic 相关分析 Oracle相关分析

  3. 电话核实/人工审批业务并发2小时极限测试(200万历史数据) 业务吞吐量以及处理效率分析 Weblogic 相关分析 Oracle相关分析

    综合分析结果以及调整建议 1. 在自动录入申请件时,模拟用户实际的电话核实和人工审批业务人员进行并发操作,系统的吞吐量和响应时间均符合要求。系统存在一年的历史数据进行并发测试时,性能有一定下降,但是仍然满足用户使用要求 2. 系统存在数据库服务器资源消耗严重的现象,扩展性很差 3. Weblogic 服务器的内存偏低

九、总结

1.  系统并发时,不能够完成预定任务,说明系统不能够正常分配任务或者分配后不能正常审批。最后证实是分配算法出了问题,即一个任务分配给多个用户。
    性能测试分析的第一步就是对业务进行分析,尤其是要分析在多用户并发时系统的核心模块能否正常工作,然后才可以进行更深入的性能测试。

2.  数据库时系统产生瓶颈的重要原因之一,因此对数据库进行性能分析时相当重要的一步。针对一些大型数据库,性能测试前应该认真检查参数配置,因为大型数据库通常进行合理的配置才可以发挥出好的性能。

3.  对银行类项目及特殊应用类项目尽早开始性能测试意味着节约成本。

4.  测试场景设计不拘泥于方案。

5.  性能测试团队分工明确
    性能测试工程师、Oracle的DBA、Unix系统管理员、Weblogic专家、程序员、项目经理

6.  首先要做好性能测试需求分析,同时根据“Web性能测试策略模型”,制定正确的性能测试策略,然后才可以进行性能测试规划与设计。在性能测试设计中最重要的是测试场景设计,测试场景的范围与详细程度要服从性能测试策略。测试场景一定要根据具体的测试项目以及可以投入的成本来进行设计。

7.  性能测试分析的重点是Web服务器、数据库服务器、操作系统、应用系统,主要根据一些反映系统瓶颈的计数器来进行分析。


评论(0 ) 点赞(16)


暂未登录,请登录之后发表评论。 QQ