装饰器与出错重试机制
谈到稳定性，不得不说的就是“出错重试”机制了，在自动化测试中，由于环境一般都是测试环境，经常会有各种各种的抽风情况影响测试结果，这样就为测试的稳定性带来了挑战，毕竟谁也不想自己的脚本一天到晚的出各种未知问题，而往往这种环境的抽风（通常是前端页面的响应速度和后端接口的响应速度）带来的影响是暂时的，可能上一秒失败了，下一秒你再执行又好了，在这种情况下，如果你有一个出错重试机制，起码可以在这种暂时性的影响下让你的脚本安然无恙，下面我们具体的说一下做法。
什么是装饰器？
因为我们的做法依赖装饰器，所以在去做之前，先简单介绍一下装饰器。
装饰器，表现形式为，在方法（或者类）的上面加上@xxx这样的语句，假如我们已经实现了一个装饰器名叫retry，那么我们想用它就这么用：
@retry
deftest_login():
print("test")
error=1/0
如果retry实现了出错再次重试（稍后再说如何实现），那么这么使用的话，就会让test_login这个case在执行出错的时候再次执行。
很神奇，让我们来看看实现retry的代码：
defretry(func):
defwarp():
fortimeinrange(3):
try:
func()
except:
pass
returnwarp
就结果而言，执行以下代码：
@retry
deftest_login():
print("test")
error=1/0
test_login()
和执行：
retry(test_login)()
是等价的，由此我们可以看出，装饰器其实本质上就是一个函数，这个函数接收其他函数（或者类）作为参数，通过对这个函数（或者类）的调用或者修改，完成不更改原始函数而修改该函数的功能。
在这里还有一个知识点，你有没有想过，在retry内部的函数warp()，是怎么拿到func这个参数来执行的？执行retry函数return的是warp这个函数，而warp并没有接受func这个传参啊。
这就是python里的闭包的概念，闭包就是指运行时自带上下文的函数，比如这里的warp这个函数，他运行的时候自带了上层函数retry传给他的func这个函数，所以才可以在运行时对func进行处理和输出。
了解了装饰器和闭包，那么下面就很容易做到对测试用例的出错重试机制了。
编写一个出错重试装饰器
现在，我们来尝试自己编写一个用于测试用例的出错重试装饰器，代码如下：
defretry(times=3,wait_time=10):
defwarp_func(func):
deffild_retry(*args,**kwargs):
fortimeinrange(times):
try:
func(*args,**kwargs)
return
except:
time.sleep(wait_time)
returnfild_retry
returnwarp_func
这个装饰器可以通过传入重试次数（times）和重试等待时间（wait_time），对待测用例实行重试机制。
pytest里的出错重试机制实现
在测试框架pytest里，已经实现了有关出错重试的策略，我们首先需要安装一个此类的插件，在cmd内执行以下命令安装：
pipinstallpytest-rerunfailures
如果你需要将此机制应用到所有的用例上，那么请在执行的时候使用如下命令（reruns是重试次数）：
pytest--reruns5
来执行你的用例；
如果你期望加上出错重试的等待时间，请使用如下命令(reruns-delay是等待时间)：
pytest--reruns5--reruns-delay1
来执行你的用例；
如果你只想对某几个测试用例应用重试策略，你可以使用装饰器：
@pytest.mark.flaky(reruns=5,reruns_delay=2)
例如：
@pytest.mark.flaky(reruns=5,reruns_delay=2)
deftest_example():
importrandom
assertrandom.choice([True,False])
更详细的介绍请参阅官方文档 。
Allure里的测试用例分层
刚刚我们实现了用例的出错重试机制，但是这仅仅解决了脚本在不稳定环境下的稳定性；如果还想要脚本变得更加容易维护，除了传统的po模式使用例和元素分离之外，我们还可以引入测试用例分层机制。
为什么要采用分层机制？
传统的po模式，仅仅实现了用例和元素分离，这一定层面上保障了用例的可维护性，起码不必头疼于元素的变更会让用例到处失效；但是这还不够，例如，现在有三个case，他们都包含了以下步骤：登录、打开工作台、进入个人中心；那么如果不做分层，这三个用例会把这三个步骤都写一遍，如果某天页面的变动导致其中一个步骤需要更改，那么你不得不去每个用例里去更新那个步骤。
而如果，我们把用例当做是堆积木，登录、打开工作台、进入个人中心这三个步骤都只是个积木，那么我们写用例的时候，只需要在用到这个步骤时，把积木搭上去；如果某一天，其中一个积木的步骤有变动，那么只需要去更改这个积木的内容，而无需在每个使用了这个积木的用例里去改动。
这大大增强了用例的复用性和可维护性，这就是采用分层机制的原因，下面，我会就allure里的分层机制做介绍来讨论具体如何实现。
allure的装饰器@step
在allure里，我们可以通过装饰器@step完成分层机制，具体的，当你用@step装饰一个方法时，当你在用例里执行这个方法，会在报告里，表现出这个被装饰方法；而@step支持嵌套结构，这就意味着，你可以像搭积木一样去搭你的步骤，而他们都会一一在报告里被展示。
下面直接用allure的官方示例作做举例：
importallure
importpytest
from.stepsimportimported_step
@allure.step
defpassing_step():
pass
@allure.step
defstep_with_nested_steps():
nested_step()
@allure.step
defnested_step():
nested_step_with_arguments(1,'abc')
@allure.step
defnested_step_with_arguments(arg1,arg2):
pass
deftest_with_imported_step():
passing_step()
imported_step()
deftest_with_nested_steps():
passing_step()
step_with_nested_steps()
运行这个case后，报告是这样的：
可以看到，
test_with_nested_steps由passing_step()和step_with_nested_steps()这两个方法组成；
而step_with_nested_steps()又由nested_step()组成；
nested_step()又由nested_step_with_arguments(1, 'abc')组成；
这样就像搭积木一样，组成了测试用例；而在报告里，也层级分明的标识了步骤的嵌套结构。
这样，我们就可以通过一个又一个@step装饰的方法，组成测试用例；同时报告里也会支持层级显示；从而完成我们的分层机制。
