性能测试基础

性能领域与功能完全不同，基本没什么关系，没什么逆向思维，分支，方法，策略，都没有。
只需关注一点，就是服务器的表现
可以把服务器想象成一个心脏，心脏如果停了，这个人就挂了
让一个大心脏剧烈跳动，就要让它跑长跑，短程冲刺或者施压，给这个人身上成吨的压东西，直到承受不住为止。
所以我们要对这个场景进行模拟，进行场景的还原，不停地刺激它，通过各种各样的方式去刺激它。
对它进行刺激的方式有三种：压力，负载，稳定性
压力的刺激就是一瞬间的刺激，负载就是循序渐进持续施压（就是凌迟处死的感觉），稳定性就是当它快要挂掉的时候不动它了，收手了，看它什么时候垮掉

性能测试前期的准备工作

1、了解本次性能测试的目的
确定是做压力还是负载还是稳定性，需求不同方法就不一样
并发接口是压力测试
看网站最多容纳多少人是负载测试
看网站人数较多时能否保持一个稳定的状态是稳定性测试

2、性能测试指标的标准
不管哪个指标都应该有个标准，或者说是预期结果
比如说响应时间不能超过多少秒（1 3 5 7）
一秒以内非常好，三秒以内是优秀，五秒以内是良好，七秒以内是合格，七秒以上是不合格

3、测试机配置测试
和人打架也得先评估一下对方的战斗力，如果对方五大三粗大金链子大纹身你敢动吗
做性能测试就是拿我们的客户端去攻击我们的服务器，客户端与服务器之间的斗争
如果服务器过于强大，客户端给服务器造成的压力挠痒痒似的，而且如果再多点服务器没事客户端可能崩掉。客户端和服务器的实力得均衡

4、服务器配置测试
问运维人员
公司有几台服务器？
服务器是什么配置？
服务器大概能承受多少人的压力？
服务器老不老？
对现在来说服务器的配置算不算好的？等等

5、服务器IP地址
服务器也就相当于一台大计算机
不知道服务器的ip就没法监控这台服务器
拿我们的电脑去给服务器施压，去盯着服务器的指标，远程监控
用我们自己的电脑来说，打开任务管理器中的性能，就是监控我们自己的电脑性能

服务器大部分都是Linux的（Linux的服务器比较稳定）
Windows系统中唯一能当服务器的系统就是Win2003，只有它最稳

6、了解有几台服务器
用户量越来越大，会逐渐增加服务器的数量 （也与服务器的配置有关）

7、提前准备测试机多机联合
服务器有多台，想给服务器施加压力肯定也要多准备几台测试机
先要看一下自己电脑的配置，想做性能测试的电脑，CPU必须很好，内存必须要大，这样的电脑才不至于打着仗自己先挂了

8、编写性能测试用例
功能有功能的用例，性能也有性能的用例
预期结果 （CPU、内存、响应时间 都不能大于多少），测试步骤（脚本怎么录，在哪设置集合点，准备并发多少数量，用户怎么进入退出，持续多长时间）

9、搭建性能测试环境
安装loadrunner等性能测试工具

如何开展性能测试（性能测试开展阶段）

接口性能测试
用jmeter（后面jmeter细写接口性能测试）
基本没有人会用loadrunner进行接口测试

业务性能测试

压力测试（并发测试）：一瞬间的并发，同一时间点，短时间内，一秒钟发送的请求
并发只能靠软件实现，人工测试不可能实现并发（人工测试有快有慢，不可能同一时间进行操作）

负载测试：压死骆驼的最后一根稻草 。 循序渐进的给一个网站施加压力，看看到底到了多少人的时候，有可能再多那么一个人，这个网站就崩了，有可能就少了一个人，网站就能扛一会儿。负载测试就是找它的极点。
做负载测试时绝对不是把服务器压垮，服务器是有指标的，可以根据一些指标来衡量服务器的表现。比如说吞吐量，吞吐量是服务器最核心的指标。通过吞吐量可以看出来服务器处理事物的能力，吞吐量越高，说明服务器处理事物的能力还不错，如果吞吐量下降，说明服务器处理事务的能力削弱
一开始可能吞吐量往上涨，当涨到一定程度的时候还在往上增加用户，用户越多吞吐量就越低，用户加到一定程度时，吞吐量死了。我们找的不是吞吐量挂掉的点，找峰值，找拐点，要找的是吞吐量开始下降时的平衡点而不是死掉时的点。
一定不能把服务器压崩，万一服务器主板烧了赔不起，就算赔得起数据也无法还原（备份也不可能每天都备份）

稳定性测试：稳定性测试就是当已经找到拐点时，就在拐点的基础之上，找到负载的峰值，让服务器长时间的运行。
比如拐点是500人，再多的话吞吐量就开始下降，处理能力开始下降，这时就用这500人，最峰值的时候，持续运行8小时，看这8小时之内崩不崩。如果8小时之内没有崩说明稳定性还可以，如果没有坚持到8小时，说明短时间的稳定性还可以长时间的高压不行，这时就应该解决问题了（服务器崩溃就相当于电脑蓝屏，没大问题）
先有负载才有稳定

故障转移和恢复测试

测试流程：拿到性能需求，分析性能指标，编写性能测试用例，录制性能脚本（录完的脚本100个里有100个都不能直接使用，需要进行脚本增强）

脚本增强很重要，如果脚本无法增强，或者没增强过，没有进行优化，那么就无法实际还原用户的场景，脚本性能结果就是错的。一步错步步错，如果有一步错了，那么最后的结果就是错的、假的，所以要保证每一步结果都是对的。

如果白天使用人多服务器有人用的时候做的性能测试和晚上夜深人静的时候做性能测试，得到的结果是不一样的，所以我们做性能测试时要保证没人用的时候去做。

性能执行阶段

创建脚本—脚本增强
集合点
事务
关联
检查点
参数化
用户思考时间
其他函数

性能测试场景设计界面

规划场景：并发多少人？持续多长时间？怎么入场（循序渐进的入还是一起入）？怎么出去（循序渐进的出还是一起出）？监控哪些指标（指标每隔几秒钟刷新一次）？性能集合的策略怎么设置？等等

性能指标分析界面
评估所有指标情况如何，哪些指标出的问题，具体什么原因导致的，该怎么去优化等

性能结果分析阶段

编写性能分析表
根据分析表分析性能变化趋势
生成概要报告进行概要分析
根据图表进行详细数据分析
生成性能测试报告

性能测试流程

1. 准备测试环境，做前期的准备工作
2. 编写测试用例，按照测试用例去录制性能脚本，定好预期结果
3. 对录好的脚本进行脚本增强
4. 增强好的脚本确定没问题后去设计测试场景
5. 设计完测试场景按照场景去跑脚本
6. 脚本跑完之后看结果，看指标
7. 指标分析完之后出报告