金融软件性能测试策略与方法综述

随着互联网技术和电子商务的快速发展，淘宝“双十一”的抢购、春节火车票的抢票，带给用户的不仅仅是的秒杀激动，更多的是系统响应慢甚至无响应的沮丧。除去网络的因素，软件性能对客户体验的影响被放大。这些电子商务行为背后需要有强大的支付类系统的支撑，这对金融软件系统的非功能性指标——性能是极大考验。

        金融软件系统的实时性、健壮性、稳定性等较一般系统软件要高，应有效地实施性能测试，保障执行策略的制定、业务模型的建立、测试指标的选取。

一、性能测试的执行策略和方法

        对于联机类系统通常有多种测试类型(负载测试、容量测试等)，性能测试在实施前可根据测试目的，选取如下多个测试类型的组合，来制定相应的实施策略。

        1．基准测试

        系统在无并发压力情况下，验证单个功能点的性能表现，其响应时间可作为基准值，为后续场景测试提供分析参考。

        测试方法：在系统无并发压力情况下运行，单个用户单个功能点，通过多次运行取响应时间的平均值，主要关注交易响应时间。

        2．单场景测试

       在一定并发压力下，验证单个功能点的性能表现。一般在混合场景前执行，可较早发现问题。

       测试方法：使用LoadRunner工具向系统发送业务请求并接收返回结果的脚本，使用逐层递增的并发压力或者恒定的并发压力进行测试，获取单功能点并发时的性能表现。

        3．负载测试

        在可能发生的业务模型下，验证系统是否满足预期的性能指标。需要说明的是，预期的性能指标不一定达到系统的最大负载。

        测试方法：针对业务模型中确定的系统主要功能点，在特定并发压力下(通常为需求规划值)，验证系统是否满足性能指标。此指标一般体现为响应时间、并发用户数、系统处理能力、资源使用率等。主要关注性能指标在特定并发压力下是否均达到预期要求。

        4．容量测试

        容量测试目的是在系统没有出现任何软件故障或主要功能仍可正常运行的状态下，获取系统的最大承载、服务能力以及系统性能表现。

        测试方法：使用一定的并发压力，通过逐步递增并发压力，找到系统性能拐点，获取系统最大的并发用户数。主要综合关注响应时间、并发用户数、系统处理能力、资源使用率等。

        5．健壮性测试

        为了验证在异常状态下，系统是否能够在出现故障的情况下仍能保持继续运行的能力。根据系统可能发生为异常状态，设计该异常状态场景，在可能发生的业务模型下，关注系统是否能够继续运行以及其性能表现。

        测试方法：负载均衡或双机热备时，将其中一台应用服务器宕机，在负载压力保持不变的情况下，观察整个系统的性能表现以及其他相关服务器的资源使用情况；主机承受了压力无法正常工作后，验证备份机是否能够快速地接管负载；部分外围系统异常，观察应用系统能否继续承压运行以及与其他正常外围系统进行交互。

        6．浪涌测试

        高峰和日常压力交替多次出现的系统适用，考察系统的可靠性，验证系统在压力多次出现的情况下，是否存在异常情况。确定从高负载(例如系统高峰时间的负载)恢复，转为几乎空闲，然后再攀升到高负载，再降低的能力。

        测试方法：针对高峰及日常压力涉及的主要功能点及交易，通过增加和减少并发用户数的方式，模拟压力如浪潮一般上下，每轮先增加到高峰压力，保持运行一段时间(如1小时)后减小至日常压力，再保持运行一段时间(如1小时)，然后再反复重复这个过程。在压力循环叠加的情况下，验证系统是否存在业务积压并无法处理以及宕机等异常情况、第二次高峰是否重现第一次的峰值、其后的每次高峰是等于还是大于第一次的峰值、是否显示了内存或GC性能降低迹象等。

        7．恢复性测试

        适用于大多数联机类系统，验证系统能否快速地从错误状态中恢复到正常状态。

        测试方法：增加压力，模拟业务量突然增长情况使系统处于过载情况，主要表现为交易的失败率陡增，系统无法正常处理，然后减少压力至日常大小，查看系统是否能快速恢复正常处理，关注压力减小后交易成功率、系统处理能力、资源使用率等指标是否恢复正常。压力增大和减小可通过并发用户数调节。

        8．配置测试

        主要是获取应用平台的最佳参数配置及其排列组合。

        测试方法：在压力相同的情况下，改变应用平台的关键性能参数及其组合情况，查看系统性能变化情况，获取系统的最佳配置。

        9．稳定性测试

        在一定压力负载下，验证系统是否可长时间稳定运行，特别关注系统资源使用情况是否平稳以及是否存在内存泄漏等异常问题。

        测试方法：在可能发生的业务模型下，使用一定的并发压力，可参考业务发生的日常压力或者预期的负载，对于无生产业务量参考的系统，可参考容量测试结果选取(一般选取容量测试最大系统处理能力的75％对应的并发压力)。

        稳定性测试需运行较长时间，通常场景执行时间为24小时，如需适当缩短或延长执行时间，需要提供理由说明，建议最短不低于12小时。主要关注平均响应时间、系统处理能力、资源利用率、交易成功率等各项指标变化是否平稳，是否存在内存泄漏等问题。

二、性能测试业务模型的建模策略和规划

         本文所指的业务模型是指用于合理地模拟生产上真实的业务发生场景，通过不同建模策略和建模规则，得到的一组或多组交易或功能点的集合及其占比。

         1．建模策略

        业务模型建立之前，首先要确定需要实施的业务场景。两种常用场景为日常业务场景和高峰业务场景。此外还有异常峰值场景。

        日常业务场景是指在正常工作时间内，用户访问较平缓时的业务场景。高峰业务场景是指在高峰业务时间内，交易量较大或者用户访问集中时的业务场景。异常峰值场景是指在一段较短时间内，交易量爆炸式增长或者用户密集式访问系统时的业务场景。

        对于日常业务场景、高峰业务场景、异常峰值场景，三者的主要差距在于用来进行交易选取的时间段的不同。日常业务场景通常会选取平常日或小时的数据；高峰业务场景会选取高峰日、小时、分钟或者特殊日、小时、分钟的数据；而异常峰值场景往往会选取异常产生的时间点的数据。

        接近实际生产运行的业务模型须建立在合理有效的数据来源基础上。系统的运行数据往往是业务模型分析最有效的参考依据，但有些待测系统因各种原因不能提供有效的实际运行数据，如未投产的新系统。故以下从运行数据分析、类似系统数据分析和规划数据分析三种情况来描述数据分析的过程。

        (1)运行数据分析

        一般从系统生产环境提取运行数据，均为一个大时间段内数据。为了获取业务模型，需细化分析该大时间段内的交易量、交易发生时间以及变化率等。数据分析具体步骤如下。

       ①根据测试的具体目标选定用于数据分析的时间段，如季度、月、周等。

       ②根据选定时段内交易量变化趋势或者运行情况，选定平常日、交易高峰日或者特殊日。特殊日为月末日、年末日、节假日等。

       ③对于选定的平常日、高峰日或特殊日，按实际需求评估细化至时、分为单位，得到该细化时段内的交易及其交易量。对于异常情况，一般直接定位到具体的时间点进行分析。

        图1为某系统高峰日的交易情况统计图，其中l5：00～17：00交易量约为50 000左右，若以小时为单位进行建模，则可选取当日交易高峰时段15：00～17：00作为分析基准。

 1 2 3 下一页 尾页

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