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

说实话，这个问题，只要搞过UI自动化测试的，十有八九都遇到过。

自动化用例跑了一整晚，第二天早上兴冲冲打开报告，五条红通通的失败记录赫然在列。点进去一看，错误信息就一行：“元素未找到”。

哪个页面？当时界面到底是什么状态？是有弹窗突然冒出来把元素挡住了，还是网络延迟导致页面根本没加载完？一概不知。

接下来的常规操作就是重新跑一遍，人得守在屏幕前，眼睛死死盯着，等着它重现那个失败场景。运气好的话能复现，运气不好，大半天时间就这么搭进去了。

更头疼的是，有些失败特别“娇气”，只会在特定的环境、特定的数据组合下才会出现。你重跑一遍，它反而通过了。于是，第一次失败时到底发生了什么，就成了一个永远解不开的谜。

最近“Skill”这个概念挺火的，很多人用它来写代码、写文档。但真正被低估的一个用法，其实是做自动化测试中的“失败自动截图”。注意，不是让你去写一个截图函数那么简单，而是让AI在用例失败的那个瞬间，自己判断该截什么、存到哪里、以及如何和测试报告关联起来。

这才是值得传播的核心观点。

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

传统的做法很直接：在自动化脚本的 exception 处理块里加一行截图代码。每个用例都这么来一遍，或者统一放在 teardown 里。这么做最大的问题是，你截到的画面，通常是失败已经发生之后的状态，而不是失败发生的那一瞬间。

比如一个弹窗一闪而过，等你的截图代码执行时，界面早就变了。你拿到的截图，根本不能反映真实的问题现场。

Skill模式则完全不同。它能感知测试执行的上下文，在断言失败的那一毫秒，立即触发截图动作。它不需要等你抛出异常再被动反应，而是直接预埋在断言环节——一旦条件不满足，截图链路瞬间启动。

说白了，这背后的本质变化是：

下面这张图很直观地展示了传统截图与Skill截图在时间线上的差异：

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

要从0到1写一个顶用的失败截图Skill，核心难点不在于截图本身，而在于

。

环节一：断言拦截

不是让你去改每一个断言，而是在测试框架的层面做一个切面。拿Pytest举例，就是利用 pytest_runtest_makereport 这个钩子。当测试用例失败时，框架会自动触发这个钩子，你的截图逻辑就在这里面执行。

核心代码逻辑大概长这样：

# 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.sa ve_screenshot(screenshot_path)
            # 可选：将截图路径附加到报告
            item.user_properties.append(("screenshot", screenshot_path))

环节二：多源截图策略

一个合格的失败截图Skill，不能只会截当前窗口。它得像一个侦探，根据不同的失败线索，调用不同的工具。

它会自动判断：当前是Web UI还是App？调不同的截图API。需不需要截长图？要不要顺手把浏览器控制台的日志也抓下来？或者干脆连网络请求的Har文件也一并拿到。

关键就在于：

比如断言失败是因为“元素不可见”，那它除了截全屏，还会额外截一个元素区域的特写，并把当时的DOM结构也一并导出。

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

截图只是第一步。没有关联到测试报告的截图，等于不存在。

一个成熟的Skill会自动完成这些事：

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

第二个值得传播的观点是：截图本身不是目的，被有效关联和检索的证据才有价值。下面这个图展示了一个完整失败截图Skill的数据流转过程：

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

传统方式和Skill方式到底差在哪？看下面这个对比就一清二楚了：

维度	手动/脚本截图	Skill截图
触发时机	异常处理块，延迟几十毫秒	断言失败瞬间，同步触发
覆盖场景	通常只截当前窗口	自动判断Web/App/长图/日志
代码侵入	每个用例都要加或改teardown	零侵入，全局生效
报告集成	手动拼路径	自动嵌入Allure/HTML
调试效率	复现失败，盯着屏幕等	直接看截图+日志+网络

这里有个真实案例。一个团队维护着300个UI自动化用例，每周失败率大概在15%。以前定位一个失败原因，平均要花20分钟——重跑、复现、猜测。引入失败截图Skill后，每个失败用例会自动附带5张证据：失败瞬间截图、滚动前后对比、控制台错误、网络请求列表、DOM快照。结果呢？定位时间从20分钟降到了3分钟。

这已经不是简单的截图了，这相当于给每一个失败的用例配了一个事故调查组。

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

好消息是，你不需要依赖大模型也能写出这个Skill。大模型可以让它更智能，但一个能用的基础版，现在就能跑起来。

Pytest用 pytest_runtest_makereport，TestNG用 ITestListener，Jest用 afterEach。核心目标就是让框架能在用例失败时，执行一个你自己定义的函数。

不管你是用Selenium、Playwright还是Appium，截图就是一行的API。先实现它，把截图保存到本地文件夹里。

这一步是真正拉开差距的地方。你可以试着让AI介入，配置一个Skill，让它能从失败日志里提取关键词，自动判断需要额外截什么。比如日志里出现“timeout”，Skill就会自动去截网络请求列表和性能指标。

做到第三步，你手里的“失败截图”就不再是一张孤立的图片，而是一个包含了丰富信息的“失败现场数据包”。

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

最后，问一个很实际的问题。

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

如果这个时间超过了5分钟，那你已经损失了本可以去覆盖更多测试场景的宝贵时间。

失败截图Skill，从来不是什么锦上添花的功能。在UI自动化测试这个领域，它就是最基础、最核心的调试工具。没有它，你的所有失败分析，本质上都是在靠运气和记忆力。

那么，你现在的测试框架，能做到每一次失败，都自动留下完整而可靠的现场证据吗？