在自动化测试过程中,常常让测试人员头疼的就是自动化测试脚本不能长期稳定的运行;总是出现各种意想不到错误导致测试的中断;长此以往,不仅影响测试的效率和准确性,也深深的影响着测试人员对自动化测试的信心。
在维护产品拷机代码时,拷机过程中有大量升级重启操作,脚本中就要不断的等待判断是否可进行下一步的操作,其中不同的操作,等待的时间不同,如果每一次等待都按照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类是通用的,大家可以用起来。
本文就是抛砖引玉,希望能和大家在自动化测试代码的健壮性上面有更多的交流;让我们的自动化测试道路走的更远一些。
作者:佚名
来源:51CTO