从0到1搭建Test Agent：我用Pytest+LLM实现了用例自生成与自愈
关注「软件测试就业联盟」公众号，陪你走好校招求职的每一步
上周在内部分享会上，一位同事展示了他用半天时间搭出来的“玩具”：一个能读懂需求文档、自动写Pytest代码，并且在脚本跑不通时能自我修复的测试智能体。
当时台下坐着不少资深测试专家，大家的第一反应不是“这不可能”，而是陷入了沉默。 因为我们都知道，传统的“录制回放”和“关键字驱动”已经死了。2026年的测试工程师，如果不懂怎么给AI设计工具（Tools）和护栏（Guardrails），真的会寸步难行。
今天我不讲虚的概念，直接带你从0到1，拆解一个Test Agent（测试智能体）的最小可行性架构。
一、 现象：为什么Pytest需要LLM？
你可能要问：Pytest本身已经很强了，为什么还要加一层LLM（大语言模型）？
本质是执行逻辑的变更。
传统Pytest脚本是静态的。一旦页面元素ID变了，或者接口字段调整了，脚本必挂，等着人修。
而结合了LLM的Pytest是动态的。它的逻辑变成了：
“目标：验证登录功能。如果失败了，分析原因，尝试修正代码，再跑一次。”
这就是自愈（Self-Healing）的核心。
二、 架构拆解：Test Agent的大脑与手脚
一个成熟的测试智能体，绝不是简单的pip install pytest。它的核心架构长这样：
这里面有三个关键组件，缺一不可：
1. 规划器（Planner）
负责理解意图。输入：“请测试用户登录，用户名错误的情况”。
输出：结构化的测试步骤和数据准备逻辑。
2. 执行器（Executor）
这里就是Pytest的舞台。但注意，Pytest不再是主角，它是Agent调用的Tool（工具）。
3. 反思器（Reflector）
这是最关键的部分。当Pytest报错时，Agent会抓取Traceback（堆栈信息），让LLM分析：“是因为元素找不到？还是断言失败？如果是元素找不到，请尝试重新定位。”
三、 实战：如何让AI写出“会修自己”的代码？
我们来看一段核心逻辑的伪代码思路（基于LangChain/LlamaIndex或微软AutoGen框架）：
# 核心逻辑示意 def run_test_agent(task_description): max_retries = 3 for i in range(max_retries): # 1. LLM生成或修正Pytest代码 pytest_code = llm.generate_code(task_description) # 2. 写入临时文件并执行 result = subprocess.run( ["pytest", "temp_test.py"], capture_output=True, text=True ) # 3. 判断是否成功 if result.returncode == 0: return"测试通过" else: # 4. 关键：把错误信息喂给LLM进行反思 error_log = result.stderr task_description = f"之前的代码运行失败，错误信息是：{error_log}。请根据错误修正代码并重试。" return"达到最大重试次数，任务失败"这段代码解决了什么问题？
它解决了传统自动化最头疼的脆性（Brittleness）。以前脚本坏了要人修，现在AI能根据报错信息，尝试换一个Selector，或者调整等待时间。
四、 对比：传统框架 VS Test Agent
维度 | 传统Pytest框架 | Pytest + LLM Agent |
|---|---|---|
输入源 | 人工编写的Feature文件/代码 | 自然语言需求 / 需求文档 |
维护成本 | 极高（人工维护） | 极低（AI自我修复） |
异常处理 | try-except，无法应对未知变化 | 反思机制，动态适应变化 |
扩展性 | 修改代码 | 修改Prompt或增加Tools |
五、 工程落地：避坑指南
如果你打算在公司内部落地这套方案，我有三条血泪建议：
1. 严格控制上下文长度
不要把整个项目的代码都塞给LLM。只给它当前的测试目标、页面DOM快照和报错信息。否则Token消耗会让你老板心梗。
2. 必须有熔断机制（Circuit Breaker）
就像我在上一篇文章里提到的字节面试题：一定要设置Max Retry次数。
如果不设上限，Agent可能在“生成代码 -> 报错 -> 再生成”之间无限循环，直到把你账号的API额度烧光。
3. 工具封装优于代码生成
与其让AI从头写代码，不如把“登录”、“造数据”、“发请求”封装成成熟的Python函数，让AI去Call Function。这比直接生成代码稳定得多。
六、 趋势：从“写测试”到“审测试”
2026年，测试工程师的日常工作会发生质变。
你不再需要每天盯着屏幕写assert response.status_code == 200。
你的新工作是：
设计高质量的Prompt（提示词），定义测试边界。
审查AI生成的测试策略和代码，确保没有幻觉。
维护和迭代底层的Tools和SDK。
最后一个问题留给你： 如果你现在的自动化用例中有100个因为“元素定位失效”而挂掉了，你是会选择一个个手动去改，还是会立刻着手搭建一个能自动修复这些错误的Agent？
欢迎在评论区聊聊你的想法。如果你对如何封装测试工具给AI调用感兴趣，我们下期可以专门讲讲MCP（Model Context Protocol）的实战。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。