1. 项目概述：为什么我们需要间接参数？

在写自动化测试脚本时，我们经常会遇到一种情况：测试用例的输入数据本身很简单，但为了运行这个用例，我们需要先准备一个复杂的“前置环境”。比如，你想测试一个用户登录功能，你的测试数据是用户名和密码，但在这之前，你得先启动一个浏览器、打开登录页面、甚至可能还要清理一下测试数据库。这个“前置环境”的构建，往往比测试数据本身更复杂、更耗时。

在pytest中，@pytest.mark.parametrize装饰器是我们批量生成测试用例的利器，它让我们能轻松地用多组数据驱动同一个测试函数。但默认情况下，它只是简单地把参数值“喂”给测试函数。如果这个参数值不是直接用于断言，而是用来构建一个更复杂的对象（比如一个配置好的浏览器驱动、一个连接特定数据库的客户端、或者一个带有特定状态的模拟对象），那么直接在测试函数里写这些构建逻辑，代码就会变得臃肿且难以复用。

这就是indirect参数大显身手的地方。它允许你将parametrize提供的参数，间接地传递给一个固件（fixture），由这个固件来负责创建和返回最终测试函数真正需要的那个复杂对象。简单说，indirect把parametrize从一个“数据分发器”，变成了一个“复杂对象工厂的订单接收员”。你告诉它你要什么“原料”（参数），它把订单转给“工厂”（固件），工厂用这些原料生产出成品，再交给测试函数使用。

我最初接触这个特性时，觉得它有点绕，但一旦用上手，尤其是在搭建数据驱动与复杂环境准备相结合的测试框架时，你会发现它能极大地提升代码的清晰度和可维护性。它能让你把环境准备的逻辑（固件）和数据驱动的逻辑（参数化）优雅地解耦。

2. 核心概念拆解：parametrize与fixture的桥梁

要彻底理解indirect，我们必须先厘清pytest中两个核心概念——parametrize和fixture——在默认模式和间接模式下的不同协作关系。

2.1 默认模式：参数直达测试函数

在没有indirect的情况下，parametrize的工作流程非常直观。我们来看一个最基础的例子：

import pytest @pytest.mark.parametrize("username, password", [("alice", "secret123"), ("bob", "qwerty")]) def test_login_with_direct_params(username, password): # 在这里，username和password是直接可用的字符串 print(f"尝试登录: 用户={username}, 密码={password}") # 假设这里调用某个登录函数进行断言 # assert login(username, password) is True

在这个例子里：

• @pytest.mark.parametrize定义了两个参数username和password，并提供了两组数据。
• pytest会自动生成两个测试用例：test_login_with_direct_params[alice-secret123]和test_login_with_direct_params[bob-qwerty]。
• 运行时，每组数据会直接作为参数值传入测试函数test_login_with_direct_params。

这种模式适用于简单场景，测试函数自己就能处理这些原始数据。但如果登录前需要先初始化一个WebDriver，并把用户名密码填充到对应的输入框，代码就会变成这样：

def test_login_with_direct_params_complex(username, password): # 环境准备逻辑和测试逻辑耦合在一起 driver = webdriver.Chrome() driver.get("http://example.com/login") user_input = driver.find_element(By.ID, "username") pwd_input = driver.find_element(By.ID, "password") user_input.send_keys(username) pwd_input.send_keys(password) # ... 点击登录按钮并进行断言 driver.quit()

你会发现，环境准备（启动浏览器、打开页面、定位元素）的代码在每个生成的测试用例中都会重复执行，并且和具体的测试数据username,password紧密耦合。这违反了DRY（Don‘t Repeat Yourself）原则，也让测试用例的重点——验证登录逻辑——变得不清晰。

2.2 间接模式：参数先经过fixture加工

indirect参数改变了这个流程。它告诉pytest：“嘿，这个参数名，你别直接传给测试函数，你先去找一个同名的固件（fixture），把这些参数值传给那个固件，然后把固件返回的结果，再传给测试函数。”

我们重构上面的例子。首先，定义一个名为login_page的固件，它接受参数：

