首页/开发/软件测试速查/失败现场的采集
自动化测试66 条

失败现场的采集

失败现场信息决定排错效率:截图、页面快照、视频、网络请求记录、服务端日志与容器日志;CI 上按失败用例归档为构件,并在报告里给出直达链接。

软件测试速查开发更新于 2026-10-13

失败现场的采集是什么

失败现场采集决定排错效率:截图、页面快照、视频、网络请求记录、服务端日志与容器日志;CI 上按失败用例归档为构件,并在报告里给出直达链接。采集原则是「按需、脱敏、可检索」:全量录制既浪费存储,也把敏感信息摊得满处都是。

基本信息

采集内容截图、DOM 快照、视频、网络记录、服务端与容器日志
触发策略仅失败时保留(only-on-failure、retain-on-failure)
归档位置CI 构件目录,报告内提供直达链接
保留周期按构建保留策略滚动清理,避免无限增长
脱敏要求上传前过滤令牌与用户敏感字段

采集配置

采集配置
# Playwright 配置片段
use:
  screenshot: only-on-failure
  trace: on-first-retry
  video: retain-on-failure
# trace 可在本地用 trace viewer 回放全过程

典型使用场景

  • 接口失败:请求、响应与关联日志一起归档,复现靠证据。
  • 界面失败:截图加 trace,定位到具体步骤与元素。
  • 偶发失败:重试时保留首次现场,重试通过也留存证据。
  • 跨团队排错:报告链接直接发给后端,不用翻流水线。
  • 回归对比:基线截图与失败截图并排归档。
  • 合规治理:构件上传前过滤敏感字段,定期抽查。

构件价值对照

构件价值注意
截图界面状态直观动态区域参照价值低
trace 或视频完整回放体积大,按策略保留
网络记录接口与延迟证据含令牌需脱敏
日志服务端上下文时间戳注意时区
归档策略按失败保留即可,全量录制会显著增加存储与上传时间。
构件可能包含令牌与用户数据:上传前脱敏,共享链接注意权限范围。
报告里注明构件对应的用例、参数组与重试次数,检索才顺畅。

易错点

  • 只在本地保留现场,CI 失败时拿不到任何证据
  • 归档内容含敏感数据(令牌、用户信息)未脱敏直接上传构件
  • 全量录制视频与 trace,存储与上传拖慢流水线
  • 构件命名混乱、无用例关联,事后无法检索
  • 重试吞掉首次失败现场,偶发问题无法分析
  • 归档保留期无人管理,半年后想复盘已找不到构件
  • 日志与截图时间戳未统一时区,跟服务端记录对不上
  • 构件列表不标注生成版本与平台,跨环境排查对不上号

数据来源与参考

  • Playwright 官方文档:Trace Viewer 与配置项(playwright.dev)
  • GitHub Actions 文档:Uploading artifacts(docs.github.com)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