性能测试初体验——基本概念

• 正常工作过程中，并不是所有的接口都要做性能测试
• 只有核心功能，用户使用量最高的，或者优先级最高的接口才需要做性能测试
• 然后针对重点的业务做性能测试
• 当有一天，平台中大部分接口的性能测试已完成；大部分业务的性能测试已经完成，你就可以对领导说：平台上基本的链路的性能测试都覆盖到了，也可以说基本全链路的性能测试已经完成

性能测试的意义价值和分类

价值

• 减少硬件上的投入，例如硬件需要升级，进行性能测试，对比服务是否有性能上的提升(接口响应速度等)
• 可以预估生产环境，硬件配置和服务数量(根据线上的活跃用户)
• 日常工作中，功能测试正常的情况下，及时进行性能测试可以尽早的发现一些性能上的隐患
• 重复的数据，进行性能测试，可能发现数据互串的问题(例如一个浏览器登录不同的账号，可能会出现错误账号的情况)
• 性能测试一般来说，先做核心功能和用户使用量最多的部分
• • 一般先做单接口，然后再做任务流程
• • 核心功能和用户使用最多的完成后，再按照优先级向周边覆盖功能

分类

• 按照端分：web端，app端，PC端
• 后端——服务器接口测试
• 只要通过服务器的接口的新能测试，提升了接口的性能，不论你是哪个端的用户，用户的相应时间都能缩短，用户的体验都能提升

等级

• 初级性能测试：懂得性能测试概念，有性能测试的思维，能写性能测试脚本
• • jmeter的接口测试脚本，与性能测试脚本——记住，千万不要说jmeter写接口测试脚本，懂jmeter就知道怎么做性能测试
• 中级：具备性能场景设计，搭建性能测试的环境(监控环境)，看门懂性能测试指标数据，看懂性能测试监控，具备一定的性能分析能力
• 高级：性能问题根源的定位、修复、调优技能，和比较丰富的经验

概念

Jmeter测试接口和性能的区别

• 使用Jmeter可以进行性能测试和接口测试

接口测试——功能测试

• 接口测试属于功能测试，主要验证实际结果和预期结果的不一致
• • 是模拟单个或者少量用户进行接口调用。
• • 模拟的行为是串行，单线程
• • jmeter的脚本中是在一个线程组下面，放很多个接口
• • 接口测试的脚本，只要功能实现，不考虑性能
• • 关注预期结果和实际结果，存在断言

性能测试

• 性能测试得到的结果是性能指标，主要通过性能指标数据的分析，判断是否有性能问题
• • 其关键在于：**多个人同时使用，分析性能指标背后的意义，接口的调用结果可能会出现问题，要确定性能指标　**
• • 性能测试的预期结果和实际结果是否一致不是重点，性能测试脚本，不一定要断言
• • 因为性能测试是要模拟很多人同时调用接口，主要查看在这种情况下性能指标、服务器的运行状况
• • 即性能测试是多个人同事使用功能时，各项性能指标的情况，再分析指标数据背后的意义，分析可能存在的意义
• • 性能测试是多个人并行操作
• • 性能测试，要考虑jmeter脚本本身的性能（beanshell元件，在接口测试的时候可以用，因为只要考虑功能实现，不考虑新能。但是性能测试不能用此元件，因为这个元件性能比较差）

性能测试的概念

• 性能测试的概念：测试工程师通过工具，找出或者验证系统在不同情况下的性能指标值
• • 通过工具，即性能测试要模拟多用户并发，没有工具来实现并发，手工是做不了的
• • 找出：是第一次做性能测试得到的指标数据，这些指标数据作为将来的参照物（参考信息）

性能测试思维

• 做功能的时候，思维就是找bug，单一请求，最终的结果是比较预期结果和实际结果是否一致
• 性能测试，思维就是多用户+并发请求**,其结果是性能指标数据，来分析性能问题**
• • 思考性能问题的时候，要先从单一用户开始，从简单入手，然后再扩展到多用户并发
• • 性能测试需要用到串行（单线程一个接口一个接口的调用） 并发/并行
• • 性能测试的步骤：得到指标数据；懂得指标数据的意思，使用指标数据来综合分析问题

并发和并发用户数

• 并发：同一个时间点，发起的请求（这个请求可以相同，也可以不同）
• • 性能测试中，宏观的并发，可以是不同的请求，微观的并发，指的是相同的请求
• 并行：同时，做很多事情
• 并发测试的定义：要模拟多个人，同时向服务器发起请求，测试服务器在一定时间中，能够处理多少请求量
• 并发用户数：同一个时间点发起的请求人数

Http协议的特性

