1. 项目概述：为什么fixture是pytest接口测试的“灵魂”

如果你正在用pytest做接口自动化测试，或者正准备从unittest、requests+unittest的组合切换到pytest，那么你迟早会碰到一个绕不开的核心概念：fixture。很多新手会觉得，不就是个 @pytest.fixture 装饰器吗，跟 setup 、 teardown 差不多，用来准备测试数据或者清理环境。如果你也这么想，那可能就错过了pytest最强大、最优雅的设计精髓。

在我经手过的多个大型接口自动化项目中，fixture机制是支撑整个测试框架保持清晰、可维护、可扩展的基石。它远不止是“准备和清理”那么简单。想象一下这样的场景：你需要测试一个下单接口，但这个接口依赖用户登录态（token）、依赖一个已创建的商品、依赖一个可用的收货地址。如果每个测试用例都自己写一遍获取token、创建商品、创建地址的代码，那代码会臃肿不堪，且维护成本极高。fixture就是来解决这个问题的——它让你能像搭积木一样，声明测试用例所需要的“依赖”，pytest会自动帮你组装、调用，甚至智能地管理这些依赖的创建和销毁生命周期。

简单说，fixture机制是pytest实现 依赖注入 的核心。它把测试用例的“准备动作”（前置条件）和“清理动作”（后置条件）抽象成可复用、可组合、可配置的组件。这对于接口测试尤其重要，因为接口测试充满了各种依赖关系和共享资源（数据库连接、HTTP会话、缓存数据等）。掌握了fixture，你写的就不再是零散的脚本，而是一个结构清晰、易于协作的自动化工程。

2. fixture机制核心思想与优势解析

2.1 从“过程式”到“声明式”的转变

在传统的测试脚本中（比如用 unittest ），我们通常这样写：

import unittest
import requests

class TestOrder(unittest.TestCase):
    def setUp(self):
        # 每个测试方法前执行：登录，获取token
        self.session = requests.Session()
        resp = self.session.post('/api/login', json={'username': 'test', 'password': '123'})
        self.token = resp.json()['token']
        self.headers = {'Authorization': f'Bearer {self.token}'}
        
        # 创建测试商品
        product_resp = self.session.post('/api/product', json={'name': '测试商品'}, headers=self.headers)
        self.product_id = product_resp.json()['id']

    def tearDown(self):
        # 每个测试方法后执行：清理商品，登出
        self.session.delete(f'/api/product/{self.product_id}', headers=self.headers)
        self.session.post('/api/logout', headers=self.headers)
        self.session.close()

    def test_create_order(self):
        # 测试下单，使用setUp中准备的token和product_id
        order_data = {'product_id': self.product_id, 'quantity': 1}
        resp = self.session.post('/api/order', json=order_data, headers=self.headers)
        self.assertEqual(resp.status_code, 201)

这种方式有几个明显问题：

1. 耦合度高 ： setUp 和 tearDown 与测试类强绑定。如果另一个测试类也需要同样的登录态和商品，代码就得复制一遍。
2. 资源浪费 ：即使某个测试方法只需要token，不需要商品， setUp 里依然会创建商品， tearDown 里也会删除，造成不必要的请求开销。
3. 灵活性差 ：很难实现“按需准备”。比如，有些用例需要管理员token，有些只需要普通用户token，在 setUp 里写死逻辑会非常别扭。

pytest的fixture机制则完全不同，它是一种 声明式 的编程模型。你不再命令测试用例“先去做什么，再做什么”，而是声明测试用例“需要什么”。pytest的引擎负责找出并满足这些声明。

2.2 fixture带来的核心优势

1. 极高的可复用性 ：一个定义好的fixture（比如 user_token ）可以被项目中的任何测试函数、测试类、甚至其他fixture使用。这彻底消除了代码复制。
2. 清晰的依赖管理 ：测试函数通过参数列表显式声明它需要哪些fixture。看一眼函数签名，你就知道这个测试依赖哪些外部资源，代码意图一目了然。
3. 灵活的作用域控制 ：这是fixture的王牌功能。你可以指定一个fixture的生命周期是 function （每个测试函数运行一次）、 class （每个测试类运行一次）、 module （每个.py文件运行一次）还是 session （整个测试会话运行一次）。对于接口测试， session 作用域的fixture可以用来初始化昂贵的资源，如数据库连接池或全局配置，大大提升测试速度。
4. 强大的依赖注入与组合 ：fixture本身可以依赖其他fixture。你可以构建一个fixture“依赖树”，pytest会以正确的顺序解析和执行它们。例如，一个 order_data fixture可以依赖于 user_token fixture和 product fixture。
5. 自动化的清理工作 ：通过 yield 语句，可以轻松实现“准备-测试-清理”的完整生命周期管理，代码比 try...finally... 更简洁。

