性能测试类型【杭州多测师_王sir】【杭州多测师】

一、基准测试
1）基准并发
测试1：迭代100次 ramp up 1  看吞吐量tps80/sec和接口响应时间，错误率，说明rps为100/sec，但是服务器1秒钟只能处理80、全部处理完毕可能需要1秒多钟
测试2：线程100  迭代1次 ramp up 2  rps实际上为50/sec、因为每秒发50个请求、 看吞吐量tps40/sec和接口响应时间，错误率
2）基准负载
用并发基准点做一次简单的脚本测试，得到一个基线，为下一次的回归做理论依据  ==》线程100  无限迭代 ramp up 2、throughput=请求个数/总共花费的时间

二、并发测试
概念：多线程在单位时间内同时发起单次请求，观察响应时间
基础线程组（强调单位时间的并发，不存在绝对并发）
1）相对并发测试：设置并发线程、不加集合点测出来的数据不是很准
2）理论上绝对并发测试：加入定时器集合点【Synchronizing Timer】、去看tps和响应时间的的曲线变化

三、负载测试
概念：持续不断的增加压力（并发用户/每秒请求），观察tps和响应时间的变化趋势，找到瓶颈点（性能衰减点）
2种压力模式：用户并发模式和吞吐量模式
用户并发模式的负载：不断增加并发用户数，发现瓶颈==》站在用户的角度思考问题
吞吐量模式的负载：不断增加请求数对服务器施加压力，发现瓶颈==》站在服务器的角度思考问题

第一种模型：吞吐量模式
1）吞吐量模式有两种。一种是TPS，一种是RPS。前者用来设计业务量模型，后者用来控制压力引擎。我们在用吞吐量模式设计负载场景的时候就有2种方法，持续的增加TPS和持续的增加RPS
但是tps用来衡量服务端的性能，是有上限的。也就是说我们持续增加的负载不可能超过服务端的吞吐量上限阈值
2）RPS模式负载：加入jp@gc - Throughput Shaping Timer定时器，不断增加每秒请求数（rps）对服务端施压，发现tps瓶颈
3）TPS模式负载：添加bzm - Free-Form Arrivals Thread Group线程组，60s内将tps均匀的提升到800，通过tps的提升观察平均并发数和响应时间的变化，不断的加tps、但是服务器有自身的阈值、最大的tps不断超过服务器的阈值

第二种模型：用户并发模式
1）一是通过普通线程组不断加并发、找出性能拐点、并且找到最佳并发用户数、但是这种也需要加集合点。但是数据没有并发线程组那么准确、所以官方比较推荐使用并发线程组
2）二是通过添加用户并发模式阶梯加压负载：持续不断地增加负载，发现性能瓶颈（阶梯加压线程组，Concurrency Thread Group）官方推荐这种
3）混合业务负载测试：通过设置每个接口的权重来控制每个接口的请求数，bzm - Weighted Switch Controller 

四、压力测试
概念：tps瓶颈点上持续负载
1）稳定性压力测试：脚本以最大压力的80%做持续运行（1h，1d，1w）
2）破坏性压力测试：不考虑服务器的稳定性，直接以极限压力测试，目的是破坏服务器，直接找到异常（内存溢出，超时）
3）阶梯式压力测试：逐渐增加测试负载，如每5s钟增加100个并发数，高负载情况下持续运行一段时间，然后再逐渐降低负载，构成一个梯级的测试场景 ==》jp@gc - Stepping Thread Group用这个线程组，默认每隔30s启动10个线程，一共启动100个，然后100并发持续1分钟，并且需要添加beanshell脚本，查看线程区间1-20，20-40，...100不同阶梯压力下的性能数据变化趋势
4）失效恢复测试：系统在出现异常之后，能否及时恢复
5）容量规划测试：根据未来的业务增长量来进行扩容，比如业务20扩到30万，高峰时间段运行2小时

五、spike测试
在性能测试中属于压力测试的一个子集。指的是在某一瞬间或者多个频次下用户数和压力陡然增加的场景。常见的场景：12306开始售票时用户急剧增加，网站公布高考成绩、录取分数时，用户急剧增加
测试spike场景可以用：Ultimate Thread Group（终极线程组）

其他观点：
1）不一定tps达到最高就是瓶颈点、有点时候tps增加幅度很小或者几乎没有波动、然后接口响应确开始变长并且也出现了报错率就可以理解为性能的瓶颈点或者拐点
2）tps达到最高不一定就会急剧下降有可能是一直平稳运行的、但是并发或者请求一直在增加但是tps没反应其实也可以判定到达瓶颈点或者拐点了
3）不一定是tps越高就越好，这个需要结合接口响应时间，错误率，CPU和内存，IO和数据库等等其他情况一起来进行分析！！