按照你的公式：170000*0.8/(3600*0.2)=188.8888889 不知道你怎么算出来是 16 和 23？

另外压测结果中产生的 tps ，除了和并发数有关，还和接口的实际处理时间有关。处理时间越短，平均每秒能处理的事物数量就越高，tps 就越大；反而如果处理时间很长，平均每秒的处理事物就越少，tps 也越少。

我理解 5 人并发，是指 5 个人同时发起请求的意思，不是说每秒 5 个请求。每秒处理多少个请求，还取决于服务器接口处理的速度。
举个例子，每个请求平均 0.5 秒可以返回，那么每秒可以处理 5*2=10 个请求，30 秒就是 300 个请求；反之如果每个请求平均 2 秒返回，则每秒可以处理 5*0.5=2.5 个请求，30 秒就是 75 个请求。

不需要写的，可能是你传的参数没有配置

https://github.com/jerrylizilong/api_test_demo 以前有写过一个 demo，可以参考一下

我记得直接把你的 code,response print 出来就可以了，allure 的 log 里面可以看到

我记得直接用 print 就能记录到 log 里面的

1. 建议你封装一下通用的请求方法，加上通用的打印输出。
2. 如果是 pytest 里面没有输出，建议试下加上 -s
   

你的代码里吧邮箱账号密码都贴出来，不怕被盗吗？

你的代码最好格式化一下，这样看得太累了。
说下我的推测吧，你这是一个测试类，用 py.test 会默认收集 test 开头的方法作为测试方法，所以会按照 pytest 正常执行测试；
而你如果直接用 Python 命令执行这个文件，因为没有 main 方法，是不会执行到这个测试方法里面的。

先确定你们的需求是什么。
我理解是前端的报错进行上报，有可能是服务端返回的错，也可能是前端处理某个逻辑的报错。按照不同的场景去模拟报错应该就可以了。
而开发让你用抓包软件，应该是修改服务端的返回，来模拟服务端返回错误的场景。

我觉得是测试深度和维度的选择问题。你说要到数据库和 ES 里面查询，那肯定业务上需要校验到这部分的数据，而这些数据的准确性可能是直接通过接口验证不到的。
另一个角度来看，存在即合理，你可以多问问团队里的同事为什么要这么做。说不定是因为以前出过类似的问题，所以才特地这么设计的呢？

对，十年前用过的工具了，一下子想不起名字来

你说的这种方式，以前微软的 vs coding 工具就是这么做的，把元素的很多属性都录制下来，然后回放的时候会根据这一组属性去识别元素，稳定性比只靠单个属性去识别要高。

测试必上自动化，我觉得这不是风气，而是每一个项目的管理者都必须会考虑到的必做项。
质量保障体系里面，有很多不同的环节：需求评审，设计评审，开发单元测试，系统集成测试，系统回归测试，用户验收测试，等等。而自动化是系统集成/回归测试阶段很重要的一步。
不做自动化，只用手动测试能做完集成测试和回归测试吗？ 当然可以。但问题是，你怎么保障测试的效率？怎么保证在不断迭代的过程中，测试人员不会疲惫而导致漏测？

什么公司？

只能说楼主说的几点，都是自动化做不好的因素，和自动化本身没什么关系。 如果自动化做得好了，这几点都能在一定程度被解决。

1. 敏捷模式： 难道你们的敏捷模式只跑一个 sprint？ 在后续的 sprint 里面不需要对已经做好的 story 进行回归测试？ 没有足够的自动化测试，怎么应对越来越多的功能和越来越大的回归测试范围？
2. 因为产品变动引起的自动化测试维护问题。 首先确定一个点，你们的产品每一轮都会把所有的功能和页面都改掉吗？ 即使每一个 sprint 里面变动的功能有 20%，那维护的工作量也只是这 20% 的用例，而且如果 page object 的结构做得好的话，页面变动很多时候只是元素定位的变化，用例的本身不需要修改。
3. 精准测试： --1 首先你能保证每次提测的代码都可以识别到 100% 准确的影响范围？ --2 其次，如果识别出来的范围也很大，如果没有自动化测试，纯手工进行测试，工作量会小吗？
   --3 再举个例子，如果开发和你说 JDK 升级了一个版本，或者服务器的操作系统升级了一个版本，你能精确识别出哪些测试范围呢？ 如果用足够的自动化，可能只是跑一次 job 的时间就能做到足够的覆盖，用纯手工的话要点多久？

而你最后的结论，都是基于你自己列举的自动化各种缺点得出来的，足够客观吗？ 能不能把优点也列出来对比呢？ 只看缺点的话，最后只会是一个片面的主观结论。

最后说一点吧，自动化测试都已经被提了几十年，从早期的商业化工具如 QTP，到已经迭代到 4.0 版本的 selenium，再到 appium，ATX， airtest ，cypress 等自动化框架，已经是百花齐放的局面了。如果只是盯着它的缺点或者不足，可能就会一直错过时代的发展。

CA_MD_TOO_WEAK] ca md too weak

我来试着翻译一下这个错误信息：
擦，md ,太弱了

环境不同，理解不一样。
连我自己到了新团队之后看着那惨不忍睹的自动化通过率，也一度怀疑自己以前做的是假自动化

小团队，就是自己管自己

pytest+ selenium 做 UI 自动化，pytest+request 做接口自动化。都是网上很多介绍的框架，不需要花很多时间来搭建。

至于写用例和维护，看你们团队和产品是否合适了，我们当时可能 20% 到 30% 的时间在自动化上。

感觉老哥你对这个团队有点执念啊

如果是我的话，努力也改变不了团队，可能是这个团队不适合你，换一个更好的呗

我觉得你这个也是特例吧，我也在小团队呆了三年多，然而并没有这种复杂的办公室政治关系。

谢谢邀请。不过那是我两年前的团队了，估计现在讲也不合适。

干货满满，谢谢大佬！

同意。 一个处于发展期的团队，特别是早期，其实有非常多环节是会被选择性忽略的，有些团队甚至前期都不会有测试，而是开发自测；但是一旦测试团队接人了，就有责任把这些缺少的环节一一补上：把没有的流程梳理起来，把简单粗暴的开发行为引导，约束起来。