import pytest from selenium import webdriver from selenium.webdriver.common.by import By @pytest.fixture def login_page(request): """一个接收参数的fixture，用于准备登录页面环境。""" # request.param 用于接收从parametrize传递过来的单个参数值 # 如果是多个参数，通常我们会用字典或元组打包传递 username = request.param["username"] password = request.param["password"] # 复杂的环境准备逻辑 driver = webdriver.Chrome() driver.get("http://example.com/login") user_input = driver.find_element(By.ID, "username") pwd_input = driver.find_element(By.ID, "password") user_input.send_keys(username) pwd_input.send_keys(password) # 将准备好的“成品”（这里我们返回driver和填充好的页面状态）交给测试函数 # 更常见的做法是返回一个包含所需状态的对象或字典 yield {"driver": driver, "username_filled": username, "password_filled": password} # 测试结束后清理环境 driver.quit()

现在，我们使用indirect来调用这个固件：

@pytest.mark.parametrize( "login_page", # 参数名必须和fixture函数名一致 [ ({"username": "alice", "password": "secret123"}), # 这组数据会传给login_page fixture的request.param ({"username": "bob", "password": "qwerty"}), ], indirect=True # 关键！声明login_page参数是间接的 ) def test_login_with_indirect_param(login_page): # 此时，login_page不再是原始数据，而是fixture返回的“成品”字典 driver = login_page["driver"] # 直接进行登录操作和断言，环境准备逻辑已被剥离 login_button = driver.find_element(By.ID, "login-btn") login_button.click() # 断言登录结果... # assert driver.current_url == "http://example.com/dashboard"

流程解析：

1. pytest看到@pytest.mark.parametrize装饰器，参数名为login_page，且indirect=True。
2. 它不会把{"username": "alice", ...}这个字典直接传给test_login_with_indirect_param。
3. 而是去查找名为login_page的固件，并将每组数据（即那个字典）赋值给该固件函数内部可访问的request.param属性。
4. 固件函数login_page被执行，它用request.param中的数据完成了复杂的浏览器启动和表单填充工作。
5. 固件yield返回一个包含driver等信息的字典。
6. 这个返回的字典，作为login_page参数的值，最终被注入到测试函数test_login_with_indirect_param中。

这样做的巨大优势：

• 关注点分离：测试函数只关心“测试什么”（业务断言），固件只关心“怎么准备”（环境搭建）。
• 逻辑复用：所有需要登录页面的测试用例，都可以复用login_page这个固件，只需提供不同的数据。
• 代码简洁：测试用例变得非常清爽，可读性极强。
• 灵活控制：你可以为不同的数据组定制不同的固件行为（虽然固件是同一个，但内部可以根据request.param进行条件判断）。

注意：当indirect=True应用于整个参数列表时，所有被参数化的参数名都必须有同名的固件存在。你也可以传递一个参数名列表给indirect，如indirect=[“login_page”]，来指定只有列表中的参数是间接的，其他参数仍是直接的。这在混合使用直接和间接参数时非常有用。

3. 间接参数的高级用法与实战技巧

掌握了基本概念后，我们来看看indirect在实际项目中更强大、也更易出错的几种用法。理解这些细节，能帮你避开很多坑。

3.1 混合使用直接与间接参数

一个测试函数常常需要多种类型的参数。有些是简单的配置项（如超时时间），适合直接传递；有些则需要复杂初始化（如数据库连接），适合间接传递。pytest允许你灵活地混合使用它们。

关键在于indirect参数可以接受一个列表。我们来看一个模拟API测试的场景：

import pytest import requests @pytest.fixture def api_client(request): """根据传入的base_url和auth_token创建并配置一个API客户端。""" # request.param 现在是一个元组或列表，因为parametrize传入了多个值 base_url, auth_token = request.param headers = {"Authorization": f"Bearer {auth_token}"} # 这里可以构建一个更复杂的客户端对象，我们简化为一个字典 client = {"base_url": base_url, "headers": headers, "session": requests.Session()} client["session"].headers.update(headers) yield client client["session"].close() @pytest.mark.parametrize( "api_client, user_id, expected_status", # 三个参数 [ (("https://api.example.com/v1", "token_abc"), 123, 200), (("https://api.example.com/v1", "token_xyz"), 999, 404), (("https://api.staging.com/v2", "token_stg"), 456, 200), ], indirect=["api_client"] # 只有api_client是间接参数，user_id和expected_status是直接参数 ) def test_get_user(api_client, user_id, expected_status): """测试获取用户信息的API。""" url = f"{api_client['base_url']}/users/{user_id}" response = api_client["session"].get(url) assert response.status_code == expected_status

代码解读：

• @pytest.mark.parametrize定义了三个参数：api_client,user_id,expected_status。
• 数据部分，每一组都是一个三元组。第一个元素(“https://...”, “token_...”)是传给间接参数api_client的。
• indirect=[“api_client”]明确指定，只有api_client参数需要走间接流程，去找同名的固件。user_id和expected_status则直接传递给测试函数。
• 在api_client固件中，request.param接收到的就是(“https://...”, “token_...”)这个元组。
• 测试函数最终接收到的三个参数分别是：固件返回的客户端字典、直接传递的用户ID、直接传递的期望状态码。

实操心得：

• 参数对齐：确保parametrize中每一组数据的结构，与indirect列表指定的参数预期完全匹配。上例中，第一组数据是一个三元组，分别对应(api_client的原料, user_id, expected_status)。
• 固件接收：在间接固件里，request.param接收的是对应参数位置上的整个值。如果像上例那样，一个间接参数对应多个“原料”，通常用元组或字典打包传递，然后在固件内解包。
• 清晰命名：给间接参数和其对应的固件起一个见名知意的名字，如api_client，这比用param1之类的要清晰得多。

3.2 单个参数接收多个值（元组/字典打包）

上面的例子已经展示了，我们可以把多个相关的配置项打包（比如base_url和auth_token）作为一个整体传递给间接固件。更常见的做法是使用字典，因为它可读性更好，也更容易扩展。

@pytest.fixture def configured_database(request): """根据配置字典初始化数据库连接和测试数据。""" config = request.param # 现在config是一个字典 conn = create_db_connection( host=config["host"], port=config["port"], user=config["user"], password=config["password"] ) # 可能根据config中的其他键，如“initial_data”，来初始化表和数据 initialize_test_data(conn, config.get("initial_data", [])) yield conn cleanup_test_data(conn) conn.close() @pytest.mark.parametrize( "configured_database", [ { "host": "localhost", "port": 3306, "user": "test_user", "password": "test_pass", "initial_data": [("user1", 100), ("user2", 200)] }, { "host": "db.staging.com", "port": 5432, "user": "ro_user", "password": "readonly", "initial_data": [] # 使用空数据测试 }, ], indirect=True ) def test_database_operations(configured_database): conn = configured_database # 使用conn进行数据库操作和断言 # ...

使用字典的好处是，固件内部的代码可以通过键名直接访问配置，避免了依赖参数顺序。未来如果需要增加新的配置项（比如database_name），只需要在字典里添加，并修改固件内部逻辑即可，测试数据层的改动最小。

3.3 通过固件动态决定参数化范围

这是indirect一个非常强大的特性。有时，我们参数化所需的数据本身需要动态生成，比如从一个文件、一个数据库或者一个外部API中读取。我们可以在一个固件里完成数据的读取和准备，然后通过indirect让另一个固件或测试函数使用这些数据。

但这里有一个常见的误区：你不能直接在一个用于indirect的固件里yield多组数据来实现参数化。参数化的源头始终是@pytest.mark.parametrize。正确的模式是，用一个固件来生成参数化需要的数据列表。

import json import pytest @pytest.fixture(scope="session") def load_test_configs(): """会话级固件，从文件加载所有测试配置。""" with open("test_configs.json", "r") as f: all_configs = json.load(f) return all_configs # 返回一个配置列表 # 注意：这个固件不会被indirect调用，它只是数据的提供者 @pytest.fixture def dynamic_test_params(load_test_configs): """基于加载的配置，动态生成用于参数化的数据。 这个fixture本身不作为indirect参数，而是用来生成parametrize的‘argvalues’。 """ # 这里可以对all_configs进行过滤、加工等操作 filtered_configs = [cfg for cfg in load_test_configs if cfg["env"] == "staging"] # 将每个配置字典打包，作为一组测试数据 # 每组数据对应parametrize的一个元组（这里只有一个参数‘config’） return [pytest.param(cfg, id=cfg["name"]) for cfg in filtered_configs] # 这才是接收间接参数的固件 @pytest.fixture def app_instance(request): """根据配置启动一个应用实例。""" config = request.param app = start_application(config["app_config"]) yield app app.shutdown() # 在测试函数上使用parametrize，其数据来源于dynamic_test_params这个fixture # 但pytest不支持直接在parametrize装饰器里调用另一个fixture。 # 因此，我们需要换一种思路：使用pytest_generate_tests钩子，或者将dynamic_test_params的返回值手动赋给一个变量，再用于装饰器。 # 更实用的做法是：在conftest.py中，使用pytest_generate_tests钩子实现动态参数化。 # 方法：使用 pytest_generate_tests 钩子 (在 conftest.py 中) def pytest_generate_tests(metafunc): """实现动态参数化的标准钩子。""" if "app_instance" in metafunc.fixturenames: # 动态加载或生成测试数据 with open("test_configs.json", "r") as f: all_configs = json.load(f) filtered_configs = [cfg for cfg in all_configs if cfg["env"] == "staging"] # 告诉pytest，对app_instance这个fixture进行参数化 metafunc.parametrize( "app_instance", filtered_configs, indirect=True, # 关键：声明为间接参数 ids=[cfg["name"] for cfg in filtered_configs] )

在这个模式中，pytest_generate_tests钩子扮演了“动态参数化决策者”的角色。它检查测试函数是否需要app_instance固件，如果需要，就动态地调用parametrize方法，并指定indirect=True。这样，数据源（JSON文件）和参数化逻辑就完全从测试函数和固件中解耦出来了，非常灵活。

常见问题：为什么我不能在@pytest.mark.parametrize里直接调用一个返回列表的固件？因为装饰器在模块导入时就会执行，而固件是在测试运行过程中根据请求动态调用的。两者的执行时机不同。所以，对于需要从固件动态获取参数化数据的场景，pytest_generate_tests钩子是标准且强大的解决方案。

4. 实战案例：构建一个数据驱动的Web UI测试框架

让我们通过一个更完整的、贴近真实项目的例子，将indirect的用法串联起来。假设我们要测试一个电商网站的搜索功能，测试需要：1) 用不同的浏览器启动；2) 访问不同环境的网址；3) 使用不同的关键词搜索；4) 验证结果。

