pytest自动化测试fixture的作用域实例化顺序及可用性

目录
  • 1. fixture的作用域
    • 1.1 scope
      • 1.function:
      • 2.class:
      • 3.module:
      • 4.package:
      • 5.session:
    • 1.2 动态作用域(Dynamic scope)
      • 1.带参数-k运行
      • 2.无参数-k运行
  • 2. fixture的实例化顺序
    • 2.1 作用域级别高的fixture先执行
    • 2.2 fixture函数的依赖项先执行
    • 2.3 自动使用的fixture在其作用域内首先执行
  • 本节总结
  • 3. fixture的可用性

1. fixture的作用域

1.1 scope

通过前面文章的介绍,我们知道@pytest.fixture()有一个scope参数,并且有五个作用域级别,这五个作用域级别的说明总结如下:

注意:fixture是在测试首次请求时创建的,并基于它们的作用域被销毁。

scope 说明
function 默认值,函数或方法级别被调用,当函数执行结束后,fixture则被销毁
class 类级别调用一次,当类中的最后一个测试函数执行结束后,fixture则被销毁
module 模块级别(每一个.py文件)调用一次,当模块中最后一个测试函数执行结束后,fixture则被销毁
package 包(一个文件夹下的.py文件)级别调用一次,当包中最后一个测试函数执行结束后,fixture则被销毁
session 多个文件调用一次,当多文件中最后一个测试函数执行结束后,fixture则被销毁

单看说明,还是不太好理解的,所以下面我们通过示例来了解一下scope的用法。

示例1:

1.function:

演示代码:

import pytest
@pytest.fixture()
def login():
    print('登陆操作')
    yield
    print('注销操作')
class TestClass:
    def test_case1(self,login):
        print("TestClass:test_case1")

    def test_case2(self):
        print("TestClass:test_case2")

运行结果:

说明:

演示代码中,我们定义了一个fixture函数——login 和两个测试函数 test_case1test_case2

装饰器@pytest.fixture()没有指定scope参数,因此使用默认值:function

test_case1test_case2TestClass类中,且test_case1调用了logintest_case2未调用。

通过运行结果,我们可以看出来,scope=function的fixture——login,只在调用了它的test_case1这个测试函数前后执行。test_case2未执行。

2.class:

演示代码:

import pytest
@pytest.fixture(scope='class')   #名为login的fixture,完成登陆和注册操作
def login():
    print('登陆操作')
    yield
    print('注销操作')
class TestClass1:
    def test_case1(self,login):  #调用了login
        print("TestClass1:test_case1")
    def test_case2(self):
        print("TestClass1:test_case2")
class TestClass2:
    def test_case1(self):
        print("TestClass2:test_case1")
    def test_case2(self,login):  #调用了login
        print("TestClass2:test_case2")
@pytest.mark.usefixtures("login")  #TestClass3这个类,使用usefixtures调用了login
class TestClass3:
    def test_case1(self):
        print("TestClass3:test_case1")
    def test_case2(self):
        print("TestClass3:test_case2")

运行结果:

说明:

演示代码中我们定义了一个fixture——login;三个测试类——TestClass1TestClass2TestClass3,这个三个测试类中都定了两个测试函数——test_case1test_case2

对fixture函数我们声明了其作用域——scope='class'
TestClass1中,只有test_case1调用了login
TestClass2中,只有test_case1调用了login
TestClass3,我们使用@pytest.mark.usefixtures("login"),让整个类调用了login

查看运行结果我们可以发现:
TestClass1中,test_case1运行前有”登陆操作“打印,并在test_case2执行后有”注销操作“显打印。
TestClass2中,只有test_case2运行前有”登陆操作“打印,并在test_case2执行后有”注销操作“打印。而test_case1执行前后并无任何数据打印。
TestClass3则与Testclass1执行后数据显示一致。