注意 ：很多从unittest转过来的同学，喜欢把fixture当成 setUp/tearDown 的替代品，只在 conftest.py 里写几个 session 或 module 级别的fixture。这其实只发挥了fixture三成的功力。真正的威力在于 细粒度的、可组合的fixture设计 。

3. fixture详解：从基础使用到高级技巧

3.1 定义与使用：你的第一个fixture

一个最简单的fixture是返回一个固定值。

# test_demo.py
import pytest

@pytest.fixture
def api_client():
    """返回一个配置好的requests会话客户端"""
    import requests
    client = requests.Session()
    client.headers.update({'Content-Type': 'application/json'})
    return client

def test_get_user(api_client): # 测试函数通过参数名请求fixture
    response = api_client.get('https://api.example.com/users/1')
    assert response.status_code == 200

当pytest执行 test_get_user 时，它会发现这个函数需要一个叫 api_client 的参数。于是pytest在自己的fixture注册表中查找名为 api_client 的fixture函数，执行它，并将返回值（一个 Session 对象）传递给 test_get_user 。

关键点 ：测试函数使用fixture的方式是 将fixture的函数名作为自己的参数 。这是pytest依赖注入的魔法所在。

3.2 作用域：控制fixture的生命周期

通过 scope 参数指定，这是优化测试效率的关键。

import pytest
import requests

@pytest.fixture(scope='session')
def global_config():
    """整个测试会话只执行一次，读取全局配置"""
    config = {'base_url': 'https://api.example.com', 'timeout': 10}
    print('\n>>> 初始化全局配置')
    return config

@pytest.fixture(scope='module')
def auth_token(global_config): # fixture可以依赖其他fixture
    """整个测试模块只执行一次，获取认证token"""
    print('\n>>> 开始获取模块级token')
    client = requests.Session()
    resp = client.post(f"{global_config['base_url']}/login", json={'user': 'test'})
    token = resp.json()['token']
    yield token # 使用yield，yield之前是setup，之后是teardown
    print('\n>>> 清理模块级token资源') # teardown逻辑
    # 例如：调用注销接口
    client.post(f"{global_config['base_url']}/logout", headers={'Authorization': f'Bearer {token}'})

@pytest.fixture(scope='function')
def fresh_order_data(auth_token, global_config):
    """每个测试函数都执行一次，生成新的订单数据"""
    print(f'\n>>> 为函数创建新的订单数据，使用token: {auth_token[:10]}...')
    return {
        'product_id': 1001,
        'quantity': 2,
        'token': auth_token
    }

def test_order_create(fresh_order_data):
    assert fresh_order_data['quantity'] == 2

def test_order_query(fresh_order_data, auth_token):
    # 这个测试函数依赖两个fixture
    assert auth_token is not None
    assert fresh_order_data['token'] == auth_token

执行上述测试，输出顺序大致如下：

>>> 初始化全局配置 (session， 第一次)
>>> 开始获取模块级token (module， 第一次进入test_order_create所在模块)
>>> 为函数创建新的订单数据... (function， test_order_create)
... 执行 test_order_create ...
>>> 为函数创建新的订单数据... (function， test_order_query)
... 执行 test_order_query ...
>>> 清理模块级token资源 (module， 该模块所有测试结束后)

你可以清晰地看到不同作用域fixture的创建和销毁时机。 对于接口测试， session 作用域非常适合存放 base_url 、数据库连接； module 作用域适合存放需要跨多个用例但又不希望每次请求都重复获取的token； function 作用域则用于那些需要完全隔离的测试数据。

3.3 使用yield实现setup/teardown

这是fixture最优雅的特性之一。在fixture函数中使用 yield 代替 return ， yield 之前的代码是“设置”部分， yield 之后的代码是“清理”部分。无论测试是否通过，清理部分的代码都会执行。