4.1 定义核心固件（接收间接参数）

首先，在conftest.py中定义我们的核心固件，它负责创建WebDriver实例。

# conftest.py import pytest from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC @pytest.fixture def browser_driver(request): """一个接收配置字典的fixture，用于创建和配置WebDriver。 配置字典应包含：browser_name, headless, implicit_wait, environment """ config = request.param # 根据配置选择浏览器 if config["browser_name"].lower() == "chrome": options = webdriver.ChromeOptions() if config.get("headless"): options.add_argument("--headless=new") driver = webdriver.Chrome(options=options) elif config["browser_name"].lower() == "firefox": options = webdriver.FirefoxOptions() if config.get("headless"): options.add_argument("--headless") driver = webdriver.Firefox(options=options) else: raise ValueError(f"不支持的浏览器: {config['browser_name']}") # 应用隐式等待 driver.implicitly_wait(config.get("implicit_wait", 10)) # 根据环境选择基础URL env_urls = { "local": "http://localhost:8080", "staging": "https://staging.shop.com", "production": "https://www.shop.com" } base_url = env_urls.get(config["environment"], env_urls["staging"]) driver.get(base_url) # 返回driver和配置信息，供测试函数使用 yield {"driver": driver, "config": config, "base_url": base_url} # 测试结束后的清理工作 driver.quit()

