资深测试总结，性能测试-业务量/吞吐量/存量数据设计关联（详细）

---

前言

业务量

是不带时间单位。我们提到业务量的时候，一定会加一个时间单位。比如说，每天的业务量是 100 万笔，每年的业务量是 1 亿笔，等等。

吞吐量

是自带时间单位的。吞吐量是单位时间内处理的业务数量。

业务量和吞吐量的关系

那么问题来了，我们做性能测试的时候，用哪个词呢？业务量 or 吞吐量？
事实上，这两个词我们都用。因为他们的内涵不同。

业务部门的目标里，往往是一年业务量多少，一天业务量多少。而这些目标并不能勾勒出性能测试目标。因为性能测试要的是每秒的业务量有多少。

举个例子，一天 24 万笔业务，并不代表一小时处理 1 万笔，也许这 24 万笔是一个小时里处理完的。

用户往往等个一两秒钟还是可以忍的，如果等 10 秒钟，恐怕是觉得系统已经挂了。因此，系统要及时处理业务请求 / 报文，不能产生严重堆积，我们最关注的是一秒钟处理多少业务。而不是一小时多少，或者一天多少。

这里有存在一个换算的过程。
业务的要求是 1 天处理 2000 万笔业务，那么吞吐量目标是多少呢？

这就要看系统的性能模型，一天当中哪个时段业务量大，这个时段的业务量占一天业务量的百分比是多少？然后一步一步的计算出峰值时期一秒钟的业务量，它，就是我们的吞吐量目标。

存量数据

有了吞吐量目标，但还不能立刻就动手做测试，这是因为，还有第三个概念，存量数据。

如果数据库是一个空库，或者数据库是个存有 2 亿条记录的库，那么 SQL 的增删改查的响应时间是完全不一样的。

对应的业务响应时间也完全不一样。那么，我们数据库里面的存量数据应该设多少呢？

存量数据和业务量的关系

预计的存量数据，就要用到业务量这个概念。
毕竟，存量数据是以年、月、天为单位的，而不是以秒为单位的。
比如说，这个系统的存量数据是 3 年，或者 3 天，而不是 3 秒。

并且，计算一年的存量数据，肯定不是用峰值每秒的业务量 360024*365 来计算的。而是用到业务部门提到的业务量。

比如，今年业务量预计 100 亿笔，预计年增长率是 50% 。那么，如果要测试系统能否满足 3 年以后的需求，就要这么计算：假设系统存量数据保存 3 年，那么 3 年后的存量数据是（ 100+1001.5+1001.5*1.5 ）亿笔。

三年后的吞吐量这么来计算：
假设一天业务最大的那个小时，占全天业务量的 20% ，业务量最大的一秒占这个小时的 1/2000 。假设一天业务量是 A 笔。

今年的每秒吞吐量目标 B=A20%(1/2000) 。假设性能模型不变，三年后的每秒吞吐量目标 C=B1.51.5。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

付出不一定有回报，但不付出肯定没有收获。成功需要奋斗，而奋斗需要勇气和毅力。只要努力拼搏，坚持自己的梦想，即使路途再艰辛，也能够创造属于自己的辉煌人生！

每一次的努力都是在为自己的梦想打下坚实的基石，即使前路漫漫，也要勇往直前，不忘初心，砥砺前行，一步一个脚印，坚定走向成功的彼岸。

只要你愿意努力，就一定能够达到自己想要的目标。每一次挑战都是成长的机会，不要害怕失败，因为勇于尝试才是进步的前提。坚持不懈，勇往直前，让你的人生活出精彩！