import pytest

@pytest.fixture
def db_connection():
    """模拟数据库连接"""
    print('\n>>> 建立数据库连接')
    connection = {'connected': True, 'id': 'conn_123'} # 模拟连接对象
    yield connection # 将连接对象提供给测试用例
    print('\n>>> 关闭数据库连接') # 测试用例执行完毕后执行
    connection['connected'] = False # 模拟关闭

def test_db_query(db_connection):
    print(f'执行查询，使用连接: {db_connection["id"]}')
    assert db_connection['connected'] is True

如果测试用例中发生了异常， yield 之后的清理代码依然会执行，这保证了资源的可靠释放，类似于 try...finally 。

实操心得 ：对于需要清理的资源（如临时文件、测试创建的数据库条目、占用的端口），务必使用 yield 模式。对于纯数据型的、无需清理的fixture（如配置字典、计算好的参数），直接用 return 更简洁。

3.4 自动使用：用autouse减少样板代码

有些fixture是每个测试用例都需要的，比如日志初始化、打点监控。你不想在每个测试函数参数里都写上它。这时可以用 autouse=True 。

import pytest
import time

@pytest.fixture(autouse=True, scope='function')
def log_test_duration():
    """自动为每个测试函数记录耗时"""
    start_time = time.time()
    yield
    duration = time.time() - start_time
    print(f'\n测试耗时: {duration:.3f}秒')
    if duration > 1.0: # 可以在这里加入慢测试告警逻辑
        print('警告：该测试执行较慢')

def test_fast():
    time.sleep(0.1)
    assert True

def test_slow():
    time.sleep(1.5)
    assert True

autouse fixture会对其作用域内的所有测试自动生效，无需在测试函数中声明。 但要谨慎使用 ，因为它隐藏了依赖关系，过度使用会让测试行为变得不透明。我的经验是，只将那些真正的、全局性的基础设施（如测试环境检查、全局日志配置）设为 autouse 。

3.5 参数化fixture：用一套逻辑测试多组数据

这是fixture结合 @pytest.mark.parametrize 之外的另一种参数化方式，尤其适合fixture本身的逻辑需要根据不同参数变化的情况。

import pytest

@pytest.fixture(params=['zh-CN', 'en-US', 'ja-JP'])
def user_locale(request): # request是一个内置fixture，可以访问当前参数
    """参数化fixture，模拟不同语言环境的用户"""
    locale = request.param
    print(f'\n>>> 初始化 {locale} 用户环境')
    user = {'name': 'TestUser', 'locale': locale}
    if locale == 'zh-CN':
        user['currency'] = 'CNY'
    elif locale == 'en-US':
        user['currency'] = 'USD'
    else:
        user['currency'] = 'JPY'
    return user

def test_user_currency(user_locale):
    # 这个测试会运行三次，分别对应三个参数
    print(f'测试用户货币: {user_locale["currency"]}')
    assert user_locale['currency'] in ['CNY', 'USD', 'JPY']

params 列表中的每个值，都会触发一次fixture的完整执行（包括yield的teardown），并运行所有依赖它的测试。这对于测试接口在不同输入条件下的行为非常有用，比如用不同的用户角色、不同的设备类型去调用同一个API。

4. 在接口测试框架中的实战应用

4.1 项目结构设计与conftest.py

一个典型的pytest接口测试项目结构如下：

api_test_project/
├── conftest.py          # 根目录conftest，定义全局fixture（如base_url, logger）
├── pytest.ini           # pytest配置文件
├── requirements.txt     # 项目依赖
├── common/              # 公共模块
│   ├── __init__.py
│   ├── client.py        # 封装的HTTP客户端
│   └── utils.py         # 工具函数
├── fixtures/            # 可选的，存放复杂fixture定义
│   └── data_fixtures.py
├── tests/
│   ├── __init__.py
│   ├── conftest.py      # 测试目录下的conftest，定义模块级fixture（如用户token）
│   ├── test_auth/       # 认证相关测试
│   │   ├── __init__.py
│   │   ├── conftest.py  # 更细粒度的conftest（如管理员fixture）
│   │   └── test_login.py
│   ├── test_order/      # 订单相关测试
│   │   ├── __init__.py
│   │   └── test_order_crud.py
│   └── test_product/    # 商品相关测试
        ├── __init__.py
        └── test_product_api.py

