1.介绍
1.1 测试分类
基准测试
并发测试
负载测试
压力测试
稳定性测试
1.2 基准测试介绍
基准测试（benchmark）
基准测试是针对系统设计的一种压力测试，为系统建立一个性能基准，以后当系统的环境参数发生变化后，在进行一次相同标准下的测试，可以看出变化对性能的影响，可以再较好的阶段发现性能问题。
基准测试可以理解为压力测试的一种。但基准测试不关心业务逻辑，更加简单、直接，数据可以由工具生成，不要求真实；而压力测试一般考虑业务逻辑（如购物车业务），要求真实数据。
基准测试目标
评估当前系统
寻找存在瓶颈
预测未来性能
对于多数 Web 应用，整个系统的瓶颈在于数据库；原因很简单： Web 应用中的其他因素，例如网络带宽、负载均衡节点、应用服务器（包括 CPU、内存、硬盘灯、连接数等）、缓存，都很容易通过水平的扩展（俗称加机器）来实现性能的提高。
而对于 MySQL ，由于数据一致性的要求，无法通过增加机器来分散向数据库写数据带来的压力；虽然可以通过前置缓存（ Redis 等）、读写分离、分库分表来减轻压力，但是与系统其它组件的水平扩展相比，受到了太多的限制。
而对数据库的基准测试的作用，就是分析在当前的配置下（包括硬件配置、 05 、数据库设置等）数据库的性能表现，从而找出 MySQL 的性能阈值，并根据实际系统的要求调整配置。
1.2.1 基准测试的方式
针对整个系统的整体测试，即集成式（ full-stack）基础测试．通过 http 请求进行测试，如通过浏览器、 App 或 postman 等测试工具．该方案的
优点：能够更好的针对整个系统，测试结果更加准确；缺点：是设计复杂实现困难。
单独测试 MySQL ，即单组件式（ single 一 component ）基准测试。只针对 MySQL 的基准测试：优点和缺点与针对整个系统的测试恰好相反。
．
1.2.2 基准测试的指标
系统吞吐量
一个系统的吞度量（承压能力）与 request 对 CPU 的消耗、外部接口、 IO 等等紧密关联。
单个 request 对 CPU 消耗越高，外部系统接口、 IO 影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐里几个重要参数： QPS、 TPS 、并发数、响应时间。
TPS / QPS ：衡量吞吐量。
响应时间：包括平均响应时间、最小响应时间、最大响应时间、时间百分比等，其中时间百分比参考意义较大，如前 95 ％的请求的最大响应时间。
并发量：同时处理的查询请求的数量。
并发数
系统同时处理的请求、事务数。
所有用户在同一时刻做同一操作，主要是为了验证榴字或数据库对并发处理的能力。
多个用户对系统发起了多个请求，这些请求可以是同一种操作，也可以是不同的操作，混合测试。
响应时间
响应时间反应完成某个业务所需的时间，一般取平均响应时间。
响应时间＝网络传输时间（请求）＋服务器处理时间＋网络传输时间（响应时间）＋页面前端解析渲染时间
每秒通过事务数（TPS）
每秒通过的事务数（吞吐量），是直接反映系统性能的指标，此值比较大，说明系统性能比较好，用户每分钟执行 6 个事务， TPS 为 6 / 60s = 0.10 TPS 。同时我们会知道事务的响应时间， 60 秒完成 6 个事务也同时代表每个事务的响应时间为 10 秒。
每秒查询事务数（QPS）
单个进程每秒请求服务器的成功次数。
每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，此值比较大，说明系统性能比较好。
QPS 基本类似于 TPS ，但是不同的是，对于一个页面的一次访问，形成一个 TPS ；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入 QPS 之中。
事务
用户一个或一系列的操作，代表一定的功能，在程序上的实现就是一段代码区块，所有性能测试其实最终都是围绕着事务开始的，事务代表用户的使用方法和结果不同的操作组合成不同的事务，不同的事务又能组合成不同的场景。
事务请求时间
从这人事务发起到最终处理完毕的所有时间。
每秒点击数
代表用户每秒向外部服务器提交的 HTTP 请求。
TPS（吞吐量）计算公式：
所以利特尔法则在负载模型中解释为：
系统内平均用户数 = 平均响应时间 * 吞吐量（ TPS = 用户数 / 平均响应时间）
N = ( R + Z ) * X
N ，用户数
R ，平均响应时间（也可能是速率）
Z ，思考时间
X ，吞吐量（如 TPS )
如： N （用户数）= 1000 , R（平均响应时间） = 5 , Z（思考时间） = 0 ，则 X （吞吐量） = 1000 / 5 = 500 TPS
