省级集中普通发票网络开具系统性能测试研究与实践.doc

省级集中普通发票网络开具系统性能测试研究与实践内容提要：本文介绍了省级集中应用系统性能测试的全过程，对性能测试目标制定、性能测试方法、测试结果分析、性能故障定位等进行了详细分析与研究。通过应用LoadRunner等专用测试工具进行测试与监控，采用单功能单节点并发测试、单功能集群并发测试、混合功能集群并发测试、混合功能疲劳测试等多场景测试方法，对系统关键功能和整体性能进行了严格测试，针对发现的性能问题及时进行了调整优化，到达了性能优化的目标。本文介绍的测试步骤、测试方法、测试结论和结果分析改进等对省级集中应用系统在大数据量、多用户应用有着很强的指导和借鉴作用。关键词：软件测试性能测试测试场景性能优化1引言山东省国家税务局开发的普通发票网络开具系统（以下简称网络开票系统）涉及税务内外和外网应用，系统涉及了应用软件、数据库、中间件、主机、存储、隔离网闸、虚拟机、加密机、F5均衡负载设备等多个组件，使用环境复杂，并具有在线用户量大、实时性、安全性和系统性能要求高等特点，由于系统上线后要面向全省十几万户纳税人在线应用，性能问题是影响应用的主要因素。为保证系统应用效果，上线前我们提前组织对系统性能进行了全面测试，并针对测试发现的问题，优化系统程序和各类参数五十余处，为系统应用打下了坚实的基础。2网络开票系统简介2.1主要功能网络发票是利用信息化手段加强发票管理，解决发票管理问题的有效手段，网络发票代表了发票发展方向，对加大以票控税力度，堵塞税收征管漏洞将起到积极的促进作用。近几年网络发票在国内各地税收征管工作中成为热点话题，同时也成为国家税务总局金税三期工程的创新点之一。修订后的发票管理办法第二十三条明确规定“国家推广使用网络发票管理系统开具发票”，为网络发票的推行做好了制度保障。山东省国税局网络开票系统采用省级数据集中模式，通过互联网在线开具纸质普通发票，纳税人凭税务机关颁发的CA数字证书（存储在U-KEY中）登录系统，在开具发票的同时，将开票信息保存在税务机关服务器中。纳税人端网络开票系统的主要功能有：发票入库校验、内部分配，发票填开、重打、作废，红字发票填开，真伪查询、发票认证，查询统计以及系统维护等功能。网络开票系统引入了用户登录口令、使用U-KEY进行CA数字证书身份认证、数字签名保护、离线时钟控制、安全加密存储、使用国密办指定SSF44税务专用算法、数据加密传输通道SSL安全传输协议控制等安全保护措施，保证了数据安全性和保密性2.2体系结构网络开票系统包含内、外网两个部分，内、外网通过网闸实现硬件安全隔离，系统结构如图1所示。从图看到，系统网络环境复杂，涉及了数据库、应用服务器、F5设备、加密机、防火墙等多个设备与系统，系统测试难度极大。本次测试主要针对网络开票外网纳税人端系统性能，内网由于税务端用户数较少，性能要求相对较低，不作为性能测试的重点。网络开票系统采用J2EE技术B/S/S三层架构，采用struts、spring和hibernate框架进行设计。系统主要硬件设备配置情况：（1）外网应用服务：采用4台虚拟机（4个CPU，8GB内存），每台虚拟机上建立3个weblogic服务，共12个应用节点。（2）内网应用服务：采用2台虚拟机（4个CPU，6GB内存），每个虚拟机上建立2个weblogic服务，共4个应用节点。（3）数据库配置情况：数据库采用两台PC服务器，每台PC服务器配备6个4核CPU，128G内存，存储空间为1.5TB.数据库采用Oracle9i数据库，采用双机RAC模式，保证数据库可靠运行。3软件测试简介软件测试是伴随着软件的产生而产生的，软件危机使得软件测试地位得到大幅提升。软件测试不仅仅是软件开发过程中的一个阶段，它贯穿于整个软件开发过程，成为软件产品质量控制与质量管理的重要手段。软件测试技术作为软件工程学科的一个分支，是保证软件质量和可靠性的关键，是软件开发过程中的一个重要环节。软件测试的核心思想是：对于输入域的特定输入，观察软件的执行结果，验证该结果与期望结果是否一致，然后根据结果作相应的纠错和调整。软件测试研究的结果表明：软件中存在的问题发现越早，其软件开发费用就越低；在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍；软件质量越高，软件发布后的维护费用越低1.据对国际著名IT企业的统计，软件测试费用占整个软件工程所有费用的50%以上。应用软件测试一般包括功能测试、性能测试、安全测试等。一般来说，性能是一种指标，表明软件系统或构件对及时性要求的符合程度；性能是软件产品的一种特性，可以用时间来进行度量2.对不同用户，对软件性能的关注点也不同。从直接体验用户的角度，表现为软件对用户操作的响应时间；在管理员角度，还要关注系统状态，分析系统的可扩展性、并发能力等指标；对于开发人员角度，还需要为软件性能问题进行定位，了解性能的制约因素和引起性能问题的关键原因，即使进行修正等。我们开展的网络开票系统测试对功能、性能与安全都有所兼顾，但测试的重点主要在性能测试方面，重点放在开发人员角度上，对网络开票系统性能进行测试和调优。3.1软件测试工具LoadRunnerLoadRunner是一种预测软件性能的负载测试工具。LoadRunner通过模拟上万用户对被测软件进行操作和请求，能够在测试环境中重现生产环境中可能出现的业务压力，通过测试过程中获取的数据来确认和查找软件性能问题，帮助分析性能瓶颈所在3.LoadRunner的脚本可以录制生成，自动关联，测试场景可以面向指标，多方监控，测试结果可以用图表显示，并且可以拆分组合。它支持广泛的协议和技术，适用于各种体系架构，具有很强的可操作性、适应性和灵活性，是目前广泛应用的软件测试工具。网络发票系统测试采用测试工具LoadRunner 8.1，安装了30台高性能PC做为客户端，把即将应用的正式生产环境作为测试环境，模拟网络开票系统外网和内网用户，组成网络开票系统测试环境。3.2监视方法本测试通过多种方法来监视系统的各个组成部分，如通过nmon程序监视服务器的硬件资源、通过spotlight软件监视oracle的资源、通过WebLogic的控制台监视WebLogic的资源、通过网闸控制台来监控网闸系统的资源、通过VMware的控制台监视VMware虚拟资源、通过LoadRunner监视业务处理情况等。3.3测试方法测试方法的确定是性能测试的关键因素。不同问题在测试中关注的内容不同，为充分了解不同的关注内容，在测试中采用了不同的性能测试方法。本次测试主要采用分功能、分场景的测试方法，主要包括：（1）发票开具、发票查询、发票入库等单功能流程测试；（2）单功能集群并发性能测试，考察关键功能、网闸、F5均衡负载器、WebLogic、Oracle、服务器硬件等性能；（3）对测试中发现的可能存在问题的设备、软件进行专项测试，定位问题，解决问题；（4）多功能混合并发测试，考察整个系统是否存在性能问题，并进行故障定位；（5）模拟系统真实使用场景，进行多功能混合疲劳测试，考察系统长时间连续运行是否存在性能问题，并进行故障定位。在测试过程中，常用的测试方法，黑盒测试、白盒测试、静态测试、动态测试、回归测试等方法，在不同的场景中都有所使用，在此不详细介绍。3.4测试流程本次测试采用性能测试通用模型PTGM（Performance Testing General Model）2，如图2所示，整个测试流程分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析等6个步骤。使用PTGM模型，包括了从“测试团队组建”到“测试分析”的全过程，每个活动都有详细的活动指引和参考模板，具有很强的指导意义，给整个测试带来了方便。4测试分析及测试目标确定4.1测试分析4.1.1用户数网络开票系统的用户数主要包括系统总用户数、高峰期在线人数以及高峰期并发用户数。首先根据全省国税系统近三年纳税人数量情况和变化趋势，确定出系统承载的纳税人用户数量。山东省国税系统近三年开具普通发票的用户数分别是：2007年为13.2万人，2008年12.92万人，2009年12.97万人，我们确定系统用户数大约在13万人左右。其次我们根据系统试点情况，确定实际在线用户数大约为总用户数的13到15分之一，预计高峰时最大在线人数在10000人左右。4.1.2并发用户数系统并发用户数也是我们关注的一个问题。根据参考文献4中的公式，我们对网络开票系统的并发用户数进行了估算。在公式（1）中，C是平均的并发用户数；n是最大在线用户数量；L是用户从登录进入系统到退出系统之间的时间段；T是考察的时间段长度。公式（2）中D则是并发用户数峰值。在网络发票系统中，n的值为10000，绝大多数用户开票的时间一般不会超过15分钟，L的值可以认为是15分钟也就是0.25小时，T的值定义为6小时。根据公式（1）和公式（2），可以得到根据估算可以得到平均并发在线用户数约为417人，峰值为478人，也就说峰值在500人左右。4.1.3数据量普通发票开具数量估算。山东省国税系统最近三年普通发票（剔除收款机发票、定额发票户、企业衔头发票户）的使用数量为：2007年1.41亿张，2008年为1.2亿张，2009年为0.96亿张。考虑到每年开具发票数量变化幅度不会太大，我们确定以每年1亿张发票为发票开具数据量的参考值。4.1.4业务处理要求由于网络开票系统的主要功能是发票填开功能，因此业务处理要求主要指的是对发票填开操作的要求。在一年中，每月按照22个工作日，每天按照8小时计算，得出系统应该满足的平均业务处理能力的要求。根据公式（3）计算得出一年如果开具一亿张发票，每秒平均需要开13.2张发票。下面我们采用两种估算方式估算系统业务峰值。方法1：根据系统使用特点，按照80/20原则估算，即80%的发票是在20%的时间里开具的。同时我们压缩工作时间，每天按6小时计算，计算公式如下：根据公式（4）我们估算出系统峰值大约是每秒开具70张发票方法2：按照国家税务总局测算峰值的估算方法进行估算。业务峰值可以认为是一个月15%的业务集中于一天完成，一天中20%的业务于1小时内完成，这时的业务量就是业务峰值。根据公式（5）我们估算出系统峰值大约是每秒开具69.4张发票根据上述两种业务峰值估算方法，我们得出了一个相同的结论，即网络开票系统业务峰值为每秒最大开票70张左右，并能以该速度持续开具较长时间。4.2测试场景测试场景包括：场景1：进行单功能单节点并发场景测试，考察关键功能、网闸、WebLogic、Oracle、服务器硬件等是否存在性能问题，并进行故障定位和调优；场景2：进行单功能集群并发场景测试，考察关键功能、网闸、F5均衡器、WebLogic、Oracle、服务器硬件等是否存在性能问题，并进行故障定位和调优；场景3：进行混合功能集群并发场景测试，考察混合功能是否存在性能问题，并进行故障定位和调优；场景4：进行混合功能疲劳场景测试，考察系统长时间连续运行是否存在性能问题，并进行故障定位和调优。4.3测试目标根据以上分析，我们确定本次测试的目标是保证网络开票系统能够容纳纳税人数在13万以上，能够满足1万名纳税人登录系统在线开票，能够支持同时500人并发开票，支持每秒持续开具70张发票、保证系统长期无故障运行，能够满足纳税人7天X24小时持续开票要求。5测试问题及解决方法5.1虚拟机在网络开票系统设计初期，数据库与应用服务器都安装在虚拟机上。在测试过程中发现使用虚拟机系统存在以下问题：虚拟机系统的可使用的最大CPU数有限制，最大能够使用8个处理器核心，影响系统的性能以及扩展性；虚拟机系统存在IO读写速度不稳定问题；虚拟机系统存在运行一段时间后系统整体性能下降问题，在数据库方面尤其明显，读写速度在使用过程中会越来越慢，性能下降显著。通过测试发现，虚拟机系统无法满足网络开票系统数据库的性能要求，最终我们应用服务器保留虚拟机不变，数据库重新安装在两台实体机上组成RAC系统。5.2网闸网闸隔离设备是连接内、外网的关键设备，其性能对整个系统性能存在直接影响。通过测试发现网闸存在以下问题：前期，网闸系统采用的是数据库同步的模式。该模式采用的方法是先将数据库数据写入网闸缓冲区，然后从网闸缓冲区写入网闸对端缓冲区，再从对端缓冲区写入对端数据库。测试发现该模式存在的最大的问题就是存在性能瓶颈。这种模式在对数据库进行快速读写操作时，网闸会出现数据丢失问题，长时间运行还会出现网闸死机的现象。最终我们将这种模式更换为数据库接入模式解决了该问题。通过测试发现，网闸系统在建立和释放连接时会占用大量资源，而且网闸最大连接数有限，在测试过程中多次出现了网闸CPU利用率达到100%的情况，此时整个系统速度减慢，达不到设计要求。最终，我们通过减少应用服务器通过网闸系统与数据库的长连接数，使得网闸空闲出更多的资源用于系统应用解决了该问题。5.3应用服务器应用服务器测试是整个系统性能的关键环节，应用服务器采用Weblogic 8.1.4，通过测试发现并解决了以下问题：前期，应用服务器是布置了4个节点，每个节点布置了2个应用。通过测试结果我们发现8个应用并不能达到系统要求，最终每个节点增加了2个应用，总共12个应用。根据测试结果，调整Weblogic部分参数，如线程池最大线程数、数据库连接池最大连接数、TCP连接缓存数等，提高Weblogic处理能力；5.4应用软件通过测试，网路开票程序发现并解决了以下问题：系统登录速度慢问题。经分析发现登录的响应时间主要消耗在网络传输上。由于系统采用了EXT框架，框架较大（500多KB），框架下载时间较长，影响登录响应时间。最终通过优化了程序结构，解决了该问题。多用户并发时出现大量开票失败情况。经分析，每个并发用户获取的开票验证码错误，出现验证码混乱现象，即A的验证码发送给B现象。根据以上分析，调整发票填开的验证码分发方式，由F5负责分发调整为各节点负责分发，解决了该问题。开具查询模块测试时发现出错现象。分析后发现由于EXT框架超时时间设置太小，大量并发查询时出现大量错误。调整EXT框架超时时间，解决该问题。测试发现原程序中部分数据库操作语句不合理，影响系统性能。通过修改程序，解决了该问题。系统长期运行时出现应用服务器节点宕机现象。通过排查，发现通过Thread dump，发现存在线程阻塞现象：“Blocked trying to get lock： org/hibernagte/util/ softlimitMRUCache”。通过分析，发现是Hibernate的版本问题造成的。本系统采用hibernate3.0，根据官方网站说明，3.0版本存在上述的bug，推荐换成3.1.3版本或者3.2.0版本。升级版本后，问题解决。5.5其他除上述几点，我们还对发现的下述问题进行了处理：修改数据库参数配置，提高数据库处理性能。增加部分数据表索引，提高数据库查询性能。修改F5配置，使得F5能够支持SSL安全传输协议。修改加密代理程序，解决大量并发加密时部分加密出错问题在多个加密代理程序前，增加F5设备，实行自动分配，提高加密代理性能。6测试结果下面以三个混合场景测试为例，介绍测试结果和测试结论。6.1混合功能并发测试混合功能并发测试中，并发用户数为500、1000、1500、2000进行测试，测试时间为10分钟，各功能分配比例为单机登录3%，发票入库3%，发票填开85%，发票真伪鉴定3%，开具查询3%，开具明细查询3%。并发测试中思考时间和操作间隔时间都为0。从并发测试可以得出结论，500个并发时系统性能最佳，除登录平均时间稍长外，其余各项指标都能满足要求。当2000用户并发开票时系统速度下降已经非常明显，整个系统接近满负荷运行。测试结果显示系统可以支持500用户并发，达到每秒开具70张发票的设计要求。6.2混合功能在线测试混合功能在线测试中，进行1万用户、1.2万用户和1.5万用户测试，测试时间为10分钟，各功能分配比例同混合功能并发测试。思考时间20秒和操作间隔时间60-300秒程序随机选择。混合功能在线测试模拟现实用户的使用情况，测试结果显示可以支持到15000个用户在线开票。这里与并发测试的区别在于并发是指用户登录后不断的进行各种操作，不断地提出各种请求，现实中用户登录后并不会这样并发操作，用户会有间隔的进行操作，混合测试模拟现实用户，