软件测试41-从小工到专家：聊聊测试执行环境的架构设计（下）

在上一篇文章中，我介绍了测试基础架构的概念，以及早期的和经典的两种测试基础架构。在文章的最后，我提到经典的测试基础架构中采用的 Selenium Grid 方案，在测试用例的数量持续增加的情况下，会带来集群扩容、Jenkins Job 臃肿不堪等诸多问题，因此我们考虑将 Selenium Grid 迁移到 Docker，并且提供便于 Jenkins Job 管理的统一测试执行平台。

所以，今天的这篇文章，我就会围绕这些瓶颈以及对应的解决方案来展开。

基于 Docker 实现的 Selenium Grid 测试基础架构

随着测试基础架构的广泛使用，以及大量的浏览器兼容性测试的需求，Selenium Grid 中 Node 的数量会变得越来越大，也就是说我们需要维护的 Selenium Node 会越来越多。

在 Node 数量只有几十台的时候，通过人工的方式去升级 WebDriver、更新杀毒软件、升级浏览器版本，可能还不是什么大问题。但是，当需要维护的 Node 数量达到几百台甚至几千台的时候，这些 Node 的维护工作量就会直线上升。虽然，你可以通过传统的运维脚本管理这些 Node，但维护的成本依然居高不下。

同时，随着测试用例数量的持续增长，Selenium Node 的数量也必然会不断增长，这时安装部署新 Node 的工作量也会难以想象。因为，每台 Node 无论是采用实体机还是虚拟机，都会牵涉到安装操作系统、浏览器、Java 环境，以及 Selenium。

而目前流行的 Docker 容器技术，由于具有更快速的交付和部署能力、更高效的资源利用，以及更简单的更新维护能力，也就使得 Docker 相比于传统虚拟机而言，更加得“轻量级”。

因此，为了降低 Selenium Node 的维护成本，我们自然而然地想到了目前主流的容器技术，也就是使用 Docker 代替原本的虚拟机方案。

基于 Docker 的 Selenium Grid，可以从三个方面降低我们维护成本：

1. 由于 Docker 的更新维护更简单，使得我们只要维护不同浏览器的不同镜像文件即可，而无需为每台机器安装或者升级各种软件；

2. Docker 轻量级的特点，使得 Node 的启动和挂载所需时间大幅减少，直接由原来的分钟级降到了秒级；

3. Docker 高效的资源利用，使得同样的硬件资源可以支持更多的 Node。也就是说，我们可以在不额外投入硬件资源的情况下，扩大 Selenium Grid 的并发执行能力。

因此，现在很多大型互联网企业的测试执行环境都在向 Docker 过渡。

而具体如何基于 Docker 搭建一套 Selenium Gr