目录
前言:
装饰器与出错重试机制
什么是装饰器?
编写一个出错重试装饰器
pytest 里的出错重试机制实现
Allure 里的测试用例分层
为什么要采用分层机制?
allure 的装饰器@step
前言:
自动化测试在软件开发中扮演着重要的角色,它可以提高测试效率、减少人工错误,并且可以在持续集成和持续交付流程中发挥重要作用。然而,自动化测试的稳定性和可维护性是一个常见的挑战。
对于自动化测试而言,如何提高其测试的稳定性?
本篇文章,将会和读者一起探讨这个问题。
装饰器与出错重试机制
谈到稳定性,不得不说的就是 “出错重试” 机制了,在自动化测试中,由于环境一般都是测试环境,经常会有各种各种的抽风情况影响测试结果,这样就为测试的稳定性带来了挑战,毕竟谁也不想自己的脚本一天到晚的出各种未知问题,而往往这种环境的抽风(通常是前端页面的响应速度和后端接口的响应速度)带来的影响是暂时的,可能上一秒失败了,下一秒你再执行又好了,在这种情况下,如果你有一个出错重试机制,起码可以在这种暂时性的影响下让你的脚本安然无恙,下面我们具体的说一下做法。
什么是装饰器?
因为我们的做法依赖装饰器,所以在去做之前,先简单介绍一下装饰器。
装饰器,表现形式为,在方法(或者类)的上面加上@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') 组成;
这样就像搭积木一样,组成了测试用例;而在报告里,也层级分明的标识了步骤的嵌套结构。
作为一位过来人也是希望大家少走一些弯路
在这里我给大家分享一些自动化测试前进之路的必须品,希望能对你带来帮助。
(WEB自动化测试、app自动化测试、接口自动化测试、持续集成、自动化测试开发、大厂面试真题、简历模板等等)
相信能使你更好的进步!
点击下方小卡片