软件性能测试工具并非万能

随着近年来各家商业银行业务的飞速发展，银行业务系统规模不断扩大，各系统的业务处理量也随之飞速上升。某银行近年开发中心的故障分析报告显示，各信息系统全年与系统性能直接相关的故障占到总故障数的5％左右。此外，因业务处理量增速快而引发的系统及客户满意度风险也在不断扩大。因此建立高效率、高质量的性能测试体系是十分必要的，其必需依赖三个重要的因素：测试人员、测试资源和测试工具。本文将从分析调优、通讯协议支持等方面局限性的角度，对商业银行引进性能测试工具后依然可能面临的问题进行分析。

软件性能测试工具原理

        性能测试从广义上来说，包括的内容比较广泛，所对应的测试工具也有所不同。有针对服务器系统级的存储性能测试、I/O性能测试、网络性能测试，及其对应的测试工具；也有针对应用系统的压力负载测试，本文所述的软件性能测试工具仅指压力负载测试的工具。这类工具的目的是用于验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

        性能测试工具的原理通常是通过录制和回放脚本、模拟多用户同时访问被测试系统的场景，制造负载，产生并记录各种性能指标，生成分析结果，从而完成性能测试的任务。

        测试工具在典型的J2EE架构软件测试部署如图2所示：
 

测试-分析-调优：性能测试工具的角色和不足

        从软件性能测试想要达到的目标看，一种工具往往无法获得全面的测试效果。性能测试的目的是模拟有效负载，发现系统设计缺陷；从测试工具的原理上看，均是通过抓取负载发生时的相关软硬件资源（如操作系统、中间件、数据库等）变化数据，根据这些分析数据的走势变化情况由第三方工具或人工分析缺陷或问题发生的原因，并给出调优建议或直接由人工进行问题分析和调优。

        目前较好的测试工具带有故障定位和调优组件（需单独购买），其功能大体类似于一个专家库，存放的是各种常见的问题及可能发生的原因，便于开发和测试人员定位缺陷，但这种功能的提供不是专业针对某一种架构或语言的，因此其有效性和深度也就可见一斑了。

        实际上，对于银行各类0LTP（指实时交易类应用系统）和OLAP（指分析类应用系统）系统来说，其分析和调优的方式也不尽相同。OLTP系统往往是并发交易量较大的应用系统。以某银行一个高峰时期并发访问量最大的渠道交易类系统来说，并发度在5000以下，结合当今的硬件处理能力，其远未达到高并发负载的条件，也不需要考虑架构设计上的海量并发处理架构。因此小规模并发模拟测试主要在于验证系统展现层和逻辑层的逻辑设计是否符合技术目标；仅仅当负载超过了一定限值，瓶颈在数据层出现的概率才会大大增加。因此，对于中等规模商业银行来说，OLTP类交易系统（开放平台）在性能压力测试时，主要的关注点在于表现层和逻辑层的执行效率。

        以目前主流的。J2EE架构为例，IBM提供了WAS问题分析工具（IBM Support Assistance），帮助开发测试人员快速定位和解决问题。

 1 2 下一页 尾页

扫码即可手机
阅读转发此文