从0到1写一个自己的失败截图Skill一

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集 自动化用例挂了，你还在手工翻日志找现场？让AI替你截住那一帧 目录 一、用例失败了你才去翻截图？这个习惯该改了 二、本质变化：失败截图从“事后调试”变成“现场封存” 三、核心机制拆解：一个失败截图Skill的三个关键环节 四、典型案例对比：手动截图 vs Skill自动截图 五、工程落地启示：从今天就能开始的三个步骤 六、你上一次用例失败，花了多久找到出错时的界面？ 一、用例失败了你才去翻截图？这个习惯该改了 很多人已经开始感觉到一个痛。 自动化用例跑了一夜，早上来一看，红了5条。你打开报告，只有一行报错：“元素未找到”。哪个页面？当时界面长什么样？有没有弹窗遮挡？网络有没有超时？一概不知道。 你只能重新跑一遍，眼睛盯着屏幕，等它复现。运气好能抓到，运气不好一天搭进去。 更糟的是，有些失败只在特定环境、特定数据下出现，重跑就过了。你永远不知道第一次失败时到底发生了什么。 最近Skill能力兴起，很多人用它写代码、写文档。但很少有人意识到，失败自动截图这件事，天然就应该用Skill来做。不是写一个截图函数，而是让AI在用例失败的那一刻，自己决定截什么、存哪里、怎么关联到报告。 一个可以截图传播的观点： 没有截图的失败用例，约等于没有现场证据的案子。 二、本质变化：失败截图从“事后调试”变成“现场封存” 传统做法是：你在自动化脚本的exception里写一行截图代码。每个用例都加，或者放在teardown里统一截。问题是，你截的可能是失败后的界面，而不是失败瞬间的界面。弹窗一闪而过，等截图代码执行，界面已经变了。 Skill模式不同。Skill可以感知测试执行的上下文，在断言失败的那一毫秒触发截图动作。它不是等你抛出异常再反应，而是预埋在断言环节，一旦条件不满足，立即执行截图链路。 本质是：失败截图从“被动响应”变成了“主动感知并固定现场”。 下图展示了传统截图与Skill截图的时序差异：