这个browser_driver固件是一个典型的“间接参数处理器”。它期望request.param是一个包含浏览器类型、是否无头模式、等待时间、测试环境等信息的配置字典。它根据这些信息完成所有复杂的初始化工作，并返回一个包含驱动和上下文的字典。

4.2 组织测试数据与参数化

接下来，我们创建测试数据。我们可以把它放在一个单独的Python模块、JSON或YAML文件里。这里为了演示，放在测试文件里。

# test_search.py import pytest # 定义多组测试配置。每组配置都会触发一次browser_driver fixture的执行。 SEARCH_TEST_CONFIGS = [ pytest.param( { # 这是传给browser_driver fixture的request.param "browser_name": "chrome", "headless": True, # 在CI环境中通常用无头模式 "implicit_wait": 5, "environment": "staging" }, # 以下是直接传给测试函数的参数 "laptop", # search_keyword ["Dell", "Lenovo", "HP"], # expected_brands (期望结果中包含的品牌) id="chrome-staging-laptop" # 为这组测试用例起一个可读的ID ), pytest.param( { "browser_name": "firefox", "headless": False, # 本地调试时可以打开浏览器查看 "implicit_wait": 10, "environment": "local" }, "mouse", ["Logitech", "Razer"], id="firefox-local-mouse" ), # 可以轻松添加更多组合，比如测试不同环境、不同浏览器 pytest.param( { "browser_name": "chrome", "headless": True, "implicit_wait": 5, "environment": "production" }, "keyboard", ["Keychron", "Filco"], id="chrome-production-keyboard" ), ] @pytest.mark.parametrize( "browser_driver, search_keyword, expected_brands", SEARCH_TEST_CONFIGS, indirect=["browser_driver"] # 指定只有browser_driver是间接参数 ) def test_product_search(browser_driver, search_keyword, expected_brands): """测试电商网站搜索功能。""" driver = browser_driver["driver"] base_url = browser_driver["base_url"] # 1. 定位搜索框并输入关键词 search_box = driver.find_element(By.NAME, "q") search_box.clear() search_box.send_keys(search_keyword) # 2. 点击搜索按钮 search_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']") search_button.click() # 3. 等待结果加载（显式等待示例） wait = WebDriverWait(driver, 10) results_container = wait.until( EC.presence_of_element_located((By.ID, "search-results")) ) # 4. 获取所有结果项 product_items = results_container.find_elements(By.CLASS_NAME, "product-item") # 5. 提取品牌信息并进行断言 actual_brands = [] for item in product_items[:5]: # 假设只检查前5个结果 brand_element = item.find_element(By.CLASS_NAME, "brand") actual_brands.append(brand_element.text.strip()) # 断言：期望的品牌至少有一个出现在实际结果中（根据实际业务逻辑调整） for expected_brand in expected_brands: assert expected_brand in actual_brands, f"期望品牌 '{expected_brand}' 未出现在搜索结果中。实际结果: {actual_brands}" # 也可以记录一些信息用于调试 print(f"测试通过: 环境={browser_driver['config']['environment']}, " f"浏览器={browser_driver['config']['browser_name']}, " f"关键词='{search_keyword}'")

