测试逍遥子的博客

性能测试方法1、验收性能测试模拟生产上线业务环境，测试是否满足性能需求特点：确定用户的环境用户需求的性能指标执行、分析结果验收性质测试结果要有客观性2、负载测试主要考察软件系统在既定负载下的性能表现，其中既定负载一般是指客户需求的负载。测试指标一般体现在：响应时间、交易容量TPS(或者吞吐量)、并发容量以及资源使用率等。3、压力测试为了考察软件系统在极端条件下的表现，我们需要进行压力测试。其中极端条件可以是超负荷的交易量和并发用户数。

项目中使用Jmeter进行大并发压测时，单机受限内存、CPU、网络IO，会出现服务器压力还没有上去，但压测服务器由于模拟的压力太大死机的情况。JMeter的集群模式可以让我们将多台机器联合起来。一起产生负载，从而弥补单台机器负载生成能力不足的问题。分布式压测原理控制机为Master，负载机为Slave；Master启动后，会拷贝jmx脚本文件到所有的Slave上；Slave会回传压测数据给Master，最后由Master汇总出结果文件；

常见的一些性能缺陷表现及如何进行定位分析并且调优。注意事项1、断言在压测时，为了判断发送的请求是否成功，一般会通过对请求添加断言来实现。使用断言时，建议遵循如下规范：①断言内容尽量以status/code、msg/message来判断（当然前提是接口设计遵循Restful规范）Jmeter示例：阿里云PTS：如果使用的是PTS压测，则断言设置中，以code/status、msg/message等于对应的值为准；

压测的目的对于Web接口压测的目的最终是要在对数据库造成压力的情况下观察压测服务器的cpu是否达到预警值、memory是否发生激变甚至泄露、响应结果的error率以及数据库服务器读写方面的情况是否正常等等情况。测试环境的准备我们要准备压测服务器和压力机，并建立二者之间的联系。压测服务器用来提供服务的，也就是我们的测试服务器，上面发布的是压测分支，我们首先要基于压测基准分支拉一个压测分支并push到远端，然后把开发的代码合到压测分支上再push到远端，发布到压测服务器。

性能测试需求分析性能测试需求分析，与传统的功能测试需求分析有所不同，功能测试需求分析重点在于从用户层面分析被测对象的功能性、易用性等质量特性，性能测试则需要从终端用户应用，系统架构设计，硬件配置等多个维度分析可能存在的性能瓶颈的业务。性能测试必要性评估任何项目在开始性能测试之前，都需要进行必要性评估，通过必要性评估活动，确认被测对象是否有必要实施性能测试活动，千万不可为了性能而性能。通常情况下，必要性评估可以设定不同条件，不同权重进行分析，将评估项分为关键评估项和一般评估项。

Jmeter执行原理Jmerer通过线程组来驱动多个(也可以理解为LR的虚拟用户)运行测试脚本对目标服务器发起大量的网络请 求，在每个客户端上可以运行多个线程组，也就是说一个测试计划可以包含N个线程组。线程数 一个线程可以理解为对应模拟一个用户，所以线程数越多，那么也就认为可以模拟的用户数越多。线程属性1、线程数1个线程可以理解为对应模拟1个用户，所以线程数越多，那么也就认为可以模拟的用户数越多。2、Ramp-Up时间(秒)

