小康叔叔-

首先来说，前端自动化测试在实际应用中还是较少的！为什么这样讲呢？我们得先了解自动化测试是为了解决什么问题的，以及自动化测试的局限性。

自动化测试的目的很简单，就是解放人力，将一些重复性核验工作交给程序自动去检测。但问题来了，对于一般后端功能来说，自动化测试是比较容易实施的。但对于前端来说，自动化的应用场景还是较少的。

我们知道，如果是测试人员对前端页面进行测试，主要测试点有：

• 界面排版布局是否和效果图一致；
  

• 在不同浏览器下的兼容性；

• 交互效果是否达到预期；

• 页面性能分析等。

从上面来看，界面布局和兼容性人工测试都比较难，自动化实施起来复杂度也很高。从另外一方面来看，前端页面改动的可能性较大，所以UED方面的确不适合实施自动化测试，成本太高！

那是不是说前端领域就真的没法实施自动化测试了呢？其实也不是，比如我们将一些偏底层性的核验交给程序来自动化测试。比如用程序来实现：

• 监测前端页面是否存在死链；
  

• 监测前端页面图片尺寸是否过大，需要裁剪；

• 监测前端页面是否抛出了JS错误等 ...

前端自动化需要了解 Selenium ，同时你需要掌握一种编程语言，如Java、Python等。利用Selenium可以实现以下功能：

• 操作浏览器，它可以按照脚本代码对页面做输入、点击、验证提交等操作，和真实用户操作流程一样；
  

• 可以对页面DOM进行操作；

• 可以执行JS；

如果有兴趣，可以去GitHub上搜索一下：checkConsoleError 、check404 ，这两个小工具是我用Selenium写的前端自动化测试小工具。

当然了，一般前端人员还是很难驾驭Selenium的，因为要一定的编程能力才能写出测试脚本。对于一般前端人员我们建议使用类似的IETester来测试页面兼容性即可。

以上就是我的看法，如果大家有其它看法，欢迎在下方评论区留言交流哈 ~

网络圈

一般前端自动化测试大致包括类库单元测试自动化UI组件测试自动化类库单元测试自动化较好实现基本思路是让不同的浏览器可以自动根据指令跑一些JS函数结果与预期比对后返回是否通过case测试标志其中一般有两种实现方式：其一：1.打开目标浏览器，运行测试框架站点2.测试框架站点通过ajax 轮询、websocket 等方式，将待测 js 的 case 在浏览器内运行（通过eval 、createElement("script") 等方式）3.比对测试结果，将结果 post 到远端4.远端接受测试结果5.远端等待所有浏览器返回结果完成6.marge 所有浏览器数据显示最终通过与否结果。这种方式弊端：人工开启一次所有浏览器需要排队测试，浏览器只能一次运行完一组测试后才能再运行下一组如果中间某testcase导致浏览器异常，返回结果将缺失，需要人工去服务器上检查下浏览器状态好处：可以覆盖所有想覆盖到的浏览器另一种方式：1.将常用浏览器内核放进一个或多个相互有关联的进程内2.用例通过系统消息发送到各个包装的内核中3.每次开启一个新内核进程运行JS用例4.用例结果发送给包装进程5.包装进程汇集所有用例结果后post到远端保存6.包装进程连带内核进程一起退出优点：无序人工开启一次浏览器独立进程运行，无需排队不怕内核异常，异常后包装进程可以直接恢复内核或者通知测试失败缺点：前端实现太困难，需要C++开发

web小学员

在回答这个问题前，先大概介绍以下内容，以便理解。若认为赘余，可直接阅读最后一章节。

结合测试分层自动化测试思想

Unit-单元测试

一般由开发人员开展测试，写单元测试用例也是开发人员对自己的代码进行检查的一个过程。

Service-服务接口自动化测试

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

UI-页面自动化测试

UI层是与用户进行交互的，测试工作大多集中在这一层。根据个人实践经验，大部分场景下不推荐UI自动化，难以做到高效的维护，关于UI自动化的两点建议:

• 能在底层做自动化覆盖，就尽量不在UI层做自动化覆盖
  
• 只做最核心的功能的自动化覆盖，脚本可维护性尽可能提高
  
  

自动化测试开展的必要条件

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

• 软件需求变动不频繁(超过10%的变动是频繁变动，同时10%并不是一个固定值，根据其维护、扩展成本适当调整阈值)
• 项目周期足够长
• 自动化测试用例可重复使用

同时，自动化测试的是否易于扩展、易于维护对其可持续性而言非常重要。

自动化测试的局限性

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

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

自动化测试的目的

自动化测试的直接目的是围绕产品质量提高测试效率，其根本目的（效率转化）无外乎以下几点：

• 真正的实现项目人力投入的缩减
  

• 做更多更有意义的测试，比如更深入的需求分析、测试设计或者对测试左移、右移的投入；
  

• 适应开发模式的转变，比如类敏捷、devops、testops模式下的频繁迭代、持续部署、质量运营等。

如何进行前端自动化测试

前面铺垫了很多，终于可以回答这个问题了。。。感谢读者能够耐心读到此处。。

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

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

最后，充分考虑易维护性、易扩展性的自动化测试策略设计，是可以实现自动化测试前移的，并非只能用于系统稳定或者回归测试的场景中。

软件测试开发技术栈

1、需要确认使用的技术栈，java、python还是javascript；

2、前端一些框架：appium、webdriver都比较成熟了；

3、如果组内整体开发技能不高，则需要写一套框架了，其他人使用关键词驱动去执行。

测试领域专家

根据我自己的工作经验，自动化测试一般用于回归测试和兼容性测试。现在移动端测试，要涵盖的机型很多，苹果还好，安卓的机子简直数不过来，手工去兼容的话，一个人最多看3-4个，再多就顾不过来了，耽误进度了。写一个自动化脚本，可以运行在所有你要兼容的机型上面，就会节省很多人力和时间。东软的一款产品我们使用过叫UTF在自动化测试这做的很好。欢迎了解东软平台产品https://platform.neusoft.com/

關鍵字: 科技 测试 互联网