• http协议是一个同步协议
• 同步协议：发出去的请求，必须要收到响应，才会发起下一个请求
• 收到的响应不一定都是正确的结果，只要收到http的响应状态就认为收到响应
• • 状态码为1XX，2XX，3XX则认为请求处理成功
• • 4XX，5XX则认为请求处理失败
• 与同步协议对应的，还有异步协议，只要发出去的请求，不需要等待响应结果，就可以持续发送请求，就是异步协议
• 做性能测试，不要人为的去控制请求量，如果控制了，就不能准确的测试出服务器真实的处理能力

基准测试

• • 基准：基准中的并发用户数是通过负载测试得到的最大可接受的并发用户数（例如接口返回的平均响应时间可接受），用找到的并发用户数做性能测试，就可以得到相应的性能指标数据，这个性能指标数据就可以作为一个基准数据
• 首次确定基准数据的性能测试，就叫做基准测试
• • 后续版本进行更新之后，用相同的并发用户数得到的性能数据，和基准数据进行比较，就可以分析得到相应的结果
• • 验证：以上说法中，做性能测试得到的性能指标和基准进行比较，确认是否存在性能问题，需要进行调优，这就是验证
• • 在做性能测试的时候，经常会出现，有明显的的性能指标数据，反应出性能问题，此时就可能存在因为分析性能问题而停止性能测试的情况，这是不正确的；应该先将性能测试流程完成之后，再分析之前的性能问题
• 在测试过程中，只要能够得到产品更高(最大并发用户数高)、更快(借口平均响应时间快)，更强(服务器的承受能力更强)的相关测试吗，都是广义上的性能测试

负载测试

• 概念：逐步增加并发用户数，向服务器发起请求(并发测试)，测试系统性能的变化，观察性能指标，通过这些指标分析，判断出服务器/系统所能够承受的最大的负载量
• • 方式：逐步增加并发的用户数量，观察性能指标
• • 最终得到的结果：最大可接受并发用户数的区间，然后逐步缩小区间，最终确定最大可接受并发用户数
• • 最大可接受并发用户数或者最大并发用户数是测试出来的，而并非计算出来的

并发用户数

• 最大可接受并发用户数 VS 最大并发用户数：
• • 最大可接受的并发用户数，要小于最大并发用户数
• • 最大并发用户数，是所有的请求，都不能被服务器处理的极限情况（服务器崩了），也就是说当服务器出现持续请求报错，资源利用率过高的时候，这个时候的并发用户数
• 但是性能测试中，一般使用的是最大可接受的并发用户数
• 最大可接受的并发用户数：满足可接受标准时的并发用户数，这个时候的并发请求几乎没有失败的
• 可接受标准——就是最大可接受并发用户数的行业标准，HTTP协议的场景下
• • 错误率小于0.1%
• • 平均相应时间要小于1.5s
• • 服务器资源利用率小于80%

线程数、并发用户数和账号

• 并发用户数：同一个时间点，发起请求的人数，模拟用户（人）
• 并发用户数 VS 用户VS 账号
• • 并发用户数和账号并不一定是一 一对应的关系（即并发用户数和账号不存在数量相等的强关系），一个用户可以有多个账号
• • 账号代表一个系统中的唯一身份，但是用户在系统中可以有多个身份
• • 账号和用户之间可能会存在多对多的关系（n对n）
• 使用线程数模拟并发用户数
• • 不同的工具，可以使用进程数、线程数、协程数来代替并发用户数
• • jmeter中，使用线程数来代替并发用户数
• • loadrunder，可以用进程数，线程数两种来代替并发用户数，默认是线程数
• • locust：用协程数来代替并发用户数
• • ngrinder：使用进程+线程的组合来代替并发用户数

问题：性能测试是否就可以用1个账号进行？是否要准备一批账号？

• 如果你的系统，一个账号可以反复登录，可以反复登录，重新登录之后用户的身份信息不变(例如token)，不会失效就可以用同一个账号；
• 如果身份信息会有变化，重新登录之后前面的登录鉴权会失效，就需要准备一批账号
• 因为前面账号的身份信息一旦变化，就会影响前面那一批请求的后续处理
• 一般情况下，建议做性能测试时，使用多个账号，用户的数量，一般建议远远大于并发用户数

性能测试——通俗

• 通过负载测试，找到最大可接受的并发用户数
• 持续请求一段时间（这个时间为几分钟到几十分钟），获得性能指标（工具/监控平台展示的指标）
• 然后通过这些性能指标，判断是否存在性能问题
• 如果有性能问题，再进行分析，调优，在验证测试的过程

压力测试——很少做

