1. 项目概述为什么我们要从JMeter转向代码化测试如果你已经用JMeter做了一段时间的接口测试尤其是当项目迭代加快、测试用例越来越复杂时你可能会开始感到一些“力不从心”。JMeter的图形化界面上手快录制回放也方便这确实是它的巨大优势。但当你面对成百上千个用例需要参数化、断言逻辑需要精细化、测试报告需要定制化或者需要将测试流程无缝集成到CI/CD流水线中时那种在界面里点点点、拖拽拽的方式效率瓶颈就非常明显了。我团队里就有测试同学抱怨维护一个大型的JMeter脚本就像在维护一个错综复杂的“黑盒”稍微改点逻辑就得在各个控制器和元件之间来回跳转版本管理更是头疼。这正是我决定带领团队探索从JMeter过渡到VS Code pytest这套技术栈的核心原因。这不是说JMeter不好而是我们的测试需求进化了。我们需要的是更灵活、更可编程、更易维护和更易集成的自动化解决方案。pytest作为Python领域最主流的测试框架之一以其简洁的语法、强大的Fixture机制和丰富的插件生态完美契合了接口自动化测试对结构化和可扩展性的要求。而VS Code凭借其轻量、高效以及对Python和测试的顶级支持通过插件成为了编写和管理这些测试代码的绝佳编辑器。简单来说这次过渡的核心目标是将测试逻辑从“配置”转变为“代码”。这意味着我们的测试用例将是一行行清晰的Python函数断言是明确的逻辑判断数据驱动可以通过读取外部文件或数据库轻松实现而整个测试套件的组织、运行和报告生成都将通过命令和配置文件来管理。这对于测试开发工程师、希望提升技术深度的功能测试人员以及任何需要构建健壮、可持续集成接口测试体系的团队来说都是一个值得投入的方向。2. 核心思路与框架选型为什么是pytest而不是unittest或其他当我们决定用代码来做接口自动化时第一个问题就是选哪个框架Python世界里unittest是标准库pytest是第三方但已成为事实标准还有nose2等。我选择pytest是基于以下几个在实战中反复被验证的关键考量2.1 极简的用例编写语法在unittest里你必须定义一个继承unittest.TestCase的类并且每个测试方法都要以test_开头。pytest则灵活得多它既支持这种类的方式也支持简单的函数式。一个最简单的pytest测试函数长这样def test_get_user_info(): response requests.get(https://api.example.com/user/1) assert response.status_code 200 assert response.json()[username] testuser没有类的束缚直观易懂。对于接口测试这种通常以单个请求为单位的场景函数式写法往往更简洁。2.2 强大的Fixture机制这是pytest的“杀手锏”也是它比unittest更适合接口自动化的核心。Fixture可以理解为测试的“脚手架”或“依赖注入”。比如每个接口测试可能都需要一个已登录的会话token。在unittest里你可能要在setUp方法里重复获取。而在pytest里你可以定义一个session_fixtureimport pytest import requests pytest.fixture(scopesession) def auth_token(): # 模拟登录获取token这个操作在整个测试会话中只执行一次 login_resp requests.post(https://api.example.com/login, json{user: admin, pwd: 123}) token login_resp.json()[data][token] yield token # 将token提供给测试用例 # 如果需要可以在这里定义清理动作比如注销 print(测试会话结束)然后在测试用例中直接使用def test_create_item(auth_token): # 将fixture作为参数传入pytest会自动注入 headers {Authorization: fBearer {auth_token}} response requests.post(https://api.example.com/items, json{name: new item}, headersheaders) assert response.status_code 201Fixture的scope参数function,class,module,session让你能精准控制资源的生命周期和复用程度极大提升了测试效率和资源管理能力。2.3 丰富的插件生态与Allure报告这是从JMeter过渡过来后在测试报告方面一个巨大的体验提升。JMeter的报告虽然全面但美观度和定制性一般。pytest可以轻松集成pytest-html生成HTML报告更强大的是集成allure-pytest生成Allure报告。Allure报告不仅颜值高还能清晰展示测试层级、步骤、附件如请求/响应日志、历史趋势等。 安装和使用非常简单pip install allure-pytest # 运行测试并生成Allure结果数据 pytest --alluredir./allure-results # 生成并打开HTML报告 allure serve ./allure-results生成的报告专业程度是向开发、产品经理展示测试结果的有力工具。2.4 参数化测试的便捷性接口测试经常需要对同一接口用多组不同数据进行测试。pytest的pytest.mark.parametrize装饰器让数据驱动测试变得异常优雅。import pytest test_data [ (page1size10, 200, 10), # (查询参数 期望状态码 期望返回数据条数) (page0size10, 400, None), (page1size1000, 400, None), # 超出最大size限制 ] pytest.mark.parametrize(query_params, expected_status, expected_count, test_data) def test_get_item_list(query_params, expected_status, expected_count): response requests.get(fhttps://api.example.com/items?{query_params}) assert response.status_code expected_status if expected_status 200: assert len(response.json()[items]) expected_count这比在JMeter里用CSV Data Set Config或者循环控制器直观和易维护得多。2.5 更好的失败信息与调试体验当断言失败时pytest会给出非常详细的错误信息直接告诉你期望值和实际值是什么。结合VS Code的调试功能你可以在测试代码中设置断点逐行执行查看变量状态这对于排查复杂的接口逻辑问题至关重要而这在JMeter的界面调试中是很难实现的。注意选择pytest并不意味着完全抛弃unittest。如果你的项目已有大量unittest用例pytest可以直接运行它们这是一个平滑过渡的利好。但新项目我强烈建议直接从pytest开始。3. 环境搭建与项目结构设计从零开始搭建一个清晰、可维护的pytest接口自动化项目是成功过渡的第一步。一个好的项目结构能让你和你的团队在未来几年都受益。3.1 基础环境准备首先确保你的系统已安装Python建议3.8及以上版本。然后我们通过pip安装核心包。我建议使用虚拟环境venv或conda来隔离项目依赖。# 创建并激活虚拟环境以venv为例 python -m venv venv # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate # 安装核心依赖 pip install pytest requests pytest-html allure-pytest # 根据需要安装其他库如pytest-xdist并行测试, pytest-rerunfailures失败重试requests库是Python中进行HTTP请求的事实标准简单易用。当然你也可以根据团队喜好选择httpx支持异步等。3.2 VS Code配置与必备插件VS Code需要安装几个关键插件来提升我们的开发体验Python (Microsoft)提供Python语言支持、智能提示、调试、测试运行器等。Pytest专为pytest框架提供的增强支持可以在侧边栏的测试视图中直接发现、运行、调试测试用例。Allure方便在VS Code内预览Allure报告。安装完Python插件后在项目根目录下创建或打开.vscode/settings.json文件进行一些关键配置{ python.testing.pytestEnabled: true, python.testing.unittestEnabled: false, python.testing.cwd: ${workspaceFolder}, python.testing.pytestArgs: [ -v, // 详细输出 --tbshort, // 简短的错误回溯 --alluredir./allure-results // 指定Allure结果目录 ], [python]: { editor.formatOnSave: true, editor.defaultFormatter: ms-python.black-formatter } }这样配置后你可以在VS Code的测试视图中直接看到所有测试用例并一键运行或调试单个用例、单个文件或整个项目。3.3 设计清晰的项目目录结构一个混乱的目录是项目腐化的开始。我推荐以下结构它分离了关注点便于扩展和维护。project_root/ ├── .vscode/ # VS Code 配置 ├── venv/ # Python虚拟环境.gitignore忽略 ├── requirements.txt # 项目依赖清单 ├── pytest.ini # pytest配置文件 ├── conftest.py # 全局Fixture和钩子函数定义 ├── common/ # 公共模块 │ ├── __init__.py │ ├── logger.py # 日志配置 │ ├── config.py # 环境配置如不同环境的base_url │ └── http_client.py # 封装的HTTP请求客户端 ├── test_data/ # 测试数据文件 │ ├── api_data.yaml # YAML格式的测试数据 │ └── user_data.json ├── test_cases/ # 测试用例目录 │ ├── __init__.py │ ├── test_user_api.py # 用户相关接口测试 │ └── test_product_api.py # 产品相关接口测试 └── reports/ # 测试报告目录.gitignore忽略 ├── html/ └── allure-results/3.4 核心配置文件详解pytest.ini: 这是pytest的主配置文件可以定义默认的运行参数。[pytest] # 指定测试文件的位置和命名模式 testpaths test_cases python_files test_*.py python_classes Test* python_functions test_* # 添加命令行默认参数 addopts -v --strict-markers --tbshort --htmlreports/html/report.html --self-contained-html # 注册自定义的mark标记用于分类运行测试 markers smoke: 冒烟测试用例 regression: 回归测试用例 slow: 运行缓慢的测试conftest.py: 这是一个特殊的文件pytest会自动发现它。这里适合放置项目级别的Fixture和钩子函数。import pytest from common.config import Config from common.http_client import HttpClient import logging pytest.fixture(scopesession) def config(): 读取配置整个测试会话只加载一次 return Config() pytest.fixture(scopesession) def api_client(config): 创建一个全局的HTTP客户端会话复用连接提升性能 client HttpClient(base_urlconfig.BASE_URL) yield client client.close() # 会话结束关闭连接 pytest.fixture(scopefunction) def logger(): 为每个测试用例提供独立的日志记录器 log logging.getLogger(__name__) # 配置日志格式、级别、输出位置... yield log # 钩子函数示例在每个测试用例失败时自动截图如果结合UI测试或记录额外信息 def pytest_runtest_makereport(item, call): if call.when call and call.failed: # 这里可以添加失败时的自定义操作比如记录请求响应到Allure passcommon/config.py: 管理环境配置避免硬编码。import os from dotenv import load_dotenv # 可以使用python-dotenv从.env文件加载敏感信息 load_dotenv() class Config: def __init__(self, envtest): self.env env if env test: self.BASE_URL https://test-api.example.com elif env prod: self.BASE_URL https://api.example.com # 可以从环境变量读取敏感信息 self.ADMIN_USER os.getenv(TEST_ADMIN_USER) self.ADMIN_PWD os.getenv(TEST_ADMIN_PWD)common/http_client.py: 对requests.Session进行封装加入重试、通用头、日志、统一的响应处理等。import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry import logging class HttpClient: def __init__(self, base_url, timeout10): self.base_url base_url self.session requests.Session() # 设置重试策略 retry_strategy Retry( total3, backoff_factor1, status_forcelist[429, 500, 502, 503, 504], ) adapter HTTPAdapter(max_retriesretry_strategy) self.session.mount(http://, adapter) self.session.mount(https://, adapter) # 设置通用请求头 self.session.headers.update({ Content-Type: application/json, User-Agent: Pytest-API-Test/1.0 }) self.timeout timeout self.logger logging.getLogger(__name__) def request(self, method, endpoint, **kwargs): url f{self.base_url}{endpoint} self.logger.info(fRequest: {method} {url}) # 可以在这里添加请求签名、加密等逻辑 resp self.session.request(method, url, timeoutself.timeout, **kwargs) self.logger.info(fResponse Status: {resp.status_code}) self.logger.debug(fResponse Body: {resp.text}) # 可以在这里添加统一的响应断言或异常处理 resp.raise_for_status() # 非2xx状态码会抛出异常 return resp def get(self, endpoint, paramsNone, **kwargs): return self.request(GET, endpoint, paramsparams, **kwargs) def post(self, endpoint, dataNone, jsonNone, **kwargs): return self.request(POST, endpoint, datadata, jsonjson, **kwargs) # ... 类似地实现 put, delete, patch 等方法 def close(self): self.session.close()实操心得在项目初期就花时间搭建好这个基础框架至关重要。conftest.py和封装的HttpClient是核心它们将大量重复代码如会话管理、重试、日志抽离出来让后续的测试用例编写者可以更专注于业务逻辑本身。这比在JMeter中复制粘贴HTTP请求采样器要优雅和高效得多。4. 测试用例编写实战从简单到复杂有了稳固的基础设施我们现在可以开始编写真正的测试用例了。你会发现用代码表达测试逻辑比在JMeter里配置元件要直观和强大得多。4.1 一个完整的简单用例假设我们要测试一个获取用户信息的GET接口。 在test_cases/test_user_api.py中import pytest class TestUserApi: 用户相关接口测试类 def test_get_user_by_id_success(self, api_client): 测试成功获取指定ID的用户信息 # 1. 准备测试数据 user_id 1 # 2. 发起请求 response api_client.get(f/users/{user_id}) # 3. 断言响应 assert response.status_code 200 data response.json() assert data[id] user_id assert username in data assert email in data # 可以添加更多业务逻辑断言比如字段类型 assert isinstance(data[username], str) def test_get_user_not_found(self, api_client): 测试获取不存在的用户应返回404 response api_client.get(/users/99999) # 断言状态码为404 assert response.status_code 404 # 断言错误信息符合预期 error_data response.json() assert error_data[code] USER_NOT_FOUND assert message in error_data你看测试逻辑非常清晰准备数据 - 执行操作 - 验证结果。api_client这个Fixture为我们处理了底层的HTTP会话和基础URL。4.2 使用Fixture处理前置与后置操作对于需要登录态的接口我们可以利用Fixture。在conftest.py或当前测试文件定义一个auth_tokenFixture。import pytest pytest.fixture def auth_token(api_client): 获取认证token作用域为function级别 login_data {username: testuser, password: securepass} resp api_client.post(/auth/login, jsonlogin_data) assert resp.status_code 200 token resp.json()[access_token] return token def test_update_user_profile(self, api_client, auth_token): 测试更新用户个人信息需要登录 headers {Authorization: fBearer {auth_token}} update_data {nickname: 新的昵称} response api_client.put(/user/profile, jsonupdate_data, headersheaders) assert response.status_code 200 # 验证更新是否生效可以再调用一次查询接口 profile_resp api_client.get(/user/profile, headersheaders) assert profile_resp.json()[nickname] 新的昵称4.3 复杂场景参数化与数据驱动当需要测试接口在不同输入下的行为时参数化大显身手。我们可以将测试数据放在Python数据结构、JSON或YAML文件中。使用pytest.mark.parametrize:import pytest pytest.mark.parametrize(username, password, expected_code, expected_msg, [ (valid_user, valid_pass, 200, 登录成功), (invalid_user, valid_pass, 401, 用户名或密码错误), (valid_user, , 400, 密码不能为空), (, valid_pass, 400, 用户名不能为空), ]) def test_login_parameterized(self, api_client, username, password, expected_code, expected_msg): 参数化测试登录接口的各种边界情况 resp api_client.post(/auth/login, json{username: username, password: password}) assert resp.status_code expected_code if expected_code ! 200: assert resp.json()[message] expected_msg else: assert access_token in resp.json()从外部文件如YAML加载数据:test_data/login_data.yaml:- case: 正常登录 username: test_user password: 123456 expected: status_code: 200 has_token: true - case: 密码错误 username: test_user password: wrong expected: status_code: 401 message: 用户名或密码错误在测试文件中读取import yaml import pytest def load_login_data(): with open(test_data/login_data.yaml, r, encodingutf-8) as f: return yaml.safe_load(f) pytest.mark.parametrize(test_data, load_login_data()) def test_login_with_yaml(self, api_client, test_data): resp api_client.post(/auth/login, json{ username: test_data[username], password: test_data[password] }) expected test_data[expected] assert resp.status_code expected[status_code] if expected.get(has_token): assert access_token in resp.json() elif expected.get(message): assert resp.json()[message] expected[message]这种方式将测试数据与测试逻辑彻底分离维护数据就像维护一个清单非常方便。4.4 处理依赖用例与测试顺序在接口测试中经常有场景B接口的测试依赖于A接口创建的数据。pytest本身不保证测试顺序但我们可以通过Fixture的依赖关系来实现。import pytest pytest.fixture def created_user_id(api_client, auth_token): 创建一个新用户并返回其ID。这个Fixture又依赖于auth_token。 headers {Authorization: fBearer {auth_token}} user_data {name: Fixture创建的用户, email: ftest_{pytest.current_time}example.com} resp api_client.post(/admin/users, jsonuser_data, headersheaders) user_id resp.json()[id] yield user_id # 后置清理测试结束后删除这个用户 api_client.delete(f/admin/users/{user_id}, headersheaders) def test_update_and_query_user(self, api_client, auth_token, created_user_id): 测试更新用户然后查询验证。依赖于created_user_id这个Fixture。 headers {Authorization: fBearer {auth_token}} # 更新用户 update_resp api_client.put(f/admin/users/{created_user_id}, json{name: 更新后的名字}, headersheaders) assert update_resp.status_code 200 # 查询用户验证 query_resp api_client.get(f/admin/users/{created_user_id}, headersheaders) assert query_resp.json()[name] 更新后的名字Fixture的yield关键字非常关键yield之前的代码是前置设置yield返回的值是注入给测试用例的yield之后的代码是后置清理。这确保了测试环境的干净。注意事项虽然可以通过Fixture依赖构建测试流但应尽量保持每个测试用例的独立性。过度复杂的依赖链会让测试变得脆弱且难以调试。对于强流程性的业务如“下单-支付-发货”可以将其作为一个完整的“场景测试”放在一个测试函数里或者使用pytest-order插件来显式控制顺序但这通常是最后的选择。5. 高级技巧与最佳实践当你的测试套件逐渐庞大你会需要一些更高级的功能和约定来保证其可维护性和效率。5.1 测试标记Mark与选择性运行使用pytest.mark装饰器给测试用例打标签可以灵活地选择运行哪些测试。import pytest pytest.mark.smoke # 冒烟测试标记 def test_api_health_check(api_client): response api_client.get(/health) assert response.status_code 200 pytest.mark.regression # 回归测试标记 pytest.mark.slow # 标记为运行缓慢的测试 def test_export_large_report(api_client, auth_token): # 这是一个耗时很长的导出报表测试 pass pytest.mark.skip(reason该接口尚未开发完成) def test_new_feature_api(): pass pytest.mark.xfail(reason已知Bug版本v2.1修复) def test_buggy_endpoint(): # 预期会失败 assert some_operation() expected_result运行命令# 只运行冒烟测试 pytest -m smoke # 运行除了慢速测试外的所有测试 pytest -m not slow # 运行回归测试并且忽略已知会失败的测试 pytest -m regression --runxfail5.2 并行测试加速当你有成千上万个测试用例时串行运行会非常耗时。pytest-xdist插件可以让你轻松实现并行测试。pip install pytest-xdist # 使用2个worker并行运行 pytest -n 2 # 自动检测CPU核心数 pytest -n auto并行测试时需要注意测试用例之间的独立性避免共享状态如操作同一个测试数据库的同一行记录导致竞态条件。通常可以通过为每个测试生成唯一的数据如使用随机用户名、邮箱来解决。5.3 失败重试机制网络波动或服务暂时不稳定可能导致测试偶发性失败。pytest-rerunfailures插件可以自动重试失败的测试。pip install pytest-rerunfailures # 最多重试3次每次失败后等待1秒 pytest --reruns 3 --reruns-delay 1这个功能对于稳定测试流水线非常有用但要谨慎使用避免掩盖真正的代码缺陷。5.4 生成丰富的测试报告我们已经提到了Allure报告。为了让报告更有价值我们可以在测试中添加详细的步骤和附件。import allure import json def test_complex_workflow_with_allure(api_client): 一个包含多个步骤的复杂流程测试并使用Allure装饰器增强报告 with allure.step(1. 用户登录): token login(api_client) allure.attach(json.dumps({token: token}), name登录响应Token, attachment_typeallure.attachment_type.JSON) with allure.step(2. 创建订单): order_id create_order(api_client, token) allure.attach(str(order_id), name创建的订单ID, attachment_typeallure.attachment_type.TEXT) with allure.step(3. 查询订单状态): status get_order_status(api_client, token, order_id) assert status PAID # 可以将整个响应体作为附件 # allure.attach(response.text, name订单查询响应, attachment_typeallure.attachment_type.JSON) with allure.step(4. 清理测试数据): delete_order(api_client, token, order_id)这样生成的Allure报告会呈现出清晰的测试步骤树并且可以查看每个步骤的请求/响应详情对于排查问题极其有帮助。5.5 测试数据的管理与清理这是一个容易被忽视但至关重要的问题。自动化测试不应该污染线上或共享测试环境的数据。造数据尽量使用API或专门的测试数据构造服务来创建测试所需的数据而不是直接操作数据库。数据独立性每个测试用例使用唯一标识的数据如ftest_user_{uuid.uuid4().hex[:8]}避免冲突。数据清理务必在Fixture的yield之后或测试用例的最后清理掉本次测试创建的数据。对于无法通过API删除的数据或为了提升性能可以考虑定期运行一个数据库清理脚本或者使用可以快速回滚的测试数据库如Docker容器。6. 从JMeter脚本迁移的策略与常见问题对于已有的JMeter脚本完全重写可能工作量巨大。我建议采用渐进式迁移策略6.1 策略先新后旧重点优先为新功能编写pytest用例所有新开发或改动的接口直接使用新的pytest框架编写自动化测试。识别核心场景迁移分析现有JMeter脚本找出核心业务流、高频执行的冒烟测试用例优先将其迁移到pytest。一个复杂的JMeter脚本可能对应多个pytest测试函数或类。逐步替换随着时间推移当某个模块的pytest覆盖率达到一定程度并且运行稳定后可以考虑将对应的JMeter脚本归档或下线。6.2 JMeter元件到pytest代码的映射参考JMeter 元件/概念pytest / Python 对应实现说明HTTP请求采样器requests库的get,post,put,delete方法核心请求动作。HTTP信息头管理器在requests请求的headers参数中传递字典如headers{Content-Type: application/json}。参数化CSV Data Set Configpytest.mark.parametrize装饰器或从文件CSV, JSON, YAML读取数据pytest的参数化更灵活数据与代码分离更清晰。正则表达式提取器/JSON提取器从response.json()返回的Python字典中直接提取或使用jsonpath库。Python处理JSON是原生优势非常方便。断言响应断言JSON断言Python的assert语句可结合pytest-assume进行软断言。断言逻辑可以用任何Python代码表达能力远超JMeter。前置处理器/后置处理器pytest的Fixture在yield前后分别执行设置和清理代码。Fixture的scope机制可以精确控制生命周期。逻辑控制器循环IfPython的for循环和if语句。用编程语言实现逻辑控制是降维打击。跨线程组传参使用Fixture的session或modulescope来共享状态或使用外部存储如小文件、环境变量。更清晰避免了JMeter中属性传递的隐晦性。定时器Python的time.sleep()或更复杂的调度如schedule库。简单等待直接用sleep复杂场景用专业库。监听器查看结果树聚合报告pytest-html,allure-pytest生成的HTML/Allure报告。报告更美观、信息更丰富、可定制性更强。6.3 迁移过程中的典型问题与解决问题一JMeter脚本中有很多复杂的“后置处理器”用于提取变量并在后续请求中使用。解决在pytest中这通常通过将提取逻辑写在Fixture或辅助函数中并将提取的值作为返回值或存储在某个对象如一个简单的类实例中供后续测试用例使用。逻辑更清晰都在代码里可见。问题二JMeter可以很方便地做性能测试pytest可以吗解决pytest本身不是性能测试工具。对于接口性能测试JMeter、Locust、k6等是更专业的选择。pytest接口自动化主要聚焦于功能正确性和集成测试。不过你可以用pytest编写性能测试的准备和校验脚本如准备测试数据断言性能测试后的数据一致性然后用专门的工具执行压测。问题三用例标题和参数化数据组合时标题显示异常或被挤换行。解决这是使用pytest.mark.parametrize时的一个常见显示问题。当参数值很长时测试报告中的用例名会很难看。可以通过ids参数来自定义每个参数组合的显示名称。pytest.mark.parametrize( a, b, expected, [(1, 2, 3), (4, 5, 9)], ids[small numbers, medium numbers] # 自定义显示名称 ) def test_add(a, b, expected): assert a b expected在Allure或HTML报告中用例名就会显示为test_add[small numbers]和test_add[medium numbers]清晰易懂。问题四如何管理不同环境的配置测试、预发、生产解决这是我们前面Config类的作用。可以通过命令行参数、环境变量或配置文件来指定当前运行的环境。例如# 通过环境变量 export TEST_ENVstaging pytest # 或通过自定义pytest命令行选项需要在conftest.py中添加hook pytest --envproduction在conftest.py中读取这个配置并传递给Config类从而动态切换BASE_URL和其他配置。从JMeter过渡到VS Code pytest本质上是从“工具使用者”到“测试代码开发者”的思维转变。初期可能会觉得写代码比拖拽元件麻烦但一旦你习惯了这种模式并构建起自己的测试框架你会发现它在灵活性、可维护性、可集成性和表达能力上的巨大优势。这个转变不仅能提升你的测试效率更能极大地提升你的技术能力和在团队中的价值。
