1. 项目概述：当UI自动化脚本“生病”时，谁来当医生？

做UI自动化测试的同行，大概都经历过这种“血压升高”的时刻：昨天还跑得顺风顺水的脚本，今天一执行就报错。页面元素ID变了，一个弹窗突然冒出来，或者某个按钮的加载状态多等了一秒……排查、定位、修改，一套流程下来，半小时就没了。如果这样的脚本有成百上千个，维护成本简直是个无底洞。我们就像消防员，四处扑灭因前端变更而燃起的“脚本之火”，疲于奔命。

这个项目，就是尝试给这个问题开一剂“自动药方”。它的核心思路非常直接：利用AI的能力，自动诊断并修复失败的UI自动化测试脚本。具体来说，我结合了OpenAI的Codex（一个强大的代码生成模型）和微软的Playwright（一个现代、可靠的浏览器自动化框架），搭建了一个能够“自愈”的测试流水线。当Playwright脚本执行失败时，系统会自动捕获错误上下文（包括错误堆栈、页面截图、最后操作的DOM片段等），将其作为“病历”提交给Codex。Codex扮演“AI医生”的角色，分析“病情”，并给出修复后的脚本代码建议，经人工或自动审核后，即可完成修复。

这不仅仅是“用AI写代码”那么简单。它触及了自动化测试工程中一个深层的痛点：脚本的脆弱性与维护的滞后性。传统的维护是反应式的，问题发生后才去处理。而这个项目探索的是一种预测式或至少是即时响应式的维护——在CI/CD流水线中，失败的测试能尝试自己“站起来”，大大缩短反馈周期，将工程师从重复的、低价值的修修补补中解放出来，去关注更复杂的测试场景设计和质量分析。

2. 核心工具选型：为什么是Codex与Playwright这对组合？

工欲善其事，必先利其器。选择Codex和Playwright，并非跟风热门技术，而是基于它们各自的特性和在这个特定场景下的完美互补性。

2.1 Playwright：稳定可靠的“执行者”与“诊断助手”

在UI自动化框架的选型上，Selenium、Cypress和Playwright是主要竞争者。我最终选择Playwright，基于以下几个关键考量：

1. 自动等待与可靠性：这是Playwright的“杀手锏”。它内置了智能等待机制，能自动等待元素可操作（如可点击、可见、启用状态），极大减少了因页面加载或网络延迟导致的“flaky tests”（不稳定的测试）。在自动修复场景中，一个稳定的执行环境是准确诊断的前提。如果框架本身不稳定，我们无法区分是脚本逻辑错误还是环境偶发问题。
2. 丰富的调试信息：Playwright在测试失败时，能提供极其丰富的上下文信息。它可以自动截取失败时的屏幕截图、录制整个测试过程的视频、捕获控制台日志和网络请求。这些信息对于AI模型理解“发生了什么”至关重要。我们可以轻松地将截图、最后操作的页面HTML片段连同错误信息一起打包，送给Codex分析。
3. 多浏览器与多语言支持：Playwright原生支持Chromium、Firefox和WebKit，确保跨浏览器行为的一致性。其API在Python、Node.js、Java、.NET中基本一致，这为项目提供了语言灵活性。本项目以Python为例，因其在AI和数据处理领域的生态优势。
4. 现代化架构：与基于WebDriver协议的Selenium相比，Playwright直接通过CDP（Chrome DevTools Protocol）等现代化协议与浏览器通信，速度更快，能力更强（如拦截网络请求、模拟移动设备）。

注意：虽然Playwright很强大，但它的选择器策略（如page.locator(‘button:has-text(“Submit”)’)）可能与团队原有的Selenium（多用XPath或CSS ID）不同。在引入时，需要评估脚本迁移或适配的成本。

2.2 Codex：具备代码上下文理解力的“AI医生”

为什么不用普通的文本生成模型，而要用Codex？原因在于“代码的上下文”。

1. 代码感知能力：Codex是在海量公开代码（尤其是GitHub）上训练而成的，它不仅仅理解自然语言，更深刻理解编程语言的语法、语义和常见模式。当你给它一段出错的Python Playwright脚本和错误信息时，它能像一个有经验的程序员一样，理解“locator.click()失败可能是因为元素不可见或已被覆盖”，并给出准确的修复建议（例如，添加一个locator.wait_for()）。
2. 长上下文与连贯性：Codex能够处理较长的代码上下文。我们可以将整个测试函数、相关的页面对象模型（POM）类、甚至自定义的辅助函数一起作为提示词（Prompt）的一部分输入，让它基于完整的代码环境进行修复，避免出现“管中窥豹”、修复一处而破坏另一处的情况。
3. 指令遵循与迭代：通过精心设计的Prompt，我们可以引导Codex进行多轮“思考”。例如，第一轮让它分析错误原因，第二轮根据分析结果生成修复代码，第三轮再对修复后的代码进行优化或解释。这种交互能力是构建有效自动修复流程的关键。