• 压力测试：用较大的并发用户数，持续运行比较长的时间，看系统的服务和资源利用情况，是否存在稳定性的问题
• • 关键点：较大的压力，较长的时间
• • 现在的企业，较长的时间一般是以小时为单位，例如连续不间断24小时
• • 输出结果：服务器是否存在稳定性的问题
• 较大的并发用户数的标准：范围时[1，最大可接受并发用户数]，行业中存在一个20%的范围和80%的范围
• • 20%的范围：指的是区间为:[1，20%的最大可接受并发用户数]，主要测试服务器在长时间、低并发量的情况下，能否正常运行，发现不稳定的情况后，发现问题的定位难度就会更低
• • 80%的范围：指的是区间为:[1，80%的最大可接受并发用户数]， 用于测试服务器在比较高的并发请求时的稳定性
• 做压力测试的场景：当服务器或者生产环境有重启/宕机的现象的时候。一般会先采用20%的范围去长时间请求去排查问题

稳定性测试

• 定义：瞬间发起非常大的请求压力，看服务器的稳定性
• • 或者用比较大的请求量，持续请求服务器一段时间，看了呢服务器是否有不稳定的情况
• • 这里的稳定性，指的是：只要接口能够正常返回数据，没有报错即可，平均响应时间可以不考虑

容量测试

• 定义：数据库的表的数据量级别不同的时候的性能情况。即在做性能测试的时候，考虑数据库中的表在不同数据量级的时候，性能指标之间的差异
• • 换句话说：不改动脚本、参数产品的情况下，只变更数据库中表的数据量级别，对性能指标做一个对比，即是容量测试
• • 数据量级：数据库可存数据在10万-100万时，数据量级为10万，100-1000万时，数据量级为百万，以此类推
• • 或者说，当数据库中表的数据分别为10万或者百万的时候，分别在表中查询/插入数据，查看指标（例如平均响应时间）之间的差异
• 在做性能测试的时候，我们的项目的数据库表中的数据量级，默认应该与生产环境的量级一致
• • 注意，这里说的是数据库中的表，测试注册接口，用到的只有用户表，只关注用户表即可
• 数据库（关系型数据库）中的表，一般来说，其量级在10万级别以下，时间上几乎没有差距，只有数据量级在10万以上的时候，其平均响应时间才有明显的差距
• • 因此，一般而言，性能测试的表的数据量级在10万级别以上
• 性能测试的时候，数据库的量级要和数据库保持一致，这样才能保证性能指标差不多

在测试环境法中，数据库中表的数据量级，达不到生产环境的表的数据量级应该怎么办？

• 解决方式1：造数据，可以是假数据，只要数据量级达到就好
• • 真实数据 VS 假数据
• • 不需要多表关联的真实数据比较好创造，例如用户注册表，直接在用户表中添加数据即可
• • 需要多张表关联的数据不好创造，要考虑假数据，例如商品订单表，要关联商品，价格，用户等多张表
• 解决方式2：从生产环境将数据copy下来
• • 但是这种方式，要将部分字段做脱敏处理

领导问：我们的系统最大能支持多少人使用？

• 性能角度：体现出并发，同时使用的概念，最大可接受的并发用户数
• 功能角度：无限量

为什么被测项目的性能越好，jmeter能产生的并发用户数就越少？

• 1.项目性能越好，说明服务的处理能力就越强
• • 这样的话，jmeter发送到服务器的请求就能够越快的被处理
• • 而http协议是一个同步的协议，服务器处理完了，就会将结果返回给nmeter
• • Jmeter收到响应之后就会马上发送写一个请求到服务器
• • 这样的话，很短的时间内，一个并发用户发起的请求次数就很大
• • 计算公式：接口请求总量=一个人发起的请求数量*并发用户数
• • 在请求次数总量相相同的情况下，一个并发用户处理的快，那么发起请求的并发用户数就会少

**刚开始做性能测试的时候，增加一点用户并发量就会出现很多报错的情况，为什么？如何解决？

• 这个时候并不一定是性能瓶颈，很大的可能性是自己电脑或者脚本的参数有问题
• 因为HTTP协议在传输工具的时候，协议规定，报文中必须包含：发起方的ip地址，发起方的端口+数据+目的地的ip+目的地的端口
• 发起方的IP地址，不会变化，因为是一台jmeter发起的
• 发起方的端口，每个请求都要有一个端口，这个端口是从发起方的机器上申请
• • 但是机器上的端口数量是有限的，因为机器的位数(64位)是有限的，可能出现端口数量不够，导致请求失败的情况，每台电脑上理论的端口个数是65535个，但实际一台windows电脑一般会开放60000个左右的端口，但实际上只能使用1万个，开放的算口中有一些不能使用，因为已经被用掉了，例如数据库的3306端口，http的80端口，ftp的21端口，sftp的22端口，SMTP的25端口，tomcat的8080端口等等。
• 请求数据——可能不一样
• 目的地址IP，不会变——目的地址只有1个，就是你被测试的服务器
• 目的地址的端口不会变，就是被测服务器的端口
• HTTP请求的时候，保持着和服务器之间的会话连接，在会话没有完全断开之前，端口是不会被释放的；断开回话之后，端口才会被释放
• HTTP协议在三次握手之后，会保存一段时间的会话连接，防止服务器/客户端重新发起请求
• 手动缩短保持连接的时间，将长连接变为短连接，就可以尽快释放端口，增加端口的服用率

