Skills实战：从0到1写一个你自己的失败截图Skill

自动化用例挂了，你还在手工翻日志找现场？让AI替你截住那一帧

目录

• 一、用例失败了你才去翻截图？这个习惯该改了
• 二、本质变化：失败截图从“事后调试”变成“现场封存”
• 三、核心机制拆解：一个失败截图Skill的三个关键环节
• 四、典型案例对比：手动截图 vs Skill自动截图
• 五、工程落地启示：从今天就能开始的三个步骤
• 六、你上一次用例失败，花了多久找到出错时的界面？

一、用例失败了你才去翻截图？这个习惯该改了

很多人已经开始感觉到一个痛。

自动化用例跑了一夜，早上来一看，红了5条。你打开报告，只有一行报错：“元素未找到”。哪个页面？当时界面长什么样？有没有弹窗遮挡？网络有没有超时？一概不知道。

你只能重新跑一遍，眼睛盯着屏幕，等它复现。运气好能抓到，运气不好一天搭进去。

更糟的是，有些失败只在特定环境、特定数据下出现，重跑就过了。你永远不知道第一次失败时到底发生了什么。

最近Skill能力兴起，很多人用它写代码、写文档。但很少有人意识到，失败自动截图这件事，天然就应该用Skill来做。不是写一个截图函数，而是让AI在用例失败的那一刻，自己决定截什么、存哪里、怎么关联到报告。

一个可以截图传播的观点：

没有截图的失败用例，约等于没有现场证据的案子。

二、本质变化：失败截图从“事后调试”变成“现场封存”

传统做法是：你在自动化脚本的exception里写一行截图代码。每个用例都加，或者放在teardown里统一截。问题是，你截的可能是失败后的界面，而不是失败瞬间的界面。弹窗一闪而过，等截图代码执行，界面已经变了。

Skill模式不同。Skill可以感知测试执行的上下文，在断言失败的那一毫秒触发截图动作。它不是等你抛出异常再反应，而是预埋在断言环节，一旦条件不满足，立即执行截图链路。

本质是：失败截图从“被动响应”变成了“主动感知并固定现场”。

下图展示了传统截图与Skill截图的时序差异：

三、核心机制拆解：一个失败截图Skill的三个关键环节

从0到1写一个失败截图Skill，核心不在于截图本身，而在于“如何在不侵入用例逻辑的前提下，捕获失败瞬间”。

环节一：断言拦截

不是改每个断言，而是在测试框架层面做切面。以Pytest为例，利用pytest_runtest_makereport钩子，在用例失败时自动执行。

Skill的逻辑是：定义一个钩子函数，检测到失败后，调用截图工具。

代码层面的Skill核心示意：

# conftest.py 中的失败截图Skill
@pytest.hookimpl(tryfirst=True, 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")  # 从fixture获取driver
        if driver:
            screenshot_path = f"screenshots/{item.name}_{timestamp()}.png"
            driver.save_screenshot(screenshot_path)
            # 可选：将截图路径附加到报告
            item.user_properties.append(("screenshot", screenshot_path))

环节二：多源截图策略

一个合格的失败截图Skill不应该只会截当前窗口。它需要判断：

• 当前是Web UI还是App？调不同的截图API
• 是否需要截长图（滚动截图）
• 是否需要同时捕获浏览器控制台日志
• 是否需要截取网络请求（Har）

Skill的核心在于：根据失败上下文，自动选择截图策略。比如断言失败是因为元素不可见，Skill可以额外截一个元素区域的特写，并输出当时页面的DOM结构。

环节三：证据关联与报告集成

截图只是第一步。没被关联到用例报告的截图，等于不存在。

Skill应该自动完成：

• 截图命名规则：用例名_失败时间_断言行号.png
• 将截图路径写入测试报告的附件字段
• 如果是Allure，调用allure.attach嵌入
• 如果是HTML报告，生成图片链接

第二个可传播的观点：

截图不报告等于没截，报告不可链等于没存。

下图展示了一个完整失败截图Skill的数据流：

四、典型案例对比：手动截图 vs Skill截图

一个真实场景：某团队维护300个UI自动化用例，每周失败率15%。之前定位一个失败平均需要20分钟（重跑、复现、猜测）。引入失败截图Skill后，每个失败用例自动附带5张证据：失败瞬间截图、滚动前后对比、控制台错误、网络请求列表、DOM快照。定位时间从20分钟降到3分钟。

这不是截图，这是给每个失败用例配了一个事故调查组。

五、工程落地启示：从今天就能开始的三个步骤

你不需要大模型也能写这个Skill。大模型的作用是让它更智能，但基础版完全可以先跑起来。

第一步：在测试框架中增加全局失败钩子

Pytest用pytest_runtest_makereport，TestNG用ITestListener，Jest用afterEach。先让框架能在失败时执行一个函数。

第二步：把截图函数挂上去

不管你用的是Selenium、Playwright还是Appium，截图API都是一行代码的事。先保存到本地文件夹。

第三步：让Skill智能起来

这一步可以用AI。训练或配置一个Skill，让它能从失败日志里提取关键词，自动判断需要额外截什么。比如日志里出现“timeout”，Skill自动截取网络请求列表和性能指标。

做到第三步，你的失败截图就不再是“一张图”，而是一个“失败现场数据包”。

第三个可传播的观点：

失败截图的终局不是一张图，而是一个可回放、可搜索的失败档案。

六、你上一次用例失败，花了多久找到出错时的界面？

问一个实际的问题。

你最近一次自动化用例失败，从看到红色到确定根本原因，用了多少分钟？其中有多少时间花在“当时界面到底长什么样”这个问题上？

如果这个时间是5分钟以上，那么你已经损失了本可以去覆盖更多场景的时间。

失败截图Skill不是锦上添花。在UI自动化测试里，它就是最基础的调试工具。没有它，你的失败分析靠的是运气和记忆力。

那么，你的测试框架现在是不是每一次失败，都能自动留下完整的现场证据？