当然，使用Codex（或类似的GPT模型）需要考虑成本、API速率限制以及代码安全性（切勿将敏感代码发送至外部API）。在内部，也可以探索使用开源的、本地部署的大型代码模型作为替代方案。

3. 系统架构设计与核心流程拆解

整个自动修复系统不是一个简单的脚本，而是一个需要嵌入到CI/CD管道中的微服务或处理流程。其核心架构可以概括为“监听-诊断-处方-应用”四个环节。

3.1 整体架构视图

一个典型的集成架构如下：

[CI/CD Runner (e.g., Jenkins, GitLab CI)] | | 执行测试，捕获失败 V [测试执行与监控模块] (基于 Pytest + Playwright) | 失败时，打包错误上下文 V [错误上下文打包器] (生成：错误日志、截图、HTML、测试代码) | V [AI修复引擎] (核心：调用 Codex API，携带精心设计的 Prompt) | 获得修复建议 V [修复建议处理器] (可选：自动应用/生成PR/通知人工) | V [版本控制系统] (e.g., Git - 提交修复)

这个流程可以设置为全自动（针对简单、明确的错误）或半自动（生成修复建议，需人工审核合并）。

3.2 核心流程步骤详解

3.2.1 步骤一：失败捕获与上下文打包

这是整个流程的基石。信息越全面，AI诊断越准确。我们会在Playwright的测试框架（如Pytest）中编写一个全局的钩子函数（hook），专门用于处理测试失败的情况。

# conftest.py import pytest from playwright.sync_api import Page import json import base64 import os @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: page = item.funcargs.get("page") # 假设测试函数接收 page fixture if page: test_name = item.name # 1. 截取屏幕截图 screenshot_bytes = page.screenshot(full_page=True, type='png') screenshot_b64 = base64.b64encode(screenshot_bytes).decode('utf-8') # 2. 获取当前页面HTML主要内容（避免过大） html_snippet = page.content() # 可以截取前5000字符或通过特定选择器获取相关区域 # relevant_html = page.locator('body').inner_html()[:5000] # 3. 获取控制台错误日志（如果有） console_errors = [] # 需要在测试开始时监听console事件并收集，这里仅为示例 # 4. 获取测试源代码 test_source = open(item.module.__file__).read() if item.module.__file__ else "" # 5. 打包所有上下文信息 error_context = { "test_name": test_name, "error_type": str(call.excinfo.type.__name__), "error_message": str(call.excinfo.value), "traceback": str(call.excinfo.traceback), "screenshot_b64": screenshot_b64, "html_snippet": html_snippet[:5000], # 限制长度 "test_source": test_source, "timestamp": datetime.now().isoformat() } # 将上下文保存到文件或发送到消息队列，供修复引擎消费 context_file = f"./error_contexts/{test_name}_{int(time.time())}.json" os.makedirs(os.path.dirname(context_file), exist_ok=True) with open(context_file, 'w') as f: json.dump(error_context, f, indent=2) print(f"错误上下文已保存至: {context_file}")

