为什么需要Tracing功能
当你的自动化测试脚本突然变慢时，是否怀疑过是某个API请求拖慢了整体速度？Tracing就像测试脚本的"黑匣子"，详细记录了每个操作耗时和网络请求详情:
- 精确到毫秒级的操作时间轴
- 所有网络请求的header/body信息
- 页面截图和console日志
我用trace.playwright.dev分析过电商网站的加入购物车测试，发现有个商品图片的CDN请求居然耗时3.2秒！
启用Tracing的3种方式
// 方式1：全局录制
const browser = await chromium.launch();
const context = await browser.newContext();
// 开始录制
await context.tracing.start({ screenshots: true, snapshots: true });
// 测试代码...
await page.click('#add-to-cart');
// 结束并保存
await context.tracing.stop({ path: 'trace.zip' });
// 方式2：命令行启动
npx playwright test --trace on
// 方式3：配置文件设置
// playwright.config.js
use: {
trace: 'retain-on-failure'
}
分析trace文件的5个关键技巧
- 网络瀑布图分析：检查哪些请求造成了连锁延迟
- 操作时序对比：发现click事件与API响应的时序矛盾
- 内存快照：定位DOM节点异常堆积
- 控制台过滤：使用
type:error快速定位JS错误 - 性能指标重叠：将LCP等Web指标与操作时间轴对齐
实测案例：某次登录测试超时，通过追踪发现是第三方验证码服务响应时间从平均200ms突增到8秒。
常见性能问题解决方案
场景1：API响应慢
- 在trace中复制curl命令本地复现
- 使用
page.route()拦截请求进行mock
场景2：元素定位耗时
- 检查是否使用了低效的XPath
- 启用
await page.waitForSelector()超时设置
场景3：突现的内存泄漏
- 对比多个trace的快照差异
- 检查未被清理的EventListeners
高级用法：自定义追踪
# 添加自定义日志
context.tracing.start(
name='checkout_flow',
sources=True,
screenshots=True,
snapshots=True,
attachments=[{
'name': 'custom_metric',
'value': performance.now()
}]
)
与其他工具结合
- 导入JMeter进行压力测试回放
- 用Lighthouse分析追踪期间的性能评分
- 与Sentry错误监控系统关联
上周帮同事发现个趣事：他们的测试在凌晨3点总会失败，查trace才发现是因为那时候CI服务器会自动打安全补丁！
