软件性能测试

软件性能测试孙晓明2018-09-25内容概要1.性能测试介绍2.性能测试过程3.性能测试举例1.性能测试介绍1.1什么是软件性能1.2性能指标介绍1.3什么是性能测试1.4性能测试类型1.5性能测试模型举例1.1什么是软件性能系统的性能是个很大的概念，覆盖面非常广泛，对一个软件系统而言，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。用户视角的软件性能管理员视角的软件性能开发人员视角的软件性能1.1什么是软件性能1.1.1用户视角的软件性能从用户角度来说，软件性能就是用户操作软件的响应时间。访问软件每个功能或页面的响应速度快不快、卡不卡。1.1什么是软件性能1.1.2管理员视角的软件性能系统的响应时间；系统运行时服务器的状态，如CPU、内存、磁盘、网络带宽等使用情况；系统是否能够实现扩展；系统支持多少用户访问；系统支持多大数据量的处理；系统性能可能的瓶颈在哪里；系统是否支持7*24小时的业务访问。1.1什么是软件性能1.1.3产品开发人员视角的软件性能用户关心的响应时间；管理员关心的系统可扩展性等；架构设计是否合理；数据库设计是否合理；代码是否存在性能方面的问题；系统中是否有不合理的内存使用方式。1.2性能指标介绍并发用户数-Vusers响应时间–ResponseTime吞吐量–Throughput事物-Transcation事物处理能力-TPS(TranscationPerSecond)点击率-HPS(HitPerSecond)资源利用率–SystemResource1.2.1并发用户数(Vusers)并发用户数是指在某一给定时间内，某个特定点上进行会话操作的用户数。并发的两种情况：一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。求并发用户数公式在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务的角度关注应该设置多少个并发数比较合理。下面找一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员工登录签到系统的时长为5分钟。可以用下面的方法计算。C=1000/30*5=166.7C表示平均并发用户数，那么对这个签到系统每分钟的平均在线用户数为166当然，在性能测试上，任何公式都不是严谨的，最重要的是对系统做出有效正确的分析。1.2.2响应时间(responsetime)响应时间指的是客户端发出请求到得到响应的整个过程所经历的时间。一般我们对平均响应时间感兴趣，在负载增大时响应时间的一贯性也很重要。提高负载后若响应时间曲线出现锯齿，往往说明性能乏善可陈，还有潜在的不稳定。1.2.3吞吐量(Throughput)吞吐量：指在一次性能测试过程中网络上传输的数据量的总和。对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。如一个大型工厂，他们的生产效率与生产速度很快，一天生产10W吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉2吨的货物，比喻有些夸张，但我想说明的是这个运输能力是整个系统的瓶颈。提示：用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开一天一夜，流出10吨水；10个水龙头开1秒钟，流出0.1吨水。当然是一个水龙头的吞吐量大。你能说1个水龙头的出水能力是10个水龙头的强？所以，我们要加单位时间，看谁1秒钟的出水量大。这就是吞吐率。吞吐率：单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。其实，不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。不过以不同的方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式表示的吞吐量主要受网络基础设置、服务器架构、应用服务器制约；以请求数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。1.2.4事物(Transaction)事物：就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程。这些我们都可以看作一个事务。那么如何衡量服务器对事务的处理能力。又引出一个概念----TPS。1.2.5事物处理能力-TPSTPS（TransactionPersecond）每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。1.2.6点击率-HPSHPS（HitPersecond）点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。每秒钟用户向web服务器提交的HTTP请求数。这个指标是web应用特有的一个指标；web应用是“请求-响应”模式，用户发一个申请，服务器就要处理一次，所以点击是web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。1.2.7资源利用率(SystemResource)资源利用率是指系统资源的使用程度，比如应用服务器或数据库服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。1.3什么是性能测试性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的一种测试。1.4性能测试类型负载测试压力测试（健壮性测试）稳定性测试（疲劳强度测试）1.4.1负载测试(loadtest)负载测试：主要用于描述常规的性能测试，通过模拟生产运行的业务压力和使用场景组合来测试系统的性能是否满足生产要求。通俗的说，这种测试方法的目标就是给系统以期望的负载量验证系统的能力。也就是说，没有速度要求的情况下，我的应用能支撑多少的并发用户，这里更多的是考虑容量。1.4.2压力测试(stresstest)压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收用户请求的性能点，来获得系统能提供的最大的服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下应用程序的性能会变得不可接受。超过容量压力下的表现，也关注应用的恢复能力，这里更多的是关注系统的变化。1.4.2压力测试（stresstest）用户量压力测试数据量压力测试1.4.3稳定性测试(stabilitytest)稳定性测试也叫-疲劳强度测试，通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。稳定性测试可以发现一些系统的性能和资源泄漏等问题。1.5性能测试模型举例-1理发店模型之性能测试相信大家都进过或见过理发店，一间或大或小的铺面，1个或几个理发师，几张理发用的椅子和供顾客等待的长条板凳在这个理发店中，我们事先做了如下的假设：1.理发店共有3名理发师；2.每位理发师剪一个发的时间都是1小时；3.我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。1.5性能测试模型举例-2通过上面的假设我们不难想象出下面的场景：1.当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；2.当理发店内同时有两位顾客，就会同时有两名理发师在为顾客服务，另外1位发呆或打杂。仍然是1小时后，两位顾客剪完头出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；3.很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。1.5性能测试模型举例-3不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。如果你可以理解上面的这些场景，就可以继续往下看了。在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了2.性能测试过程测试需求分析制定测试方案执行测试方案测试结果分析系统性能调优编写测试报告2.1测试需求分析测试需求分析主要有以下的几个关键点：测试的目的是什么性能符合性验证：验证是否满足用户和应用的需要。性能能力验证：确定性能极限、是否存在性能瓶颈。性能调优：对系统的性能进行调试、优化。2.1性能测试需求分析性能测试要素分析：用户访问数量（用户并发数量）需要验证性能的功能点需要制定符合实际应用的场景（登陆、注册、查询、新增、上传、下载、购物并发）用户分布（即执行每种功能场景的用户数）硬件环境（包括网络环境）软件环境数据量其它分析系统运行中所出现的问题有什么特征或规律疲劳测试执行时间多少性能需求的指标是什么等2.2制定测试策略测试目的不同，则相应的测试策略不同。性能符合性验证—负载测试、疲劳强度测试。性能能力验证—压力测试、疲劳强度测试。性能调优—测试-调整-测试。负载测试、压力测试、疲劳强度测试。2.3制定测试方案测试需求测试策略测试场景测试环境测试准备人员及时间安排问题与对策2.4执行测试方案搭建测试环境录制脚本、编辑优化脚本布置测试场景执行测试场景2.5测试结果分析性能符合性验