TestClass1TestClass2结果的不同是由什么原因造成的呢?
官方文档在介绍fixture的scope的时候,有这样一句话,上文中也有提到:fixture是在测试首次请求时创建的,并基于它们的作用域被销毁。(Fixtures are created when first requested by a test, and are destroyed based on their scope。)
对于TestClass1test_case1调用了login,因此会在test_case1执行的时候,创建login,并在其执行之前打印了”登陆操作“。又根据login的scope——class,在TestClass1的最后一个测试函数test_case2执行后,根据login的功能打印”注销操作“,并销毁login
对于TestClass2login是由test_case2调用的,而test_case1test_case2先执行,所以test_case1执行的时候login还未被调用,fixture未被创建。直到执行test_case2时,login才被创建并进行了对应的操作。
后面其他类型的作用域示例中将不会在演示此种情况。

3.module:

演示代码:

import pytest
@pytest.fixture(scope='module')   #名为login的fixture,完成登陆和注册操作
def login():
    print('登陆操作')
    yield
    print('注销操作')
@pytest.mark.usefixtures("login")
class TestClass1:
    def test_case1(self):
        print("TestClass1:test_case1")
    def test_case2(self):
        print("TestClass1:test_case2")
class TestClass2:
    def test_case1(self):
        print("TestClass2:test_case1")
    def test_case2(self):
        print("TestClass2:test_case2")

运行结果:

说明:

演示代码中,我们定义了:
一个fixture——login(),并且声明其scope=”module“
两个测试类——TestClass1TestClass2
两个测试类中分别定义了两个测试函数——test_case1test_case2
TestClass1使用@pytest.mark.usefixtures("login")的方法,调用了login()

运行结果显示:
执行时,自第一个测试函数TestClass1中的test_case1调用login()时,该fixture被创建,并且按照login()实现的功能打印"登陆操作",并在当前模块中(一个.py文件)最后一个测试函数TestClass2中的test_case2执行结束后,按照login()实现的功能打印"注销操作",然后被销毁。

4.package:

演示代码:

首先看一下测试包目录,新增一个conftest.py。里面所有的模块都是上面的演示代码。修改这些模块里代码,注释调feature函数,删掉调用即可。

conftest.py

import pytest
@pytest.fixture(scope='package',autouse=True)   #名为login的fixture,完成登陆和注册操作
def login():
    print('登陆操作')
    yield
    print('注销操作')

使用命令行运行:

运行结果:

说明:
conftest.py中声明了一个fixture——login(),并且设置scope='package'autouse=True

使用命令行方式运行test_scope这个测试包中的所有模块。查看运行结果,在test_scope中第一个测试函数调用login()的时候,login创建,并按照功能打印”登陆操作“。在test_scope中最后一个测试函数运行结束后,按照login()功能打印出”注销操作“,并销毁login()

5.session:

使用package的演示代码,需改conftest.pylogin()scope='session',然后我们直接在终端中使用命令行运行多个文件。

运行以下命令:

运行结果:

说明:

使用命令行方式运行test_scope这个测试包中的test_class.py和test_function.py。查看运行结果,在test_class.py中第一个测试函数调用login()的时候,login创建,并按照功能打印”登陆操作“。在test_function.py中最后一个测试函数运行结束后,按照login()功能打印出”注销操作“,并销毁login()

1.2 动态作用域(Dynamic scope)

在某些情况下,我希望在不更改代码的情况下更改feature的作用域。pytest的从5.2版本开始,提供了动态作用域的方法,来解决这种情况。

通过官方文档的说明,我们了解到,可以将一个可调用对象传递给scope来实现动态作用域。这个可调用对象必须满足以下三个条件:

1.这个可调用对象返回类型需是string,且必须是有效的scope级别,即只能返回"function""class""module""package""session"中的一个。
2.在fixture定义期间,这个可调用对象只能被执行一次,不能被多次调用。
3.这个可调用对象定义的时候,必须使用fixture_nameconfig作为参数。

下面通过示例给大家演示以下用法。

示例2:

演示代码:

import pytest
def dynamic_fixture_scope(fixture_name,config):
    if config.getoption("-k",None):
        return "function"
    return "class"
@pytest.fixture(scope=dynamic_fixture_scope,autouse=True)
def login():
    print('登陆操作')
    yield
    print('注销操作')
