恭喜恭喜，新婚快乐

😂，鹅友好，大佬就不互道了，快成梗了

我勒个去，暴露年龄了

那个转经筒，13 年的时候转过

卷的不行了，睡觉时间都不多了

假设服务器的线程池只开了最大 500 个线程时，或者服务器的资源，只够开销 500 个线程时，500 个并发和 1000 个并发，性能结果差别会很大

建议使用腾讯会议吧，別找会议室了

666，第一次见到这种方案，测试效率大大提升

我在北京腾讯，目前在武汉有 HC，武汉团队规模比较大

欢迎大家投递简历：851462306@qq.com

朝气蓬勃，向你学习

哈哈，必须的，需要补的课太多了

哈哈，又到了吸收飞哥养分的时候

没问题

赞赞赞

说了最简单的部分

httprunner 是极其优秀的接口自动化框架，设计思路和开源项目整合都非常优秀，不仅仅可以作为工具入手，更可以作为学习框架设计、优秀源代码学习的参考

自己做的一些能拿得出手的工具，可以在简历中着重体现，用 STAR 重点描述。

我的感觉，市场上不缺少会写代码的测开，但是非常缺少有成功经验和优秀案例积累的

建议简历中增加数据的体现，比如你加入后，通过什么行为，提升了什么数据。比如做过多少用户级、多大量级项目的质量保障，类似这样能体现你亮点的

剩下的这些技能的罗列，目前的行情都是基本要求，但算不上亮点。

测试人员本来就是检验工程的质量的，如果开发做的够好，确实不需要单独招聘测试。

很久没看到这样的好文了，支持

来个播客直播？

两个数据都很重要。

TPS 是最直观的表明服务性能能力的一个指标，但是同样一个服务，在 1000 并发下和 2000 并发下的性能表现可能会差距很大。 1000 并发和 2000 并发对于服务来说，表示不同的连接压力。

举个例子：当服务最大处理能力为 1000TPS 时，当 1000 个并发压测时，平均响应时间为 1 秒。
但是当 2000 个并发压测时，因服务处理能力有限，平均响应时间可能会增加到 1.5 秒。

这个时候，当并发继续增加的时候，服务很可能出现性能拐点（QPS 大幅下降，响应时间大幅增加）。

所以，在日常压测中，开发同学还需要考虑，当大量并发链接请求来临时：
（1）是否会出现性能拐点
（2）到达性能拐点之前，是否需要增加降级方案
（3）对于易引发性能问题的并发数，是否要增加细粒度报警
等等
以及：
（1）在目前的基础上，是否可通过调整配置，来提高服务的 TPS 能力和应对并发的能力

监控和预警方便多聊聊吗？ 我们这边也是支付如果做正式环境拨测，比较费劲。

所以更多的是监控自身服务的拨测，期望隔离开第三方支付服务

我们这边全是 go，有类似 sandbox 这类的中间代理吗？