金融软件性能测试的理论分析

进入21世纪后，我国各家商业银行相继完成了数据的大集中工程，部分商业银行不仅完成了数据的物理集中同时也实现了数据的逻辑集中，从而使商业银行的IT风险管理、生产管理、数据管理、运维管理、研发管理、测试管理等诸多方面的IT管控能力得到进一步的提升，数据集中工程实现之后，各家商业银行的IT体系布局也逐步形成研发、测试、生产三足鼎立格局。在测试领域，由于数据集中之后面临着数据量的增长、交易量的增长和程序变更频率加快等实际情况，因而各家商业银行已经和正在面临着应用软件投产后的容量和性能的缺陷和瓶颈的困扰。基于近年来性能测试的实践，笔者将从理论、流程、方法、工具和技能5个维度探讨银行应用软件的性能测试的实质和规律，旨在引起有关领导、专家和专业人员对该领域的方法论的足够重视，并对其共同进行一些研究。

一、软件性能及性能测试

目前，业界对软件性能的定义主要有两种观点。第一种的观点是，软件性能是软件产品重要的质量指标之一，它描述软件系统或者组件对其及时性要求的符合程度，通常用及时性、吞吐量及可伸缩

金融软件性能测试的中国工商银行股份有限公司数据中心（北京） 林勇 霍嘉 侯志荣

理论分析

性来衡量。软件性能是软件产品的非功能特性之一，目前各家商业银行的软件开发部门提供的《软件需求说明书》（或者其他单独的文档）用专门的章节对软件性能需求加以明确，主要分为系统性能、安全性和可靠性等具体方面。第二种观点是，软件性能是软件产品重要的质量指标之一，它描述软件系统或者组件提供及时服务的能力，性能包括速度、吞吐量和持续高速性三方面的要求。具体而言，速度往往通过平均响应时间来度量，吞吐量通过单位时间处理的交易数来度量，而持续高速性是指保持高速处理速度的能力。

以上两种定义没有本质的区别，定义中描述的软件也完全适用于商业银行的应用软件。

对于金融软件来讲，站在不同的角度，对于软件性能的要求往往不同。作为业务人员，软件性能往往意味着业务请求响应时间，这个响应时间不仅仅是软件的响应时间，还包括网络的响应时间（比如某应用软件系统在版本测试过程中，由于分行网络带宽限制，业务人员大都反应系统速度太慢，实际上系统性能问题并不明显），甚至还要包括业务人员的操作时间。作为系统管理员（或者应用维护人员），通常通过计算机系统的性能指标，比如CPU利用率、内存使用率、用户并发请求数等技术指标来衡量。作为软件开发人员，则可能把架构设计复杂度、内存使用方式、资源竞争等指标作为软件性能的重要指标。软件性能评价的不同“用户视角”，是软件性能测试工程师不能忽略的因素。

软件性能测试既可以作为软件测试过程中的一项内容，也可以作为软件专项测试单独实施。软件性能测试是软件非功能测试工作中的重要内容，既遵循软件测试的一般规律，也有其特殊性，往往以基础的功能测试完成为前提。对一个系统而言，软件性能测试包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。软件性能测试用来保障产品发布后系统的性能和容量满足用户的需求，性能测试在软件质量保障中起着重要作用。软件性能测试还可以分为负载测试、压力测试、配置测试、破坏性测试、可靠性、容量测试等多项具体的内容，其主要区别是测试目标和测试手段有所差异。压力测试是软件性能测试的主要形式和基础。

在不同的应用领域开展性能测试工作，工作的目标与工作过程会有所不同，一般包括三个方面的应用领域。一是软件版本（包括了多个项目集中打包的综合版本或者应用版本投产的生产补丁）的性能测试，其目标主要是发现应用软件在性能和效率上的缺陷，或者证明应用软件无性能和效率上的缺陷，从而测算应用软件版本投产后生产系统的性能和容量变化情况，同时也为生产系统的性能、容量的评估和规划提供以测试数据为事实的依据证明，如主机（Mainframe）联机综合压力测试、主机批量压力测试、集中式平台应用的联机压力测试。二是应用软件的性能和效率问题诊断，例如可靠性、破坏性测试。三是系统性能优化调整，其目的在于证明系统性能在当前环境下的性能优越性，如应用软件版本的安装、投产演练，压力测试中某些参数的调整对性能的提升等。

