我这有个更方便的https://gitee.com/wangyix/maven-jmeter
目前还跟 allure 结合了

文件名这块 少用空格 少用中文

参考一下这个https://www.jianshu.com/p/5658d7c97ca1

不好意思，没描述清楚，授权是需要付费的。

刚刚看了下主页，这个异常没了

真的不是我的

往后会逐渐分享到社区，用简书起初是因为排版和交互适合我养成自己的写作习惯，现在发现做技术的人用简书用的太少，往后逐渐往社区分享。
图片打不开的情况已修复， 是图片的链接从简书复制过来之后被添加了一些内容，简书这个做法有点不地道。

来了，回答在楼上

小团队的测试哎，提 BUG 的时候，没有底气，Python 可以完善自己工程化思想，但是对于日常测试中定位 BUG 的时候帮助其实并不大。
日常有提 BUG 之后追问研发产生原因是什么，研发也很友好的告诉我为什么会产生，但是只是 Python 的情况下，其实并不能很好的理解为什么会产生某个 BUG，所以就转了 Java，帮助自己在工作中更好的定位 BUG，然后告诉研发哪里错了，直接去改就好了。
还有像新业务中研发框架选型，代码评审，听的一知半解，但是有 Java 底子之后，可以更前置的从测试角度提出是否符合业务问题。

受教了

我也是直接申请的，不太清楚审核逻辑；测试沙龙也是在社区里看到的 ，经常来社区逛逛吧

JMeter 的缺陷问题，有舍有得，根据实际情况衡量吧

1. 保存脚本的逻辑零散；借鉴包命名的思路，针对于自己的用例结构进行拆分。 2.编写用例的时候繁琐 要配置一大堆东西，没有约定即默认配置的思想;使用前培训，进行约定，规则说明 3.可视化低；这个没有好的解决方案，maven 集中管理和命名空间来解决吧

遇到问题，解决问题。我认为我的自动化方向错误是因为这个
平台是好，但是对于团队来说，整体的综合能力更重要！！！
据我了解，大厂的外包同学对于自己使用的平台没有多少参与度，工具是会用的，但是综合能力呢？代码编写，BUG 定位这些呢？
我没有参与过大型的测试团队，所以，我的理解可能有点偏差

认同，中小公司更注重效率，团队能力上

平台呢？好是当然好，但是我觉得平台的方案会弱化使用者的代码能力，使用者傻瓜式的操作就行了，对于整个测试团队来说，不是一个好的方案。
更倾向于团队里自己用代码写 case（在线编译的方案可以有），加深对于代码，数据结构的理解，在测试工作中定位缺陷的时候也更容易一点。
也可以摆脱测试地位低的帽子（自认为测试地位低是因为在一个技术团队里，测试是偏技术薄弱的一方，如果技术好，还地位低？）

详细描述一下？

和我想做的几乎差不多，我还加了线上日志监控的功能。。。这个交互，参考了

19 号的已经安排上了

杭州的是不是还在排队

已买票

建议先面试看看市场的选择吧 脱坑太久，再想回来的话，有点难的

确定是点击到了

不好意思 给大佬填麻烦了
在上面的场景下，右上角的个人下拉框 我认为是层级最高的功能，，，但是上面的情况存在下拉框展不开的情况