class TestClass1:
    def test_A(self):
        print("这是TestClass1:test_A")
    def test_B(self):
        print("这是TestClass1:test_B")
class TestClass2:
    def test_A(self):
        print("这是TestClass2:test_A")

说明:

dynamic_fixture_scope:用来管理fixture的作用域,这个函数按照pytest官方文档的要求,带有fixture_nameconfig两个关键字作为参数,并且实现下述功能:

1.当用命令行运行测试时,运行命令中带有‘-k'参数,则被调的fixture函数的作用域为"function"

2.其余情况下,被调的fixture的函数为"class"

login:一个使用动态作用域方法的fixture,其scope=dynamic_fixture_scope。为了方便演示,autouse也被设置为True

下面我们分两种情况来运行看看:

1.带参数-k运行

运行命令:我们只运行测试名称中包含test_A的测试函数。

pytest -vs -k 'test_A' test_dynamicscope.py

运行结果:

通过运行结果可以看到,当命令行中出现-k参数的时候,loginscope确实是function级别的。两个被选中的测试函数分别在不同的测试类中,但是都调用了login

2.无参数-k运行

运行命令:我们不带参数-k运行。

pytest -vs test_dynamicscope.py

运行结果:

通过运行结果可以看到,无-k参数的时候,loginscope确实是class级别的。

2. fixture的实例化顺序

根据官方文档,我们了解到影响fixture实例化顺序的三个因素是:

1. 作用域(scope)
2. 依赖项
3. 自动调用(autouse)

而fixture名称、测试函数名称以及定义它们的位置一般都不会影响执行顺序。

下面介绍一下这个三个因素是如何影响实例化顺序的。

2.1 作用域级别高的fixture先执行

我们直接使用官方文档提供的示例来说明。

示例3:

演示代码:

import pytest
@pytest.fixture(scope="session")
def order():
    return []
@pytest.fixture
def func(order):
    order.append("function")
@pytest.fixture(scope="class")
def cls(order):
    order.append("class")
@pytest.fixture(scope="module")
def mod(order):
    order.append("module")
@pytest.fixture(scope="package")
def pack(order):
    order.append("package")
@pytest.fixture(scope="session")
def sess(order):
    order.append("session")
class TestClass:
    def test_order(self, func, cls, mod, pack, sess, order):
        assert order == ["session", "package", "module", "class", "function"]

运行结果:

说明:
演示代码中我们定义了:
六个fixture函数:

order:scope为session级别,返回一个空list。func: 调用了order,scope为默认的function级别,并实现向order返回的列表中插入”function“的操作。cls:调用了order,scope为class级别,并实现向order返回的列表中插入”class“的操作。mod:调用了order,scope为module级别,并实现向order返回的列表中插入”module“的操作。pack:调用了order,scope为package级别,并实现向order返回的列表中插入”package“的操作。sess:调用了order,scope为session级别,并实现向order返回的列表中插入”session“的操作。

一个测试函数:
test_order:主要目的是通过list中元素的顺序来判断是否按照预想的顺序执行fixture。

根据运行结果显示,测试断言通过,也就是fixture的执行顺序是按照我们预期的scope的级别由高到低去执行的。

test_order调用fixture的顺序是func, cls, mod, pack, sess, order,而实际执行的顺序是order, sess, pack, mod, cls, func。由此可见,我们在调用时定义的顺序不会影响到fixture的实际执行顺序的。

官网执行顺序图:

其中sessorder的scope都是session级别的,但是因为order是sess的依赖项,所以会先调用order,这个一点正好我们下面要说明。

2.2 fixture函数的依赖项先执行

前面文章中有说过,fixture函数是可以调用另外一个fixture函数的。在执行的时候,也是先执行调用的那个fixture函数。举了例子,fixture a 调用了fixture b,当测试函数调用fixture a的时候,会先去执行fixture b 然后再执行fixture a,最后执行测试函数。

这是因为fixture b 是fixture a 的依赖项,fixture a 可能会需要fixture b提供一些条件才能正常被执行。

