关于自动化难不难：
有些领导，尤其是啥也不懂然后又急于表现的领导，觉得自动化很高大上，动不动就想整一个自动化出来。
真心觉得写自动化cases很简单。尤其是借助工具的，甚至只需要record and play。不借助工具的也可以借助一些驱动来开发。
难的是搭建自动化测试框架，需要一个有经验，有想法的人才可以做的漂亮。不然后期写脚本会很费劲。
关于要不要自动化：
如果测试时间给的比较短，比如说一两个月，我觉得就不要自动化了。等你设计好test cases，然后再翻译成自动化之后，项目都结束了，还跑他干嘛。
如果项目变动比较大，比如对UI敏感的工具UI一直变动，也不要进行自动化。
如果是频繁的回归测试，可以自动化。变动不大，每一轮回归测试都可以跑一遍。
如果是长期项目，尤其是一种产品做很多年的，可以考虑自动化。
关于自动化工具：
真心觉得自动化工具是为人服务的。所以你就把他放在一个服务你的位置上，没必要去崇拜它。如果维护自动化工具的工作量甚至超过了编写自动化cases的工作量，那最好还是果断抛弃它。
关于自动化失败的总结：
我经历过2个失败的自动化项目。
第一个：领导比较白。项目刚出来没多久，界面以及链接一直变动。这个时候要么不自动化，只手动测试，要么就选用不依赖于界面链接的自动化测试工具。结果自动化是搭建好啦，每天新的image出来，手动测试人员很忙，因为有很多变动。自动化测试的人也很忙，因为有很多变动，然后要每天一个一个的更新自动化测试cases，关键这部分cases手动的每天还必须测。
第二个：项目很适合自动化，但是自动化工具没选好。公司自己制作了一个自动化工具，这个工具base在skuli工具上。skuli是采用图片设计cases。然后设计cases的时候就很头疼，图片精确度调高了会匹配不上，图片精确度调低了又会匹配到其他不相关的图片。导致cases运行极度不稳定。