自动化测试是一个老生常谈的话题,往往应为界面变化太快,测试脚本更新跟不上需求变化而作罢。所以打算引入能自动生成测试脚本的 uirecorder 这一开源工具。并且配合使用 Docker 来加快测试环境的部署。
自动化测试的重要性大家都有共识,在 web 前端领域大家做的比较完善的基本上还是在基础类库和公共方法上的单元测试。因为这一块代码比较稳定,单元测试的工具也比较完善。但是前端的大部分工作是在和界面打交道,把打比喻成一种特殊的 GUI 软件也会会更形象一点。所以模拟用户操作的自动化测试能更多的覆盖我们的业务逻辑。
那为什么目前的自动化测试普及率还是不高呢?这里引入业界的一个公式:
自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
往往就是因为写测试用例的耗时(首次自动化成本)加上需求变化(维护次数)大,导致自动化的收益回报低。所以业界一直在探索一些工具来降低这些成本。
经过一些调研,觉得 uirecorder这套开源工具方便易用,能通过让使用者自己跑一遍测试流程而自动生成对应的测试脚本,简化编写脚本的过程。于是决定尝试尝试。
使用 uirecorder 需要 Node、Java 的环境。在环境准备好后通过
npm install uirecorder -g
命令安装,然后新建一个文件夹在其中使用
npm init
初始化配置后就可以开始录制脚本了。
具体使用可以参考它的文档和这个 视频介绍,这里就不赘述了。
录制脚本生成之后可以手动跑一跑刚才的 case
1. 启动 WebDriver 服务:
npm run installdriver
npm run server
2. 在新窗口运行单个脚本:
source run.sh sample/test.spec.js
然后我们就可以看到测试运行的整个流程。
通过使用录制的方式生成脚本,能大大加快我们开发测试用例的的速度,一旦需求界面发生变化,我们可以迅速同步测试用例。
解决了脚本生成的问题,我们还想让整个测试的体系更加高效敏捷。我们知道前端的另一大苦逼之处就是要做浏览器兼容,各大浏览器都通过了才算大功告成。所以自动化测试也需要在各个浏览器下运行。
因为自动化测试时独占的,所以往往需要一个浏览器部署在一个测试机上来并行测试。而这样导致太多的资源的消耗,也成为自动化测试普及的一个瓶颈。
庆幸这是一个好的时代!我们有了 Docker 这一神器。Docker 有秒级启动、应用隔离、良好的可移植性的优点,完全使用沙箱机制,相互之间没有任何接口。而且性能开销小,可以很容易地在机器和数据中心中运行。最重要的是, 他们不依赖于任何语言、框架或系统。
很自然的,我们想尝试尝试这两者结合起来的力量。
生在开源时代的 Docker 也自带开源属性,在 Docker Hub上我们能找到非常多的镜像地址,不需要我们一步一步的从零开始构建我们自己的镜像。
回到我们的主题,我们需要的是利用 Docker 来构建我们的测试环境,这样可以很方便快速的部署到测试机上,并且后期扩展也非常容易。
要跑我们的测试用例需要 selenium 和浏览器的环境,docker hub 上有专门的一个镜像系列:https://hub.docker.com/r/selenium/
这里面包含了基础环境的镜像,包含各种浏览器 Selenium standalone 的镜像。我们先使用 hub 和 node-chrome 来试试水
首先我们把这两个镜像拉去到本地:
docker pull selenium/hub
docker pull selenium/node-chrome
然后先后把两个镜像跑起来:
docker run -d --name hub -p 4444:4444 selenium/hub
这个命令解释一下几个参数:
docker run
后面追加 -d=true
或者 -d
,那么容器将会运行在后台模式。docker run
时没有指定 \--name
,那么 deamon 会自动生成一个随机字符串 UUID 作为标识符。所以有个 name 会非常方便,这里我们指定 name 为 hub。docker run -d -P -p 5901:5900 -p 15000:5555 --link hub:hub selenium/node-chrome
\--link name:alias 在消费和服务容器之间创建链接
然后在跑 uirecorder 的项目中的 config.json 文件中,修改 webdriver 的 port 参数:
"webdriver": {
"host": "127.0.0.1",
"port": "15000",
"browsers": "chrome"
},
这里的 port 15000 就是在上面的 docker 启动命令中指定的。接着使用之前 run testcase 的命令(source run.sh)启动就可以看到 case 跑起来了,而且本地浏览器并没有启动。因为这是的浏览器是启动在 docker 容器中了。
之前的尝试中,最后一个测试环境也就是 uirecorder 的测试环境并没有在 docker 容器中,其实我们也可以吧组后的环境也 build 成一个 docker 容器,这样部署起来才更畅快。接下来会继续尝试这一步的改进,并真正部署到测试环境中,并结合定时脚本,邮件报警机制完善我们的流程。
且看下回分解。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。