测试框架解剖是什么
测试框架不是某个单一工具，而是让用例可写、可跑、可维护的一整套机制，通常由五部分组成：用例发现与组织、夹具与资源配置、断言与等待、执行调度（并发/重试/分片）、报告与 CI 集成接口。无论 pytest、JUnit 5、Jest 还是 Go testing，骨架都相同；理解这套结构后，换语言或换框架只是概念映射，而不是从头学起。
组成
| 组成 | 职责 | 常见实现 |
|---|---|---|
| 运行器 | 发现、组织与执行用例 | pytest、JUnit Platform |
| 夹具机制 | 准备与清理测试资源 | pytest fixture、JUnit @BeforeEach |
| 断言与等待 | 表达期望并同步异步状态 | assert、AssertJ、web-first 断言 |
| 执行调度 | 并发、重试、分片 | pytest-xdist、JUnit 并行执行 |
| 报告与集成 | 输出结果供 CI 与看板消费 | JUnit XML、Allure、HTML 报告 |
选型评估点
| 语言与生态 | 与团队技术栈一致，插件可复用 |
|---|---|
| 钩子与扩展点 | 决定能否注入环境准备、数据清理 |
| 并行与重试 | 内置还是靠插件，配置复杂度 |
| 报告格式 | CI 能否直接消费并聚合趋势 |
| 社区活跃度 | 文档质量与问题响应速度 |
固件作用域示例
固件作用域示例
import pytest
@pytest.fixture(scope="session") # 会话级：整套测试只执行一次
def db():
conn = connect()
yield conn # yield 前是准备，之后是清理
conn.close()
def test_query(db): # 按参数名注入固件
assert db.query("select 1") == 1典型使用场景
- 框架选型：按五部分逐项打分对比候选方案
- 自建与现成的取舍：报告、重试、并发不必自己造
- 新人上手：用五部分结构解释项目自动化怎么运转
- CI 接入：确认报告格式能被流水线消费
- 框架迁移：按组成拆解迁移工作量
- 排查用例不执行：对照发现规则检查文件与命名
框架能力上限由扩展点决定：容器支持、失败重跑、报告美化通常都以插件形式存在，先看生态再动手自研。
固件作用域决定执行频次与隔离度：函数级每条用例都跑，会话级只跑一次；贪图省时间用会话级共享状态，容易引入用例互相污染。
用例独立是并行与乱序执行的前提：依赖执行顺序的用例在单线程下像通过，一开并行就大面积失败。