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

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

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

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

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

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

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

来个播客直播？

两个数据都很重要。

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

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

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

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

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

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

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

求指导，线上怎么 mock？

嗯嗯，是的，横捷，请教一下，你们之前的预警或监测机制大概是什么样的啊？

容量测试可以

嗯嗯，白名单专注于检测自家系统的质量。

关于第三方服务的监测：
（1）通过 UI 自动化（真实支付用例）监测
（2）第三方支付提供测试账号，用于接口拨测；

我理解的白名单，对于测试账号默认不调用支付系统，只覆盖基本逻辑。

嗯嗯，这样可以。 是不是也可以加白名单，对于测试账号默认不调用支付系统，只覆盖基本逻辑。

请教各位有过在线支付接口测试经验的朋友，帮忙回答一下，多谢

请教一下恒捷，如果对在线支付做正式环境的拨测的话，是不是只有白名单一条路走了

本文 转自九边的微信公众号，麻烦@Onions将第一作者的名字和文章来源置顶吧，尊重一下原创

飞哥🐮

能分享出来吗？我们最近也在弄

httprunner V3 的文档，可以看这里
https://ontheway.cool/HttpRunner3DocsForCN/

建议使用相对 x,y 控制，找一个稳定的参照物，这样比 x,y 绝对值稳定性高很多

不讲武德啊

wrk

1