你要解决问题的思路是，为什么其中 page 容易继承和初始化 driver 驱动，导致测试时会同时打开多个浏览器页面。？

显然是你的传参有问题。不是每一步都创建 driver，创建 driver 只调用一次，包括了打开浏览器、关闭浏览器，配合 yeild，放在 conftest 里面，在 setUp 和 tearDown 分别调用。

盲猜，你的 PO 模式的，page 模块的 driver 不是入参。每个模块都会重复创建。 我写个伪代码吧，帮你提供思路,仅供参考：

你的 conftest 配置：

# ./conftest.py
import  pytest
import ... ...

@pytest.fixture(scope='function')
def   operatorSeleniumDriver():
        driver = 创建dirver
        driver.打开浏览器
        yield  driver 
        driver.关闭浏览器

你的 page 模块的封装：

#./Page/ Login.py

class LoginStep:

  def 选择登录的方式(self,driver):
       driver.find_element(xxxxxxx)
       pass

  def 输入用户名密码登陆(self,driver):
       driver.find_element(xxxxxxx)
       pass

你的测试用例这样写：

# ./TestCase/test_login.py
import   Page.xxx.Login

class Test_login:

    def  test_login(operatorSeleniumDriver)：
    driver = operatorSeleniumDriver
    action = LoginStep()
    action.选择登录的方式(driver)
    action.输入用户名密码登陆(driver)
    ......

虽然不会改动原来脚本，但我感觉你大部分工作要维护 field_change 函数了

首先你这个逻辑就是错的，夹具函数本身只返回一个值或者不返回，即使是加入 yield，也不能实现分批次返回。“When using yield the code block after the yield statement is executed as teardown code regardless of the test outcome, and must yield exactly once.”

所以，你要把夹具函数当成@pytest.mark.parametrize用？夹具函数本身就不具备参数化的能力，重新设计你的脚本逻辑，再深刻点理解一下夹具函数的定义

Decorator to mark a fixture factory function.
This decorator can be used, with or without parameters, to define a fixture function.
The name of the fixture function can later be referenced to cause its invocation ahead of running tests: test modules or classes can use the pytest.mark.usefixtures(fixturename) marker.
Test functions can directly use fixture names as input arguments in which case the fixture instance returned from the fixture function will be injected.
Fixtures can provide their values to test functions using return or yield statements. When using yield the code block after the yield statement is executed as teardown code regardless of the test outcome, and must yield exactly once.

赞一个

必须到现场吗？

我有 dubbo 测试工具

任何事情是有前提的，你如果要进行单接口日常测试。用 1 条数据，被 1000 个接口去测，没问题，因为运行完了就完了，这条数据删了也就删了，接口变也就变了，因为你测过了你不用管了，后面别人也不会用。但是！
但是！如果你要是写自动化脚本，用一条数据被 1000 个接口去调，会被打死。或者说，长得帅的人，一般不干这种事。

我给你举个简单例子

假设你这条客户数据 “小明，18 岁，男，高级管理员，自由从业者”，满足 1000 个接口的调用。有一天，你的接口当中有个做了调整，它需要查询，19 岁以上的客户。好了，你这条数据不满足了，于是你又造了一条，或者更糟糕的情况是你直接把小明改成了 20 岁。然后又有一天，另外一个接口又变了，它需要女性客户，你又增加数据。又变了一个接口，需要普通管理员等等等等，于是终于你造了一大堆客户。但是某天，数据库表被一顿操作不知道啥时候被清空了，数据丢了，当然这种情况还可以挽回，如果你批量化造数据。但是你发现 5000 个接口执行时间太长，需要分布执行自动化脚本，你又发现数据被同时操作又有冲突。。。。。。等等等等问题会等着。为了仅仅一开始偷的懒，后面要弥补多少操作?? 所以为什么一开始就不把事情做好呢??

自动化脚本写不难，难的是维护

等你维护 3w 条自动化用例的时候，你会发现，隔离，太他 niang 的正确了！而且要从框架搭建一开始就就要做！必须每条 case 是 0 耦合度！从用例执行前客户新建，到用例执行完删除客户，数据库每次都新的像舔过一样