实操心得：HTML片段不宜过长，否则会消耗大量Token并可能干扰AI判断。最好通过Playwright选择器定位到失败操作附近的DOM容器（如page.locator(‘#main-content’).inner_html()），只提取相关区域。截图经过Base64编码后也会很长，需要权衡。

3.2.2 步骤二：构造智能Prompt，调用AI修复引擎

这是最具技巧性的部分。Prompt的质量直接决定了修复的效果。我们不能简单地把错误堆栈扔给Codex，而需要给它清晰的“角色设定”、“任务指令”和“上下文”。

# ai_repair_engine.py import openai import json def construct_repair_prompt(error_context): """ 构造用于Codex修复的Prompt。 """ prompt_template = """ 你是一名资深的测试自动化工程师，精通Python和Playwright。你的任务是分析和修复一个失败的UI自动化测试脚本。 ## 错误上下文 - 测试名称：{test_name} - 错误类型：{error_type} - 错误信息：`{error_message}` - 相关页面HTML片段（失败时）：

{html_snippet}

## 需要修复的测试源代码 ```python {test_source}

你的任务

1. 分析：首先，请分析测试失败的根本原因。可能的原因包括：元素定位器失效、元素状态不可交互、页面未加载完成、存在弹窗遮挡、网络请求超时等。
2. 修复：然后，直接输出修复后的完整Python测试代码。请确保：
   • 修复后的代码能够解决上述错误。
   • 使用Playwright最佳实践（例如，使用明确的等待，优先使用get_by_role,get_by_text等稳健的选择器）。
   • 保持代码简洁、可读。
   • 如果原代码逻辑有误，请一并修正。
3. 解释：最后，用一两句话简要说明你做了哪些关键修改以及为什么。

请直接按以下格式输出： ANALYSIS: [你的分析] FIXED_CODE:

[修复后的完整代码]

EXPLANATION: [你的解释] """

prompt = prompt_template.format( test_name=error_context["test_name"], error_type=error_context["error_type"], error_message=error_context["error_message"], html_snippet=error_context["html_snippet"], test_source=error_context["test_source"] ) return prompt

def call_codex_for_repair(prompt): """ 调用OpenAI API（模拟Codex）获取修复建议。 实际使用需替换为正确的API密钥和模型。 """ # 注意：此处为示例，实际需配置API Key并使用合适的模型（如gpt-4-turbo-preview） client = openai.OpenAI(api_key="your-api-key")

try: response = client.chat.completions.create( model="gpt-4-turbo-preview", # 或使用专为代码优化的模型 messages=[ {"role": "system", "content": "你是一个专业的Python和Playwright代码助手。"}, {"role": "user", "content": prompt} ], temperature=0.2, # 低温度，确保输出确定性高、稳定性强 max_tokens=2000 ) return response.choices[0].message.content except Exception as e: return f"调用AI API失败: {e}"

主流程

with open(‘./error_contexts/latest_error.json‘, ’r‘) as f: context = json.load(f)

prompt = construct_repair_prompt(context) ai_response = call_codex_for_repair(prompt) print(ai_response)

#### 3.2.3 步骤三：解析AI响应与修复应用 AI返回的响应需要被解析，提取出修复后的代码，并进行后续处理。 ```python def parse_ai_response(response): """ 解析AI返回的文本，提取分析、修复代码和解释。 """ lines = response.split(‘\n‘) analysis = "" fixed_code = "" explanation = "" current_section = None code_block = False code_lines = [] for line in lines: if line.startswith(‘ANALYSIS:‘): current_section = ‘analysis‘ analysis = line.replace(‘ANALYSIS:‘, ‘‘).strip() elif line.startswith(‘FIXED_CODE:‘): current_section = ‘code‘ code_block = True elif line.startswith(‘```python‘): code_block = True elif line.startswith(‘```‘) and code_block: code_block = False fixed_code = ‘\n‘.join(code_lines) code_lines = [] elif line.startswith(‘EXPLANATION:‘): current_section = ‘explanation‘ explanation = line.replace(‘EXPLANATION:‘, ‘‘).strip() else: if current_section == ‘analysis‘ and not code_block: analysis += ‘ ‘ + line.strip() elif code_block and current_section == ‘code‘: code_lines.append(line) elif current_section == ‘explanation‘ and not code_block: explanation += ‘ ‘ + line.strip() # 清理分析 analysis = analysis.strip() explanation = explanation.strip() return { “analysis”: analysis, “fixed_code”: fixed_code, “explanation”: explanation } parsed_result = parse_ai_response(ai_response) print(“分析结果：“, parsed_result[“analysis”]) print(“\n修复代码预览：“, parsed_result[“fixed_code”][:200], “...”) print(“\n解释：“, parsed_result[“explanation”])

获得修复代码后，可以选择：

• 自动应用：直接覆盖原测试文件。风险较高，需有完备的回滚机制和测试验证。
• 生成Pull Request (PR)：更安全的方式。将修复后的代码提交到一个新的分支，并创建PR，触发一次新的CI运行，验证修复是否有效，然后由工程师合并。
• 生成报告并通知：将AI的分析、建议代码和解释生成一份报告，通过邮件或即时通讯工具发送给负责的测试工程师，由人工决策。

4. 实战案例：一个登录测试脚本的自动修复全过程

让我们通过一个具体的、简化的例子，来看整个流程如何运作。

4.1 原始脚本与模拟失败

假设我们有一个测试用户登录的脚本，使用了不够稳健的选择器。

# test_login.py def test_user_login(page): page.goto(“https://example.com/login“) # 使用可能不稳定的CSS选择器 page.locator(‘input[type=“text”]‘).fill(‘testuser‘) page.locator(‘input[type=“password”]‘).fill(‘password123‘) # 使用可能变化的文本定位按钮 page.locator(‘button:has-text(“Sign In”)‘).click() # 断言登录成功 assert page.locator(‘.welcome-message‘).is_visible()

某天，前端开发将登录按钮的文本从“Sign In”改成了“Log In”。测试执行失败，抛出TimeoutError: locator.click: Timeout 30000ms exceeded。

4.2 错误上下文打包

钩子函数捕获到失败，并生成如下error_context.json（摘要）：

{ “test_name”: “test_user_login“, “error_type”: “TimeoutError“, “error_message”: “locator.click: Timeout 30000ms exceeded. ...“, “traceback”: “...“, “html_snippet”: “<form>...<button>