相比之下，LICEcap 可能更牛逼一些~

我自己的应用遇到过这个问题，是因为同时存在多个 Markdown 编辑器绑定了拖拽和 paste 事件监听
社区这个呢，估计是用户窗口多开导致的，绑定的监听事件重复，解决方法参见：

watch: {
  currentActive: function() {
    if (this.currentActive) {
      this.mdeIMGHandler('simpleMdeDesc');
    } else { // 移除非当前markdown编辑器中的监听
      if (this.$refs["simpleMdeDesc"]) {
        [this.$refs["simpleMdeDesc"]].map(({ simplemde }) => {
          if (simplemde.codemirror) {
            simplemde.codemirror.on("drop", false);
            simplemde.codemirror.on("paste", false);
          }
        });
      }
    }
  }
}

methods: {
  mdeIMGHandler(objectRef) {
    this.$nextTick(() => {
      [this.$refs[objectRef]].map(({ simplemde }) => {
        simplemde.codemirror.on("drop", (editor, e) =>{
          this.multiDragUpload(editor, e, simplemde);
        });
        simplemde.codemirror.on("paste", (editor, e) =>{
          this.singleCopyUpload(editor, e, simplemde);
        });
      });
    });
  }
}

港真，我都不知道发生了什么，为什么大家都不待见 autoit 这种神器呢

提交 PR 不就结了

你大可不必为此争辩，不同水平的人看到的东西本身就不一样，做好你自己所在阶段的事情就足够了
你所总结的东西对于初级、专家级来说都很重要和实际，对于专注产品测试本身也很重要和实际，对于其他人来说空泛就空泛了，没必要一定要得到别人 100% 的认同~

我不用 python 的，所以具体实现我做不了，只提供思路，你要确保 js 得到了执行：
http://www.w3school.com.cn/jsref/met_win_scrollto.asp

应该是缓存导致的 css 污染吧

亲心，拿走不泄

js 有 window.scrollto 方法
webdriver 可以执行 js，所以你可以写一个函数，每 100ms 向下拖 10 个像素（根据渲染速度可以适当调整），循环（记得超时时间配置），直到滚动到找到对象为止

顶蒋老师

总结的非常好，虽然不同产品可能会有不同策略，但是一看就知道楼主是个踏实做事、认真思考、善于总结的人~

实现上是没啥不可行的，但是你要考虑，会不会因为你的测试代码侵入导致被测应用的正确性问题

用 vue 测试 vue 页面势必会有侵入，如果侵入肯定是不行的，除非你是工具性、框架性的小产品的测试
楼主可以看下 puppeteer，也是纯 js 的

选择了 python，建议还是做自动化前端、接口测试吧，不要总想着测试开发，写测试脚本严格意义上不算正经的开发

继续招

不要提测试的思维这几个字，不然一会又有口水战……
东西很多，建议看大佬的文章：https://testerhome.com/topics/16354
核心就是：产品、价值、效率、技巧、技术、协作、管理，等等等等，而且不要以为一定要去做技术专家才需要学技术，不要以为准备去做团队管理或者项目管理才去学习管理……有意识地累积职业技能的广度和专业技能的深度，端正态度，留好后路，别把发财致富押宝到测试这个工作上来，哈哈哈~

点点点做得好的人大有人在，薪水一样干翻 8 成的半吊子自动化啊……核心不在于会不会 coding 好吗
只要能力能够持续提升，没什么不可以长期做的，关键是点点点把自己点傻了，思考都不会了，那就得换点花样来逼着自己思考了，不过以我的经验，点点点把自己干傻了的，去写代码也会把自己写傻掉的

puppeteer 和 istanbul 是前端自动化测试的好帮手啊

原来是分享，我以为是遇到麻烦了，多谢分享。
能改进就好，团队建设急不得，十年树木，团队文化建设至少要 2、3 年（我觉得）才能做到即使原来的主管走了还能把风气延续下去，加油！

弄不懂规矩就是弄不懂啊，估计真的是猎头呢

问题 3 成来自管理者太过温柔，不够狠，适当的档口就应该让 KPI 的大棒挥舞起来；
3 成来自管理者的惰性，有些问题显而易见却没有付诸解决实施，换句话说执行力出了点问题；
剩下的 4 成来自管理者的工作方法和能力，没能随着团队结构和时间成长起来~

总的来说，能让团队从创建步入稳定期，说明领导的能力和魅力还是很不错的，只不过那些诸如问题 4、12、13，是每个团队都要面临和解决的问题，如果没有好好解决，说明领导在技术格局和管理手段上的持续学习好像没跟上。
建议一大坨，但是细说太费劲，就说一条：
梳理团队的层次结构，让（逼着）你的 leader 们的技术和综合能力上去，适当授权，让他们担当起主干的作用，带动叶子的摇摆，如果他们不行就果断下手换掉，提拔或者社招都可以，20 人以上的团队，你想保持技术进步的同时还想亲自妥善管理好，绝对没有那么多精力，依赖分层管理是必须的，没有谁永远是 leader，稳定之后迟早要变成 manager 的，言尽于此，操作细节相信可以脑补出来。

1、看他出过的线上问题，判断水平首先看频次，其次做根因分析，看是低级错误还是复杂问题思虑不周；
2、看他平时的缺陷，是属于低级错误还是复杂问题思虑不周，观测度量其缺陷密度（单位时间），观察其是否具备 “不二错” 的基本素质；
3、看他与测试、产品的沟通，看是否有意回避自己的缺陷还是主动寻求质量，无论是否有 KPI 的驱动，态度对了水平很难不高；
4、看他的代码，看代码品味和实现的技巧；
5、通过与之闲聊或参与会议，看其对新老技术的掌握程度和工程实践能力；
6、看他有没有女朋友，有女朋友的一般水平都很渣
补充一条：
7、看他头发茂密不茂密，头发茂密的一般水平都很渣

是的，这是经典的框架定义注解