论文部分内容阅读
摘 要：性能测试是系统上线前最重要的系统级测试，省级集中的营销系统在正式运行前进行全面、完整的性能测试进行评估是必须的环节。文章简述了性能测试的方法、指标和资源监控的内容，详细分析了省级集中营销系统的体系结构，针对具体的测试目标及海量数据处理的要求设计了测试业务场景。并以一测试场景为例，介绍了消除性能瓶颈的方法。
关键词：性能测试；数据处理；场景设计；调优
中图分类号：TP274+.4 文献标识码：A 文章编号：1006-8937（2016）32-0086-02
1 概 述
性能测试是保证软件质量的重要手段，属于软件测试中的系统级测试， 它针对软件在继承系统中运行的性能指标进行测试， 旨在及早确定和消除新系统中的性能瓶颈[1]。
通过负载测试、压力测试等方法的性能测试，测试应用系统能否承受大量的并发用户数以及快速响应用户发送的请求，能否长时间稳定运行。在系统测试期间监控资源、获取性能指标并进行分析，找出系统在硬件、操作系统、数据库、应用软件等方面的性能瓶颈加以改善，使整个系统的性能得到改进优化[2]。
省级集中的一体化营销管理系统服务于全省广大用电客户和适于企业内部管理，具有如下特点：
①在可用性方面，需保证7×24小时不间断运行；
②在业务处理方面，应具海量数据快速处理、复杂业务流转畅顺、资料查询及时响应；
③在系统扩展性方面，需满足多层次应用、地域面积覆盖广、使用人员众多等多方要求。因此，系统的性能测试需要有完整、全面的方案。
为了获取省级集中营销系统性能指标瓶颈，提出改进、优化措施，基于已有成果，本文结合省级集中营销系统的体系结构，在设定具体测试目标基础上，提出了基于海量数据处理的测试场景具体设计原则和监控内容，通过案例分析说明了系统性能调优的具体方法。
2 性能测试概述
性能测试是通过模拟真实环境下的负载，采集系统各方面的性能数据，评估系统正常运行情况下的承受力和稳定性，分析系统的性能与存在的瓶颈。测试方法主要包括负载测试、压力测试、配置测试并发测试和可靠性测试等[3]。在测试过程中，通常需要合理的结合几种测试方法，模拟真实环境，设计不同的测场景获取更多有效的性能指标。
性能测试一般基于如下目的：
①验证系统在给定条件下是否达到设计目标或用户要求；
②探测系统在给定条件下极限处理能力；
③通过对系统各参数的调整，测试系统的最优性能配置；
④通过性能测试发现功能测试难以发现的与性能有关缺陷。
因此，对当前的系统给予相当的负载，并且能够分析系统在给定负载下的表现是实现性能测试的关键。为有效发现负载条件下的各项性能指标，需要筛选分析影响系统的主要测试性能因素，才能做到有的放矢。应用系统性能测试主要包括：响应时间、吞吐量、每秒事务数（TPS）、资源利用率、数据库性能等方面。
在进行性能测试时，需要对系统各个方面（包括系统硬件、操作系统、中间件、数据库等）统一监控，以便进行系统瓶颈的分析与优化。
3 测试方案
省级集中的营销系统为了满足高可用性、高可扩展性和高性能需求，采用了分布式协调服务ZooKeeper和自适配通信环境（ACE）技术构建通用的高性能分布式计算框架；同时，为了满足全省千家万户用电服务、电量电费计量收费的信息支撑服务要求，在系统中存放了海量的用户数据、电网数据，以及系统支持信息。测试场景的设计既要发现系统框架中用户访问的性能瓶颈，又要测试到海量数据处理的反应速度。
3.1 系统结构
基于SOA的多层架构的省级集中系统，在技术路线上采用将表示逻辑、业务逻辑与数据逻辑相分离，客户端支持PC、掌上电脑、手持电脑等设备；接入端通过负载均衡器将用户的访问按照一定的策略分配到不同的服务器群组；应用服务器将展示與运算逻辑分离，而逻辑运算服务组件采用混合模式，针对不同的服务要求采用C或Java来进行开发，以充分利用C语言及Java语言的优势；数据层通过小型机群与存储阵列实现海量数据的存放与访问。
3.2 具体测试目标
评估系统在现有软、硬件环境下可支持业务规模的系统性能。在包括多类业务场景情况下的如下指标：
①访问的平均响应时间；
②访问的最大响应时间；
③平均每秒处理访问数量；
④访问用户的成功率；
⑤规定最大用户并发数下的性能指标。
根据上述量化的指标测试，分析被测营销管理系统在不同并发用户数下的性能指标，找出系统性能瓶颈，提出改善性能方案。
3.3 测试场景设计|
性能测试的用例设计不同于功能测试用例，它只是有针对性地根据系统最可能出现瓶颈的功能点来编写，不需要覆盖整个系统需求[4]。为使性能测试的覆盖率更广泛，性能测试用例的设计需考虑单一场景测试用例和混合场景测试用例的同时存在，性能测试用例中也需考虑并发数、响应时间、持续时间、资源使用情况等关键设计值或者指标值的存在。见表1。
3.3.1 单一场景测试用例
单一场景测试用例（见表1）考察系统对于单一业务的并发处理能力，本次测试选择具有代表性、最核心的9个业务场景，按照实际数据确定并发数。
3.3.2 混合场景测试用例
在性能测试中，常见的错误观点是，认为分别优化单个操作，就能优化系统的整体性能，而事实上系统运行时，不同的操作之间往往对系统资源有互锁关系。为了模拟用户的真实体验，避免性能测试偏重于技术人员的想法，需要综合考虑整个系统的运行情况[5]。省级集中的应用系统中最具有代表性、最核心的9个单一业务场景组合起来则是有代表性、最核心的混合场景的测试用例，见表2。 按照实际数据情况确定并发数。在设计测试场景时，严格按照业务数据的处理关联和顺序，并且为真实模拟实际业务来满足测试的需要。
4 案例测试及分析
性能测试中的测试分析是难点，在应用测试实践中，需要针对具体测试结果进行分析。以下列举本方案中单一登录业务场景的测试及系统性能问题的调优方法和步骤，其中案例所用数据库为Oracle；数据库服务器操作系统为AIX；应用服务器平台为WebLogic。
4.1 测试结果
模拟实际操作员的登陆退出操作的功能，设置1 000并发循环10分钟，测试结果显示登陆的平均事务响应时间为3.139 S，HTTP返回状态全部是HTTP 200状态。
4.2 各测试结果指标分析
①系统响应：在10分钟内运行虚拟用户数一直在1000并发中，平均事务响应时间无特别大的波动，系统在此压力下运行比较稳定。
②在10分钟内每秒点击率图和吞吐量图呈现一致情况，平均每秒吞吐量为14 967 273.462Byte/s=14.27 MB/s，相对于千兆网络不会形成网络瓶颈。
③服务器性能：从Web服务器、Java组件服务器、数据库服务器资源情况来看，Web应用服务器CPU在30%左右，JAVA应用服务器CPU不超过5%，数据库服务器CPU不超过5%，服务器资源运行良好。
從上述结果中我们看到登陆功能压力测试期间运行稳定，各个系统资源没有形成明显的瓶颈。
④问题症结：平均响应时间为3.139 s，不符合要求。针对这种情况，我们对登陆事务进行网页细分进一步查看时间消耗，找到登陆中时间占比最大的页面请求，进一步排查发现登陆功能的页面请求量比较多。
4.3 系统优化
经程序代码排查，简化login.jsp页面请求、压缩grid.js文件组件，提高较大页面组件的执行效率，从而缩短响应时间，提高系统性能。调整后，登陆响应时间满足测试方案需求。
5 结 语
性能测试是应用系统上线前必须经历的过程。系统设计中的任何一个小问题都可能造成严重的性能影响，尤其针对省级集中的系统，一旦出现问题影响范围更大。在性能测试方案中，针对系统特点模拟运行真实的业务场景发现系统架构、系统设计、中间件、数据库、应用服务等各个方面的性能问题，对性能瓶颈有的放矢不断优化调整，使省级集中的营销管理系统达到设计和应用要求，为系统上线打下坚实的技术基础。
参考文献：
[1] 张永祥等.性能测试专家分析系统[J].计算机系统应用，2013，22（4）：6-9.
[2] 李怡，周国祥.基于Load Runner 的一种性能测试流程方案研究与设 计[J].计算机应用研究，2009，26（11）：4143-4145.
[3] 庄严，程绍银，廉明，等.性能测试在等级测评中的应用[J]计算机应用与 软件，2014，31（7）：55-58.
[4] 李怡，周国祥.基于Load Runner 的一种性能测试流程方案研究与设 计[J].计算机应用研究，2009，26（11）：4143-4145.
[5] 简玲.B/S系统性能测试的设计与实现[J].计算机工程，2009，35（10）：
51-53.
关键词：性能测试；数据处理；场景设计；调优
中图分类号：TP274+.4 文献标识码：A 文章编号：1006-8937（2016）32-0086-02
1 概 述
性能测试是保证软件质量的重要手段，属于软件测试中的系统级测试， 它针对软件在继承系统中运行的性能指标进行测试， 旨在及早确定和消除新系统中的性能瓶颈[1]。
通过负载测试、压力测试等方法的性能测试，测试应用系统能否承受大量的并发用户数以及快速响应用户发送的请求，能否长时间稳定运行。在系统测试期间监控资源、获取性能指标并进行分析，找出系统在硬件、操作系统、数据库、应用软件等方面的性能瓶颈加以改善，使整个系统的性能得到改进优化[2]。
省级集中的一体化营销管理系统服务于全省广大用电客户和适于企业内部管理，具有如下特点：
①在可用性方面，需保证7×24小时不间断运行；
②在业务处理方面，应具海量数据快速处理、复杂业务流转畅顺、资料查询及时响应；
③在系统扩展性方面，需满足多层次应用、地域面积覆盖广、使用人员众多等多方要求。因此，系统的性能测试需要有完整、全面的方案。
为了获取省级集中营销系统性能指标瓶颈，提出改进、优化措施，基于已有成果，本文结合省级集中营销系统的体系结构，在设定具体测试目标基础上，提出了基于海量数据处理的测试场景具体设计原则和监控内容，通过案例分析说明了系统性能调优的具体方法。
2 性能测试概述
性能测试是通过模拟真实环境下的负载，采集系统各方面的性能数据，评估系统正常运行情况下的承受力和稳定性，分析系统的性能与存在的瓶颈。测试方法主要包括负载测试、压力测试、配置测试并发测试和可靠性测试等[3]。在测试过程中，通常需要合理的结合几种测试方法，模拟真实环境，设计不同的测场景获取更多有效的性能指标。
性能测试一般基于如下目的：
①验证系统在给定条件下是否达到设计目标或用户要求；
②探测系统在给定条件下极限处理能力；
③通过对系统各参数的调整，测试系统的最优性能配置；
④通过性能测试发现功能测试难以发现的与性能有关缺陷。
因此，对当前的系统给予相当的负载，并且能够分析系统在给定负载下的表现是实现性能测试的关键。为有效发现负载条件下的各项性能指标，需要筛选分析影响系统的主要测试性能因素，才能做到有的放矢。应用系统性能测试主要包括：响应时间、吞吐量、每秒事务数（TPS）、资源利用率、数据库性能等方面。
在进行性能测试时，需要对系统各个方面（包括系统硬件、操作系统、中间件、数据库等）统一监控，以便进行系统瓶颈的分析与优化。
3 测试方案
省级集中的营销系统为了满足高可用性、高可扩展性和高性能需求，采用了分布式协调服务ZooKeeper和自适配通信环境（ACE）技术构建通用的高性能分布式计算框架；同时，为了满足全省千家万户用电服务、电量电费计量收费的信息支撑服务要求，在系统中存放了海量的用户数据、电网数据，以及系统支持信息。测试场景的设计既要发现系统框架中用户访问的性能瓶颈，又要测试到海量数据处理的反应速度。
3.1 系统结构
基于SOA的多层架构的省级集中系统，在技术路线上采用将表示逻辑、业务逻辑与数据逻辑相分离，客户端支持PC、掌上电脑、手持电脑等设备；接入端通过负载均衡器将用户的访问按照一定的策略分配到不同的服务器群组；应用服务器将展示與运算逻辑分离，而逻辑运算服务组件采用混合模式，针对不同的服务要求采用C或Java来进行开发，以充分利用C语言及Java语言的优势；数据层通过小型机群与存储阵列实现海量数据的存放与访问。
3.2 具体测试目标
评估系统在现有软、硬件环境下可支持业务规模的系统性能。在包括多类业务场景情况下的如下指标：
①访问的平均响应时间；
②访问的最大响应时间；
③平均每秒处理访问数量；
④访问用户的成功率；
⑤规定最大用户并发数下的性能指标。
根据上述量化的指标测试，分析被测营销管理系统在不同并发用户数下的性能指标，找出系统性能瓶颈，提出改善性能方案。
3.3 测试场景设计|
性能测试的用例设计不同于功能测试用例，它只是有针对性地根据系统最可能出现瓶颈的功能点来编写，不需要覆盖整个系统需求[4]。为使性能测试的覆盖率更广泛，性能测试用例的设计需考虑单一场景测试用例和混合场景测试用例的同时存在，性能测试用例中也需考虑并发数、响应时间、持续时间、资源使用情况等关键设计值或者指标值的存在。见表1。
3.3.1 单一场景测试用例
单一场景测试用例（见表1）考察系统对于单一业务的并发处理能力，本次测试选择具有代表性、最核心的9个业务场景，按照实际数据确定并发数。
3.3.2 混合场景测试用例
在性能测试中，常见的错误观点是，认为分别优化单个操作，就能优化系统的整体性能，而事实上系统运行时，不同的操作之间往往对系统资源有互锁关系。为了模拟用户的真实体验，避免性能测试偏重于技术人员的想法，需要综合考虑整个系统的运行情况[5]。省级集中的应用系统中最具有代表性、最核心的9个单一业务场景组合起来则是有代表性、最核心的混合场景的测试用例，见表2。 按照实际数据情况确定并发数。在设计测试场景时，严格按照业务数据的处理关联和顺序，并且为真实模拟实际业务来满足测试的需要。
4 案例测试及分析
性能测试中的测试分析是难点，在应用测试实践中，需要针对具体测试结果进行分析。以下列举本方案中单一登录业务场景的测试及系统性能问题的调优方法和步骤，其中案例所用数据库为Oracle；数据库服务器操作系统为AIX；应用服务器平台为WebLogic。
4.1 测试结果
模拟实际操作员的登陆退出操作的功能，设置1 000并发循环10分钟，测试结果显示登陆的平均事务响应时间为3.139 S，HTTP返回状态全部是HTTP 200状态。
4.2 各测试结果指标分析
①系统响应：在10分钟内运行虚拟用户数一直在1000并发中，平均事务响应时间无特别大的波动，系统在此压力下运行比较稳定。
②在10分钟内每秒点击率图和吞吐量图呈现一致情况，平均每秒吞吐量为14 967 273.462Byte/s=14.27 MB/s，相对于千兆网络不会形成网络瓶颈。
③服务器性能：从Web服务器、Java组件服务器、数据库服务器资源情况来看，Web应用服务器CPU在30%左右，JAVA应用服务器CPU不超过5%，数据库服务器CPU不超过5%，服务器资源运行良好。
從上述结果中我们看到登陆功能压力测试期间运行稳定，各个系统资源没有形成明显的瓶颈。
④问题症结：平均响应时间为3.139 s，不符合要求。针对这种情况，我们对登陆事务进行网页细分进一步查看时间消耗，找到登陆中时间占比最大的页面请求，进一步排查发现登陆功能的页面请求量比较多。
4.3 系统优化
经程序代码排查，简化login.jsp页面请求、压缩grid.js文件组件，提高较大页面组件的执行效率，从而缩短响应时间，提高系统性能。调整后，登陆响应时间满足测试方案需求。
5 结 语
性能测试是应用系统上线前必须经历的过程。系统设计中的任何一个小问题都可能造成严重的性能影响，尤其针对省级集中的系统，一旦出现问题影响范围更大。在性能测试方案中，针对系统特点模拟运行真实的业务场景发现系统架构、系统设计、中间件、数据库、应用服务等各个方面的性能问题，对性能瓶颈有的放矢不断优化调整，使省级集中的营销管理系统达到设计和应用要求，为系统上线打下坚实的技术基础。
参考文献：
[1] 张永祥等.性能测试专家分析系统[J].计算机系统应用，2013，22（4）：6-9.
[2] 李怡，周国祥.基于Load Runner 的一种性能测试流程方案研究与设 计[J].计算机应用研究，2009，26（11）：4143-4145.
[3] 庄严，程绍银，廉明，等.性能测试在等级测评中的应用[J]计算机应用与 软件，2014，31（7）：55-58.
[4] 李怡，周国祥.基于Load Runner 的一种性能测试流程方案研究与设 计[J].计算机应用研究，2009，26（11）：4143-4145.
[5] 简玲.B/S系统性能测试的设计与实现[J].计算机工程，2009，35（10）：
51-53.