7.2 截图日志与失败取证

7.2 截图日志与失败取证

本节摘要：失败取证的目标是让每条失败用例"自带答案"：截图留住页面现场，日志留住操作轨迹，上下文数据留住环境指纹，录屏留住动态过程。四件套在夹具层一次挂载，全部失败自动生效。本节讲清四件套的采集要点、挂载设计与归档规范——7.1 的失败定性依赖失败签名，本节就是签名的生产车间。

没有现场的失败要花十倍成本还原

先算一笔账。一条失败用例，报告里只有一行"断言错误：预期5实际3"。接下来发生了什么：测试复现环境、手动跑到该步骤、发现本地不复现、在流水线参数上重试三次、拉前端一起看、两小时后确认是列表少了一行——而当时页面长什么样，已经永远不可知了。若失败瞬间的截图、操作日志与接口状态被自动留存，这案子五分钟结案。

取证体系的设计原则由此而来：取证是自动的、事后的、面向"当时"的。自动——不能依赖当事人记得截图；事后——失败发生时立即采集，不等人来；面向当时——留存的是失败瞬间的状态，而不是"之后再去看"的承诺。

四件套各自采集什么

截图是最直观的现场。采集要点有三：时机在失败瞬间（夹具的失败钩子里触发），视口截图默认就够（整页截图用于布局类缺陷），文件名带用例标识与时间戳。操作日志是行为轨迹：每步操作前记录动作、目标与当前地址，失败时日志能还原"走到哪一步死的"。Selenium 自身提供浏览器端日志通道（控制台、性能、驱动行为三类），配合用例层的动作日志，形成"脚本做了什么"与"页面反应了什么"的双面记录。上下文数据是环境指纹：用例标识、环境名、浏览器与版本、会话标识、测试数据标识，一组键值对把失败钉到具体环境与数据组合上——7.1 定性的"环境指纹"就是它。录屏是动态过程，对"红得莫名其妙"的用例是杀手锏：元素闪现、动画遮挡、弹窗突袭这类截图抓不到的过程性问题，录屏一帧不漏。录屏有存储与性能成本，建议只对指定用例或指定层（如核心旅程）开启。

图7-2 失败取证链路

挂载：一处实现，全部生效

取证的工程挂载点在第 4 章就埋好了——夹具层。运行器提供失败钩子或让夹具捕获用例异常，在那里调用统一的取证函数：

@pytest.hookimpl(hookwrapper=True)
def pytest_runtest_makereport(item, call):
    outcome = yield
    report = outcome.get_result()
    if report.when == "call" and report.failed:
        driver = item.funcargs.get("driver")
        if driver:
            stamp = time.strftime("%H%M%S")
            name = f"{item.name}_{stamp}"
            driver.save_screenshot(f"evidence/{name}.png")
            with open(f"evidence/{name}.log", "w", encoding="utf-8") as f:
                f.write(driver.page_source[:20000])   # 页面快照入档
​

这段钩子是取证体系的"总开关"：任何用例失败，截图与页面快照自动落盘，工程里没有第二处需要写取证代码。页面源码快照值得单独表扬——它比截图更能回答"当时 DOM 里到底有没有那个元素"，定位类失败（3.2 的六张工单）几乎都要靠它结案。日志与上下文指纹的实现同理：动作日志在页面对象基类的统一入口里埋一行记录，指纹从配置加载函数里取（4.4 的配置体系又派上用场）。

归档规范：取证包与保留期

散落的截图文件会变成新的垃圾场，归档要立三条规矩。按用例聚合：一次失败的全部证据（截图、日志、快照、指纹、录屏）归入同一个以用例加时间命名的目录，缺陷单只附一个包。随报告走：取证包路径写进报告条目，看报告的人一键可达现场。有保留期：取证文件按磁盘预算滚动清理，通过用例的轻量记录保留更长，失败证据保留到对应缺陷关闭——存量治理时它们还要当历史卷宗用。

一个取证包结案的完整过程

看取证体系在真实工单里的工作方式。失败条目：搜索用例断言失败，预期结果列表非空，实际为零。没有取证的时代，这个案子的第一小时会耗在"复现不出来"上。现在打开取证包，五件证据依次说话。

截图显示：搜索结果区域完全空白，但页面其他区域正常。页面源码快照显示：结果容器存在且为空——不是没渲染，是没有数据。动作日志显示：输入、点击、等待三步时序正常。上下文指纹显示：预发布环境、账号 A、时间凌晨两点。浏览器控制台日志（8.2 的调试集成）显示：结果接口返回了正常的空数组。

四份证据拼出结论：凌晨两点的预发布环境里，搜索索引正在重建，接口如实返回了空。这不是缺陷，是数据时窗问题——但取证包的价值不止于结案，它推动了一个改进：搜索类用例的前置校验里加入"索引就绪"检查，检查不过就标记跳过并说明。一个取证包，结了一案，还堵了一类案的源头。这就是 7.1 说的"取证是定性的生产车间"——证据链完整，定性就从猜变成了断。

取证设计的三个常见坑

坑一：取证代码写进用例。 每条用例末尾手工调用截图函数——挂一漏万，新用例必然忘。取证必须挂在夹具或钩子里自动触发，本节的钩子示例就是标准答案；用例里出现取证调用即是设计异味。

坑二：截图时机太晚。 失败发生后先做了几步清理动作（关弹窗、回首页）再截图，现场已被破坏。取证要抢在一切恢复动作之前——这也是钩子挂载优于 try 清块内挂载的原因。

坑三：证据与报告断链。 截图散落在执行机器的临时目录，报告里没有链接，机器回收时证据陪葬。归档路径必须写进报告条目，且归档目录要有独立于执行环境的保留期——证据的生命周期应当比执行环境长，比缺陷纠纷短。

三个坑的共同根源是把取证当成"功能"而不是"体系"。功能随用例生灭，体系靠挂载点与归档规范维系——这一字的差别，决定了三个月后你的失败报告里有没有现场。

收工清单

• 取证三原则：自动触发、失败瞬间采集、留存"当时"的状态。
• 四件套分工：截图给现场、日志给轨迹、指纹给环境、录屏给过程；页面源码快照是定位类失败的关键证据。
• 挂载在夹具层：失败钩子一处实现全仓生效，取证代码不进用例。
• 归档三规矩：按用例聚合成包、随报告可达、按保留期滚动。
• 与 7.3 的接口：取证让失败可解释，但更好的目标是少失败——下一节清脆弱性的根子。

证据链齐了，红屏不再可怕。但更高级的打法是让红屏本身变少——下一节做减法：清掉脆弱性设计与反模式。