性能测试涉及到的一些指标解释
性能测试前提
确认指标，在做性能测试之前，应该有产品的性能指标，其次性能测试不能说是越早测越好，因为性能测试的需求指标，会随着产品的开发产生变动，合适的测试时间应该是在彩票功能测试完成几轮，确定产品相对稳定之后，在启动性能测试。当然测试人员的预先做一些准备也是十分有必要的，比如对测试工具的熟悉，基础相关知识的学习。
TPS
TPS(transaction per second)是服务端每秒处理的请求的数量
TPS最直观的反映了系统的处理能力，是重要的性能指标之一。
大致的计算公式如下：
TPS = 并发用户数\div平均响应时间
与TPS相关的名词：
RPS(request per second)是测试工具每秒发送的请求的数量
RPS 和 TPS 概念不同，前者是每秒发出的请求数量。后者是处理完成的请求数量。
但是显然，RPS 是决定 TPS 的重要因素。
TPS 是由 RPS 、网络延迟 、服务端本身的处理速度 这3个因素决定的。
一个性能表现良好的系统，TPS和RPS几乎是相同的
EPS (error per second) 是 服务端 每秒处理出错的数量，也包含在TPS中。
一个性能表现良好的系统，EPS 应该一直为0
TOPS (timeout per second) 是 服务端 每秒处理超时的数量
超时时间具体是多少，应该由产品需求定义。
一个性能表现良好的系统，TOPS 应该一直为0
服务端本身的处理速度 就是我们要测试的，测试时，我们要保证的是其他两个因素：RPS 和 网络延迟。
做 性能/压力测试 时， 被测系统 和 加压系统， 应该 在一个 带宽网速 比较理想的环境中，首先保证网络延迟没有问题。
然后，性能测试工具 要 测试 TPS 能否达到 ， 主要就是设置每秒发送请求的数量，也就是RPS。
RPS 是由测试工具决定的。
一个压测工具本身的加压性能也很重要。
否则，如果TPS指标比较高，工具本身做不到，就没法测试了。
Jmeter受制于机器性能，单台几期可能支持最大的RPS在几千到几百之间，所以在涉及到大型的高并发测试往往需要使用分布式来实现性能实施，需要一台控制机，指挥压力机来实现。
响应时长
响应时长就是服务器处理的请求耗费的时间
平均响应时长
平均响应时长 就是 服务端 处理请求的平均耗费时间。
这是影响用户体验的重要指标。设想一下如果 TPS 很高，但是，很多请求要很长时间才得到反应，用户体验就会很差。
相应时长区段统计
光看平均响应时长，往往是不全面的。
可能 有些请求会耗时特别长，严重影响用户体验。但是被平均了就看不出来。
响应时长不能两极分化。
这就像 国民收入，不能只看平均值，也要关注挣扎在贫困线上的人有多少。
响应时长区段统计 就是查看是否 两极分化的 衡量指标。
并发连接和并发用户
并发连接数 是 服务端 和客户端 建立的 TCP连接的数量
并发用户数 是 服务端 同时服务的 用户的数量 。
用户的一个操作可能引发多个并发连接。
并发链接
通常，并发连接数指标，适用于 测试 面向客户端程序的 API服务系统，比如 云服务。
和 TPS 对系统性能的衡量侧重点不同 ，并发连接数指标 衡量 系统 能 同时处理 客户的能力。
两者的区别 用一个比方 来解释，就像银行服务：
并发连接数，就像有多少个服务窗口
TPS， 就像每个窗口 服务员的处理速度
每个窗口服务员的处理速度即使很快，但是同时来了很多人，也必须开多个窗口，否则就会有人得不到服务。
测试工具 创建这么多的并发连接， 目的就是为了测试 服务端 是否能支持 指定的并发连接数量。
服务端支持并发连接的数量，是由很多因素决定的：集群系统设置、服务端运行硬件配置、服务端系统软件配置、应用程序设置。
做性能测试时，被测服务系统 一定要按照 性能测试的要求进行部署（模拟真实的运行环境），否则是没有测试意义的。
并发用户
通常，并发用户数指标，适用于 测试 面向真实用户的 系统，比如 淘宝。
一个用户的一个操作可能引发多个并发连接
单独说 并发用户数 这个指标没有意义， 必须指定是 哪种性能测试场景 下的并发用户数。
因为用户的操作行为不一样，对服务端的 请求数量 和 并发连接数也不一样。
而且并发用户指标 是 一段时间 内 的，说某个时间点的 并发用户数 也没有意义，因为该点上，很多用户可能没有任何操作。
比如，一个 商城系统，我们要测试 晚高峰典型压力下，系统的性能表现。
可以像这样写测试用例
系统数据环境
系统中，多少注册用户，多少商品数量等等
单个用户的操作行为
- 先登录，1分钟后
- 随机浏览25种商品，每次浏览间隔1分钟，
- 把5个商品加入购物车，间隔1分钟
- 购买2种商品，间隔1分钟
晚高峰的压力模拟（ 7:00-10:00 ）
- 每秒10个用户登录消费，持续30分钟后
- 每秒20个用户登录消费，持续30分钟后
- 每秒30个用户登录消费，持续60分钟后
- 每秒20个用户登录消费，持续30分钟后
- 每秒10个用户登录消费，持续30分钟
上述测试场景下，并发用户数量是变动的，大概是
- 每秒10个用户登录消费，持续30分钟后 （阶段1）
并发用户每秒10个递增，30分钟后达到 18000 左右。
注意随后这些用户以每秒10个 不断减少（因为该用户结束了）
- 每秒20个用户登录消费，持续30分钟后 （阶段2）
并发用户每秒20个递增，但是算上阶段1用户每秒10个递减，总用户数仍然是每秒10个递增。
30分钟后达到 36000 左右。 这时，系统中的用户全是 阶段2 产生的用户，随后这些用户以每秒20个 不断减少
- 每秒30个用户登录消费，持续60分钟后 （阶段3）
前30分钟 算上阶段2用户每秒20个递减，总用户数仍然是每秒10个递增。
30分钟后达到 54000 左右 。 这时，系统中的用户全是 阶段3前30秒 产生的用户，随后这些用户以每秒30个 不断减少。
后30分钟 增加和用户和 阶段3前30分钟 的用户下线速度 数量相同，所以维持 54000 左右不变
到了阶段2的末尾，系统中的用户数 为54000 左右，而且全是 阶段3后30秒 产生的用户，随后这些用户以每秒30个 不断减少。
- 每秒20个用户登录消费，持续30分钟后 （阶段4）
和 阶段3 后30分钟 的用户下线速度 相抵，以每秒10个 速度递减。
30分钟后减少到 36000 左右。 这时，系统中的用户全是 阶段4 产生的用户，随后这些用户以每秒20个 不断减少
- 每秒10个用户登录消费，持续30分钟 （阶段5）
和 阶段4 的用户下线速度 相抵，以每秒10个 速度递减。
30分钟后减少到 18000 左右。
这时，系统中的用户全是 阶段5 产生的用户，随后这些用户以每秒10个 不断减少，再过30分钟，也就是到了10:30，并发用户数量减少到0
可以看出上述过程中，并发用户数量是不断变化的，巅峰数量为 54000 左右 维持半小时
CPU/内存/磁盘/网络 负载
我们做性能测试时，不能只看 TPS、响应时长 等指标是否达到，也要看被测系统在达到这些指标时，机器本身的负载情况。
所谓负载情况，主要是： CPU占用率， 内存使用，磁盘IO、磁盘使用率。
在性能测试分析时，我们主要关注这两点
- 是否接近满负荷
如果在达到这些指标时，机器已经处于满负荷状态：CPU使用率 接近 100%， 内存几乎用光，那也是不行的。 因为随时系统可能出问题。
就是说再加点压力，或者再持续一段时间，就很可能出现响应超时甚至响应错误的情况。
- 是否资源使用持续上升
这点特别体现在 内存使用率 上。
如果系统资源使用图上，内存使用率是一个斜线不断上升，的情况，那么很可能被测系统存在内存泄露。
这样只要再持续一段时间，就很可能出现系统因内存耗尽而奔溃的现象。
出现这样的图表，就应该添加测试用例，做一个较长时间的性能测试（longevity testing），观查系统的行为。