由于项目比较偏前端，我们的 UI 自动化采用了 cypress
在选型好了工具以后，所有的自动化也需要集成到 jenkins 流水线中集成，达到持续集成的目的

原始方案

一开始跑 UI 自动化所使用的 salve，我们选择主流方案，使用跟编译打包同样的 slave。

发现问题

• UI 自动化执行的时间比较长，最短也需要执行 3 分钟左右。在限制了 slave 管道的情况下 (考虑到资源消耗，我厂设置每台 slave 最多同时执行 5 个任务)，UI 自动化持续独占 slave，导致研发同学持续提交的过程经常被中断，拖累了生产效率。
• 在实际执行的过程中，因为经常会出现 “卡 case”(跑着跑着就不动了) 等问题。调查 log 后发现是跑 case 的时候自动断开浏览器 session，升级 cypress 版本也无法解决问题。猜测可能是操作系统版本和 xvfb 等插件版本对 chrome 兼容性的问题。

改进方案

占用生产的 slave 问题比较好解决，先尝试用 jenkins label 分割 slave 群，独占一个台 slave 执行 UI 自动化。
Cypress 卡 case 的问题，因为怀疑是环境问题，于是首选尝试使用官方提供的 docker 镜像来运行测试。同时将测试场景分成多个 spec，每个 spec 文件中只有一个 describe(调研发现卡 case 通常发生在初始化 describe，即 scenario 的时候)

又发现问题

• 使用官方提供的镜像后，发现卡 case 的问题虽然次数不那么频繁，但是依然存在。
• docker 中运行 chrome/electric 市场崩溃。尝试过增加初始内存，但也只是缓解崩溃次数。
• 中途考虑过换自动化方案，使用 webdriver+selenium grid 的上古方案。在 docker 环境下实际执行过程中还是回碰到 chrome 崩溃的问题。另外项目中途换工具的成本其实也不低。还有就是爽过 cypress 以后，实际上已经回不去 webdriver 了。。

终极方案

我厂大部分测试同学使用的是 windows 机器开发脚本。在碰到卡 case 啊，chrome 崩溃等问题的时候，windows 机器均无法复现跑得飞起。那是不是使用 windows 机器作为 slave 就可以解决上面碰到的所有问题了呢。

Windows slave 的必要性

• 借助浏览器的 headless 模式，目前在持续集成中我们比较主流的做法是在 linux slave 中直接跑 UI 自动化。 但是 Cypress 的本质上是浏览器插件，chrome 等浏览器目前支持的 headless 模式还无法提供对插件的支持。操作系统为 Linux 的 jenkins slave 中必须按照官方提示安装 xvfb 等插件来提供运行支持。 shell apt-get install xvfb libgtk2.0-0 libnotify-dev libgconf-2-4 libnss3 libxss1 libasound2
• 从用户使用习惯上考虑，市面上绝大部分的用户使用的是 windows。使用 windows 及真实浏览器执行出的结果是最可信的。

确定了必要性和可行性，就开始准备做 windows slave。
公司的 jenkins 等基础设施建在云主机上。需要增加 slave 的时候，必须要走财务流程申请新的云主机，流程冗长复杂，而且还不便宜。
然后我突然想到办公室里面有好几台空闲的的 PC 机器 (win10)，用作显示 CI monitor，略显浪费。那是不是可以把这几台 windows pc 做成 jenkins slave 集群，当土生云使用呢。

给 jenkins 增加 windows slave

通信问题

为了达到把本地机器装载到 jenkins slave 集群中的目的，host 和 slave 之间的通信问题得先解决。
找运维同学配合，绕过各种 IP、访问限制，确保两点即可

• host 和 slave 之间可以相互访问
• 开发机和 slave 之间可以相互访问

在 slave 上安装依赖环境

需要在 slave 上安装执行 jenkins 以及 UI 自动化的环境

• java8
• nodejs
• git 等等

在 slave 上安装 jenkins agent

按照这个教程，做到第四步。后面，我们采用直接在 slave 上用 bat 文件启动 agent.jar 的方案。

其中-Dfile.encoding=UTF8可以解决在 console 中的乱码问题
然后依次把其他 slave 机器设置好，执行 bat 文件后，java 进程以 cmd 窗口的形式存在在 slave 上。
成功后，jenkins 上查看结果。

做到这一步，只需要把 UI 测试配置上这个 slave 集群的 label，然后就可以正常在流水线中跑 UI 自动化了。

新的问题

按理来说现在自动化也可以独立跑了，cypress 也不挂了，完美了啊。
结果在实践中发现承载 jenkins 的命令行窗口，经常因为不同的原因挂掉

• 其他同学看到命令行习惯性的关掉
• win10 的自动更新机制（关了自动更新服务也不起作用) 会定时重启机器
• 在命令行窗口中点击了右键让命令行窗口处于挂起状态

所以又得想个办法把这些窗口隐藏起来。

使 bat 变成 windows 服务

两种方式可以达到目的

• 使用 nssm.exe 工具，借助工具的托管，可以轻松的让 bat 变成 windows services nssm.exe install [服务名] [bat文件路径]
• 根据教程第四步及以后的内容做成服务。(不推荐，使用此方法做成服务后，删除服务时候需要使用sc命令。比较麻烦)

做成 windows 服务以后，再也不同担心被误关窗口了。而且重启后也会自动启动。

问题又来了

jenkins agent 做成服务以后，跑 UI 自动化的时候，发现 cypress 的 viewport 设置失效，始终会以手机的 viewport 来执行测试。
经过调查和多次验证，发现问题还真出在 jenkins agent 被.net 框架包装成服务时。同样的 bat 文件，直接执行就不会有 viewport 的问题。

所以必须要放弃服务化，用另外一种方式使 agent 以命令行方式执行。

vbs

虽然start \min命令，可以使 bat 文件在一开始就以最小化的方式执行。这种方式下我们还是能在任务栏看到这个命令行窗口。

所以最终还是直接选择使用 vbs 来包装这个 bat 文件。

• 在 bat 文件同目录中创建记事本文件
• 键入下面脚本,其中 Run 命令后面跟的是用 cmd 来跑 jenkins agent 启动 bat 的意思。参数 0 表示启动后不在界面显示 (只能通过任务管理器查看进程)。完了以后把扩展名改成 vbs。

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("cmd.exe /c jenkins_slave_start.bat"), 0

• 右键创建这个脚本的快捷方式，在 windows->run 中输入 shell:startup 打开启动项，把快捷方式拖入到启动文件夹中。

双击启动这个进程后，windows slave 成功上线。服务器的界面上也看不到任何窗口了。而且服务器重启的时候，也会通过启动项把这个服务启动起来。

同样的方式，我们也用来启动了 selenium grid 等其他可以用 bat 启动的服务。

不完美的地方

至此，windows slave 算搭建完成了。vbs 隐藏界面的方式看上去很美好，但是也会有问题, 比如

• 操作反馈十分不友好，你甚至不知道自己有没有点击成功。需要去查看进程。
• 无法看到 log。如果服务出了问题没办法拿到日志。

所以后面还可以改进的地方还挺多。
顺带提一下因为重新引入 windows slave 的关系，最近又重新捡起了 vbs，开心 -v-