这个是典型的负载机性能问题存在问题，导致你看上去并发压力升高，但是到达服务器的请求数并没有增加。你看网络请求并没有增加哟。

已经在团队内部多次实践，文章中也有具体的案例了。

需要有安全的环境，还有适应的引导和鼓励，回顾会的一些方法可以用用

是的，很多事在做决策前，都可以用这种思路做下事前分析。

感谢认可

链接：https://pan.baidu.com/s/1R3p0K36e62ldMpEz2z7gNQ
提取码：2l5j
完整版

就是用的 commitlint

思维模式，执行力，业务感度。 三者缺一不可。

理论和实际总会有出入，本文讨论的只是一些可能，在符合 3 模型的条件下，加人是合理的。

不能因为延期经常出现，就觉得他是合理的。

防微杜渐，未雨绸缪。尊重团队产能，才会做的更好。

进的早，也要表现好啊，不矛盾

写用例浪费时间？那你怎么做测试执行呢？想到哪测到哪么？

可以做些测试以外的事，从研发全局的角度看看能做些啥。或者主业划水，副业搞起。

划水久了，真就水了。

不要被测试角色捆绑了。

落地实践可参考：https://testerhome.com/topics/36475

是的，本质还是团队规范的问题，或者说研发负责人的质量意识，决定了团队的质量意识。

优秀~

接口自动化测试的意义在于以下几点：

1. 实现分层测试：这个才是核心重点，测试是需要分层的，而不是一股脑的丢给 UI 或者 E2E 测试，这样会给问题定位带来更大的麻烦，而且修复成本也高。就如文中的例子，你可以很直观的判断出来是 UI 调用错误，而不是接口本身的问题，如果没有接口测试，你需要做更多的排查。

2、提高测试覆盖：有些场景并不是简单的通过页面操作就可以覆盖到的，比如异步类请求，比如第三方的依赖，比如多层接口的套用调用

1. 适应持续集成和交付：可以有流水线有效的结合在一起，做为基本的质量门禁

至于节省的成本，这个要从更大的时间维度来看，如果只是某个迭代，那接口测试一定是降效的，因为它意味着更多 的时间投入和维护成本，但是从半年或者 1 年的时间来看，它是能够提效的，提效的程度取决于你执行的次数。

我只想知道这么扯蛋的性能需求是谁提出来。

行业总归要发展的，这个并不以个人的意志为转移。那就自己跑快点，没什么不好的。不给自己的借口。

这个帖子这么多人点赞我是没想到的~感谢大家支持

此处有掌声👏

1. 指标的意义就是引导团队做出有意义的改进即可。公式没有太多的固定式

2. 度量和 OKR 挂钩，都是不太靠谱的。会为了指标而指标。造数还是比较容易的。

测试就像品菜师，会在厨师精进的道路上提供必要的帮助。二者相辅相承。才能让整个研发过程更加流畅。也能体现测试的价值。

测试并不比开发低一级。

很多数据都是可以量化的呀，比如说验收标准数量、用例数量、缺陷跟踪、风险评估、专项测试等。

如果你的老板都是这样的，那就没什么好说的，至少我经历过的和我听说过的，大部分 Leader，还是愿意了解测试的工作内容和价值的。

表达也是件很重要的事。文中也说了，适当的时候，刷刷存在感，多多汇报。

现在酒香也怕巷子深。你不说，没人会替你考虑的。

不应该是有了好的测试。才能让开发优秀起来？