银行性能测试项目小结.docx

银行性能测试项目小结

第一篇：银行性能测试项目小结1、背景本次性能测试的系统是X银行营销服务系统总行版，该系统使用的数据库服务器、应用服务器均布署在总行机房，各地分行通过WEB方式登录访问本系统。系统上线后的总用户数（包括各分行、支行主管，客户经理等）在5000左右。该系统采用DB2数据库、WebLogic应用服务器。本次性能测试进入的条件是系统的代码已经基本完成并经过功能测试。2、测试计划在确定了本次性能测试的要点后，我们初步拟定一份性能测试计划，提交给客户，并获得了客户的认可。在本文中不列出项目测试计划中的所有内容，仅就主要问题进行说明。测试范围：在真实业务局域网测试环境下，对系统实施并发性能测试的同时，监控Web服务器和数据库服务器的系统资源，以及数据库资源的使用情况。测试内容：并发性能测试、系统资源监控。测试方法与工具：采用自动测试与人工测试相结合的测试方法，测试工具使用LoadRunner。测试资源：测试环境及测试数据准备。3、测试用例确定了测试计划，我们针对该系统的特点，从中挑选出三个有代表性的功能点，作为本次性能测试的用例。我们认为作为银行的营销服务系统，最常使用且对于系统的整体性能有着较大影响的是“客户信息查询”和“客户对账单查询”两个模块。因此，我们设计了三个单交易性能测试用例，分别是：“用户签到/签退”、“客户信息查询”、“客户对账单查询”。然而客户却对此提出异议，他们认为我们设计的测试用例数量太少，要求我们的测试用例应包含更多的功能模块。经过会议讨论，最终我们根据客户给出的一份性能测试大纲，针对其中提出的测试内容、测试策略，以及测试目标，将单交易测试用例增加到十四个。测试用例采用以下格式：要求清晰地描述出详细的操作步骤。4、测试数据针对以上设计的测试用例，需要准备大量的业务数据。本次性能测试的环境即系统上线后真实运行的环境，所有的业务数据均来自兴业银行的真实核心系统（通过ETL转换），数据量已经能满足测试的需要。由于测试用例中要求执行并发操作的时候使用不同身份的用户登录系统，因此在测试开始前需要准备一批具有不同身份的用户名（包括各分支行的主管以及客户经理），并且要有相应的操作权限。对于“积分转移”、“积分兑换”、“礼品兑换”等等交易，则需要提供一批卡上有足够积分的客户理财卡号。以上测试数据由兴业银行负责提供，在性能测试执行之前提供给我们。5、测试脚本使用性能测试工具LoadRunner录制并调试测试脚本，对相关的输入项进行参数化。6、测试实施在LoadRunner中执行测试脚本，实施性能测试。对于每个单交易测试脚本各执行一轮测试，并按一定的用户比例设计出一个混合交易场景，令其自动持续运行五小时左右，观察系统的性能表现。每次执行的结果文件均保存下来，待测试完成后连同性能测试报告一并交付客户确认。在此过程中，需要监视相关的系统资源使用情况，包括：应用服务器和数据库服务器的所有系统资源指标，所有数据库资源指标。7、测试结果经过本次性能测试，发现了系统五个主要的性能问题。我们与程序开发人员一同分析问题产生的原因，并给出改进建议，一起记录到测试报告中。其中的一个问题在性能测试报告提交客户之前已经过优化，得到显著改进。8、测试结论测试结果显示，系统性能能满足测试目标，交易并发数达到或超过30个，批量交易（查询记录50条以上的交易）并发数也能达到或超过10个，交易平均响应时间在2－12秒内，90％平均响应时间在2－15秒间完成。混合交易案例持续运行5小时，运行结果正常，系统没有报任何错误，系统稳定，可用率应达到100％。另外如在ETL批处理期间运行营销服务系统，系统性能明显下降，建议ETL批处理在夜间处理，避免影响系统的正常运行。9、经验在本次性能测试的过程中，我们遇到一些问题，通过解决这些问题，从中获得了一些经验。现总结如下：问题一在我们对系统进行测试的过程中，某些操作是相关联的。例如我们测试“查看客户资产历史”这个交易的系统响应时间，这时需要先列出客户的基本信息，选中一个客户，点击打开另一个页面，才能查看到该客户的资产历史信息，同时，在测试脚本中需要对所选择的客户编号做一个参数化，但由于LoadRunner不提供像WinRunner或QTP一样识别页面对象的功能，如果在Vugen中直接抓取页面上显示的客户编号去参数化，实现起来将十分烦琐。考虑到在以上那两步操作中，第一步“列出客户基本信息”只是辅助的操作，而第二步操作“查看客户资产历史”才是我们要测试的功能点，因此我们忽略了这二者之间的关联性，仅对第二步操作中的客户编号进行参数化。（只要服务器端对此不加验证，甚至我们将第一步操作都忽略掉，也是可行的）。结论：LoadRunner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的