很多测试同学第一次接触 LangChain 时的反应大概率是点开官方文档看到 Agent、Chain、Tool、Memory 一堆术语然后默默关掉页面。这个反应很正常。LangChain 的问题从来不是能力不够而是资料太散官方文档偏重 API 罗列社区教程又喜欢堆砌概念。但如果你正在做测试尤其是接口测试、自动化测试、性能测试分析LangChain 的价值其实非常直接它能把“写用例、查边界、分析报告”这类重复性很高的测试工作变成一个大模型驱动的 Agent 流程。这篇文章我会用一个真实的测试用例生成 Agent 项目为主线先带你从零搭建一个可运行的 LangChain Agent再围绕 AI 测试的常见场景比如接口测试用例生成、自动化测试脚本辅助生成、性能测试报告分析一步步拆解实现方式。读完你可以直接照着落地也可以根据自己团队的测试框架改成定制版本。这不涉及多复杂的算法核心是把 LangChain 的 Agent 机制用对。我先把观点放在前面LangChain 对测试工程师的真正价值不是帮你自动点按钮而是把“测试经验”变成可复用的 Agent 工具链。你积累的接口边界、异常场景、性能指标分析思路都可以沉淀成 Tool让大模型在生成用例、分析报告时真正“懂测试”而不是只会生成泛泛的 Markdown 文本。这一点想通了你就知道为什么有人在用 LangChain 写测试 Agent而有人只是在用 ChatGPT 复制粘贴。1. 这篇文章真正要解决的问题很多测试团队这两年都尝试过用大模型辅助测试最常见的做法是把接口文档扔给 ChatGPT让它生成测试用例然后复制到 Excel 或者用例管理平台。这个流程跑几次就会发现瓶颈一次两次还行接口一多、字段一变你每次都要重新复制粘贴、调整 Prompt、手工清理输出。整个流程没有被真正工程化大模型只是你的临时打字员而不是测试流程里的一环。LangChain Agent 解决的是另一个层次的问题让大模型自己决定调用什么工具、按什么顺序执行、如何把结果组装成最终产出。你不需要每次手动喂 Prompt而是把需求分析、边界值提取、用例模板拼接这些步骤封装成 ToolAgent 拿到一个接口定义后会自己规划流程调用合适的工具最终输出结构化的测试用例。举个例子你给 Agent 一个“用户登录接口”的 OpenAPI 定义它不应该只是简单列几个正向用例而是应该自动做几件事。第一提取接口的请求参数、必填项、类型约束第二调用边界值分析工具生成空值、超长字符串、非法类型这些异常场景第三结合你的历史测试经验库补充鉴权失败、Token 过期、并发请求等业务场景第四把最终结果按统一模板导出成测试用例文档。这四步如果每次都是人工做耗时 30 分钟Agent 做可能只需要 3 分钟而且格式稳定、不会漏项。文章的后半部分还会扩展到 AI 测试的另外两个常见场景一是用 LangChain 辅助生成 Playwright 自动化测试脚本二是让 Agent 读取 JMeter 性能测试结果直接输出分析报告。这三个场景覆盖了测试工程师日常最花时间的部分用例设计、自动化编码、性能结果分析。它们不是孤立的三段代码而是同一个思路的三种落地把测试经验工具化让 Agent 成为测试资产的一部分。2. LangChain 与 Agent 的核心概念开始写代码之前先把几个关键概念讲清楚。否则你后面看代码会觉得每个类都认识但拼在一起不知道在干什么。2.1 LangChain 到底做了什么LangChain 是一个用于构建大模型应用的开源框架。它本身不提供大模型而是提供了一套标准化的“胶水层”让开发者可以方便地把大模型、外部工具、数据源、记忆模块组合成一条工作流。对于测试场景LangChain 最有用的两个部分一个是大模型调用抽象你可以用同一套代码切换 OpenAI、国产大模型或者本地模型另一个是 Agent 机制它让大模型具备“决策下一步做什么”的能力。注意一个容易混淆的点LangChain 不是测试框架它不执行用例也不发起 HTTP 请求。真正发起请求的是 Requests、JMeter、Playwright 这类工具。LangChain 在这里扮演的是“调度大脑”它决定调用哪个工具、传什么参数、如何解读结果。2.2 Agent、Tool、Executor 的分工Agent 是 LangChain 中最常被提起的概念。通俗地讲Agent 就是一个由大模型驱动的“决策器”它接收一个用户任务自己拆解步骤然后决定调用哪些工具。比如用户说“帮我看一下这个登录接口有哪些测试点”Agent 会拆解为“提取参数约束 - 调用边界值工具 - 调用场景补充工具 - 生成最终用例”。Tool 是 Agent 可以调用的外部能力本质上就是一个函数加上名称和描述。描述非常关键因为大模型靠描述来决定什么时候调用这个工具。比如一个工具叫analyze_boundary_values描述里写清楚“输入参数类型和约束输出边界值测试用例”Agent 在遇到字符串长度限制时就会想到调用它。Executor 是 Agent 的执行容器。它负责维护 Agent 和 Tool 之间的循环把任务交给 AgentAgent 决定调用某个 ToolExecutor 执行 Tool 并返回结果然后再次交给 Agent直到 Agent 认为任务完成。这个循环就是所谓 ReAct 模式的核心机制。2.3 LangGraph 和 LangChain 的区别最近 LangGraph 的讨论热度很高很多文章会把它和 LangChain 放在一起比较。简单说LangChain 提供的是构建 Agent 的高层抽象适合快速搭建LangGraph 则是一个更低层的工作流引擎它把 Agent 的决策、执行、状态流转建模成一张图适合需要精细控制流程、分支、回退的复杂场景。对测试用例生成这类任务直接用 LangChain 的 AgentExecutor 就够代码量少容易理解。如果你后续要做多 Agent 协作、人工审核环节、复杂的重试和分支逻辑再考虑迁移到 LangGraph。这篇文章的示例全部基于 LangChain 标准库保证你能直接跑通。3. 环境准备与前置条件开始之前先确认本地环境。以下配置以 2025 年主流的 Python 版本为例实际操作时版本请以官方最新稳定版为准本文重点演示通用思路不会绑定某个特定小版本。建议环境Python 3.10 或更高版本pip 包管理工具一个大模型 API 的访问凭证操作系统Windows / macOS / Linux 均可需要安装的核心依赖pip install langchain pip install langchain-openai pip install langchain-core pip install openai pip install requests pip install jmeter说明一下每个包的用途langchain核心框架langchain-openaiOpenAI 兼容接口的封装支持 OpenAI、DeepSeek、Qwen 等langchain-core核心抽象类如 Tool、Prompt 模板openaiOpenAI Python SDKrequests用于接口测试工具调用jmeter性能测试相关辅助如果你使用的是国内大模型服务比如 DeepSeek、通义千问、智谱通常它们提供 OpenAI 兼容接口可以直接使用langchain_openai.ChatOpenAI只需要修改base_url和api_key。不需要额外安装特定的包。大模型的选择上推荐使用支持 Function Calling 的模型因为 Agent 的 Tool 调用依赖这个能力。大多数主流商业模型均已支持本地部署模型则建议选择 Qwen 2.5 或更高版本的 7B 以上参数模型效果更稳定。4. 系统架构与整体流程在写代码之前先看整体的架构设计。这样你在看代码时能知道每个文件在做什么不会迷失在细节里。本文的测试用例生成 Agent 由四层组成第一层是入口层接收用户的测试需求比如接口的 OpenAPI 定义或者一段需求描述。第二层是 Agent 调度层这是核心。它包含一个大模型驱动的主 Agent负责理解用户需求、拆解任务、调用工具、汇总结果。第三层是工具层这里定义了多个测试专用工具接口解析工具、边界值分析工具、测试场景生成工具、测试脚本生成工具、性能结果解析工具。每个工具都是独立的函数职责单一。第四层是输出层把 Agent 生成的结果格式化为 Markdown 用例文档、JSON 或测试脚本文件。整体调用链可以用一句话概括用户输入测试目标Agent 规划步骤按需调用工具工具返回结构化结果Agent 汇总输出测试产物。5. 测试用例生成 Agent 完整实现这一部分是全文的核心我会带你从零写一个可运行的测试用例生成 Agent。先从一个最小版本开始然后逐步添加工具和功能。5.1 最小可用版本先跑通核心链路创建一个 Agent注册一个工具让 Agent 能使用这个工具完成任务。创建一个文件test_agent_basic.py# 文件路径test_agent_basic.py from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate # 初始化大模型 llm ChatOpenAI( modelgpt-4o-mini, temperature0, api_keyyour-api-key, base_urlhttps://api.openai.com/v1 # 如果是国内模型替换为对应 base_url ) # 定义一个测试用例生成工具 tool def generate_boundary_test_cases(param_name: str, param_type: str, min_value: str, max_value: str) - str: 根据参数名称、类型和取值范围生成边界值测试用例。 适用于接口参数边界测试。 cases [] cases.append(f正常边界{param_name} {min_value}验证通过) cases.append(f正常边界{param_name} {max_value}验证通过) cases.append(f异常值{param_name} {min_value} - 1验证返回参数错误) cases.append(f异常值{param_name} {max_value} 1验证返回参数错误) cases.append(f空值{param_name} None验证返回参数错误) cases.append(f类型错误{param_name} not_number验证返回类型错误) return \n.join(cases) # 创建 Prompt 模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一个资深的测试工程师助手擅长生成高质量的测试用例。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 创建 Agent agent create_tool_calling_agent(llm, [generate_boundary_test_cases], prompt) executor AgentExecutor(agentagent, tools[generate_boundary_test_cases], verboseTrue) # 执行任务 result executor.invoke({ input: 请为 age 字段生成边界值测试用例age 是整数类型取值范围 18 到 60。 }) print(result[output])这段代码的核心逻辑是第一通过tool装饰器把普通函数变成 LangChain 的工具函数名和 docstring 会自动成为 Agent 理解该工具的元信息。第二ChatPromptTemplate中的agent_scratchpad是固定占位符Agent 的中间推理过程会存放在这里。不能缺少。第三create_tool_calling_agent是基于大模型 Function Calling 能力的 Agent 创建方式是目前最主流的方式。运行方式python test_agent_basic.py如果一切正常你会看到 verbose 模式下打印的 Agent 思考过程以及最终生成的边界值测试用例列表。5.2 为 Agent 添加接口解析与用例生成工具最小版本跑通后我们扩展为一个更真实的场景根据接口的 OpenAPI 定义自动提取参数信息生成完整测试用例。创建一个工具用于从 OpenAPI 定义中提取接口参数# 文件路径test_agent_openapi.py import json import requests from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate tool def extract_api_info(openapi_url: str) - str: 从 OpenAPI 文档中提取接口名称、请求方法、路径和参数信息。 输入是 OpenAPI 文档的远程地址或本地文件路径。 # 这里支持从本地 JSON 文件读取也可以从 URL 读取 openapi_spec load_openapi(openapi_url) paths openapi_spec.get(paths, {}) result_lines [] for path, methods in paths.items(): for method, detail in methods.items(): if method not in [get, post, put, delete, patch]: continue parameters detail.get(parameters, []) request_body detail.get(requestBody, {}) result_lines.append(f接口路径{path}) result_lines.append(f请求方法{method.upper()}) result_lines.append(f接口描述{detail.get(summary, )}) if parameters: result_lines.append(Query/Path 参数) for param in parameters: schema param.get(schema, {}) result_lines.append(f - {param[name]} ({param[in]}), 类型: {schema.get(type, 未知)}, 必填: {param.get(required, False)}) # 简单处理 RequestBody if request_body: content request_body.get(content, {}) if application/json in content: schema content[application/json].get(schema, {}) props schema.get(properties, {}) required schema.get(required, []) result_lines.append(JSON Body 参数) for prop_name, prop_detail in props.items(): result_lines.append(f - {prop_name}, 类型: {prop_detail.get(type, 未知)}, 必填: {prop_name in required}) return \n.join(result_lines) tool def generate_normal_test_cases(api_info: str) - str: 根据接口信息生成正向测试用例。 输入是 extract_api_info 输出的接口信息。 # 这个函数在真实项目中会基于历史用例模板生成 # 这里简单演示格式 return f 基于以下接口信息生成正向测试用例 {api_info} 正向测试用例要点 1. 所有必填参数使用合法值验证返回 200 2. 可选参数不传验证返回 200 3. 分页参数使用默认值验证返回结构正确 这里的重点是工具之间的协作。Agent 会先调用extract_api_info获取接口定义然后把结果传给generate_normal_test_cases生成正向用例。工具链的粒度决定了 Agent 的灵活性工具越小、职责越单一Agent 越容易在不同场景下组合它们。5.3 完整项目结构一个适合放进真实项目的测试 Agent 代码结构建议这样组织test_agent_project/ ├── main.py # 入口文件初始化 Agent 并提供交互入口 ├── tools/ │ ├── __init__.py │ ├── api_tools.py # 接口解析、HTTP 请求相关工具 │ ├── boundary_tools.py # 边界值、等价类分析工具 │ ├── script_tools.py # 自动化测试脚本生成工具 │ └── perf_tools.py # 性能测试结果解析工具 ├── prompts/ │ ├── __init__.py │ └── test_agent_prompt.py # Prompt 模板 ├── outputs/ │ └── generated/ # 生成的用例和报告 └── requirements.txt这样的结构让每个工具独立可测试后续添加新工具不需要改动 Agent 主流程。如果你的团队规模不大也可以先在一个文件里写完跑通后再拆分。6. AI 测试场景实战一接口测试用例生成第一个完整场景我们做一个能“读懂接口文档并生成用例”的 Agent。6.1 注册核心工具在完整实现中我们需要注册三个核心工具接口解析、边界值分析、业务场景补充。下面给出完整代码# 文件路径tools/api_tools.py import re import requests import json from langchain_core.tools import tool tool def parse_openapi_spec(spec_path: str) - str: 从指定的 OpenAPI JSON 文件中读取接口定义提取所有接口的路径、方法、参数和请求体信息。 输入可以是本地文件路径或 HTTP URL。 # 支持本地文件和远程 URL if spec_path.startswith(http): response requests.get(spec_path) spec response.json() else: with open(spec_path, r, encodingutf-8) as f: spec json.load(f) output_lines [] for path, methods in spec.get(paths, {}).items(): for method, detail in methods.items(): if method not in [get, post, put, delete, patch]: continue output_lines.append(f路径: {path} [{method.upper()}]) params detail.get(parameters, []) for param in params: schema param.get(schema, {}) output_lines.append( f 参数: {param.get(name)}, f位置: {param.get(in)}, f类型: {schema.get(type, unknown)}, f必填: {param.get(required, false)} ) body detail.get(requestBody, {}) if body: content body.get(content, {}) json_schema content.get(application/json, {}).get(schema, {}) props json_schema.get(properties, {}) required json_schema.get(required, []) for prop, prop_detail in props.items(): output_lines.append( f Body参数: {prop}, f类型: {prop_detail.get(type, unknown)}, f必填: {prop in required} ) return \n.join(output_lines)# 文件路径tools/boundary_tools.py from langchain_core.tools import tool tool def generate_boundary_cases(param_name: str, param_type: str, min_value: str None, max_value: str None) - str: 为单个接口参数生成边界值测试用例。 param_name 是参数名param_type 是参数类型int/string/float min_value 和 max_value 是取值范围可选。 cases [] cases.append(f用例1: {param_name}使用最小值 {min_value}预期成功) cases.append(f用例2: {param_name}使用最大值 {max_value}预期成功) cases.append(f用例3: {param_name}使用最小值-1预期参数校验失败) cases.append(f用例4: {param_name}使用最大值1预期参数校验失败) if param_type string: cases.append(f用例5: {param_name}为空字符串预期参数校验失败) cases.append(f用例6: {param_name}为超长字符串超过最大长度预期参数校验失败) cases.append(f用例7: {param_name}包含特殊字符预期处理正确) elif param_type int: cases.append(f用例5: {param_name}为0预期根据业务规则处理) cases.append(f用例6: {param_name}为负数预期参数校验失败) cases.append(f用例7: {param_name}为字符串格式预期类型校验失败) return \n.join(cases) tool def generate_equivalence_cases(param_name: str, valid_values: str, invalid_values: str) - str: 为接口参数生成等价类划分测试用例。 valid_values 是合法值列表用逗号分隔invalid_values 是非法值列表用逗号分隔。 cases [] cases.append(f有效等价类用例: {param_name} 分别取 {valid_values}预期均通过) cases.append(f无效等价类用例: {param_name} 分别取 {invalid_values}预期均校验失败) cases.append(f边界相关等价类: 验证有效等价类与无效等价类之间的边界) return \n.join(cases)6.2 调用示例# 文件路径main_api_case_agent.py from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from tools.api_tools import parse_openapi_spec from tools.boundary_tools import generate_boundary_cases, generate_equivalence_cases llm ChatOpenAI( modelgpt-4o-mini, temperature0, api_keyyour-api-key, base_urlhttps://api.openai.com/v1 ) tools [parse_openapi_spec, generate_boundary_cases, generate_equivalence_cases] prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的测试工程师擅长分析接口定义并生成高质量的测试用例。 请根据用户提供的接口信息先解析接口参数然后调用边界值和等价类工具生成用例。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) user_request 请对用户登录接口生成测试用例接口定义文档在 api_spec.json。 重点关注 username 和 password 的边界值和异常场景。 result executor.invoke({input: user_request}) print(result[output])这里要注意handle_parsing_errorsTrue这个配置。Agent 在调用工具时偶尔会出现大模型输出格式不符合解析器预期的情况设置这个参数后Agent 会捕获解析错误并自动重试而不是直接崩溃。7. AI 测试场景实战二自动化测试脚本生成接口用例生成只是第一步。很多团队更关心的是Agent 能不能直接生成可执行的自动化测试脚本答案是能但需要正确的工具设计。7.1 用 Agent 生成 Playwright 脚本的思路Playwright 是目前主流的端到端自动化测试框架。LangChain Agent 在这里的用法是先让大模型理解页面结构和业务动作然后调用一个“脚本生成工具”把操作步骤转换为 Playwright 代码。不建议直接让大模型输出完整代码然后手工复制而是应该定义一个工具类让它输入业务步骤描述输出格式化的 Playwright 脚本文件# 文件路径tools/script_tools.py from langchain_core.tools import tool tool def generate_playwright_script(scenario_name: str, action_steps: str) - str: 根据业务场景名称和操作步骤生成 Playwright Python 测试脚本。 action_steps 用逗号分隔多个操作步骤例如 打开首页, 点击登录按钮, 输入用户名, 输入密码, 点击提交, 验证跳转 steps [s.strip() for s in action_steps.split(,) if s.strip()] code_lines [] code_lines.append(from playwright.sync_api import sync_playwright) code_lines.append() code_lines.append(fdef test_{scenario_name}():) code_lines.append( with sync_playwright() as p:) code_lines.append( browser p.chromium.launch(headlessFalse)) code_lines.append( page browser.new_page()) for step in steps: if 打开 in step: code_lines.append(f page.goto(https://example.com) # 请替换为实际URL) elif 点击 in step: button step.replace(点击, ).replace(按钮, ) code_lines.append(f page.click(text{button})) elif 输入 in step: field step.replace(输入, ).replace(用户名, username).replace(密码, password) code_lines.append(f page.fill(input[name{field}], test_user)) elif 验证 in step: code_lines.append(f assert page.title() Expected Title # 请替换为实际断言) code_lines.append( browser.close()) return \n.join(code_lines)这个工具是简化的模板实现。真实项目中建议把 Playwright 代码的模板做得更细致配合 POM 模式或者团队自定义的断言方法。你可以让 Agent 调用这个工具后再由大模型根据 UI 元素定位信息完善代码细节。7.2 验证脚本可执行性生成的脚本不是直接就能跑的原因是 Agent 不知道你测试环境的真实域名、真实账号、真实按钮文案。这里有一个重要的工程习惯Agent 生成的脚本必须经过人工审核和参数替换才能纳入自动化测试套件。建议的流程是Agent 根据业务步骤生成脚本骨架测试工程师补充真实 URL、测试数据、元素定位本地执行pytest验证脚本通过再提交到 CI 流水线这样既利用了 Agent 的生成效率又保证了脚本质量。8. AI 测试场景实战三性能测试分析报告生成性能测试是另一个非常适合 AI 辅助的场景。原因在于性能测试的结果分析有大量模式化判断吞吐量下降、响应时间增加、错误率提升、资源使用率过高这些都是可以总结成规则的。LangChain Agent 的用法是读取 JMeter 生成的测试结果文件调用分析工具提取关键指标再由大模型根据指标生成报告。8.1 读取并解析 JMeter 性能测试结果JMeter 的结果文件通常有 JTL、CSV 和 HTML 报告三种格式。以 CSV 为例字段包括时间戳、响应时间、线程组名称、成功与否等。先定义一个工具函数把 CSV 解析成结构化摘要# 文件路径tools/perf_tools.py import csv from collections import defaultdict from langchain_core.tools import tool tool def analyze_jmeter_csv(csv_path: str, response_time_threshold: int 1000) - str: 解析 JMeter 导出的 CSV 结果文件计算关键性能指标。 主要包括总请求数、通过率、平均响应时间、TP95、TP99、最大响应时间。 response_time_threshold 是慢请求阈值单位毫秒默认 1000。 total_requests 0 success_requests 0 failed_requests 0 response_times [] slow_requests 0 with open(csv_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: total_requests 1 success row.get(success, true).lower() true if success: success_requests 1 else: failed_requests 1 elapsed int(row.get(elapsed, 0)) response_times.append(elapsed) if elapsed response_time_threshold: slow_requests 1 if not response_times: return CSV 文件中没有有效的请求数据 sorted_times sorted(response_times) tp95 sorted_times[int(len(sorted_times) * 0.95) - 1] if len(sorted_times) 20 else sorted_times[-1] tp99 sorted_times[int(len(sorted_times) * 0.99) - 1] if len(sorted_times) 100 else sorted_times[-1] avg_response sum(response_times) / len(response_times) result { total_requests: total_requests, success_rate: round(success_requests / total_requests * 100, 2), avg_response_time_ms: round(avg_response, 2), tp95_ms: tp95, tp99_ms: tp99, max_response_time_ms: max(response_times), slow_request_count: slow_requests, slow_request_ratio: round(slow_requests / total_requests * 100, 2) } return f 总请求数: {result[total_requests]} 通过率: {result[success_rate]}% 平均响应时间: {result[avg_response_time_ms]} ms TP95: {result[tp95_ms]} ms TP99: {result[tp99_ms]} ms 最大响应时间: {result[max_response_time_ms]} ms 慢请求数: {result[slow_request_count]} ({result[slow_request_ratio]}%) 8.2 Agent 生成分析报告有了指标解析工具后Agent 的工作是解读这些指标并输出一份可供评审使用的分析报告# 文件路径main_perf_agent.py from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from tools.perf_tools import analyze_jmeter_csv llm ChatOpenAI( modelgpt-4o-mini, temperature0, api_keyyour-api-key, base_urlhttps://api.openai.com/v1 ) tools [analyze_jmeter_csv] prompt ChatPromptTemplate.from_messages([ (system, 你是一位资深性能测试专家。请基于 JMeter 性能测试结果数据 输出专业的中文性能测试分析报告包含整体结论、瓶颈点分析、优化建议三部分。 报告必须使用 Markdown 格式。), (human, 请分析这份 JMeter 测试结果{input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) result executor.invoke({ input: 请分析 jmeter_results.csv 的性能测试结果并给出优化建议。响应时间阈值 1000ms。 }) print(result[output])运行这段代码后Agent 会先调用analyze_jmeter_csv读取文件拿到指标摘要然后结合这些数据生成报告。你可以在 system prompt 中指定报告模板比如“按测试概况、结果分析、问题定位、优化建议四段输出”大模型会严格遵循这个结构。9. 运行结果与效果验证代码写完怎么确认 Agent 真的在工作这里给你一套验证方法。9.1 预期输出运行main_api_case_agent.py后控制台会输出类似这样的信息 Entering new AgentExecutor chain... Invoking: parse_openapi_spec with {spec_path: api_spec.json} 路径: /api/v1/login [POST] Body参数: username, 类型: string, 必填: True Body参数: password, 类型: string, 必填: True Invoking: generate_boundary_cases with {param_name: username, param_type: string, min_value: 1, max_value: 50} 用例1: username使用最小值 1预期成功 用例2: username使用最大值 50预期成功 ...这个输出表明 Agent 正确理解了任务并按顺序调用了工具。如果你的输出里没有出现Invoking字样而是直接生成了一段文字通常说明 Prompt 中没有引导 Agent 使用工具。这在 LangChain Agent 的调试中非常常见优先检查 system message 是否明确告诉 Agent“必须先生成测试用例再调用工具”。9.2 如何判断 Agent 生成质量判断测试用例生成结果是否合格可以从三个维度看第一覆盖度正反向用例是否齐备边界值是否覆盖到上下界两侧异常参数是否包含类型错误、空值、超长值。第二可执行性用例中是否包含明确的输入数据和预期结果而不是含糊的“正常情况”。第三格式规范性输出是否严格按照 Prompt 中定义的模板方便直接导入用例管理平台。性能报告的好坏主要看它是否给出了可操作的优化方向。比如 Averages 正常但 TP99 很高Agent 应该能指出这是有长尾延迟可能存在某台机器或某个接口的偶发慢请求。如果报告只是复述指标数值没有分析判断说明 Prompt 引导不够。9.3 常见运行失败排查顺序刚接触 LangChain Agent 的人遇到问题最常犯的错误是直接改代码而不是先看日志。正确的排查顺序应该是第一步打开 verbose 模式也就是AgentExecutor(..., verboseTrue)查看 Agent 的实际思考过程。第二步确认大模型确实返回了工具调用请求。如果 verbose 输出里没有任何工具调用去检查 API 返回是不是被 content filter 拦截了。第三步确认工具的输入参数格式。大模型可能会把参数名传错比如传了param而不是param_name这种情况要查看工具函数签名并帮助模型理解。第四步确认agent_scratchpad占位符存在。很多新手会漏掉这个占位符结果 Agent 无法维护中间状态。10. 常见问题与排查思路下面整理使用 LangChain 搭建 AI 测试 Agent 时最常遇到的几个问题每个问题都给出了具体的排查方式你可以收藏备用问题现象可能原因排查方式解决方案Agent 不调用工具直接输出文字Prompt 未引导工具调用或模型不支持 Function Calling打开 verbose 查看 Agent 是否输出 tool_calls在 system prompt 中明确要求调用工具更换支持 Function Calling 的模型工具调用后解析失败大模型输出的工具参数格式不符合函数签名查看报错中的 JSON 内容与函数签名差异使用 handle_parsing_errorsTrue简化参数命名在工具 docstring 中说明参数格式中文乱码或字符串编码错误Windows 控制台编码默认 GBK查看控制台编码运行 chcp 65001在 Python 文件头部加# -*- coding: utf-8 -*-或在环境变量中设置 PYTHONIOENCODINGutf-8调用 OpenAI 接口超时网络不稳定或代理配置问题检查 API 连通性查看是否配置了代理设置超时时间重试机制使用国内模型接口Agent 循环调用同一个工具工具返回结果不足以让 Agent 判断任务完成查看 verbose 中 Agent 每次调用的依据丰富工具返回内容加入“下一步建议”在 Prompt 中说明完成任务的条件生成的测试用例格式不一致大模型随机性导致输出不稳定设置 temperature0对比多次输出使用输出解析器如 PydanticOutputParser强制结构化输出JMeter 文件解析失败CSV 字段名与代码不匹配打印 CSV 的 header 行确认字段名根据实际 JMeter 版本调整字段名常见为 timeStamp,elapsed,label,success,bytes11. 最佳实践与工程建议最后这部分是把 Agent 用到真实测试项目中的一些建议。这些经验不来自书本而是来自踩坑。11.1 别把 Agent 当成用例管理系统LangChain Agent 适合生成用例草案但它不适合作为用例的唯一存储和追踪系统。测试用例的最终状态管理还是应该放在你团队原有的用例管理平台、Jira、禅道或者代码仓库里。Agent 的职责是生成、建议和辅助而不是取代用例管理流程。11.2 工具的描述要写清楚而不是写多工具 docstring 是大模型决定是否调用工具的重要依据。很多新手在工具描述里写一堆空话比如“生成高质量的测试用例”但没说清楚输入和输出是什么。更好的写法是明确的输入输出契约例如输入是接口参数名和类型输出是一组边界值测试用例字符串每条用例包含输入数据和预期结果。注意工具描述不是越长越好太长的描述反而会让模型抓不住重点。好的描述应该能在两句话内说完工具做什么、输入是什么、输出是什么。11.3 用 Pydantic 做结构化输出如果你希望 Agent 生成的测试用例是 JSON 格式方便后续程序化处理推荐使用 LangChain 的输出解析器。核心思路是定义一个 Pydantic 模型强制大模型输出符合 Schema 的 JSON# 文件路径models/test_case.py from pydantic import BaseModel, Field from typing import List class TestCase(BaseModel): case_id: str Field(description用例编号) title: str Field(description用例标题) preconditions: str Field(description前置条件) test_data: str Field(description测试数据) steps: List[str] Field(description测试步骤) expected_result: str Field(description预期结果) priority: str Field(description优先级高/中/低) class TestCaseSet(BaseModel): module: str Field(description模块名称) test_cases: List[TestCase] Field(description测试用例列表)然后使用PydanticOutputParser把大模型输出解析成这个模型。这样无论大模型如何表述最终得到的对象结构都是统一的可以直接序列化为 JSON 存入数据库。11.4 日志与可观测性生产环境中使用测试 Agent日志很重要。建议至少记录三部分输入的用户请求、Agent 每一步调用的工具和参数、最终输出结果。可以在AgentExecutor外面包一层日志装饰器或者调用 callbacks 功能。这样即使 Agent 某一次输出质量差你也能回溯问题出在哪一步。11.5 安全与合规这里特别提醒一点在测试 Agent 中使用大模型 API 时如果接口定义或测试数据包含敏感信息要注意数据脱敏。不要把真实的生产环境 Token、用户手机号、身份证号直接传给外部大模型 API。常见的做法是在调用 Agent 前对输入做脱敏替换或者在私有化环境中部署本地模型。11.6 从最小项目开始迭代不要一开始就想做一个“全自动测试平台”那会让项目失控。先选定一个场景比如“根据 OpenAPI 生成接口测试用例”写一个最小 Agent跑通后再加边界值工具、业务场景工具、性能分析工具。每次加一个工具验证这个工具对最终结果有没有提升保留有用的删掉没用的。12. 总结与后续学习方向到这里你应该已经掌握了一整条从测试用例生成到性能测试分析报告输出的 LangChain Agent 搭建路径。回顾一下主要做了几件事理解了 LangChain 中 Agent、Tool、Executor 的分工学会了用tool装饰器封装测试专用函数动手实现了接口测试用例生成 Agent、Playwright 脚本生成辅助和 JMeter 性能分析报告生成最后整理了真实项目中常见的排错方法和工程规范。下一步的学习方向取决于你当前团队的实际需求。如果你负责的项目接口很多、字段经常变建议先把接口用例生成 Agent 做扎实用 Pydantic 输出统一格式接驳到现有的用例管理平台。如果你正在做性能测试可以先用本文的性能分析 Agent 处理最近一次压测结果让它帮你生成报告初稿再人工补充优化建议。如果你对 Agent 的流程控制有更高要求比如需要人工审核后再继续执行可以开始研究 LangGraph它能把“Agent 生成用例 - 人工审批 - 更新用例库”这类流程固化为有状态的工作流比目前单轮 Agent 更适合团队协作场景。最后给你一个实用建议搭建这类 AI 测试工具不要一开始就追求“全自动”。把 AI 当成一个能即时响应、知识面广、输出规范的测试助理先让它帮你完成最繁琐的 80%剩下的 20% 靠你的测试经验兜底。时间长了你会找到最适合自己团队的 AI 测试协作模式。 用LangChain构建测试用例生成Agent：从接口测试到性能分析
很多测试同学第一次接触 LangChain 时的反应大概率是点开官方文档看到 Agent、Chain、Tool、Memory 一堆术语然后默默关掉页面。这个反应很正常。LangChain 的问题从来不是能力不够而是资料太散官方文档偏重 API 罗列社区教程又喜欢堆砌概念。但如果你正在做测试尤其是接口测试、自动化测试、性能测试分析LangChain 的价值其实非常直接它能把“写用例、查边界、分析报告”这类重复性很高的测试工作变成一个大模型驱动的 Agent 流程。这篇文章我会用一个真实的测试用例生成 Agent 项目为主线先带你从零搭建一个可运行的 LangChain Agent再围绕 AI 测试的常见场景比如接口测试用例生成、自动化测试脚本辅助生成、性能测试报告分析一步步拆解实现方式。读完你可以直接照着落地也可以根据自己团队的测试框架改成定制版本。这不涉及多复杂的算法核心是把 LangChain 的 Agent 机制用对。我先把观点放在前面LangChain 对测试工程师的真正价值不是帮你自动点按钮而是把“测试经验”变成可复用的 Agent 工具链。你积累的接口边界、异常场景、性能指标分析思路都可以沉淀成 Tool让大模型在生成用例、分析报告时真正“懂测试”而不是只会生成泛泛的 Markdown 文本。这一点想通了你就知道为什么有人在用 LangChain 写测试 Agent而有人只是在用 ChatGPT 复制粘贴。1. 这篇文章真正要解决的问题很多测试团队这两年都尝试过用大模型辅助测试最常见的做法是把接口文档扔给 ChatGPT让它生成测试用例然后复制到 Excel 或者用例管理平台。这个流程跑几次就会发现瓶颈一次两次还行接口一多、字段一变你每次都要重新复制粘贴、调整 Prompt、手工清理输出。整个流程没有被真正工程化大模型只是你的临时打字员而不是测试流程里的一环。LangChain Agent 解决的是另一个层次的问题让大模型自己决定调用什么工具、按什么顺序执行、如何把结果组装成最终产出。你不需要每次手动喂 Prompt而是把需求分析、边界值提取、用例模板拼接这些步骤封装成 ToolAgent 拿到一个接口定义后会自己规划流程调用合适的工具最终输出结构化的测试用例。举个例子你给 Agent 一个“用户登录接口”的 OpenAPI 定义它不应该只是简单列几个正向用例而是应该自动做几件事。第一提取接口的请求参数、必填项、类型约束第二调用边界值分析工具生成空值、超长字符串、非法类型这些异常场景第三结合你的历史测试经验库补充鉴权失败、Token 过期、并发请求等业务场景第四把最终结果按统一模板导出成测试用例文档。这四步如果每次都是人工做耗时 30 分钟Agent 做可能只需要 3 分钟而且格式稳定、不会漏项。文章的后半部分还会扩展到 AI 测试的另外两个常见场景一是用 LangChain 辅助生成 Playwright 自动化测试脚本二是让 Agent 读取 JMeter 性能测试结果直接输出分析报告。这三个场景覆盖了测试工程师日常最花时间的部分用例设计、自动化编码、性能结果分析。它们不是孤立的三段代码而是同一个思路的三种落地把测试经验工具化让 Agent 成为测试资产的一部分。2. LangChain 与 Agent 的核心概念开始写代码之前先把几个关键概念讲清楚。否则你后面看代码会觉得每个类都认识但拼在一起不知道在干什么。2.1 LangChain 到底做了什么LangChain 是一个用于构建大模型应用的开源框架。它本身不提供大模型而是提供了一套标准化的“胶水层”让开发者可以方便地把大模型、外部工具、数据源、记忆模块组合成一条工作流。对于测试场景LangChain 最有用的两个部分一个是大模型调用抽象你可以用同一套代码切换 OpenAI、国产大模型或者本地模型另一个是 Agent 机制它让大模型具备“决策下一步做什么”的能力。注意一个容易混淆的点LangChain 不是测试框架它不执行用例也不发起 HTTP 请求。真正发起请求的是 Requests、JMeter、Playwright 这类工具。LangChain 在这里扮演的是“调度大脑”它决定调用哪个工具、传什么参数、如何解读结果。2.2 Agent、Tool、Executor 的分工Agent 是 LangChain 中最常被提起的概念。通俗地讲Agent 就是一个由大模型驱动的“决策器”它接收一个用户任务自己拆解步骤然后决定调用哪些工具。比如用户说“帮我看一下这个登录接口有哪些测试点”Agent 会拆解为“提取参数约束 - 调用边界值工具 - 调用场景补充工具 - 生成最终用例”。Tool 是 Agent 可以调用的外部能力本质上就是一个函数加上名称和描述。描述非常关键因为大模型靠描述来决定什么时候调用这个工具。比如一个工具叫analyze_boundary_values描述里写清楚“输入参数类型和约束输出边界值测试用例”Agent 在遇到字符串长度限制时就会想到调用它。Executor 是 Agent 的执行容器。它负责维护 Agent 和 Tool 之间的循环把任务交给 AgentAgent 决定调用某个 ToolExecutor 执行 Tool 并返回结果然后再次交给 Agent直到 Agent 认为任务完成。这个循环就是所谓 ReAct 模式的核心机制。2.3 LangGraph 和 LangChain 的区别最近 LangGraph 的讨论热度很高很多文章会把它和 LangChain 放在一起比较。简单说LangChain 提供的是构建 Agent 的高层抽象适合快速搭建LangGraph 则是一个更低层的工作流引擎它把 Agent 的决策、执行、状态流转建模成一张图适合需要精细控制流程、分支、回退的复杂场景。对测试用例生成这类任务直接用 LangChain 的 AgentExecutor 就够代码量少容易理解。如果你后续要做多 Agent 协作、人工审核环节、复杂的重试和分支逻辑再考虑迁移到 LangGraph。这篇文章的示例全部基于 LangChain 标准库保证你能直接跑通。3. 环境准备与前置条件开始之前先确认本地环境。以下配置以 2025 年主流的 Python 版本为例实际操作时版本请以官方最新稳定版为准本文重点演示通用思路不会绑定某个特定小版本。建议环境Python 3.10 或更高版本pip 包管理工具一个大模型 API 的访问凭证操作系统Windows / macOS / Linux 均可需要安装的核心依赖pip install langchain pip install langchain-openai pip install langchain-core pip install openai pip install requests pip install jmeter说明一下每个包的用途langchain核心框架langchain-openaiOpenAI 兼容接口的封装支持 OpenAI、DeepSeek、Qwen 等langchain-core核心抽象类如 Tool、Prompt 模板openaiOpenAI Python SDKrequests用于接口测试工具调用jmeter性能测试相关辅助如果你使用的是国内大模型服务比如 DeepSeek、通义千问、智谱通常它们提供 OpenAI 兼容接口可以直接使用langchain_openai.ChatOpenAI只需要修改base_url和api_key。不需要额外安装特定的包。大模型的选择上推荐使用支持 Function Calling 的模型因为 Agent 的 Tool 调用依赖这个能力。大多数主流商业模型均已支持本地部署模型则建议选择 Qwen 2.5 或更高版本的 7B 以上参数模型效果更稳定。4. 系统架构与整体流程在写代码之前先看整体的架构设计。这样你在看代码时能知道每个文件在做什么不会迷失在细节里。本文的测试用例生成 Agent 由四层组成第一层是入口层接收用户的测试需求比如接口的 OpenAPI 定义或者一段需求描述。第二层是 Agent 调度层这是核心。它包含一个大模型驱动的主 Agent负责理解用户需求、拆解任务、调用工具、汇总结果。第三层是工具层这里定义了多个测试专用工具接口解析工具、边界值分析工具、测试场景生成工具、测试脚本生成工具、性能结果解析工具。每个工具都是独立的函数职责单一。第四层是输出层把 Agent 生成的结果格式化为 Markdown 用例文档、JSON 或测试脚本文件。整体调用链可以用一句话概括用户输入测试目标Agent 规划步骤按需调用工具工具返回结构化结果Agent 汇总输出测试产物。5. 测试用例生成 Agent 完整实现这一部分是全文的核心我会带你从零写一个可运行的测试用例生成 Agent。先从一个最小版本开始然后逐步添加工具和功能。5.1 最小可用版本先跑通核心链路创建一个 Agent注册一个工具让 Agent 能使用这个工具完成任务。创建一个文件test_agent_basic.py# 文件路径test_agent_basic.py from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate # 初始化大模型 llm ChatOpenAI( modelgpt-4o-mini, temperature0, api_keyyour-api-key, base_urlhttps://api.openai.com/v1 # 如果是国内模型替换为对应 base_url ) # 定义一个测试用例生成工具 tool def generate_boundary_test_cases(param_name: str, param_type: str, min_value: str, max_value: str) - str: 根据参数名称、类型和取值范围生成边界值测试用例。 适用于接口参数边界测试。 cases [] cases.append(f正常边界{param_name} {min_value}验证通过) cases.append(f正常边界{param_name} {max_value}验证通过) cases.append(f异常值{param_name} {min_value} - 1验证返回参数错误) cases.append(f异常值{param_name} {max_value} 1验证返回参数错误) cases.append(f空值{param_name} None验证返回参数错误) cases.append(f类型错误{param_name} not_number验证返回类型错误) return \n.join(cases) # 创建 Prompt 模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一个资深的测试工程师助手擅长生成高质量的测试用例。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 创建 Agent agent create_tool_calling_agent(llm, [generate_boundary_test_cases], prompt) executor AgentExecutor(agentagent, tools[generate_boundary_test_cases], verboseTrue) # 执行任务 result executor.invoke({ input: 请为 age 字段生成边界值测试用例age 是整数类型取值范围 18 到 60。 }) print(result[output])这段代码的核心逻辑是第一通过tool装饰器把普通函数变成 LangChain 的工具函数名和 docstring 会自动成为 Agent 理解该工具的元信息。第二ChatPromptTemplate中的agent_scratchpad是固定占位符Agent 的中间推理过程会存放在这里。不能缺少。第三create_tool_calling_agent是基于大模型 Function Calling 能力的 Agent 创建方式是目前最主流的方式。运行方式python test_agent_basic.py如果一切正常你会看到 verbose 模式下打印的 Agent 思考过程以及最终生成的边界值测试用例列表。5.2 为 Agent 添加接口解析与用例生成工具最小版本跑通后我们扩展为一个更真实的场景根据接口的 OpenAPI 定义自动提取参数信息生成完整测试用例。创建一个工具用于从 OpenAPI 定义中提取接口参数# 文件路径test_agent_openapi.py import json import requests from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate tool def extract_api_info(openapi_url: str) - str: 从 OpenAPI 文档中提取接口名称、请求方法、路径和参数信息。 输入是 OpenAPI 文档的远程地址或本地文件路径。 # 这里支持从本地 JSON 文件读取也可以从 URL 读取 openapi_spec load_openapi(openapi_url) paths openapi_spec.get(paths, {}) result_lines [] for path, methods in paths.items(): for method, detail in methods.items(): if method not in [get, post, put, delete, patch]: continue parameters detail.get(parameters, []) request_body detail.get(requestBody, {}) result_lines.append(f接口路径{path}) result_lines.append(f请求方法{method.upper()}) result_lines.append(f接口描述{detail.get(summary, )}) if parameters: result_lines.append(Query/Path 参数) for param in parameters: schema param.get(schema, {}) result_lines.append(f - {param[name]} ({param[in]}), 类型: {schema.get(type, 未知)}, 必填: {param.get(required, False)}) # 简单处理 RequestBody if request_body: content request_body.get(content, {}) if application/json in content: schema content[application/json].get(schema, {}) props schema.get(properties, {}) required schema.get(required, []) result_lines.append(JSON Body 参数) for prop_name, prop_detail in props.items(): result_lines.append(f - {prop_name}, 类型: {prop_detail.get(type, 未知)}, 必填: {prop_name in required}) return \n.join(result_lines) tool def generate_normal_test_cases(api_info: str) - str: 根据接口信息生成正向测试用例。 输入是 extract_api_info 输出的接口信息。 # 这个函数在真实项目中会基于历史用例模板生成 # 这里简单演示格式 return f 基于以下接口信息生成正向测试用例 {api_info} 正向测试用例要点 1. 所有必填参数使用合法值验证返回 200 2. 可选参数不传验证返回 200 3. 分页参数使用默认值验证返回结构正确 这里的重点是工具之间的协作。Agent 会先调用extract_api_info获取接口定义然后把结果传给generate_normal_test_cases生成正向用例。工具链的粒度决定了 Agent 的灵活性工具越小、职责越单一Agent 越容易在不同场景下组合它们。5.3 完整项目结构一个适合放进真实项目的测试 Agent 代码结构建议这样组织test_agent_project/ ├── main.py # 入口文件初始化 Agent 并提供交互入口 ├── tools/ │ ├── __init__.py │ ├── api_tools.py # 接口解析、HTTP 请求相关工具 │ ├── boundary_tools.py # 边界值、等价类分析工具 │ ├── script_tools.py # 自动化测试脚本生成工具 │ └── perf_tools.py # 性能测试结果解析工具 ├── prompts/ │ ├── __init__.py │ └── test_agent_prompt.py # Prompt 模板 ├── outputs/ │ └── generated/ # 生成的用例和报告 └── requirements.txt这样的结构让每个工具独立可测试后续添加新工具不需要改动 Agent 主流程。如果你的团队规模不大也可以先在一个文件里写完跑通后再拆分。6. AI 测试场景实战一接口测试用例生成第一个完整场景我们做一个能“读懂接口文档并生成用例”的 Agent。6.1 注册核心工具在完整实现中我们需要注册三个核心工具接口解析、边界值分析、业务场景补充。下面给出完整代码# 文件路径tools/api_tools.py import re import requests import json from langchain_core.tools import tool tool def parse_openapi_spec(spec_path: str) - str: 从指定的 OpenAPI JSON 文件中读取接口定义提取所有接口的路径、方法、参数和请求体信息。 输入可以是本地文件路径或 HTTP URL。 # 支持本地文件和远程 URL if spec_path.startswith(http): response requests.get(spec_path) spec response.json() else: with open(spec_path, r, encodingutf-8) as f: spec json.load(f) output_lines [] for path, methods in spec.get(paths, {}).items(): for method, detail in methods.items(): if method not in [get, post, put, delete, patch]: continue output_lines.append(f路径: {path} [{method.upper()}]) params detail.get(parameters, []) for param in params: schema param.get(schema, {}) output_lines.append( f 参数: {param.get(name)}, f位置: {param.get(in)}, f类型: {schema.get(type, unknown)}, f必填: {param.get(required, false)} ) body detail.get(requestBody, {}) if body: content body.get(content, {}) json_schema content.get(application/json, {}).get(schema, {}) props json_schema.get(properties, {}) required json_schema.get(required, []) for prop, prop_detail in props.items(): output_lines.append( f Body参数: {prop}, f类型: {prop_detail.get(type, unknown)}, f必填: {prop in required} ) return \n.join(output_lines)# 文件路径tools/boundary_tools.py from langchain_core.tools import tool tool def generate_boundary_cases(param_name: str, param_type: str, min_value: str None, max_value: str None) - str: 为单个接口参数生成边界值测试用例。 param_name 是参数名param_type 是参数类型int/string/float min_value 和 max_value 是取值范围可选。 cases [] cases.append(f用例1: {param_name}使用最小值 {min_value}预期成功) cases.append(f用例2: {param_name}使用最大值 {max_value}预期成功) cases.append(f用例3: {param_name}使用最小值-1预期参数校验失败) cases.append(f用例4: {param_name}使用最大值1预期参数校验失败) if param_type string: cases.append(f用例5: {param_name}为空字符串预期参数校验失败) cases.append(f用例6: {param_name}为超长字符串超过最大长度预期参数校验失败) cases.append(f用例7: {param_name}包含特殊字符预期处理正确) elif param_type int: cases.append(f用例5: {param_name}为0预期根据业务规则处理) cases.append(f用例6: {param_name}为负数预期参数校验失败) cases.append(f用例7: {param_name}为字符串格式预期类型校验失败) return \n.join(cases) tool def generate_equivalence_cases(param_name: str, valid_values: str, invalid_values: str) - str: 为接口参数生成等价类划分测试用例。 valid_values 是合法值列表用逗号分隔invalid_values 是非法值列表用逗号分隔。 cases [] cases.append(f有效等价类用例: {param_name} 分别取 {valid_values}预期均通过) cases.append(f无效等价类用例: {param_name} 分别取 {invalid_values}预期均校验失败) cases.append(f边界相关等价类: 验证有效等价类与无效等价类之间的边界) return \n.join(cases)6.2 调用示例# 文件路径main_api_case_agent.py from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from tools.api_tools import parse_openapi_spec from tools.boundary_tools import generate_boundary_cases, generate_equivalence_cases llm ChatOpenAI( modelgpt-4o-mini, temperature0, api_keyyour-api-key, base_urlhttps://api.openai.com/v1 ) tools [parse_openapi_spec, generate_boundary_cases, generate_equivalence_cases] prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的测试工程师擅长分析接口定义并生成高质量的测试用例。 请根据用户提供的接口信息先解析接口参数然后调用边界值和等价类工具生成用例。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) user_request 请对用户登录接口生成测试用例接口定义文档在 api_spec.json。 重点关注 username 和 password 的边界值和异常场景。 result executor.invoke({input: user_request}) print(result[output])这里要注意handle_parsing_errorsTrue这个配置。Agent 在调用工具时偶尔会出现大模型输出格式不符合解析器预期的情况设置这个参数后Agent 会捕获解析错误并自动重试而不是直接崩溃。7. AI 测试场景实战二自动化测试脚本生成接口用例生成只是第一步。很多团队更关心的是Agent 能不能直接生成可执行的自动化测试脚本答案是能但需要正确的工具设计。7.1 用 Agent 生成 Playwright 脚本的思路Playwright 是目前主流的端到端自动化测试框架。LangChain Agent 在这里的用法是先让大模型理解页面结构和业务动作然后调用一个“脚本生成工具”把操作步骤转换为 Playwright 代码。不建议直接让大模型输出完整代码然后手工复制而是应该定义一个工具类让它输入业务步骤描述输出格式化的 Playwright 脚本文件# 文件路径tools/script_tools.py from langchain_core.tools import tool tool def generate_playwright_script(scenario_name: str, action_steps: str) - str: 根据业务场景名称和操作步骤生成 Playwright Python 测试脚本。 action_steps 用逗号分隔多个操作步骤例如 打开首页, 点击登录按钮, 输入用户名, 输入密码, 点击提交, 验证跳转 steps [s.strip() for s in action_steps.split(,) if s.strip()] code_lines [] code_lines.append(from playwright.sync_api import sync_playwright) code_lines.append() code_lines.append(fdef test_{scenario_name}():) code_lines.append( with sync_playwright() as p:) code_lines.append( browser p.chromium.launch(headlessFalse)) code_lines.append( page browser.new_page()) for step in steps: if 打开 in step: code_lines.append(f page.goto(https://example.com) # 请替换为实际URL) elif 点击 in step: button step.replace(点击, ).replace(按钮, ) code_lines.append(f page.click(text{button})) elif 输入 in step: field step.replace(输入, ).replace(用户名, username).replace(密码, password) code_lines.append(f page.fill(input[name{field}], test_user)) elif 验证 in step: code_lines.append(f assert page.title() Expected Title # 请替换为实际断言) code_lines.append( browser.close()) return \n.join(code_lines)这个工具是简化的模板实现。真实项目中建议把 Playwright 代码的模板做得更细致配合 POM 模式或者团队自定义的断言方法。你可以让 Agent 调用这个工具后再由大模型根据 UI 元素定位信息完善代码细节。7.2 验证脚本可执行性生成的脚本不是直接就能跑的原因是 Agent 不知道你测试环境的真实域名、真实账号、真实按钮文案。这里有一个重要的工程习惯Agent 生成的脚本必须经过人工审核和参数替换才能纳入自动化测试套件。建议的流程是Agent 根据业务步骤生成脚本骨架测试工程师补充真实 URL、测试数据、元素定位本地执行pytest验证脚本通过再提交到 CI 流水线这样既利用了 Agent 的生成效率又保证了脚本质量。8. AI 测试场景实战三性能测试分析报告生成性能测试是另一个非常适合 AI 辅助的场景。原因在于性能测试的结果分析有大量模式化判断吞吐量下降、响应时间增加、错误率提升、资源使用率过高这些都是可以总结成规则的。LangChain Agent 的用法是读取 JMeter 生成的测试结果文件调用分析工具提取关键指标再由大模型根据指标生成报告。8.1 读取并解析 JMeter 性能测试结果JMeter 的结果文件通常有 JTL、CSV 和 HTML 报告三种格式。以 CSV 为例字段包括时间戳、响应时间、线程组名称、成功与否等。先定义一个工具函数把 CSV 解析成结构化摘要# 文件路径tools/perf_tools.py import csv from collections import defaultdict from langchain_core.tools import tool tool def analyze_jmeter_csv(csv_path: str, response_time_threshold: int 1000) - str: 解析 JMeter 导出的 CSV 结果文件计算关键性能指标。 主要包括总请求数、通过率、平均响应时间、TP95、TP99、最大响应时间。 response_time_threshold 是慢请求阈值单位毫秒默认 1000。 total_requests 0 success_requests 0 failed_requests 0 response_times [] slow_requests 0 with open(csv_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: total_requests 1 success row.get(success, true).lower() true if success: success_requests 1 else: failed_requests 1 elapsed int(row.get(elapsed, 0)) response_times.append(elapsed) if elapsed response_time_threshold: slow_requests 1 if not response_times: return CSV 文件中没有有效的请求数据 sorted_times sorted(response_times) tp95 sorted_times[int(len(sorted_times) * 0.95) - 1] if len(sorted_times) 20 else sorted_times[-1] tp99 sorted_times[int(len(sorted_times) * 0.99) - 1] if len(sorted_times) 100 else sorted_times[-1] avg_response sum(response_times) / len(response_times) result { total_requests: total_requests, success_rate: round(success_requests / total_requests * 100, 2), avg_response_time_ms: round(avg_response, 2), tp95_ms: tp95, tp99_ms: tp99, max_response_time_ms: max(response_times), slow_request_count: slow_requests, slow_request_ratio: round(slow_requests / total_requests * 100, 2) } return f 总请求数: {result[total_requests]} 通过率: {result[success_rate]}% 平均响应时间: {result[avg_response_time_ms]} ms TP95: {result[tp95_ms]} ms TP99: {result[tp99_ms]} ms 最大响应时间: {result[max_response_time_ms]} ms 慢请求数: {result[slow_request_count]} ({result[slow_request_ratio]}%) 8.2 Agent 生成分析报告有了指标解析工具后Agent 的工作是解读这些指标并输出一份可供评审使用的分析报告# 文件路径main_perf_agent.py from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from tools.perf_tools import analyze_jmeter_csv llm ChatOpenAI( modelgpt-4o-mini, temperature0, api_keyyour-api-key, base_urlhttps://api.openai.com/v1 ) tools [analyze_jmeter_csv] prompt ChatPromptTemplate.from_messages([ (system, 你是一位资深性能测试专家。请基于 JMeter 性能测试结果数据 输出专业的中文性能测试分析报告包含整体结论、瓶颈点分析、优化建议三部分。 报告必须使用 Markdown 格式。), (human, 请分析这份 JMeter 测试结果{input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) result executor.invoke({ input: 请分析 jmeter_results.csv 的性能测试结果并给出优化建议。响应时间阈值 1000ms。 }) print(result[output])运行这段代码后Agent 会先调用analyze_jmeter_csv读取文件拿到指标摘要然后结合这些数据生成报告。你可以在 system prompt 中指定报告模板比如“按测试概况、结果分析、问题定位、优化建议四段输出”大模型会严格遵循这个结构。9. 运行结果与效果验证代码写完怎么确认 Agent 真的在工作这里给你一套验证方法。9.1 预期输出运行main_api_case_agent.py后控制台会输出类似这样的信息 Entering new AgentExecutor chain... Invoking: parse_openapi_spec with {spec_path: api_spec.json} 路径: /api/v1/login [POST] Body参数: username, 类型: string, 必填: True Body参数: password, 类型: string, 必填: True Invoking: generate_boundary_cases with {param_name: username, param_type: string, min_value: 1, max_value: 50} 用例1: username使用最小值 1预期成功 用例2: username使用最大值 50预期成功 ...这个输出表明 Agent 正确理解了任务并按顺序调用了工具。如果你的输出里没有出现Invoking字样而是直接生成了一段文字通常说明 Prompt 中没有引导 Agent 使用工具。这在 LangChain Agent 的调试中非常常见优先检查 system message 是否明确告诉 Agent“必须先生成测试用例再调用工具”。9.2 如何判断 Agent 生成质量判断测试用例生成结果是否合格可以从三个维度看第一覆盖度正反向用例是否齐备边界值是否覆盖到上下界两侧异常参数是否包含类型错误、空值、超长值。第二可执行性用例中是否包含明确的输入数据和预期结果而不是含糊的“正常情况”。第三格式规范性输出是否严格按照 Prompt 中定义的模板方便直接导入用例管理平台。性能报告的好坏主要看它是否给出了可操作的优化方向。比如 Averages 正常但 TP99 很高Agent 应该能指出这是有长尾延迟可能存在某台机器或某个接口的偶发慢请求。如果报告只是复述指标数值没有分析判断说明 Prompt 引导不够。9.3 常见运行失败排查顺序刚接触 LangChain Agent 的人遇到问题最常犯的错误是直接改代码而不是先看日志。正确的排查顺序应该是第一步打开 verbose 模式也就是AgentExecutor(..., verboseTrue)查看 Agent 的实际思考过程。第二步确认大模型确实返回了工具调用请求。如果 verbose 输出里没有任何工具调用去检查 API 返回是不是被 content filter 拦截了。第三步确认工具的输入参数格式。大模型可能会把参数名传错比如传了param而不是param_name这种情况要查看工具函数签名并帮助模型理解。第四步确认agent_scratchpad占位符存在。很多新手会漏掉这个占位符结果 Agent 无法维护中间状态。10. 常见问题与排查思路下面整理使用 LangChain 搭建 AI 测试 Agent 时最常遇到的几个问题每个问题都给出了具体的排查方式你可以收藏备用问题现象可能原因排查方式解决方案Agent 不调用工具直接输出文字Prompt 未引导工具调用或模型不支持 Function Calling打开 verbose 查看 Agent 是否输出 tool_calls在 system prompt 中明确要求调用工具更换支持 Function Calling 的模型工具调用后解析失败大模型输出的工具参数格式不符合函数签名查看报错中的 JSON 内容与函数签名差异使用 handle_parsing_errorsTrue简化参数命名在工具 docstring 中说明参数格式中文乱码或字符串编码错误Windows 控制台编码默认 GBK查看控制台编码运行 chcp 65001在 Python 文件头部加# -*- coding: utf-8 -*-或在环境变量中设置 PYTHONIOENCODINGutf-8调用 OpenAI 接口超时网络不稳定或代理配置问题检查 API 连通性查看是否配置了代理设置超时时间重试机制使用国内模型接口Agent 循环调用同一个工具工具返回结果不足以让 Agent 判断任务完成查看 verbose 中 Agent 每次调用的依据丰富工具返回内容加入“下一步建议”在 Prompt 中说明完成任务的条件生成的测试用例格式不一致大模型随机性导致输出不稳定设置 temperature0对比多次输出使用输出解析器如 PydanticOutputParser强制结构化输出JMeter 文件解析失败CSV 字段名与代码不匹配打印 CSV 的 header 行确认字段名根据实际 JMeter 版本调整字段名常见为 timeStamp,elapsed,label,success,bytes11. 最佳实践与工程建议最后这部分是把 Agent 用到真实测试项目中的一些建议。这些经验不来自书本而是来自踩坑。11.1 别把 Agent 当成用例管理系统LangChain Agent 适合生成用例草案但它不适合作为用例的唯一存储和追踪系统。测试用例的最终状态管理还是应该放在你团队原有的用例管理平台、Jira、禅道或者代码仓库里。Agent 的职责是生成、建议和辅助而不是取代用例管理流程。11.2 工具的描述要写清楚而不是写多工具 docstring 是大模型决定是否调用工具的重要依据。很多新手在工具描述里写一堆空话比如“生成高质量的测试用例”但没说清楚输入和输出是什么。更好的写法是明确的输入输出契约例如输入是接口参数名和类型输出是一组边界值测试用例字符串每条用例包含输入数据和预期结果。注意工具描述不是越长越好太长的描述反而会让模型抓不住重点。好的描述应该能在两句话内说完工具做什么、输入是什么、输出是什么。11.3 用 Pydantic 做结构化输出如果你希望 Agent 生成的测试用例是 JSON 格式方便后续程序化处理推荐使用 LangChain 的输出解析器。核心思路是定义一个 Pydantic 模型强制大模型输出符合 Schema 的 JSON# 文件路径models/test_case.py from pydantic import BaseModel, Field from typing import List class TestCase(BaseModel): case_id: str Field(description用例编号) title: str Field(description用例标题) preconditions: str Field(description前置条件) test_data: str Field(description测试数据) steps: List[str] Field(description测试步骤) expected_result: str Field(description预期结果) priority: str Field(description优先级高/中/低) class TestCaseSet(BaseModel): module: str Field(description模块名称) test_cases: List[TestCase] Field(description测试用例列表)然后使用PydanticOutputParser把大模型输出解析成这个模型。这样无论大模型如何表述最终得到的对象结构都是统一的可以直接序列化为 JSON 存入数据库。11.4 日志与可观测性生产环境中使用测试 Agent日志很重要。建议至少记录三部分输入的用户请求、Agent 每一步调用的工具和参数、最终输出结果。可以在AgentExecutor外面包一层日志装饰器或者调用 callbacks 功能。这样即使 Agent 某一次输出质量差你也能回溯问题出在哪一步。11.5 安全与合规这里特别提醒一点在测试 Agent 中使用大模型 API 时如果接口定义或测试数据包含敏感信息要注意数据脱敏。不要把真实的生产环境 Token、用户手机号、身份证号直接传给外部大模型 API。常见的做法是在调用 Agent 前对输入做脱敏替换或者在私有化环境中部署本地模型。11.6 从最小项目开始迭代不要一开始就想做一个“全自动测试平台”那会让项目失控。先选定一个场景比如“根据 OpenAPI 生成接口测试用例”写一个最小 Agent跑通后再加边界值工具、业务场景工具、性能分析工具。每次加一个工具验证这个工具对最终结果有没有提升保留有用的删掉没用的。12. 总结与后续学习方向到这里你应该已经掌握了一整条从测试用例生成到性能测试分析报告输出的 LangChain Agent 搭建路径。回顾一下主要做了几件事理解了 LangChain 中 Agent、Tool、Executor 的分工学会了用tool装饰器封装测试专用函数动手实现了接口测试用例生成 Agent、Playwright 脚本生成辅助和 JMeter 性能分析报告生成最后整理了真实项目中常见的排错方法和工程规范。下一步的学习方向取决于你当前团队的实际需求。如果你负责的项目接口很多、字段经常变建议先把接口用例生成 Agent 做扎实用 Pydantic 输出统一格式接驳到现有的用例管理平台。如果你正在做性能测试可以先用本文的性能分析 Agent 处理最近一次压测结果让它帮你生成报告初稿再人工补充优化建议。如果你对 Agent 的流程控制有更高要求比如需要人工审核后再继续执行可以开始研究 LangGraph它能把“Agent 生成用例 - 人工审批 - 更新用例库”这类流程固化为有状态的工作流比目前单轮 Agent 更适合团队协作场景。最后给你一个实用建议搭建这类 AI 测试工具不要一开始就追求“全自动”。把 AI 当成一个能即时响应、知识面广、输出规范的测试助理先让它帮你完成最繁琐的 80%剩下的 20% 靠你的测试经验兜底。时间长了你会找到最适合自己团队的 AI 测试协作模式。