本篇幅主要对性能测试中的一些基础预备知识进行描述，其中包括专业名称、指标参数、历史发展、性能测试流程等作为一个简单的知识储备为后期的篇幅打下基础

概念和常识

常识

  • 功能或自动化测试目的：找bug预期结果与实际结果进行比对，模拟都是单个用户的操作
  • 性能测试：模拟 多个人同时 操作时,查看响应时间，接口服务器性能测试中,一定是多个人同时操作,才是性能测试
  • 响应时间基准：性能中的avgRT可接受的范围≤1500ms,APDEX用户满意度指数＝（1 × 满意样本 ＋ 0.5 × 容忍样本）÷ 样本总数
  • 事务：一个请求行为,并不一定只有一个接口,所以事务可能是多个 ineterface，默认情况下,1个接口请求1次,认为一个1个事务 Transation。也可以是通过事务控制器,挂载多个接口请求，合并成为1个事务（在页面上输入账号密码后，点击登录，会触发多个接口，这些自动关联可合并为一个事务，多个事务可组成一个 workflow ）

并发

  • 狭义的并发：同一时间请求同一事物（同一时间都在并发登陆，单场景）
  • 广义的并发：同一时间请求不同事物（同一时间，有登陆，有注册，有浏览，有评论，有发呆）
  • 在性能中，先狭义，再广义，先单接口，后混合场景，这样方便定位到问题

角色分析

用户

用户只关心速度，请求的响应快不快，在不在可以接受的范围内，这个会直接影响到用户的体验

管理层

  • 应用服务器/数据库服务器资源使用是否合理（资源利用率，资源不回收，泄露，cpu慢查询
  • 系统能否实现可扩展 （可扩展性方面考虑，比如扩展一个新功能，服务，需要对代码大量更换，修改，甚至要全部重来，这种的扩展性就很差，或者不需要更改多少这种就比较好）
  • 系统最大支持多少用户（系统容量，比如最多支持10w,100W用户，就支持不了了）
  • 系统最大业务处理能力 tps(每秒服务器能够处理的请求数) 吞吐量是以KB每秒，或每秒的条数，属于tps的一种，qps一般是开发的称呼，是每秒查询的请求数
  • 系统性能存在的瓶颈在哪里 定位到那个代码，或者哪个进程等等，或者是硬件的问题
  • 更换哪些设备能够提高系统性能 cpu核数加大，硬盘等等，比如双11，618都是靠堆服务器
  • 稳定性，能否支持7x24小时的业务访问（比如跑个几天就必须重启，或者8个小时，12个小时等等，先跑单接口，再跑多个请求混和场景）

开发人员

  • 架构设计是否合理（系统架构图是架构师设计的，但是实现还是开发，有些情况可能根本不能实现）
  • 数据库设计是否存在问题（数据库设计，监控是不是有慢查询）
  • 代码是否存在性能问题（不同人写的代码方法，算法的复杂度不一样，导致性能处理也不一样）
  • 代码是否存在不合理的内存使用方式（代码用完了是不是有释放掉，还是一直占用着资源，监控内存是不是会出现内存溢出）

经验总结

  • 执行顺序：负载|得到最大用户数 –> 性能|得到各项指标 –> 压力|查看服务器的稳定性
  • 性能测试环境要求：需要搭建独立环境不可同自动化，功能测试环境混合，服务器配置和正式环境一致（硬件，数量可按集群比例划分，网络，架构参数）
  • 性能测试中不能使用WiFi，不能使用VPN代理等桥接方式
  • 性能测试的必要性研究，优先级制定（核心功能，用户访问量大的业务）
  • 反复沟通确认性能指标，量化指标

参数指标

TPS

服务器每秒处理的事务数（综合处理能力，IO,CPU,network等）

吞吐量

网络每秒能通过的事务（客户端和服务端传输通讯）

RPS

客户端（jmeter，loadrunner不局限于此）用户每秒请求率，例：并发数10，每人1s能发3个请求，rps=30

QPS

服务器每秒查询率，在企业中如果没有严格区分，默认是把1个事务当做只查询了一次tps=qps–》1：1（但是实际的情况一般是一个事务对应多个查询即1个事务：N个查询）

HPS

每秒用户点击率（页面点击，较早的概念）

RT

响应时间，Response Time，是指从提交第一个请求到产生第一个响应所用时间，是用户最直观的感受，系统响应时间=网络（N1+N2+N3+N4）+服务处理(A1+A2+A3)

响应时间

-

三大性能场景

执行顺序：负载|得到最大用户数 –> 性能|得到各项指标 –> 压力|查看服务器的稳定性

性能测试