面向问题诊断的性能测试工作，其目标主要在于通过压力测试，发现性能问题的瓶颈所在，往往与研究问题解决方案相结合，其工作特点具有试探性，不带确定目标，测试场景应该在实施过程中不断变化。

面向性能优化调整的压力测试工作，主要目标在于通过性能测试确认优化方案具有实际的改进意义。其工作方式主要是比较，在优化前后的性能测试工作中，基于同样的环境，使用同样的测试场景，比较前后的性能指标，至少需要实施两轮或者两轮以上场景的性能测试及比较。

无论何种性能测试，其基本的实施过程大致相同，只是在某些具体环境上有所侧重、有所调整。

本文阐述的软件测试原理和方法主要针对基本的实施过程，在不同应用领域开展实际工作时，可作适当精简或者补充。

需要指出的是，性能测试实际上也包括了疲劳及可靠性等因素，例如，性能（压力）测试在一定的负载状态下持续一定的时间，就是一个典型的考量应用软件的

疲劳强度的方法。

由上所述，我们可以将性能测试的目的描述为以下几点。①对待测试项目通过一系列的测试活动证明其不存在性能缺陷，投产后该项目在性能上是易用、可靠和优异的；②找到其性能上的瓶颈所在；③在当前的应用软件性能表现情况下，根据银行业务发展的趋势为生产环境的设备和容量管理及设备扩容提供依据。例如，某银行的××应用系统生产环境下已经达到12台（套），性能测试的目标将紧密围绕以下内容：在开发团队交付软件版本的基础上，性能测试证明了开发团队交付的应用软件无典型的性能缺陷；或者找到了开发团队交付版本的性能缺陷。此外，在测试环境下根据生产场景下的主要交易特征发现单套××系统在CPU和内存负荷在50%的情况下，以及单套××系统的处理能力在1200个并发交易请求情况下，其交易时间和交易成功率仍然是在合理的范围内；或者单套××系统在500个并发交易请求的情况下，交易时间和成功率仍然在合理的范围内，生产单位则可以根据该性能和容量基线进行合理的设备扩容。

二、性能测试的基本术语及度量指标

软件性能可以用好、中和差来定性描述，但没有明确的标准。面对不同的用户，定性描述得出的结果往往并不一致。随着对软件性能的要求越来越高，软件性能评价通常必须进行量化计量，基于专业的度量指标进行分析，然后得出结论。因此，从这个角度出发，性能测试的过程，也是一个性能数据采集与数据分析的过程。软件性能的度量指标包括以下具体内容。

(1)响应时间（Response Time）。是指用户发出请求到得到最终结果的时间。以开放平台典型的B/S应用为例，系统响应时间包括系统处理时间（Web服务器处理时间+应用服务器处理时间+数据库服务器处理时间）以及网络传输时间（Web服务器与应用服务器之间及应用服务器与数据库服务器之间）。

(2)平均响应时间（Average Response Time）。压

力测试往往需要模拟多个用户，每个用户执行多次业务操作。由于性能表现具有一定的随机性，系统性能也表现出统计学特征，每个用户每次的响应时间往往并不相同，计算全部用户全部请求的平均响应时间是评价系统性能的通用方法。

(3)并发用户（Concurrent Users）。并发用户是衡量系统并发处理能力的一个重要指标，是指同时对系统发出请求、施加压力的用户数量。一般并发用户往往是针对交易或事务而言的，通常并发用户用TPS （Transactions Per Second）指标来度量即每秒处理事务的数量。对主机系统或者从CICS的角度来看，系统管理人员一般称之为交易率。

(4)吞吐量（Throughout）。吞吐量是指“单位时间内系统处理的事务请求数量”，直接体现系统的性能承载能力。需要注意的是，事务请求数量可以在测试场景中自行定义；在本文或者后续文章中采用计算机应用软件在高峰期TPS下的持续30分钟或者60分钟的处理能力来度量。

(5)性能计数器（Performance Counter）。性能计数

器是从系统管理员的视角出发的一种性能度量指标，比如CPU使用率、内存PI/PO数据和I/O速率等。