在快速迭代的产品或者说团队中，UI自动化通常是一件看似美好，实际鸡肋（甚至绝大部分连鸡肋都算不上）的工具。
原因不外乎以下几点：
一、效果有限
通常只是听说过就想去搞UI自动化的团队，心里都认为【UI自动化】等于【减少人工提高效率】，这固然没什么大错，但是通常他们也都会认为减少的人工成本和提高的效率会非常高，所以会对UI自动化寄予非常高的期望，这就很有问题了。毕竟现实是很残酷的，UI自动化真实的效果并没有那么好。
这个效果没那么好通常体现在两个方面：
1、本身就无法完全满足复杂的业务代码框架。除开常见的ID，Name这些常用元素不足外，还有些本身框架就比较复杂，需要对开发有非常高的要求才能比较好的添加需要的信息，比如说VUE，非常好用的框架，封装的非常好的同时也意味着，改造VUE非常困难。更何况还有些前端代码直接是动态生成的，这就让本就难过的自动化更加雪上加霜。
2、有些同学会说，不适用还要强行用，用了不好用还要怪工具，真有你的。确实，第一点是因为被测系统框架本身和Selenium不兼容导致的，但是第二点就是目前自动化都无法逾越的问题。一般情况下，UI自动化仅能就已知的问题做兜底，基本无法检查出新的BUG。这个特性是天生的，平常我们自己做测试的时候也知道，很多BUG其实是在测试用例之外发现的，而UI自动化毕竟是一段编码，它无法对超出预设的BUG进行报告，仅能对已知的问题做兜底。
其实兜底能做的好，就已经是非常好了，依然可以为公司和团队提供非常好的帮助，但是除开上述框架层面的原因外，公司层面的原因也非常关键。
二、重视度不够
在众多设置了UI自动化岗位的公司，通常情况下，只有一到两位，仅有一半不到的时间在写自动化脚本的同学，而这些同学被寄予了厚望，希望可以做出一个覆盖面积广、测试通过率高、持续集成稳定、领导拿出去装逼倍有面的UI自动化系统。
想想都气抖冷，但是这就是比较真实的现状，又想马儿跑，又想马儿不吃草。
而除此之外，大部分招聘UI自动化的公司给出的薪资也较低，普遍在8-20之间（15以上一般都在大厂了）。我们换位思考一下，如果一个公司的主程月薪20K，你觉得这个公司的研发水平是怎么样的？答案不言自喻。有很多同学不服了，你UI自动化测试跑去跟正经开发比，真有你的。我还真就要说了，UI自动化想要落地，招人的标准就要冲着开发水平去招，不然就是劳民伤财，毫无意义。
当然，给出高工资并且全职做UI自动化的公司并不是没有，可是效果也一言难尽，因为这涉及到了执行层面的内容。
三、痛苦的维护
自动化要做好，难在维护，这个是很多人都知道的。维护的原因只有一种：需求变更。无论是页面修改、逻辑修改、底层代码变动导致的其实都可以归结于需求。
每次维护通常分为以下几步：
1、跑全部用例，拿到出错的用例。
2、分析出错用例，找出因为本次修改导致的用例。
3、修改用例后复跑，确认没有问题。
4、重复步骤3，直到所有出错用例都修改完。
5、再次跑全部用例，确认没有问题合并代码。如果有问题，重复步骤3和4。
上述步骤已经非常耗时了，通常一到两个人的自动化团队，即使是全职当用例累积到五六百时，大部分时间都会消耗在维护上，更何况很多都不是全职。
耗时耗力，如果改好后能保证效果的话，其实勉强也能接受。但是非常不幸，上述的维护动作，通常是在我们正式跑用例出报告时才会发现有问题，这也导致了我们发出去的报告中的通过率会忽高忽低，没有UI修改时风平浪静，一旦有修改一地鸡毛。
而通过率的不稳定会导致很可怕的事情：不受信任。
试想，你是测试leader或者开发又或者是业务测试同学，当一份自动化测试报告发过来的时候，点开一个错误用例发现是UI修改导致的，点开第二个还是，终于在一堆因为未维护导致的失败用例中找到一个其他原因导致的错误，找你一核对，发现是网络问题。看这份报告的人心态会是怎么样的？
多次这样之后，会关心这份报告的人，都不会记得你成功率是95%时的模样，只会记得成功率是80%时的模样，并给出结论：这东西没什么用。
事实上，这还是做的好的情况，毕竟通过率可以达到95%已经非常不错，而市面上绝大部分公司的UI自动化通过率从来没有达到过95%，甚至80%都达不到，试问这样的结果拿出去，给谁看呢？丢谁的人呢？
总结：维护耗心耗力，结果依旧不受信任。
以上三点，是我自己总结的UI自动化说了这么多年依旧鸡肋的原因。它目前是一个实际投入100分，产出只有90分，然后还要持续投入越来越高的成本才能继续维持90分产出的东西。但是却被不了解或者了解也装不了解的人看成是实际投入50分，产出可以到150分的一劳永逸的解决方案。以此吸引了一大波人进入这个领域，看了一段伪代码就说自己会了，完整的写了一个用例就说自己精通了，在某个公司做着半吊子的项目就说自己是专家了。
那么问题来了，它似乎没那么美，我们要不要做呢？做成的困难那么多，我们要不要做呢？后续投入好像是个无底洞，我们要不要做呢？