通过工具,模拟多用户发起请求,获取**性能指标值**,用工具来模拟多个人的方式很多

  • 进程:资源拥有者,资源消耗会比较大，如果电脑打开一个qq,系统后台就会生成一个进程以及对应的PID，代表软件loadrunner，性能测试标杆软件、c语言、国内破解(<11）、12免费试用50限制用户数、更新极慢
  • 线程:使用进程的资源，多线程技术（Thread），代表软件jmeter，建议v5.1.1+
  • 协程：一个底层调度单元，可以是一个函数，运行在线程之上代表python+locust，自行写py脚本

可靠性测试

在给定一定的业务压力下，持续一段时间看系统是否稳定 最大并发*20%

容量测试

不同数据量级,数万条,百万条数据的操作读写不一样,因为测试环境数据一般不会很多,除非自己创造,所以在测试环境的速度和正式环境会有差异

在性能测试时,如果数据库的数据量级是不一致的,性能指标值,也可能存在差异
生成的数据库数据量级百万级,测试环境几千几百条读写速度肯定会有差异，因此在做性能测试的时候数据库的量级要保持一致（可通过主从数据进行同步，或者批量造数据）

负载测试

逐步增加并发用户数找出最大拐点【区间】,适用于初步测试定位性能区间，可通过多次反复减小步长确定具体的值或较为精确的值

区间判断依据（tps计算：50tpsX60sX60minX8H=144W访问量）

  • 请求报错

  • tps下降

  • 响应时间变长长

压力测试

在**一定的压力下，持续较长**的时间，测试服务的稳定性，可靠性，一般是以小时为单位或者1-2天（因为现在互联网环境，速度很快）,在服务器出现不稳定的情况下再去做压力测试

一定的压力一般采用如下两种方案：

  • 最大并发用户数*20%+相对较长时间
  • 最大并发用户数*80%+相对短时间

测试流程

性能测试目的

  • 评估系统的处理能力：验证系统的处理能力是不是达到规划是的水平
  • 发现系统中的性能瓶颈：是不是某个接口响应时间很长，tps很低，硬件是不是可以支持
  • 验证系统稳定性和可靠性：长时间的测试会不会导致内存溢出
  • 系统调优：重复执行性能测试，来验证系统调优是否取得预期结果

案例分析

  • 需求支持50万并发/支持20万并发
    • 系统用户数：就是我们系统用户数总数，包括活跃的和僵尸用户
    • 在线用户数：就是登陆系统的用户，例如：其中有N个用户为在线，但是在线用户数并不一定会对服务器产生压力，比如有的挂机，session过期不算在线用户数
    • 并发用户数：是对服务器产生压力的用户，例如：可能有10W人在线，但是只有20%用户对服务器产生了压力，也就是说这个接口并发用户数只有20%，以及需要拆分产品的需求，要求50W并发，本来系统就50W，但是并发数可能拆分下来就10%或者更少，要懂得分析

性能测试准备

  • 需求分析
  • 熟悉业务
  • 明确性能测试目标(指标值)
  • 了解软件功能、架构
  • 制定测试计划,做好工作量评估(2-3倍，主要在环境搭建消耗时间，调优)
  • 制定测试模型(编辑测试用例，性能场景)
  • 首先必须要排除网络问题，比如准备千兆交换机，或者局域网的同一网段的千兆网卡
  • 跑场景的时候，ping服务器，（ping ip -t）,确定网络，有没有丢包现象
  • 先跑单个接口的性能测试场景（确定没有问题，或者能直接定位到具体问题的模块），再跑混合场景（多个接口混合）

搭建性能测试环境

工具选型与准备(jmeter,loadrunner)

被测系统环境搭建（服务器，服务版本更新，数据库数据准备,数据量级）

网络配置

性能测试脚本开发

选取协议（http，jdbc,websocket…）
制作脚本
调试脚本
验证脚本

性能测试脚本执行

试运行

场景执行（负载，性能，面向目标，混合）

结果分析与调优

分析依据:结果图表
分析思路:服务器硬件瓶颈>网络瓶颈>服务器σs瓶颈(参数配置、数据
库、web服务器)>应用瓶颈(sq语句、数据库设计、业务逻辑、算法)
调优：
修改脚本或场景

测试报告与结果跟踪

性能测试报告
性能测试问题跟踪

应用发展

  • 最开始所有的代码都在一个工程下面，生成一个项目包，随着项目开发，代码越来越多，功能越来越多，导致的问题就来了，如果项目足够大，哪怕是再好的一台服务器也跑不动这个单体架构的项目

  • 第二就是项目过大不好管理08年前，然后到了08年10年后就开始把项目和数据库（Oracle,sqlserver,access,mysql,postgrasql）、文件服务器（图片，资源，就像现在的七牛云,ftp,oss）、项目服务器(apache,tomcat,springboot,springcloud)分离、再后面就是集群（12-15年开始蔓延流行，主要是nignx），docker、微服务模块化（16 17年开始出现，只是大家技术没统一拆分方法，后面技术成熟了都用模块化的方式来拆分，所以就用了 springcloud，这样又导致不适用Tomcat了，因为太臃肿所以就用上了docker），中台

  • 数据库开始主从同步备份，读写分离，分表分区，非关系型（momgodb：bson格式类似json格式的数据方式存储比较好操作18年左右流行起来的、memcache：缓存数据库13 14年就很流行，后面被readis替代，因为不能持久化（好像是可以配置的比较复杂），断电数据就没了

  • redis：缓存数据库，可以持久化，写入磁盘断电后可以再次读取

  • HBase：大数据分布式文件系统数据库18年左右）

  • 时序数据库：influxdb Prometheus（根据时间记录数据，连接起来就像一条折现图，每一行的第一列都是时间戳，做监控平台的时候需要使用展示）

  • 拆项目：前后端分离，中台（微服务衍生出来的，接口透传，封装接口，比如现在微服务的拆分导致模块越细，以前本来展示一个前台只需要调用一个后端接口现在可能需要调用三个，那么中台就可以做数据的封装，把三个接口的数据整理组装好一起返回给前端，14 15年就有中台概念，以前叫做数据总线）