在自动化测试过程中，常常让测试人员头疼的就是自动化测试脚本不能长期稳定的运行;总是出现各种意想不到错误导致测试的中断;长此以往，不仅影响测试的效率和准确性，也深深的影响着测试人员对自动化测试的信心。
在维护产品拷机代码时，拷机过程中有大量升级重启操作，脚本中就要不断的等待判断是否可进行下一步的操作，其中不同的操作，等待的时间不同，如果每一次等待都按照atom设备型号的标准，想想浪费大把的时间真是罪过呀。今天我们就以等待系统重启的例子来说明如何改善代码的稳定性，让你的脚本不再掉链子。
首先看一下下面这两段代码中等待页面响应的方法：
相信大家都会遇到上面例子中的问题，测试脚本总是因为等待时间不够长而屡次中断，通常情况，都会找一个最长的时间去等待，但即便是设置最长的时间，一旦网络比预想的多一秒的延迟，依然会导致测试的中断。那看下面用while循环，这样是不是就能够适应动态的等待时间。
但是问题又来了，对于测试脚本来讲，大部分都是在等待系统的各种响应，如果都按照这种方法，再看一下自己的脚本遍地都是while判断，每次都要循环，一不留神还死循环了;整个流程都被淹没在while中了;不爽啊。那我们就在继续封装一下了，哈哈，天池神器：wait_until wait_until_not 就问世了。
wait_until：等待你的目标出现
wait_until_not：等待你的目标消失
主要分为三个部分：等待(wait) 目标(method) 出现(until)/消失(until_not)
考虑到这段代码所有的测试人员都可以直接使用，就直接把代码贴出来，供大家参考;下面就直接看代码好了。
Wait说明
Wait类可以设置最长等待时间(timeout)，刷新时间间隔(poll_frequency)，可忽略的异常值(ignored_exceptions)。
前两个都不用解释了，就简单介绍一下 ignored_exceptions这个值，主要是在目标的检测过程可能发生各种异常，有些异常并不影响继续等待，就可以在这个值里面设置。当然wait方法被封装成类的形式，主要是天池的需要，大家可根据自己的需要进行简化。
util就是等待目标(method)的出现，直到timeout退出;**kwargs参数主要是目标(method)需要的一些参数扩展。
util_not就是等待目标(method)的消失，直到timeout退出;**kwargs参数主要是目标(method)需要的一些参数扩展。
通过以上封装，将第一节的while 循环瞬间就变成一个until函数。
首次尝试一下wait类吧，看! 好几行的代码是不是就变成下面一行就搞定了，你随便等吧。不过到底等什么呢，请看下节的method方法
目标(method)说明
就拿例子中的url_is_connectable举例吧，url_is_connectable类主要是判断url是否可访问;页面可响应后就可以进行下一步的操作了。当然，封装成类，并且内容在call函数中实现也是天池的需要，大家可根据自己的需要简化为函数都是可以的;函数的实现使用urllib库来判断当然大家也可以用其他方法。
结束
看了Wait和url_is_connectable这两个类，是不是一下子就清晰明了了，有了wait以后你就只需要关心你要等的目标就可以了。不过大家一定要注意死循环哦，我都已经掉进去两次了。当然，上面url_is_connectable方法只是一个例子，不过wait类是通用的，大家可以用起来。
本文就是抛砖引玉，希望能和大家在自动化测试代码的健壮性上面有更多的交流;让我们的自动化测试道路走的更远一些。
