性能测试中的关键词有响应时间、并发用户数、吞吐量、性能计数器、思考时间,这是性能测试中经常使用的几个概念,必需要有清晰的认识。前端
(1)响应时间数据库
响应时间的定义能够参考下图,一般的响应时间是指从C1一直到C2所有的时间,这里我想补充的一个知识点是,因为前端性能这些年愈来愈受重视,用户感觉到的时间并非“客户端收到最后一个字节的时间”,而是愈来愈多的引入了“用户感觉到的响应时间”。二者的区别在数据量庞大,页面渲染须要花费大量时间的状况下极为明显,即,咱们优化系统响应时间的一个方向是让用户感觉到的响应时间变短。安全
(2)并发用户数性能优化
并发用户数主要与在线用户数、系统用户总数区分。最简单的认知就是被测系统是一个QQ群,用户老是就是全体群成员,在线用户数就是在线的成员,并发用户数就是在聊天的成员。这么一来就很明显了,咱们都知道一个QQ群里真正活跃的每每是少数人,因此被测系统的并发用户数也是远小于系统用户总数的。服务器
如何肯定并发用户数,这个问题常见的答案就是看具体状况,或者用户总数的10%~20%。事实上,确实没有能够适用于大部分软件的肯定并发用户数的方法。通常而言,针对于企业内部的信息系统而言,采用经验公式选择10%~20%的用户总数做为并发用户数是比较合理的。网络
(3)吞吐量架构
吞吐量能直接反应系统的性能承载能力,反应的是系统在单位时间内处理请求的能力。常见的吞吐量衡量指标是请求数/秒或者字节数/小时,固然具体的系统能够选择不一样的指标如页面数/秒,处理业务数/小时,等等。并发
注意:要区分这里的吞吐量与loadrunner的analysis的吞吐量概念并不彻底相同,loadrunner中的吞吐量是字节数/秒,并且引入了平均事务响应时间TPS的概念,分别从不一样维度展现被测系统的吞吐量。前端性能
(4)性能计数器工具
性能测试的执行阶段须要记录服务器的资源占用率,通常使用性能计数器来衡量被测系统当前的状况而且进行性能测试的结果分析。
性能计数器包括不少种类,一般须要咱们关注的就是服务器的资源占用率、内存使用率、磁盘I/O,固然还有其余不少的性能计数器,这里不详细赘述。经过这些资源的占用状况咱们能获得表征,可是具体的性能瓶颈还须要深刻的分析。
因为服务器使用操做系统不一样,因此须要选择不一样的工具,对于Windows系统可使用系统自带的资源监视器,对于Linux系统可使用nmon工具,这类的工具备不少选择适用的就能够。
(5)思考时间
关于思考时间,不少时候咱们都认为设置成0是最合理的,由于这样能够模拟一种尽可能大的压力,以研究系统在巨大压力下的表现;可是若是要验证系统具备预期的能力,则须要尽可能模拟真实用户在处理业务时的思考时间。
性能测试的方法主要包括验收性能测试、负载测试、压力测试、配置测试、并发测试、可靠性测试、失败恢复测试。
(1)验收性能测试
验收性能测试的主要目的是验证系统是否具备所宣称的能力,这须要在被测系统有肯定的性能目标,以及肯定的被测环境。性能测试人员在肯定的条件下,经过模拟生产运行的业务压力量和使用场景组合的方式来进行验收性能测试。
(2)负载测试
负载测试指经过在被测系统上不断增长压力,直到性能指标例如响应时间超过预约指标或者某种资源已经达到饱和状态。这种测试的目的是找到系统的处理能力极限,另外一方面这种方法能够了解系统的容量,为性能调优提供依据。
(3)压力测试
压力测试的主要目的是检查系统在必定压力下的性能表现。经过模拟负载等方法,使得系统资源占用达到较高水平。压力测试通常也用来验证系统的稳定性
(4)配置测试
配置测试的目的是经过对系统软硬件调整,了解不一样配置对系统性能影响程度,从而找到最优分配原则。这种测试通常在对系统的性能表现有了必定了解后进行,用于系统的性能调优和规划能力。
(5)并发测试
并发测试的主要目的是发现系统中可能隐藏的并发访问问题,经过模拟用户并发访问实现,主要关注内存泄露、线程锁、资源争用等。并发测试能够在开发的各阶段针对不一样的对象使用。
(6)可靠性测试
可靠性测试主要的目的是验证系统可否支持长时间稳定运行。经过给系统加载必定的业务压力(如资源在70%~90%使用率),让应用持续运行一段时间,经过关注系统的运行状态测试系统是否稳定。
这里我认为须要对负载测试、压力测试、可靠性测试加以区分,经过测试的目的区分这三个概念是比较容易的,负载测试的目的在于发现系统的性能瓶颈;压力测试的目的是在必定压力下验证系统性能表现,重点关注响应时间等内容;可靠性测试则是近乎破坏式地让系统保持在业务的高峰期,关注的是系统可否正常工做,这时就不那么关注系统的响应时间了。
(7)失效恢复测试
失效恢复测试针对有冗余备份和载均衡的系统设计,能够用来检验若是系统局部发生故障,用户可否继续使用系统,以及用户将受多大程度的影响。通常只有对持续运行指标有明确需求的系统才须要这类性能测试。
性能测试的应用领域主要有能力验证、规划能力、性能调优、发现缺陷和性能基准比较五个领域。其中性能基准比较使用于敏捷开发过程当中,在这里不作讲述。下面主要讲述经常使用的四个领域。
(1)能力验证
能力验证一般是对已部署系统的性能进行验证。通常采用性能测试,可靠性测试,压力测试,失效恢复测试
(2)规划能力
规划能力主要用于了解系统的性能而且得到扩展性能的方法,如系统可否支持将来一段时间内的用户增加,是一种探索性测试。通常采用负载测试,配置测试和压力测试
(3)性能调优
性能调优一般是肯定基准的环境和性能指标,经过调整环境和实现方式进行测试,进而发现性能优化的方式,通常采用配置测试,负载测试,压力测试和失效恢复测试
(4)缺陷发现
这一领域的目的就是发现系统中可能存在的性能缺陷,没有须要达到的性能指标,所以主要采用并发测试,若是须要关注压力或者失效恢复过程当中的问题,也能够采用压力测试和失效恢复测试。
(5)性能测试应用领域和测试方法的关系
经过下方的表格,能够帮助读者更好地理解应用领域与测试方法的关系。
应用领域 |
主要用途 |
典型场景 |
特色 |
性能测试方法 |
能力验证 |
关注在给定的软硬件条件下,系统可否具备预期的能力表现 |
在要求平均响应时间小于2秒的前提下,如何判断系统是否可以支持50万用户/天的访问量? |
a)要求在已肯定的环境下运行 |
a)性能测试 d)失效恢复测试 |
规划能力 |
关注如何使系统具备咱们要求的性能能力 |
某某系统计划在一年内获客量在到xxx万,系统到时候是否能支持这么多用户量?若是不能须要如何调整系统的配置? |
a)它是一种探索性的测试 |
a)负载测试 |
性能调优 |
主要用于对系统性能进行调优 |
某某系统上线运行一段时间后响应速度愈来愈慢,此时应该如何办? |
每次只改变一个配置,切忌无休止的调优 |
a)负载测试 |
缺陷发现 |
发现缺陷或问题重现、定位手段 |
某些缺陷只有在高负载的状况下才能暴露出来,如线程锁、资源竞争或内存泄露。 |
作为系统测试的补充,用来发现并发问题,或是对系统已经出现的问题进行重现和定位 |
a)并发测试 c)失效恢复测试 |
性能测试过程模型PTGM(Performance Testing General Model),将性能测试过程分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析等6个步骤。另外一种模型是敏捷性能测试模型(APTM),一般敏捷开发的项目若是存在性能需求才会用到这样的性能测试模型,因为目前本人的性能测试经验都是集中在系统或者验收测试的阶段展开,所以本文中只介绍性能测试过程模型PTGM。
前期准备工做主要完成的工做是确保系统稳定和创建性能测试团队具体的活动包括以下的几个方面:
(1)系统基础功能验证
这一步的目的是肯定系统功能可以正常使用,毫无疑问性能的基础就是系统可使用,若是系统的正常使用都存在问题,那追求性能也不具有太大的意义。所以,性能测试展开的前提就是确保被测系统通过至少一轮的功能测试。一般接近验收阶段的项目的测试顺序是功能测试→安全测试→性能测试,由于若是系统须要引入安全策略或者某些设备的话一样会对被测系统的性能产生影响。
(2)组建测试团队
一个性能测试团队包括的角色以下表,组建性能测试团队时能够根据以下的表格,选择具备相应能力的成员。
角色 |
职责 |
技能 |
测试经理 |
1.和用户等项目干系人交互,确保测试的外部环境 |
1.计划执行和监控能力 |
测试设计 |
1.定义性能规划 |
1.业务把控能力 |
测试开发 |
1.实现已设计的性能场景 |
1.脚本编码和调试能力 |
测试执行 |
1.部署测试环境 |
1.搭建测试环境的能力 |
测试分析 |
1.根据测试结果,性能指标的数值,性能计数器值进行分析 |
1.掌握性能测试工具的使用方法 |
系统支持 |
1.系统支持,协助解决测试工程师没法解决的系统问题 |
1.处理系统问题的能力和技能,最好有专职的系统管理员担任这个角色 |
网络支持 |
1.网络方面的支持,协助测试工程师解决网络方面的问题,在必要时为测试分析角色提供网络方面的分析支持 |
1.网络方面的能力和技能,最好有专职的网络管理员担任这个角色 |
数据库支持 |
1.数据库方面的支持,在必要时为测试分析角色提供数据库方面的支持 |
1.数据库方面的能力和技能,最好由专职的DBA担任这个角色 |
(3)测试工具选择
关于性能测试使用的工具,本人想要向读者说明,性能测试中工具并不会起到决定性的做用,一般在进行测试工具的选择时,须要考虑被测系统的环境,如操做系统环境、应用服务器环境、数据库环境、应用使用的协议、网络环境等,只要性能测试工具知足这些环境的需求,不管是使用loadrunner或者是jmeter都是能够的。
(4)性能预备测试
这一步是探索性的测试,是非正式的测试,其目的主要是用来对被测系统的性能表现创建初步印象,获得的结论也是各有不一样。固然,若是对被测系统已经有了初步的印象,这一步也是能够跳过的。
(1)选择工具
对于性能测试来讲,没有合适的工具配合简直是不可能实现性能测试的,虽说选择了好的测试工具也不必定就能作好性能测试,可是选择一个适合的测试工具显然是更利于测试活动的开展与实现的。一般是选定几种测试工具,根据被测系统的环境来选择最适合项目的测试工具。
(2)工具应用的技能培训
工具使用方面的培训主要是针对测试开发、测试执行、测试分析三类角色,目的是保证测试活动参与者具有测试所需的技能。
(3)肯定工具的应用过程
这个步骤主要是明确工具能够完成的功能,测试工具使用过程当中出现了问题如何解决、测试脚本如何管理等各类相关的问题,这些问题是测试过程当中必须解决的问题。
(1)性能测试领域分析
性能测试计划就是为了实现性能测试的目标,根据性能测试的目标咱们就能够分析出本次性能测试的领域。不一样应用领域的性能测试的性能测试目标和性能目标以下表
应用领域 |
性能测试目标 |
性能目标 |
能力验证 |
验证系统在给定环境中的性能能力 |
重点关注关键业务响应时间、吞吐量、资源等 |
规划能力 |
验证系统的性能扩展能力,找出系统能力扩充的关键点,给出改善其性能扩展能力的建议 |
业务的性能瓶颈 |
性能调优 |
提供系统的性能表现 |
重点关注关键业务的响应时间、吞吐量、资源等 |
发现缺陷 |
发现系统中的缺陷 |
无 |
(2)用户活动剖析业务建模
用户活动剖析的方法主要分为系统日志分析和用户调查分析。
系统日志分析是指经过应用系统的日志了解用户的活动,分析出用户最关注、最经常使用的业务功能,以及达到业务功能的操做路径;用户调查分析是在不具有系统日志分析条件的时候(例如,该系统还没有交付用户运行实际的业务)时采用的一种估算方法,能够经过用户调查问卷、同类型系统对比的方法获取用户最关注、最经常使用的业务功能等内容。
业务建模主要是采用流程图画出各进程之间的交互关系和数据流向,对业务复杂的系统来讲,业务建模能够清晰地呈现系统业务,为性能测试提供指导做用
(3)肯定性能目标
性能测试目标根据性能测试需求和用户活动分析结果来肯定,肯定性能测试目标的通常步骤是首先从需求和设计中分析出性能测试需求,结合用户活动剖析与业务建模的结果,最终肯定性能测试的目标。
对于性能目标,不能是一句响应时间不能太慢,或是要能稳定运行就完了的,由于这样的目标在测试执行时会遗留下无尽的麻烦。一个较为详细的性能目标以下:
系统在5秒响应时间内处理100个并发用户对业务A的访问,此时服务器的CPU占用率小于75%,内存使用率小于70%。
固然客户给出的需求可能只关注响应时间,或者关注其余的某些场景下的性能指标,但都须要保证肯定的性能目标,这样才能保证性能测试良性地进行下去。
(4)制定测试时间计划
主要是给出性能测试的各个活动起止时间,为性能测试的执行给出时间上的估算。
(1)测试环境设计
测试环境设计是测试设计中不可缺乏的环节。性能测试的结果与测试环境之间的关联性很是大,不管是哪一种领域内的性能测试,都必须首先肯定测试的环境。
对于“能力验证”领域的性能测试来讲,测试首先就已经明确了是在特定的部署环境上进行,所以不须要特别为性能测试设计环境,只须要保证用于测试的环境与从此系统运行的环境一致便可。
对于“规划能力”领域的性能测试来讲,测试环境不特定,但也须要设计一个基准的环境。
对于“性能调优”领域的性能测试来讲,须要有性能测试来衡量调优的效果,所以必须在开始就给出一个用于衡量的环境标准,并在整个调优过程当中,保证每次测试时的环境保持不变。
这里的测试环境包括的不只仅是软件环境和硬件环境,还有一个你们都容易忽略的数据库环境,在一个几乎为空的数据库和一个已有50000条数据库的环境上,一样执行查询、增长和删除数据的操做获得的响应时间明显是不一样的。所以若是保证数据库环境稳定,建议备份数据库,每次性能测试开始时恢复相同的数据库备份。
(2)测试场景设计
测试场景模拟的通常是实际业务运行的剖面,其包括业务、业务比例、测试指标的目标以及须要在测试过程当中进行监控的性能计数器。测试场景的示例以下:
场景名称 |
场景业务及用户比例分配 |
测试指标 |
性能计数器 |
用户登陆 |
登陆业务,100%用户 |
响应时间 |
服务器CPU Usage |
标准平常工做 |
增长数据,40%用户 |
响应时间 |
服务器CPU Usage |
在性能测试执行中有时是执行单独的某一功能的性能测试,这样只能对某一功能验证,也就是说,其余业务几乎不产生压力的状况下,某一功能具备什么样的性能表现,这显然是不符合实际的运行环境的,体现的结果也没法反映被测系统的性能表现。
(3)测试用例设计
测试用例是对测试场景的进一步细化,细化内容包括场景中涉及业务的操做序列描述、场景须要的环境部署等内容。
性能测试的测试用例与功能测试的用例类似,下面是一个登陆业务的测试用例。
一、用户进入登陆页面
二、用户输入正确的用户名和口令
三、用户点击“登陆”按钮
四、等待直到出现登陆成功的页面,判断该页面成功显示的方法是HTML页面内容中的“欢迎”文本
(4)脚本开发
一个测试脚本通常包含一个业务操做,如登陆的脚本就包含上述测试用例中的登陆业务的程序化描述。测试脚本的开发一般基于“录制”,依靠工具提供的录制功能,能够将须要性能测试关注的业务在工具的录制下操做一遍,而后基于该录制后的脚本,对其进行修改和调试,确保其能够在性能测试中顺利使用。最经常使用的脚本修改和调试技巧是“参数化”、“关联”和“日志输出”等。
(1)创建测试环境
该活动用于搭建须要的测试环境。在设计完成用例以后就会开始该活动,该活动是一个持续性的活动,在测试过程当中,可能会根据测试需求进行环境上的调整。
创建测试环境通常包括硬件、软件系统环境的搭建,数据库环境创建,应用系统的部署,系统设置参数的调整,以及数据环境准备几个方面的工做内容。
测试环境的维护,指的是为了测试结果的可比性,通常都须要在每次运行测试结束后恢复初始的测试环境。
(2)部署测试脚本和测试场景
在创建和合适的测试环境以后,接下来的工做是部署测试脚本和测试场景。部署测试脚本和测试场景活动经过测试工具自己提供的功能来实现。
部署活动最终须要保证场景与设计的一致性,保证须要监控的计数器都已经部署好了相应的监控手段。
(3)执行测试和记录结果
准备好环境和部署好测试脚本以及场景后,就能够执行测试并记录测试结果了。在测试工具的协助下,测试执行是很是简单的操做,通常只须要使用菜单或是按钮就能够完成;记录测试结果也能够依靠测试工具完成,经过测试工具的Monitor模块,能够获取并记录须要关注的性能计数器的值。
在测试工具自己不提供对须要关注的性能计数器进行监控的功能时,能够用一些操做系统的工具,自行编制部分脚本解决这个问题,通常的方法是用脚本调用操做系统提供的工具,在脚本实现中将各性能计数器值分析出来并按照必定格式记录在本地文件中。
测试分析过程用于对测试结果进行分析,根据测试的目的和目标给出测试结论。
性能测试的挑战性很大程度上体如今对测试结果的分析上,能够说,每次性能测试结果的分析都须要测试分析人员具备至关程度的对软件性能的了解、对软件架构的了解、对各性能指标的了解。
测试分析过程是一个灵活的过程,很难给出一种具体的、能适应各类性能测试须要的统一的过程活动列表。
性能分析的通用方法之一是“拐点分析”的方法。“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法,该方法的基本思想是基于这个事实:性能产生瓶颈是因为某个资源的使用达到了极限,此时的表现是随着压力增大系统性能表现急剧降低,所以,只要关注性能表现上的“拐点”,得到“拐点”附近的资源使用状况,就可以定位出系统的性能瓶颈。