conftest.py 是pytest的魔力文件。其中定义的fixture可以被该文件所在目录及其所有子目录下的测试用例自动发现和使用。 利用好 conftest.py 的层级结构，可以实现fixture的精准作用域和共享。

• 根目录 conftest.py ：定义 session 或 module 级别的全局fixture。

  # 项目根目录 /conftest.py
  import pytest
  import os
  from common.client import ApiClient
  
  @pytest.fixture(scope='session')
  def env_config(request):
      """读取环境配置，如测试环境、预发布环境"""
      env = request.config.getoption('--env', default='test')
      config_map = {
          'test': {'base_url': 'https://test-api.example.com'},
          'staging': {'base_url': 'https://staging-api.example.com'},
      }
      return config_map.get(env, config_map['test'])
  
  @pytest.fixture(scope='session')
  def api_client(env_config):
      """初始化全局API客户端"""
      client = ApiClient(base_url=env_config['base_url'])
      yield client
      client.close() # 会话结束，关闭可能存在的连接池
  
  def pytest_addoption(parser):
      """添加自定义命令行选项"""
      parser.addoption('--env', action='store', default='test', help='选择测试环境: test or staging')
  

• 测试目录 tests/conftest.py ：定义该测试模块共用的fixture，如通用的测试用户。

  # tests/conftest.py
  import pytest
  
  @pytest.fixture(scope='module')
  def normal_user_token(api_client): # 依赖根目录的api_client
      """获取普通用户token，本模块所有测试共用"""
      resp = api_client.post('/auth/login', json={'username': 'user1', 'password': 'pass'})
      return resp.json()['access_token']
  
  @pytest.fixture(scope='function')
  def unique_username():
      """生成唯一的用户名，用于注册测试，避免重复"""
      import uuid
      return f'test_user_{uuid.uuid4().hex[:8]}'
  

• 子测试目录 tests/test_auth/conftest.py ：定义更具体的fixture，如管理员token。

  # tests/test_auth/conftest.py
  import pytest
  
  @pytest.fixture(scope='module')
  def admin_token(api_client):
      """获取管理员token，仅限auth测试模块使用"""
      resp = api_client.post('/auth/login', json={'username': 'admin', 'password': 'adminpass'})
      return resp.json()['access_token']
  

4.2 构建可组合的测试依赖链

接口测试中，后一个接口往往依赖前一个接口的产出。fixture的依赖注入特性让这种链条变得非常清晰。

假设我们要测试一个“创建订单-支付订单-查询订单”的流程：

# tests/test_order/test_order_flow.py
import pytest

@pytest.fixture
def logged_in_user(api_client, normal_user_token):
    """组合fixture：返回一个已登录的用户上下文"""
    api_client.set_token(normal_user_token)
    return {'client': api_client, 'token': normal_user_token}

@pytest.fixture
def created_product(logged_in_user):
    """依赖logged_in_user，创建一个测试商品"""
    client = logged_in_user['client']
    product_data = {'name': 'Fixture测试商品', 'price': 99.9, 'stock': 100}
    resp = client.post('/products', json=product_data)
    assert resp.status_code == 201
    product = resp.json()
    product_id = product['id']
    yield product # 将商品信息提供给测试用例
    # Teardown: 测试结束后删除商品
    client.delete(f'/products/{product_id}')

@pytest.fixture
def created_order(logged_in_user, created_product):
    """依赖logged_in_user和created_product，创建一个测试订单"""
    client = logged_in_user['client']
    order_data = {'product_id': created_product['id'], 'quantity': 2}
    resp = client.post('/orders', json=order_data)
    assert resp.status_code == 201
    order = resp.json()
    order_id = order['id']
    yield order
    # Teardown: 测试结束后删除订单 (假设接口支持)
    client.delete(f'/orders/{order_id}')

def test_order_payment(created_order, logged_in_user):
    """测试支付流程，依赖已创建的订单和登录态"""
    client = logged_in_user['client']
    payment_data = {'order_id': created_order['id'], 'amount': created_order['total_amount']}
    resp = client.post('/payments', json=payment_data)
    assert resp.status_code == 200
    assert resp.json()['status'] == 'success'

