专栏 ：Playwright Python 自动化测试从入门到实战
适读人群 ：测试工程师 / 测试开发 / Python 开发者
预计阅读：12 分钟
一、一个让人等不起的 CI
100 个用例串行跑完要 28 分钟 ，CI 排队 + 测试 1 小时起步。开发提交一次代码，咖啡喝完还没看到结果。
慢的测试 = 没人愿意跑的测试 = 迟早被跳过。
二、并行的三个前提（缺一不可）
| 前提 | 含义 | 对应篇目 |
|---|---|---|
| 用例隔离 | 用例之间互不干扰 | 第 10 篇测试数据 |
| 数据隔离 | 每个用例独立数据 | 第 10 篇工厂函数 |
| 进程隔离 | 多进程互不抢占资源 | 本篇 pytest-xdist |
核心原则 ：并行 = 隔离 + 分片 ，不是简单加 --workers。
三、本地并行：pytest-xdist
安装
bash
pip install pytest-xdist运行
bash
# 自动检测 CPU 核心数
pytest -n auto
# 指定进程数
pytest -n 4工作原理：xdist 启动 N 个 worker 进程，按文件/用例分片调度。
四、分片策略（避免数据竞争）
bash
# 按文件分片（默认，隔离性最好）
pytest -n 4 --dist=loadfile
# 按用例分片（更均匀）
pytest -n 4 --dist=loadscope选择建议：
- 文件间无共享状态 →
loadfile - 单文件内有共享 fixture →
loadscope
五、CI 并行：GitHub Actions 矩阵
yaml
# .github/workflows/test.yml
name: Playwright Tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
shard: [1, 2, 3, 4] # 4 路并行
steps:
- uses: actions/checkout@v4
- run: pip install -r requirements.txt
- run: playwright install
- name: Run tests (shard ${{ matrix.shard }})
run: pytest -n 2 --shard-id=${{ matrix.shard }} --num-shards=4
- name: Upload report
if: always()
uses: actions/upload-artifact@v4
with:
name: report-shard-${{ matrix.shard }}
path: allure-results/效果 ：28 分钟 → 约 8 分钟（4 路 + 每路 2 worker）。
六、失败重试（不稳定用例的缓冲）
bash
# 失败用例自动重试 2 次
pytest --reruns 2
# 只对特定错误重试
pytest --reruns 2 --reruns-delay 1配合 Allure（第 13 篇）：重试历史会记录在报告中。
七、完整 CI 流水线（接第 13 篇报告）
代码提交
↓
[Job] lint + 单测（快速反馈）
↓
[Job] E2E 并行（4 shard × 2 worker）
↓
[Job] 生成 Allure 报告 + 上传制品
↓
评论区附报告链接关键配置：
- 超时：
pytest --timeout=300 - 失败时保留制品：
if: always() - 合并报告：用
allure merge汇总 4 路结果
八、常见坑位
❌ 坑 1：并行下共享状态冲突
python
# 错误：全局变量被多进程同时改写
counter = 0
def test_a(): global counter; counter += 1✅ 修复：用 fixture scope + 独立数据（第 10 篇工厂）
❌ 坑 2：端口 / 临时文件竞争
多个 worker 同时占用 8080 端口 → 随机端口或动态分配
❌ 坑 3：测试顺序依赖
python
# 错误：假设 test_b 在 test_a 之后跑
def test_a(): create_user()
def test_b(): assert user_exists() # 并行下可能分到不同进程✅ 修复：每个用例自给自足（第 10 篇隔离原则）
九、性能对比（实测参考）
| 配置 | 100 用例耗时 | 加速比 |
|---|---|---|
| 串行 1 进程 | 28 min | 1× |
-n 4 |
9 min | 3.1× |
| 4 shard × 2 worker | 7.5 min | 3.7× |
⚠️ 加速比受限于 I/O 与服务器并发能力，并非线性。
十、与前面章节的关系
| 专栏篇目 | 关联点 |
|---|---|
| 第 6 篇《自动等待》 | 避免硬编码 sleep 导致并行抖动 |
| 第 10 篇《测试数据》 | 并行安全的根基：工厂 + 隔离 |
| 第 11 篇《Page Object》 | PO 无状态 → 天然适合并行 |
| 第 13 篇《Allure》 | CI 生成报告 + 上传制品 |
十一、最佳实践总结
✅ 隔离优先 ：数据独立 > 进程并行
✅ 分片策略 ：loadfile 起步，有共享 fixture 改 loadscope
✅ 失败重试 ：--reruns 2 缓冲偶发抖动
✅ CI 矩阵 ：shard + artifact + 报告链接
✅ 监控趋势：执行时间 / 失败率纳入看板
十二、小结（建议收藏）
✅ 并行 = 用例隔离 + 数据隔离 + 进程隔离
✅ 本地 pytest -n auto，CI 用矩阵分片
✅ 失败重试 + Allure 报告 = 稳定可观测
✅ 加速比非线性，先保证隔离再谈并发
十三、下一篇预告
👉 《13-可视化报告与 Allure 深度集成》