下面我们来看一下官方文档提供的一个例子,

示例4:

演示代码:

import pytest
@pytest.fixture
def order():
    return []
@pytest.fixture
def a(order):
    order.append("a")
@pytest.fixture
def b(a, order):
    order.append("b")
@pytest.fixture
def c(a, b, order):
    order.append("c")
@pytest.fixture
def d(c, b, order):
    order.append("d")
@pytest.fixture
def e(d, b, order):
    order.append("e")
@pytest.fixture
def f(e, order):
    order.append("f")
@pytest.fixture
def g(f, c, order):
    order.append("g")
def test_order(g, order):
    assert order == ["a", "b", "c", "d", "e", "f", "g"]

运行结果:

说明:

演示代码中定义了八个fixture函数和一个测试函数,其中:
fixture函数有:ordeabcdefg
测试函数有:test_order

a调用了order
b调用了a, order
c调用了a, b, order
d调用了c, b, order
f调用了e, order
g调用了f, c, order
test_order调用了gorder

我们来整理以上所有函数的依赖关系,他们之间的依赖关系如图所示:

之前文章也有说过,在同一次测试执行过程中,fixture是可以被多次调用的,但是不会被多次执行。执行一次后,fixture的实例对象和返回值会存在缓存中,下次再被调用的时候是直接从缓存中获取的。

所以上面的顺序我们可以再简化一下:

执行完所有依赖的fixture函数后,我们得到的order的结果为:['a','b','c','d','e'],因此测试断言通过。

2.3 自动使用的fixture在其作用域内首先执行

根据官方文档的说明,我们可以得到一下两点重要内容:

1.当测试函数调用的fixture的作用域级别都一样,那么会首先调用自动使用的fixture。

示例5:

import pytest
@pytest.fixture
def order():
    return []
@pytest.fixture
def func(order):
    order.append("function")
@pytest.fixture(autouse=True) #修改cls为自动使用fixture
def cls(order):
    order.append("class")
@pytest.fixture
def mod(order):
    order.append("module")
@pytest.fixture
def pack(order):
    order.append("package")
@pytest.fixture
def sess(order):
    order.append("session")
class TestClass:
    def test_order(self, func, cls, mod, pack, sess, order):
        print(order)
        assert order == ["session", "package", "module", "class", "function"]

运行结果:

说明:

我们把示例3的代码拿过来修改一下,把所有fixture的scope都改为function级别,并且对cls试着autouse=True。
test_order请求fixture的顺序是:func, cls, mod, pack, sess

当scope级别一样的时候,且无依赖关系的时候,fixture的执行顺序应该与调用顺序一致,也应该是func, cls, mod, pack, sess。但是实际运行的结果却是['class', 'function', 'module', 'package', 'session']。由此可以判断出,在scope一致且无依赖的情况下,自动执行的fixture是最先被执行的。

2.对一个autouse的fixture A来说,若调用了非autouse的fixture B,那么对于调用了fixture A的测试函数来说,fixture B也相当于是autouse的。

我们再来看一下官方给的一个示例。

示例6:

演示代码:

import pytest
@pytest.fixture
def order():
    return []
@pytest.fixture
def a(order):
    order.append("a")
@pytest.fixture
def b(a, order):
    order.append("b")
@pytest.fixture(autouse=True)
def c(b, order):
    order.append("c")
@pytest.fixture
def d(b, order):
    order.append("d")
@pytest.fixture
def e(d, order):
    order.append("e")
@pytest.fixture
def f(e, order):
    order.append("f")
@pytest.fixture
def g(f, c, order):
    order.append("g")
def test_order_and_g(g, order):
    assert order == ["a", "b", "c", "d", "e", "f", "g"]

说明:

演示代码中定义了八个fixture函数和一个测试函数,其中:
fixture函数有:ordeabcdefg
测试函数有:test_order

a调用了order
b调用了a, order
c调用了 b, order,且是自动使用fixture;
d调用了 b, order
f调用了e, order
g调用了f, c, order
test_order调用了gorder

若c是非自动使用的fixture,代码中fixture的一个执行顺序是什么样的呢?