如果需要的并发用户数量很多，一台机器不够怎么办？

• 增加请求机器，每台机器上可用的端口是1万，10台机器就是10万个端口
• 在被测服务器的性能非常好的时候，发起方的jmeter的数量就得多

产品为1.0版本，从来没有上线应该怎么办？

• 预估产品上线一段时间之后，数据量级能达到多少
• 这里的一段时间，一般是说一年
• 以这样的数据量级，乘以1.2-1.5倍的数据量来进行测试

混沌测试

• 混沌测试类似于“故障演练”，不局限于测试，更倾向于直接实践，类似于探索性测试，实验本身没有明确的预期条件/输入步骤和实际结果，通过对系统或者服务器的干预，来观察系统的反应
• 将混沌测试融入在实验过程中，在生产环境小规模的模拟/测试环境上直接制造系统故障并定期的自动化执行实验，通过实验结果于正常结果的对比，确定故障的出现的现象，排查思路，解决方案等信息，为以后生产环境出现类似问题提供快速应急的处理方式，快速解决问题
• 这种测试的目的是：在测试环境上提前将生产环境中可能出现的问题，提前扼杀掉(将这些问题在测试环境上模拟/造出来，提前异常处理，提前规避掉)，提高产品的质量
• • 举个例子：https证书到期；服务器停电，服务器突然间挂掉了；服务器突然间断网了；云服务到期等等

配置测试

• 配置测试是指调整各种参数（例如链接池），查看不同参数/不同链接池下的性能指标会不会有变化

性能测试的步骤

• 如果要做性能测试，就需要设置最大可接受并发用户数，调用接口请求一段时间
• 最大可接受的并发用户数，需要通过负载设置来确定，判断标准是行业基本标准(如果公司没有相关设定的)
• 因此，做性能测试的步骤为：
• • 先做负载测试，确定最大可接受的用户数
• • 然后再做压力测试/性能测试
• 行业中，口语中所说的压测，其实是去做性能测试，即先做负载测试，再做性能测试，最终给出性能指标，如果测试有分析的能力，再通过指标来分析性能问题
• 一般情况下，领导说要做压测的场景，是存在服务器崩溃，或者服务器容易宕机的情况下，这个时候才有可能去做压力测试
• • 压力测试的时间一般是在几个小时，但是性能测试的时间的区间为几十秒到几十分钟即可
• • 因为负载测试是逐步增加并发用户数，每一次增加并发用户数之后，调用接口查看接口是否符合行业标准(错误率，平均响应时间，资源利用率等)，如果不符合标准，负载测试就完成了

性能指标

并发和并发用户数

• 并发：同一时间向服务器发起请求的数量
• • 狭义上来说：同一个时间点向服务器发起同一个接口请求的数量
• 辨析：在线用户数 VS 系统用户数 VS 并发用户数
• • 系统用户数：只要在产品中进行了注册/游客，就是系统用户。系统用户可能只是注册了/临时游客，可能再也不会使用，并不一定对产品产生请求压力
• • 在线用户数：正在访问产品的用户数（产品处于登陆状态的用户数），在线用户数也不一定对产品产生请求压力，因为可能存在只登陆不操作的情况，即挂机的情况
• • 行业中认为，只有5%-10%的在线用户数会对产品产生请求压力
• • 并发用户数：在同一个时间向服务器发起请求的用户数量
• • 并发用户数是性能测试的源动力(前提条件)
• • 并发用户数的实现：进程，线程，协程

响应时间

