基金股票不亏都难，已经看开了

有工作之外的技术真好

是企微请求我们系统，把数据给我们。。就怕数据给的多了快了把系统给弄崩了

嗯，压调用企微接口的场景的时候会注意这个的

虚拟出一个接口估计不太合适吧，得到的结果只能证明虚拟接口的性能

和开发讨论了下，模拟企微对系统发起请求理论可行，但请求会涉及到各种加密，估计难点就是如何构造请求了

可能是因为业务带销售性质，对聊天记录比较敏感吧。。

勾上这个试试

目前待的这个团队，性能指标只有并发用户数，只要不报错就继续加线程 ，开发可能为了省事也同意这个指标，昨天特地为这个争论了一下，没啥作用。

我目前也是这样理解的，而且实际压测过程中拿着 TPS 和响应时间找开发运维进行调优的时候他们也比较有方向，调优的目的只有一个，就是减少响应时间增加 TPS。但现在换了个团队之后概念这块都要重头来，并发这块统一口径挺难的，要么争论要么加入。

翻到一篇阿里云大佬写的，现在性能这块应该是分成了两个派系，一派是并发，一派是 TPS，但是两个流派都能通过分析和调优解决问题。

https://developer.aliyun.com/article/709950

看了后思路突然打开了，既然线程数和 TPS 都能解决问题的话，那其实配合团队目前的水平更改测试方式才是正确的。

同二线测试，10k 往上差不多得是管理级别了，其实二线搞测开技术挺香的，因为没几个测试会，容易得到认可，前提是公司有晋升机制，可以爬到管理层，不然也是凉凉

比如我 1000 个线程持续压测，但此时 tps 是 100，在某个时间点，有 100 个线程在服务里面，那剩下的 900 个线程是在哪个位置排队呢，在 nginx 里面还是其他地方呢

确实是这样，但是现在很多团队还有领导，都认为并发数这个概念是以线程数或者用户数来判定，想要在团队里改变这种观念太难了，甚至有次出完性能报告给甲方后，甲方又找了家第三方有测试资质的机构再次测试了一遍性能，一看第三方的报告，1000 并发就是 1000 个线程，给我整不会了都

我理解的是 tps 饱和了，说明服务器只能处理这么多请求，再往上加压力就开始排队了然后触发超时

不是所有场景都适合写自动化的

你想想手工测试的时候是怎么测接口的,关注哪些点,怎么验证数据真实性然后吧这些写点进用例里面
我是这样测的,状态码,code,响应时间,返回参数,返回参数需要连接数据库写 sql 进行断言