def test_order_query_after_payment(created_order, logged_in_user):
    """测试支付后查询订单状态"""
    client = logged_in_user['client']
    # 先执行支付（可以调用上面的fixture逻辑，或复用）
    payment_data = {'order_id': created_order['id'], 'amount': created_order['total_amount']}
    client.post('/payments', json=payment_data)
    
    # 再查询订单
    resp = client.get(f'/orders/{created_order["id"]}')
    assert resp.status_code == 200
    assert resp.json()['payment_status'] == 'paid'

在这个例子中， test_order_payment 函数只声明它需要 created_order 和 logged_in_user 。pytest会自动按依赖关系执行： api_client -> normal_user_token -> logged_in_user -> created_product -> created_order 。整个依赖链清晰可见，且每个资源都有自己明确的生命周期和清理逻辑。

4.3 动态fixture与请求上下文

有时，fixture的行为需要根据测试函数或外部条件动态决定。这时可以使用 request 这个内置fixture。

import pytest

@pytest.fixture
def user_role(request):
    """根据测试用例的标记（mark）动态返回用户角色"""
    # 检查测试函数是否有特定的pytest标记
    if request.node.get_closest_marker('admin_test'):
        role = 'admin'
        token = fetch_admin_token() # 假设的函数
    elif request.node.get_closest_marker('vip_test'):
        role = 'vip'
        token = fetch_vip_token()
    else:
        role = 'user'
        token = fetch_user_token()
    return {'role': role, 'token': token}

@pytest.mark.admin_test
def test_admin_api(user_role):
    assert user_role['role'] == 'admin'
    # 使用admin token测试管理接口

@pytest.mark.vip_test
def test_vip_api(user_role):
    assert user_role['role'] == 'vip'

request fixture提供了丰富的上下文信息，如当前测试模块、类、函数的名字，命令行参数，以及上面用到的标记（marks）。这让你能写出非常灵活的fixture。

5. 常见问题、调试技巧与性能优化

5.1 常见问题排查

1. FixtureNotFoundError: The fixture ‘xxx‘ is not found

   • 原因 ：最常见的原因是拼写错误。fixture名称区分大小写。
   • 排查 ：
     • 检查测试函数参数名和fixture定义名是否完全一致。
     • 检查该fixture是否定义在了当前测试文件、或当前及父目录的 conftest.py 中。
     • 使用 pytest --fixtures 命令可以列出当前目录下所有可用的fixture，确认你的fixture是否在其中。

2. ScopeMismatchError

   • 原因 ：fixture的作用域依赖关系错误。例如，一个 scope='function' 的fixture，不能依赖一个 scope='module' 的fixture（因为function级别的fixture每次测试都会新建，而它依赖的module级别fixture可能已经处于清理阶段）。
   • 规则 ：fixture只能依赖 作用域相同或更宽 的fixture。即： session -> module -> class -> function 。左边的可以依赖右边的，反之则不行。

3. Fixture在teardown时（yield之后）报错

   • 现象 ：测试用例本身通过了，但整个测试会话结束时报告错误。
   • 排查 ：错误很可能来自某个fixture的 yield 之后的清理代码。仔细检查这些清理逻辑（如关闭连接、删除测试数据）的异常处理。建议在清理代码中加入 try...except 和日志记录。

4. Autouse fixture导致意外行为

   • 现象 ：测试结果不符合预期，可能因为某个 autouse=True 的fixture默默地修改了全局状态。
   • 调试 ：使用 pytest -s 关闭输出捕获，查看 autouse fixture的打印信息。或者临时将其 autouse 设为 False ，在需要的测试中显式引用，看问题是否消失。

5.2 调试技巧

• 使用 pytest --setup-show ：这是调试fixture执行顺序的神器。它会以树状图显示每个测试用例执行前和执行后，fixture的调用和销毁顺序。

  pytest test_order_flow.py::test_order_payment --setup-show
  

• 在fixture中加入打印语句 ：在fixture的 yield 前后加入 print 语句，可以直观看到其生命周期。配合 pytest -s 使用。
• 使用 pytest --fixtures -v ：查看fixture的详细定义，包括其作用域和文档字符串。

5.3 性能优化实践

接口测试往往比较慢，优化fixture的使用能显著提升测试速度。

