从两个层面定义性能场景的需求指标：业务指标和技术指标
业务指标和性能指标之间的关系：
从图中可以知道：
所有的技术指标都是在有业务场景的前提下制定的
技术指标和业务指标之间也要有详细的换算过程
性能测试行业常用的性能指标表示法：
1、TPS（Transactions Per Second）：每秒事务数
在性能测试过程中，TPS 之所以重要，是因为它可以反应出一个系统的处理能力。TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。
通常情况下，我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。
举个例子：
如果我们要单独测试接口 1、2、3，那 T 就是接口级的；如果我们要从用户的角度来下一个订单，那 1、2、3 应该在一个 T 中，这就是业务级的了
2、QPS（Query Per Second）：SQL 的每秒执行条数
从第一个例子中QPS其实描述的是服务后面接的数据库中 SQL 的每秒执行条数。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的。所以不建议用 QPS 来描述系统整体的性能，以免产生误解。
3、RPS（Request per second）：每秒请求数
请求这个词比较广泛，要看是哪个层面的请求
如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2 次库存服务，调用了 1 次积分服务，那么这个请求数是3+2+2+1=8吗？不是的，如果要描述整体，最多算是有 3 个 RPS。
4、HPS（Hits Per Second），每秒点击数
Hit 一般在性能测试中，都用来描述 HTTP Request
5、CPS/CPM（Calls Per Second/ Calls Per Minutes）：每秒 / 每分钟调用次数
6、RT（Response Time）：响应时间
RT = T2-T1
响应时间的概念简单至极，但定位就复杂了。性能测试工具都会记录响应时间，但是，都不会给出后端链路到底哪里慢，因此我们需要进行时间拆分，比如：
先画架构图，看请求链路，然后再一层层找下去，在所有服务的进出口上都做记录，然后计算结果就行了。也有链路监控工具和一些 Metrics 的使用，让这个需求变得简单了不少：
压力工具中的线程数和用户数与 TPS
并发线程数在没有模拟真实用户操作的情况下，和真实的用户操作差别非常远。从上图中，可以知道压力工具是 4 个并发线程，由于每个线程都可以在一秒内完成 4 个事务，所以总的TPS是16
那么用户数怎么来定义呢？有些人认为一个系统如果有 1 万个用户在线，那就应该测试 1 万的并发线程，这种逻辑实在是不技术。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于 5%，甚至低于 1%。
拿 5% 来计算，就是 10000 用户 x5%=500(TPS)，注意哦，这里是 TPS，而不是并发线程数。如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。
通过这样简单的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了：
但是！响应时间肯定不会一直都是 100ms 的嘛。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系
————————————————
原文链接：https://blog.csdn.net/ZhangYongWei1955/article/details/106890788