其他测试框架 浅谈如何提高自动化测试的稳定性和可维护性 (pytest&allure)
序
在之前，我写过一个系列 “从零开始搭建一个简单的 ui 自动化测试框架（pytest+selenium+allure)”，在这个系列里，主要介绍了如何从零开始去搭建一个可用的自动化工程框架，但是还缺乏了一些细节的补充，例如对于自动化测试而言，如何提高其测试的稳定性？
本篇文章，将会和读者一起探讨这个问题。
装饰器与出错重试机制
谈到稳定性，不得不说的就是 “出错重试” 机制了，在自动化测试中，由于环境一般都是测试环境，经常会有各种各种的抽风情况影响测试结果，这样就为测试的稳定性带来了挑战，毕竟谁也不想自己的脚本一天到晚的出各种未知问题，而往往这种环境的抽风（通常是前端页面的响应速度和后端接口的响应速度）带来的影响是暂时的，可能上一秒失败了，下一秒你再执行又好了，在这种情况下，如果你有一个出错重试机制，起码可以在这种暂时性的影响下让你的脚本安然无恙，下面我们具体的说一下做法。
什么是装饰器？
因为我们的做法依赖装饰器，所以在去做之前，先简单介绍一下装饰器。
装饰器，表现形式为，在方法（或者类）的上面加上@xxx这样的语句，假如我们已经实现了一个装饰器名叫 retry，那么我们想用它就这么用：
@retry
def test_login():
print("test")
error = 1/0
如果 retry 实现了出错再次重试（稍后再说如何实现），那么这么使用的话，就会让 test_login 这个 case 在执行出错的时候再次执行。
很神奇，让我们来看看实现 retry 的代码：
def retry(func):
def warp():
for time in range(3):
try:
func()
except:
pass
return warp
就结果而言，执行以下代码：
@retry
def test_login():
print("test")
error = 1/0
test_login()
和执行：
retry(test_login)()
是等价的，由此我们可以看出，装饰器其实本质上就是一个函数，这个函数接收其他函数（或者类）作为参数，通过对这个函数（或者类）的调用或者修改，完成不更改原始函数而修改该函数的功能。
在这里还有一个知识点，你有没有想过，在 retry 内部的函数 warp()，是怎么拿到 func 这个参数来执行的？执行 retry 函数 return 的是 warp 这个函数，而 warp 并没有接受 func 这个传参啊。
这就是 python 里的闭包的概念，闭包就是指运行时自带上下文的函数，比如这里的 warp 这个函数，他运行的时候自带了上层函数 retry 传给他的 func 这个函数，所以才可以在运行时对 func 进行处理和输出。
了解了装饰器和闭包，那么下面就很容易做到对测试用例的出错重试机制了。
编写一个出错重试装饰器
现在，我们来尝试自己编写一个用于测试用例的出错重试装饰器，代码如下：
def retry(times=3,wait_time=10):
def warp_func(func):
def fild_retry(*args,**kwargs):
for t in range(times):
try:
func(*args,**kwargs)
return
except:
time.sleep(wait_time)
return fild_retry
return warp_func
这个装饰器可以通过传入重试次数（times）和重试等待时间（wait_time），对待测用例实行重试机制。
pytest 里的出错重试机制实现
在测试框架 pytest 里，已经实现了有关出错重试的策略，我们首先需要安装一个此类的插件，在 cmd 内执行以下命令安装：
pip install pytest-rerunfailures
如果你需要将此机制应用到所有的用例上，那么请在执行的时候使用如下命令（reruns 是重试次数）：
pytest --reruns 5
来执行你的用例；
如果你期望加上出错重试的等待时间，请使用如下命令 (reruns-delay 是等待时间)：
pytest --reruns 5 --reruns-delay 1
来执行你的用例；
如果你只想对某几个测试用例应用重试策略，你可以使用装饰器：
@pytest.mark.flaky(reruns=5, reruns_delay=2)
例如：
@pytest.mark.flaky(reruns=5, reruns_delay=2)
def test_example():
import random
assert random.choice([True, False])
更详细的介绍请参阅官方文档 。
Allure 里的测试用例分层
刚刚我们实现了用例的出错重试机制，但是这仅仅解决了脚本在不稳定环境下的稳定性；如果还想要脚本变得更加容易维护，除了传统的 po 模式使用例和元素分离之外，我们还可以引入测试用例分层机制。
为什么要采用分层机制？
传统的 po 模式，仅仅实现了用例和元素分离，这一定层面上保障了用例的可维护性，起码不必头疼于元素的变更会让用例到处失效；但是这还不够，例如，现在有三个 case，他们都包含了以下步骤：登录、打开工作台、进入个人中心；那么如果不做分层，这三个用例会把这三个步骤都写一遍，如果某天页面的变动导致其中一个步骤需要更改，那么你不得不去每个用例里去更新那个步骤。
而如果，我们把用例当做是堆积木，登录、打开工作台、进入个人中心这三个步骤都只是个积木，那么我们写用例的时候，只需要在用到这个步骤时，把积木搭上去；如果某一天，其中一个积木的步骤有变动，那么只需要去更改这个积木的内容，而无需在每个使用了这个积木的用例里去改动。
这大大增强了用例的复用性和可维护性，这就是采用分层机制的原因，下面，我会就 allure 里的分层机制做介绍来讨论具体如何实现。
allure 的装饰器@step
在 allure 里，我们可以通过装饰器@step完成分层机制，具体的，当你用@step装饰一个方法时，当你在用例里执行这个方法，会在报告里，表现出这个被装饰方法；而@step支持嵌套结构，这就意味着，你可以像搭积木一样去搭你的步骤，而他们都会一一在报告里被展示。
下面直接用 allure 的官方示例作做举例：
import allure
import pytest
from .steps import imported_step
@allure.step
def passing_step():
pass
@allure.step
def step_with_nested_steps():
nested_step()
@allure.step
def nested_step():
nested_step_with_arguments(1, 'abc')
@allure.step
def nested_step_with_arguments(arg1, arg2):
pass
def test_with_imported_step():
passing_step()
imported_step()
def test_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装饰的方法，组成测试用例；同时报告里也会支持层级显示；从而完成我们的分层机制。
Null，有缘哈哈.....
Allure 目前正在项目中成熟应用,也抛开了 Pytest,所以关于 Allure 有几个补充的...
1.Allure 的 Step 只是日志层的美化,它结合 Pytest 出来的 feature 、story 的功能对于管理用例来说非常棒.
2.Allure 更适合分布式运行,它独有的机制可以很轻松的实现 N 个报告整合...
3.Allure 很漂亮有木有..当时选择它的初衷的漂亮哈哈哈
unittest 有这个失败重试机制吗？
装饰器用的不错。测试框架还是推荐 robot framework，好用，好看。
666
Jenkins 的 Pipeline 里面也有相应的 retry 函数 https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#retry-retry-the-body-up-to-n-times
自己整的东西，感觉灵活性更高，多谢分享~
多谢分享！
有启发。
现在团队遇到的问题就是用 RF 框架，用例越写越多，里面的关键字也越来越多，底层的 Python 库也越来越多，可维护性和问题定位方法也越来越差
allure 不只是 step ，还有 feature 、story
Python 有 retrying 模块 这样写一个有什么优势吗？
赞一个， 问下 “从零开始搭建一个简单的 ui 自动化测试框架（pytest+selenium+allure)” 这个的链接发下呗，学习下哈
多谢楼主分享
Null，有缘哈哈.....
Allure 目前正在项目中成熟应用,也抛开了 Pytest,所以关于 Allure 有几个补充的...
1.Allure 的 Step 只是日志层的美化,它结合 Pytest 出来的 feature 、story 的功能对于管理用例来说非常棒.
2.Allure 更适合分布式运行,它独有的机制可以很轻松的实现 N 个报告整合...
3.Allure 很漂亮有木有..当时选择它的初衷的漂亮哈哈哈
chend
回复
是的，利用 step，feature ，story 可以写出类似 bdd 风格的用例，用例写的可以十分赏心悦目；
分布式我还没试过，主要因为没有那么多的 case，分布式对我来说比较多余；
allure 当然是我见过的最漂亮的报告啦~
为什么要出错重试，不稳定是什么原因造成的，如果是测试脚本，那要优化脚本，如果是被测程序自身问题，这时候不是说要重试吧，要把问题暴露出来，是程序问题要优化程序，是测试环境的问题要优化测试环境。
chend
回复
怎么实现分布式测试呀，现在用 pytest 和 allure 在做手机 ui 自动化，driver 在 conftest 下写了个 session 的 fixture，如果要实现多台手机的话，那要起不同手机不同 driver，要怎么搞，能给个思路么
这个 retry 函数的基础是参数 function 的失败是以程序 error 抛出来的，如果 function 的问题无法 catch 到怎么办？
楼主用 allure（python3.7,pytest3.8.0,pytest-allure-adaptor-1.7.10），有碰到这种报错吗？怎么解决的
cheng
回复
Sorry 现在才看到.
用多线程启动多个 Driver 就行了,通过 IP 来绑定.
另外多说一句, pytest 不支持多线程, 有个 xdist 的插件是支持多进程的. 如果使用多线程的话，你需要自己写个 Case 调度的简单框架.
def retry(times=3,wait_time=10):
def warp_func(func):
def fild_retry(args,kwargs):
for time in range(times):
try:
func(*args,*kwargs)
return
except:
time.sleep(wait_time)
return fild_retry
return warp_func
time 的变量和 time 模块冲突了
sfitstest
回复
没有太理解你的需求， 你是想将多个组的 Case 分别按组显示 Allure 的报告吗？还是 不同组的 Case 显示在不同的 Allure 中.
如果是第一种: Allure 有 store,feature,severity,thread,host 等五个分类, 你将 Case 分别按照这些分类就好，最终的 Allure 页面 可以分组显示每种类别下面的每个 Case。
如果是第二种:需要在运行过程中自己去创建每个 suites 的文件夹来存放对应的 xml 日志文件, 然后最终通过 allure generate 去生成 allure 报告的时候,分别指定不同的 suites 文件夹, 就可以生成多个 allrue 页面了.
chend
回复
不是想生成多个 allrue 页面，是想在一个 allure 页面中怎么显示多个 suits 的信息，我想组合一些 case,变成不同的 suits,但是现在虽然我把 case 写在不同的 py 中，显示出来的还是一个 suit 下的多个 case，我想问下怎么写，才能让显示变成不同 suits 下的多个 case
sfitstest
回复
看我上面回复， Allure 有 store,feature,severity,thread,host 等五个分类， 你说的 suits 应该指的是 feature 的概念, feature 下面还有 store 这一层。 如果你适用的是 pytest.allure 插件的话，你可以用 allure.feature 装饰器和 allure.story 装饰器来设置每个 Case 的所属 suits。
最后附一张报告截图,
sfitstest
回复
上面提到了呀， 如果你使用的是 pytest.allure 插件的话，用 allure.feature 和 allure.story 装饰器来设置每个 Case 的所属 suits. 如果不是用的 pytest 的话,就找下看你用的框架哪个 function 负责写 xml 日志中的 feature 和 story 节点的，用它这个 function 就行
chend
回复
我是用的 pytest，但是我用了 allure.feature 和 allure.story 装饰器来设置每个 Case，但这些 case 最后都归属在了一个 suite 下，怎么改才能像你这样分多个 suites 呢
sfitstest
回复
或者来个你最后 pytest 生成的 xml 日志的截图. 检查下这个 xml 日志文件中对应的每个 Case 的 feature 和 story 和你在代码中设置的一样不
chend
回复
我用了这四个 feature 来设置每个 Case，其中 jjjjj 那个还在另外一个 py 里，但是最终这四个 case 都归属在一个 suite 里了，就是我上面的那张截图
sfitstest
回复
你这不是四个 suite 显示么..不知道你所说的在一个 suite 是什么意思
feature 对应你说的 suite, story 是 feature 的下一层, 在 allure 的 html 报告界面, 主菜单的 Suites 表示按 feature 分类显示, Behaviors 表示按 feature-story 显示. 还有其它的按线程分类显示, 图表显示等等
chend
回复
这是我的 allure 报告，就是你看 Total 1 suites，虽然有很多 feature，但是我觉得 feature 不对应的 suite 吧
这是我网上看的别人的报告，你看他这个就有 Total 8 suites,相当于用一些 test case 来组成这 8 个 suites
我就想怎么能实现下面的这种样子
sfitstest
回复
@allure.feature("suite1")
@allure.story('Case01')
def test_case_01():
pass
@allure.feature("suite2")
@allure.story('Case02')
def test_case_02():
pass
你试一下, 看是否是你想要的效果.....
还有, allure 分 1 和 2 两个版本,1 已经不更新了, 现在 github 上都是 allure2.x 的. 你截图的那个 好像是 allure1.x 版本的, 可能显示位置和 allure2.x 版本有点界面上的不一样