1. 尽可能使用宽作用域 ：对于创建成本高、状态稳定的资源，如HTTP客户端、数据库连接、全局配置，使用 scope='session' 。对于登录token这类在一定时间内有效的资源，使用 scope='module' 甚至 scope='session' （如果token有效期足够长）。
2. 避免在 session / module 级fixture中做可变操作 ： session 级fixture在整个测试过程中只初始化一次。如果你在其中创建了测试数据，并且后面的测试修改或删除了它，可能会影响其他测试。这类可变数据最好放在 function 级fixture中。
3. 利用 @pytest.fixture 的 params 参数进行批量数据准备 ：相比在测试函数内循环，使用参数化fixture可以让pytest更好地调度和执行，有时还能利用并行。
4. 对于只读的静态数据，使用普通模块变量 ：如果只是一些固定的配置数据、测试用例的预期结果，完全没必要放在fixture里，直接定义为模块顶层的常量或从文件加载即可。

5.4 一个综合性的conftest.py示例

最后，分享一个我在实际项目中常用的、功能比较全面的根目录 conftest.py 示例，它集成了环境控制、日志、API客户端和全局数据准备。

# conftest.py
import pytest
import logging
import os
from datetime import datetime
from common.client import ApiClient
from common.utils import load_yaml_config

def pytest_addoption(parser):
    parser.addoption('--env', action='store', default='test', choices=['dev', 'test', 'staging'], help='选择运行环境')
    parser.addoption('--log-level', action='store', default='INFO', help='设置日志级别')

@pytest.fixture(scope='session')
def env_config(request):
    """加载对应环境的配置"""
    env = request.config.getoption('--env')
    config_path = os.path.join('config', f'{env}_config.yaml')
    config = load_yaml_config(config_path)
    config['env'] = env
    return config

@pytest.fixture(scope='session')
def api_client(env_config, request):
    """创建并配置全局API客户端，并附加请求日志"""
    client = ApiClient(
        base_url=env_config['base_url'],
        timeout=env_config.get('timeout', 30)
    )
    
    # 为客户端添加一个简单的请求日志钩子，便于调试
    original_request = client.request
    
    def logged_request(method, url, **kwargs):
        test_name = request.node.name if hasattr(request, 'node') else 'UNKNOWN'
        logging.info(f'[{test_name}] 请求: {method} {url}')
        resp = original_request(method, url, **kwargs)
        logging.info(f'[{test_name}] 响应: {resp.status_code} - {resp.text[:200]}')
        return resp
    
    client.request = logged_request
    yield client
    client.close()
    logging.info('全局API客户端已关闭')

@pytest.fixture(scope='session', autouse=True)
def setup_logging(request):
    """根据命令行参数自动设置日志"""
    log_level = getattr(logging, request.config.getoption('--log-level').upper())
    logging.basicConfig(
        level=log_level,
        format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
        datefmt='%Y-%m-%d %H:%M:%S'
    )
    # 创建一个文件处理器，将日志写入文件
    log_dir = 'logs'
    os.makedirs(log_dir, exist_ok=True)
    file_handler = logging.FileHandler(os.path.join(log_dir, f'test_{datetime.now():%Y%m%d_%H%M%S}.log'))
    file_handler.setLevel(log_level)
    formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
    file_handler.setFormatter(formatter)
    logging.getLogger().addHandler(file_handler)
    yield
    # 测试结束后，清理自定义的处理器（可选）
    logging.getLogger().removeHandler(file_handler)

@pytest.fixture(scope='function')
def unique_test_data():
    """生成函数级别的唯一测试数据，避免测试间污染"""
    import uuid
    import time
    prefix = int(time.time())
    suffix = uuid.uuid4().hex[:6]
    return {
        'username': f'user_{prefix}_{suffix}',
        'email': f'test_{prefix}_{suffix}@example.com',
        'order_sn': f'ORDER{prefix}{suffix.upper()}'
    }

这个 conftest.py 提供了从环境隔离、日志记录到客户端封装的完整基础设施。当你运行 pytest --env=staging --log-level=DEBUG 时，所有测试都会自动在预发布环境运行，并输出详细的请求/响应日志到控制台和文件。这种设计让测试脚本本身可以更专注于业务断言，而将环境、配置、日志等横切关注点交给fixture管理。