为什么UI自动化难做？—— 关于Selenium UI自动化的思考

在快速迭代的产品、团队中，UI自动化通常是一件看似美好，实际“鸡肋”（甚至绝大部分连鸡肋都算不上）的工具。原因不外乎以下几点：

1 效果有限

通常只是听说过，就想去搞UI自动化的团队，心里都认为「UI自动化」等于「减少人工 提高效率」，这固然没什么大错，但是他们也会认为减少的人工成本和提高的效率会非常高，所以会对UI自动化寄予非常高的期望，这就很有问题了。

毕竟现实是很残酷的，UI自动化真实的效果并没有那么好。 这个效果没那么好通常体现在两个方面：

A.本身无法完全满足复杂的业务代码框架

除了ID，Name这些常用元素不足，还有些本身框架就比较复杂，需要对开发有非常高的要求才能比较好地添加需要的信息，比如说VUE，非常好用的框架，封装得非常好的同时也意味着，改造VUE非常困难。

更何况还有些前端代码直接是动态生成的，这使本就难搞的自动化雪上加霜。

B.UI自动化仅能就已知的问题做兜底，基本无法检查出新的BUG

有些同学会说，不适用还要强行用，用了不好用还要怪工具，真有你的。确实，第一点是因为被测系统框架本身和Selenium不兼容导致的，但是第二点就是目前自动化都无法逾越的问题。

这个特性是天生的，平常我们自己做测试的时候也知道，很多BUG其实是在测试用例之外发现的，而UI自动化毕竟是一段编码，它无法对超出预设的BUG进行报告，仅能对已知的问题做兜底。

其实兜底能做的好，就已经是非常好了，依然可以为公司和团队提供非常好的帮助，但是除开上述框架层面的原因外，公司层面的原因也