涉及抢购、秒杀、抽奖、抢票等活动时，为了避免超卖，那么库存数量是有限的，但是如果同时下单人数超过了库存数量，就会导致商品超卖问题。那么我们怎么来解决这个问题呢？sql1 : 查询商品库存 if(库存数量 > 0) {// 生成订单 . . . sql2 : 同时库存 - 1 }当没有并发时，上面的流程看起来是再正常不过了，假设同时两个人下单，而库存只有1个了，在sql1阶段两个人查询到的库存都是>0的，于是最终都执行了sql2，库存最后变为-1，超售了，这不是我们想要的结果吧。解决这个问题思路。

性能分析前提：性能分析的前提除了需要丰富的性能测试监控（如PTS自身的客户侧监控、基础类监控-阿里云监控、应用类监控-ARMS监控等），还需要具备相关的技术知识（包括但不限于：操作系统、中间件、数据库、开发等）。流程：很多情况下压测流量并没有完全进入到后端（服务端），在网络接入层（云化的架构，例如：SLB/WAF/高防IP，甚至是CDN/全站加速等）可能就会出现由于各种规格（带宽、最大连接数、新建连接数等）限制或者因为压测的某些特征符合CC和DDoS的行为而触发了防护策略导致压测结果达不到预期。

android的app性能测试包括的测试项：响应、内存、CPU、FPS、GPU、耗电、耗流量响应响应主要测试点：启动：首次启动app的时间间隔（只是启动时间，不包括页面加载）热启动：非首次启动 app的时间间隔（只是启动时间，不包括页面加载）完全启动：从启动到首页完全加载出来的时间间隔有网启动：从发起跳转，到页面完全加载出来的时间间隔无网启动：从发起跳转，到页面完全加载出来的时间间隔 （在项目中，主要测试关注点是冷启动，热启动）测试方法：使用adb命令冷启动。

一般推荐，如果你：没啥人用的服务 tps 20，返回有300ms就行了；十万到百万级的服务，响应能达到tps50 /200ms就可以了；后台服务，能达到tps 20 / 200ms即可（通常后台同时使用也没多少人）；秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间（具体情况还是要看业务量）背景：做项目开发的时候，不止一次被性能测试问“这个服务性能要求是多少？”他期望能得到一个这次接口TPS压到50还是100，返回时间是100ms还是200ms的回答。

随着银行业数字化转型的日益深入，银行信息系统的规模和复杂度日趋庞大，系统之间的耦合度越来越高，交易链路的长度和复杂度也日益增加，交易链路中任一个环节出现性能问题均可能导致交易操作失败，甚至影响整个系统和关联系统的运行。性能测试作为系统投产前性能把控的最后一道关口，其效果影响着生产系统的稳定运行，而当前性能测试主要以系统为维度进行测试。如何对交易链路尤其是关键链路进行有效的性能测试，从而提前避免可能的生产问题，成为性能测试面临的挑战。

性能测试按照不同视角，可以分为以下几类：用户视角的性能：用户角度感受到的网站响应速度的快和慢。从用户在浏览器输入网址/打开应用，到整个页面呈现给用户的耗时。包含了用户端发送请求，服务端收到并执行请求，返回请求，客户端收到之后渲染的总时间。开发人员视角的性能：包括系统吞吐量，并发处理能力，系统稳定性，响应延迟等。如果发现有不满足要求的地方，需要定位出问题所在，并给出解决方案。

性能场景——稳定性场景提起稳定性测试，有人会说7*24小时跑脚本，连续执行2天两夜，跑一晚上…个人觉得这些都没有任何依据，脚本的执行时间难道是一拍脑袋想多少就多少？我非常不赞同这些观点，凡事又要有依据，比如724小时执行脚本，是根据什么判断执行724小时后就一定没有问题，线上就一定不会出现问题呢？那么，稳定性场景应该怎么设计呢？个人认为设计稳定性场景只需要考虑2个关键点，运行时长和压力量级，下面针对这两个关键点进行说明为什么说运行时长是一个重要的关键点呢？我们先想一想稳定性场景的目标是什么呢？

性能测试：最佳并发与最大并发最佳并发正确率达到预期（如：99.9%）、平均响应时间达到预期（用户满意）的并发数（且最大吞吐量对应的并发数。如果前后两个并发数间隔较大，吞吐量值差值较小，选择较大并发数作为最佳并发）。但根据经验值（比对历史性能数据），选取正确率达到预期、平均响应时间达到预期（用户满意）的并发数几乎就是最佳并发。最大并发正确率达到预期（如：99.9%）、平均响应时间达到容忍界限（用户可容忍）的并发数。

并发用户数：是指现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)。并发用户数和注册用户数、在线用户数的概念不同。并发用户数一定会对服务器产生压力的；而在线用户数只是 ”挂” 在系统上，对服务器不产生压力；注册用户数一般指的是数据库中存在的用户数；TPS：Transaction Per Second, 每秒事务数，是衡量系统性能的一个非常重要的指标。

响应时间大概规范：1-3秒，属于优的表现；3-5秒，可以接受，属于中间的表现；5秒以上，无法接受；系统资源：一般大于70% cpu 内存 可能达到瓶颈平均负载所有的数据都是来自数据库：连接数：连接数泄露（使用了连接数，但是没有释放）；读写速度：IOPS；

Jmeter的集群模式可以让我们将多台机器联合起来一起产生负载，从而弥补单台机器负载生成能力不足的问题。假设我们的测试计划会产生100个threads，我们使用6台机器进行分布式测试的时候，一共会产生100 * 6 = 600的负载。日常情况，大部分的性能需求，单台压测机就可以抗住的。4C8G的window server机器，使用UI方式，最高压测过2000并发（RT 20ms以内），单机没什么问题（当然如果IO很高的话，注意压测机网卡可能会先出现瓶颈。超过2000并发，可使用分布式。注意事项。

安装常见问题hostname 命令获取机器名称，追加一个映射 iZwz95j86y235aroi85ht0Zwindows用户 修改c:\windows\system32\drivers\etc\hosts文件，增加一条域名 与IP的映射拥有RMI over SSL的有效密钥库，或者禁用了SSL。禁用SSLjmeter.property里面 server.rmi.ssl.disable 改为 true，表示禁用。

性能测试实战 - 部署1、什么时候做性能测试①项目刚上线的时候：用户为0（避免用户量突然增加，系统承受不住）。②发布活动的时候：节日商品秒杀，打折优惠，某时间段促销，大批量用户集中访问下单（平时没这么多用户）。③版本迭代的时候：新功能产生（类似刚上线）。④高负载的稳定性：推出免费课程，一天内就会持续增长，要看负载，一个视频网站最多容纳多少人（只进不出）。2、如何模拟生产环境①等比模拟硬件：生产环境是100台，那么测试就等比缩小为10台。

