放学别走

好的，自认为最佳答复，棒

对，同理不同事

哈哈，这个跟滴滴什么关系啊

mysql 认为最有效的索引跟你们设置的索引，有哪些具体的不同吗？为什么会引发线上事故啊？

1、性能上不去无非两方面原因：压测服务器的性能问题、被压服务器的性能问题

（局域网环境，初步不考虑网络环境因素）

2、压测服务器性能分析：

初步分析得出结论 1: 8slave 测试接口 1（http://.../s/0ms/1k）的时候，压力服务器 CPU 资源达到瓶颈，服务 tps 性能应该大于 4794，可以增加压力服务器来测试服务器的真实性能；

分析过程如下：

8slave 测试接口 1（http://.../s/0ms/1k）的时候（算了一下，你的持续运行时间不到 90s，大概 75s）:
测试接口 1 性能结果：tps 可以达到 4000，平均响应时间 152ms;
服务器资源情况：被测服务器资源无异常，压力服务器 8 核 CPU 全部满载，初步推测，随着你加压时间的增加，cpu load 会增加至一个稳定的数值；
接口 1 性能测试结论：

• 被测服务器的单接口 1（http://.../s/0ms/1k）可支持 tps 性能大于 4794；
• 压力服务器 CPU 资源出现瓶颈；

分析结论 2:压力服务器可以达到每秒发送 4000tps 的性能。

3、被压服务器性能分析

8slave 测试接口 2（http://.../s/200ms/1k）的时候，tps 上不去，初步认定为被压服务器的性能问题为：连接堵塞 + 响应时间过长。

压力服务器性能分析过程：根据第 2 部分可以看到，压力服务器最少可支持每秒发送 4000tps 的能力。
被压服务器连接数分析过程:

8slave 测试接口 1 的时候，被测服务器每核 cpu 均不到 50%，假设目前被测服务器的硬件资源没问题。
计算被测服务器支持的连接数：假设连接数为 n，接口平均响应时间为 t ms，
则每个连接数每秒可以处理的请求数为 x = 1000 / t;
tps = n * 1000 / t;
则，被测服务器的连接数 n = tps * t / 1000;

根据接口 1 测试结果，被压服务器连接数至少为：n = tps * t / 1000 = 4794 * 152 / 1000 >= 728;
8slave 测试接口 2 的时候，平均响应时间达到了：999ms，根据上面的公式 tps = n * 1000 / t，可以计算出理论上的 tps 应该>=728，但是实际测试结果 tps 为 990，说明 8slave 测试接口 1 时，没有达到被压服务器的最大性能。8slave 测试接口 2 的时候，达到了被压服务器的最大性能，原因是连接数过大或过小造成的请求连接堵塞 和 接口 2 响应时间过长；

真实连接数计算：8slave 测试接口 2 的时候，平均响应时间 999ms，tps990，根据公式： n = tps * t / 1000 = 990 * 999 / 1000 = 989，约等于 1000 连接数；

结论：

• 结论 1: 8slave 测试接口 1（http://.../s/0ms/1k）的时候，压力服务器 CPU 资源达到瓶颈，服务 tps 性能应该大于 4794，可以增加压力服务器来测试服务器的真实性能；
• 结论 2: 8slave 测试接口 2（http://.../s/200ms/1k）的时候，tps 上不去，初步认定为被压服务器的性能问题为：请求连接堵塞 + 响应时间过长。
• 结论 3:当前服务器连接数设置为 1000

建议：

• 建议 1: 8slave 测试接口 1（http://.../s/0ms/1k）的时候，增加压测服务器资源测试，或更换测试工具 locust 为 wrk(目前得知的硬件性能转化率最高的工具)
• 建议 2:8slave 测试接口 2（http://.../s/200ms/1k）的时候，tps 上不去，可以上下调整连接数观察 tps 变化和响应时间变化，有可能因为连接堵塞导致的响应时间增大。

mvn 名利挂执行，比如 mvn clean install

我只能说，当事情达到一定复杂度的时候，肯定需要写写画画、整理规划。
如果你觉得你的工作只需要想一想思考思考就可以完成，那你的工作肯定还不够复杂

我专门把 youtube 的英文字幕拿到 google 翻译上 翻译了一下，发现一样的
看来不是 youtube 翻译准确度不够，是 google 翻译准确度不够

是，满足基本要求

是啊，功能很强大，就是好想翻译不够准确

看飞哥写的东西，就两个字，高级

我们要做一个测试平台，目前部分需求还在调研中，这是其中之一

谢谢，冯大辉是我偶像，虽然他走了

关注你很久了

属于测试平台，有很多业务线使用，问题是：测试 leader 有权限直接修改组员的测试用例吗？

涉及到用例优化的问题，评审也不一定一次就最优

谢谢修文，可以说明一下理由吗？

同意

XX 公司 + 不可以 + 测试工程师
理由：测试 leader 直接修改 case：
1、容易导致混乱，虽然有修改记录
2、容易写成更差的 case，组长写出来的 case 不一定更好，如果不好，组员没有组长的勇气，可以直接改回来
3、容易伤害测试组员的自尊心

需要找外援来抗一波攻击了

谢谢关注

我是在 ubuntu 做的，应该差不多，要看具体的失败原因了

不需要会用 docker，按照安装教程里面的命令敲打就行

建议直接 docker 安装 STF 吧，很简单，很顺畅，可参考：https://testerhome.com/topics/10406