浅谈前端（UI）自动化测试

作为一名测试开发从业者，自动化测试好像是绕不开的话题…。结合最近接触到的一些测开应聘同学聊到关于前端自动化测试及自己的理解，分享一下自己对UI自动化测试的认识，大概如下。

测试分层的自动化测试思想

自动化测试分层思想所倡导的是对系统进行分层，针对不同层次选择合适的自动化类型进行测试的一种测试策略，同时自动化测试分层思想也与测试阶段（单元测试、集成测试、系统测试）具备相关性。项目的自动化测试覆盖程度取决于各分层自动化测试分层策略设计的合理性、全面性。
Unit-单元测试

一般由开发人员开展测试，也就是我们日常所说的开发人员对自己开发代码的自测过程。

Service-服务集成的接口自动化测试

通常指的是API接口自动化测试，在分层自动化测试的应用中，接口自动化是最常见的自动化解决方案。

同时，结合数据驱动测试框架、关键字驱动测试框架可以满足大部分测试场景，包含含有复杂业务逻辑的功能的覆盖（B接口依赖A接口返回），同时降低测试代码的冗余。特别是在前后端分离的产品架构设计中，可以对功能点进行有效的覆盖，至于页面显示、页面元素布局、展示的验证可以通过手工测试或者其他工具覆盖。

UI-页面自动化测试

UI层是与用户进行交互的，用户通过与UI层交互使用系统功能。测试人员的大部分测试工作（黑盒测试）也集中在这一层。根据个人实践经验，大部分场景下都不推荐UI自动化，难以做到高效的维护，投入产出比不可控。关于UI自动化的三点建议如下：

优先考虑底层自动化覆盖，尽量不进行UI自动化覆盖。
优先考虑核心功能的自动化覆盖，降低非核心功能的自动化覆盖。
着重考虑自动化的可扩展性、易维护性设计。
自动化测试开展的必要条件

首先，是否开展自动化，通常需要同时满足以下条件：

软件需求变动不频繁(超过10%的变动是频繁变动，同时10%并不是一个固定值，根据其维护、扩展成本适当调整阈值)
项目周期足够长
自动化测试用例可重复使用
同时，自动化测试的是否易于扩展、易于维护对其可持续性而言非常重要。
自动化测试的局限性

一方面，自动化测试的局限性体现在上述其开展的必要条件，如果在不满足其必要条件的背景下，开展自动化会发现自动化并不会提高测试效率，甚至可能加大了测试成本。

另一方面，UI自动化与接口自动化本身的局限性，UI自动化较接口自动化而言其具备覆盖率高的优势（接口测试无法覆盖页面元素、格式、数据），接口自动化较UI自动化而言具备高扩展、易维护、问题修复成本低的优势。
前端自动化测试

我们知道UI自动化其开展的前提更强调系统的稳定性，不稳定的系统会导致频繁的自动化用例维护，这种维护成本是巨大的，甚至会出现原本两个人测试的项目，引入UI自动化现在需要三个人测试的情况。那么系统稳定性高，改动的可能性较小的情况下如何进行UI自动化？——建议参考Robot Framework + Selenium2Library，同时自动化测试设计时考虑数据与代码分离，以便减低维护成本，提高其可扩展性。

如果系统的稳定性一般，存在需求改动、页面优化的可能性，如何开展高覆盖的自动化测试？——建议参考Robot Framework + RequestsLibrary +Python requests(自定义关键字库开发)实现接口自动化，也需要考虑数据与代码分离的设计策略，同时RobotFramework支持数据驱动，用例编写效率会得到很大的提升。基于此再使用UI Recorder(阿里开源的一款零成本UI自动化录制工具)进行整体页面的自动化测试。
最后，充分考虑易维护性、易扩展性的自动化测试策略设计，是可以实现自动化测试前移的，并非只能用于系统稳定或者回归测试的场景中。