• 一个请求，从发起开始，经过网络传输到大服务器，服务器内部处理后经过网络传输返回给发起方，之间的时间差
• • 即响应时间(RT) = 网络传输时间*2 + 服务器处理时间+延迟时间(理想情况下不存在，现实会存在)
• • 响应时间不包含响应后前端的渲染时间——也就是说，这个时间小于用户能够感受到的时间
• • Jmeter这个工具，做性能测试的时候，并不具备解析html的能力，因此响应时间中不包含页面渲染时间
• • 因此有一个矛盾：性能测试接口的平均响应时间低，但是用户界面上感受的时间会很卡，就是因为渲染时间长，或者需要多个接口的数据组合才能渲染的吹啊导致
• • 网络传输时间越大，那么响应时间与务器处理时间的偏差就越
• 一般情况下的性能指标指的是：平均响应时间
• • 平均响应时间：所有接口的的响应时间的平均时间
• 平均响应时间并不能够反应某个接口的真实情况，但他能够反应大多数接口的真实情况
• 实际工作中，还有几个概念：
• • 90%的响应时间：90%的请求的响应时间是小于等于某个时间点；或者说是所有请求的响应时间，从低到高排序之后，第90%那个请求的响应时间
• • 95%的响应时间：95%的请求的响应时间是小于等于某个时间点；或者说是所有请求的响应时间，从低到高排序之后，第95%那个请求的响应时间
• • 99%的响应时间：99%的请求的响应时间是小于等于某个时间点；或者说是所有请求的响应时间，从低到高排序之后，第99%那个请求的响应时间
• 假设一家公司，自定义的标准是：90%的响应时间<1.5s，就是说绝大多数的请求响应时间要<=1.5s，只有少量的大于1.5s
• • 这样的话，用户的体验就非常稳定，几乎没有明显的时间波动

TPS

• TPS的概念：服务器每秒处理的事务数——衡量服务器性能最重要的综合指标数据；也是服务器综合处理能力的重要指标
• • TPS = 并发用户数*频率*1s；当TPS比并发用户数大的时候，可以继续增加并发用户数
• • Tps/ 并发用户数=频率(即每个人每秒钟发起的请求数)
• • 每个请求的平均耗时 = 1/频率数
• • 因此，用户发起请求的频率越高，每个请求的响应时间就越短，这样系统的性能就越好；频率越高，服务器处理的总量就越高，性能就越好
• 在性能测试中，假设请求频率不变，增加并发用户数，会导致TPS的值增大，
• • 但当总请求量达到服务器的最大处理能力时，TPS会保持平缓（用户数增加，请求频率减少，因为出现没有响应结果的情况）
• • 再过一段时间，就会下降，因为内耗严重，服务器的性能出现问题导致接口的请求报错

事务

• 一个完整的请求，即从发出请求，到接受到请求相应的过程
• 在Jmeter中，对事务有两种定义：
• • 默认的情况下一个取样器发起的一个完整的请求(从请求到接收到响应结果的过程)就是一个事务
• • 但Jmeter中，可以通过事务控制器将多个取样器打包成一个事务
• • 例如在功能测试的时候的流程，由多个接口组成，将多个接口打包成一个事务，那么一个流程从开始请求到最后一个接口的响应就是一个事务
• 在做性能测试的时候，用户发起请求的频率是不应该去限制的
• • 因为如果将频率做了限制，就不能真实的反应我们服务器的性能；
• • 因此，在使用jmeter做性能测试的时候，我们一般不添加定时器(集合点)
• https协议这种半双工的协议，一定是收到前一个的请求响应之后，才会发起下一个请求，因此，要实现TPS的计算公式的前提是：服务器会将之前发起的请求的响应数据全部返回回去
• • 例如，3个并发用户，每秒钟发起3个请求，1s的TPS就是15个请求，这就意味之，服务器必须在1s内将这15个请求处理并返回相应的响应结果才不会影响第2s发起的15个请求

QPS

• 定义：服务器每秒查询次数，是用户查询应用服务器资源，也可以是用户查询数据库服务器的数据
• TPS和QPS的关系
• • QPS并不一定等于TPS，即查询次数并不一定等于服务器的事务数，一般情况下QPS的值会大于等于TPS的值的
• • 一个事务，在服务器中查询k次，那么TPS就等于1，QPS就等于k
• • 因此，对于T（TPS），K（一个事务的查询次数），Q（QPS）之间的关系是：Q = KT；查询次数K一定大于等于1
• • 理解：服务器中的一个事务，在监控事务是否处理完毕的过程中，查询了k次进度，那么其QPS就等于k。一个请求事务是一个接口从请求到返回结果的处理过程，但查询只是接口处理过程中的某一个步骤
• • 因此在工作中常常将QPS作为TPS的原因是：QPS和TPS之间的关系成正比，QPS会随TPS的增大而增大，此时查询次数k是固定大；即TPS 和QPS的变化趋势基本是一致的
• QPS的查询，不仅仅是查询数据库，还有查询应用服务相关的资源

RPS

