（计算机科学与技术专业论文）软件性能测试在税收征管信息系统中的应用研究.pdf

摘要 摘要 软件测试是软件开发的重要环节，贯穿于软件过程的始终，是一贯科学的 质量控制的过程。税收征管信息系统( 简称c t a i s ) 是以划清征纳双方法律责任、 规范税务机关执法行为，建立并实现税收征管各相关业务环节的制约监控机制， 规范纳税服务及各项工作秩序和权限，以计算机网络为依托，提高依法治税的 力度，实现信息高度共享的计算机信息管理系统。 本文介绍了软件性能测试的全过程，并且运用软件工程理论结合实际，提 密了一种通用的软件性能测试过程模型( p t g m ) ，将软件性能测试过程分为测 试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以 及测试分析等阶段，并对每个阶段进行了阐述，并结合税收征管信息系统的测 试实例对p t g m 模型进行了具体的设计实施。最后，根据测试结果，提出了一 些实用性的改进方法。 关键词：性能测试，c t a i s ，过程模型 a b s t r a c t t h es o f t w a r et e s t i n gi st h ei m p o r t a n tl i n ko ft h es o f t w a r ed e v e l o p m e n t ，p i e r c e t h r o u g hi sa l w a y si nt h es o f t w a r ep r o c e s s ，i st h ep r o c e s so ft h eq u a n t i t yc o n t r o lo f c o n s i s t e n ts c i e n c e t h er e v e n u ef r o mt a xa d v e r t i s e sf o rt ot a k ec a r eo ft h ei n f o r m a t i o n s y s t e m ( t h eb r i e fn a m ec t a i s ) t oa d v e r t i s ef o rb ym a k eac l e a rd i s t i n c t i o nt h eb o t h p a r t i e s l a wr e s p o n s i b i l i t y ，t h en o r mt a xo f f i c et oe n f o r c et h el a wt h eb e h a v i o r ， b u i l d i n gu pc a r r y i n go u tt h ec h e c ka n ds u p e r v i s i o ns u p e r v i s i o nm e c h a n i s mt h a tt h e r e v e n u ef r o mt a xa d v e r t i s e sf o re a c hr e l a t e db u s i n e s sl i n ko ft u b ea l s o ，t h en o r mp a y s t a xs e r v i c ea n dv a r i o u sw o r ko r d e r sa n dl e g a lp o w e r s ，t a k i n gt h ec a l e f i l a t o rn e t w o r ka s t or e l yo n , r a i s i n gt h es t r e n g t ho fc u r et h et a xb yl a w ，c a r r yo u t t h ec a l c u l a t o r i n f o r m a t i o n m a n a g e m e n ts y s t e mt h a tt h ei n f o r m a t i o ns h a r e sh i g h l y t h i st e x ti n t r o d u c e dt h ew h o l ep r o c e s so ft h es o f t w a r ep e r f o r m a n c et e s t ，a n d m a k eu s eo ft h es o f t w a r ee n g i n e e r i n gt h e o r i e st oc o m b i n ep h y s i c a l l y ，p u tf o r w a r da k i n do fi ng e n e r a lu s es o f t w a r ep e r f o r m a n c et e s tp r o c e s sm o d e l ( p t g m ) ，l e a dt h e s o f t w a r ep e r f o r m a n c et e s tp r o c e s sb e f o r e i s i n gd i v i d e di n t ot h t e s te x p e c tt h e p r e p a r a t i o n ，t h et e s tt o o li n t o ，t h et e s tp l a n ，t h et e s td e s i g na n dd e v e l o p m e n t ，t h et e s t p e r f o r m a n c e sa n ds t a g e ss u c ha sm a n a g e m e n ta n dt h e t e s ta n a l y s i se t c ，a n dc a r r i e do n t oe l a b o r a t et oe a c hs t a g e ，a n dc o m b i n e dt h es o l i de x a m p l eo ft h et e s tt h a tt h er e v e n u e f r o mt a xa d v e r t i s e df o rt ot a k ec a r eo ft h ei n f o r m a t i o ns y s t e mt oc a r r i e do nt h e c o n c r e t ed e s i g ni m p l e m e n tt ot h em o d e lo fp t g m t h ee n d ，a c c o r d i n gt ot h et e s ta sa r e s u l t ，p u tf o r w a r dt h ei m p r o v e m e n tm e t h o do f s o m ef u n c t i o n k e y w o r d s ：p e r f o r m a n c et e s t ，c t a i s ，p r o c e s sm o d e l i i 学位论文版权使用授权书 本人完全了解同济大学关于收集、保存、使用学位论文的规定， 同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版 本；学校有权保存学位论文的e p , 届u 本和电子版，并采用影印、缩印、 扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提 供本学位论文全文或者部分的阅览服务；学校有权按有关规定向国 家有关部门或者机构送交论文的复印件和电子版；在不以赢利为目 的的前提下，学校可以适当复制论文的部分或全部内容用于学术活 动。 学位论文作者签名：了咖饥彳 w 蜃年 月tp 日 经指导教师同意，本学位论文属于保密，在年解密后适用 本授权书。 指导教师签名： 年月日 学位论文作者签名：t 似厶叶 年? 月，oe l 同济大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进 行研究工作所取得的成果。除文中已经注明引用的内容外，本学位 论文的研究成果不包含任何他人创作的、己公开发表或者没有公开 发表的作品的内容。对本论文所涉及的研究工作做出贡献的其他个 人和集体，均已在文中以明确方式标明。本学位论文原创性声明的 法律责任由本人承担。 签名：f 希州印 矿售。年予月i 日 第1 章绪论 1 1 选题背景及意义 第1 章绪论 大多数的测试工程师对“性能测试”这个名词并不陌生，即使他们没有真正参 与过性能测试项目，在各个论坛或网站上也很容易发现这个名词。然而，究竟什 么是软件性能? 软件性能测试究竟该如何开展? 软件性能测试到底测试些什 么? 这些问题恐怕就不是每个测试工程师都能清楚地回答的了。 其实，在日常工作中，每个测试工程师基本上都会遇到与软件性能、软件性 能测试相关的内容。在我们接触到的用户需求中，经常会有类似如下的描述：“要 求某某系统对用户的操作能快速反应”，“要求某某系统能够在大量用户同时使用 时保持稳定运行”，等等。实际上，这些就是用户对我们的软件系统提出的朴素 的性能要求，虽然这些性能要求不是那么显而易见，在实际的测试中也可能会被 忽略，但无论如何，这些描述至少说明了性能要求其实是大部分用户对软件系统 的一个基本要求。 从世界上第一台计算机诞生开始算起，软件的存在已经有相当时间的历史 了。仅仅回忆一下十多年前，我们就会发现，在以前的d o s 时代，甚至是w i n d o w s 9 5 的时代，好像很少能听到对软件性能的抱怨，但在近几年，为什么对软件性 能的关注突然变得强烈起来了呢? 这种变化究竟是什么原因造成的呢? 在d o s 和w i n d o w s9 5 的时代，我们接触到的大量的应用都是单机的应用， 对这些应用，其实也存在性能方面的要求( 想想看，我们是不是曾经因为某个游 戏运行不流畅或单击了i d e 工具的“编译”命令后需要等待1 0 分钟甚至更长时 间而抱怨自己的机器? ) 。但对这类单机应用来说，程序运行的速度基本上只与 运行程序的本机相关，因此，只需要简单地更换运行程序的设备就能很好地解决 这个问题。所以，虽然用户会觉得程序运行速度慢，但由此引起的抱怨一般都会 直接针对无辜的计算机设备和自己不争气的钱包，而不会瞄准运行得慢的软件。 而近几年来，随着软件系统规模和复杂程度的增加，我们接触到的系统( o a 系 统、信息管理系统等) 都变得越来越巨大，在结构上，这些系统大多采用c s 或 b s 架构，采用多种分布式应用技术，具有几百、几千甚至上万的用户数量。由 于其采用的是c s 或b s 架构，大量的运算和处理都被放到服务端来实现，这 种变化使得软件系统的性能影响因素变得庞杂，很难通过简单的更换设备来解 决。这时，采用类似单机时代的“更换更好的设备”无论从经济性还是可实现性的 角度来考虑，都完全不能满足需要；在这个时候，对性能的关注才越来越多地集 1 第1 章绪论 中在应用系统本身，而不仪仅是运行系统的设备上。 软件性熊和软件性能测试的复杂性是显丽易见的。与一个软件系统静性能表 现的相关因素非常多，网络环境、数据库服务器、应用服务器、业务逻辑的实现 方式、系统采用的架构、代码优化的程度、使用者的使用方式都会对系统的性能 表现造成影响。 1 2 国内外发展现状 软件测试技术的发展与软件技术的发震是密切相关的。隧着软俘和软件技术 的复杂程度越来越高，人们对于软件测试的认识也随之提高到一个新的水平。2 0 世纪7 0 年代以来，国内外许多学者和组织在软件测试方面进行了大量的研究工 作，形成许多经典的软件测试技术和软件测试流程管理规范。 随着我国国民经济信息化迅速发展，软件产品质量已成为开发商和用户关注 的焦点。我国软件产品测试技术研究起步于“六五”期阆，僵入力、物力不足，因 此与国际先进水平差距较大，难以满足现代化要求。根据软件工程原理和国内外 实践中成功企业和项西经验，软件产品测试的经济规模至少占软件产业顼蟊的 3 0 5 0 ，而耳前我国只占3 1 0 左右。我国专门从事软件测试技术研究的单位 只有中国软件评测中心、北京航空航天大学软件工程研究所、国防科工委系统所 和西北工业大学等几家，研制了一系列的程序理解工具和测试工具，比较具有代 表性的工具有s a f e p r oc c ，s a f e p r o j a v a 。航空计算机研究所、南京大学在嵌 入式系统测试方面进行较多工 乍，开发了一些静态分毒厅工具和测试用侧邕动生成 工具。西北工业大学在航空软件仿真测试、并行软件综合测试平台以及c s 系统 的测试方面进行许多研究工作并取得了一系列成果。 国外的软件测试发展迅速，市场繁荣。美困的1 e e e ，a c m 等组织制定了 一系列软件测试规范，国外的许多大学( 如c a r n e g i em e l l o n ，g e o r g em o s a n 等) 、 研究机构( 如：n a t i o n a ls o f t w a r et e s t i n gl a b 等) 和公司( 如：s o f t w a r er e s e a r c h , r a t i o n a lc o r p o r a t i o n ，l d r a 以及a u t o t e s t e r 等) 进行了大量软件测试的研究和应 用工作。其中c a r n e g i em e l l o n 大学侧重予回归测试和c l i e n t s e r v e r 测试技术的 研究，g e o r g em o s a n 侧重于基于规范的测试自动生成和面向对象测试技术的研 究，n s t l 主要从事测试规范和标准的制定。比较流行的软件测试工具集有 s o f t w a r er e s e a r c h 的t e s t w o r k s ，r a t i o n a l 的r a t i o n a lr o s e 9 8 , m e r c u r y i n t e r a c t i v e 的w i n r u n n e r x r u n n e r , l d r a 的t e s t b e d 等。 基前性能测试存在的阉题： 1 测试准备不充分，测试目标不明确，测试计划不详细； 2 缺乏测试以及针对测试对象蕊技术储备； 2 第1 章绪论 3 测试环境的稳定性及前后一致性不足； 4 测试数据精确性和代表性不足； 5 测试描述不精练。 1 3 税收征管信息系统简介 中国税收征管信息系统( c h i n at a x a t i o na d m i n i s t r a t i o n i n f o r m a t i o ns y s t e m ) ，简称c t a i s 。c t a i s 是以国家税务总局编写的税 收征管业务规程和市局级税收征管业务需求为基准，由国家税务总局与联 想神州数码公司联合开发的适用于全国各级税务机关的统一的征管软件。c t a i s 的开发是为了配合我国不断深入的税收征管改革，通过统一的税收征管软件来规 范税收征管行为，它将在全国各级税务机关建立一个统一的、全面的、严密的、 科学的税收监控体系。通过c t a i s 系统的应用，将大大提高税务系统的征收管 理水平，逐步实现全国税收的现代化管理。 1 、c t 越s 系统功能： c t a i s 是一个应尉于全国各地税收征管的大型软件，共有七个子系统，其 中六个是业务子系统，一个是系统维护。每个子系统都设有若干模块、子模块， 覆盖了绝大部分税收征管业务。具体包括： 管理服务子系统。主要处理税务登记、一般纳税人认定、发票管理、减 免退税、核定税额、增值税专用发票交叉稽核、信息采集、待批文书、 证件管理、资料管理、档案管理等业务。 征收监控子系统。主要处理申报征收、稽核评税、税收计划、税收会计、 税收统计、票证管理等业务。 税务稽查子系统。主要处理稽查选案、稽查实施、稽查审理、稽查案卷 管理等业务。 税收法制子系统。主要处理违法违章处罚、税务行政复议、行政诉讼、 行政赔偿等业务。 税务执行子系统。主要处理税务文书送达、税收一般执行、保全、强制 执行等业务。 市局业务级系统。主要处理税务机关征管质量考核、分析监控、统计查 询、报表管理等业务。 系统维护子系统。主要负责各项业务的维护管理。 2 、c t a i s 系统特点： c t a i s 系统是以划清征纳双方法律责任、规范税务机关执法行为，建立并 3 第1 章绪论 实现税收征管各相关业务环节的制约监控机制，规范纳税服务及各项工作秩序和 权限，以计算机臃络为依托，提高依法治税的力度，实现信息高度共享的计算机 信息管理系统。主要有如下特点： 规范性。该系统严格遵循中华人民共和国税收征收管理法和税收法律、 法规、规章、制度的要求，严格按照国家税务总局编写的税收征管业务 规程和表证单书而开发的。程序编码、软件界面及文档用语都遵循规范 化和标准化的要求，统一了税收征管业务规程、办税程序，规范了税务文 书，明确职责，创建了专业化的人员分工组合、相互制约的运行机制，改 变过去办事中的随意性、变通性。 妫全面性。该系统覆盖了绝大部分税收征管业务，不是一时一地的、一般性 的业务内容。另外还考虑了一些地区的特殊业务需求。 鸪监控性。该系统将税务登记、发票管理、待批文书、证件管理、资料管理、 档案管理、信息采集、申报征收、稽核评税、稽查管理、税收法治、税务 执行、行政复议、行政诉讼、行政菇偿等征管业务融为一体，环环相扣， 建立了全面而灵活的监控体系。使得所有的业务操作都能及时地得到反映 和追踪。如该系统的违法违章管理模块，可以登记并处理征管业务各个环 节所发生的违法违章信息，为税收征管业务提供了多项计算机自动监控手 段。该系统可以全面采集纳税人信息数据，全面处理征管业务，保证了征 管行为的实时监控，为征篱质量的提高起到了有力的支持。 d ) 数据共享性。纳税人几乎所有的涉税原始数据都可以直接录入，形成了税 收征管所必需的、完整的、系统的基础数据信息。无论是具体经办人员还 是上级领导都能及时查询到工作所需的纳税人信息数据，初步实现了征管 信息的共享。 e ) 优化性。根据c t a i s 和国家税务总局制定的税收征管业务规程的要 求，我局结合机构改革、征管改革方案，对税务机构设置、工作职责划分、 陡位权限设置进行了重新调整稆完善，拟订了新的深圳市国家税务局岗 责体系，实现了税收征管业务流程的重组。迸一步优化了税收征管组织， 建立较为科学、规范和有效制约的岗责体系，提高办税效率，推进依法治 税，最大限度地方便了纳税人。 l 。4 论文的研究内容及主要王作 本课题研究主要目的是结合税收征管信息系统的性能测试能够比较系统、详 尽地对软件性能测试过程作一个细致的研究，并且运用软件工程理论结合实际， 4 第1 章绪论 提出一些实用性的改进方法，将软件性能测试工作做到更好。 本文的主要工作大致分为以下几点： ( 1 ) 介绍软件性能测试的基本概念，性能测试的方法和工具； ( 2 ) 通过分析研究软件性能测试过程，提出一种较全面的软件性能测试模型 ( p t g m ) ，将软件性能测试过程分为测试前期准备、测试工具引入、测试计划、 测试设计与开发、测试执行和管理以及测试分析等阶段，进行合理的设计安排； ( 3 ) 结合p t g m 软件性能测试模型，设计实施了税收征管信息系统的性能测 试方案； ( 4 ) 根据测试结果，提出测试过程中需要改进的地方。 1 5 论文的组织安排 本文介绍了软件性能测试的全过程，提出了一种通用的过程模型p t g m ，并 结合税收征管信息系统的实例展示了如何在软件性能测试的过程中应用该模型。 本文共分6 章，其后续章节内容安排如下 第2 章，首先介绍软件性能测试的一些相关基本概念，并对并发用户数、 响应时间、吞吐量等软件性能测试中常见术语进行详细解释和描述，重点阐述软 件性能测试的方法。 第3 章，介绍性能测试的过程模型及其测试工具，提出通用的性能测试过 程模型p t g m ，并详细描述该模型的各个阶段以及每个阶段的活动。 第4 章，结合p t g m 软件性能测试模型，设计了税收征管信息系统的性能 测试方案。 第5 章，具体实施税收征管信息系统的性能测试。 最后一章给出本文工作的总结，并且指出进一步的工作。 5 第2 章软件性熊测试的相关理论 第2 章软件性能测试的相关理论 2 。1 软件性能测试的概念 软件性能是指软件系统或构件对于其及时性要求的符合程度，是软件产品的 种特性，可以用时间或者吞吐量等指标来进行度量。 对于单个事务，响应时间就是完成事务所霈的时闻；对于用户任务，响应时 间体现为端到端的时间。比如，“用户单击o k 按钮后2 秒内收到结果”就是 个对用户任务响应时闻的描述，具体到这个用户任务中，可能有多个具体的事务 需要完成，每个事务都有其单独的响应时间。 对交互式的应用( 例如典型的w e b 应用) 来说，我们一般以用户感受到的 响应时间来描述系统的性能，两对非交互式应用( 嵌入式系统或是银行等的业务 处理系统) 而言，响应时间是指系统对事件产生响应所需要的时间。 软件性熊测试主要是通过模拟多种正常、峰值以及异常负载条件来对系统的 各项性能指标进行测试，网的是验证软件系统是否能够达到用户提出的性能指 标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。 主要包括以下几个方面： 1 评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所 计划的模型的能力，并帮助侔出决策。 2 识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破 它，从而修复体系的瓶颈或薄弱的地方。 3 系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从 而改进性能。检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄 露引起的失败，揭示程序中的隐含的问题或冲突。 4 验证稳定性( r e s i l i e n c e ) 可靠性( r e l i a b i l i t y ) ：在一个生产负荷下执行测 试一定的时阕是评信系统稳定性和可靠性是否满足要求的瞧一方法。 2 2 软件性能测试的主要指标 软件性能测试的主要指标包括：响应时间、并发用户数、吞吐量、性能计数 器等。 6 第2 章软件性能测试的相关理论 2 2 1 响应时间 响应时间是“对请求作出响应所需要的时间”。而“系统响应时间”指应用系统 从请求发出开始到客户端接收到数据所消耗的时间。 响应时间可以被进一步分解。图2 1 描述了一个w e b 应用的页面响应时间 的构成。从图中可以看到，页面的响应时间可被分解为“网络传输时间” ( n i + n 2 + n 3 + n 4 ) 和“应用延迟时间”( a 1 + a 2 + a 3 ) ，而“应用延迟时间”又可以 分解为“数据库延迟时间”( a 2 ) 和“应用服务器延迟时间”( a l + a 3 ) 。之所以要 对响应时间进行这些分解，主要目的是为了能更好定位性能瓶颈的所在。 图2 1w e b 应用的页面响应时间分解 关于响应时间，要特别说明的一点是，响应时间的“长”和“短”没有绝对的区 别。 例如，对一个电子商务网站来说，在美国和欧洲，一个普遍被接受的响应时 间标准为2 5 1 0 秒，也就是说，在2 秒之内给客户响应被用户认为是“非常有吸 引力的”，在5 秒之内响应客户被认为是“比较不错的”，而1 0 秒是客户能接受 的响应的上限。 但考虑一个税务报账系统，该系统的用户每月使用一次该系统，一次花费2 小时以上进行数据的录入，当用户单击“提交”按钮后，即使系统在2 0 分钟后才 给出“处理成功”的消息，用户仍然不会认为该系统的响应时间不能接受毕 竟，相对于一个月才进行一次的操作来说，2 0 分钟确实是一个可以接受的等待 时间。 因此，在进行性能测试时，“合理的响应时间”取决于实际的用户需求，而不 能依据测试人员自己的设想来决定。 2 2 2 并发用户数 并发用户数是指在同一个时间段内访问系统的用户数量，通常用于从业务的 角度模拟真实的用户访问，体现的是业务并发用户数。性能测试的一个目标是验 证当前系统能否支持现有用户的访问，最好的办法就是弄清楚会有多少用户会在 同一个时间段内访问被测试的系统，如果使用性能测试工具模拟出与系统的访问 7 第2 章软件性能测试的相关理论 用户数相同的用户，并模拟用户的行为，那得到的测试结果就能够真实反映实际 用户访闯时的系统性能表现，也就能够逶过性麓测试了解到当系统处于实际用户 访问时，会具有怎样的性能表现。 在实际的性能测试中，经常接触到的与并发用户数相关豹概念还包括“并发 用户数”、“系统用户数”和“同时在线用户人数”。测试人员一般比较关心的是业 务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，为 了方便，直接将业务并发嗣户数称为著发用户数。 用于估算并发用户数的公式， c ：n l ( 1 ) r 一 c = c + 3 e( 2 ) 在公式( 1 ) 中，c 是平均的并发用户数；n 是l o g i ns e s s i o n 的数量；l 是 l o g i ns e s s i o n 的平均长度；t 指考察的时间段长度。例如，对一个典型的o a 应 用，考察的时间段长度应该为8 小时的工作时间。 公式( 2 ) 则给出了并发用户数峰值的计算方式，其中，c 指并发用户数的 峰值，c 就是公式( 1 ) 孛得到麴平均的并发用户数。该公式的缮穗是假设用户 的l o g i ns e s s i o n 产生符合泊松分布而估算得到的。 基于公式( i ) ( 2 ) 的细化，可以更精确地计算得到并发用户数： ( 1 ) 以更细的时间粒度进行考察：例如，可以设定1 个小时为考察时间的 粒度，对一个典型的o a 系统，将一天的上班时间划分为8 个区间。 ( 2 ) 考虑典型的业务模式：不同的应用有不同的业务模式，例如，一个恣 部系统一般在上班开始后的3 0 分钟至1 个小时集中出现用户的登录；一个账务 系统在每月的结账西前凡天会比较繁忙；一个门户网站在重大消息发布豹翁后会 有访问高峰；一个旅游的网站在节假日前夕会有大量用户的访问因此，在考 虑计算并发用户数时，可以结合应用的业务模式，多考虑一些可能发生的场景， 基于这些场景进行估算。 也可以采取“日志分析”方法是指通过对应用服务器的日志进行分析，从而了 解系统用户的使用状态，从基志中计算蹬“服务器承受的最大并发用户访问数” 数据。这种方式得到的数据准确度和可信度都比较高，对于i n t e m e t 应用等无法 估计用户数量和用户行为模式的应用，这种方式最为可信。“舀志分析”的方法需 要日志分析工具的支持，这里推荐a w s t a t s 开源工具 2 。2 3 吞吐量 吞吐量是指“单位时间内系统处理的客户请求的数量”，。直接体现软件系统的 8 第2 章软件性能测试的相关理论 性能承载能力。一般来说，吞吐量用请求数秒或是页面数秒来衡量，从业务的 角度，吞吐量也可以用访问人数天或是处理的业务数j 、时等单位来衡量。当然， 从网络的角度来说，也可以用字节数天来考察网络流量。 以不同方式表达的吞吐量可以说明不同层次的问题。例如，以字节数秒方 式表示的吞吐量主要受网络基础设施、服务器架构、应用服务器制约；以单击数 秒方式表示的吞吐量主要受应用服务器和应用代码的制约。 作为性能测试时的主要关注指标，吞吐量和并发用户数之间存在一定的联 系。在没有遇到性能瓶颈的时候，吞吐量可以采用如下公式计算： f ：n v u x r( 3 ) r 其中，f 表示吞吐量；n v u 表示v u ( v i r t u a eu s e r ，虚拟用户) 的个数；r 表示每个v u 发出的请求( 单击) 数量；t 表示性能测试所用的时间。但如果 遇到了性能瓶颈，此时吞吐量和v u 数量之间就不再符合公式( 3 ) 给出的关系。 常用于分析吞吐量的图形是“吞吐量v u 数量”的关联图。图2 - 2 给出了 两个“吞吐量- ，数量”关联图的示例。 从图中可以看到，吞吐量在v u 数量增长到一定程度的时候产生了性能瓶 颈。 最后，虽然吞吐量指标可被看作是系统承受压力的体现，但在不同并发用户 数量的情况下，对同一个系统施加相同的吞吐量压力，很可能会得到不同的测试 结果。 ，。i 痧、叠爨燮； ： 。巅 。嘭猡； j 季 ! t l i 黟 ： l 铲 2 2 4 性能计数器 一 。囊赡2 汰! 羹童 。j 蛩：弋鬟7 甏；尹妒 q ”2 * t 鑫3 、 张”： “ 峨 图2 2吞吐量- i 数量”关联图示例 性能计数器( c o u n t e r ) 是描述服务器或操作系统性能的一些数据指标。例 如，对w i n d o w s 系统来说，使用内存数( m e m o r yi nu s a g e ) ，进程时间( t o t a l p r o c e s st i m e ) 等都是常见的计数器。 计数器在性能测试中发挥着“监控和分析”的关键作用，尤其是在分析系统的 可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。但必须说明 的是，单一的性能计数器只能体现系统性能的某一个方面，对性能测试结果的分 9 第2 章软件性能测试的相关理论 析必须基于多个不同的计数器。 与性能计数器相关的另一个术语是“资源利用率”。该术语指的是系统各种资 源的使用状况。为了方便比较，一般用“资源的实际使用总的资源可用量”形成 资源利用率的数据，用以进行各种资源使用的比较。 在性能测试中常用资源利用率进行横向的对比，例如，在进行测试时会发现， 资源a 的使用率达到了接近1 0 0 的数值，而其他的资源利用率都处于比较低的 水平，则可以很清楚地知道，资源a 就很有可能是系统的一个性能瓶颈。当然， 资源利用率在通常的情况下需要结合响应时间变化曲线、系统负载曲线等各种指 标进行分析。 2 2 5 思考时间 思考时间( t h i n kt i m e ) ，也被称为“休眠时间”，从业务的角度来说，这个时 间指的是用户在进行操作时，每个请求之间的间隔时间。 在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。不同 的测试工具提供了不同的函数或者方法来实现思考时间。 在实际的测试中，设置多长的思考时间与迭代次数、并发用户数和吞吐量之 间存在一定的关系。公式( 3 ) 说明吞吐量是v u 数量n v u 、每个用户发出请求 数r 和时间t 的函数，而其中的r 又可以用时间t 和用户的思考时间t s 来 计算： r ：三( 4 ) 丁， 用公式( 3 ) 和公式( 4 ) 进行化简运算可得，吞吐量与n v u 成正比，而与 t s 成反比。 计算思考时间的一般步骤： 1 首先计算出系统的并发用户数； 2 统计出系统平均的吞吐量； 3 统计出平均每个用户发出的请求数量； 4 根据公式( 4 ) 计算出思考时间。 当然，为了让性能测试场景更加符合实际情况，可以考虑以步骤4 计算得 出的思考时间为基准，让实际的思考时间在一定幅度内随机变动。l o a d r u n n e r 和 s e g u es i l kp e r f o r m e r 等工具都支持以这种方式设置思考时间。 1 0 第2 章软件性能测试的相关理论 2 3 常用性能测试方法 2 3 1 性能测试 性能测试( p e r f o r m a n c et e s t i n g ) 方法是通过模拟生产运行的业务压力量和使 用场景组合，测试系统的性能是否满足生产性能的要求。 这种方法的特点： ( 1 ) 主要目的是验证系统是否有系统宣称具有的能力。p e r f o r m a n c et e s t i n g 方法包括确定用户场景、给出需要关注的性能指标、测试执行和测试分析等步骤， 是一种完全确定了系统运行环境和测试行为的测试方法，其目的是依据事先的性 能规划，验证系统有没有达到其宣称具有的能力。 ( 2 ) 需要事先了解被测试系统的典型场景，并具有确定的性能目标。所谓 典型场景是指具有代表性的用户业务操作，一个典型场景包括操作序列、并发用 户数量条件。其次，这种方法需要有确定的性能目标，性能目标的描述基本上是 这样的。 ( 3 ) 要求在已确定的环境下运行。软件系统的性能表现与非常多的因素相 关，无法根据系统在一个环境上的表现去推断其在另一个不同环境中的表现，因 此必须要求测试环境( 包括硬件设备、软件环境、网络条件、基础数据) 都已经 确定。 2 3 2 负载测试 负载测试( l o a dt e s i n g ) 方法通过在被测试系统上不断增加压力，直到性能 指标超过预定指标或某种资源使用已经达到饱和状态。 通过这种测试方法可以找到系统的处理极限，为系统调优提供数据。也称为 可量性测试( s c a l a b i l i t yt e s t i n g ) 。该方法特点： ( 1 ) 主要目的是找到系统处理能力的极限。通过“检测加压直到性 能指标超过预期”的手段，其主要目的是找到系统处理能力的极限。 ( 2 ) 需要在给定的测试环境下进行，要考虑被测系统的业务压力量和典型 场景，使测试结果具有业务意义。 ( 3 ) 一般用来了解系统的性能容量，配合性能调优使用。 2 3 3 压力测试 压力测试( s t r e s st e s t i n g ) 方法测试系统在一定饱和状态下，系统能够处理 第2 章软件性能测试的相关理论 的会话能力，以及系统是否会出现错误。 特点： ( 1 ) 主要目的是检查系统处于压力情况下时，廒用的表现。s t r e s st e s t i n g 通过增加访问压力，使应用系统资源使用保持在一定水平，检验此时的应用表现， 重点在与有无崽错信息产生，系统对应瘸的响应时间等。 ( 2 ) 一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。可 以对c p u 和内存使潮率、j v m 的可用蠹存、数据库连接数、数据库服务器c p u 利用率等作为设定压力依据。 ( 3 ) 用于测试系统的稳定性。 2 3 4 配置测试 配置测试( c o n f i g u r a t i o nt e s t i n g ) 方法通过对被测系统的软硬件环境的调优， 了解各种不同环境下对系统性能影响的程度，从而找到系统备项资源的最优分配 原则。 特点： ( 1 ) 主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最 值得进行的调优操作。 ( 2 ) 一般在对系统性能状况有初步了解后进行。c o n f i g u r a t i o nt e s t i n g 方法 需要在确定的环境和步骤、确定的压力条件下进行。在每次执行测试时更换、扩 充硬件设备，调整网络环境，调整应用服务器和数据库服务器的参数设置，比较 每次测试结果，确定各个因素对系统性能的影响，找出影响最大的因素。 ( 3 ) 一般用于性能调优和规划能力。 2 3 5 并发测试 并发测试( c o n c u r r e n c yt e s t i n g ) 方法透过模拟用户的并发访闻，测试多用 户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能 问题。 特点： ( 1 ) 主要目的是发现系统中可能隐藏的并发访问时的问题。c o n c u r r e n c y t e s t i n g 方法是逶过并发的手段发现系统中存在问题的最常见方法。 ( 2 ) 主要关注系统中可能存在的并发问题，如系统中的内存泄漏、线程锁 和资源争用的阏题。 表2 1 并发测试主要关注的问题 1 2 第2 章软件性能测试的相关理论 问题类别问题描述 是否有内存泄漏 内存问题是否有太多的临时对象 是否有太多的超过设计生命周期的对象 是否有数据库死锁 数据库问题 是否经常出现长事务 线程问题是否出现线程进度同步失败 是否出现资源争用导致的死锁 其他问题 是否没有正确处理异常导致系统死锁 ( 3 ) 可在开发的各个阶段使用，需要相关的测试工具的配合和支持。 2 3 6 可靠性测试 可靠性测试( r e l i a b i l i t yt e s t i n g ) 方法通过给系统加载一定的业务压力的情 况下，让应用持续一段时间，测试系统在这种条件下是否能够稳定运行。 特点： ( 1 ) 主要目的是验证系统是否支持长期稳定的运行。在大的压力下进行一 个较长时间的测试，如果系统在测试中不出现问题或是不好的征兆，基本上可以 说明系统具备长期稳定运行的条件。 ( 2 ) 需要在压力下维持一段时间的运行。时间的具体数值根据系统稳定性 要求确定。 ( 3 ) 测试过程中需要关注系统的运行状况。在运行过程中，要关注系统内 存使用状况，系统的其他资源使用有无明显的变化，以及系统响应时间有无明显 变化。 1 3 第3 章性能测试的过程模型及其测试工具 第3 章性能测试的过程模型及其测试工具 本文提出了一种对性能测试进行管理的办法，该方法基于自动化测试生命周 期方法a t l m 和被广泛采用的t m a p 模型，按照a t l m 的描述方法对性能测试 过程进行建模，在本文中，我们把这种模型称为性能测试过程逶用模型p t g m 。 该性能测试模型将性能测试过程分为测试前期准备、测试工具引入、测试计划、 测试设计与开发、测试执行和管理以及测试分析等6 个步骤，如图3 1 所示。 p t g m 是一个结构化的过程模型，如图： 图3 1p t g m 模型示意图 p t g m 模型参考了各种不同的性能测试、分析等模型，并结合a t l m 和 t m a p 等过程模型，结合笔者本人的性熊测试经验，应该说是一个毒 常有实践指 导意义的性能测试模型。 3 性畿测试的过程模型 3 1 1 测试前期准备 在前期准备阶段要完成两个方面的工作：傈证系统稳定和建立合适的测试团 队。性能测试一般是软件系统已经开发或是部署完成之后的测试，要求被测对象 至少具有一定的稳定性，在功能上基本满足了需求，对一个很不稳定的或是还处 予“半成品”状态的软件系统进行测试，没有太大的意义。 具体来说，测试前期准备包包括： ( 1 ) 系统基础功能验证 1 4 第3 章性能测试的过程模型及其测试工具 该活动类似于系统测试阶段，每个迭代过程中的b v t ( b u i l dv e r i f i c a t i o n t e s t ) 测试，对性能测试而言，这个活动的主要目的是确保当前需要进行测试的 应用系统已经具备了进行性能测试的条件。 如果性能测试本身属于验收测试的一部分，只需要把性能测试安排在功能验 收测试完成之后即可；如果性能测试不在验收测试阶段进行，则必须保证在性能 测试之前进行至少一次系统的功能覆盖测试。 ( 2 ) 组建测试团队 在测试前期准备阶段，我们需要根据项目的大致情况，确定人员需要的技能， 从而从组织中或是通过招聘挑选合适的人员组成测试组。 ( 3 ) 测试工具确认 在这个活动中，需要根据对被测系统的了解和对测试过程的初步规划，给出 测试工具应该具备的功能列表。 表3 1 性能测试工具需求规划表 被测系统环境测试工具功能需求建议 操作系统环境测试工具是否能运行在本操作系统上? 测试工具是否支持对本操作系统的监控? 应用服务器环境测试工具能否支持对本应用服务器的监控? 数据库环境测试工具能否支持本数据库的监控? 应用使用的协议 本系统使用了哪些协议? 哪些协议需要在性能测试中通过工具进行录制和产生负载? 测试工具能否支持我们需要进行录制和产生负载的协议? 网络环境是否需要测试工具支持防火墙? 是否需要测试工具支持负载均衡? 测试管理支持测试工具能够提供方便的测试结果分析和管理? 3 1 2 引入测试工具 性能测试工具在性能测试项目中发挥着不可替代的作用，很难想象一个没有 使用任何性能测试工具而完全依靠手工进行的性能测试。但从另一个方面来说， 使用了性能测试工具，并不一定能做好性能测试。对性能测试来说，要为项目测 试选择合适的工具，要为测试工具的使用确定范围，要在测试过程中规定和规范 测试工具的使用。 引入测试工具包括： 1 ) 工具选择 性能测试一定会使用自动化测试手段，使用自动测试工具( 商业或是自行开 发的) ，为项目选择合适的工具。 选择的方法是选定几种可用的工具，对照表3 1 给出的问题列表，为每个工 1 5 第3 章性能测试的过程模型及其测试工具 具进行一个功能符合度的评估，选择符合度最高的工具，如果所有的工具都无法 达到我们要求的功能符合度，则可以考虑通过创建方式自行构建测试中使用的工 具。 2 ) 工具技能培训 对项目的相关参与者进行测试工具的应用技能培训，以使测试活动参与者能 够具备测试需要的技能。最好能够在测试开始前确定各种角色人员的详细技能标 准，并据此给出培训是否达到预定西标的评判准则，培训活动不一定需要组织内 部的人员招待完成，可以通过工具的经销商培训或是外包服务等方式完成。 3 ) 确定工具应用过程 对测试工具应用范围和测试工具应用局限性的进行确认。确定性能测试工具 在测试中的具体应用范围，工具使用过程中的问题解决方法等内容。具体来说， 哪些工作使用工具完成? 测试工具在使用过程中的问题由谁来解决? 测试工具 的脚本如果管理? 这些问题都应该在这个过程中完成。 3 1 3 制定测试计划 制定测试计划是指生成指导整个测试执行的计划。主要包括完成测试目标的 确定，测试时闻计划拟定，这个阶段的工作分解如下： ( 1 ) 性能测试应用分析 可以将性能测试的应用领域分为“能力验证”、“规划能力”、“性能调优”和“发 现缺陷”四个领域，在性能测试计划阶段，首先要根据性能测试的尽的，分析性 能测试的应用领域。 确定了性能测试的应蔫领域之后，初步确定可用的性能测试方法。 根据不同的性能测试应用领域分析结果，性能测试的目标定义会有所不同。 表3 2 各种不同应用领域的性能测试目标和性能目标 应爝领域 性筢溪l 试强檬性能譬标 重点关注的关键业务响应 能力验证验证系统在给定黪境中的性能熊力 时阉、吞吐量 验诋系统的性能扩展能力，找出系统能力 规范能力扩充的关键点，给出改善其性能扩展能力业务的性能瓶颈 的建议 重点关注的关键业务响应 性熊调优提麓系统的性能表现 时闻、吞吐量 发现缺陷 发现系统中的缺陷无 1 6 第3 章性能测试的过程模型及其测试工具 ( 2