标签：second 处理 能力 一个 应该 src 慢慢 结果 拼接
题目所示的其实都是性能需求指标。
通常，性能指标可以从两个层面去定义：业务指标、技术指标。而且，这两个之间是存在映射关系的。
举例，如果一个系统要支持 1000 万人在线，可能你能测试出来的结果是系统能支持 1 万 TPS。但是，如果问你，1000 万人在线会不会有问题？这估计就很难回答了。
所以，业务指标和技术指标的关系是：
有了关系之后，就可以回答“1000 万人在线会不会有问题？”。比如，我可以回答“有问题”，因为1万 TPS 的时候，接口的响应时间大幅超过预期。
TPS，这是一项关键指标，用来描述每秒事务数，可以反应出一个系统的处理能力。
但是，TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。
如图所示，一个业务流程图：
当然了，还要具体看系统是怎么设计的。通常来说，积分服务是异步的，而库存不是异步，那么这个业务级就可以看做是 1、2 两个接口。但是，在做这样的业务级压力时，3 接口也是必须要监控分析的。
所以，性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用。
具体用示例来说明下：
接口级脚本：
——事务 start（接口 1）
接口 1 脚本
——事务 end（接口 1）
——事务 start（接口 2）
接口 2 脚本
——事务 end（接口 2）
——事务 start（接口 3）
接口 3 脚本
——事务 end（接口 3）
业务级接口层脚本（就是用接口拼接出一个完整的业务流）：
——事务 start（业务 A）
接口 1 脚本 - 接口 2（同步调用）
接口 1 脚本 - 接口 3（异步调用）
——事务 end（业务 A）
结合上述示例，再次理解下：你要创建什么级别的事务，完全取决于测试的目的是什么，这句话。
另外，在测试过程中，通常是先接口级、后业务级的顺序，容易定位问题。
QPS 一开始是用来描述 MySQL 中 SQL 每秒执行数 Query Per Second，所有的 SQL 都被称为 Query。后来，由于一些文章的转来转去，QPS 被慢慢地移到了压力工具中，用来描述吞吐量。
如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的，所以不建议用 QPS 来描述系统整体的性能。
RT 就是响应时间（Response Time）。
图示中 T1 和 T2 分别代表请求时间和返回的时间，所以 T1 - T2 = RT，即响应时间。
不过这个响应时间是包括了后面一连串的链路，如果要定位响应时间慢在哪里，就要知道各环节的耗时，除了在所有服务的进出口上都做记录，然后计算结果来实现，目前也有成熟的工具。
它很直观地显示了，在一个请求链路上，每个节点消耗的时间和请求的持续时间。
通常是不需要用吞吐量这个概念的。因为它在不同人的脑子里会存在一些误解。
比如说，有些人说吞吐量就是在说TPS。有些人说吞吐量是说的每秒字节数。所以不建议用这个概念来承载性能指标，有TPS就够了。
关于性能测试的种种，简化完后，需要记住的关键字是：
本文参考：
高楼老师 性能测试实战30讲
标签：second 处理 能力 一个 应该 src 慢慢 结果 拼接
原文地址：https://www.cnblogs.com/pingguo-softwaretesting/p/15011708.html
