这两天我一直在修复、并补齐之前的 UI 自动化测试——我知道你们大多数人都不会在项目上写测试的。然后，我发现一个浏览器跑完所有的 UI 自动化测试要花 8 分钟。

我就想着优化一下吧，多开几个浏览器试试。测试了一下不同浏览器数量下的测试时间，发现 8 是最合适的。

初始化测试的时候就是这样的效果，一瞬间启动 8 个浏览器，各自跑各自独立的测试。

那么问题来了，八个浏览器跑完这些测试要多久？？

八个浏览器要跑多久？

人月神话里说：一个人怀胎十月你可以找十个人来怀胎一月吗？

测试之间都是独立的，每个测试都会在运行之前，都会打开指定的 URL，并运行相应的单元测试。当一个测试运行完的时候，浏览器就会运行下一个测试。于是，我猜想时间应该大于一分钟。带着这个假想，我开始测试时间了。

先让我们说一些现象：

• 最开始的时候浏览器并不是同时打开的，而是一个个打开的。这就意味着，这个时间要大于一分钟的。
• 在最后的十几秒里，只有一个测试在运行。很明显这是一个文件里的测试。

顺便说一说，究竟在测些什么？以我博客首页为例，当我打开我的博客时，我要测试一个行为和状态：

• 状态，页面上存在着那行标语
• 行为，当我点击博客标签的时候，它应该跳转到我的列表页。因此，我需要断言当前的页面是博客列表页即可。

跑完的时候，接近了两分钟。我开始在想为什么会这么长：

有一种情况，可以让浏览器在接近一分钟内跑完：所有的测试的运行时间都相当的短，并且测试时间近似平均——但是我们知道这是不可能的。有的测试运行的时间相当的长，甚至它的运行时间决定了整个测试所需要花费的时间。

我们所要做的事情就是：测试好时间，再分配好这些测试就可以了。假设我们有两个浏览器线程四个测试，时间长度分别为 1 2 2 4， 那么最差的情况是：

A 1 2

B 2 4

一共花了6 分钟的时间长运行完，最好的情况就是 5 分钟了。正好下班回来的时候，我看到人们在排队。顺手搜索了一下，找到了排队论。

排队论

排队论(Queuing Theory) ，是研究系统随机聚散现象和随机服务系统工作过程的数学理论和方法，又称随机服务系统理论，为运筹学的一个分支。它的研究主要集中于这三个方面：

1. 统计推断，根据资料建立模型
2. 系统的性态，即和排队有关的数量指标的概率规律性
3. ​系统的优化问题

好吧，扯远了~~~

这个问题倒是挺有意思的，但是优化测试的成本还是蛮高的：

1. 首次运行的时候，系统本身是没办法优化的，我们只需要记录每一个测试的运行时间。
2. 第二次运行测试时，读取上次的运行时间，按时间排序并对其进行优化。
3. 第三次运行测试时，对前两次不同的测试时间取取值，再次排队列。
4. 。。。

我反正是懒得这么做，跑测试的时候可以刷刷微博。