性能测试基础
性能测试的目的
发现性能瓶颈，应用系统的短板在哪里，若发现性能问题，
能够分析它是哪个点爆发的。
性能测试的分类
1.负载测试
通过逐步加压的方法，达到既定的性能阈值的目标，
阈值的设定应该小于等于某个值，如CPU使用率小于等于80%。
2.压力测试
通过逐步加压的方法，使得系统的某些资源达到饱和，
甚至失效的状态（中间件，数据库，应用程序等）
3.并发测试
同一个时间内，多个虚拟用户同时访问同一个模块，同一个功能，
通常的测试方法是设置集合点。
4.容量测试
通常是指数据库层面的，目标是获取数据库的最佳容量的能力，具体测试方法为
在一定的并发用户，不同的基础数据量下，观察数据库的处理能力，即获取数据库的
各项性能指标。
5.稳定性测试
又称可靠性测试或疲劳测试，指系统在高压情况下，长时间的运行系统是否文档。
如cpu使用率在80%以上，7*24小时运行，系统是否稳定。
内存泄漏的原因，系统长时间运行，底层垃圾回收不彻底。
6.异常测试
又称失败测试，是指系统架构方面的测试，如在负载均衡架构中，要测试
宕机，节点挂掉等情况系统的反映。
性能测试技能树
性能测试流程
需求分析
熟悉项目是做什么的，用户如何在我们的平台上操作的，哪些是重点，有哪些主要流程
性能指标
定义TPS，吞吐量等这些指标
定义我们所满足的指标
什么样的标准满足我们现阶段的业务需求
开发脚本
场景设置
脚本开发完后一般不能直接用于性能测试，调试脚本，设置场景
和需求分析产生关联，设置的场景要符合用户在我们的平台上使用的流程，
比如用户经常做哪些操作等
监控部署
一个应用软件一般包括自己的应用程序，应用的服务器，数据存储部分，
这些都要把它监控起来，才能发现性能瓶颈
测试执行
怎么跑？第一阶段：基本测试，少量用户跑15分钟，
第一轮发现问题，多并发下，应用程序对多线程的逻辑处理问题，
有时，一个用户操作没问题，
但是当多个用户去操作功能点时，就会发生问题，多并发逻辑问题。
解决第一轮的问题时，进入第二阶段时间长的跑一跑，跑几天
性能分析
它基于监控部署，只有把监控部署完善，无死角监控，它才能更轻松。
无论程序运行在哪，发生了什么问题，都可以看到，性能分析才能有理有据
性能调优
只有把监控部署好，性能分析和性能调优才能更顺利
只看测试工具中的那些报告，这些报告是工具用来收集应用程序和服务器的一些运行状态
这些状态并不全，不能完全胜任眼睛这个角色。
开发在做开发时，在对一个变量和类的声明等等生命周期控制的不严格，发生了内存泄漏，溢出等
测试报告
对于敏捷测试来讲，一般多个迭代版本有不同的性能指标
系统应用分层架构
优点
分层利于分析和定位问题
性能的前期准备工作
监控mysql，监控API层，代码处理速度
mysql和api运行在linux，监控linux服务器的运行状态，承载数据库和代码的运行环境
web层面的监控，图片加载和js加载，首先加载js后加图出现停顿
先加载样式后加载js，如何加载图片不失真等
测试思路
（1）可以一块块测试，首先进行数据库测试，把开发的代码拿过来，把其中和数据库交互的sql语句抽离出来，
（2）然后开发成我们的脚本，对mysql进行性能测试，好处没有其他因素影响，
sql语句调优，myql配置调优，服务器配置调优，缩短了分析范围，性能调优变的容易
如果从web开始测试，要经过web>api>myql然后再返回去
（3）然后再做接口API层，做 并发，如果有问题，代码逻辑问题，并发逻辑等
（4）最后再并发前端，自底向上做测试
性能测试指标
事务
从客户端发起的一个或多个请求，到客户端接收到从服务器返回的响应。
TPS
Transaction Per Second
每秒钟系统能够处理的事务数
请求响应时间
从客户端发起的一个请求开始，到客户端接收到服务器返回的响应，整个过程所消耗的时间。
事务响应时间
事务是有一个或多个请求组成，事务响应时间主要是针对于用户的角度而言，如转账。
并发
没有严格意义上的并发，并发总会有先有后，一般讲的并发是在一个时间内，如1秒。
并发的两种情况
多用户在系统上进行同一操作，比如大家对同一种商品进行秒杀；
多用户在系统上进行不同的操作，比如大家浏览不同的商品。
用户并发数
同一单位时间内，对系统发送请求的用户数量。
吞吐量
一次性能测试过程中网络上传输的数据量的总和。
吞吐率
单位时间内网络上传输的数据量的总和。
点击率
每秒钟用户向服务器提交的请求数。
资源使用率
对不同的系统资源的使用情况，如cpu，内存，io
性能测试需求分析
目的
给性能测试画个圈，明确性能测试重点
明确测试指标
把哪些指标作为重点关注指标，和开发人员约定这些指标是什么意思，避免后期不明确而产生分歧
明确测试场景
跟业务挂钩，比如注册相对于登录重要性低，每个功能点要有多少并发