性能测试理论和数据模拟
mockServer（需要 Java 环境）
什么是 mock
主要是针对单元测试的应用，它可以很方便的解除单元测试中各种依赖，大大的降低了编写单元测试的难度。
不同角色对mock的使用场景
前端
前端完成代码需要数据进行测试，模拟后段返回数据
将 moco.jar 和 product.json 放置在同一目录
命令：java -jar 使用的 jar 包 http -p 端口 -c 使用的 json 文件
例：java -jar moco-runner-1.3.0-standalone.jar http -p 12306 -c product.json
[ { "request": { "method": "get", "uri": "/products" }, "response": { "json": { "name": "沙皇炸弹", "type": "WEB", "version": "V1.0", "master": "星德川", "description": "AN602" } } } ]
后端
测试后端逻辑是否正常
[ { "request": { "method": "post", "uri": "/parking", "json": { "park": "陕A888888" } }, "response": { "json": { "park": "陕A888888", "in": "2022-01-14 00:00:00", "out": "2022-01-14 08:00:00", "money": "$5", "master": "chenli" } } } ]
性能测试
什么是软件性能
不同角色对性能的理解
⽤户
软件性能就是⽤户操作的响应时间。
⼀般⽽⾔关于响应时间业界的说法具体如下：
1-3 秒，属于优的表现
3-5 秒，可以接受
5 秒以上，⽆法接受
如果响应时间是⼤于5秒，需要提单让程序员来进⾏具体的优化
运维
除了关注响应时间外，也会关注更多底层的资源信息
开发视角
前后交互的响应时间
中间件的参数设置
内存释放泄露
连接数泄露
是否存在不合理的内存使⽤⽅式
是否存在不合理的线程同步⽅式
系统中是否存在不合理的资源竞争
系统架构&代码结构
测试视角
需要考虑⽤户视⻆的产品体验，也要监控以及关注运维视⻆和开发视⻆
设计合理的场景和测试⽤例来验证系统的资源数据
验证在⾼并发的情况下架构是否满⾜
给架构师以及开发⼈员提供中间件配置参数的合理值范围
使⽤技术⼿段监控系统，DB，中间件，全链路监控的⽅式来监控系统资源情况
WEB前端
浏览器的资源加载（HTML解析，图⽚资源加载，CSS⽂件资源加载）
前端缓存技术的优化是否合理性
前端与后端的交互性耗时
性能常用术语
响应时间
⼀次操作完成的时间，客户端发送请求到服务端后，服务端返回到客户端的响应数据的时间。包含等待和服务的时间，也包括⽤来返回结果的时间。响应时间=⽹络时间+应⽤程序的处理时间
并发⽤户数
性能测试的核⼼是验证当前系统能否⽀持现有⽤户的访问，也就是说系统可以承受在同⼀时间段多少⽤户来访问系统，这中间主要体现的是服务端承受的最⼤并发访问数；优先级1-10，默认优先级5
吞吐量
主要⽤于数据传输⽅⾯，是被测试系统的执⾏效率。吞吐量指的是操作的速度，也就是每秒操作数或者每秒业务数
使⽤率
对于服务所请求的资源，使⽤率描述是所给定的时间区间内资源的繁忙程度。⼀个是系统资源的使⽤率，另外⼀个是系统内部署服务对系统资源的使⽤率。
如⼀个业务中，会使⽤⼤量的内存资源，总的内存资源是4G，在⼀定数据量的情况下执⾏该 业务形态，内存使⽤率从100M⼀直占⽤到3G，然后随着业务形态内存资源得到释放呈下降的趋势，那么可以说内存使⽤率最⾼为75%，可能会存在OOM的错误信息，也可能会存在内存泄露的情况。
性能计数器
主要指的是性能测试过程中操作系统以及其他组件的⼀些数据指标
思考时间
在业务视⻆，思考时间指的是⽤户在进⾏操作时，每个请求之 间的间隔时间
IOPS
主要是针对数据库的，指每秒发⽣的输⼊/输出操作的次数，是数据传输的⼀个度量⽅法。⽤于磁盘的读写，IOPS值的是每秒读和写的次数
TPS/QPS
指的是某个操作或者是⼀组操作的组合TPS统计的是每秒处理的事务数，即系统每秒能够处理的事务的数量。QPS指的是每秒查询率
软件性能测试理论
资源调度
调度器可以理解为：CPU时间划分给活跃的进程和线程，⽽且维护⼀套优先级的机制，这样更重要的⼯ 作可以更快的执⾏，调度器会跟踪所有ready-to-run状态的进程。
调度器（调度策略）可以动态的调优先级以来提升⼯作负载的性能，可以做如下的区分：
CPU密集型：应⽤程序执⾏繁重的计算，会占⽤⼤量的CPU
IO密集型：应⽤程序执⾏I/O，计算不多，会占⽤⼤量的内存资源系统的最⼩粒度是线程，也就是说系统调度中粒度最细的就是对线程的调度。
等待队列
不管是同步交互还是异步的交互中，都会涉及它的最⼤队列，这样设计防⽌在客户端⾼并发的情况下服务端在没有队列的情况下出现雪崩以及最终导致服务端出现瘫痪，因此队列等待是⾮常核⼼并且是⾮常有必要的。
在等待队列中，测试需要得出如下⼏个性能数据：
1、队列设置的值是多少?最⼤可以运⾏的任务是多少？
2、需要测试排队的策略机制，然后⼀个任务执⾏结束后，队列位置释放⼀个，等待中的可以⽴刻进⼊然后执⾏，这中间就设计到先进先出还是先进后出，以及线程优先级的设计策略
3、线程在排队的过程中，设置最⼤的等待时间是多少，还是没到执⾏的阶段，这个时候服务针对排队等待的线程处理的机制是？这个时间专业术语就是：访问等待时间
4、那么⼀个线程完整的时间是由三部分组成的，响应时间：客户端发起请求的时间+访问等待时间+逻辑执⾏时间 +返回给客户端的时间。⼀般在测试中，可以把每个线程名称设置为uuid，这样它都是独⽴的，可以依据这个 uuid，让开发同学配合输出每个阶段的时间输出，然后就可以得到每个阶段的具体时间了，根据时间再来判断时间是否优化。
性能测试步骤
测试前期准备
着手准备测试相关的工作，包括测试环境和测试工具准备，测试案例和场景的准备，测试数据的准备，脚本录制，性能监控的验证等。
性能测试工具
常用 Jmater（Java）
locust（Python）
性能计划
人力
具体工作
开始时间
使用技术
测试设计与开启
工具/代码编写
具体的脚本
测试执行与管理数据收集
根据容量执行
根据数据库资源——IOPS
Liunx
CPU
memory
nginx
连续数
本身
对测试进行分析
性能测试方法
验收负载测试
QA环境模拟生产运行的业务压力和使用场景组合，测试系统性能是否满足生产环境的性能诉求
负载测试
在被测系统上持续不断的增加压力，直到性能指标（响应时间等）超过预定指标或者某种资源（CPU&内存）使用已达到饱和状态。核心是找到系统的处理极限，为系统调优提供数据，从而达到了解系统性能的容量
压力测试
该方法是指系统在一定饱和状态下，具体如CPU，内存等饱和使用的情况下，系统能够处理的会话能力，以及系统是否会出现错误，比如TimeOut,OOM，OverStackExpection（堆栈异常）。特点：
检查系统在处于压力情况下时应用的性能表现
等价于负载测试，使系统的资源处于一个瓶颈的状态（建议CPU和内存在75%以上）
配置测试
被测环境软硬件环境参数的调整，达到最优的分配原则
并发测试
模拟用户的并发访问，测试多用户并发访问同一个应用时是否存在死锁或者其他的问题，特点是：
发现系统中可能隐藏的并发访问的问题
关注系统可能存在的并发问题，如内存泄露，线程锁，资源争用情况
使用的测试工具如profiler等
可靠性测试
给系统加载一定的业务压力，让应用持续运行一段时间，测试系统在这种条件下是否能稳定运行
故障演练
故障演练是应用高可用能力测评的核心，一次完整的故障演练由演练的对象、对象发生的具体故障、应用的预期故障应对表现、对应用表现的实际观察和判断几部分组成
容灾恢复测试
当各种灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生产系统的业务不间断的运行。任何针对可能发生的灾难，提高系统可靠性和可用性的措施都可以称为容灾