• 发起方/客户端的每秒请求数
• 在Jmeter中，，默认每一个完整的请求就是一个事务，在数值上，TPS的数值会等于RPS，因此有时会将RPS看作TPS（网络没有瓶颈、通畅的情况下）
• • 当网络异常，阻塞，网络带宽不够的情况下，发起的请求没有到达服务器，就有可能请求阻塞在网络中，那么RPS发起的数据量就不会等于服务器处理的数据量

HPS

• 发起方每秒的点击次数，这个概念一般是有界面的性能测试才会存在的

TPS、RPS、HPS、QPS之间的联系

• TPS、RPS、HPS、QPS都是用来表达服务器的处理能力的，在日常生活中，我们经常会将其等价，但是在某种情况下，他们也是有差异的

吞吐量

• 吞吐量：网络中每秒传输的事务数，和TPS不一样
• 在没有网络阻塞/瓶颈的时候，吞吐量的数值 = TPS数值
• 网络阻塞的情况下：吞吐量的数值就不等于TPS的数值。网络阻塞分为：
• • 发起方发起请求的网络阻塞
• • 服务器返回响应的网络阻塞
• 性能测试的时候，先做负载测试，逐步增加并发用户数，这样就会导致TPS增加，此时吞吐量也会增加
• • jmeter中，只在聚合报告中，可以看到一个吞吐量的值
• • 因此在负载测试的时候，因为每秒并发用户数发生变化，因此不能看吞吐量的值，因为其不能反应TPS的真实情况
• • 并发用户变的时候， 吞吐量是一个平均值，因此在做负载测试的时候，并不需要看jmeter的聚合报告和汇总报告

吞吐率

• 吞吐率是：网络中，每秒传输的字节数，单位是：KB/s
• • 注意：单位上的大写的B，和小写的b不一样，1B=8bit
• • 网络带宽=100Mbps = 102400Kbps = 102400/8KBps = 12800KBps，因此1M的带宽就等于128KB/s，也就是说其吞吐量就是128KB/s
• • 做性能测试的时候，知道了吞吐量，和128相比，就知道用了几兆的带宽；知道这个和公司实际的带宽做比较，就可以知道公司的网络是否存在瓶颈
• 吞吐量存在上行和下行两种，发送方和服务器分别对应其中的一种，两者之间是相对的，并不是绝对的
• 企业级别的带宽和家庭版的带宽，存在很大的差别，如果需要下班后在家里做性能测试，就需要在家用电脑控制公司的电脑进行性能测试，要不然会存在很大的差别，性能分析会很困难
• • 例如使用向日葵远程控制公司的电脑，用公司的电脑发起性能测试请求

资源利用率

硬件资源利用率

• 做性能测试一定要关注服务器资源利用率，其是要来监控服务器软、硬件资源的使用程度
• • 服务器资源不局限于硬件资源，还需要使用监控来监控服务器的各项资源使用情况的
• • 监控数据之后，要记录各种数据，这样才能分析问题
• • 上面的说的硬件资源指的是：CPU，内存，磁盘，io，网络等，其阈值一般不超过80%
• • CPU目前都是多核的，这里说的是总体的80%，而不是单个的80%，单个超过80%是可以的，企业中一般情况下比这个高，例如不能出现60%/70%
• • 在工作中，可能会遇到某个进程的CPU使用率达到百分之几百，这是可能的，而且没有任何问题，因为其取决于CPU有多少个核

应用服务资源

分布式和集群的区别

• 在性能测试中，分布式和集群是有差异的
• 但是在企业中，如果不做性能测试，单单讲环境部署的时候，会将这两个概念在一起混用
• • 性能测试中的分布式：分摊请求压力——>发起的请求的机器是多台（例如产生5000并发，就是将请求分布在5台机器上，每台机器产生1000个并发用户数）
• • 性能测试中的集群：集合在一起提高更强的能力输出——>服务器中将相同的服务集成在一起，提供更强的能力输出，集成在一起的工具，一般就是nginx
• • 将产品拆分成多个不同的子项目，将子项目放在不同的服务器（机器）中，提供能力输出，这就是微服务
• 举个例子：假设微服务器的名称是palt-bco，这个微服务的集群大小，启动了多少个pod数
• • 假设公司有5台服务器——即机器的数量是5台
• • 假设使用的是k8s，就会将这5台构成一个整日，部署整个项目P
• • 这个项目，由多个微服务构成（例如p1，p2，p3）
• • 使用k8s部署微服务P1的时候们就会部署到5台机器上(随机部署)，那么P1的数量就是n个，这个数字n就是这个微服务集群的大小

性能测试流程

• 性能测试的总体时间，要比功能测试、自动化测试的时间都要长，行业经验一般是功能测试的2倍-2，5倍(以天为单位比较好)，性能测试的流程分为：
• 性能测试准备
• 性能测试环境搭建
• 性能测试脚本开发
• 性能测试执行
• 性能测试结果分析和调优
• 性能测试报告和问题跟踪

