作者：成洁
来源：《中国金融电脑》 2015年第7期
随着互联网技术和电子商务的快速发展，淘宝“双十一”的抢购、春节火车票的抢票，带给用户的不仅仅是的秒杀激动，更多的是系统响应慢甚至无响应的沮丧。除去网络的因素，软件性能对客户体验的影响被放大。这些电子商务行为背后需要有强大的支付类系统的支撑，这对金融软件系统的非功能性指标——性能是极大考验。
金融软件系统的实时性、健壮性、稳定性等较一般系统软件要高, 应有效地实施性能测试，保障执行策略的制定、业务模型的建立、测试指标的选取。一、性能测试的执行策略与方法
对于联机类系统通常有多种测试类型（负载测试、容量测试等），性能测试在实施前可根据测试目的，选取如下多个测试类型的组合，来制定相应的实施策略。
1. 基准测试
系统在无并发压力情况下，验证单个功能点的性能表现，其响应时间可作为基准值, 为后续场景测试提供分析参考。
测试方法：在系统无并发压力情况下运行，单个用户单个功能点，通过多次运行取响应时间的平均值，主要关注交易响应时间。
2. 单场景测试
在一定并发压力下，验证单个功能点的性能表现。一般在混合场景前执行，可较早发现问题。
测试方法：使用LoadRunner 工具向系统发送业务请求并接收返回结果的脚本，使用逐层递增的并发压力或者恒定的并发压力进行测试，获取单功能点并发时的性能表现。
3. 负载测试
在可能发生的业务模型下，验证系统是否满足预期的性能指标。需要说明的是，预期的性能指标不一定达到系统的最大负载。
测试方法：针对业务模型中确定的系统主要功能点，在特定并发压力下（通常为需求规划值），验证系统是否满足性能指标。此指标一般体现为响应时间、并发用户数、系统处理能力、资源使用率等。主要关注性能指标在特定并发压力下是否均达到预期要求。
4. 容量测试
容量测试目的是在系统没有出现任何软件故障或主要功能仍可正常运行的状态下，获取系统的最大承载、服务能力以及系统性能表现。
测试方法：使用一定的并发压力，通过逐步递增并发压力，找到系统性能拐点，获取系统最大的并发用户数。主要综合关注响应时间、并发用户数、系统处理能力、资源使用率等。
5. 健壮性测试
为了验证在异常状态下, 系统是否能够在出现故障的情况下仍能保持继续运行的能力。根据系统可能发生的异常状态, 设计该异常状态场景, 在可能发生的业务模型下，关注系统是否能够继续运行以及其性能表现。
测试方法：负载均衡或双机热备时, 将其中一台应用服务器宕机, 在负载压力保持不变的情况下，观察整个系统的性能表现以及其他相关服务器的资源使用情况；主机承受了压力无法正常工作后，验证备份机是否能够快速地接管负载；部分外围系统异常，观察应用系统能否继续承压运行以及与其他正常外围系统进行交互。
6. 浪涌测试
高峰和日常压力交替多次出现的系统适用，考察系统的可靠性，验证系统在压力多次出现的情况下，是否存在异常情况。确定从高负载（例如系统高峰时间的负载）恢复，转为几乎空闲，然后再攀升到高负载，再降低的能力。
测试方法：针对高峰及日常压力涉及的主要功能点及交易，通过增加和减少并发用户数的方式，模拟压力如浪潮一般上下，每轮先增加到高峰压力，保持运行一段时间( 如1 小时) 后减小至日常压力，再保持运行一段时间( 如1 小时)，然后再反复重复这个过程。在压力循环叠加的情况下，验证系统是否存在业务积压并无法处理以及宕机等异常情况、第二次高峰是否重现第一次的峰值、其后的每次高峰是等于还是大于第一次的峰值、是否显示了内存或GC 性能降低迹象等。
7. 恢复性测试
适用于大多数联机类系统，验证系统能否快速地从错误状态中恢复到正常状态。
测试方法：增加压力, 模拟业务量突然增长情况使系统处于过载情况，主要表现为交易的失败率陡增，系统无法正常处理，然后减少压力至日常大小，查看系统是否能快速恢复正常处理，关注压力减小后交易成功率、系统处理能力、资源使用率等指标是否恢复正常。压力增大和减小可通过并发用户数调节。
8. 配置测试
主要是获取应用平台的最佳参数配置及其排列组合。
测试方法：在压力相同的情况下，改变应用平台的关键性能参数及其组合情况，查看系统性能变化情况，获取系统的最佳配置。
9. 稳定性测试
在一定压力负载下，验证系统是否可长时间稳定运行，特别关注系统资源使用情况是否平稳以及是否存在内存泄漏等异常问题。
测试方法：在可能发生的业务模型下，使用一定的并发压力，可参考业务发生的日常压力或者预期的负载，对于无生产业务量参考的系统，可参考容量测试结果选取（一般选取容量测试最大系统处理能力的75% 对应的并发压力）。
稳定性测试需运行较长时间，通常场景执行时间为24 小时，如需适当缩短或延长执行时间，需要提供理由说明，建议最短不低于12 小时。主要关注平均响应时间、系统处理能力、资源利用率、交易成功率等各项指标变化是否平稳，是否存在内存泄漏等问题。
二、性能测试业务模型的建模策略和规则
本文所指的业务模型是指用于合理地模拟生产上真实的业务发生场景，通过不同建模策略和建模规则，得到的一组或多组交易或功能点的集合及其占比。 1. 建模策略
业务模型建立之前，首先要确定需要实施的业务场景。两种常用场景为日常业务场景和高峰业务场景。此外还有异常峰值场景。
日常业务场景是指在正常工作时间内，用户访问较平缓时的业务场景。高峰业务场景是指在高峰业务时间内，交易量较大或者用户访问集中时的业务场景。异常峰值场景是指在一段较短时间内，交易量爆炸式增长或者用户密集式访问系统时的业务场景。
对于日常业务场景、高峰业务场景、异常峰值场景，三者的主要差距在于用来进行交易选取的时间段的不同。日常业务场景通常会选取平常日或小时的数据；高峰业务场景会选取高峰日、小时、分钟或者特殊日、小时、分钟的数据；而异常峰值场景往往会选取异常产生的时间点的数据。
接近实际生产运行的业务模型须建立在合理有效的数据来源基础上。系统的运行数据往往是业务模型分析最有效的参考依据，但有些待测系统因各种原因不能提供有效的实际运行数据，如未投产的新系统。故以下从运行数据分析、类似系统数据分析和规划数据分析三种情况来描述数据分析的过程。
（1）运行数据分析
一般从系统生产环境提取运行数据，均为一个大时间段内数据。为了获取业务模型，需细化分析该大时间段内的交易量、交易发生时间以及变化率等。数据分析具体步骤如下。
①根据测试的具体目标选定用于数据分析的时间段，如季度、月、周等。
②根据选定时段内交易量变化趋势或者运行情况，选定平常日、交易高峰日或者特殊日。特殊日为月末日、年末日、节假日等。
③对于选定的平常日、高峰日或特殊日，按实际需求评估细化至时、分为单位，得到该细化时段内的交易及其交易量。对于异常情况，一般直接定位到具体的时间点进行分析。
图1 为某系统高峰日的交易情况统计图， 其中15：00~17：00 交易量约为50 000 左右， 若以小时为单位进行建模，则可选取当日交易高峰时段15：00~17：00 作为分析基准。
（2）类似系统数据分析
在没有投产运行数据情况下，可以优先参考功能相似系统的运行情况，数据分析方法同上。同时，获取的业务模型，须兼顾待测系统功能点的变化，根据实际情况对功能点进行合理的拆分、合并以及数量调整。
（3）规划数据分析
对于没有任何数据可参考的系统来说，需会同项目组与业务部门一同分析未来生产上可能出现的业务场景，获取业务模型。一般在前期系统技术方案中，会明确系统须支撑的相关交易及其交易量。
2. 建模规则
通过前期数据分析，可得到某个时间段内的交易及其交易量，作为备选集合供后续进一步的筛选。这些交易往往数量繁多。因此，基于测试目的和效率等方面的考虑，在业务模型的建立时，通常需要遵循四大规则：TOP 规则、特殊交易规则、内外部系统覆盖规则和等价类规则。一次建模过程可以同时使用一个或多个规则，从而能更准确地获取业务模型。
例如 ：通过对某系统2010 年5 月1 日到2010 年5月31 日共31 天的交易数据进行汇总分析，统计每日交易笔数，找出31 天中日最高交易笔数数据。再对日最高交易笔数数据进
行具体的分析，确定各交易笔数以及所占的比例，按照一定规则进行取舍，以此确定业务模型。
（1）TOP 规则
TOP 规则要求在备选集合中，选取占交易总量较大的交易纳入业务模型。通常会采取以下步骤进行实施。
①对所有的交易进行占比分析。
②按占比从高到低，进行累加。
③将占比累加值不小于选取阈值的交易，纳入业务模型范围。该阈值通常为90% 或以上，可根据具体项目情况设定。
如图2 所示，为一个交易选取阈值设定为90% 的业务模型分析过程。最终占比累加值大于了90% 的交易B、C、A、D 被选入业务模型。
（2）特殊交易或功能点规则
特殊交易或功能点规则要求在备选集合中，选取那些投产运行后可能对系统有潜在性能风险的交易纳入业务模型。这类交易主要的特点有以下几方面。
①交易的系统实现逻辑复杂。
②与其他交易采用不同的实现机制，如不同中间件、通信协议等。
③生产上出现过性能问题的交易。
④对本模块、其他关联模块或外围系统等有潜在性能风险的新增交易。
（3）内外部系统覆盖原则
内外部系统覆盖原则要求在待测系统存在内部子系统或者相关联的外围系统情况下，在备选集合中选取交易时，原则上须覆盖到该系统的众多子系统或相关外围系统。
如图3 所示，某系统受到来自“网银”、“柜面”、“电话银行”等不同外围系统的压力。因此，尽管“网银”与“柜面”类交易已占到所有交易的90%，“电话银行”类交易占比较小，但是为了全面考查三个外围系统对待测系统的性能影响，“电话银行”类交易也必须选择部分重要交易纳入测试。
（4）等价类规则
等价类规则是指建立业务模型时，可根据测试目的，适当地将技术实现相同的交易进行合并，在对服务器端造成同等压力的前提下，减少业务模型复杂度。
如图4 所示，为一个等价类原则的应用图。对于部分查询交易，系统采用了三种技术进行实现。因此在交易选取时，可对同样采用实现技术2 的交易A、C 进行合并，仅选择交易A 并根据A 和C 的交易总量重新计算占比。
三、性能测试指标的确定
性能指标是用来度量系统各项运行能力的数值指标。常用的性能测试指标包括：系统处理能力、响应时间、相对并发用户数、绝对并发用户数、成功率和资源利用率等。金融软件系统的联机性能指标包括但不限于上述度量指标，根据系统特点及不同类型的性能测试，其指标可调整。
1. 系统处理能力从业务指标角度来说，系统处理能力是指系统每秒钟处理完成的业务交易笔数，即TPS（Transaction PerSecond）。
从系统角度来说，需详细考虑每笔业务对后台服务器的请求次数，从而将每笔业务交易转化为系统请求数，因此，在这个角度上，系统处理能力可以定义为系统每秒钟处理完成的请求数量，即CPS（Call PerSecond）。
TPS 更为业务人员所理解，而CPS 更能考察出系统真实的处理能力。在实际分析系统处理能力需求的时候，需要根据项目组关注点的不同，采用不同指标进行衡量。
2. 响应时间
通常，响应时间是指从客户端发起业务请求，到得到响应的整个过程所经历的时间。系统响应时间，是指从前端发出请求，到系统处理完毕返回给前端处理结果的时间，仅包含了服务器处理以及网络通信所消耗的时间。用户响应时间，除了包含系统响应时间外，还需要考虑前端呈现时间（前端响应时间）和用户操作时间。性能测试主要考查服务器的性能表现，故一般采用系统响应时间作为衡量指标，以LoadRunner 为压测工具，系统响应时间是指从
LoadRunner 执行机发出请求，到获得响应之间的时间差。如需求方提供的指标值为用户响应时间，则须进一步分析得到系统响应时间。在某些特殊情况下，如需考查前端性能表现时，可考虑采用用户响应时间。
对于系统响应时间，通常采用交易平均响应时间、90% 交易响应时间、最大和最小响应时间等指标衡量系统性能。
（1）平均响应时间：在单位时间内，某交易运行得到响应时间结果的平均值。
（2）最大、最小响应时间：在单位时间内，某交易所有响应时间的最大和最小值。
（3）90% 交易响应时间：在单位时间内，某交易运行多次，将该交易的所有响应时间结果按升序排列，前90% 响应时间结果都小于的值，即为90% 交易响应时间。
3. 在线用户数
在线用户数是指同一时间段内访问系统的用户数量。这些用户在同一时间段内已登录或者已访问系统，但是不一定每时每刻都在进行操作。如果使用在线用户数进行并发测试，需要考虑增加模拟用户思考的等待时间( 即迭代时间)，来进行测试。
估算方法：一段时间内访问用户总数×Session 保持时间（分钟）/ 该时间段（分钟）
4. 并发用户数
并发用户数是指在同一时刻与服务器进行了交互的并发用户数量。这些用户的最大特征是和服务器产生了交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。并发用户数是从服务器端承受的压力来考虑的，越多的用户同时使用系统，系统承受的压力越大。
在性能测试中，如采用并发用户数进行测试，那么这些用户操作间将不加间隔时间。对于并发用户数，可以采用平均值（平均并发用户数）和峰值（峰值并发用户数）进行计算。一般均采用平均值进行测试。在浪涌测试中，峰值并发用户数可被用于做峰值点的压力。
在估算并发用户数时，首先须确认用于分析的时间段（一般与业务模型估算时间段一致），然后在该时间段的实际生产数据或者规划数据的基准上进一步地估算。
5. 成功率
成功率是指交易成功的数量占发出交易总量的百分比。性能测试一般只采用正案例对系统进行施压，因此测试过程中产生的错误交易绝大多数是由于系统无法承受压力而导致的。实时类要求性高的系统通常将成功率不低于99.9% 作为衡量指标。
6. 资源利用率
资源利用率用来衡量各服务器或者外设的系统资源占用情况。主要的监控项有CPU、内存、磁盘IO、剩余空间容量、网络带宽等。一般CPU 使用率采用75%~80%，内存使用率采用80%~90% 作为衡量指标。
HP 小型机下，内存使用率关注sys 以及usr 之和。IBM 小型机下，内存使用率关注计算内存（comp）。Windows 下，内存使用率关注剩余内存量，使用TotalAvailable Memory 计算得到。Linux 下， 关注buffer、cache、free，综合考虑应用内存使用模式，酌情去除buffer 或cache。
因篇幅问题不能全部显示，请点此查看更多更全内容