UI自动化测试误区

UI自动化测试误区

误区一: UI自动化实现很简单

误区二: UI自动化没用

造成这个误区的原因也很简单。技术和业务拆解能力不足就直接去搞自动化了。所以自然就没什么好效果。而且忙于在维护脚本中奔波。然后总结出了一个结论--UI自动化没有什么卵用。

正确的打开方式

1、首先，代码能力要好，代码能力要好，代码能力要好。重要的事情说三遍。好的UI自动化项目依赖于好的设计。好的代码能力不是说你会使用各种牛逼的技术，框架。而是你能设计好一个项目，该封装变化的封装变化，该抽象分层的分层，设计模式该用就用。把脚本层，数据层，基础框架层，业务层，page层等等剥离清楚。 按业务需求把各模块分割明白。 这时候要明白，我是写代码的。以一个开发的标准要求自己。

2、挑选最合适的开源框架。别装逼自己写，自己写的肯定没人家开源的做得好。除非你是大神否则别自己写。但也别一刀不动，要根据自己的需求对开源框架做二次开发。 推荐一个java系的工具链。UI工具用selenide，注意不是selenium。report框架allure，断言框架assert-core和assert-db。基础测试框架testng或junit。 UI相关的差不多就这些。别再用老旧过时的工具了，还在用原生webdriver是很痛苦的。连自旋等待机制都没有。

3、别迷恋关键字驱动，录制回放和各式测试平台。这些东西的发展就目前来说虽然逼格满满，但还无法做好自动化，它们善于降低学习成本，让没有技术能力的人能迅速做到60分，而我们这里说的是要做到90分以上。并且脚本数量一上来就是维护噩梦。公司体量没到一定程度的时候也别去自研测试平台，测试平台也不是保姆式的无脑降低学习成本，主要目的还在于标准化，自动化。

4、要与业务绑定，让技术人员只写脚本不管业务测试是大忌。先不说别的，架构都是根据业务拆分设计的，你看哪个架构师设计的时候不看业务需求直接动手的?退一步讲业务不熟练你用例都写不好。

5、标准化，我们并不是在一个人在战斗。最好要有统一的技术栈，运行环境，代码风格等等。标准化真的是好处多多。

6、理性看待UI自动化，合理运用UI自动化。它不是神，有很多东西不适合做UI自动化的别硬去做。也别因为有些东西UI自动化做的不好就否定它。

每个项目面对的情况不一样，我就不说太多了。介绍下我厂现在的情况。 6个浏览器并发一个小时基本跑完所有UI自动化。之前3个QA3天跑完所有case，现在是7个小时。现在的痛点仍然是运行速度问题。 希望今年能申请到更多的资源。