单个接口的压测（基准容量测试）目的：验证被测试接口的最高TPS（基于一定的响应时间ms)，TPS是从服务端角度验证接口性能；方法：采用梯度压测方法，按照设置的梯度逐步递增压力，观察TPS曲线变化（测试时注意递增的粒度，粒度需要细化到TPS曲线跟随梯度压力曲线呈梯度变化）最大TPS：当梯度压力增加时，TPS趋于稳定不再增加，继续增加压力接口响应时间不断增加，该TPS即是最大TPS（对于无明显性能拐点的系统适用）；

WebServer服务优化对于Web服务性能优化的方向，一般是：页面静态化：比如访问的页面，先进行静态化后提供访问，减少DB负担；减少页面的Size：减少图片尺寸、CSS合并、JS精简等；客户端缓冲图片、样式等；去掉无用请求与数据；对数据做异步处理(非常关键)；只能DNS及CDN加速，让响应数据离用户更近，规避缓解网络瓶颈。程序优化程序优化是治本的方法，也是我们大部分来解决性能问题的一个措施。

两种性能指标业务指标；技术指标；通常我们会从两个层面定义性能场景的需求指标，它们有映射关系，技术指标不能脱离业务指标1、并发狭义：指同一个时间点执行相同的操作（如：秒杀）广义：同一时间点，向服务器发起的请求（可能是不同的请求）只要向服务器发起请求，那么服务器在这一时间点内都会收到请求（不管是不是同一个请求）场景类比高速公路上，同时有多少辆车经过同一个关卡，但不一定是同一个牌子的汽车并发用户数（重点）同一时间点，发出请求的用户数，一个用户可以发出多个请求；场景不一定是同一个；

什么是性能测试？性能测试是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。概括为三个方面：应用在客户端性能的测试；应用在网络上性能的测试；应用在服务器端性能的测试；通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。目前绝大多数应用都是基于网络的分布式应用，我们无法知道用户数量，用户场景的不确定性，导致系统测试时，不仅仅是功能，业务逻辑，接口测试，还要测试系统性能。

为什么要使用分布式？做性能测试时，如果被测系统性能比较好，或者系统项目比较大，那么一般都会要求能支持比较高的并发用户数。而我们做性能测试时，发起请求的机器，硬件资源是一定的，不可能配置无限大。所以，它能发起的并发用户数是有限的，而当我们发起方一台电脑能发起的并发用户数小于我们性能测试期望的并发用户数时，我们就会自然而然想到增加发起方的电脑。增加发起方电脑数量，那么，发起的并发用户数累加，就增大了。

开始性能测试前需要了解的内容：①项目具体需求。②指标：响应时间在多少以内，并发数多少，tps多少，总tps多少，稳定性交易总量多少，事务成功率，交易波动范围，稳定运行时长，资源利用率，测哪些交易，哪些接口,测试哪些场景。③环境：生产环境服务器数量，测试环境服务器数量，按照资源配比得出测试指标。④协议：系统用什么协议进行通讯。⑤压力机数量：如果并发用户数太多，需要把压力发到不同的压力机，不然可能会存在压力机瓶颈问题，导致tps和响应时间抖动。⑥交易占比：分析线上日志得出tps占比。

从小入手，从简单的开始，然后慢慢的做更系统更复杂的性能测试。1、确定需求刚接触性能测试的同学往往不知道性能测试是有需求的。比如：给我测一下系统的性能；线上xx服务器挂了，能否重现一下线上问题；如果你是性能测试同学，假设时间有限，这两个需求你只能接一个，你是接哪个？很多同学会选第一个，因为第一个需求似乎是性能测试的需求，第二个跟性能测试似乎没有特别强烈的关系。

压测过程中，我们除了需要关注客户端的pqs、并发量等指标外，还需要密切关注服务器资源相关的指标，例如：cpu使用率、内存使用率等等。1、CPU使用率CPU使用率代表程序占用的CPU资源，CPU使用率 = 1 - CPU空闲时间/总CPU时间，在性能测试中，CPU使用率是个非常重要的指标。细分为如下指标：用户态（user）：用户程序运行时间占比。当该值很高时，说明用户程序处理时间过长，需要优化代码；系统态（sys）：系统程序运行时间占比。

我们谈到测试设计，往往是指功能测试设计，往往忽视性能测试的场景设计，例如，如何进行性能测试时，如何把性能负载加上去，就需要根据业务进行负载发起策略的设计，包括逐步加载、一次性加载和峰谷加载等。不管是否重视，性能场景应该说是在性能测试中非常关键的一个环节。经常在一些场合被问到性能场景的设计问题，但是大部分都是和容量相关的。但为什么稳定性问的人少呢？稳定性是不是说在容量场景做好了之后就水到渠成了呢？首先稳定性场景的设计应该说比容量场景设计要简单一点。