请求多少次，不止和并发用户数有关，还跟持续运行时间、每次请求的思考时间、接口响应时间有关。

比如：（为了更清晰的说明问题， 以理想状态考虑）

• 1 并发用户，持续运行 1 分钟，接口响应时间为 1 秒，思考时间为 0，那么 1 分钟 60 次请求。
• 1 并发用户，持续运行 1 分钟，接口响应时间为 2 秒，思考时间为 0，那么 1 分钟 30 次请求。
• 1 并发用户，持续运行 1 分钟，接口响应时间为 1 秒，思考时间为 1，那么 1 分钟 30 次请求。
• 1 并发用户，持续运行 10 分钟，接口响应时间为 1 秒，思考时间为 0，那么 1 分钟 600 次请求。

这些都是性能测试的基础，建议看看：
性能概念不清楚的，建议阅读：服务端性能测试 - 入门指南
性能测试工具学习的，建议阅读：服务端性能测试 - 工具篇 (Jmeter)

1、用线上流量统计来计算线上真实压力

根据日 UV 和日 PV 来推导线上真实并发压力，可能会出现严重的性能评估偏差。

因为服务端的并发压力，跟业务本身的特点强相关。

举个例子：秒杀系统，1 秒钟放入 100 万用户，和 1 分钟放入 100 万用户，是截然不同的两种并发压力。

所以，不建议根据 UV 或 PV 来分析并发压力。

建议：根据服务端接口的流量统计来评估当前线上真实 TPS 压力
如果性能目标是满足接下来半年到一年的业务需求，再根据业务增长速度，计算需要的性能冗余。

性能目标评估例子： 比如过去一年，用户数有 100 万，历史峰值 QPS 是 1000。如果接下来一年，我们的目标是用户增加到 500 万，那么线上实际需要的 QPS 目标就是 5000，考虑到业务增长不可预测性（比如超过 500 万）、服务器和开发资源的提前准备、业务的不稳定等，一般准备 3 倍性能冗余，即目标可以定为 5000*3 = 1.5 万，这样满足 1.5 万 TPS 要求的服务，在未来一年内，在软件层面，出现严重性能故障的情况，将比较小。

2、用什么压力模型来测试

如果是一个新系统，建议压力模型顺序：
（1）评估系统压力、拐点、不同压力下表现：用 负载测试（阶梯式加压），建议每个阶段增加的并发，能明显改变性能曲线。比如每分钟增加 100 用户，发现性能直接打满了，那就用二分法，下次每分钟增加 50 用户再试试。
（2）评估系统某个压力下，满足某个业务场景的性能表现：用 压力测试，比如一个持续半小时的活动，那就用目标压力，持续测试 1 小时，观察这期间系统表现。
（3）评估系统稳定性：用稳定性测试，目标压力下，持续运行 7*24 小时，观察系统稳定性，以及是否有内存泄漏。

以上三种压力模型，基本可以满足绝大部分性能需求。

3、建议：先熟悉服务端性能的基本知识

服务端性能的执行，其实大家学习一下基本都能搞定。
但是如果保障自己服务端测试的质量，即能准确做出满足性能目标的性能测试，需要好好考虑和熟悉性能测试的基本概念。
性能概念不清楚的，建议阅读：服务端性能测试 - 入门指南
性能测试工具学习的，建议阅读：服务端性能测试 - 工具篇 (Jmeter)

性能测试工具大同小异，一通百通。

测开目前看路窄，能做开发还是做开发吧，成为 T 型人才的机会比测开大太多了

奔着 100 分去吧，先别想着买房，先努力奋斗拼搏，钱、房都会有的。

我比你的起点低太多了，我家正儿八经的穷 4 代，全国倒数二本毕业，第一份工作在富士康，现在也在北京买房买车娶妻生子了。

我还是不够努力的那种，所以先努力做 100 分，然后我觉得你所关心的那些，用不了几年就会实现了。

复杂的业务，既可以增加你的行业知识深度，又可以增加技术深度，多好啊。

机会难得，能坚持做起来的话，下一份工作可能就跃升一个档次了。

不好意思，这块放了太久了，可以咨询一下 @zsx10110

全职奶爸看到帖子后，手动点赞，哈哈，好有共鸣。

真的是经典中的经典，文中提到的方向，真的很适合参考，是成为 T 型人才的很好的引导。

不加检查点的测试通过都是耍流氓

被神化的一种可能是，能做到的人或者能做成功的人太少了。

不过有人很早就做成功了，看看十年前的段念，已经把自动化成功做起来了。

性能测试的关键，不是如何写脚本、如何用工具、如何监控。

性能测试的关键是：如何理解性能目标并规划性能测试模型，建议看看我的两篇文章：

• 《服务端性能测试 - 入门指南》
• 《服务端性能测试 - 工具篇》

科普好文

可以的

1、先搞明白 TPS 和 QPS 的区别
TPS(Transactions per second)：是从事务的角度出发，比如一个下单事务，可能包含 3 个接口。
QPS(Request per second)：可以理解为每秒接口的请求数。

2、如何对一个接口性能进行评估？
建议使用 “负载测试”，可以找到该接口的性能在不同并发压力下的 QPS 能力。
详细说明如下：

3、性能测试中限制 QPS 操作：
首先为什么要限制 QPS 呢？如果是为了做长时间的稳定性测试，建议先用负载测试测试出各阶段并发压力下的 QPS，然后再用对应的 QPS 去做。

如果使用限制 QPS 的插件去做，Jmeter 会额外增加 QPS 的计算，增加了压力机的负载。

亲测有效：

哈哈，赞赞赞。 编程对于不懂的人来说，确实有点像超能力

哇，厉害厉害，可以写一篇介绍一下你们的实验室和测试流程，帮助大家

已经停止维护了

专业算法开发的，可以评估算法效果。但是在音视频质量上，还是建议专业的音视频从业人员建设实验室来做。

@ 蔓藤不到冬 @ 清风的故事 客气啦，能帮到大家就好

你这个图有毒，吓我一跳😂

jmeter setup 中登录获取公共变量，可以做到

飞哥的进阶之路看着像坐火箭，其实是每天的努力学习、实践、总结，佩服佩服

同意，低代码平台，我们这边整过。

发现对于没有代码逻辑思路的测试同学来说，低代码写出来的用例质量一直会很低。但是写代码的用例质量，写个半年一年，基本合格。

而且写代码的同学，可以通过培训加速提高到合格线。

说白了，写自动化用例基本上都是套路 + 关键函数，有点技术含量的全部封装出来即可。

换个思路，看文中描述，不知道我理解的对不对：
setup 登录
beanshell 获取 token
普通业务线程组使用 token
teardown 删除 token

不太明白楼主为什么不直接使用 beanshell 声明全局变量（值为 token），然后线程组直接使用就行。

不需要写 csv 和删除 csv 的操作