其他测试框架 浅谈如何提高自动化测试的稳定性和可维护性 (pytest&allure)

ice · August 30, 2018 · Last by sfitstest replied at January 14, 2019 · 8713 hits
本帖已被设为精华帖!

在之前,我写过一个系列“从零开始搭建一个简单的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后,报告是这样的:
image

可以看到,

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装饰的方法,组成测试用例;同时报告里也会支持层级显示;从而完成我们的分层机制。

有关@step的更多详细介绍请参阅官方文档

最佳回复

Null,有缘哈哈.....
Allure目前正在项目中成熟应用,也抛开了Pytest,所以关于Allure有几个补充的...
1.Allure的Step只是日志层的美化,它结合Pytest出来的feature 、story的功能对于管理用例来说非常棒.
2.Allure更适合分布式运行,它独有的机制可以很轻松的实现N个报告整合...
3.Allure很漂亮有木有..当时选择它的初衷的漂亮哈哈哈

共收到 44 条回复 时间 点赞

unittest有这个失败重试机制吗?

装饰器用的不错。测试框架还是推荐robot framework,好用,好看。

思寒_seveniruby 将本帖设为了精华贴 03 Sep 03:41

自己整的东西,感觉灵活性更高,多谢分享~

多谢分享!

有启发。

现在团队遇到的问题就是用RF框架,用例越写越多,里面的关键字也越来越多,底层的Python库也越来越多,可维护性和问题定位方法也越来越差

allure 不只是 step ,还有feature 、story

Python 有retrying模块 这样写一个有什么优势吗?

ice #12 · September 06, 2018 作者
Try ...Execpt 回复

自己写一下只是方便自己理解原理 如果没有特别的需求肯定是用现有的库更为方便

赞一个, 问下“从零开始搭建一个简单的ui自动化测试框架(pytest+selenium+allure)” 这个的链接发下呗,学习下哈

Tony 回复

赞同,还是robot framework好使,稍微稍微有点代码知识就可以搞定

多谢楼主分享

Null,有缘哈哈.....
Allure目前正在项目中成熟应用,也抛开了Pytest,所以关于Allure有几个补充的...
1.Allure的Step只是日志层的美化,它结合Pytest出来的feature 、story的功能对于管理用例来说非常棒.
2.Allure更适合分布式运行,它独有的机制可以很轻松的实现N个报告整合...
3.Allure很漂亮有木有..当时选择它的初衷的漂亮哈哈哈

ice #18 · September 07, 2018 作者
晨东 回复

是的,利用step,feature ,story可以写出类似bdd风格的用例,用例写的可以十分赏心悦目;
分布式我还没试过,主要因为没有那么多的case,分布式对我来说比较多余;
allure当然是我见过的最漂亮的报告啦~

为什么要出错重试,不稳定是什么原因造成的,如果是测试脚本,那要优化脚本,如果是被测程序自身问题,这时候不是说要重试吧,要把问题暴露出来,是程序问题要优化程序,是测试环境的问题要优化测试环境。

晨东 回复

怎么实现分布式测试呀,现在用pytest和allure在做手机ui自动化,driver在conftest下写了个session的fixture,如果要实现多台手机的话,那要起不同手机不同driver,要怎么搞,能给个思路么

这个retry函数的基础是参数function的失败是以程序error抛出来的,如果function的问题无法catch到怎么办?

Felix 回复

我们也用的 用的是 python3 + robotframework 感觉 工程化比较难做 ,

失败重跑,这个我也在用,很赞哦。但是楼主编写一个出错重试装饰器,这个举例子的代码有问题,这不是出错重试,只要用了这个装饰器,不管成功失败,都会按照设定次数重复运行,这个装饰器要修改一下

楼主用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模块冲突了

ice #27 · December 10, 2018 作者
丁剑 回复

我用的是import xx as xx。。。。 所以我这里没问题 😂 😂 😂

ice #28 · December 10, 2018 作者
丁剑 回复

不过你提醒的很有道理 确实应该做下提醒

simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 13 Dec 14:44
晨东 回复

你好,我想问下怎么写能实现allure展示多个suits,我想组合一些case,但是最后都在一个suit里面

sfitstest 回复

没有太理解你的需求, 你是想将多个组的Case分别按组显示Allure的报告吗?还是 不同组的Case 显示在不同的Allure中.
如果是第一种: Allure有store,feature,severity,thread,host等五个分类, 你将Case分别按照这些分类就好,最终的Allure页面 可以分组显示每种类别下面的每个Case。
如果是第二种:需要在运行过程中自己去创建每个suites的文件夹来存放对应的xml日志文件, 然后最终通过allure generate去生成allure报告的时候,分别指定不同的suites文件夹, 就可以生成多个allrue页面了.

晨东 回复


不是想生成多个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 回复

Sorry,截错了, 这个才是你说的那个图

晨东 回复

啊,对,就是这样,我想问的就是你这个suites里这四个suite是怎么形成的😝

sfitstest 回复

上面提到了呀, 如果你使用的是pytest.allure插件的话,用allure.feature和allure.story装饰器来设置每个Case的所属suits. 如果不是用的pytest的话,就找下看你用的框架哪个function负责写xml日志中的feature和story节点的,用它这个function就行

晨东 回复

我是用的pytest,但是我用了allure.feature和allure.story装饰器来设置每个Case,但这些case最后都归属在了一个suite下,怎么改才能像你这样分多个suites呢😰

sfitstest 回复

可以来个截图么, 你代码的截图 和 allure报告的截图

sfitstest 回复

或者来个你最后pytest生成的xml日志的截图. 检查下这个xml日志文件中对应的每个Case的feature和story和你在代码中设置的一样不

晨东 回复


我用了这四个feature来设置每个Case,其中jjjjj那个还在另外一个py里,但是最终这四个case都归属在一个suite里了,就是我上面的那张截图😥

sfitstest 回复

你这不是四个suite显示么..不知道你所说的在一个suite是什么意思😢
feature对应你说的suite, story是feature的下一层, 在allure的html报告界面, 主菜单的Suites表示按feature分类显示, Behaviors表示按feature-story显示. 还有其它的按线程分类显示, 图表显示等等

晨东 回复


这是我的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版本有点界面上的不一样

晨东 回复

好的,谢谢啦~

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up