这个问题报过好久了

autotest_platform/app/core/process.py /
这个文件里面

用例管理那里有单条执行的入口

感谢分享！
正好最近也有做一部分这方面的使用，场景有两种：

1. 页面上的接口进行了升级处理，在打开的情况下会请求新接口，关闭的情况下请求旧接口。我就在用例里面通过这种方式来验证请求的接口是否正确。
2. 网页会在 localstorage 里面存储一些变量来控制某些页面属性，比如记住看过的广告轮播图的位置。也是在用例里面在对应步骤去获取对应的 localstorage 来验证。当然这个和 performance 没关系，通过 JS 就能取到。但是思路是一致的。

哈哈，没错，特别是三合一那种，很可能的不支持数据传输的

其实不用太在意是不是独立，有多少所谓话语权。

写个依赖文件一键安装就好了，比如：pip install -r requrements.txt

1. case 数量太多导致执行时间很长 -- 解决办法是并发执行。
2. case 不稳定因素 -- 稳定性和错误处理。

主要的功能用例，以及以前出过问题的用例。前者是保证产品的主要功能是可以的，后者是避免一些以前出过的问题再次出现（比如配置出了同样的遗漏）

上次也提过这个问题：

https://testerhome.com/topics/31049

按照你的公式：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 工具就是这么做的，把元素的很多属性都录制下来，然后回放的时候会根据这一组属性去识别元素，稳定性比只靠单个属性去识别要高。

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

什么公司？