做自动化测试和自动化运维的朋友应该都有过这种体验晚上十一点监控群突然弹出一条失败告警你眯着眼打开电脑翻日志、查截图、复现问题最后发现是某个页面元素被前端改了个class或者某个依赖服务昨晚升级导致响应超时。修好之后第二天换了个场景又炸一次。传统自动化的本质其实是“重复地发现问题”而不是“解决问题”。AI驱动的自动化自愈链路想做的就是把这套逻辑倒过来——让系统自己完成失败归因、自己下判断、自己执行修复、自己验证闭环。这篇文章我会从整体设计、归因原理、修复策略、落地方案和常见坑位五个维度展开把这套链路从思路到代码完整讲一遍。适合正在做自动化测试、自动化运维、以及想在现有脚本体系里引入AI能力的工程师参考。1. 先搞清楚我们到底在解决什么问题1.1 传统自动化的三个死穴第一个死穴是“靠人肉盯”。自动化跑起来之后脚本本身不会思考只知道红了就是红了。问题是红了之后呢还是得人去看。你想想如果一晚上跑一千条用例失败三十条哪怕成功率都到97%了你还是得逐条点开日志去判断哪些是代码Bug、哪些是环境抖动、哪些是前端改版导致的选择器失效。这个排查过程极其消耗精力而且完全是在重复劳动。第二个死穴是“规则永远写不完”。有些团队会给自动化框架加一些失败重试的机制比如失败之后自动重跑一次或者遇到特定错误码就自动重启服务。这类规则确实管用但规则的覆盖范围始终有限。今天加一条“超时重试”明天加一条“登录失效自动重登”后天又冒出一种“弹窗拦截导致点击失败”。规则越写越多最终变成一团乱麻而且新出现的异常类型永远没法第一时间覆盖。第三个死穴是“环境沾了锅就没人管”。很多失败其实是环境问题比如测试数据库连接池满了、测试账号被锁、依赖服务没起来。这类问题本身不难修但它会淹没掉真正需要开发介入的Bug。一个自愈链路真正要解决的就是这三件事快速判断失败属于哪一类、跳过或修复环境类问题、把真正需要人处理的异常精准地抛出来。1.2 自愈链路的整体设计四层结构我把“自愈”拆成了四层每一层只做一件事层与层之间通过标准数据结构通信这样整个系统才不至于变成一座屎山。第一层是上下文采集层。失败发生后系统立刻把能拿到的信息全部搜集起来包括异常堆栈、页面截图、DOM快照、网络请求记录、控制台日志、接口响应报文等。这一层的关键不是“尽量多”而是“带着目的去采集”。比如UI自动化重点抓页面状态接口自动化重点抓请求和响应服务端任务重点抓进程状态和日志时间线。第二层是失败归因层。采集完上下文之后先交给规则引擎做一轮快速匹配。如果规则引擎能命中直接输出结构化结论如果命中不了再交给大模型做语义分析让它基于上下文推断可能原因并输出同样结构的结果。这里的核心原则是“规则兜底、AI覆盖未知”。第三层是自动修复层。拿到归因结论之后系统根据原因类别执行对应的修复动作。修复动作要封装成原子操作比如重试、刷新登录态、重置测试数据、更新元素定位器、重启依赖服务等。每个动作必须幂等、可回滚、有超时控制。第四层是验证闭环层。修复执行完之后自动重新运行刚才失败的用例或任务。验证通过就算自愈成功验证失败就再做一轮归因超过最大轮数就熔断升级给人工处理。没有这一层自愈就是一条没有反馈的流水线你不知道修复到底有没有效。这四个层级不是物理上必须拆成四个服务而是逻辑上必须分开尤其是归因和修复绝不能混在一个函数里。否则你会遇到“又做诊断又动手”的混乱状态出了问题根本没法追踪。1.3 为什么不是纯AI也不是纯规则很多人一听“AI驱动”就觉得应该让大模型接管一切让它自己看日志、自己改代码、自己处理一切异常。我的意见是在生产环境里千万别这么干原因很现实。第一纯AI的成本高而且慢。一次归因调用如果走云端大模型单次耗时可能三五秒如果失败用例多光归因就排队排半天。加上token费用一晚上跑几百次成本不容忽视。而很多失败其实用几条if-else就能判断出来比如“登录超时”、“选择器找不到”、“断言数值不匹配”根本不需要动用大模型。第二纯AI有幻觉风险。大模型在没有足够上下文的时候会一本正经地瞎编原因。如果这个编出来的原因直接驱动了修复动作那后果可能非常严重。比如模型认为“接口返回500是因为数据库连接池满了”于是触发数据库重启但实际上根因是代码里有个死循环。一次误判可能让整个环境雪上加霜。第三纯规则的上限很低。规则是有限集合环境是无限集合你永远写不出能覆盖所有异常类型的规则。而大模型的语义理解能力恰好能处理那些“没见过但描述一下就能推断”的场景。所以我的选择是先用规则做快速通道再让AI做疑难杂症通道同时把AI的输出约束成结构化JSON并且标注置信度低置信度一律不自动执行修复转人工。这个思路是所有自愈链路设计的核心基调。2. 失败归因让系统先学会“看懂失败”2.1 归因前提先把失败现场的“证据链”做齐全做失败归因就像破案你不能只凭一句话下定论。很多人在这一步犯的错误是只把异常信息丢给大模型然后问“为什么失败”。结果大模型回答得模棱两可因为你没给它足够的信息。想让归因质量高首先要确保证据链完整。我的做法是设计一个统一的Context对象不管什么类型的自动化任务失败之后都往这个对象里填充标准字段。比如UI自动化任务会填充页面URL、Title、截图路径、DOM关键节点快照、最近十次网络请求列表、浏览器控制台日志、执行的操作历史。接口自动化任务会填充请求方法、请求URL、请求头、请求体、响应状态码、响应体、耗时、接口依赖的服务名称。这些字段不一定要全部有但能填的都填上。为什么这么做因为大模型本质上是一个模式匹配器你给它的上下文越丰富它匹配到正确原因的概率就越高。有一个小细节截图一定要用Base64编码塞进Prompt吗不一定。多数大模型能读图但读图的成本更高、响应更慢而且对日志和代码类问题帮助有限。我的建议是截图先存盘作为人工复核的依据Prompt里主要放文本化的日志和状态信息。采集阶段还有一个容易被忽略的点采集动作本身要控制耗时。比如DOM快照很大整个页面序列化出来可能几十万字符真把这些都塞给大模型一是token爆炸二是噪声太多。所以我会做裁剪获取页面关键元素的文本内容、输入框的值、可见性状态以及距离当前操作最近的区域节点。规则是“宁缺毋滥”不要为了追求全面而采集一堆无用信息。2.2 规则引擎快速命中80%的已知问题规则引擎听起来简单实际上也有设计门道。我的建议是不要写一大堆互相纠缠的if-else而是把规则抽象成“条件模板 结果模板”。每个规则包含一组匹配条件和一组输出结果。举个例子一个典型的规则可以这样写当异常类型是TimeoutError并且重试次数等于0并且最近一次网络请求的响应时间超过5秒时输出“可能原因网络抖动或服务响应缓慢建议动作延迟重试、降低超时阈值”。另一个规则当异常类型是NoSuchElementException并且页面Title和上一轮相同并且页面中出现“系统繁忙”字样输出“可能原因后端服务异常导致页面未正常渲染建议动作检查服务健康状态、等待服务恢复后重试”。规则引擎的优势是零成本、零延迟、确定性高。它虽然在扩展性上不如大模型但足以覆盖绝大多数高频失败场景。实际操作中我会把规则写在YAML或JSON文件里而不是硬编码在代码中这样后续维护规则不需要改代码重新发布。规则合并的逻辑也要做如果多个规则同时命中按预设优先级取一个置信度最高的结果。有人会问规则和AI的边界怎么划分我个人的经验是凡是能通过“异常类型 几个关键字段值”直接得出结论的都不需要AI处理凡是需要综合多段日志理解前后逻辑的才交给AI。比如“登录失败”和“权限不足”这两个问题如果只靠状态码判断可能都是401但日志里一个是因为token过期一个是因为用户角色不对这时候规则很难区分就需要AI读日志上下文做判断。2.3 LLM语义归因处理规则覆盖不到的20%当规则引擎没有命中时就轮到LLM上场了。这里说的LLM既可以是云端的大模型API也可以是本地部署的开源模型比如通过Ollama跑的Qwen或Llama系列。我的建议是如果对数据安全要求高优先本地部署如果只做测试环境用云端API也完全没问题。调用LLM做归因最关键的是Prompt设计。我见过很多人直接把原始日志一股脑塞给AI然后问“这是为什么”输出基本没法用。一个合格的归因Prompt至少要包含以下部分系统角色设定你是一名资深测试工程师擅长分析自动化任务失败原因、任务目标请根据以下失败上下文判断失败原因并给出修复建议、结构化上下文把Context对象序列化成清晰的文本块按字段分组、输出格式要求严格输出JSON包含failure_type、confidence、root_cause_summary、suggested_actions、risk_level等字段。示例Prompt长这样你是一名资深测试工程师正在协助分析一次自动化测试失败的原因。 以下是本次失败现场的完整上下文 页面URL: https://example.com/order/create 页面标题: 创建订单 异常类型: ElementNotFoundError 异常信息: 找不到元素 [data-testidsubmit-btn] DOM片段: div classbtn-group ... button classbtn提交/button ... /div 最近操作: 点击提交按钮 网络请求: POST /api/order 返回 200耗时 320ms 请基于以上信息判断失败原因并按以下JSON格式输出不要输出任何其他内容 { failure_type: element_not_found, confidence: 0.0-1.0, root_cause_summary: 简要说明根因, suggested_actions: [动作1, 动作2], risk_level: low|medium|high }为什么要强调JSON格式输出因为归因结果要被修复引擎直接消费。如果AI输出一段散文你还得再写一个文本解析器去抽关键信息解析错了又是新的麻烦。用JSON规范化输出解析简单、容错容易、后续存数据库做历史分析也方便。实测下来Qwen和Llama这类模型在遵循JSON格式方面已经做得很好了偶尔会多输出一些解释文字我在代码里会做一层容错处理截取第一个JSON块来解析。2.4 归因结果的结构化让修复引擎听得懂归因的结果不能只是一个字符串描述它应该是一个结构化的对象。这个对象里至少要包含四个字段归因类别、置信度、原因描述、建议动作列表。归因类别我建议设计一个枚举不要用自由文本否则修复引擎没法做分支判断。常见的类别可以包括网络超时类、元素定位类、登录态失效类、数据状态污染类、服务不可用类、断言失败类、脚本逻辑Bug类、未知类型。每一类对应一组修复策略。置信度字段是自愈链路里最重要的安全阀。我的设定是置信度低于0.6的结论不允许自动执行修复只能转人工0.6到0.8之间的结论允许执行低风险的修复动作比如重试、等待、刷新登录态0.8以上才可以尝试高风险的修复动作比如自动生成代码补丁、重启服务。这个阈值不是拍脑袋定的我会在系统运行一段时间后根据人工复核通过率动态调整。原因描述和动作建议的生成也要注意可读性。原因描述要能让一个没参与过这个任务的人看懂动作建议要具体比如“更新元素定位器为data-testidsubmit-btn”而不是“修复元素”。这不仅仅是为了给修复引擎用也是为了让最终收到告警的开发人员能快速理解问题背景。3. 自动修复从“诊断”到“下处方”的安全落地3.1 修复策略不是蛮力重试而是分级处理修复动作是自愈链路里风险最高的环节。一个自动化脚本失败后系统要替人做决定这个决定如果做错了轻则测试数据被污染重则生产环境出事故。所以我从来不做“一刀切”式的修复而是把修复动作按风险等级分成四级。第一级是重试类对应瞬时故障。比如网络请求超时、偶发的页面渲染延迟、临时性的服务抖动。这类修复动作最简单就是等待几秒后重新执行失败的操作但要注意重试次数必须有上限而且每次重试的间隔要逐次递增避免雪崩效应。我曾见过一个团队的重试策略是失败后立刻重试结果服务还没恢复重试请求把服务彻底压垮了。第二级是状态恢复类对应环境状态问题。比如登录态失效、测试账号被锁定、本地缓存过期、数据库脏数据干扰。这类修复动作通常包含重新登录、刷新Token、调用重置接口、清理缓存等。执行之前要确认这些动作不会影响其他正在运行的测试用例。最典型的问题是一个测试账号被多个用例共享你在修复时重置了账号可能把另一个正在跑的用例也搞挂了。第三级是结构变更类对应前端改版或配置漂移导致的问题。最常见的场景是UI自动化跑得好好的突然某天因为前端给按钮换了个class导致选择器定位失败。这类问题用重试解决不了必须更新定位器或者改用更健壮的定位策略。系统可以自动扫描页面上相似的元素用文本内容、位置坐标、相邻元素关系等属性生成新的定位器然后在测试环境验证一下能否定位成功再替换掉旧的定位器。第四级是服务修复类对应依赖服务异常。比如某个服务进程挂掉、容器被杀死、数据库连接数耗尽。这类修复动作通常需要调用运维平台的API执行重启服务、扩容实例、清理连接池等操作。风险等级极高必须严格控制权限一般只允许在测试环境自动执行生产环境一律转人工审批。3.2 把修复动作封装成原子操作前面说了这么多修复动作最终要落地到代码我建议把所有修复逻辑都封装成独立的、可复用的原子操作。每个操作只做一件事输入是归因对象输出是修复结果。这样的设计有几个好处第一方便做单元测试第二后续扩展新的修复方式不用改原有逻辑第三可以在每个操作外面套统一的日志、审计、超时控制。拿UI自动化举例我封装过这样一批操作class RepairAction: def execute(self, context) - RepairResult: raise NotImplementedError class RetryAction(RepairAction): def __init__(self, max_retries3, base_delay2): self.max_retries max_retries self.base_delay base_delay def execute(self, context): for i in range(self.max_retries): time.sleep(self.base_delay * (i 1)) try: context.test_func(*context.args, **context.kwargs) return RepairResult(successTrue, message重试成功) except Exception as e: last_error e return RepairResult(successFalse, messagef重试失败: {last_error}) class ReloginAction(RepairAction): def execute(self, context): # 调用登录接口刷新token并更新全局session token api_login(context.config.username, context.config.password) context.session.update_token(token) return RepairResult(successbool(token), message重新登录完成)这里有个容易踩的坑原子操作内部的异常一定不能直接抛出去要统一转换成RepairResult对象返回。因为修复引擎需要汇总所有操作的结果决定要不要继续下一轮验证、要不要通知人工。如果中途抛异常整个自愈流程就中断了后面的熔断和审计逻辑都执行不到。审计日志也是必须的。每个原子操作执行完都要把操作名称、入参、出参、耗时、执行时间记录下来。这些数据一是用来复盘“这个自愈系统到底干了啥”二是用来优化归因模型和修复策略。比如你发现某类修复操作成功率很低就应该考虑调整策略或者干脆不自动执行直接转人工。3.3 自动生成代码补丁的注意事项级别最高的自动修复动作是“让AI直接生成代码补丁”。这个方向确实有想象力但目前在实践中风险还是偏大我建议谨慎推进。如果你确实想在项目里试水有几个必须遵守的原则。第一AI生成补丁只能作用于测试代码不能直接作用于被测系统的源代码。比如UI自动化里出现选择器失效可以让AI基于页面快照生成一个新的定位器接口自动化里出现断言值变化可以让AI基于接口文档生成新的断言规则。这些都是测试层面的修正就算修错了影响范围也有限。第二必须做静态检查和沙箱验证。AI生成的补丁不能直接合入仓库。我的做法是先生成一个diff文件跑一遍代码规范检查比如pylint、flake8再把它应用到临时分支或沙箱环境运行对应的测试用例验证全部通过之后才会合入主分支同时自动创建一条MR附上AI归因的分析报告方便人工复核。这个流程看似繁琐但能挡住绝大多数AI误修造成的二次破坏。第三一定要限制AI修改文件的范围。在Prompt里明确说“你只能修改tests目录下的文件”“你只能新增或修改元素定位器禁止修改被测对象”。大模型在自由度太高的时候反而容易出问题给它带上约束输出质量会稳定很多。我还见过一个离谱案例AI为了修复一个UI自动化用例直接把被测应用的配置文件改掉了结果整个环境起不来。这就是没限制范围导致的。3.4 修复不成功的熔断机制自愈系统必须有熔断机制否则它会像一台失控的机器反复撞墙。我的设定是每一条失败记录最多允许两轮自愈每轮包含一次归因和一次修复修复后做验证。第一轮自愈失败允许带着新的上下文进入第二轮第二轮再失败直接转人工并且锁定这条记录系统不再自动处理。为什么要限定两轮而不是一直循环下去因为大多数问题要么是简单的瞬时故障一轮重试就能解决要么是结构性问题需要改代码改配置自愈系统不一定每次都能搞定。如果一直循环一方面浪费时间另一方面可能把环境搞得越来越乱。比如数据库被反复重置可能导致其他用例的数据依赖全部断裂。还有一个重要细节熔断要带全局限流。如果同一个时间段内有大量失败用例涌入自愈系统不应该对每一例都执行归因和修复否则会造成“修复风暴”。我的做法是按失败类型做聚合比如一小时内出现一百次元素定位失败先聚类成一条事件只做一次深层归因然后批量处理对修复动作也设置最大并发数超出部分排队等待。这样既能控制成本也能避免自愈行为本身对被测系统造成额外压力。4. 实操搭建一条最小可用的自愈链路4.1 环境准备与技术选型这一节我从零开始讲刷卡上车。我选用的组合是Python 3.11 Playwright pytest Ollama本地模型这套组合的好处是全链路开源不依赖特定云平台改造成本低。如果你做的是接口自动化把Playwright换成requests或httpx就行架构不变如果你用Selenium或Appium思路也完全通用。先做环境准备# 创建虚拟环境 python3 -m venv healenv source healenv/bin/activate # 安装依赖 pip install pytest playwright pip install ollama # 安装浏览器内核 playwright install chromium # 拉取本地大模型我用的是qwen2.5:7b显存8G以上跑起来比较舒服 ollama pull qwen2.5:7b安装完之后验证一下Ollama能否正常调用跑一条简单的Python代码发送一个“你好”的请求看看返回是否正常。这一步一定要先验证不然后面排错的时候分不清是模型问题还是代码问题。项目结构我建议按下面的方式组织self_healing/ ├── core/ │ ├── context.py # 失败上下文对象 │ ├── diagnosis.py # 归因引擎规则LLM │ ├── repair.py # 修复动作封装 │ └── verifier.py # 验证与闭环 ├── rules/ │ └── common.yaml # 规则引擎配置 ├── prompts/ │ └── diagnose.txt # LLM归因Prompt模板 ├── tests/ │ ├── test_order.py # 被测的自动化用例 │ └── conftest.py # pytest钩子 └── main.py # 自愈入口也可以直接被pytest调用4.2 失败捕获与上下文采集的实现在pytest框架里捕获失败最标准的方式是用pytest_runtest_makereport钩子。每次用例结束后这个钩子会拿到一份TestReport对象里面有passed、failed、skipped状态。我们只需要在failed时触发自愈流程。conftest.py里可以这样写import pytest from core.context import FailureContext from core.diagnosis import diagnose from core.repair import repair from core.verifier import verify pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: context FailureContext.from_test_item(item, report) heal_result run_self_healing(item, context) if heal_result.success: # 自愈成功把用例状态标记为通过并记录note report.outcome passed report.user_properties.append((self_healed, true)) def run_self_healing(item, context): # 第一轮自愈 diag diagnose(context) result repair(diag, context) if result.success and verify(item, context): return result # 第二轮自愈 context.refresh() diag diagnose(context) result repair(diag, context) if result.success and verify(item, context): return result # 熔断通知人工 notify_human(context, diag, result) return result这里注意一个细节把失败用例强行改成passed在团队协作中可能会引发争议。所以我在report的user_properties里加了self_healed标记在最终测试报告里能看到哪些用例是被自愈救活的方便复盘。也可以选择不把状态改成passed而是在passed之外增加一个self_healed状态看团队怎么约定。FailureContext类的设计很关键它负责把pytest的item和report转成标准化的上下文对象。代码可以参考下面这样class FailureContext: def __init__(self, test_name, error_type, error_message, page_snapshot, network_log, dom_fragment): self.test_name test_name self.error_type error_type self.error_message error_message self.page_snapshot page_snapshot self.network_log network_log self.dom_fragment dom_fragment classmethod def from_test_item(cls, item, report): # 从item里拿浏览器实例或请求session采集现场信息 page item.funcargs.get(page) snapshot None network_log [] dom_fragment if page: snapshot page.screenshot() dom_fragment page.locator(body).inner_text()[:2000] # 这里省略从CDP里拿network log的代码 return cls( test_nameitem.name, error_typereport.longrepr.reprcrash.message.split(:)[0] if report.longrepr else Unknown, error_messagestr(report.longrepr), page_snapshotsnapshot, network_lognetwork_log, dom_fragmentdom_fragment ) def refresh(self): # 采集第二轮的现场数据 pass def to_prompt_text(self): # 序列化成给LLM的文本块 return f 测试名称: {self.test_name} 异常类型: {self.error_type} 异常信息: {self.error_message} 页面片段: {self.dom_fragment} 网络日志: {self.network_log} 4.3 AI归因调用的实现与Prompt优化归因引擎不能只写一个单纯调用LLM的函数我按“先规则、后LLM”的顺序来实现。代码如下import json import re import yaml import ollama def load_rules(pathrules/common.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def match_rule(context, rules): for rule in rules[rules]: conditions rule[conditions] # 简单示例检查异常类型是否匹配 if context.error_type conditions.get(error_type): if keyword in conditions and conditions[keyword] not in context.error_message: continue return rule[result] return None def diagnose_with_llm(context): prompt_template open(prompts/diagnose.txt, encodingutf-8).read() prompt prompt_template.replace({{CONTEXT}}, context.to_prompt_text()) response ollama.chat( modelqwen2.5:7b, messages[{role: user, content: prompt}] ) text response[message][content] # 容错解析提取第一个JSON块 json_match re.search(r\{.*\}, text, re.S) if not json_match: return None try: return json.loads(json_match.group()) except json.JSONDecodeError: return None def diagnose(context): rules load_rules() rule_result match_rule(context, rules) if rule_result: return rule_result llm_result diagnose_with_llm(context) if llm_result and llm_result.get(confidence, 0) 0.6: return llm_result return { failure_type: unknown, confidence: 0, root_cause_summary: 无法自动归因需要人工介入, suggested_actions: [manual_review], risk_level: high }Prompt模板我单独拿一个文件维护不用代码字符串拼接写起来清晰。模板内容我前面贴过一版这里说几个实测下来很有用的补充指令“如果提供的上下文不足以判断原因请明确输出failure_type为unknown不要猜测。”这条能显著降低幻觉。“请参考之前出现的相同错误模式在根因分析中对齐行业常见经验。”这条对提升准确率有帮助但不要强求。“不要输出Markdown代码块标记只输出JSON。”减少解析时报错的概率。模型参数方面我建议把temperature设到0.2以下甚至直接用0。归因任务本质是分析判断不是创意写作温度太高会让输出忽东忽西影响自愈的稳定性。4.4 修复动作落地与验证闭环修复引擎拿到诊断结果后先去一个动作注册表里找对应的处理函数。我用一个字典做映射key是failure_typevalue是修复动作列表每个动作是一个实现了execute方法的对象。ACTION_REGISTRY { timeout: [RetryAction(max_retries2, base_delay3)], login_expired: [ReloginAction(), RetryAction(max_retries1)], element_not_found: [UpdateLocatorAction(), RetryAction(max_retries1)], data_conflict: [ResetDataAction(), RetryAction(max_retries1)], service_unavailable: [WaitServiceHealthyAction(timeout30), RetryAction(max_retries2)], } def repair(diagnosis, context): if diagnosis[confidence] 0.6: return RepairResult(successFalse, message置信度过低不执行自动修复) actions ACTION_REGISTRY.get(diagnosis[failure_type], []) if not actions: return RepairResult(successFalse, message没有匹配的修复动作) for action in actions: if action.risk_level high and not context.allow_high_risk: return RepairResult(successFalse, message高风险动作被拦截) result action.execute(context) if not result.success: return result return RepairResult(successTrue, message修复动作执行完成)验证闭环的动作在main的run_self_healing里已经体现了每次修复完成后重新跑一遍失败的用例通过才算闭环。这里有一个细节重跑用例时避免跟当前全局的pytest会话冲突。我一般用一个独立的runner直接用pytest.main收集单个测试节点执行把结果返回到自愈流程里。如果验证失败别急着走第二轮归因。先更新一下上下文把“上次修复后的最新状态”加进去。比如重试之后页面Title变了或者接口返回值变了这些都是关键信息。不带新信息就重新归因大概率得到跟上一轮一样的结论那第二轮自愈就没有意义。5. 常见问题与排查技巧实录5.1 高频问题速查表我把实际运行中遇到的高频问题整理成一个速查表方便你对照排查。问题现象可能原因解决方案大模型返回的不是合法JSON模型被Prompt带偏或上下文太长导致截断正则提取首个JSON块限制上下文长度开关strict模式修复后验证仍然失败陷入循环修复方向错误或修复动作不完整限定最大自愈轮数第二轮不成功强制人工自愈流程本身耗时过长模型推理慢或设置了过多修复动作设置模型调用超时高风险修复动作最多只跑一个一个时间段内失败激增引发修复风暴系统或环境发生全局故障按错误类型聚合设置全局修复并发上限修复动作影响了其他用例测试数据或账号被共享修复前加资源锁修复动作限定只处理本用例数据AI误判了根因修复了无关部分上下文不全或Prompt引导不足增加上下文采集维度要求AI输出confidence并设置阈值5.2 如何降低AI幻觉误判幻觉是AI归因最大的敌人。我在实践中摸索出几个降低幻觉的手段效果都很明显。第一个手段是给AI“不猜的权利”。在Prompt里明确写“如果信息不足请返回unknown”。这听起来很简单但效果立竿见影。因为没有这句话的时候模型倾向于给出一个看似合理的猜测有了这句话它才敢说不知道。归因输出unknown之后系统不会执行修复动作而是直接转人工相当于把误判风险挡在了门外。第二个手段是设置置信度阈值双保险。模型说“confidence为0.9”不等于它真的那么确定这只是模型自己的评估本身可能不准。所以我会结合规则的命中情况和修复验证的成功率动态调整阈值。比如某个failure_type对应的修复动作成功率一直很低那就把这个类型的自动执行阈值提高或者直接禁用自动修复。用数据反过来校准系统比单纯信任模型的置信度靠谱得多。第三个手段是构建历史案例库。把每次成功修复的案例上下文摘要、归因结果、修复动作、修复是否成功存下来后续遇到同类问题时先用检索相似案例的方式做一次匹配把匹配到的历史案例作为“参考信息”喂给模型。模型有了前车之鉴判断会谨慎很多。这块功能我已经在用本质上是给模型加了一个外挂记忆库。5.3 被坑过才懂的几条实战心得第一先做规则再做AI别一上来就上大模型。很多人做自愈链路第一个念头就是“我要搞个Agent”但Agent的调试难度和时间成本远超想象。我建议先把规则引擎跑顺把采集、修复、验证这些基础设施都搭好再逐步把AI接入到规则覆盖不了的场景里。这样即使AI效果不理想系统也可以靠规则引擎兜底运行。第二自愈链路要重视“可观测性”而不是“美观度”。系统里每一个归因、每一次修复、每一轮验证都要有日志、有指标、有轨迹。我甚至可以回放某次自愈的完整过程就像调试器单步执行一样。没有这个能力你很难判断是归因错了还是修复动作写错了还是验证逻辑出问题了。没有可观测性这个系统就是个黑盒出事了根本无从下手。第三修复动作一定要做资源隔离。尤其是重置测试数据、重启服务这类高影响操作一定要把影响范围限制在当前用例相关的资源上。比如重置订单数据时只删除当前这个订单ID关联的数据绝对不能清空整张表。我见过一次教训一个自愈脚本为了修复“订单创建失败”直接truncate了测试库的订单表结果旁边另一条正在跑报表的用例直接挂了。这种事故比不修还严重。第四自愈不是万能的边界要画清楚。什么能自愈什么必须人工在系统设计阶段就要定义好。比如代码逻辑错误导致的断言失败这类问题自愈系统不应该尝试去“修”因为修了也可能掩盖真实的Bug。边界之内自动处理边界之外明确抛给人工。把这句话写在团队的约定文档里比写在代码注释里更有用。最后再分享一个小技巧给每个自愈案例都落一个“复盘”标记。系统运行一段时间之后定期去看哪些类型的问题反复出现、哪些修复动作经常成功、哪些归因结果被人工纠正了。这些数据不只是优化系统用还能反向暴露被测系统的问题。比如某个元素选择器隔三岔五就失效说明前端团队对测试属性不重视这时候就该推动开发规范了。自愈链路真正有价值的地方不只是把问题修好而是通过自动化的沉淀倒逼整个研发流程变得更好。 AI驱动自动化自愈链路：失败归因与自动修复的完整指南
做自动化测试和自动化运维的朋友应该都有过这种体验晚上十一点监控群突然弹出一条失败告警你眯着眼打开电脑翻日志、查截图、复现问题最后发现是某个页面元素被前端改了个class或者某个依赖服务昨晚升级导致响应超时。修好之后第二天换了个场景又炸一次。传统自动化的本质其实是“重复地发现问题”而不是“解决问题”。AI驱动的自动化自愈链路想做的就是把这套逻辑倒过来——让系统自己完成失败归因、自己下判断、自己执行修复、自己验证闭环。这篇文章我会从整体设计、归因原理、修复策略、落地方案和常见坑位五个维度展开把这套链路从思路到代码完整讲一遍。适合正在做自动化测试、自动化运维、以及想在现有脚本体系里引入AI能力的工程师参考。1. 先搞清楚我们到底在解决什么问题1.1 传统自动化的三个死穴第一个死穴是“靠人肉盯”。自动化跑起来之后脚本本身不会思考只知道红了就是红了。问题是红了之后呢还是得人去看。你想想如果一晚上跑一千条用例失败三十条哪怕成功率都到97%了你还是得逐条点开日志去判断哪些是代码Bug、哪些是环境抖动、哪些是前端改版导致的选择器失效。这个排查过程极其消耗精力而且完全是在重复劳动。第二个死穴是“规则永远写不完”。有些团队会给自动化框架加一些失败重试的机制比如失败之后自动重跑一次或者遇到特定错误码就自动重启服务。这类规则确实管用但规则的覆盖范围始终有限。今天加一条“超时重试”明天加一条“登录失效自动重登”后天又冒出一种“弹窗拦截导致点击失败”。规则越写越多最终变成一团乱麻而且新出现的异常类型永远没法第一时间覆盖。第三个死穴是“环境沾了锅就没人管”。很多失败其实是环境问题比如测试数据库连接池满了、测试账号被锁、依赖服务没起来。这类问题本身不难修但它会淹没掉真正需要开发介入的Bug。一个自愈链路真正要解决的就是这三件事快速判断失败属于哪一类、跳过或修复环境类问题、把真正需要人处理的异常精准地抛出来。1.2 自愈链路的整体设计四层结构我把“自愈”拆成了四层每一层只做一件事层与层之间通过标准数据结构通信这样整个系统才不至于变成一座屎山。第一层是上下文采集层。失败发生后系统立刻把能拿到的信息全部搜集起来包括异常堆栈、页面截图、DOM快照、网络请求记录、控制台日志、接口响应报文等。这一层的关键不是“尽量多”而是“带着目的去采集”。比如UI自动化重点抓页面状态接口自动化重点抓请求和响应服务端任务重点抓进程状态和日志时间线。第二层是失败归因层。采集完上下文之后先交给规则引擎做一轮快速匹配。如果规则引擎能命中直接输出结构化结论如果命中不了再交给大模型做语义分析让它基于上下文推断可能原因并输出同样结构的结果。这里的核心原则是“规则兜底、AI覆盖未知”。第三层是自动修复层。拿到归因结论之后系统根据原因类别执行对应的修复动作。修复动作要封装成原子操作比如重试、刷新登录态、重置测试数据、更新元素定位器、重启依赖服务等。每个动作必须幂等、可回滚、有超时控制。第四层是验证闭环层。修复执行完之后自动重新运行刚才失败的用例或任务。验证通过就算自愈成功验证失败就再做一轮归因超过最大轮数就熔断升级给人工处理。没有这一层自愈就是一条没有反馈的流水线你不知道修复到底有没有效。这四个层级不是物理上必须拆成四个服务而是逻辑上必须分开尤其是归因和修复绝不能混在一个函数里。否则你会遇到“又做诊断又动手”的混乱状态出了问题根本没法追踪。1.3 为什么不是纯AI也不是纯规则很多人一听“AI驱动”就觉得应该让大模型接管一切让它自己看日志、自己改代码、自己处理一切异常。我的意见是在生产环境里千万别这么干原因很现实。第一纯AI的成本高而且慢。一次归因调用如果走云端大模型单次耗时可能三五秒如果失败用例多光归因就排队排半天。加上token费用一晚上跑几百次成本不容忽视。而很多失败其实用几条if-else就能判断出来比如“登录超时”、“选择器找不到”、“断言数值不匹配”根本不需要动用大模型。第二纯AI有幻觉风险。大模型在没有足够上下文的时候会一本正经地瞎编原因。如果这个编出来的原因直接驱动了修复动作那后果可能非常严重。比如模型认为“接口返回500是因为数据库连接池满了”于是触发数据库重启但实际上根因是代码里有个死循环。一次误判可能让整个环境雪上加霜。第三纯规则的上限很低。规则是有限集合环境是无限集合你永远写不出能覆盖所有异常类型的规则。而大模型的语义理解能力恰好能处理那些“没见过但描述一下就能推断”的场景。所以我的选择是先用规则做快速通道再让AI做疑难杂症通道同时把AI的输出约束成结构化JSON并且标注置信度低置信度一律不自动执行修复转人工。这个思路是所有自愈链路设计的核心基调。2. 失败归因让系统先学会“看懂失败”2.1 归因前提先把失败现场的“证据链”做齐全做失败归因就像破案你不能只凭一句话下定论。很多人在这一步犯的错误是只把异常信息丢给大模型然后问“为什么失败”。结果大模型回答得模棱两可因为你没给它足够的信息。想让归因质量高首先要确保证据链完整。我的做法是设计一个统一的Context对象不管什么类型的自动化任务失败之后都往这个对象里填充标准字段。比如UI自动化任务会填充页面URL、Title、截图路径、DOM关键节点快照、最近十次网络请求列表、浏览器控制台日志、执行的操作历史。接口自动化任务会填充请求方法、请求URL、请求头、请求体、响应状态码、响应体、耗时、接口依赖的服务名称。这些字段不一定要全部有但能填的都填上。为什么这么做因为大模型本质上是一个模式匹配器你给它的上下文越丰富它匹配到正确原因的概率就越高。有一个小细节截图一定要用Base64编码塞进Prompt吗不一定。多数大模型能读图但读图的成本更高、响应更慢而且对日志和代码类问题帮助有限。我的建议是截图先存盘作为人工复核的依据Prompt里主要放文本化的日志和状态信息。采集阶段还有一个容易被忽略的点采集动作本身要控制耗时。比如DOM快照很大整个页面序列化出来可能几十万字符真把这些都塞给大模型一是token爆炸二是噪声太多。所以我会做裁剪获取页面关键元素的文本内容、输入框的值、可见性状态以及距离当前操作最近的区域节点。规则是“宁缺毋滥”不要为了追求全面而采集一堆无用信息。2.2 规则引擎快速命中80%的已知问题规则引擎听起来简单实际上也有设计门道。我的建议是不要写一大堆互相纠缠的if-else而是把规则抽象成“条件模板 结果模板”。每个规则包含一组匹配条件和一组输出结果。举个例子一个典型的规则可以这样写当异常类型是TimeoutError并且重试次数等于0并且最近一次网络请求的响应时间超过5秒时输出“可能原因网络抖动或服务响应缓慢建议动作延迟重试、降低超时阈值”。另一个规则当异常类型是NoSuchElementException并且页面Title和上一轮相同并且页面中出现“系统繁忙”字样输出“可能原因后端服务异常导致页面未正常渲染建议动作检查服务健康状态、等待服务恢复后重试”。规则引擎的优势是零成本、零延迟、确定性高。它虽然在扩展性上不如大模型但足以覆盖绝大多数高频失败场景。实际操作中我会把规则写在YAML或JSON文件里而不是硬编码在代码中这样后续维护规则不需要改代码重新发布。规则合并的逻辑也要做如果多个规则同时命中按预设优先级取一个置信度最高的结果。有人会问规则和AI的边界怎么划分我个人的经验是凡是能通过“异常类型 几个关键字段值”直接得出结论的都不需要AI处理凡是需要综合多段日志理解前后逻辑的才交给AI。比如“登录失败”和“权限不足”这两个问题如果只靠状态码判断可能都是401但日志里一个是因为token过期一个是因为用户角色不对这时候规则很难区分就需要AI读日志上下文做判断。2.3 LLM语义归因处理规则覆盖不到的20%当规则引擎没有命中时就轮到LLM上场了。这里说的LLM既可以是云端的大模型API也可以是本地部署的开源模型比如通过Ollama跑的Qwen或Llama系列。我的建议是如果对数据安全要求高优先本地部署如果只做测试环境用云端API也完全没问题。调用LLM做归因最关键的是Prompt设计。我见过很多人直接把原始日志一股脑塞给AI然后问“这是为什么”输出基本没法用。一个合格的归因Prompt至少要包含以下部分系统角色设定你是一名资深测试工程师擅长分析自动化任务失败原因、任务目标请根据以下失败上下文判断失败原因并给出修复建议、结构化上下文把Context对象序列化成清晰的文本块按字段分组、输出格式要求严格输出JSON包含failure_type、confidence、root_cause_summary、suggested_actions、risk_level等字段。示例Prompt长这样你是一名资深测试工程师正在协助分析一次自动化测试失败的原因。 以下是本次失败现场的完整上下文 页面URL: https://example.com/order/create 页面标题: 创建订单 异常类型: ElementNotFoundError 异常信息: 找不到元素 [data-testidsubmit-btn] DOM片段: div classbtn-group ... button classbtn提交/button ... /div 最近操作: 点击提交按钮 网络请求: POST /api/order 返回 200耗时 320ms 请基于以上信息判断失败原因并按以下JSON格式输出不要输出任何其他内容 { failure_type: element_not_found, confidence: 0.0-1.0, root_cause_summary: 简要说明根因, suggested_actions: [动作1, 动作2], risk_level: low|medium|high }为什么要强调JSON格式输出因为归因结果要被修复引擎直接消费。如果AI输出一段散文你还得再写一个文本解析器去抽关键信息解析错了又是新的麻烦。用JSON规范化输出解析简单、容错容易、后续存数据库做历史分析也方便。实测下来Qwen和Llama这类模型在遵循JSON格式方面已经做得很好了偶尔会多输出一些解释文字我在代码里会做一层容错处理截取第一个JSON块来解析。2.4 归因结果的结构化让修复引擎听得懂归因的结果不能只是一个字符串描述它应该是一个结构化的对象。这个对象里至少要包含四个字段归因类别、置信度、原因描述、建议动作列表。归因类别我建议设计一个枚举不要用自由文本否则修复引擎没法做分支判断。常见的类别可以包括网络超时类、元素定位类、登录态失效类、数据状态污染类、服务不可用类、断言失败类、脚本逻辑Bug类、未知类型。每一类对应一组修复策略。置信度字段是自愈链路里最重要的安全阀。我的设定是置信度低于0.6的结论不允许自动执行修复只能转人工0.6到0.8之间的结论允许执行低风险的修复动作比如重试、等待、刷新登录态0.8以上才可以尝试高风险的修复动作比如自动生成代码补丁、重启服务。这个阈值不是拍脑袋定的我会在系统运行一段时间后根据人工复核通过率动态调整。原因描述和动作建议的生成也要注意可读性。原因描述要能让一个没参与过这个任务的人看懂动作建议要具体比如“更新元素定位器为data-testidsubmit-btn”而不是“修复元素”。这不仅仅是为了给修复引擎用也是为了让最终收到告警的开发人员能快速理解问题背景。3. 自动修复从“诊断”到“下处方”的安全落地3.1 修复策略不是蛮力重试而是分级处理修复动作是自愈链路里风险最高的环节。一个自动化脚本失败后系统要替人做决定这个决定如果做错了轻则测试数据被污染重则生产环境出事故。所以我从来不做“一刀切”式的修复而是把修复动作按风险等级分成四级。第一级是重试类对应瞬时故障。比如网络请求超时、偶发的页面渲染延迟、临时性的服务抖动。这类修复动作最简单就是等待几秒后重新执行失败的操作但要注意重试次数必须有上限而且每次重试的间隔要逐次递增避免雪崩效应。我曾见过一个团队的重试策略是失败后立刻重试结果服务还没恢复重试请求把服务彻底压垮了。第二级是状态恢复类对应环境状态问题。比如登录态失效、测试账号被锁定、本地缓存过期、数据库脏数据干扰。这类修复动作通常包含重新登录、刷新Token、调用重置接口、清理缓存等。执行之前要确认这些动作不会影响其他正在运行的测试用例。最典型的问题是一个测试账号被多个用例共享你在修复时重置了账号可能把另一个正在跑的用例也搞挂了。第三级是结构变更类对应前端改版或配置漂移导致的问题。最常见的场景是UI自动化跑得好好的突然某天因为前端给按钮换了个class导致选择器定位失败。这类问题用重试解决不了必须更新定位器或者改用更健壮的定位策略。系统可以自动扫描页面上相似的元素用文本内容、位置坐标、相邻元素关系等属性生成新的定位器然后在测试环境验证一下能否定位成功再替换掉旧的定位器。第四级是服务修复类对应依赖服务异常。比如某个服务进程挂掉、容器被杀死、数据库连接数耗尽。这类修复动作通常需要调用运维平台的API执行重启服务、扩容实例、清理连接池等操作。风险等级极高必须严格控制权限一般只允许在测试环境自动执行生产环境一律转人工审批。3.2 把修复动作封装成原子操作前面说了这么多修复动作最终要落地到代码我建议把所有修复逻辑都封装成独立的、可复用的原子操作。每个操作只做一件事输入是归因对象输出是修复结果。这样的设计有几个好处第一方便做单元测试第二后续扩展新的修复方式不用改原有逻辑第三可以在每个操作外面套统一的日志、审计、超时控制。拿UI自动化举例我封装过这样一批操作class RepairAction: def execute(self, context) - RepairResult: raise NotImplementedError class RetryAction(RepairAction): def __init__(self, max_retries3, base_delay2): self.max_retries max_retries self.base_delay base_delay def execute(self, context): for i in range(self.max_retries): time.sleep(self.base_delay * (i 1)) try: context.test_func(*context.args, **context.kwargs) return RepairResult(successTrue, message重试成功) except Exception as e: last_error e return RepairResult(successFalse, messagef重试失败: {last_error}) class ReloginAction(RepairAction): def execute(self, context): # 调用登录接口刷新token并更新全局session token api_login(context.config.username, context.config.password) context.session.update_token(token) return RepairResult(successbool(token), message重新登录完成)这里有个容易踩的坑原子操作内部的异常一定不能直接抛出去要统一转换成RepairResult对象返回。因为修复引擎需要汇总所有操作的结果决定要不要继续下一轮验证、要不要通知人工。如果中途抛异常整个自愈流程就中断了后面的熔断和审计逻辑都执行不到。审计日志也是必须的。每个原子操作执行完都要把操作名称、入参、出参、耗时、执行时间记录下来。这些数据一是用来复盘“这个自愈系统到底干了啥”二是用来优化归因模型和修复策略。比如你发现某类修复操作成功率很低就应该考虑调整策略或者干脆不自动执行直接转人工。3.3 自动生成代码补丁的注意事项级别最高的自动修复动作是“让AI直接生成代码补丁”。这个方向确实有想象力但目前在实践中风险还是偏大我建议谨慎推进。如果你确实想在项目里试水有几个必须遵守的原则。第一AI生成补丁只能作用于测试代码不能直接作用于被测系统的源代码。比如UI自动化里出现选择器失效可以让AI基于页面快照生成一个新的定位器接口自动化里出现断言值变化可以让AI基于接口文档生成新的断言规则。这些都是测试层面的修正就算修错了影响范围也有限。第二必须做静态检查和沙箱验证。AI生成的补丁不能直接合入仓库。我的做法是先生成一个diff文件跑一遍代码规范检查比如pylint、flake8再把它应用到临时分支或沙箱环境运行对应的测试用例验证全部通过之后才会合入主分支同时自动创建一条MR附上AI归因的分析报告方便人工复核。这个流程看似繁琐但能挡住绝大多数AI误修造成的二次破坏。第三一定要限制AI修改文件的范围。在Prompt里明确说“你只能修改tests目录下的文件”“你只能新增或修改元素定位器禁止修改被测对象”。大模型在自由度太高的时候反而容易出问题给它带上约束输出质量会稳定很多。我还见过一个离谱案例AI为了修复一个UI自动化用例直接把被测应用的配置文件改掉了结果整个环境起不来。这就是没限制范围导致的。3.4 修复不成功的熔断机制自愈系统必须有熔断机制否则它会像一台失控的机器反复撞墙。我的设定是每一条失败记录最多允许两轮自愈每轮包含一次归因和一次修复修复后做验证。第一轮自愈失败允许带着新的上下文进入第二轮第二轮再失败直接转人工并且锁定这条记录系统不再自动处理。为什么要限定两轮而不是一直循环下去因为大多数问题要么是简单的瞬时故障一轮重试就能解决要么是结构性问题需要改代码改配置自愈系统不一定每次都能搞定。如果一直循环一方面浪费时间另一方面可能把环境搞得越来越乱。比如数据库被反复重置可能导致其他用例的数据依赖全部断裂。还有一个重要细节熔断要带全局限流。如果同一个时间段内有大量失败用例涌入自愈系统不应该对每一例都执行归因和修复否则会造成“修复风暴”。我的做法是按失败类型做聚合比如一小时内出现一百次元素定位失败先聚类成一条事件只做一次深层归因然后批量处理对修复动作也设置最大并发数超出部分排队等待。这样既能控制成本也能避免自愈行为本身对被测系统造成额外压力。4. 实操搭建一条最小可用的自愈链路4.1 环境准备与技术选型这一节我从零开始讲刷卡上车。我选用的组合是Python 3.11 Playwright pytest Ollama本地模型这套组合的好处是全链路开源不依赖特定云平台改造成本低。如果你做的是接口自动化把Playwright换成requests或httpx就行架构不变如果你用Selenium或Appium思路也完全通用。先做环境准备# 创建虚拟环境 python3 -m venv healenv source healenv/bin/activate # 安装依赖 pip install pytest playwright pip install ollama # 安装浏览器内核 playwright install chromium # 拉取本地大模型我用的是qwen2.5:7b显存8G以上跑起来比较舒服 ollama pull qwen2.5:7b安装完之后验证一下Ollama能否正常调用跑一条简单的Python代码发送一个“你好”的请求看看返回是否正常。这一步一定要先验证不然后面排错的时候分不清是模型问题还是代码问题。项目结构我建议按下面的方式组织self_healing/ ├── core/ │ ├── context.py # 失败上下文对象 │ ├── diagnosis.py # 归因引擎规则LLM │ ├── repair.py # 修复动作封装 │ └── verifier.py # 验证与闭环 ├── rules/ │ └── common.yaml # 规则引擎配置 ├── prompts/ │ └── diagnose.txt # LLM归因Prompt模板 ├── tests/ │ ├── test_order.py # 被测的自动化用例 │ └── conftest.py # pytest钩子 └── main.py # 自愈入口也可以直接被pytest调用4.2 失败捕获与上下文采集的实现在pytest框架里捕获失败最标准的方式是用pytest_runtest_makereport钩子。每次用例结束后这个钩子会拿到一份TestReport对象里面有passed、failed、skipped状态。我们只需要在failed时触发自愈流程。conftest.py里可以这样写import pytest from core.context import FailureContext from core.diagnosis import diagnose from core.repair import repair from core.verifier import verify pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: context FailureContext.from_test_item(item, report) heal_result run_self_healing(item, context) if heal_result.success: # 自愈成功把用例状态标记为通过并记录note report.outcome passed report.user_properties.append((self_healed, true)) def run_self_healing(item, context): # 第一轮自愈 diag diagnose(context) result repair(diag, context) if result.success and verify(item, context): return result # 第二轮自愈 context.refresh() diag diagnose(context) result repair(diag, context) if result.success and verify(item, context): return result # 熔断通知人工 notify_human(context, diag, result) return result这里注意一个细节把失败用例强行改成passed在团队协作中可能会引发争议。所以我在report的user_properties里加了self_healed标记在最终测试报告里能看到哪些用例是被自愈救活的方便复盘。也可以选择不把状态改成passed而是在passed之外增加一个self_healed状态看团队怎么约定。FailureContext类的设计很关键它负责把pytest的item和report转成标准化的上下文对象。代码可以参考下面这样class FailureContext: def __init__(self, test_name, error_type, error_message, page_snapshot, network_log, dom_fragment): self.test_name test_name self.error_type error_type self.error_message error_message self.page_snapshot page_snapshot self.network_log network_log self.dom_fragment dom_fragment classmethod def from_test_item(cls, item, report): # 从item里拿浏览器实例或请求session采集现场信息 page item.funcargs.get(page) snapshot None network_log [] dom_fragment if page: snapshot page.screenshot() dom_fragment page.locator(body).inner_text()[:2000] # 这里省略从CDP里拿network log的代码 return cls( test_nameitem.name, error_typereport.longrepr.reprcrash.message.split(:)[0] if report.longrepr else Unknown, error_messagestr(report.longrepr), page_snapshotsnapshot, network_lognetwork_log, dom_fragmentdom_fragment ) def refresh(self): # 采集第二轮的现场数据 pass def to_prompt_text(self): # 序列化成给LLM的文本块 return f 测试名称: {self.test_name} 异常类型: {self.error_type} 异常信息: {self.error_message} 页面片段: {self.dom_fragment} 网络日志: {self.network_log} 4.3 AI归因调用的实现与Prompt优化归因引擎不能只写一个单纯调用LLM的函数我按“先规则、后LLM”的顺序来实现。代码如下import json import re import yaml import ollama def load_rules(pathrules/common.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def match_rule(context, rules): for rule in rules[rules]: conditions rule[conditions] # 简单示例检查异常类型是否匹配 if context.error_type conditions.get(error_type): if keyword in conditions and conditions[keyword] not in context.error_message: continue return rule[result] return None def diagnose_with_llm(context): prompt_template open(prompts/diagnose.txt, encodingutf-8).read() prompt prompt_template.replace({{CONTEXT}}, context.to_prompt_text()) response ollama.chat( modelqwen2.5:7b, messages[{role: user, content: prompt}] ) text response[message][content] # 容错解析提取第一个JSON块 json_match re.search(r\{.*\}, text, re.S) if not json_match: return None try: return json.loads(json_match.group()) except json.JSONDecodeError: return None def diagnose(context): rules load_rules() rule_result match_rule(context, rules) if rule_result: return rule_result llm_result diagnose_with_llm(context) if llm_result and llm_result.get(confidence, 0) 0.6: return llm_result return { failure_type: unknown, confidence: 0, root_cause_summary: 无法自动归因需要人工介入, suggested_actions: [manual_review], risk_level: high }Prompt模板我单独拿一个文件维护不用代码字符串拼接写起来清晰。模板内容我前面贴过一版这里说几个实测下来很有用的补充指令“如果提供的上下文不足以判断原因请明确输出failure_type为unknown不要猜测。”这条能显著降低幻觉。“请参考之前出现的相同错误模式在根因分析中对齐行业常见经验。”这条对提升准确率有帮助但不要强求。“不要输出Markdown代码块标记只输出JSON。”减少解析时报错的概率。模型参数方面我建议把temperature设到0.2以下甚至直接用0。归因任务本质是分析判断不是创意写作温度太高会让输出忽东忽西影响自愈的稳定性。4.4 修复动作落地与验证闭环修复引擎拿到诊断结果后先去一个动作注册表里找对应的处理函数。我用一个字典做映射key是failure_typevalue是修复动作列表每个动作是一个实现了execute方法的对象。ACTION_REGISTRY { timeout: [RetryAction(max_retries2, base_delay3)], login_expired: [ReloginAction(), RetryAction(max_retries1)], element_not_found: [UpdateLocatorAction(), RetryAction(max_retries1)], data_conflict: [ResetDataAction(), RetryAction(max_retries1)], service_unavailable: [WaitServiceHealthyAction(timeout30), RetryAction(max_retries2)], } def repair(diagnosis, context): if diagnosis[confidence] 0.6: return RepairResult(successFalse, message置信度过低不执行自动修复) actions ACTION_REGISTRY.get(diagnosis[failure_type], []) if not actions: return RepairResult(successFalse, message没有匹配的修复动作) for action in actions: if action.risk_level high and not context.allow_high_risk: return RepairResult(successFalse, message高风险动作被拦截) result action.execute(context) if not result.success: return result return RepairResult(successTrue, message修复动作执行完成)验证闭环的动作在main的run_self_healing里已经体现了每次修复完成后重新跑一遍失败的用例通过才算闭环。这里有一个细节重跑用例时避免跟当前全局的pytest会话冲突。我一般用一个独立的runner直接用pytest.main收集单个测试节点执行把结果返回到自愈流程里。如果验证失败别急着走第二轮归因。先更新一下上下文把“上次修复后的最新状态”加进去。比如重试之后页面Title变了或者接口返回值变了这些都是关键信息。不带新信息就重新归因大概率得到跟上一轮一样的结论那第二轮自愈就没有意义。5. 常见问题与排查技巧实录5.1 高频问题速查表我把实际运行中遇到的高频问题整理成一个速查表方便你对照排查。问题现象可能原因解决方案大模型返回的不是合法JSON模型被Prompt带偏或上下文太长导致截断正则提取首个JSON块限制上下文长度开关strict模式修复后验证仍然失败陷入循环修复方向错误或修复动作不完整限定最大自愈轮数第二轮不成功强制人工自愈流程本身耗时过长模型推理慢或设置了过多修复动作设置模型调用超时高风险修复动作最多只跑一个一个时间段内失败激增引发修复风暴系统或环境发生全局故障按错误类型聚合设置全局修复并发上限修复动作影响了其他用例测试数据或账号被共享修复前加资源锁修复动作限定只处理本用例数据AI误判了根因修复了无关部分上下文不全或Prompt引导不足增加上下文采集维度要求AI输出confidence并设置阈值5.2 如何降低AI幻觉误判幻觉是AI归因最大的敌人。我在实践中摸索出几个降低幻觉的手段效果都很明显。第一个手段是给AI“不猜的权利”。在Prompt里明确写“如果信息不足请返回unknown”。这听起来很简单但效果立竿见影。因为没有这句话的时候模型倾向于给出一个看似合理的猜测有了这句话它才敢说不知道。归因输出unknown之后系统不会执行修复动作而是直接转人工相当于把误判风险挡在了门外。第二个手段是设置置信度阈值双保险。模型说“confidence为0.9”不等于它真的那么确定这只是模型自己的评估本身可能不准。所以我会结合规则的命中情况和修复验证的成功率动态调整阈值。比如某个failure_type对应的修复动作成功率一直很低那就把这个类型的自动执行阈值提高或者直接禁用自动修复。用数据反过来校准系统比单纯信任模型的置信度靠谱得多。第三个手段是构建历史案例库。把每次成功修复的案例上下文摘要、归因结果、修复动作、修复是否成功存下来后续遇到同类问题时先用检索相似案例的方式做一次匹配把匹配到的历史案例作为“参考信息”喂给模型。模型有了前车之鉴判断会谨慎很多。这块功能我已经在用本质上是给模型加了一个外挂记忆库。5.3 被坑过才懂的几条实战心得第一先做规则再做AI别一上来就上大模型。很多人做自愈链路第一个念头就是“我要搞个Agent”但Agent的调试难度和时间成本远超想象。我建议先把规则引擎跑顺把采集、修复、验证这些基础设施都搭好再逐步把AI接入到规则覆盖不了的场景里。这样即使AI效果不理想系统也可以靠规则引擎兜底运行。第二自愈链路要重视“可观测性”而不是“美观度”。系统里每一个归因、每一次修复、每一轮验证都要有日志、有指标、有轨迹。我甚至可以回放某次自愈的完整过程就像调试器单步执行一样。没有这个能力你很难判断是归因错了还是修复动作写错了还是验证逻辑出问题了。没有可观测性这个系统就是个黑盒出事了根本无从下手。第三修复动作一定要做资源隔离。尤其是重置测试数据、重启服务这类高影响操作一定要把影响范围限制在当前用例相关的资源上。比如重置订单数据时只删除当前这个订单ID关联的数据绝对不能清空整张表。我见过一次教训一个自愈脚本为了修复“订单创建失败”直接truncate了测试库的订单表结果旁边另一条正在跑报表的用例直接挂了。这种事故比不修还严重。第四自愈不是万能的边界要画清楚。什么能自愈什么必须人工在系统设计阶段就要定义好。比如代码逻辑错误导致的断言失败这类问题自愈系统不应该尝试去“修”因为修了也可能掩盖真实的Bug。边界之内自动处理边界之外明确抛给人工。把这句话写在团队的约定文档里比写在代码注释里更有用。最后再分享一个小技巧给每个自愈案例都落一个“复盘”标记。系统运行一段时间之后定期去看哪些类型的问题反复出现、哪些修复动作经常成功、哪些归因结果被人工纠正了。这些数据不只是优化系统用还能反向暴露被测系统的问题。比如某个元素选择器隔三岔五就失效说明前端团队对测试属性不重视这时候就该推动开发规范了。自愈链路真正有价值的地方不只是把问题修好而是通过自动化的沉淀倒逼整个研发流程变得更好。