性能测试准备

• 性能测试准备要做的工作有：
• 1.性能需求分析，主要分析性能需求的必要性(需求要不要做)，
• • 如果接口/场景并不是重点功能，使用的用户量不会很多，并不是核心业务，在人手不足的情况下，就没有必要做性能测试
• • 在有监管，有合同规定，或者明确下来的点，要做性能测试
• • 在涉及生命财产安全，国计民生等等方面，要做性能测试
• • 大型产品上线之前，核心，用户使用率高的场景需要做性能测试
• • 如果架构/底层进行了调整，需要对架构做性能测试
• • 底层的bug修复后，也需要做性能测试
• • 核心功能，用户使用率最高的，需要做性能测试
• • 性能测试和功能测试不一样，性能测试的需求不能尽信产品经理的
• • 明确需求边界，量化性能指标，需要反复讨论，如果讨论不出，要先做出结果，然后再讨论这个结果是否符合要求
• 2.熟悉业务——对于要做的需求的业务要点
• 3.熟悉项目架构，通信协议——数据流从哪里流向哪里
• 4.理清请求的数据流
• 5.掌握环境以及环境的关键参数（有哪些机器，机器的ip，链接的账号信息，CPU的内存信息，操作系统以及操作系统的核心参数，部署服务及服务的核心参数信息
• 6.负载机器准备，用自己的可能会出现各种问题，例如占用带宽导致同事电脑卡顿
• 7.性能测试计划；性能测试模型；性能测试工作量评估
• • 测试模型，指的是性能测试用例，或者测试场景，例如：负载测试

负载测试过程中，发现了性能问题怎么办？

• 测试过程中，响应出现了性能问题，例如：
• • 响应出现了持续报错；
• • 响应时间明显波动或者波动比较大；
• • 出现平均响应时间忽高忽低；
• • 出现TPS下降等等
• 这个时候，不需要去解决问题，要停止性能测试，记录相关问题，作出简单的分析
• 说明存在性能问题，但是不需要去定位问题，不需要去调优

出性能报告的时候，性能标准是什么？

• 如果没有给出特殊的指标，就以行业标准来定

性能测试环境的搭建

• 主要做的事情有：
• 1.申请硬件资源
• 2.搭建项目环境(搞不定的可以找相关人员问一下)
• • 环境搭建可以请人帮忙，但是环境的核心参数必须自己掌握
• 3.搭建网络
• • 如何保证本机到北侧服务器之间的网络是畅通的？
• • 1.在发起机器上，启动telent服务，win电脑这个服务默认是关闭的
• • 2.在发起机器上使用cmd打开dos窗口，使用telent 被访问的机器ip 服务端口，请求正常之后才能保证本地机器到被测服务器之间的网络是畅通的
• 4.搭建性能监控环境，有监控环境才能监控性能测试过程，并搜集测试过程中的数据，如果没有数据，就做不了分析

性能脚本的开发

• 根据通信协议和测试人员的技能，选择一款比较容易上手，好用的工具
• 调试和优化脚本（多个人同时使用脚本，还要考虑脚本本身性能的情况——jmeter写脚本的时候，能少用的元件就少用）
• 准备测试数据(数据指的是脚本运行所需的数据——发起方脚本需要的数据，也有服务器需要的数据)
• 在负载机调试脚本(本地脚本运行，负载机器上运行，多台负载机上运行是三种不同的情况)
• • 在负载机上运行，是无图形化界面，本地是图形化的
• • 多台涉及网络通畅的情况，测试脚本准备的数据，多台负载机如何共享数据

脚本的执行

• 数据库中，表数据的准备
• 性能场景的设计（根据第一阶段的模型，去设计并执行）
• 性能测试过程的监控——脚本数据的监控(被测项目的监控)，服务器硬件资源的监控，项目应用资源(项目所在机器)的监控等
• 初步分析数据
• 网络监控
• 负载机资源监控——发起请求的电脑的监控
• 测试记录——至少要包括：性能测试场景，响应时间图，TPS图，监控图表、简单分析的测试结论
• 对记录下来的数据，做一个简单的初步分析，调整执行性能测试(例如端口不够，解决问题后再次进行测试)

性能结果的分析

• 对性能测试结果和监控数据的综合分析
• 对比每次结果
• 问题定位、调优、分析，再测试
• • 分析思路：自身问题>服务器硬件瓶颈>网络瓶颈>服务器os瓶颈(参数配置，数据库，web服务器)>应用瓶颈(sql语句、数据库设计、业务逻辑和算法)

性能问题跟踪和报告