4.3 运行与报告分析

当你运行pytest test_search.py -v时，你会看到类似如下的输出：

test_search.py::test_product_search[chrome-staging-laptop] PASSED test_search.py::test_product_search[firefox-local-mouse] PASSED test_search.py::test_product_search[chrome-production-keyboard] PASSED

每个用例的ID（id=”chrome-staging-laptop”）都清晰地显示在报告中，让你一眼就能看出是哪组配置下的测试。如果某个用例失败，你能立刻知道是在什么浏览器、什么环境、测试什么关键词时出的问题，极大地方便了问题定位。

这个框架的优势总结：

1. 高度可配置：通过修改SEARCH_TEST_CONFIGS列表，可以轻松添加新的浏览器、环境、关键词组合，无需改动测试逻辑或固件逻辑。
2. 关注点分离：
   • browser_driver固件：只负责WebDriver的生命周期管理和初始导航。
   • test_product_search函数：只负责具体的搜索业务逻辑和断言。
   • 测试数据：集中管理，清晰明了。
3. 易于维护：如果未来需要更换浏览器驱动（如从Chrome切换到Edge），或者修改环境URL，只需要在一个地方（browser_driver固件）修改。
4. 利于扩展：如果想增加新的测试维度（比如不同的屏幕分辨率），只需在配置字典中添加字段，并在固件中增加相应的处理逻辑即可。

5. 避坑指南与最佳实践

在使用indirect参数化的过程中，我踩过不少坑，也总结出一些让代码更健壮、更易用的实践。

5.1 常见错误与排查

1. FixtureNotFoundError: The fixture ‘xxx‘ requested by ‘yyy‘ not found.

   • 原因：在@pytest.mark.parametrize中指定了indirect=True或indirect=[“xxx”]，但项目中不存在名为xxx的固件。
   • 解决：检查固件名拼写是否正确，固件是否定义在测试文件内、conftest.py中，或者是否通过插件正确引入。确保固件的作用域（scope）允许被当前测试函数访问。