下图是运行结果:

根据上面的运行结果和下面的顺序图,我们可以看到,除了g调用了c之外,其他函数都没有调用c,而g也调用了f,所以现在还不清楚c应该在d、e、f之前还是之后执行。对c来说他只需在b之后、g之前执行即可。而实际运行结果,c是在d、e、f之后和g之前执行的。

对于pytest来说,fixture的执行顺序就是不明确,这种情况很可能会影响测试函数的执行行为,影响了测试结果。

所以,我们需要明确fixture的执行顺序。

当我们使c为自动使用fixture时,这个顺序又会发生什么变化呢?

下图为运行结果:

根据上图的运行结果和下图的顺序图,我们可以看出来,当自动使用c后,它的执行优先级就比d要高,所以可以保证c是在d之前执行的。这样使执行顺序明确了。

当c是自动使用的fixture后,根据fixture函数的依赖项先执行这一规则,c所依赖的b、b所依赖的a和a所依赖的order都会被执行。这样对于调用了c的g来说,order、a、b也相当于是自动使用的fixture了,但是当有其他fixture调用order、a、b时,order、a、b仍然保持自己的特性。

本节总结

我们来总结一下fixture实例化顺序的一个规则:

1.fixture的scope级别越高,那么它执行的优先级越高。优先级为:session>package>module>class>function

2.fixture如果存在依赖项,那么它所依赖的fixture函数会先被执行。

3.同scope级别fixture中,自动使用的fixture会最先执行;若该fixture存在依赖项,则对于调用了fixture的测试函数来说,这些依赖项也可以看做是自动使用的。

4.我们在编码的时候最好可以依照以上规则为pytest提供一个清晰的fixture执行顺序,以免影响测试函数的行为和测试结果。

3. fixture的可用性

对于测试函数来说,能够调用那些fixture,是由fixture定义的位置决定。

1.当fixture定义在一个测试类中时,只有该类中的测试函数可调用此fixture,其他测试函数无法调用该fixture。当测试函数在模块的全局范围内定,则模块下的所有测试函数都可以调用它。该特点与全局变量和局部变量相似。

示例7:

演示代码:

import pytest
class TestClass1:
    @pytest.fixture()
    def login(self):
        print("login")
    def test_case1(self,login):
        print("TestClass1::test_case1")
class TestClass2:
    def test_case2(self,login):
        print("test_case2")

运行结果:

说明:

演示代码中定义了两个测试类:TestClass1TestClass2
TestClass1中定义了一个fixture——login,和测试函数test_case1test_case1有调用login
TestClass1中定义了一个测试函数test_case2test_case2有调用login

通过运行结果我们可以看到,与login在同一测试类中的test_case1成功调用了login,但是TestClass2test_case2调用login的时候报错了,报错原因:未发现fixture函数“login”

2.conftest.py中定义的fixture,可以被同目录下的所有模块中定义的测试函数调用。

示例8:

演示代码:

test_availability/conftest.py:

import pytest
@pytest.fixture()
def login():
    print("login")

test_availability/test_availability.py:

class TestClass1:
    def test_case1(self,login):
        print("TestClass1::test_case1")
class TestClass2:
    def test_case2(self,login):
        print("test_case2")

运行结果:

说明:

我们在test_availability目录下创建了一个conftest.py,并且定义了一个fixture——login
在test_availability.py中,我们定义了两个测试函数test_case1test_case1,两个测试函数都调用了login

查看运行结果,测试函数都成功调用了login

3.如果安装的第三方插件提供了fixture,任何测试函数都可以正常使用,无需考虑位置因素。

文末说明:
以上内容是我在阅读pytest官方文档后,依照个人理解进行整理。内容可能会有理解错误之处,欢迎大家留言指正。谢谢

更多关于fixture作用域实例化顺序及可用性的资料请关注我们其它相关文章!

(0)

