（计算机应用技术专业论文）性能测试在电力信息系统中的应用研究.pdf

性能测试在电力信息系统中的应用研究 摘要 性能测试的目的在于系统建设完成、验收使用前，通过选用并发量较大的 操作以及会对系统产生较大压力的操作作为性能测试的测试用例，利用测试工 具执行用例，分析测试结果，尽可能多的及时发现系统中存在的性能问题，确 定系统是否满足各项性能指标，以此判断系统是否满足用户需求。 电力信息系统在正式投用到生产环境以前，也都要经过一个完整的性能测 试，以确保上线质量。针对安徽省信息化供电公司项目的自身特点和环境，运 用新的测试技术，l o a d r u n n e r 作为性能测试辅佐工具，在提出一种新的测试流 程方案的指导下，完成项目测试工作。本论文的主要工作包括以下几个方面： ( 1 ) 深入研究了解性能测试理论和流程，分析国内外当前所拥有的性能测 试技术和模型，针对c s 结构的电力信息系统大数据，页面多，流程复杂等特 点，提出一套新的适合电力信息系统性能测试的流程和方案。 ( 2 ) 对现有常用的几款性能测试工具进行分析和研究，使用l o a d r u n n e r 执行性能测试，通过手动关联、参数化等脚本技术，以及场景设置，改进 l o a d r u n n e r 自动化的局限性，更合理和真实地模拟生产环境下信息化供电公司 的性能表现。 ( 3 ) 根据测试用例和性能指标的完成情况，给出项目性能测试结果，分析 可能出现性能瓶颈的地方。结合测试中遇到的一些问题，指出下步工作研究方 向。 应用所提出的性能测试流程和方案，基于l o a d r u n n e r 对安徽省信息化供电 公司项目：“营财一体化、“营配一体化 、“设备资产一体化等进行了有效的 性能测试，测试结果表明，能够准确及时地发现被测系统中存在的性能问题， 为系统更正提供依据。 关键词：性能测试 测试方案测试工具测试用例性能指标 t h er e s e a r c ha n da p p l i c a t i o no fp e r f o r m a n c et e s t i n go n e l e c t r i c a li n f o r m a t i o ns y s t e m ab s t r a c t i np e r f o r m a n c et e s t i n g ，o p e r a t i o n sw i t hal a r g en u m b e ro fp a r a l l e lt r a n s m i s s i o n s o ro p e r a t i o n sw i t hh e a v yp r e s s u r eo nt h es y s t e ma r ee m p l o y e da st e s t i n gc a s e s a sa t e s t i n gt o o l ，t e s ts o f t w a r er u n st e s tc a s e st oa c q u i r ea n da n a l y z et h er e s u l t s t h e p u r p o s eo fp e r f o r m a n c et e s t i n gi st od e t e c tt h ec o m p l e t i o nr a t e so fp e r f o r m a n c e q u o t ai nt h es y s t e ma n dm e a s u r et h e mb yt h ec r i t e r i o no fu s e rd e m a n d t h u s ， p e r f o r m a n c et e s t i n gc a na s s i s tt od i s c o v e rt h ee x i s t i n gp e r f o r m a n c ep r o b l e m si n e l e c t r i c a li n f o r m a t i o ns y s t e ma n dg u a r a n t e et h er u n n i n gp e r f o r m a n c ea f t e rt h e f o r m a ld e p l o y m e n to ft h es y s t e m e l e c t r i c a li n f o r m a t i o ns y s t e md e m a n d sac o m p l e t ep e r f o r m a n c et e s t i n gb e f o r ei t i sf o r m a l l yu t i l i z e di nw o r ke n v i r o n m e n t a c c o r d i n gt ot h ef e a t u r e sa n da p p l i c a t i o n e n v i r o n m e n to fp r o je c to ft h ea n h u ip r o v i n c ei n f o r m a t i o n i z a t i o np o w e rs u p p l y c o m p a n y , an e wt e s t i n gs c h e m ei sp r o p o s e da n du s e di nt h et e s t i n gw o r ka sa g u i d e l i n e i nt h et e s t i n gw o r k ，l o a d r u n n e ri sc h o s et ob et h ep e r f o r m a n c et e s t i n g t o o li na c c o r d a n c ew i t ho u rt e a m st e s t i n gt e c h n i q u e s t h em a i nc o n t e x t so ft h i s d i s s e r t a t i o na r ea sf o l l o w s ： ( 1 ) t h ep e r f o r m a n c et e s t i n gt h e o r ya n dp r o c e d u r e sa r ei n v e s t i g a t e d t h es t a t u s q u oo ft h ed o m e s t i ca n df o r e i g np e r f o r m a n c et e s t i n gt e c h n i q u e sa n dm o d e l sa r e a n a l y z e d an e w s e to fp e r f o r m a n c et e s t i n gp r o c e d u r ea n ds c h e m ef o rt h ee l e c t r i c a l i n f o r m a t i o ns y s t e mi sp r o p o s e di na c c o r d a n c ew i t ht h el a r g ea m o u n to fd a t a ， m u l t i p l ep a g e sa n dc o m p l e xp r o c e d u r ef e a t u r e so ft h ec se l e c t r i c a l i n f o r m a t i o n s y s t e m ( 2 ) s e v e r a lo r d i n a r yp e r f o r m a n c et e s t i n gt o o l sa r er e s e a r c h e dt h r o u g hd i f f e r e n c e c o m p a r i s o n s l o a d r u n n e ri se m p l o y e df o rt h ep e r f o r m a n c et e s t i n g i t sl i m i t a t i o n o na u t o m a t i o ni si m p r o v e db y s c r i p tt e c h n i q u e ss u c h a sm a n u a la s s o c i a t i o n ， p a r a m e t e r i z a t i o na sw e l la ss c e n a r i os e t t i n g s t h e r e f o r e ，t h ep e r f o r m a n c eo fw o r k e n v i r o n m e n to ft h ei n f o r m a t i o n i z a t i o np o w e rs u p p l yc o m p a n yi ss i m u l a t e dm o r e r e a s o n a b l ea n dm o r er e a l i t yt h a nb e f o r e ( 3 ) a c c o r d i n gt ot h ec o m p l e t i o nr a t e so ft h et e s t i n ge x a m p l e sa n dp e r f o r m a n c e q u o t a ，t h ep e r f o r m a n c et e s t i n gr e s u l t so ft h i sp r o j e c ta r ep r o v i d e da n dp o s s i b l e b o t t l e n e c k sa r ea n a l y z e d c o m b i n e dw i t hs o m ep r o b l e m sw h e nd o i n gt h et e s t ， r e s e a r c ha n dw o r ki nn e x ts t e pa r ea l s op r o p o s e d w i t hu s i n gt h en e ws e to fp e r f o r m a n c et e s t i n gp r o c e d u r ea n ds c h e m e ，a l s ot a k i n g l o a d r u n n e ra st h et e s tt o o l ，w eh a v ed o n ee f f e c t i v ep e r f o r m a n c et e s t i n go nt h e a n h u ip r o v i n c ei n f o r m a t i o n i z a t i o np o w e rs u p p l yc o m p a n yp r o j e c t ，s u c ha st h e i n t e g r a t i o n o fm a r k e t i n ga n d f i n a n c e ，i n t e g r a t i o n o fm a r k e t i n ga n dp o w e r d i s t r i b u t i o n ，i n t e g r a t i o no fe q u i p m e n ta n da s s e t t h er e s u l ts h o w s ，i tc a nf i n d p e r f o r m a n c ep r o b l e m s t h a te x i s t e di nt h es y s t e m a c c u r a t e l ya n dt i m e l y ，a l s o p r o v i d e sf o u n d a t i o nf o rt h es y s t e mc o r r e 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 i n g ；t e s t i n gs c h e m e ；t e s t i n gt o o l ；t e s t i n gc a s e ； p e r f o r m a n c eq u o t a 插图清单 图2 1w e b 应用的页面响应时间分解7 图2 2v 模型结构1 0 图2 3w 模型结构1 1 图2 4 s i l kp e r f o r m a c e 的性能测试过程1 3 图2 5p t m 方法模型结构图1 3 图3 1关联原理示意图2 0 图4 1营财一体化系统架构图2 6 图4 2 营销系统的网络拓扑图2 6 图4 3 营财一体化项目测试过程管理流程图2 7 图4 4 性能测试环境架构拓扑图3 0 图5 1系统登录应用服务器资源消耗图3 3 图5 2 电费坐收缴费数据库服务器性能图3 4 图5 3电费坐收缴费应用服务器性能图3 5 图5 - 4 走收查询数据库服务器性能指标一3 5 图5 5 走收查询应用服务器c p u & 内存性能图3 6 图5 - 6 走收查询应用服务器网络流量性能图3 6 图5 7 走收查询应用服务器磁盘读写性能图3 7 图5 8 坐收解款数据库服务器性能图3 8 图5 - 9 坐收解款应用服务器性能图3 8 表格清单 表2 1开发角度关注的性能问题6 表3 1 参数化数据更新分配表2 3 表4 1 性能测试用例表2 9 表4 2 风险分析表3l 表5 1 系统登录测试结果3 3 表5 2 电费坐收缴费测试结果3 4 表5 3电费坐收解款测试结果3 7 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研究成 果。据我所知，除了文中特别加以标志和致谢的地方外，论文中不包含其他人已经发表 或撰写过的研究成果，也不包含为获得 盒壁王些丕堂 或其他教育机构的学位或证书 而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确 的说明并表示谢意。 学位论文作者签字苍抬 签字日期：矽f o 年斗月诊日 学位论文版权使用授权书 本学位论文作者完全了解 金蟹互些太堂 有关保留、使用学位论文的规定，有权 保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅或借阅。本人 授权 金胆王些太堂 可以将学位论文的全部或部分论文内容编入有关数据库进行检 索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文者虢鹰牾 签字日期：7 咖年午月落日 学位论文作者毕业后去向： 工作单位： 通讯地址： 名：同) 易研 签字日期：年华月矿日 电话： 邮编： 致谢 本论文是在导师周国祥教授的悉心指导下完成的。周老师渊博的专业知识、 深厚的理论功底、严谨的治学态度、敏锐的学术思想以及不断创新进取的学术 态度，是我今后学习和工作的楷模。 周老师在学术方面给予了我无私的指导和帮助，为我们提供了良好的学习 环境和丰富的实践机会。此外，周老师在日常生活中还向我们传授了如何为人 处事的很多道理，对我们严格要求，努力培养我们的综合素质。这些教育让我 终身受益，在此谨向周老师致以衷心的感谢和崇高的敬意! 感谢安徽省电力科学研究院信息技术研究中心的所有领导和同事，谢谢你 们提供的实习岗位，大大增加了我的实际项目经验，锻炼了我踏入社会的工作 能力。 感谢指导和帮助过我的师长，感谢帮助过我的同学，你们让我觉得学校的 生活是如此的温暖和快乐。 深深感谢我的父母和亲人，感谢你们二十多年来一直对我无微不至的关怀， 在我遇到困难的时候开导我，在我取得进步的时候鼓励我。你们无私的爱和深 切的希望是我求学路上最大的精神动力! 作者：李怡 2 0 1 0 年4 月3 日 第一章绪论 1 1 课题研究背景及意义 国家电网公司根据“十一五”信息发展规划，决定开展信息化“$ g 1 8 6 工 程”。安徽省电力公司为满足“十一五 国网公司信息化建设要求，同时考虑公 司业务自身的持续快速发展和对客户进行优质服务的总体要求，以“一强三优” 为导向，提出“信息化供电公司”的建设思路，并将“信息化供电公司”建设 目标具体表述为“三个一体化 建设，即“营配体化 、“营财一体化”和“设 备资产一体化【ij 。 信息化供电公司项目营财一体化系统的目标是在营销m i s ( m a n a g e m e n t i n f o r m a t i o ns y s t e m ) 与财务系统之间，建立起一定的业务流程和处理规则，通 过数据接口使营销m i s 系统中的具体业务处理与财务系统中的账务处理建立关 联。解决重复维护、数据不一致以及信息孤岛的问题，达到营财信息共享的目 的，为基层业务工作效率的提高和企业领导经营决策的制定提供手段和辅助依 据。其主要内容是按照财务化管理要求，采用借贷复式记账原理，处理电费、 非电费等各种账务核算业务，从管理制度和信息系统两个方面来实现营销财务 化。 为确保该项目能正式投用，在上线前由专业测试人员对其进行性能测试。 性能测试属于软件测试中的系统级测试。软件测试是软件质量保证的重要 手段【2 j 。有研究数据显示，国外软件开发机构4 0 的工作量都花在软件测试上， 软件测试费用占软件开发总费用的3 0 - 一5 0 。对于一些要求高可靠、高安全的 软件，测试费用可能相当于整个软件项目开发所有费用的3 5 倍。由此可见， 要成功开发出高质量的软件产品，除了从思想上重视软件测试工作，还必须掌 握测试技术，有效地实施测试工作l j j 。 性能测试包括的测试内容丰富多样。中国软件评测中心将性能测试概括为 三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务 器端性能的测试【4 1 。通常情况下，三方面有效、合理的结合，可以达到对系统 性能全面的分析和瓶颈的预测。不同测试内容有相应的测试重点。 本课题来源于安徽省电力公司信息化供电公司营财一体化性能测试项 目的开发，并作为后续的研究课题。本文针对该电力系统的自身特点，研究了 国内外现有的性能测试技术和测试工具，提出一套新的性能测试流程方案，选 择惠普公司的l o a d r u n n e r 作为本项目的自动化测试工具，通过改进l o a d r u n n e r 的脚本技术，更真实地模拟用户行为和贴近用例要求，让系统满足用户的各项 性能指标，确保系统在各地市公司的正常上线使用。 一个完备的性能测试流程方案，能使整个性能测试高效安全的进行，测试 过程变得规范有序。结合安徽省信息化供电公司项目的性能测试实施情况，确 定了按本文提出的方案执行性能测试的可行性和正确性。在其他类似j 2 e e 或 者n e t 平台搭建的电力系统中，此流程方案的框架和设计方法具有通用性，同 时文中提供的脚本技术、性能测试用例设计方法、数据提取方法等都是在经过 多次实践后得出的高效手段，测试计划和准则从各个角度严格规定了测试执行 的进度，以此确保系统的安全上线。同时方案的完善性和清晰条理是设计性能 测试流程时的首选，具有广泛的实用推广价值。 1 2 国内外研究现状 自计算机问世以来，程序的编制与测试就同时摆在人们面前。由于早期的 计算机运行可靠性差，以及程序编写的问题，导致很难定位故障。随着大规模 集成电路技术的发展，计算机系统硬件的可靠性得到了很大提高，而计算机应 用的不断推广和深入，相应软件规模也越来越大，因此，软件的测试问题显得 更为突出和重要。 1 2 1 国内外的软件测试现状 早在5 0 年代，英国著名计算机科学家图灵曾给出程序测试的原始定义，认 为测试是正确性确认的实验方法的一种极端形式。直到7 0 年代以后，测试的意 义才逐渐被人们认识。1 9 7 5 年，g o o d e n o u g h 首次提出软件测试的理论，把软件 测试提高到理论的高度。1 9 7 9 年，软件测试艺术( t h ea r to fs o f t w a r e t e s t i n g ) 一书中认为，测试是为发现错误而执行的一个程序或者系统的过程。 在软件测试理论迅速发展的同时，各种软件测试方法也相继提出。j c h u a n g 提出了程序插桩的概念，we h o u d e n 提出了系统功能测试以及代数测试等概 念，m s k a r a s i k 提出了环境测试的概念，重点在于验证程序是否与说明书一 致。1 9 8 2 年，美国北卡来纳大学首次召开了软件测试技术会议，成为软件技术 发展的一个重要里程碑。此后，测试理论和测试方法进一步完善，但仍不能满 足当前软件开发的实际需求门。 1 3 论文研究内容 本文依据安徽省电力公司信息化供电公司营财系统的性能测试项目为基 础，对其进行深入的分析和研究。以熟悉掌握性能测试的基本理论和技术为前 提，针对该电力系统的特点，研究设计出一个新的测试流程方案设计方法，分 析流程各层详细内容和执行方法。比对现有的自动化测试工具，选择适合的工 具，研究其脚本相关技术，明确影响模拟用户行为真实性的因素。项目执行完 毕，结合项目测试结果，分析与优化系统性能。研究内容主要如下： 一、总结国内外关于软件测试的一些情况，从多方面角度去解析性能测词 的理论和技术，研究不同角色对系统的不同性能需求。比对市场现有的几种主 流测试工具，确定根据何种标准来进行选择，对于选定的工具需要如何掌握， 2 才能更好地辅佐测试的进行。 二、研究项目系统的特点，对要进行的性能测试进行需求分析，确定系统 性能指标，如何提出一个新的测试流程方案，指导性能测试的执行是工作研究 的关键内容。 三、根据设计好的测试方案，结合已掌握的技术基础上，选定的测试工具。 在执行测试中，研究流程中每一项的具体内容。最后依据测试结果数据，进行 分析，指出可能出现瓶颈的地方，提供优化方法。 1 4 论文组织结构 论文主要分为六个部分，各章主要内容安排如下： 第一章，绪论。 主要介绍论文的选题背景和国内外研究现状，以及论文的组织内容。 第二章，性能测试理论概述。 介绍性能测试的相关理论技术。分析了当前存在的性能测试模型，从不同 角度分析软件性能，给出不同结构系统可能涉及的性能指标。在研究多种性能 测试方法的基础上，提出一种新的性能测试流程方案，指导实际项目的执行。 第三章，l o a d r u n n e r 测试技术概述。 比较当前市面存在的自动化性能测试工具，以介绍l o a d r u n n e r 为对象，研 究它的脚本技术，通过了解它的原理，更好地应用于测试。 第四章，信息化供电公司项目的性能测试。 结合信息化供电公司实际项目，以l o a d r u n n e r 为测试工具，实际应用论文 中所提出的新的测试方法。介绍性能测试的详细过程，给出相应测试结果。 第五章，测试分析与优化。 根据性能指标，分析测试结果，指出可能存在瓶颈的地方，指导后期的优 化。 第六章，总结。 总结一下自己所做的工作和研究，指出项目进行过程中存在的未解决的地 方，指出改进方向。 第二章性能测试理论概述 性能对一个系统而言包括稳定性、资源占用、执行效率、安全性、可扩展 性、兼容性、可靠性等，是一个很大的概念，覆盖面非常广泛。性能测试在软 件质量保证中起着重要作用，用来确保产品发布后系统的性能满足用户的需求， 复杂性显而易见，一个软件系统的性能表现相关因素非常多，例如网络环境、 数据库服务器、应用服务器、业务逻辑的实现方式、系统采用的架构、代码优 化程度等均会对系统的性能表现造成影响【5 】。性能测试包含的测试内容丰富多 样，贯穿了软件开发、软件测试、软件系统等多个领域，并且相关技术也会随 着软件架构、软件开发的变化而不断发展。 2 1 软件性能 软件性能测试，很明确关注的是系统的“性能”。一般来说，性能是一种指 标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产 品的一种特性，可以用时间来进行度量【6 l 。 通常，对软件性能的关注为三个层面的：用户关注软件性能，管理员关注 软件性能，产品的开发人员也关注软件性能。不同的关注者侧重的具体内容有 所不同。 2 1 1 用户角度的软件性能 软件系统经过单机系统时代，客户机服务器系统时代，到现在跨广域网的 庞大分布式系统时代，满足用户强大的功能需求同时，软件系统在架构和实现 上也变得复杂。随着系统业务量的增大，需要使用更多的时间和空间资源，一 般情况下不能出现的软件性能问题，就会暴露出来，轻则让软件对外不能正常 提供服务，重则会导致系统的崩溃甚至数据的丢失，这都会给用户带来无法估 量的损失。 从用户角度来说，软件性能就是软件对用户操作的响应时间。当用户单击 一个按钮、发出一条指令或是在w e b 页面上单击一个链接，从用户单击开始到 应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的 时间就是用户对软件性能的直观印象【7 1 。细数用户对软件的性能需求为以下几 个： 计算性能 计算性能是用户最关心的一个指标，即软件系统的响应时间有多快。 启动时间 用户希望系统进入正常工作状态的时间越短越好，尤其在主备系统中，软 件的启动时间直接影响主备的切换效率。不同的软件系统启动时间是不同的， 4 例如，j 2 e e 系统在第一次启动的时候一般会比较慢，而c c + + 程序因直接运行 的是二进制机器代码，启动速度就要快一些。 稳定性 稳定性问题反映在系统运行一段时间后，出现了问题，不能响应用户的请 求，甚至破坏或丢失数据，这造成的损失是用户非常关心的。 2 1 2 管理员角度的软件性能 从管理员的角度来看，软件系统的性能首先表现在系统的响应时间上，这 一点和用户角度是一样的。但管理员是一种特殊的用户，和般用户相比，除 了关注一般的性能需求体验外，还会关心和系统状态相关的信息。例如，管理 员已经知道，在并发用户数为1 0 0 时，a 业务的响应时间为8 秒，那么此时的 系统状态如何? 服务器的c p u 使用是不是已经达到了最大值? 是否存在可用的 内存? 概括起来就是考虑资源的利用和回收。 硬件资源包括客户端硬件、服务器硬件和网络硬件，软件资源包括操作系 统、中间件和数据库等。运行软件系统需要使用到的服务器内存数量，对于整 个系统的性能表现是至关重要的i s 。因此，软件系统能否在运行时有效地使用 和释放内存是管理员考察软件性能的一个重要因素。 另一方面，管理员会想要知道系统具有多大的可扩展性，处理并发的能力 如何；知道系统可能的最大容量是什么，系统可能的性能瓶颈在哪里，通过更 换哪些设备或是进行哪些扩展能够提高系统性能，了解这些情况，管理员才能 根据系统的用户状况制定管理措施，在系统出现计划之外的用户增长等紧急情 况时候能够立即制定相应措施，进行迅速的处理；此外，管理员可能还会关心 系统在长时间的运行中是否足够稳定，是否能够不间断地提供业务服务等。 因此，从管理员视角来看，关注的更多的是系统的资源利用率、可扩展性 和容量，即使是系统稳定性，也和普通用户要求的角度不同。 2 1 3 开发角度的软件性能 从开发人员的角度来说，对软件性能的关注更深。开发人员知道，没有过 分理想化的软件可以拥有无限的性能。除了关心用户的直接体验外，最想知道 的是“如何通过调整设计和代码实现，或是如何通过调整系统设置等方法提高 软件的性能表现 和“如何发现并解决软件设计和开发过程中产生的由于多用 户访问引起的缺陷 1 9 】。最关注的是使性能不佳的因素和由于大量用户访问引 发的软件故障，也就是通常所说的“性能瓶颈 ，系统中存在的大量用户访问时 表现出来的缺陷。 对于一个即将发布的系统，开发人员可能会想要知道当大量用户访问这个 系统时，是否存在由于资源竞争引起的挂起? 是否存在由于内存处理等问题引 5 起的系统故障? 通常从开发角度关注的性能问题如表2 1 所示： 表2 1开发角度关注的性能问题 器开发人员关心的问题。一。 。 闯题所属，。，；獯 架构设计是否合理 系统架构 数据库设计是否存在问题 数据库设计 代码是否存在性能方面的问题 代码 系统中是否有不合理的内存使用方式 代码 系统中是否存在不合理的线程同步方式 设计与代码 系统中是否存在不合理的资源竞争 设计与代码 不同的对象对软件系统性能的关注有着显著的差异。从项目管理的角度， 大部分用户对性能的理解属于“用户角度”，项目的维护人员或是用户方的项目 经理一般会从“管理员角度”来看待软件性能的问题，而项目的创建者一开发 人员( 包括设计人员) 自然是从“开发角度 来关注软件性能。 2 2 性能指标 性能测试的目的一般分为以下两部分：一部分是查看系统在一定的负载条 件下运行是否合乎需求；另一部分是通过系统在一定负载下运行所得的数据分 析它可能发生性能瓶颈的地方f l o 】。因此，能够对当前的系统产生定的负载，并 且能够分析系统在一定负载下的表现是实现性能测试的关键。为方便利用测试 工具分析测试结果时，有的放矢，关注影响系统的主要因素，在指标中就应该 给出本次性能测试需要关注的具体项【1 1 】。典型的性能度量指标有响应时间 ( r e s p o n s et i m e ) 、系统吞吐量( t h r o u g h p u t ) 、并发用户数目( c o n c u r r e n t u s e r s ) 、系统资源利用率( u t i l i z a t i o n ) 。 2 2 1 响应时间 响应时间是对请求做出响应所需要的时间，可划分为呈现时间和系统响应 时间两个部分，其中，呈现时间取决于数据在客户端收到响应数据后呈现页面 所消耗的时间【挖l 。例如，对一个w e b 应用，呈现时间就是浏览器接受到数据后 用户把数据呈现出来的时间。而系统响应时间指应用系统从请求发出开始到客 户端接受到数据所消耗的时间。在一般的性能测试中，并不注重呈现时间，因 为呈现时间在很大程度上取决于客户端的表现，例如，一台内存不足的客户端 机器在处理复杂页面的时候，其呈现时间可能就很长，但并不能说明整个系统 的性能【1 3 】。 响应时间可以被进一步分解。图2 1 描述了个w e b 应用的页面响应时间 的构成。从图中看出，页面的响应时间可被分解为“网络传输时间” ( n i + n 2 + n 3 + n 4 ) 和“应用延迟时间 ( a i + a 2 + a 3 ) ，而“应用延迟时间”又可以 6 分解为“数据库延迟时间 ( a 2 ) 和“应用服务器延迟时间”( a 1 + a 3 ) 。分的越 细，在后期分析性能测试结果时，比较容易找到性能瓶颈所在。 嗍络 客户端w 曲 数据库 n 1 八 服务器， 服务器 a1 。n 2 。 a 2 rr 内 、： n 4a 3 。n 3影 厂 图2 1w e b 应用的页面响应时间分解 通常，响应时间主要由n 1 和n 4 决定，这个等待时间代表了客户访问 i n t e r n e t 的方式。为了减少这些等待时间( n 1 和n 4 ) ，一个普通的解决办法是 把w e b 服务器或w e b 应用尽可能地放在靠近客户的地点，这可以通过就近设置 服务器或在一些主要i n t e r n e t 主机提供商的站点上做镜象站点来实现，减少客 户到服务器之间的网络路由转发时间。网络等待时间n 2 和n 3 常常依赖服务器 交换设备的性能。当后端数据库的通信量增加时，可以考虑升级交换设置和网 络适配器来改善性能。要减少应用等待时间( a l ，a 2 和a 3 ) 比较困难，因为服务 器应用软件的复杂性将使得分析性能数据和性能调整( p e r f o r m a n c et u n i n g ) 变 得十分复杂。例如多个软件构件在服务器上相互作用来为特定的请求服务，等 待时间将可能由这些构件中的任何一个产生。 2 2 2 吞吐量 吞吐量是指单位时间按内系统处理的客户请求的数量，直接体现软件系统 的性能承载能力【1 4 】。一般来说，吞吐量用请求数秒或是页面数秒来衡量，从 业务的角度，吞吐量也可以用访问人数天或是处理的业务数小时等单位来衡 量；从网络的角度来说，也可以用字节数天来考察网络流量。 对于交互式应用，用户直接的体验为响应时间，通过并发用户数和响应时 间可以确定系统的性能规划；但对于非交互式应用，用吞吐量来描述对系统性 能的期望可能更加合理【i5 1 。吞吐量指标反映的是服务器承受的压力。在容量规 划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载 能力；另外，在性能调优的过程中，吞吐量指标也有重要的价值【l6 。吞吐量指 标可以在两个方面发挥作用： ( 1 ) 用于协助设计性能测试场景，以及衡量性能测试场景是否达到了预期 的设计目标：在设计性能测试场景时，吞吐量可被用于协助设计性能测试场景， 根据估算的吞吐量数据，可以对应到测试场景的事务发生频率、事务发生次数 等：另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的 目标。 7 ( 2 ) 用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形 式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能瓶颈所在 位置。以不同方式表达的吞吐量可以说明不同层次的问题。例如，以字节数 秒方式表示的吞吐量主要受网络基础设施、服务器架构、应用服务器制约；以 单击数秒方式表示的吞吐量主要受应用服务器和应用代码的制约【1 7 】【1 8 l 。 作为性能测试时的主要关注指标，吞吐量和并发用户数之间存在一定的联 系。在没有遇到性能瓶颈的时候，吞吐量可以采用如下公式计算： f ：坚业兰垦 t ( 3 - i ) 其中，f 表示吞吐量；n 表示v u ( v i r t u a lu s e r ，虚拟用户) 的个数；r 表 示每个v u 发出的请求( 单击) 数量；t 表示性能测试所用的时间。但如果遇到 了性能瓶颈，此时吞吐量和v u 数量之间就不再符合公式给出的关系。 虽然吞吐量指标可被看作是系统承受压力的体现，但在不同并发用户数量 的情况下，对同一个系统施加相同的吞吐量压力，很可能会得到不同的测试结 果。许多性能测试工具生成的报告中都会有吞吐量这个项目。其实吞吐量本身 就是一个很直观的指标，两个不同系统可能具有不同的用户数和用户使用模式， 但如果具有基本一致的吞吐量，则可以说，它们具有基本相同的平均处理能力。 2 2 3 并发用户数 若性能测试的目标是验证当前系统能否支持现有用户的访问，最好的办法 就是弄清楚会有多少用户会在同一个时间段内访问被测试的系统。如果使用性 能测试工具模拟出与系统的访问用户数相同的用户，并模拟用户的行为，得到 的测试结果就能够真实反映实际用户访问时的系统性能表现，也就能够通过性 能测试了解到当系统处于实际用户访问时，会具有怎样的性能表现。这里提到 的在同一个时间段内访问系统的用户数量，即性能测试中常提到的并发用户数 的概念19 1 。 对服务端来讲，每个用户和服务端的交互都是离散的。如果仅考虑一个单 独的用户对系统的使用，过程大致为：用户每隔一段时间向服务端发送一个请 求或是命令，服务端按照用户的请求执行某些操作，然后将结果返回给用户瞄。 从用户的角度来看，在一个相当长的时问段，都会有基本固定数量的使用 者使用该系统，虽然每个使用者的行为不同，但从业务的角度来说，如果所有 这些用户的操作都没有遇到性能障碍，则可以说该系统能够承受该数量的并发 用户访问，这里的并发概念就是前面讨论的业务并发用户数。然而，如果考虑 整个系统运行过程中服务器所承受的压力，情况就会不同。在该系统的运行过 程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个同时向服 务端发送请求的客户数，这个就是服务端承受的最大并发访问数【2 。如果能找 8 到运行过程中可能出现的最大可能的服务端承受的最大并发访问数，则在该用 户数下，服务器承受的压力最大，资源承受的压力也最大，在这种状态下，可 以考虑通过并发测试( c o n c u r r e n c yt e s t i n g ) 发现系统中存在的并发引起的资 源争用等问题。 在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数。 下面给出一个一般估算并发用户数的公式： c=了nl(3-2) ，。一 c = c + 3 c( 3 3 ) 在公式3 - 2 中，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 小时的工作时间。 在公式3 - 3 则给出了并发用户数峰值的计算方式，其中c 指并发用户数的 峰值，c 就是公式3 - 2 中得到的平均的并发用户数。该公式的得出是假设用户 的l o g i ns e s s i o n 产生符合泊松分布而估算得到的。 公式计算方法并不是惟一，在公式中仍然需要估算“平均用户数”和“l o g i n s e s s i o n 的长度”，要精确估算这两个值并不容易【2 2 1 。另外，考虑到用户的业务 操作存在一定的时间集中性，也就是说，用户对系统业务的访问往往不是平均 分布在整个考察时间段内，而是相对集中地分布在某几个时间段内，采用上述 公式进行计算存在一定的偏差。 “日志分析”法是另一种得到并发用户数的方法，指通过对应用服务器的 日志进行分析，从而了解系统用户的使用状态，从日志中计算出服务器承受的 最大并发用户访问数据【2 3 1 。这种方式得到的数据准确度和可信度都比较高，对 于i n t e r n e t 应用等无法估计用户数量和用户行为模式的应用，这种方式最可 信。“日志分析 的方法需要借助日志分析工具的支持，利用一般的开源或商业 工具提供分析和扩展支持。 2 2 4 资源利用率 查看性能测试的资源利用率最基本的方法是利用“性能计数器”来描述服 务器或操作系统性能的一些数据指标。在分析系统的可扩展性、进行性能瓶颈 的定位时，对计算器取值显示的资源率非常关键。为了方便比较，般用“资 源的实际使用率总的资源用量”形成资源利用率的数据，用以进行各种资源使 用的比较。 在性能测试中常用资源利用率进行横向的对比，例如，在进行测试时会发 现，资源a 的使用率到了接近1 0 0 的数值，而其他的资源利用率都处于比较低 9 的水平，则可以清楚地知道，资源a 就很有可能是系统的一个性能瓶颈。当然， 资源利用率在通常的情况下需要结合响应时间变化曲线、系统负载曲线等各种 指标进行分析。 单一的性能计数器通常反映了系统性能的一个侧面，在进行性能测试结果 分析的时候，一般要对多个性能计数器进行分析，这些指标就是监控系统资源 利用率的最佳标准。 2 3 性能测试方法 2 3 1 测试模型 一个软件测试过程模型的内容应包括，在测试过程中应考虑哪些问题，如 对测试进行计划，测试要达到什么目标，什么时候开始，在测试中要用到哪些 信息资源，参考什么标准【2 引。好的测试模型的应用，能使测试活动高效，准确 地执行，有效节约成本资源，避免重复性的错误。 现存通用的测试模型有v 、w 模型两种。图2 2 明确的标注了针对v 模型， 测试过程中存在的不同类型的测试，并且清楚地描述了这些测试阶段和开发过 程期间各阶段的对应关系。 图2 - 2v 模型结构 在v 模型中，单元和集成测试是为了查看程序的执行是否满足软件设计的 要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标： 验收测试是最终确定软件的实现是否满足用户需要或合同的要求 z s j 。v 模型存 在一定的局限性，它仅仅把测试作为在编码之后进行的一个阶段，是针对程序 进行的寻找错误的活动，从而忽视了测试活动对需求分析、系统设计等活动的 验证和确认。 相对于v 模型，w 模型则在软件各开发阶段中增加了应同步进行的验证和 确认活动。 在w 模型中，测试伴随着整个软件开发周期，而且测试的对象不仅仅是程 l o 序，需求、设计等同样在测试范围内，也就是说，测试与开发是同步进行的。w 模型有利于尽早地全面发现问题。强调对需求的测试有利于及时了解项目难度 和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但w 模型也有局限性l z 引。w 模型强调，需求、设计、编码等活动被视为串行的， 同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才 可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件 开发复杂多变的情况，w 模型并不能解除测试管理面临着的困惑 图2 - 3w 模型结构 后期还有别的专家提出一种h 模型，强调的是测试是个独立的过程，只要 条件具备就应尽早地展开测试工作。 2 3 2 性能测试方法 ( 1 ) r b i ( r a p idb o t t l e n