• 性能问题有些是在短时间内可以进行调优的
• 对于短时间内无法调优的，要跟踪记录
• 整理形成测试报告

性能测试相关文档的编写

性能测试计划

• 简单的说：就是什么时间，什么人，在什么地方做什么事情，因此需要包含：
• 1.定义情况：需要明确具体做哪些接口——重点的、核心的接口，接口还需要分优先级
• • 例如5个需求，20个接口，需要做性能测试的接口有12个，做性能测试的时间预估：以天为单位，功能测试所需时长*2.5倍
• • 如果给到性能时间的时长不够，那就需要将接口分优先级，再根据优先级从高到低做性能测试；可以将优先级最高的完成之后上线，其他优先级的可以在发版之后再进行
• 2.说明选择的性能测试模型：是先做性能测试，还是先做负载测试；或者说是性能+压力+性能测试
• • 这里的模型选择是对于每个接口来说的
• • 一般来说，不考虑压力测试(因为时间不够)
• 3.性能测试用例：预估工作量，所需时间
• 4.性能环境搭建：预估工作量，所需时间
• 5.性能脚本编写：预估工作量，所需时间
• 6.性能测试脚本执行：预估工作量，所需时间
• 7.什么时候会出测试报告

性能测试用例

• 测试用例的条数：有哪些接口(接口+报文)*性能测试模型
• • 例如5个接口，每个接口都需要做100个并发，200个并发,300个并发，那么就需要3*5=15条用例
• 需要包含：1.用例的前置条件，例如性能测试环境等
• 2.数据搜集：搜集的性能指标数据ART、TPS、服务器资源利用率、错误率、内存监控数据、CPU监控数据、数据库资源使用情况……
• 3.判断标准：行业标准
• 4.测试结果：通过/不通过
• 一个简单的模板，详见下图
  

测试报告

• 1.性能测试基本的描述——可以找模板
• 2.性能测试的结论
• 3.测试的计划(不需要写完整的计划，做一个表格即可)
• 4.测试的环境信息
• • 包括服务器的硬件信息
• • 微服务的集群信息
• • 网络拓扑图：这样就可以知道测试过程中网络的哪个环境会出现瓶颈
• • • 服务器内部微服务之间的数据流向图，
• • • 或者从你这台机器发起请求，要经过哪些环境发到服务器，服务器处理完成之后，有需要经过哪些环节将结果发到你的机器上来
• 5.测试记录：在测试过程中调用了哪个接口，和测试相关的图表
• • 接口
• • 测试相关的图表
• • 监控结果
• • 结果分析
• 6.测试结论

性能测试应该遵循的原则

• 原则上不能用生产环境、功能测试/自动化测试环境，原因无法保证不会影响功能测试/生产测试的正常运行，例如性能测试产生数据/日志的隔离；性能测试运行导致服务的卡顿等
• 性能测试的环境，硬件配置要与生产环境保持一致，如果生产环境的性能参数已经调优，那么性能测试环境也需要一起变动；机器的数量可以适当的减少，因为并不是所有的功能都要测试，在现有的机器上部署现在可以测试的场景，可能达到和线上一样的性能
• 性能测试原则上不能用生产环境和功能测试环境，需要独立测试环境
• 性能测试原则上也不能共用网络，需要独立网络——即性能测试服务器之间的网络是独立的，与其他的测试环境不在一个网段(不考虑子网掩码的情况下，例如192.168.224.1和192.168.220.1是两个不同的网段)
• • 不懂的可查看文章：链接
• 发起请求的电脑到服务器之间的网络，也尽可能的独立
• 尽可能用有限网络做性能测试，不要用无线网络做性能测试
• • 如果做性能测试，网络都不稳定，那么测试出来的任何数据都不可靠

性能测试工具

• 挑选工具的原则
• • 工具的学习成本
• • 工具的功能与帮助
• • 确认工具支持的协议
• 常见的性能测试工具有：
• Jmeter：java开源工具，需要JDK8/jdk1.8
• • 几乎支持所有的协议，可以做功能测试，自动化测试，性能测试等
• • 用线程来模拟并发用户数
• loadrunder，以前做性能测试的标杆软件，过时了，不推荐使用和学习；
• • 使用线程或者进程来模拟并发用户数，默认是用户的线程
• ngrinder：写代码——groovy和jython
• • 进程+线程组合模拟并发用户数
• locust：python用于性能测试的库，只能写python语言
• • 因为python没有真正的多线程，因此做性能测试不是用线程，而是用协程
• wrk和ab都是简单，快速做性能测试的工具，不能做很复杂的性能测试，只能做简单的
• • 支持lua语言

学习性能测试还需要哪些呢？

• linux和服务器知识
• 网络知识
• 数据库