为什么要做ui自动化？

你去到一家公司，你的组长给你安排的第一个任务就是说要做ui自动化，然后跟你说一下公司的app是怎么样的，让你看一下给出一个ui自动化的方案和一个完成时间，大概什么时候能把框架搭建好，什么时候能把功能用例转换成自动化用例；听了组长的任务，你可能会一脸懵逼，然后马上去baidu上找能够快速实现ui自动化的方案，可能你的运气比较好，在github上找到了一个别人开源的ui自动化框架，拿过来修修补补，几个星期后你跟你的领导说框架搭建完成了，用例也写了一部分，然后你的组长说要在业务组里推广ui自动化，让大家都来写自动化用例，但是这个自动化用例推广起来比想象的难，业务测试工程师根本不想写自动化用例，自己的业务测试任务就已经够多了，大家根本没有时间去学习这个，而且ui自动化有很多局限性，比如很多场景不能实现、需要一直去维护，到最后你写的这个ui自动化项目则会无疾而终。

这就是绝大多数公司为什么要做ui自动化的原因，没错就是因为领导的一句话，别人有ui自动化我们也要有，而上面这个就是我自己的真实经历，我称这种ui自动化为KPI的ui自动化。

为了避免上面的这种悲剧的再次发生，我们在做ui自动化之前就必须去思考一些事情，为什么要做ui自动化，ui自动化能给我们带来什么？你当前的项目适不适合做ui自动化？

最直观的来讲，就是因为ui自动化能去完成一部分功能测试，然后缩短项目的测试时间，缩短测试时间就等于节约了人力成本，如果ui自动化真正能够达到这种效果的话，那说明你们的ui自动化成功了。但是在真正去做ui自动化的时候你就会发现事情根本不是你想象的这么简单，随着ui自动化用例的执行，接下来就会发生一堆的问题，用例很多都实现不了(用例转换率低)，用例执行起来一堆的报错(用例成功率低)，还要花一堆的时间去看到底是用例写的有问题还是真正的bug，结果到头来ui自动化不仅没有带来正收益，还带来了一堆麻烦的问题，导致使用ui自动化的测试工程师失去信心，最后放弃ui自动化。

如何去做ui自动化？

ui自动化的难点