真的不是我的

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

来了，回答在楼上

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

受教了

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

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

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

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

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

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

详细描述一下？

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

19 号的已经安排上了

杭州的是不是还在排队

已买票

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

确定是点击到了

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

想起来一个话题，工作需求和市场需求哪个重要？
工作需求的可能疲于奔命在日常工作中，深耕某一业务，但是偏离市场需求，跳槽的时候价值打折。
市场需求的可能在工作中用不到，对公司没有利益。
借老张的一句话就是：努力提升自己解决问题的能力。
现在来看这个话题，业务或者技术，都重要吧。
很多 bug 都是研发人员对业务逻辑理解不透彻，忽略掉的点，或者大家理解的都不一致，有歧义的点。
技术就不用说了，测试工程师，工程师，工程师，就是个技术岗，帮研发解决 bug 不好么？找研发提 bug 的也有底气，改不改，不改换我来？（可惜我技术菜）

自己写 bat 脚本 或者 sh 脚本 把之前的文件挪走

或者说是文件名根据时间戳来

PC 导入，移动端使用

如果提了离职，就下家吧。在团队里离职这回事，就像把团队的成员拉黑一样，你有这个想法，那无所谓，也就是想法，但是你一旦拉黑别人，想再加回来，成本会蛮高的。
如果没提离职，开发吧，转岗的好机会，很多人都遇不到这种机会的，就像我，降薪转岗都不给

菜鸡互啄 没错 就是咱俩