哥们，你出现挺频繁的，又被扣了工资，所以我打算多跟你说一点。
首先，我本人在全力做自动化中，无外乎就是 ui+ 接口。ui 用用 selenium 和 puppeteer，接口跑跑 testng
自动化被定义为做回归和冒烟，其实是为了节省成本。但是如果你把所有能覆盖到的场景，包括文件下载验证文件内容等等，你会发现其实覆盖的越全，就越舒服。为什么呢？举个例子，你自动化用例写了 1K 条，2 分钟跑完，没有发现问题，和人手工执行没发现问题是一模一样的，既然这样，领导会选哪个？
相反的，你跑了 1K 条，发了了几个迭代的 bug 甚至是很难执行到的长流程 bug，功能测试没发现。这就更显而易见了。
不是说本末倒置了，自动化这块有没有价值，答案是有的，而且很大。你看国外乃至国内大一点的企业都会去有专门做自动化的人员，但是自动化这块弊端也很明显，就是很有可能覆盖不全，有些无法执行到，或者是必须用直观肉眼和逻辑思维去处理的流程，毕竟现在还没有这么智能，多半的用例都是提前录入或者万能不变的很难有成效。

要分层测试，单纯接口自动化不可能覆盖全场景。
另外要有衡量标准，如何认为全场景覆盖?功能 case 全覆盖?还是代码分支全覆盖?空口说覆盖，结果就是领导认为怎么样就怎么样。

全覆盖不现实，然而项目领导们又不是很懂，“这怎么不能自动化，那怎么不能自动化，我跟你说你可以这样这样，可以那样那样”，给了任务要写个 case 就要一长串，想拆成小颗粒写但是需要一些资源上的支持，又 TM 不提供资源支持

好机会，又是一个涨薪的机会，先提出一个人搞不定，然后看领导脸色，如果面色不好赶紧解释这个会太累，接着透露出年底了可以加薪一波吗，剩下的我就瞎编不出来了

做自动化测试就是为了代替人。把冒烟当自动化测试的目的是做不好自动化测试的。
特别是接口测试，天然适合自动化测试。
覆盖所有测试场景这个描述是不准确也做不到的。应该是覆盖所有正向业务场景，以及你想覆盖的其他异常场景。

确实可能做好，覆盖全了，每次点一下执行就执行了 1K 的 case，这样我认为对于不频繁变更的产品，确实带来好的效益，我们项目经常频繁变更 (每周一次迭代)，这样维护成本高，工作也不只是做接口，还有很多杂七杂八的，项目东西也很复杂，东西功能模块也很多

一看就是有准备的人

好契机，有技术总监盯着这个事，开发没理由不去配合
要求没集成 swagger 的必须集成，接口文档/定义信息不完善的必须立刻搞好

前提是，你得说服你们总监，自动化测试不是测试工程师自己的事，开发必须配合，看看他是否还依然那么坚决，如果依然坚决，那么如上所说，你会做得很顺畅；如果不是，那么估计就是找个由头整你们，赶紧闪人啊~

好的，谢谢大佬的建议。

来一波 case 评审了，他们觉得 ok，那就是覆盖到位了

最近听到一个观点： 组织内部达成共识，即使是暂时错误的共识也比没有共识要好。当然这种错误的共识也要是大家一起承担的那种，不是甩锅强推强迫类型的共识。

说实话，接口自动化测试我还是很支持的。这个基本可以保证业务流程不出什么大问题，当然客户端交互这个不说了。

是不是可以理解成监控线上业务是否正常

就在 jp@gc - Stepping Thread Group (deprecated) 下新增 http 请求等场景，为什么要在原来的线程组下添加？

我那天试啊试，试出来了，但还是谢谢你。。。。我现在遇到的问题是服务器带宽没跑满，连接池的最大连接数也够用，但是并发的线程数从 20 加到 110，吞吐量还是在 4.8/sec,楼主能赐教一下吗

性能的指标都得关注，看这个接口的服务 cpu，内存，数据库的 cpu,是不是都没满，一般来说服务资源不足会导致接口响应慢，错误率高等原因，如这些指标都还未跑满，则看你接口设计的场景，或让开发加日志，在压测时，看是阻塞在哪个环节

https://testerhome.com/topics/30492

我发帖了，你可以看看，服务器资源都是 OK 的，再不行我就让开发加日志了