相关推荐

  • Python pytest装饰器总结(实例详解)

    几个常用装饰器 pytest.ini 配置文件 例子: [pytest] addopts = -v -s --html=py_test/scripts/report/report.html -p no:warnings --reruns=10 testpaths = ./py_test/scripts python_files= test_rerun.py python_classes = Test* python_function = test* xfail_strict = true add

  • python pytest进阶之conftest.py详解

    前言 前面几篇文章基本上已经了解了pytest 命令使用,收集用例,finxture使用及作用范围,今天简单介绍一下conftest.py文件的作用和实际项目中如是使用此文件! 实例场景 首先们思考这样一个问题:如果我们在编写测试用的时候,每一个测试文件里面的用例都需要先登录后才能完成后面的操作,那么们该如何实现呢?这就需要我们掌握conftest.py文件的使用了. 实例代码 创建如下一个目录 ConftestFile |conftest.py |test_file_01.py |test_f

  • 详解Pytest测试用例的执行方法

    pytest概述 pytest是一个非常成熟的全功能的Python测试框架,主要特点有以下几点: 1.简单灵活,容易上手,文档丰富: 2.支持参数化,可以细粒度地控制要测试的测试用例: 3.能够支持简单的单元测试和复杂的功能测试,还可以用来做selenium/appnium等自动化测试.接口自动化测试(pytest+requests); 4.pytest具有很多第三方插件,并且可以自定义扩展,比较好用的如pytest-selenium(集成selenium).pytest-html(完美html

  • python pytest进阶之fixture详解

    前言 学pytest就不得不说fixture,fixture是pytest的精髓所在,就像unittest中的setup和teardown一样,如果不学fixture那么使用pytest和使用unittest是没什么区别的(个人理解). fixture用途 1.做测试前后的初始化设置,如测试数据准备,链接数据库,打开浏览器等这些操作都可以使用fixture来实现 2.测试用例的前置条件可以使用fixture实现 3.支持经典的xunit fixture ,像unittest使用的setup和te

  • Pytest接口自动化测试框架搭建模板

    auto_api_test 开发环境: Pycharm 开发语言&版本: python3.7.8 测试框架: Pytest.测试报告: Allure 项目源码Git地址 项目目录结构 api – 模仿PO模式, 抽象出页面类, 页面类内包含页面所包含所有接口, 并封装成方法可供其他模块直接调用 config – 配置文件目录 data – 测试数据目录 doc – 文档存放目录 log – 日志 report – 测试报告 scripts – 测试脚本存放目录 tools – 工具类目录 .gi

  • pytest自动化测试fixture的作用域实例化顺序及可用性

    目录 1. fixture的作用域 1.1 scope 1.function: 2.class: 3.module: 4.package: 5.session: 1.2 动态作用域(Dynamic scope) 1.带参数-k运行 2.无参数-k运行 2. fixture的实例化顺序 2.1 作用域级别高的fixture先执行 2.2 fixture函数的依赖项先执行 2.3 自动使用的fixture在其作用域内首先执行 本节总结 3. fixture的可用性 1. fixture的作用域 1.

  • pytest自动化测试中的fixture的声明和调用

    目录 1. fixture的声明 2. fixture的调用 2.1 fixture的调用方式 2.1.1 使用fixturename 2.1.2 使用@pytest.mark.usefixtures("fixturename") 2.1.3 autouse--自动应用 2.2 fixture使用的灵活性 2.2.1 一个fixture函数可以调用其他的fixture 2.2.2 fixture函数可被反复重用 2.2.3 测试函数/fixture函数可以一次调用多个fixture 2

  • pytest解读fixture有效性及跨文件共享fixtures

    目录 fixture有效性及跨文件共享fixtures 一.fixture有效性 二.跨文件共享fixtures fixture有效性及跨文件共享fixtures 一.fixture有效性 fixture有效性,说白了就是fixture函数只有在它定义的使用范围内,才可以被请求到.比如,在类里面定义了一个fixture,那么就只能是这个类中的测试函数才可以请求.但是,如果一个fixture定义的范围是整个模块,那么这个模块下的每个测试函数都可以去请求. 这里还有另一个影响fixture有效性的参

  • pytest中fixture函数使用

    目录 前言 fixture函数 fixture的使用 前言 setup和teardown能实现在测试用例执行之前或之后做一些操作,但是这种是整个测试脚本全局生效的: 如果我们想实现某些用例执行之前进行登录,某些用例执行之前不需要进行登录,这种场景我们再使用setup和teardown就无法实现了,这时候我们就需要用到fixture功能了. fixture函数 fixture(scope="function", params=None, autouse=False, ids=None,

  • Appium+Python+pytest自动化测试框架的实战

    菜鸟一枚,写的不好勿喷,大家一起学习 先简单介绍一下目录,再贴一些代码,代码里有注释 Basic目录下写的是一些公共的方法,Data目录下写的是测试数据,image存的是测试失败截图,Log日志文件,Page测试的定位元素,report测试报告,Test测试用例,pytest.ini是pytest启动配置文件,requirements.txt需要安装的py模块,run.py运行文件 Basic/base.py 里面封装了 一些方法,元素的点击,输入,查找,还有一些自己需要的公共方法也封装在里面,

  • pytest自动化测试数据驱动yaml/excel/csv/json

    目录 数据驱动 1.pytest结合数据驱动-yaml 工程目录结构: 2.pytest结合数据驱动-excel 工程目录结构: 3.pyetst结合数据驱动-csv 读取csv数据: 工程目录结构: 4.pytest结合数据驱动-json json结构: 查看json文件: 读取json文件: 工程目录结构: 数据驱动 数据的改变从而驱动自动化测试用例的执行,最终引起测试结果的改变.简单说就是参数化的应用. 测试驱动在自动化测试中的应用场景: 测试步骤的数据驱动: 测试数据的数据驱动: 配置的

  • Python自动化测试pytest中fixtureAPI简单说明

    什么是fixture 根据pytest官方文档的说明,fixture可以简单的归纳为具有以下功能的函数: 配置测试前系统的初始状态: 定义传入测试中的数据集: 为批量测试提供数据源等 与xUnit风格的setup和teardown的对比 fixture的功能与setup和teardown类似,可以实现setup和teardown的功能,但是对这些功能进行了明显的改进,主要有以下方面: 调用灵活.可以在测试函数.模块.类或整个项目中声明fixture的名称来进行调用: 使用灵活.fixture即适

  • Pytest框架之fixture的详细使用教程

    前言 前面一篇讲了setup.teardown可以实现在执行用例前或结束后加入一些操作,但这种都是针对整个脚本全局生效的 如果有以下场景:用例 1 需要先登录,用例 2 不需要登录,用例 3 需要先登录.很显然无法用 setup 和 teardown 来实现了fixture可以让我们自定义测试用例的前置条件 fixture优势 命名方式灵活,不局限于 setup 和teardown 这几个命名 conftest.py 配置里可以实现数据共享,不需要 import 就能自动找到fixture sc

  • 浅谈基于Pytest框架的自动化测试开发实践

    目录 01 - Pytest核心功能 02 - 创建测试项目 03 - 编写测试用例 04 - 执行测试用例 05 - 数据与脚本分离 06 - 参数化 07 - 测试配置管理 08 - 测试的准备与收尾 09 - 标记与分组 10 - 并发执行 11 - 测试报告 12 - 总结 参考资料 Pytest是Python的一种易用.高效和灵活的单元测试框架,可以支持单元测试和功能测试.本文不以介绍Pytest工具本身为目的,而是以一个实际的API测试项目为例,将Pytest的功能应用到实际的测试工

  • Pytest框架之fixture详解(一)

    我们在编写测试用例,都会涉及到用例执行之前的环境准备工作,和用例执行之后的环境清理工作. 代码版的测试用例也不例外.在自动化测试框架当中,我们也需要编写: 用例执行之前的环境准备工作代码(前置工作代码) 用例执行之后的环境清理工作(后置工作代码) 通常,在自动化测试框架当中,都叫做fixture. pytest作为python语言的测试框架,它的fixture有2种实现方式. 一种是xunit-style,跟unittest框架的机制非常相似,即setup/teardown系列 一种是它自己的f

随机推荐