什么是测试框架与分层选型
测试投入要按分层分配：单元测试提供毫秒级快速反馈，集成测试验证模块与依赖的交互，契约测试锁定服务间约定，端到端测试只覆盖少量关键用户路径。框架选型看语言生态、执行速度、断言与调试体验、隔离与并发能力。分层的意义在于让失败尽早暴露、定位成本足够低。
基本信息
| 分层配比 | 大量单元、适量集成与契约、少量端到端 |
|---|---|
| 执行时机 | 单元随提交、契约在合并前、集成按需、端到端发布前 |
| 选型维度 | 语言生态、执行速度、断言可读性、并行与隔离能力 |
| 配套设施 | 测试数据构造、容器化依赖、报告与失败留档 |
测试分层
| 层级 | 覆盖目标 | 执行特征 |
|---|---|---|
| 单元 | 函数与类级逻辑 | 毫秒级，随提交执行 |
| 集成 | 模块与真实依赖交互 | 秒级到分钟级，按需执行 |
| 契约 | 服务间接口约定 | 提供方与消费方双向验证 |
| 端到端 | 关键用户路径 | 分钟级，控制在少量用例 |
典型使用场景
- 新项目起骨架：先定分层与目录约定，再选具体框架
- 流水线加速：把慢用例移出提交阶段，缩短反馈时间
- 重构保护：单元与契约测试先行，重构时行为可验证
- 联调前置：契约测试在合并前发现不兼容变更，减少联调返工
- 测试数据治理：用容器化依赖与固定夹具替代共享脏环境
- 质量度量：跟踪各层用例数量、执行时长与不稳定用例比例
分层运行的一种组织方式
分层运行的一种组织方式
# 提交阶段：只跑快速用例，控制在几十秒内
pytest -m unit -q # 单元测试（示例：Python 生态）
# 合并前：跑契约与轻量集成
pytest -m contract -q && pytest -m integration -q
# 发布前：跑端到端关键路径
npx playwright test tests/e2e/critical-path.spec.ts
# 失败留档：截图、日志与 trace 一并上传，便于定位
# 不稳定用例单独标记并设期限修复，不要长期重跑掩盖问题端到端用例越多，维护成本与不稳定度越高：把稳定的关键路径留给端到端，其余验证下沉到低层测试。
只断言实现细节会让重构时大量用例失效：优先断言外部可观察行为，而不是内部调用顺序。