不会出现响应时间和 TPS 同时变多的情况，因为这两个本身就有点互斥的意思。

后续专门写一篇吧

并没有，敏捷和加班不冲突。
虽然敏捷不提倡加班，但现实就是还是要加班，敏不敏捷都一样；
但是敏捷可以让团队更有目标的加班，做好了也可以不加的，
主要是工作透明化。

不恰饭，诚心推荐

新年快乐～

竟然是个 QQ 群~~好多年没用 QQ 了。

在朋友圈看到了 震撼、神奇、折服等词来形容这个工具。然后就去下载玩了下。和恒温的感觉差不多，离落地应用还远着。每个项目的 prompt 还得自己改，慢慢适应。

我们的团队基本上都是这么做的，当然每个团队的实际情况不一样，只是一种参考。相对于拍脑袋，分成三部分还是好点的。

感谢你对灌水文还如此在意~

从技术的角度没毛病~~但是组内人要是怎么玩，是要挨骂的

Jmeter 也支持的啊，非 GUI 模式。这种方式严重依赖工具提供的功能，文章也说了很多 sample 还不支持。所以没想明白真实的应用场景是什么

没想明白什么场景下会用到这个工具。一般都是生成好 JMX，然后丢给 Jmeter 去跑就好了呀

没想到这个帖子得到大家这么多的讨论，其实就像文章里说的，这只是个人的选择，没有对不对；
只在于自己的选择，每个人有不同的选择，世界才会多彩；
只要你能平衡，不做过多的抱怨即可。
大家都过的很不容易，不是么。

这个歧视做为个体没办法改变，可以吐槽，但没什么意义。希望以后会变好吧

对于 Metaspace 没有设置 MaxMetaspaceSize 值，导致使用过多，本次问题是因为还没触发 FGC，就 OOM 了。
参考：http://lovestblog.cn/blog/2016/10/29/metaspace/

是的，我在 TCL 呀

1. JMV 内存在 02 段落写清楚了，大概使用了 561MB，还没达到 GC 的条件，所以没继续看；

2. Metaspace 正常情况下，本来就不会被 GC 回收，GC 回收的是堆栈空间；

3. 在解决方案中有提到减少业务的处理数据量，分批处理，减少反射的集中使用。其实在日常的业务代码中，也不提供过多的使用反射，对类的安全性也是个入侵。

4.因为很多代码处理逻辑的底层，使用了反射（包括上面提到的 spring 的 BeanUtils 的拷贝对象，json 的序列化） --没说 BeanUtils 处理 Json，而是说这两个都用到了反射；

感谢讨论。

接口文档完整 --这个基础就有很多团队做不到的。

在有完善的前置条件下，接口自动化当然适合开展，性价比也最高。

交付类的项目，给到工厂部署后，基本上就不会再动了，除非业务的工艺流程发生变化。

而且维护也交付给工厂的 IT 部门了，所以不太适合花时间去搞自动化。

水不水的，大家看着就好，不同水平的人本来知识结构就不一样。可能你懂的多，我的文章不就水了嘛。

不过确实是公众号同步过来的。

流量回放的技术成本更高，更加依赖基础设施。

测试左移其实也是为了更好的做测试，最基本的，左移能够保证你的测试用例是相对更准确和靠谱的。

左移不影响你测试能力的提升。有的人从技术层面去提升，有的人从业务的角度出发。在当下的互联网环境中，可能对技术的提升需求更显著。但是在实业或者制造业，一个慢懂 MES 或者 WMS 业务流的测试，价值远高于会技术的测试。笔者现在就在实业，比较清楚业务的价值。

所以不是所有人都适合 Leader 的，如果只是传声筒的作用，要他干什么。

活可以接，但该出的声音还是得出，能怼的还是得好好说

理论肯定是象和简化了部分场景，大方向上应该是没什么问题的。

缺人的情况下，更得注意做事方法，有些成本还是得花的，比如左移的时间、和开发对齐的时间，主动点。

无非是把时间花在提测前还是提测后。

市场越不好，越需要左移，而不是以 BUG 数来保命，本身就不靠谱