pytest.mark.parametrize 必须紧贴测试函数定义上方使用，否则 pytest 不识别参数化逻辑；ids 参数可提升失败时的可读性；异常测试需配合 pytest.raises；多层 parametrize 会产生笛卡尔积，易导致用例爆炸。
pytest.mark.parametrize 为什么不能直接写在测试函数外面
因为 pytest.mark.parametrize 是一个装饰器，必须紧贴测试函数定义上方使用，否则 pytest 根本不会识别参数化逻辑，测试会直接跳过或报 TypeError: 'function' object is not callable。常见错误是把它当成普通函数调用，写成 parametrize(...) 或放在类定义里但没装饰具体方法。
实操建议：
立即学习“Python免费学习笔记（深入）”；
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 确保装饰器写在
def test_*函数正上方，中间不能有空行或其它语句 - 如果测试函数在类中，要装饰到具体方法上，而不是类名上（类级别参数化需用
@pytest.mark.parametrize配合self参数） - 参数名必须和函数签名中的形参名严格一致，大小写敏感，比如函数定义为
def test_add(a, b):，则parametrize的第一个参数就得是"a, b"
传入多组数据时，ids 参数怎么避免默认数字编号
pytest 默认用索引（0, 1, 2…）标记每组参数，但这样在失败时看不出哪组数据出问题。加 ids 可以让输出更可读，比如显示 test_divide[10-2] 而不是 test_divide[0]。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
ids接收列表或可调用对象；列表长度必须和参数组合数一致 - 用 lambda 写简洁 id：
ids=lambda x: f"{x[0]}-{x[1]}"（适用于元组输入） - 注意
ids不影响实际执行逻辑，只改 pytest -v 输出里的测试名 - 如果某组数据导致测试崩溃（如
ZeroDivisionError），对应 id 仍会显示，方便定位
如何用 parametrize 测试异常场景（比如期望抛出 ValueError）
不能直接在 parametrize 中“断言异常”，必须把异常检查逻辑放进测试函数体，配合 pytest.raises 使用。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把预期异常类型、输入值、甚至异常消息片段一起参数化，例如：
("invalid", ValueError, "must be positive") - 测试函数内用
with pytest.raises(expected_exc, match=expected_msg)包裹被测代码 - 别忘了给
match参数加re.escape()如果消息含正则特殊字符 - 如果某组数据不该抛异常，就单独写个正常流程分支，或拆成两个独立的
parametrize块
嵌套参数化（多个 parametrize 装饰器）会生成笛卡尔积吗
会。连续使用多个 @pytest.mark.parametrize 会做全量组合，比如两层各 3 组，最终运行 9 个测试用例。这容易导致用例爆炸，尤其当其中一组包含大量数据时。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 优先用单层
parametrize显式列出所有组合，控制总量 - 真需要组合时，确认是否真的需要全部交叉——很多时候只需边界 + 典型值，而非全量
- 用
pytest -k "test_name[subset]"快速筛选子集运行，避免本地反复等全部用例 - 组合后测试名会变长（如
test_login[admin-true-200]），注意终端显示截断问题
