1. 项目概述为什么要把用例塞进一个“类”里刚接触 pytest 那会儿我习惯把每个测试函数都扔在一个文件里简单直接。但随着项目变大测试文件膨胀到几百行找某个功能的测试用例就像大海捞针维护起来更是噩梦。直到我开始把相关的测试用例组织到一个类Class里整个世界都清爽了。这不仅仅是代码结构上的变化更是测试思维从“脚本化”向“工程化”迈进的关键一步。简单说用类来组织用例核心是逻辑聚合和资源共享。比如你要测试一个用户管理模块所有关于“用户登录”、“用户注册”、“用户信息修改”的测试天然就属于“用户”这个业务范畴。把它们放在一个TestUser类里逻辑上顺理成章。更重要的是pytest 的类机制提供了setup和teardown这样的脚手架让你能在类级别共享测试环境比如初始化一个数据库连接、创建一个临时测试用户这个资源对所有类内的测试方法都可用写起来省事跑起来也更高效。所以这个“快速入门”的目标很明确不是教你 pytest 的所有细节而是让你最快掌握“用类组织用例”这个核心模式。一旦掌握你就能立刻写出结构清晰、易于维护的测试代码告别混乱的测试脚本。无论你是测试新手还是从 unittest 等框架转过来的老手这套方法都能让你在 pytest 的世界里快速上手构建稳健的自动化测试体系。2. 核心思路从“散装函数”到“模块化类”的转变2.1 函数式测试的局限性在纯函数式的写法里一个测试文件可能长这样# test_user_loose.py def test_login_with_valid_credentials(): # 初始化用户、准备数据、调用接口、断言... pass def test_login_with_wrong_password(): # 又是一套初始化、准备、调用、断言... pass def test_register_new_user(): # 再来一套... pass这种写法的问题显而易见代码重复每个测试函数可能都要先创建一个用户对象或连接数据库这些准备和清理的代码被不断复制粘贴。关注点分散测试逻辑断言和测试夹具fixture如初始化数据混杂在一起可读性差。维护困难当公共的初始化逻辑需要修改时比如数据库连接方式变了你必须修改每一个测试函数极易出错。缺乏结构成百上千个测试函数平铺在一个文件或几个文件里难以快速定位某个功能模块的所有测试。2.2 类的优势与pytest的实现类的引入正是为了解决上述问题。在 pytest 中一个测试类本质上是一个测试用例的容器它提供了两个维度的组织能力逻辑维度通过类名如TestUser清晰地宣告“这个类里的所有测试都是关于‘用户’这个主题的”。这符合人类的认知习惯便于理解和检索。资源维度通过类级别的setup_method/teardown_method或更强大的classmethod装饰器你可以定义一些“类级别”的夹具它们在整个类的生命周期内只执行一次并被所有测试方法共享。pytest 对测试类的识别非常智能任何以Test开头的类且类名不以__双下划线结尾其内部任何以test_开头的方法都会被自动收集为测试用例。这个约定大于配置的规则让代码既简洁又规范。2.3 设计模式如何规划你的测试类不要为了用类而用类。一个设计良好的测试类应该遵循“高内聚、低耦合”的原则高内聚一个类应该只负责测试一个明确的业务模块或一个具体的类。例如TestUserAPI、TestShoppingCart、TestDataValidator。低耦合类与类之间的依赖应尽可能少。避免一个测试类的setup需要依赖另一个测试类的执行结果。依赖应通过 pytest 的 fixture 机制在更抽象的层面如会话级或模块级解决。一个常见的实践是按系统模块或页面对象Page Object来划分测试类。在 Web 自动化中你可能有一个TestLoginPage类里面包含了验证登录页面各种交互的所有测试方法。3. 从零开始创建你的第一个测试类3.1 基础结构搭建让我们从一个最简单的例子开始。假设我们要测试一个简单的计算器Calculator类这里我们先模拟这个类。首先创建被测对象通常在实际项目中是导入的# calculator.py class Calculator: def add(self, a, b): return a b def subtract(self, a, b): return a - b def multiply(self, a, b): return a * b def divide(self, a, b): if b 0: raise ValueError(Cannot divide by zero!) return a / b接着创建测试文件并使用类来组织测试# test_calculator.py import pytest from calculator import Calculator class TestCalculator: 测试Calculator类的所有功能 # 在每个测试方法开始前执行 def setup_method(self): print(\n初始化Calculator实例...) self.calc Calculator() # 在每个测试方法结束后执行 def teardown_method(self): print(清理资源...) # 这里可以添加清理代码比如关闭文件、删除临时数据等 del self.calc def test_add(self): 测试加法功能 result self.calc.add(2, 3) assert result 5, f2 3 应该等于 5但得到 {result} def test_subtract(self): 测试减法功能 result self.calc.subtract(10, 4) assert result 6 def test_multiply(self): 测试乘法功能 result self.calc.multiply(7, 8) assert result 56 def test_divide_normal(self): 测试正常的除法功能 result self.calc.divide(9, 3) assert result 3 def test_divide_by_zero(self): 测试除零异常 with pytest.raises(ValueError, matchCannot divide by zero!): self.calc.divide(5, 0)运行测试在终端执行pytest test_calculator.py -v。你会看到 pytest 识别到了TestCalculator类并运行了里面的5个test_方法。-v参数让输出更详细可以看到每个测试方法的名字和状态。注意setup_method和teardown_method是实例方法它们会在每个测试方法执行前后被调用。这意味着对于上面的例子Calculator实例会被创建和销毁5次。这适用于测试方法间需要完全隔离的场景。3.2 类级别夹具更高效的资源共享如果初始化操作非常耗时比如建立数据库连接、启动浏览器为每个测试方法都做一次就太浪费了。这时我们可以使用类级别的setup_class和teardown_class。# test_calculator_with_class_fixture.py import pytest from calculator import Calculator class TestCalculatorWithClassFixture: 使用类级别夹具的Calculator测试 classmethod def setup_class(cls): 在整个类开始执行前只运行一次 print(\n 开始执行 TestCalculatorWithClassFixture 类 ) # 注意这里创建的是类属性所有实例方法共享 cls.calc Calculator() # 假设这里有一个耗时的初始化比如连接测试数据库 cls.db_connection 模拟的数据库连接 print(f类级别初始化完成。数据库连接: {cls.db_connection}) classmethod def teardown_class(cls): 在整个类执行结束后只运行一次 print(\n 结束执行 TestCalculatorWithClassFixture 类 ) # 关闭数据库连接等清理工作 cls.db_connection None print(类级别资源清理完成。) def setup_method(self): 每个测试方法前执行可以访问类属性 print(f\n准备执行测试方法使用共享的计算器: {self.calc}) def test_add(self): # 可以直接使用 self.calc它是在 setup_class 中创建的类属性 assert self.calc.add(1, 2) 3 def test_multiply(self): # 所有测试方法共享同一个 self.calc 实例 assert self.calc.multiply(3, 4) 12 # 也可以访问类级别的资源 print(f测试中使用的数据库连接: {self.db_connection})运行这个测试你会发现setup_class和teardown_class的打印语句只出现了一次而setup_method的打印出现了两次。这证明了类级别夹具在资源共享上的效率优势。实操心得选择setup_method还是setup_class取决于你的测试需求。需要绝对隔离每个测试方法必须拥有全新的、独立的环境例如测试会修改对象内部状态。用setup_method。追求执行效率初始化成本高且测试方法不会相互干扰例如只读操作或操作可回滚。用setup_class。混合使用非常常见。在setup_class里建立数据库连接池在setup_method里从池中获取连接并开始一个事务在teardown_method里回滚事务在teardown_class里关闭连接池。这样既高效又隔离。4. 进阶技巧让测试类更强大、更清晰4.1 使用 pytest.fixture 替代 setup/teardown虽然setup_*和teardown_*方法直观但 pytest 更推荐使用其核心特性——fixture。Fixture 功能更强大、更灵活是 pytest 的精华所在。我们可以在类里定义和使用 fixture。# test_calculator_with_fixture.py import pytest from calculator import Calculator class TestCalculatorWithFixture: 在类内部使用fixture # 定义一个作用于类级别的fixture pytest.fixture(scopeclass) def shared_calculator(self): 提供一个共享的Calculator实例整个类只初始化一次 print(\n[Fixture] 创建共享Calculator...) calc Calculator() yield calc # 将实例提供给测试用例 print(\n[Fixture] 清理共享Calculator...) # yield 之后的代码是清理部分类似于 teardown_class # 定义一个作用于每个方法的fixture pytest.fixture def fresh_data(self): 为每个测试方法提供一份新的测试数据 print([Fixture] 生成新测试数据...) return {a: 10, b: 5} # 测试方法通过参数来“请求”所需的fixture def test_add_with_fixture(self, shared_calculator, fresh_data): result shared_calculator.add(fresh_data[a], fresh_data[b]) assert result 15 def test_subtract_with_fixture(self, shared_calculator, fresh_data): # shared_calculator 是同一个实例fresh_data 是新的副本 result shared_calculator.subtract(fresh_data[a], fresh_data[b]) assert result 5使用 fixture 的好处依赖注入测试方法需要什么资源就在参数里声明什么。代码意图更清晰。作用域灵活通过scope参数可以轻松控制 fixture 的生命周期function(默认),class,module,session。可复用性Fixture 可以定义在conftest.py文件中供多个测试类和模块使用这是组织大型测试项目的基石。更清晰的清理逻辑使用yield模式清理代码紧跟在生成代码之后结构更好。4.2 参数化测试一个方法多组数据当你想用多组输入数据测试同一个功能时pytest.mark.parametrize装饰器是绝佳工具。它可以应用在类方法上。# test_calculator_parametrize.py import pytest from calculator import Calculator class TestCalculatorParametrized: pytest.fixture(scopeclass) def calc(self): return Calculator() # 参数化加法测试 pytest.mark.parametrize(a, b, expected, [ (1, 2, 3), (0, 0, 0), (-1, 1, 0), (100, -50, 50), ]) def test_add_various(self, calc, a, b, expected): assert calc.add(a, b) expected # 参数化除法测试包括正常和异常情况 pytest.mark.parametrize(a, b, expected, [ (10, 2, 5), (9, 3, 3), (0, 5, 0), ]) def test_divide_normal_various(self, calc, a, b, expected): assert calc.divide(a, b) expected pytest.mark.parametrize(a, b, expected_exception, [ (5, 0, ValueError), (-10, 0, ValueError), ]) def test_divide_by_zero_various(self, calc, a, b, expected_exception): with pytest.raises(expected_exception): calc.divide(a, b)运行后pytest 会将每个参数组合视为一个独立的测试用例。这样你只用写一个测试方法就覆盖了多种边界情况和正常情况大大减少了代码量提高了测试覆盖率。4.3 测试类的继承与组合面向对象的优势在测试中也能体现。你可以创建一个测试基类把通用的夹具和工具方法放进去然后让具体的测试类继承它。# base_test.py import pytest class BaseAPITest: 所有API测试的基类 pytest.fixture(scopeclass) def api_client(self): # 模拟一个需要认证的API客户端初始化 client {token: fake_token_123, base_url: https://api.example.com} print(f\n初始化API客户端: {client}) yield client print(\n登出并清理API客户端) pytest.fixture def common_headers(self, api_client): 生成通用的请求头 return { Authorization: fBearer {api_client[token]}, Content-Type: application/json } # test_user_api.py from base_test import BaseAPITest class TestUserAPI(BaseAPITest): 用户相关API测试 def test_get_user_profile(self, api_client, common_headers): # 可以直接使用父类的fixture print(f使用客户端 {api_client} 和请求头 {common_headers} 获取用户资料) # 这里应该是实际的请求断言代码例如 # response requests.get(f{api_client[base_url]}/user/profile, headerscommon_headers) # assert response.status_code 200 assert True # 模拟断言成功 def test_update_user_email(self, api_client, common_headers): print(f使用客户端 {api_client} 和请求头 {common_headers} 更新用户邮箱) assert True # test_product_api.py from base_test import BaseAPITest class TestProductAPI(BaseAPITest): 商品相关API测试 def test_list_products(self, api_client, common_headers): print(f使用客户端 {api_client} 和请求头 {common_headers} 列出商品) assert True通过继承TestUserAPI和TestProductAPI都自动获得了api_client和common_headers这两个 fixture避免了重复代码保证了测试环境的一致性。5. 实战组织一个完整的Web UI测试类让我们看一个更贴近实战的例子模拟一个使用 Selenium 的 Web 登录测试。我们将使用 Page Object Model (POM) 模式并将测试用例组织在类中。首先假设我们有简单的页面对象# pages/login_page.py class LoginPage: def __init__(self, driver): self.driver driver self.username_input (id, username) self.password_input (id, password) self.submit_button (id, submit) self.error_message (id, error-message) def enter_username(self, username): # 实际代码会调用 self.driver.find_element(...).send_keys(username) print(f在用户名输入框输入: {username}) def enter_password(self, password): print(f在密码输入框输入: {password}) def click_submit(self): print(点击登录按钮) def get_error_message(self): # 实际代码会返回 self.driver.find_element(...).text return 模拟的错误信息用户名或密码错误然后是组织在类中的测试# tests/test_login.py import pytest # 假设我们已经有了一个配置好的WebDriver fixture定义在 conftest.py 中 # from conftest import driver from pages.login_page import LoginPage class TestLoginFunctionality: 登录功能测试集 pytest.fixture(scopeclass) def login_page(self, driver): # 这里请求了外部的 driver fixture 为整个测试类提供一个LoginPage实例 print(\n[Class Fixture] 初始化登录页面对象...) page LoginPage(driver) # 可能还需要导航到登录页 # driver.get(https://example.com/login) yield page print(\n[Class Fixture] 登录测试类结束。) # 可能执行一些登出或清理操作 def test_successful_login(self, login_page): 测试使用正确凭据登录 print(\n--- 测试成功登录 ---) login_page.enter_username(valid_user) login_page.enter_password(valid_pass) login_page.click_submit() # 断言应该跳转到主页或显示登录成功消息 # assert driver.current_url https://example.com/dashboard print(断言登录成功页面跳转。) assert True def test_login_with_wrong_password(self, login_page): 测试使用错误密码登录 print(\n--- 测试密码错误 ---) login_page.enter_username(valid_user) login_page.enter_password(wrong_pass) login_page.click_submit() error_msg login_page.get_error_message() # 断言应该显示特定的错误信息 assert 用户名或密码错误 in error_msg print(f断言成功收到预期错误信息 {error_msg}) pytest.mark.parametrize(username, password, [ (, somepass), # 用户名为空 (someuser, ), # 密码为空 (, ), # 两者都为空 ]) def test_login_with_empty_credentials(self, login_page, username, password): 测试使用空凭据登录参数化 print(f\n--- 测试空凭据登录 (用户: {username}, 密码: {password}) ---) login_page.enter_username(username) login_page.enter_password(password) login_page.click_submit() # 断言前端验证应阻止提交或后端返回特定错误 # 这里简化处理 print(断言前端验证应触发或收到相应错误。) assert True # 根据实际行为修改断言这个例子展示了如何在一个类 (TestLoginFunctionality) 中使用类级别的 fixture (login_page) 来初始化页面对象所有测试方法共享。将相关的测试用例成功登录、密码错误、空凭据清晰地组织在一起。对边界情况空凭据使用参数化减少重复代码。测试方法名 (test_successful_login) 清晰地描述了测试场景。运行pytest tests/test_login.py -v -s(-s用于显示 print 输出)你可以看到结构清晰的测试执行流程。6. 常见问题与排查技巧实录在实际使用类组织用例时你肯定会遇到一些坑。下面是我踩过之后总结出来的经验。6.1 问题测试方法没被发现症状运行pytest时你的测试类或类里的方法没有被执行。排查检查命名确保类名以Test开头且不以__结尾。确保方法名以test_开头。这是 pytest 默认的发现规则。检查文件位置测试文件是否在 pytest 的搜索路径下通常当前目录及其子目录都会被搜索。你可以通过pytest --collect-only命令查看 pytest 发现了哪些测试项。检查__init__.py如果你的测试文件在包里确保包目录下有一个__init__.py文件可以是空的这样 pytest 才能将其识别为可导入的模块。6.2 问题类级别的 fixture 状态污染了测试症状第一个测试方法修改了类属性如self.calc.some_state changed导致后续测试方法运行结果不符合预期。解决使用setup_method如果测试间需要完全隔离就不要用setup_class或scopeclass的 fixture改用setup_method为每个测试创建新实例。设计可重置的对象确保被测对象有重置状态的方法并在每个setup_method中调用它。使用autousefixture 进行清理可以定义一个autouseTrue的 fixture在每次测试后自动重置状态。class TestStateful: pytest.fixture(autouseTrue) def reset_state(self): # 测试前保存状态或不做操作 yield # 测试后自动执行清理 self.shared_obj.reset_to_initial_state()6.3 问题setup_class中初始化失败导致整个类跳过症状setup_class方法里抛出了异常比如数据库连不上然后这个类下的所有测试都被标记为ERROR或跳过一个都没执行。解决使用更灵活的 fixture考虑将关键的初始化移到pytest.fixture中并使用scopesession或scopemodule。这样即使某个 fixture 失败也只影响依赖它的测试而不是整个类或模块。添加容错或跳过逻辑在setup_class中使用pytest.skip()或pytest.xfail()来优雅地处理无法初始化的场景并给出明确原因。classmethod def setup_class(cls): try: cls.db connect_to_database() except ConnectionError as e: pytest.skip(f无法连接测试数据库: {e})6.4 问题如何只运行某个特定测试类或类里的某个方法技巧运行单个类pytest path/to/test_file.py::TestClassName运行单个方法pytest path/to/test_file.py::TestClassName::test_method_name使用-k进行关键字过滤pytest -k TestLogin and test_success会运行所有类名包含TestLogin且方法名包含test_success的测试。使用-m运行标记的测试在测试方法上用pytest.mark.smoke装饰然后运行pytest -m smoke。6.5 实操心得关于测试类组织的几点建议一个类一个明确的责任不要创建“上帝类”把不相关的测试都塞进去。TestUser、TestOrder、TestPayment是好的划分TestEverything是坏的。善用conftest.py将跨多个测试类共享的 fixture如driver,db_session定义在conftest.py文件中。pytest 会自动发现并使其可用。这是管理测试依赖的最佳实践。类名和方法名就是文档TestLoginFunctionality.test_user_cannot_login_with_expired_password这样的名字即使不看代码也能清楚知道测试意图。平衡类的大小如果一个类里的测试方法超过20-30个考虑是否应该按子功能进一步拆分。例如将TestUserAPI拆分为TestUserRegistrationAPI、TestUserLoginAPI、TestUserProfileAPI。优先使用 fixture 而非 setup/teardownfixture 的依赖注入模式更灵活、更强大尤其是结合autouse、参数化和作用域控制时。setup/teardown可以视为 fixture 的一种简单、特定的实现形式在新项目中建议直接上手 fixture。