最近在修改公司现有的一个自动化测试框架，里面用了很多time.sleep()方法，看着不是很爽，为什么我觉得sleep方法在自动化测试中不应该过多的使用呢，我甚至觉得应该尽可能避免sleep方法的使用，sleep可以作为增加自动化测试稳定性的手段，但是不能依赖sleep来让自动化系统稳定。

　　举个例子，如果一个UI的自动化测试，需要等待某个页面load完成以后才进行操作，那么需要对那个页面是否已经Load完成进行判断，而不应该 sleep(x)，x是一个magic number，有时候1、2秒就足以，有时候它却不知道有多大，因为已经超时了！那如果我们在check页面状态之前做一个短时间的sleep，那么在某些场合下可以增加这个自动化测试的稳定性，但是最终整个自动化测试的脚本是不会依赖于这个sleep的语句来达到稳定的。

　　在做自动化测试的时候，最常见的两种判断就是1. 某程序已经成功启动，某页面已经加载完毕。 2. 某程序已经正常关闭，某服务已经顺利停止。

　　回到实际的工作，我要判断被测的程序是否已经正常启动，可以用系统提供的一些工具，或者调用一些接口，例如SNMP命令，或者是调用一下Lua脚本等，如果他们都返回我们期望的数据，那么可以认为程序已经成功启动了。反之，如果前面的这些命令出错了，那么我也可以认为程序已经是关闭了的。

　　要实现自动化测试，就必须要让测试代码每时每刻都掌握着被测系统的状态，sleep方法会让自动化测试脚本的行为变得诡异。

　　什么是“诡异”的测试脚本呢？就是这个脚本在多次运行的情况下，测试结果并非每次都是一致，例如运行10次，有9次是通过的，有1次是失败的，那么这个测试究竟算是通过呢，还是失败呢？答案是：It depends。

　　在某些情况下，那一次失败，的确抓住了程序的某个BUG。原因可能是：

　　* 程序在运行一段时间后会出错

　　* 程序会出错，但错误不是每次都发生

　　* 在某些特殊输入下把错误暴露出来

　　但是在某些情况下，那1次失败的测试其实只是告诉测试的人，你写了一个“诡异”的测试脚本，实现了一个诡异的测试（Flakey Test）。不幸的是，导致一个自动化测试的行为变得诡异的原因实在太多太多。下面是一些常见的：

　　* 竞争条件

　　* 测试数据选择不当

　　* 测试的前置条件不受控

　　当发现一个诡异的自动化测试脚本，必须要下决心去改掉它：

　　* 使用一些常见有效的用例设计模式，例如“准备，执行，断言(Arrange, Act, Assert)”

　　* 使用MOCK技术

　　总之，当出现一个诡异的测试（Flakey Test）的时候，总是很郁闷的，但是为了以后不要遇到更大的郁闷，我们要尽早发现并且改掉那些诡异的测试。