其实很正常 无论你怎么操作 不同环境你还是得测一遍 测试环境你得全过 预发布发布你可以粗略 但是都是一样的道理，始终是要花时间切不同环境测试的

测试人员少 小公司 敏捷开发的 还是不建议写 效率太慢

你是真牛逼

用个测试平台先把流程走通吧。你要自己搭建的话学的东西和维护成本太高，一般做的好的都是底层框架做好了用 UI 维护，你们才开始这样干除非是有大神。

你看看你 Jmeter 上报的是什么错呢 可能是本地网络已经拥塞之类的

第二个吧 不过真贵

性能测试的时候本就不应该还去做这些操作

解决了 我本地搞了个 nginx 反向代理了被测网站的域名跳转到了 yapi 上 就不存在跨域了

没懂 现在他这个分支是去掉了跨域插件，但是我用 127.0.0.1 去做接口测试就一直存在跨域问题，而且我的 yapi server 是没和服务器通信。又觉得他这的功能挺好用的 怎么破

你现在怎么解决的呢 跨域插件去掉了我这一直是请求不到的

是滴 低压力也有 服务器肯定做的有限制，但是这个长连接和短连接应该肯定有影响的

但是好像又有说 不勾选的话会占用太多端口，耗服务器资源

请问作者没有在更新了吗 以及跨域插件在哪加上呢

你自己觉得呢

哈哈哈哈 你这回答真顶

抓包不行 属于 SDK 底层

前面波动的报错具体是什么？还有你的脚本能保证一直稳定的每 5 秒并发一万个请求嘛？先找找自身脚本有没问题，再看报错原因。后续稳定后是都一直请求成功么。还有压力测试时要注意热机，模拟真实场景，不能拿到脚本就开跑。你压测时开始是有请求拥塞的，所以服务器的压力比较大会有波动去处理这些请求，当 TPS 稳定后就会像你后面的一样了，所以这样设计脚本就很有可能出现这种情况。你也可以设定稳定的 QPS 去压测

这个就要看需求了。服务端逻辑和前端逻辑是应该保持一致的，这种也是安全问题，可以篡改

还是得看具体业务

?

xmind 吧 特别是项目灵活的，且测试人员不是很够的情况，写用例耗时间而且不灵活，人少考虑的不完善。xmind 就可以一目了然，而且可以各种覆盖。。测试人员少项目迭代快需求不清晰的去写用例就存粹是耍流氓，你会发现很多时候用例满足不了以及不灵活

用例上添加了这个监听类是可以生效的，xml 运行可以。但是用 ant 构建就不行

嗯 我再多看看

这是路径 是 c 盘根目录下的一个报告。直接用 ant 跑没问题，用 jenkins 输出两份报告的时候就会报错

毕竟是 UI 自动化 要和接口连起来太多判断了不建议，最好把日志打印出来每一步干什么，然后分析有问题的时候是哪一步出现可问题再结合报告的报错原因。可以把日志也生成一个报告