2. TypeError: fixture ‘xxx‘ got an unexpected keyword argument ‘param‘

   • 原因：你定义了一个固件，并在parametrize中将其指定为间接参数，但这个固件函数没有定义request参数。request参数是pytest传入的，用于访问request.param。
   • 解决：确保间接固件的函数签名中包含request参数。例如：def my_fixture(request):

3. ValueError: In test ‘yyy‘: indirect fixture ‘xxx‘ doesn‘t have a parameter marked value.

   • 原因：这个错误信息可能有点晦涩。它通常发生在你为间接参数提供了多组数据，但固件内部访问request.param的方式不对，或者parametrize的数据结构与固件期望的不匹配。
   • 解决：仔细检查parametrize中每一组数据里，对应间接参数的那个部分（可能是元组、字典或单个值），是否与固件内request.param的预期类型和结构一致。使用调试打印print(request.param)来确认实际接收到的值。

4. 测试用例ID混乱或不可读

   • 原因：如果没有使用pytest.param的id参数，pytest会自动生成用例ID，对于复杂数据结构（如字典、长元组），生成的ID会非常长且难以阅读。
   • 解决：养成使用pytest.param(..., id=”描述性名称”)的习惯。这个ID会出现在测试报告和-v输出中，是定位问题的关键。

5.2 最佳实践建议

1. 为间接参数固件明确命名：固件名应能清晰反映其创建的资源或状态，如database_connection,authenticated_client,configured_browser。避免使用泛泛的fixture1,param_fixture等。

2. 使用字典作为配置载体：当需要向间接固件传递多个相关配置项时，优先使用字典而非元组。字典通过键名访问，不依赖顺序，可读性和可扩展性都更好。在固件内部，可以使用config.get(“key”, default_value)来安全地获取带默认值的配置。

3. 在固件内部做好参数验证：间接固件接收外部数据，应该对request.param进行基本的验证，比如检查必要的键是否存在，值是否在允许范围内。这可以在测试早期发现数据配置错误，而不是让错误在复杂的初始化过程中暴露。

   @pytest.fixture def validated_client(request): config = request.param required_keys = ["api_key", "base_url"] for key in required_keys: if key not in config: raise ValueError(f"配置缺失必要键 '{key}': {config}") if config.get("timeout") and not isinstance(config["timeout"], (int, float)): raise TypeError(f"timeout应为数字，但收到: {config['timeout']}") # ... 后续初始化逻辑

4. 谨慎管理固件作用域（scope）：间接固件通常执行较重的初始化操作（如启动浏览器、连接数据库）。如果它的作用域是默认的function，那么每组参数都会触发一次完整的初始化和清理，可能会很慢。根据实际情况，考虑将其作用域提升到class（一个测试类共用）或module（一个测试文件共用），但前提是不同参数组之间的状态不会相互干扰。如果固件状态会相互干扰（比如不同参数需要不同的数据库），则必须保持function作用域。

5. 利用pytest_generate_tests实现高级动态参数化：当你的测试数据需要从文件、数据库或网络动态加载时，@pytest.mark.parametrize静态装饰器就不够用了。此时，在conftest.py中定义pytest_generate_tests钩子函数是标准做法。它让你能在运行时动态决定如何参数化测试函数，功能极其强大。

6. 保持测试函数的纯粹性：测试函数应该尽可能只包含“执行操作”和“进行断言”的逻辑。所有“准备环境”和“清理环境”的工作都应委托给固件。使用indirect参数化，正是将“根据数据准备特定环境”这一复杂任务从测试函数中剥离出去的优雅手段。当你发现一个测试函数又长又复杂时，看看是否能将一部分准备工作抽离成接收间接参数的固件。

pytest的indirect参数化，初看可能觉得多了一层抽象，有些复杂。但一旦你习惯了这种“数据驱动环境”的思维模式，你就会发现它能让你的测试代码变得模块清晰、职责分明、扩展自如。它特别适合那些测试逻辑相对稳定，但测试环境和数据组合多变的场景。花点时间掌握它，对于构建中大型的、可维护的自动化测试项目来说，是一项非常值得的投资。