先说说这次实战的背景。最近在测试团队内部尝试把大模型接入日常流程最早只是想解放一部分写用例的时间后来发现 LangChain 在串联“需求理解—用例设计—结果分析”这条链路上比想象中顺手。调研了目前各家用 AI 辅助测试的方案之后决定自己搭一个基于 LangChain 的 Agent 原型把测试用例生成、接口测试脚本生成、性能测试结果分析报告输出这几个高频场景全部串起来。动手之后才发现LangChain 真正值钱的地方不只是“能调用模型”而是它能把工具调用、上下文管理、多步骤执行这些逻辑组织成一个稳定的框架帮助我们把测试工作的结构化思维固化到代码里。本文将围绕这套测试用例生成 Agent 的设计思路与完整实现展开从环境准备、核心链路拆解、关键代码示例、运行效果到常见排错、工程化落地建议一次讲清楚。如果你对 LangChain Agent 开发、AI 测试提效、测试用例自动化生成、性能测试报告自动输出这几个方向感兴趣这篇文章应该能给你一套可以直接参考的完整方案。1. 为什么我们要自研一个测试用例生成 Agent1.1 AI 测试常见的痛点传统测试用例设计高度依赖测试工程师的个人经验和业务熟悉度新人写出来的用例经常覆盖不全老手写用例质量虽高但耗时很长。引入 AI 辅助之后最常见的做法是把需求描述扔给 ChatGPT让它“帮我写测试用例”然后复制粘贴到 Excel。这样做确实快但问题也很明显上下文太短模型只能根据一段孤立的需求文本生成用例缺少对项目背景、接口数据结构、历史缺陷信息的理解。输出不稳定换一个 Prompt 表述结果差异很大。后续无法自动化生成的结果是自然语言文本没有结构化的 JSON 或测试步骤不能直接接入测试管理平台。多样例之间用例重复率高、优先级设计不合理边界条件经常漏。这些痛点的根源在于大模型本质上是一个“文本生成器”它不具备主动查询接口定义、分析历史缺陷、检查数据库字段这些能力。如果想要 AI 真正辅助测试就需要给它装上“手和眼睛”让它能够调用工具、访问外部数据源并按测试设计的逻辑一步步执行。这正好是 LangChain Agent 擅长的领域。1.2 LangChain Agent 能做什么LangChain 是一个面向大语言模型应用的开发框架核心抽象包括模型封装、Prompt 管理、记忆、工具调用、Agent 编排。在测试场景里我们可以把 Agent 理解为“一个会使用工具的 AI 助手”它不仅能回答问题还能按照你设定的流程去执行任务。对于测试用例生成这个场景Agent 可以做以下几件事接收输入的需求描述自动理解业务功能点。调用接口文档解析工具拉取真实的请求参数、响应字段、边界约束。调用历史缺陷查询工具找到过去容易出问题的模块和场景。按照等价类划分、边界值分析、场景法等测试设计方法生成用例。对生成的用例进行去重、补充、排序输出结构化 JSON。将结果以指定格式写入测试管理平台或导出为文件。这已经不是简单的“套 Prompt”而是一套可以复用的测试辅助工具。多个 Agent 组合使用还能完成从需求解析、用例生成、脚本编写到性能报告输出的完整链路。1.3 为什么选择 LangChain 而不是直接调 API可能有同学会问直接写代码调用大模型 API 不也能完成吗为什么还要引入 LangChain直接调用 API 的方式适合一次性脚本但一旦我们要实现“多步骤任务、工具选择、记忆保持、结果结构化输出”就会发现自己重写一套框架非常繁琐。LangChain 提供了几个非常省事的能力标准化的模型调用接口切换模型厂商时只需改少量配置。内置 Agent 执行框架支持 ReAct、Plan-and-Execute 等常见 Agent 模式。丰富的工具集成也可以自定义函数作为 Tool。输出解析器可以强制模型按指定 JSON 结构输出。消息记忆机制多轮交互中保持上下文。更重要的是LangChain 的生态足够大网上资料多团队成员接手成本低。如果你只是做几个 demo直接调 API 没问题但如果你要搭建一套可持续维护的 AI 测试基础设施LangChain 这类框架可以帮你省下不少基建代码。这里也顺便解答一个经常被问到的问题LangChain 和 LangGraph 有什么区别简单来说LangChain 提供了 Agent 的基础能力适合流程相对简单、步骤不固定的场景LangGraph 是 LangChain 团队推出的更底层的编排框架适合需要精确控制状态流转、支持循环分支、可观测性要求较高的复杂 Agent 应用。用测试业务来类比LangChain 像是“用例执行引擎”LangGraph 则像“测试流程编排引擎”。对于本文中的测试用例生成 Agent使用 LangChain 已经足够如果后续要做跨团队的完整测试流水线建议了解一下 LangGraph。2. 环境准备与版本说明2.1 基础运行环境本文的示例代码基于 Python 3操作系统不限Windows、macOS、Linux 都可以跑。建议使用虚拟环境管理依赖避免污染系统 Python。需要安装的核心依赖如下pip install langchain pip install langchain-openai pip install langchain-community pip install openai pip install pandas pip install pydantic版本方面LangChain 目前迭代速度较快API 变化也比较大。本文示例基于 0.1.x 到 0.2.x 之间的常见 API 编写。在动手之前建议先执行下列命令确认当前环境版本python --version pip show langchain pip show langchain-openai如果发现安装了更高版本导致 API 不兼容有两种处理方式一是按官方文档迁移到新写法二是固定版本安装例如pip install langchain0.2.16。生产的项目建议锁版本。2.2 模型选择说明在示例代码中默认使用 OpenAI 兼容接口通过环境变量配置 API Key。如果你使用的是国内大模型服务商提供的 OpenAI 兼容网关通常只需要修改base_url和api_key两个配置项不需要改动业务逻辑。这里需要特别说明的是大模型的能力直接影响测试用例生成质量。在实际项目落地时建议根据业务安全要求来选择模型部署方式。涉及敏感数据的项目优先使用私有化部署模型一般业务场景可以使用云服务。无论选择哪种模型都要在测试环境充分验证生成结果并保留人工审核环节。配置环境变量示例export OPENAI_API_KEYsk-xxxxxxxxxxxx export OPENAI_BASE_URLhttps://api.xxx.com/v1在 Windows PowerShell 下可以写成$env:OPENAI_API_KEYsk-xxxxxxxxxxxx $env:OPENAI_BASE_URLhttps://api.xxx.com/v12.3 项目整体结构为了方便管理我们新建一个名为ai_test_agent的项目目录ai_test_agent/ ├── requirements.txt ├── .env ├── agents/ │ ├── __init__.py │ ├── requirement_agent.py │ ├── testcase_agent.py │ └── perf_agent.py ├── tools/ │ ├── __init__.py │ ├── api_schema_tool.py │ └── history_bug_tool.py ├── models/ │ ├── __init__.py │ ├── testcase_schema.py │ └── perf_report_schema.py ├── output/ │ ├── testcases/ │ └── reports/ ├── main.py └── utils.py目录职责说明agents/存放不同的 Agent 定义。tools/存放自定义工具例如接口文档解析工具、历史缺陷查询工具。models/存放输出数据模型也就是我们期望大模型输出的结构化 JSON 结构。output/存放生成的测试用例文件和测试报告。main.py是主入口负责串联整个流程。3. 测试用例生成 Agent 的核心设计3.1 整体流程设计在开始写代码之前先梳理一下整个 Agent 的工作流程。我们的目标是从一段需求描述出发自动生成一份结构化的测试用例集。流程可以拆成以下步骤第一步需求解析Agent 先读取需求描述提取出功能模块、用户角色、核心业务流程、业务规则、输入输出等关键信息。如果需求文本中提到了接口就调用接口文档解析工具获取接口的请求参数和响应字段。第二步测试点提取基于需求解析结果Agent 按照功能列表和业务规则生成测试点。例如一个登录功能测试点可能包括正确用户名密码登录、错误密码登录、账号不存在、密码为空、账号被锁定、验证码过期、并发登录等。第三步测试用例生成对每个测试点Agent 按照测试设计方法来补充用例详情包括前置条件、测试步骤、输入数据、预期结果、优先级、用例类型。第四步用例规则套用与去重Agent 套用用例规范规则从覆盖度、重复度、边界条件、异常场景几个维度对生成结果进行优化。这里可以调用一个“测试用例规范检查工具”自动把不满足要求的用例打回重写。第五步结构化输出最终结果通过输出解析器转换成 JSON 格式写入文件。3.2 Agent 输入输出设计为了让 Agent 的生成结果稳定、可复用建议先定义好输入和输出的数据结构。输入需求描述示例{ requirement_id: REQ-2025-001, title: 用户登录功能, description: 用户通过手机号和密码登录系统登录成功后跳转到首页。密码连续错误5次后账号锁定30分钟。支持记住密码功能。, related_api: [ { name: POST /api/login, method: POST, request_params: phone: string, password: string, remember: boolean, response: { code: 0, message: success, data: { token: string } } } ], priority: P0 }输出测试用例结构示例{ requirement_id: REQ-2025-001, test_cases: [ { case_id: TC-001, case_title: 正确手机号和密码登录成功, precondition: 已注册用户手机号13800000000密码正确, steps: [ 打开登录页面, 输入手机号13800000000, 输入正确密码, 点击登录按钮 ], test_data: { phone: 13800000000, password: correct_password }, expected_result: 登录成功跳转首页右上角显示用户名, case_type: 功能测试, priority: P0 } ] }定义好结构之后在代码中使用 Pydantic 模型来约束输出格式这样大模型生成的结果即使缺少某些字段也会被解析器修正。3.3 核心工具设计为了让 Agent 具备“动手能力”我们需要自定义几个工具。接口文档解析工具很多测试项目中接口信息散落在 YAPI、Swagger 或者文档页面里。我们可以写一个工具函数接收一个接口名称返回该接口的详细信息。在实际演示中先用一个 mock 字典代替。历史缺陷工具这个工具用于查询历史缺陷帮助 Agent 在生成用例时重点关注曾出现问题的场景。比如某模块历史缺陷中“金额为0时前端校验通过但后端报错”的频率很高那 Agent 在生成用例时会自动补充这个边界场景。from langchain_core.tools import tool tool def get_history_bug_count(module_name: str) - str: 查询指定模块的历史缺陷数量与高频缺陷类型。 module_name: 模块名称例如 登录、支付 bug_db { 登录: 历史缺陷共15个高频类型验证码过期、账号锁定逻辑错误、密码错误提示不明确, 支付: 历史缺陷共32个高频类型金额为0未拦截、重复支付、并发扣款超扣、回调顺序异常, 订单: 历史缺陷共28个高频类型订单状态流转错误、超时未关闭、分页丢失条件 } return bug_db.get(module_name, 暂未发现历史缺陷数据)这里只是示例真实项目中可以将查询逻辑换成数据库查询或接口调用。关键点在于工具函数最好带有清晰的 docstring因为 LangChain 会把函数名称和介绍一并发送给模型模型根据这个描述来判断何时调用该工具。4. 完整实战搭建测试用例生成 Agent4.1 创建项目结构和安装依赖先创建项目目录和虚拟环境mkdir ai_test_agent cd ai_test_agent python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate创建requirements.txt文件langchain0.1.0,0.3.0 langchain-openai0.1.0 langchain-community0.2.0 openai1.0.0 pandas2.0.0 pydantic2.0.0 python-dotenv1.0.0安装依赖pip install -r requirements.txt4.2 自定义工具实现创建tools/api_schema_tool.py实现接口文档解析工具。这里先使用 mock 数据演示如何定义 Tool。实际项目中你可以替换为读取 YAPI 接口文档或数据库配置。# 文件路径tools/api_schema_tool.py from langchain_core.tools import tool tool def get_api_schema(api_name: str) - str: 根据接口名称查询接口的请求参数和响应结构。 api_name: 接口名称例如 login、create_order api_docs { login: { name: POST /api/login, method: POST, request_params: { phone: string, 手机号, 11位, password: string, 密码, 6-20位字母数字, remember: boolean, 是否记住密码 }, response: { code: int, 0表示成功, message: string, 提示信息, data: {token: string, 登录凭证} }, constraints: [ phone 必须为11位有效手机号, password 长度为6-20位, 连续5次错误密码锁定账号30分钟 ] }, create_order: { name: POST /api/order/create, method: POST, request_params: { user_id: string, 用户ID, product_id: string, 商品ID, quantity: int, 购买数量, 1-99, coupon_id: string, 优惠券ID, 可为空 }, response: { code: int, 0表示成功, message: string, 提示信息, data: {order_id: string, 订单号} }, constraints: [ quantity 必须在1-99之间, 商品必须上架, 优惠券必须属于当前用户且未被使用 ] } } api api_docs.get(api_name) if not api: return 未找到该接口文档请确认接口名称。 import json return json.dumps(api, ensure_asciiFalse, indent2)同样创建tools/history_bug_tool.py# 文件路径tools/history_bug_tool.py from langchain_core.tools import tool tool def get_history_bug(module_name: str) - str: 查询指定模块的历史缺陷信息帮助测试用例设计时重点关注高频缺陷场景。 module_name: 模块名称例如 login、order、payment bug_db { login: 历史缺陷15个密码连续错误后锁定逻辑异常、验证码过期后提示不友好、手机号校验不严格, order: 历史缺陷22个数量边界未校验、超时订单状态未流转、批量下单并发场景数据错乱, payment: 历史缺陷30个订单金额为0时未拦截、重复支付回调、并发扣款超扣、退款金额大于原订单 } return bug_db.get(module_name, 该模块暂无历史缺陷数据)4.3 定义输出数据模型创建models/testcase_schema.py# 文件路径models/testcase_schema.py from typing import List, Dict from pydantic import BaseModel, Field class TestCase(BaseModel): case_id: str Field(description用例编号) case_title: str Field(description用例标题) precondition: str Field(description前置条件) steps: List[str] Field(description测试步骤) test_data: Dict Field(description测试数据) expected_result: str Field(description预期结果) case_type: str Field(description用例类型如功能测试、边界测试、异常测试) priority: str Field(description优先级P0/P1/P2/P3) class TestCaseList(BaseModel): requirement_id: str Field(description需求编号) requirement_title: str Field(description需求标题) test_cases: List[TestCase] Field(description测试用例列表)这样做的目的是给大模型的输出加上一层约束LangChain 会结合 Pydantic 模型生成JSON Schema要求大模型输出的字段必须符合这个结构。4.4 测试用例生成 Agent 实现创建agents/testcase_agent.py。这个 Agent 是整个系统的核心也是代码量最大的部分。# 文件路径agents/testcase_agent.py import json from typing import Any, Dict from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_core.output_parsers import PydanticOutputParser from tools.api_schema_tool import get_api_schema from tools.history_bug_tool import get_history_bug from models.testcase_schema import TestCaseList class TestcaseGenerateAgent: def __init__(self, model_name: str gpt-4o, temperature: float 0.2): self.llm ChatOpenAI( modelmodel_name, temperaturetemperature ) self.parser PydanticOutputParser(pydantic_objectTestCaseList) self.tools [get_api_schema, get_history_bug] self.prompt ChatPromptTemplate.from_messages([ (system, 你是一名资深测试工程师擅长测试用例设计。 你的任务是根据需求描述借助可用工具生成一份完整、专业、可直接执行的测试用例集合。 要求如下 1. 如果需求中涉及接口必须调用 get_api_schema 工具获取接口定义基于真实参数设计用例。 2. 必须调用 get_history_bug 工具查询相关模块历史缺陷补充对应的高风险场景。 3. 测试用例必须覆盖正常功能、边界值、异常场景、权限/安全、兼容性等维度。 4. 每个用例包含用例编号、标题、前置条件、步骤、测试数据、预期结果、用例类型、优先级。 5. 生成结果必须符合指定 JSON 结构。 {format_instructions} ), (human, 需求描述\n{requirement_text}), MessagesPlaceholder(variable_nameagent_scratchpad), ]).partial(format_instructionsself.parser.get_format_instructions()) def build_agent(self) - AgentExecutor: agent create_openai_tools_agent( llmself.llm, toolsself.tools, promptself.prompt ) executor AgentExecutor( agentagent, toolsself.tools, verboseTrue, handle_parsing_errorsTrue ) return executor def generate(self, requirement_text: str) - Dict[str, Any]: executor self.build_agent() result executor.invoke({ requirement_text: requirement_text }) # 输出解析为结构化数据 parsed self.parser.invoke(result[output]) return parsed.dict()4.5 调用示例与运行创建一个main.py只保留最核心的调用逻辑# 文件路径main.py import json from agents.testcase_agent import TestcaseGenerateAgent if __name__ __main__: requirement_text 需求编号REQ-2025-001 需求名称用户登录功能 需求描述用户通过手机号和密码登录系统登录成功后跳转到首页。 密码连续错误5次后账号锁定30分钟。支持记住密码功能。 涉及接口login agent TestcaseGenerateAgent(model_namegpt-4o) result agent.generate(requirement_text) with open(output/testcases/testcase_REQ-2025-001.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print( 生成结果 ) for tc in result[test_cases]: print(f{tc[case_id]} | {tc[case_title]} | {tc[priority]})运行前确保output/testcases目录存在mkdir -p output/testcases python main.py运行后预期输出类似 生成结果 TC-001 | 正确手机号和密码登录成功 | P0 TC-002 | 手机号格式不正确 | P1 TC-003 | 密码错误1次提示重新输入 | P1 TC-004 | 密码连续错误5次账号锁定30分钟 | P0 TC-005 | 锁定期间使用正确密码登录失败 | P0 TC-006 | 记住密码功能验证 | P2 TC-007 | 登录接口响应超时 | P2同时在output/testcases/testcase_REQ-2025-001.json中可以看到完整的 JSON 结构化结果。4.6 结果说明从结果中可以看出Agent 已经自动完成了以下工作识别了“连续错误5次锁定”这个关键业务规则并生成对应的正反向用例。设置了 P0、P1、P2 优先级区分核心功能和次要功能。对手机号格式、密码错误次数、锁定时间等边界条件做了覆盖。补充了记住密码、响应超时等容易被遗漏的非主路径测试点。这就是把测试设计方法论“喂”给 Agent 的效果。它不是在瞎编测试步骤而是像一个有经验的测试工程师那样围绕功能点、边界条件、异常场景和业务规则展开用例设计。5. 核心原理拆解与优化技巧5.1 Prompt 设计为什么如此重要在 Agent 应用中Prompt 是最容易被低估的部分。同一个模型Prompt 质量不同生成用例的质量差异非常大。结合测试场景有几点经验可以参考角色限定让模型充当“资深测试工程师”而不是普通的“AI 助手”。角色设定的价值在于让模型调用更专业的思维方式。明确输出约束告诉模型必须覆盖功能、边界、异常等测试维度而不是“写出你可能想到的测试场景”。提供工具使用规则明确要求模型在涉及接口时先调用 API 工具而不是凭记忆输出。这能有效减少模型“幻觉”问题。结构化要求用 Pydantic 约束输出格式并明确要求必须输出指定字段。5.2 工具调用减少模型幻觉在测试用例生成场景中模型最容易编造的内容是接口参数和业务规则。比如它可能凭经验认为“登录密码重置后需要重新验证邮箱”但你的业务并不需要这一步。解决手段是让 Agent 在生成用例时强制调用接口文档工具和历史缺陷工具。工具返回的结果作为真实上下文注入到 Agent 的观测空间中模型基于真实数据而不是训练记忆来设计用例。这比单纯依赖 Prompt 更可靠。如果模型在推理过程中没有调用工具就直接输出可以设置一个检查步骤发现结果缺少接口参数字段时将结果丢弃并重新触发生成要求“必须调用 get_api_schema 工具后再生成”。5.3 配置 LangChain 记忆提升多轮对话效果如果你希望测试人员可以和 Agent 多轮对话例如先让它生成登录模块的用例再追问“再加几个并发登录的用例”就需要为 Agent 配置 Memory。在 LangChain 中可以结合ConversationBufferMemory或MemorySaver来存储历史消息。配置方式需要结合你使用的 LangChain 版本示例思路如下from langchain.memory import ConversationBufferMemory from langchain.agents import AgentExecutor memory ConversationBufferMemory( memory_keychat_history, return_messagesTrue ) executor AgentExecutor( agentagent, toolsself.tools, memorymemory, verboseTrue )配置记忆之后Agent 会记住之前的用例生成结果你可以在后续对话中提出“把 TC-003 改成 P1 优先级并补充一个等价类用例”这类要求Agent 能够理解上下文并执行修改。注意新版 LangChain 中 Memory API 可能有所调整建议以官方文档为准。如果你的场景是一次性批量生成用例不建议开启记忆因为历史消息会占用大量 token增加成本。5.4 输出解析器与容错处理在实际运行中大模型偶尔会输出不完整的 JSON或者字段缺失。handle_parsing_errorsTrue可以在解析失败时让 Agent 自动纠错并重试。另外Pydantic 输出解析器会在字段缺失时抛错此时 Agent 会将错误信息反馈给模型要求它按格式重新输出。为了提升成功率建议在 Prompt 中明确给出 JSON 示例而不只是依赖format_instructions。这样模型在生成时有一个更直观的参考。6. 实战场景扩展自动生成接口测试脚本6.1 从测试用例到可执行脚本如果生成的测试用例只是一份文档价值仍然有限。更好的方案是让 Agent 继续往下走根据接口测试用例自动生成可执行的 pytest 脚本。设计思路如下使用另一个 Agent输入是接口文档 JSON。Agent 生成一个 pytest 测试文件包含正常场景、异常场景、边界场景的测试函数。生成的脚本带有清晰的断言语句。后续可直接通过 pytest 命令执行。来看一个简化版的接口测试脚本生成 Agent# 文件路径agents/api_test_script_agent.py from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI class ApiScriptGenerateAgent: def __init__(self, model_namegpt-4o): self.llm ChatOpenAI(modelmodel_name, temperature0) def generate(self, api_schema: str) - str: prompt ChatPromptTemplate.from_messages([ (system, 你是一名测试开发工程师请根据接口文档生成可直接运行的 pytest 测试脚本。 要求 1. 使用 requests 库发送 HTTP 请求。 2. 覆盖正常场景、参数缺失、参数类型错误、边界值异常。 3. 使用 pytest.mark.parametrize 驱动多组测试数据。 4. 函数命名清晰包含断言。 5. 直接输出 Python 代码不要输出额外解释。 ), (human, 接口文档\n{api_schema}) ]) chain prompt | self.llm return chain.invoke({api_schema: api_schema}).content生成的脚本示例预期输出import requests import pytest BASE_URL http://127.0.0.1:8000 def test_login_success(): resp requests.post( f{BASE_URL}/api/login, json{phone: 13800000000, password: correct_password, remember: False} ) assert resp.status_code 200 assert resp.json()[code] 0 assert token in resp.json()[data] pytest.mark.parametrize(phone,password, [ (12345, abc123), (13800000000, ), (1380000000, abc123), ]) def test_login_invalid_params(phone, password): resp requests.post( f{BASE_URL}/api/login, json{phone: phone, password: password} ) assert resp.status_code 200 assert resp.json()[code] ! 0生成脚本之后还需要经过代码格式检查和人工审核确认请求路径、断言逻辑符合实际项目要求。AI 生成的脚本只能作为基线不能直接无脑用于生产。7. 实战场景扩展性能测试分析报告自动输出7.1 性能测试报告生成的痛点性能测试在测试体系中比较特殊很多人觉得“数据太专业报告很难写”。传统做法是先把 JMeter、LoadRunner 跑完导出汇总数据然后人工在 Word 或 PPT 里填表写结论。一次性能测试周期报告撰写常常要占掉半天甚至一天的时间。如果把性能测试结果数据交给 LangChain Agent 处理就能自动完成以下工作读取性能测试汇总 CSV 或 JSON。分析各接口的响应时间、TPS、错误率、资源使用情况。对照性能需求阈值判断是否达标。输出包含结论、瓶颈分析、优化建议的 Markdown 报告。7.2 性能数据分析 Agent 实现创建agents/perf_agent.py# 文件路径agents/perf_agent.py import json from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser class PerfAnalysisAgent: def __init__(self, model_namegpt-4o): self.llm ChatOpenAI(model_namemodel_name, temperature0.2) def generate_report(self, perf_data: dict, requirement: str) - str: prompt ChatPromptTemplate.from_messages([ (system, 你是一名资深性能测试工程师请根据性能测试数据输出一份专业的性能测试分析报告。 报告必须包含 1. 测试概况测试目标、测试环境、压力策略。 2. 测试结果汇总各接口的TPS、平均响应时间、P95响应时间、错误率。 3. 结果分析与性能需求阈值对比给出达标/未达标结论。 4. 瓶颈分析根据数据判断可能存在的性能瓶颈。 5. 优化建议给出具体可执行的优化方向。 6. 风险提示说明本次测试的局限性。 使用 Markdown 格式输出要求数据准确、结论明确。 ), (human, 性能测试需求{requirement}\n\n性能测试数据\n{perf_data}) ]) chain prompt | self.llm | StrOutputParser() return chain.invoke({ requirement: requirement, perf_data: json.dumps(perf_data, ensure_asciiFalse, indent2) })7.3 模拟性能数据演示准备一份模拟的性能测试汇总数据{ test_duration: 15min, concurrency: 100, apis: [ { api_name: POST /api/login, tps: 245, avg_rt: 356, p95_rt: 720, error_rate: 0.02, cpu_usage: 68, memory_usage: 72 }, { api_name: POST /api/order/create, tps: 120, avg_rt: 580, p95_rt: 1100, error_rate: 0.08, cpu_usage: 85, memory_usage: 80 }, { api_name: GET /api/order/list, tps: 320, avg_rt: 180, p95_rt: 350, error_rate: 0.01, cpu_usage: 45, memory_usage: 50 } ] }在main.py中追加调用代码from agents.perf_agent import PerfAnalysisAgent perf_agent PerfAnalysisAgent(model_namegpt-4o) report perf_agent.generate_report( perf_dataperf_data, requirement系统支持200并发用户接口平均响应时间小于500msP95小于1000ms错误率小于0.1% ) with open(output/reports/perf_report.md, w, encodingutf-8) as f: f.write(report) print(report)生成报告的核心价值在于Agent 不是简单复述数据而是把“平均响应时间达标但 P95 偏高”这类深层数据规律识别出来给出有价值的结论。例如它可能会得出“order/create 接口 P95 为 1100ms超出 1000ms 阈值错误率 0.08% 接近上限存在数据库连接池不足或慢 SQL 的嫌疑”这类分析这个输出已经接近一位中级性能测试工程师的分析水平。7.4 接入 JMeter 和 LoadRunner 测试结果在实际项目中性能测试数据通常来自 JMeter 的Summary Report或Aggregate Report导出 CSV以及 LoadRunner 的 Analysis 报告。处理思路是先用 Python 读取 CSV 文件并转换为 JSON 字典再传给 Agent。示例代码import pandas as pd # 读取 JMeter Aggregate Report 导出的 CSV df pd.read_csv(jmeter_aggregate_report.csv) perf_data { apis: [ { api_name: row[Label], samples: row[#Samples], avg_rt: row[Average], p95_rt: row[90% Line], # 根据实际列名调整 error_rate: row[Error %], tps: row[Throughput] } for _, row in df.iterrows() ] }需要注意的是不同版本的 JMeter 导出的列名略有差异比如“90% Line”、“95% Line”、“Throughput”等要以实际导出文件为准。LoadRunner 则通常需要先将 Analysis 结果导出为 Excel 或 CSV再走同样的流程。8. 如何让 Agent 更懂你的项目8.1 沉淀项目专属知识和规范测试用例生成 Agent 能不能真正落地很大程度上取决于它是否“了解你的项目”。通用大模型知道“如何写测试用例”但不知道你的项目叫“神策订单系统”也不知道贵司要求“所有用例必须包含前置环境标识、数据准备 SQL、断言级别”等规范。为了让 Agent 更懂项目建议构建一个项目知识库用 RAG检索增强生成的方式在运行时补充上下文。具体操作步骤收集项目文档需求文档、接口文档、测试计划、历史用例、线上事故复盘文档。将文档切片并向量化存入向量数据库。Agent 在生成用例之前先从知识库中检索与当前需求相关的资料片段。将检索到的片段插入 Prompt 上下文让 Agent 基于这些知识生成用例。在 LangChain 中可以通过RetrievalQA或create_retrieval_chain实现也可以将检索结果封装成一个自定义工具。这里不过度展开但需要明确一个思路RAG 不是“标准配置”而是项目复杂到一定程度后的必然选择。如果项目接口文档简单、业务规则清晰直接用工具调用就足够了。8.2 根据反馈持续迭代 PromptAgent 上线后建议建立一个“生成结果反馈闭环”测试人员在使用过程中对生成用例进行批注标记“无用”“重复”“缺少场景”。定期收集这些反馈分析 Agent 的错误类型。根据错误类型调整 Prompt或增加工具约束。将高频被修正的用例场景固化到 Prompt 中作为示例。例如如果 Agent 总是漏掉“金额为0”的边界用例就可以在 Prompt 中加入一条规则“涉及金额、数量等数值字段时必须包含0值、负值、极大值、极小值四类边界用例。”这种迭代方式比频繁更换模型更有效。8.3 用 LangGraph 编排复杂流程如果你的测试 Agent 要完成的任务链路越来越长例如“需求解析 → 用例生成 → 测试数据准备 → 脚本生成 → 冒烟执行 → 报告输出”六步串联且中间需要人工审批节点建议从 LangChain Agent 切换到 LangGraph。LangGraph 的优势在于可以精确控制每个节点的输入输出和跳转逻辑。支持条件分支例如用例评审不通过则返回修改。支持全局状态管理多个节点之间可以共享中间数据。可以配合 LangSmith 做链路追踪排查每一步的执行情况。从 LangChain 迁移到 LangGraph 的学习成本不算特别高核心是把原来的“Agent 一步到底”改成“节点 边的图结构”。对于初创团队或 POC 阶段先用 LangChain 把流程跑通后续再演进到 LangGraph 是性价比最高的方式。9. 常见问题与排查思路问题现象常见原因解决思路调用 OpenAI 接口超时网络不稳定或 Base URL 配置错误检查环境变量确认OPENAI_BASE_URL是否正确尝试更换网络后重试Agent 不调用工具直接输出结果工具描述不清晰或 Prompt 未强调必须调用工具在 System Prompt 中明确“涉及接口必须调用 get_api_schema”并给一个工具调用示例生成的 JSON 解析失败模型输出不完整或字段命名不匹配开启handle_parsing_errorsTrue同时在 Prompt 中给出 JSON 示例生成的用例重复度高Prompt 没有去重要求增加“删除语义重复用例”的规则并在输出前增加去重过滤步骤用例覆盖不到边界条件Prompt 缺少边界设计方法的约束在 Prompt 中列出必须覆盖的边界值场景类型性能报告结论和真实情况不符数据预处理不完整或关键指标缺失先检查输入数据是否包含错误率、TPS、P95 等必要指标模型回答字数过多超出上下文历史消息太长使用摘要记忆替代完整记忆或定期清空历史消息LangChain API 报错提示属性不存在版本差异导致 API 变更固定 LangChain 版本查阅对应版本文档Agent 生成脚本不能运行请求路径或断言与项目不符生成后增加一次格式检查与人工 review 流程10. AI 测试落地过程中的工程建议10.1 安全与权限边界在真实项目中接入 AI Agent安全是最重要的一条线。有几个原则需要提前定好涉及生产环境的任何操作都必须使用最小权限账号且提前申请审批。测试用例生成 Agent 只能读取内部测试环境的数据不能访问生产数据库。如果要让 Agent 操作测试管理平台必须通过 API Token 授权并限制 Token 的权限范围。大模型生成的所有测试脚本必须经过人工 Review 后才能执行。禁止将敏感业务数据直接发送到外部模型 API必要时采用私有化部署。10.2 数据与结果管理建议将 Agent 的输入输出全部记录到日志系统方便事后审计。每一步的记录至少包含调用的模型名称和版本。输入的 token 数量和消耗成本。生成的中间结果和最终输出。人工反馈信息和后续修改内容。通过这样的日志团队可以量化 AI 测试的投入产出比也能在出现问题时快速定位是模型问题、Prompt 问题还是数据问题。10.3 模型选型建议在测试用例生成这个场景里模型选择并不一定越贵越好。在实际对比中我们发现如果只是做初步用例头脑风暴轻量级模型足够。如果要生成高质量的多维度用例建议使用能力较强的旗舰模型。如果要做性能测试报告分析模型的分析能力比代码生成能力更重要。建议团队先拿 10 个典型需求做一次模型评测对比不同模型的用例覆盖度、准确率和格式合规率再决定正式环境用哪个模型。不要一上来就迷信“最大的模型”。10.4 成本控制Agent 应用的成本主要来自 token 消耗。工具返回的接口文档 JSON 很可能会在多轮推理中被反复发送给模型尤其是使用 ReAct 模式时模型每执行一步都会携带完整的对话历史。控制成本的几个手段精简工具返回内容只返回必要字段而不是整个接口文档。使用摘要记忆而不是完整保存所有历史消息。对简单任务使用温度参数为 0减少无效重试。对重复任务做结果缓存相同需求不重复调用模型。设定单次任务的 token 上限防止死循环。11. 学习路线与下一步规划如果你目前刚接触 LangChain Agent建议按下面的路线走一遍第一阶段入门 LangChain 基础 API理解 ChatModel、Prompt、OutputParser 这三个核心抽象尝试完成一个“调用模型生成一段文本”的最小示例。第二阶段掌握工具调用和 Agent 执行流程学会使用tool装饰器定义工具并理解 Agent 是如何根据任务描述决定调用哪个工具的。第三阶段开发一个垂直领域 Agent比如本文中的测试用例生成 Agent。不要追求功能复杂先把一条链路走通再逐步增加工具和约束。第四阶段引入 RAG 和记忆让 Agent 能结合项目知识库和历史对话给出更精准的输出。第五阶段学习 LangGraph理解状态机编排将单一 Agent 升级为多 Agent 协作系统。第六阶段工程化落地包括模型评测、成本监控、日志审计、人工审核闭环、私有化部署。在实际项目中我建议先选一个价值明确、流程标准化程度高、结果容易验证的测试场景切入比如“接口测试用例生成”不要一上来就要覆盖所有测试类型。先把单点做到可用再逐步扩展这是 AI 测试落地最稳的路径。最后提醒一句AI 测试的定位应该是“测试工程师的超级助手”而不是“替代测试工程师”。工具能帮我们节省重复劳动时间但测试策略的制定、关键业务的判断、上线风险的决策仍然需要人来把握。把 Agent 当成一个能随叫随到、知识面极广但不一定了解你项目的实习生来看待可能更贴近实际情况。你要做的是教会它你的规范、你的业务、你的坑然后让它帮你干那些确定性高的脏活累活。 用LangChain Agent实现测试用例自动生成与AI测试提效实战
先说说这次实战的背景。最近在测试团队内部尝试把大模型接入日常流程最早只是想解放一部分写用例的时间后来发现 LangChain 在串联“需求理解—用例设计—结果分析”这条链路上比想象中顺手。调研了目前各家用 AI 辅助测试的方案之后决定自己搭一个基于 LangChain 的 Agent 原型把测试用例生成、接口测试脚本生成、性能测试结果分析报告输出这几个高频场景全部串起来。动手之后才发现LangChain 真正值钱的地方不只是“能调用模型”而是它能把工具调用、上下文管理、多步骤执行这些逻辑组织成一个稳定的框架帮助我们把测试工作的结构化思维固化到代码里。本文将围绕这套测试用例生成 Agent 的设计思路与完整实现展开从环境准备、核心链路拆解、关键代码示例、运行效果到常见排错、工程化落地建议一次讲清楚。如果你对 LangChain Agent 开发、AI 测试提效、测试用例自动化生成、性能测试报告自动输出这几个方向感兴趣这篇文章应该能给你一套可以直接参考的完整方案。1. 为什么我们要自研一个测试用例生成 Agent1.1 AI 测试常见的痛点传统测试用例设计高度依赖测试工程师的个人经验和业务熟悉度新人写出来的用例经常覆盖不全老手写用例质量虽高但耗时很长。引入 AI 辅助之后最常见的做法是把需求描述扔给 ChatGPT让它“帮我写测试用例”然后复制粘贴到 Excel。这样做确实快但问题也很明显上下文太短模型只能根据一段孤立的需求文本生成用例缺少对项目背景、接口数据结构、历史缺陷信息的理解。输出不稳定换一个 Prompt 表述结果差异很大。后续无法自动化生成的结果是自然语言文本没有结构化的 JSON 或测试步骤不能直接接入测试管理平台。多样例之间用例重复率高、优先级设计不合理边界条件经常漏。这些痛点的根源在于大模型本质上是一个“文本生成器”它不具备主动查询接口定义、分析历史缺陷、检查数据库字段这些能力。如果想要 AI 真正辅助测试就需要给它装上“手和眼睛”让它能够调用工具、访问外部数据源并按测试设计的逻辑一步步执行。这正好是 LangChain Agent 擅长的领域。1.2 LangChain Agent 能做什么LangChain 是一个面向大语言模型应用的开发框架核心抽象包括模型封装、Prompt 管理、记忆、工具调用、Agent 编排。在测试场景里我们可以把 Agent 理解为“一个会使用工具的 AI 助手”它不仅能回答问题还能按照你设定的流程去执行任务。对于测试用例生成这个场景Agent 可以做以下几件事接收输入的需求描述自动理解业务功能点。调用接口文档解析工具拉取真实的请求参数、响应字段、边界约束。调用历史缺陷查询工具找到过去容易出问题的模块和场景。按照等价类划分、边界值分析、场景法等测试设计方法生成用例。对生成的用例进行去重、补充、排序输出结构化 JSON。将结果以指定格式写入测试管理平台或导出为文件。这已经不是简单的“套 Prompt”而是一套可以复用的测试辅助工具。多个 Agent 组合使用还能完成从需求解析、用例生成、脚本编写到性能报告输出的完整链路。1.3 为什么选择 LangChain 而不是直接调 API可能有同学会问直接写代码调用大模型 API 不也能完成吗为什么还要引入 LangChain直接调用 API 的方式适合一次性脚本但一旦我们要实现“多步骤任务、工具选择、记忆保持、结果结构化输出”就会发现自己重写一套框架非常繁琐。LangChain 提供了几个非常省事的能力标准化的模型调用接口切换模型厂商时只需改少量配置。内置 Agent 执行框架支持 ReAct、Plan-and-Execute 等常见 Agent 模式。丰富的工具集成也可以自定义函数作为 Tool。输出解析器可以强制模型按指定 JSON 结构输出。消息记忆机制多轮交互中保持上下文。更重要的是LangChain 的生态足够大网上资料多团队成员接手成本低。如果你只是做几个 demo直接调 API 没问题但如果你要搭建一套可持续维护的 AI 测试基础设施LangChain 这类框架可以帮你省下不少基建代码。这里也顺便解答一个经常被问到的问题LangChain 和 LangGraph 有什么区别简单来说LangChain 提供了 Agent 的基础能力适合流程相对简单、步骤不固定的场景LangGraph 是 LangChain 团队推出的更底层的编排框架适合需要精确控制状态流转、支持循环分支、可观测性要求较高的复杂 Agent 应用。用测试业务来类比LangChain 像是“用例执行引擎”LangGraph 则像“测试流程编排引擎”。对于本文中的测试用例生成 Agent使用 LangChain 已经足够如果后续要做跨团队的完整测试流水线建议了解一下 LangGraph。2. 环境准备与版本说明2.1 基础运行环境本文的示例代码基于 Python 3操作系统不限Windows、macOS、Linux 都可以跑。建议使用虚拟环境管理依赖避免污染系统 Python。需要安装的核心依赖如下pip install langchain pip install langchain-openai pip install langchain-community pip install openai pip install pandas pip install pydantic版本方面LangChain 目前迭代速度较快API 变化也比较大。本文示例基于 0.1.x 到 0.2.x 之间的常见 API 编写。在动手之前建议先执行下列命令确认当前环境版本python --version pip show langchain pip show langchain-openai如果发现安装了更高版本导致 API 不兼容有两种处理方式一是按官方文档迁移到新写法二是固定版本安装例如pip install langchain0.2.16。生产的项目建议锁版本。2.2 模型选择说明在示例代码中默认使用 OpenAI 兼容接口通过环境变量配置 API Key。如果你使用的是国内大模型服务商提供的 OpenAI 兼容网关通常只需要修改base_url和api_key两个配置项不需要改动业务逻辑。这里需要特别说明的是大模型的能力直接影响测试用例生成质量。在实际项目落地时建议根据业务安全要求来选择模型部署方式。涉及敏感数据的项目优先使用私有化部署模型一般业务场景可以使用云服务。无论选择哪种模型都要在测试环境充分验证生成结果并保留人工审核环节。配置环境变量示例export OPENAI_API_KEYsk-xxxxxxxxxxxx export OPENAI_BASE_URLhttps://api.xxx.com/v1在 Windows PowerShell 下可以写成$env:OPENAI_API_KEYsk-xxxxxxxxxxxx $env:OPENAI_BASE_URLhttps://api.xxx.com/v12.3 项目整体结构为了方便管理我们新建一个名为ai_test_agent的项目目录ai_test_agent/ ├── requirements.txt ├── .env ├── agents/ │ ├── __init__.py │ ├── requirement_agent.py │ ├── testcase_agent.py │ └── perf_agent.py ├── tools/ │ ├── __init__.py │ ├── api_schema_tool.py │ └── history_bug_tool.py ├── models/ │ ├── __init__.py │ ├── testcase_schema.py │ └── perf_report_schema.py ├── output/ │ ├── testcases/ │ └── reports/ ├── main.py └── utils.py目录职责说明agents/存放不同的 Agent 定义。tools/存放自定义工具例如接口文档解析工具、历史缺陷查询工具。models/存放输出数据模型也就是我们期望大模型输出的结构化 JSON 结构。output/存放生成的测试用例文件和测试报告。main.py是主入口负责串联整个流程。3. 测试用例生成 Agent 的核心设计3.1 整体流程设计在开始写代码之前先梳理一下整个 Agent 的工作流程。我们的目标是从一段需求描述出发自动生成一份结构化的测试用例集。流程可以拆成以下步骤第一步需求解析Agent 先读取需求描述提取出功能模块、用户角色、核心业务流程、业务规则、输入输出等关键信息。如果需求文本中提到了接口就调用接口文档解析工具获取接口的请求参数和响应字段。第二步测试点提取基于需求解析结果Agent 按照功能列表和业务规则生成测试点。例如一个登录功能测试点可能包括正确用户名密码登录、错误密码登录、账号不存在、密码为空、账号被锁定、验证码过期、并发登录等。第三步测试用例生成对每个测试点Agent 按照测试设计方法来补充用例详情包括前置条件、测试步骤、输入数据、预期结果、优先级、用例类型。第四步用例规则套用与去重Agent 套用用例规范规则从覆盖度、重复度、边界条件、异常场景几个维度对生成结果进行优化。这里可以调用一个“测试用例规范检查工具”自动把不满足要求的用例打回重写。第五步结构化输出最终结果通过输出解析器转换成 JSON 格式写入文件。3.2 Agent 输入输出设计为了让 Agent 的生成结果稳定、可复用建议先定义好输入和输出的数据结构。输入需求描述示例{ requirement_id: REQ-2025-001, title: 用户登录功能, description: 用户通过手机号和密码登录系统登录成功后跳转到首页。密码连续错误5次后账号锁定30分钟。支持记住密码功能。, related_api: [ { name: POST /api/login, method: POST, request_params: phone: string, password: string, remember: boolean, response: { code: 0, message: success, data: { token: string } } } ], priority: P0 }输出测试用例结构示例{ requirement_id: REQ-2025-001, test_cases: [ { case_id: TC-001, case_title: 正确手机号和密码登录成功, precondition: 已注册用户手机号13800000000密码正确, steps: [ 打开登录页面, 输入手机号13800000000, 输入正确密码, 点击登录按钮 ], test_data: { phone: 13800000000, password: correct_password }, expected_result: 登录成功跳转首页右上角显示用户名, case_type: 功能测试, priority: P0 } ] }定义好结构之后在代码中使用 Pydantic 模型来约束输出格式这样大模型生成的结果即使缺少某些字段也会被解析器修正。3.3 核心工具设计为了让 Agent 具备“动手能力”我们需要自定义几个工具。接口文档解析工具很多测试项目中接口信息散落在 YAPI、Swagger 或者文档页面里。我们可以写一个工具函数接收一个接口名称返回该接口的详细信息。在实际演示中先用一个 mock 字典代替。历史缺陷工具这个工具用于查询历史缺陷帮助 Agent 在生成用例时重点关注曾出现问题的场景。比如某模块历史缺陷中“金额为0时前端校验通过但后端报错”的频率很高那 Agent 在生成用例时会自动补充这个边界场景。from langchain_core.tools import tool tool def get_history_bug_count(module_name: str) - str: 查询指定模块的历史缺陷数量与高频缺陷类型。 module_name: 模块名称例如 登录、支付 bug_db { 登录: 历史缺陷共15个高频类型验证码过期、账号锁定逻辑错误、密码错误提示不明确, 支付: 历史缺陷共32个高频类型金额为0未拦截、重复支付、并发扣款超扣、回调顺序异常, 订单: 历史缺陷共28个高频类型订单状态流转错误、超时未关闭、分页丢失条件 } return bug_db.get(module_name, 暂未发现历史缺陷数据)这里只是示例真实项目中可以将查询逻辑换成数据库查询或接口调用。关键点在于工具函数最好带有清晰的 docstring因为 LangChain 会把函数名称和介绍一并发送给模型模型根据这个描述来判断何时调用该工具。4. 完整实战搭建测试用例生成 Agent4.1 创建项目结构和安装依赖先创建项目目录和虚拟环境mkdir ai_test_agent cd ai_test_agent python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate创建requirements.txt文件langchain0.1.0,0.3.0 langchain-openai0.1.0 langchain-community0.2.0 openai1.0.0 pandas2.0.0 pydantic2.0.0 python-dotenv1.0.0安装依赖pip install -r requirements.txt4.2 自定义工具实现创建tools/api_schema_tool.py实现接口文档解析工具。这里先使用 mock 数据演示如何定义 Tool。实际项目中你可以替换为读取 YAPI 接口文档或数据库配置。# 文件路径tools/api_schema_tool.py from langchain_core.tools import tool tool def get_api_schema(api_name: str) - str: 根据接口名称查询接口的请求参数和响应结构。 api_name: 接口名称例如 login、create_order api_docs { login: { name: POST /api/login, method: POST, request_params: { phone: string, 手机号, 11位, password: string, 密码, 6-20位字母数字, remember: boolean, 是否记住密码 }, response: { code: int, 0表示成功, message: string, 提示信息, data: {token: string, 登录凭证} }, constraints: [ phone 必须为11位有效手机号, password 长度为6-20位, 连续5次错误密码锁定账号30分钟 ] }, create_order: { name: POST /api/order/create, method: POST, request_params: { user_id: string, 用户ID, product_id: string, 商品ID, quantity: int, 购买数量, 1-99, coupon_id: string, 优惠券ID, 可为空 }, response: { code: int, 0表示成功, message: string, 提示信息, data: {order_id: string, 订单号} }, constraints: [ quantity 必须在1-99之间, 商品必须上架, 优惠券必须属于当前用户且未被使用 ] } } api api_docs.get(api_name) if not api: return 未找到该接口文档请确认接口名称。 import json return json.dumps(api, ensure_asciiFalse, indent2)同样创建tools/history_bug_tool.py# 文件路径tools/history_bug_tool.py from langchain_core.tools import tool tool def get_history_bug(module_name: str) - str: 查询指定模块的历史缺陷信息帮助测试用例设计时重点关注高频缺陷场景。 module_name: 模块名称例如 login、order、payment bug_db { login: 历史缺陷15个密码连续错误后锁定逻辑异常、验证码过期后提示不友好、手机号校验不严格, order: 历史缺陷22个数量边界未校验、超时订单状态未流转、批量下单并发场景数据错乱, payment: 历史缺陷30个订单金额为0时未拦截、重复支付回调、并发扣款超扣、退款金额大于原订单 } return bug_db.get(module_name, 该模块暂无历史缺陷数据)4.3 定义输出数据模型创建models/testcase_schema.py# 文件路径models/testcase_schema.py from typing import List, Dict from pydantic import BaseModel, Field class TestCase(BaseModel): case_id: str Field(description用例编号) case_title: str Field(description用例标题) precondition: str Field(description前置条件) steps: List[str] Field(description测试步骤) test_data: Dict Field(description测试数据) expected_result: str Field(description预期结果) case_type: str Field(description用例类型如功能测试、边界测试、异常测试) priority: str Field(description优先级P0/P1/P2/P3) class TestCaseList(BaseModel): requirement_id: str Field(description需求编号) requirement_title: str Field(description需求标题) test_cases: List[TestCase] Field(description测试用例列表)这样做的目的是给大模型的输出加上一层约束LangChain 会结合 Pydantic 模型生成JSON Schema要求大模型输出的字段必须符合这个结构。4.4 测试用例生成 Agent 实现创建agents/testcase_agent.py。这个 Agent 是整个系统的核心也是代码量最大的部分。# 文件路径agents/testcase_agent.py import json from typing import Any, Dict from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_core.output_parsers import PydanticOutputParser from tools.api_schema_tool import get_api_schema from tools.history_bug_tool import get_history_bug from models.testcase_schema import TestCaseList class TestcaseGenerateAgent: def __init__(self, model_name: str gpt-4o, temperature: float 0.2): self.llm ChatOpenAI( modelmodel_name, temperaturetemperature ) self.parser PydanticOutputParser(pydantic_objectTestCaseList) self.tools [get_api_schema, get_history_bug] self.prompt ChatPromptTemplate.from_messages([ (system, 你是一名资深测试工程师擅长测试用例设计。 你的任务是根据需求描述借助可用工具生成一份完整、专业、可直接执行的测试用例集合。 要求如下 1. 如果需求中涉及接口必须调用 get_api_schema 工具获取接口定义基于真实参数设计用例。 2. 必须调用 get_history_bug 工具查询相关模块历史缺陷补充对应的高风险场景。 3. 测试用例必须覆盖正常功能、边界值、异常场景、权限/安全、兼容性等维度。 4. 每个用例包含用例编号、标题、前置条件、步骤、测试数据、预期结果、用例类型、优先级。 5. 生成结果必须符合指定 JSON 结构。 {format_instructions} ), (human, 需求描述\n{requirement_text}), MessagesPlaceholder(variable_nameagent_scratchpad), ]).partial(format_instructionsself.parser.get_format_instructions()) def build_agent(self) - AgentExecutor: agent create_openai_tools_agent( llmself.llm, toolsself.tools, promptself.prompt ) executor AgentExecutor( agentagent, toolsself.tools, verboseTrue, handle_parsing_errorsTrue ) return executor def generate(self, requirement_text: str) - Dict[str, Any]: executor self.build_agent() result executor.invoke({ requirement_text: requirement_text }) # 输出解析为结构化数据 parsed self.parser.invoke(result[output]) return parsed.dict()4.5 调用示例与运行创建一个main.py只保留最核心的调用逻辑# 文件路径main.py import json from agents.testcase_agent import TestcaseGenerateAgent if __name__ __main__: requirement_text 需求编号REQ-2025-001 需求名称用户登录功能 需求描述用户通过手机号和密码登录系统登录成功后跳转到首页。 密码连续错误5次后账号锁定30分钟。支持记住密码功能。 涉及接口login agent TestcaseGenerateAgent(model_namegpt-4o) result agent.generate(requirement_text) with open(output/testcases/testcase_REQ-2025-001.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print( 生成结果 ) for tc in result[test_cases]: print(f{tc[case_id]} | {tc[case_title]} | {tc[priority]})运行前确保output/testcases目录存在mkdir -p output/testcases python main.py运行后预期输出类似 生成结果 TC-001 | 正确手机号和密码登录成功 | P0 TC-002 | 手机号格式不正确 | P1 TC-003 | 密码错误1次提示重新输入 | P1 TC-004 | 密码连续错误5次账号锁定30分钟 | P0 TC-005 | 锁定期间使用正确密码登录失败 | P0 TC-006 | 记住密码功能验证 | P2 TC-007 | 登录接口响应超时 | P2同时在output/testcases/testcase_REQ-2025-001.json中可以看到完整的 JSON 结构化结果。4.6 结果说明从结果中可以看出Agent 已经自动完成了以下工作识别了“连续错误5次锁定”这个关键业务规则并生成对应的正反向用例。设置了 P0、P1、P2 优先级区分核心功能和次要功能。对手机号格式、密码错误次数、锁定时间等边界条件做了覆盖。补充了记住密码、响应超时等容易被遗漏的非主路径测试点。这就是把测试设计方法论“喂”给 Agent 的效果。它不是在瞎编测试步骤而是像一个有经验的测试工程师那样围绕功能点、边界条件、异常场景和业务规则展开用例设计。5. 核心原理拆解与优化技巧5.1 Prompt 设计为什么如此重要在 Agent 应用中Prompt 是最容易被低估的部分。同一个模型Prompt 质量不同生成用例的质量差异非常大。结合测试场景有几点经验可以参考角色限定让模型充当“资深测试工程师”而不是普通的“AI 助手”。角色设定的价值在于让模型调用更专业的思维方式。明确输出约束告诉模型必须覆盖功能、边界、异常等测试维度而不是“写出你可能想到的测试场景”。提供工具使用规则明确要求模型在涉及接口时先调用 API 工具而不是凭记忆输出。这能有效减少模型“幻觉”问题。结构化要求用 Pydantic 约束输出格式并明确要求必须输出指定字段。5.2 工具调用减少模型幻觉在测试用例生成场景中模型最容易编造的内容是接口参数和业务规则。比如它可能凭经验认为“登录密码重置后需要重新验证邮箱”但你的业务并不需要这一步。解决手段是让 Agent 在生成用例时强制调用接口文档工具和历史缺陷工具。工具返回的结果作为真实上下文注入到 Agent 的观测空间中模型基于真实数据而不是训练记忆来设计用例。这比单纯依赖 Prompt 更可靠。如果模型在推理过程中没有调用工具就直接输出可以设置一个检查步骤发现结果缺少接口参数字段时将结果丢弃并重新触发生成要求“必须调用 get_api_schema 工具后再生成”。5.3 配置 LangChain 记忆提升多轮对话效果如果你希望测试人员可以和 Agent 多轮对话例如先让它生成登录模块的用例再追问“再加几个并发登录的用例”就需要为 Agent 配置 Memory。在 LangChain 中可以结合ConversationBufferMemory或MemorySaver来存储历史消息。配置方式需要结合你使用的 LangChain 版本示例思路如下from langchain.memory import ConversationBufferMemory from langchain.agents import AgentExecutor memory ConversationBufferMemory( memory_keychat_history, return_messagesTrue ) executor AgentExecutor( agentagent, toolsself.tools, memorymemory, verboseTrue )配置记忆之后Agent 会记住之前的用例生成结果你可以在后续对话中提出“把 TC-003 改成 P1 优先级并补充一个等价类用例”这类要求Agent 能够理解上下文并执行修改。注意新版 LangChain 中 Memory API 可能有所调整建议以官方文档为准。如果你的场景是一次性批量生成用例不建议开启记忆因为历史消息会占用大量 token增加成本。5.4 输出解析器与容错处理在实际运行中大模型偶尔会输出不完整的 JSON或者字段缺失。handle_parsing_errorsTrue可以在解析失败时让 Agent 自动纠错并重试。另外Pydantic 输出解析器会在字段缺失时抛错此时 Agent 会将错误信息反馈给模型要求它按格式重新输出。为了提升成功率建议在 Prompt 中明确给出 JSON 示例而不只是依赖format_instructions。这样模型在生成时有一个更直观的参考。6. 实战场景扩展自动生成接口测试脚本6.1 从测试用例到可执行脚本如果生成的测试用例只是一份文档价值仍然有限。更好的方案是让 Agent 继续往下走根据接口测试用例自动生成可执行的 pytest 脚本。设计思路如下使用另一个 Agent输入是接口文档 JSON。Agent 生成一个 pytest 测试文件包含正常场景、异常场景、边界场景的测试函数。生成的脚本带有清晰的断言语句。后续可直接通过 pytest 命令执行。来看一个简化版的接口测试脚本生成 Agent# 文件路径agents/api_test_script_agent.py from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI class ApiScriptGenerateAgent: def __init__(self, model_namegpt-4o): self.llm ChatOpenAI(modelmodel_name, temperature0) def generate(self, api_schema: str) - str: prompt ChatPromptTemplate.from_messages([ (system, 你是一名测试开发工程师请根据接口文档生成可直接运行的 pytest 测试脚本。 要求 1. 使用 requests 库发送 HTTP 请求。 2. 覆盖正常场景、参数缺失、参数类型错误、边界值异常。 3. 使用 pytest.mark.parametrize 驱动多组测试数据。 4. 函数命名清晰包含断言。 5. 直接输出 Python 代码不要输出额外解释。 ), (human, 接口文档\n{api_schema}) ]) chain prompt | self.llm return chain.invoke({api_schema: api_schema}).content生成的脚本示例预期输出import requests import pytest BASE_URL http://127.0.0.1:8000 def test_login_success(): resp requests.post( f{BASE_URL}/api/login, json{phone: 13800000000, password: correct_password, remember: False} ) assert resp.status_code 200 assert resp.json()[code] 0 assert token in resp.json()[data] pytest.mark.parametrize(phone,password, [ (12345, abc123), (13800000000, ), (1380000000, abc123), ]) def test_login_invalid_params(phone, password): resp requests.post( f{BASE_URL}/api/login, json{phone: phone, password: password} ) assert resp.status_code 200 assert resp.json()[code] ! 0生成脚本之后还需要经过代码格式检查和人工审核确认请求路径、断言逻辑符合实际项目要求。AI 生成的脚本只能作为基线不能直接无脑用于生产。7. 实战场景扩展性能测试分析报告自动输出7.1 性能测试报告生成的痛点性能测试在测试体系中比较特殊很多人觉得“数据太专业报告很难写”。传统做法是先把 JMeter、LoadRunner 跑完导出汇总数据然后人工在 Word 或 PPT 里填表写结论。一次性能测试周期报告撰写常常要占掉半天甚至一天的时间。如果把性能测试结果数据交给 LangChain Agent 处理就能自动完成以下工作读取性能测试汇总 CSV 或 JSON。分析各接口的响应时间、TPS、错误率、资源使用情况。对照性能需求阈值判断是否达标。输出包含结论、瓶颈分析、优化建议的 Markdown 报告。7.2 性能数据分析 Agent 实现创建agents/perf_agent.py# 文件路径agents/perf_agent.py import json from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser class PerfAnalysisAgent: def __init__(self, model_namegpt-4o): self.llm ChatOpenAI(model_namemodel_name, temperature0.2) def generate_report(self, perf_data: dict, requirement: str) - str: prompt ChatPromptTemplate.from_messages([ (system, 你是一名资深性能测试工程师请根据性能测试数据输出一份专业的性能测试分析报告。 报告必须包含 1. 测试概况测试目标、测试环境、压力策略。 2. 测试结果汇总各接口的TPS、平均响应时间、P95响应时间、错误率。 3. 结果分析与性能需求阈值对比给出达标/未达标结论。 4. 瓶颈分析根据数据判断可能存在的性能瓶颈。 5. 优化建议给出具体可执行的优化方向。 6. 风险提示说明本次测试的局限性。 使用 Markdown 格式输出要求数据准确、结论明确。 ), (human, 性能测试需求{requirement}\n\n性能测试数据\n{perf_data}) ]) chain prompt | self.llm | StrOutputParser() return chain.invoke({ requirement: requirement, perf_data: json.dumps(perf_data, ensure_asciiFalse, indent2) })7.3 模拟性能数据演示准备一份模拟的性能测试汇总数据{ test_duration: 15min, concurrency: 100, apis: [ { api_name: POST /api/login, tps: 245, avg_rt: 356, p95_rt: 720, error_rate: 0.02, cpu_usage: 68, memory_usage: 72 }, { api_name: POST /api/order/create, tps: 120, avg_rt: 580, p95_rt: 1100, error_rate: 0.08, cpu_usage: 85, memory_usage: 80 }, { api_name: GET /api/order/list, tps: 320, avg_rt: 180, p95_rt: 350, error_rate: 0.01, cpu_usage: 45, memory_usage: 50 } ] }在main.py中追加调用代码from agents.perf_agent import PerfAnalysisAgent perf_agent PerfAnalysisAgent(model_namegpt-4o) report perf_agent.generate_report( perf_dataperf_data, requirement系统支持200并发用户接口平均响应时间小于500msP95小于1000ms错误率小于0.1% ) with open(output/reports/perf_report.md, w, encodingutf-8) as f: f.write(report) print(report)生成报告的核心价值在于Agent 不是简单复述数据而是把“平均响应时间达标但 P95 偏高”这类深层数据规律识别出来给出有价值的结论。例如它可能会得出“order/create 接口 P95 为 1100ms超出 1000ms 阈值错误率 0.08% 接近上限存在数据库连接池不足或慢 SQL 的嫌疑”这类分析这个输出已经接近一位中级性能测试工程师的分析水平。7.4 接入 JMeter 和 LoadRunner 测试结果在实际项目中性能测试数据通常来自 JMeter 的Summary Report或Aggregate Report导出 CSV以及 LoadRunner 的 Analysis 报告。处理思路是先用 Python 读取 CSV 文件并转换为 JSON 字典再传给 Agent。示例代码import pandas as pd # 读取 JMeter Aggregate Report 导出的 CSV df pd.read_csv(jmeter_aggregate_report.csv) perf_data { apis: [ { api_name: row[Label], samples: row[#Samples], avg_rt: row[Average], p95_rt: row[90% Line], # 根据实际列名调整 error_rate: row[Error %], tps: row[Throughput] } for _, row in df.iterrows() ] }需要注意的是不同版本的 JMeter 导出的列名略有差异比如“90% Line”、“95% Line”、“Throughput”等要以实际导出文件为准。LoadRunner 则通常需要先将 Analysis 结果导出为 Excel 或 CSV再走同样的流程。8. 如何让 Agent 更懂你的项目8.1 沉淀项目专属知识和规范测试用例生成 Agent 能不能真正落地很大程度上取决于它是否“了解你的项目”。通用大模型知道“如何写测试用例”但不知道你的项目叫“神策订单系统”也不知道贵司要求“所有用例必须包含前置环境标识、数据准备 SQL、断言级别”等规范。为了让 Agent 更懂项目建议构建一个项目知识库用 RAG检索增强生成的方式在运行时补充上下文。具体操作步骤收集项目文档需求文档、接口文档、测试计划、历史用例、线上事故复盘文档。将文档切片并向量化存入向量数据库。Agent 在生成用例之前先从知识库中检索与当前需求相关的资料片段。将检索到的片段插入 Prompt 上下文让 Agent 基于这些知识生成用例。在 LangChain 中可以通过RetrievalQA或create_retrieval_chain实现也可以将检索结果封装成一个自定义工具。这里不过度展开但需要明确一个思路RAG 不是“标准配置”而是项目复杂到一定程度后的必然选择。如果项目接口文档简单、业务规则清晰直接用工具调用就足够了。8.2 根据反馈持续迭代 PromptAgent 上线后建议建立一个“生成结果反馈闭环”测试人员在使用过程中对生成用例进行批注标记“无用”“重复”“缺少场景”。定期收集这些反馈分析 Agent 的错误类型。根据错误类型调整 Prompt或增加工具约束。将高频被修正的用例场景固化到 Prompt 中作为示例。例如如果 Agent 总是漏掉“金额为0”的边界用例就可以在 Prompt 中加入一条规则“涉及金额、数量等数值字段时必须包含0值、负值、极大值、极小值四类边界用例。”这种迭代方式比频繁更换模型更有效。8.3 用 LangGraph 编排复杂流程如果你的测试 Agent 要完成的任务链路越来越长例如“需求解析 → 用例生成 → 测试数据准备 → 脚本生成 → 冒烟执行 → 报告输出”六步串联且中间需要人工审批节点建议从 LangChain Agent 切换到 LangGraph。LangGraph 的优势在于可以精确控制每个节点的输入输出和跳转逻辑。支持条件分支例如用例评审不通过则返回修改。支持全局状态管理多个节点之间可以共享中间数据。可以配合 LangSmith 做链路追踪排查每一步的执行情况。从 LangChain 迁移到 LangGraph 的学习成本不算特别高核心是把原来的“Agent 一步到底”改成“节点 边的图结构”。对于初创团队或 POC 阶段先用 LangChain 把流程跑通后续再演进到 LangGraph 是性价比最高的方式。9. 常见问题与排查思路问题现象常见原因解决思路调用 OpenAI 接口超时网络不稳定或 Base URL 配置错误检查环境变量确认OPENAI_BASE_URL是否正确尝试更换网络后重试Agent 不调用工具直接输出结果工具描述不清晰或 Prompt 未强调必须调用工具在 System Prompt 中明确“涉及接口必须调用 get_api_schema”并给一个工具调用示例生成的 JSON 解析失败模型输出不完整或字段命名不匹配开启handle_parsing_errorsTrue同时在 Prompt 中给出 JSON 示例生成的用例重复度高Prompt 没有去重要求增加“删除语义重复用例”的规则并在输出前增加去重过滤步骤用例覆盖不到边界条件Prompt 缺少边界设计方法的约束在 Prompt 中列出必须覆盖的边界值场景类型性能报告结论和真实情况不符数据预处理不完整或关键指标缺失先检查输入数据是否包含错误率、TPS、P95 等必要指标模型回答字数过多超出上下文历史消息太长使用摘要记忆替代完整记忆或定期清空历史消息LangChain API 报错提示属性不存在版本差异导致 API 变更固定 LangChain 版本查阅对应版本文档Agent 生成脚本不能运行请求路径或断言与项目不符生成后增加一次格式检查与人工 review 流程10. AI 测试落地过程中的工程建议10.1 安全与权限边界在真实项目中接入 AI Agent安全是最重要的一条线。有几个原则需要提前定好涉及生产环境的任何操作都必须使用最小权限账号且提前申请审批。测试用例生成 Agent 只能读取内部测试环境的数据不能访问生产数据库。如果要让 Agent 操作测试管理平台必须通过 API Token 授权并限制 Token 的权限范围。大模型生成的所有测试脚本必须经过人工 Review 后才能执行。禁止将敏感业务数据直接发送到外部模型 API必要时采用私有化部署。10.2 数据与结果管理建议将 Agent 的输入输出全部记录到日志系统方便事后审计。每一步的记录至少包含调用的模型名称和版本。输入的 token 数量和消耗成本。生成的中间结果和最终输出。人工反馈信息和后续修改内容。通过这样的日志团队可以量化 AI 测试的投入产出比也能在出现问题时快速定位是模型问题、Prompt 问题还是数据问题。10.3 模型选型建议在测试用例生成这个场景里模型选择并不一定越贵越好。在实际对比中我们发现如果只是做初步用例头脑风暴轻量级模型足够。如果要生成高质量的多维度用例建议使用能力较强的旗舰模型。如果要做性能测试报告分析模型的分析能力比代码生成能力更重要。建议团队先拿 10 个典型需求做一次模型评测对比不同模型的用例覆盖度、准确率和格式合规率再决定正式环境用哪个模型。不要一上来就迷信“最大的模型”。10.4 成本控制Agent 应用的成本主要来自 token 消耗。工具返回的接口文档 JSON 很可能会在多轮推理中被反复发送给模型尤其是使用 ReAct 模式时模型每执行一步都会携带完整的对话历史。控制成本的几个手段精简工具返回内容只返回必要字段而不是整个接口文档。使用摘要记忆而不是完整保存所有历史消息。对简单任务使用温度参数为 0减少无效重试。对重复任务做结果缓存相同需求不重复调用模型。设定单次任务的 token 上限防止死循环。11. 学习路线与下一步规划如果你目前刚接触 LangChain Agent建议按下面的路线走一遍第一阶段入门 LangChain 基础 API理解 ChatModel、Prompt、OutputParser 这三个核心抽象尝试完成一个“调用模型生成一段文本”的最小示例。第二阶段掌握工具调用和 Agent 执行流程学会使用tool装饰器定义工具并理解 Agent 是如何根据任务描述决定调用哪个工具的。第三阶段开发一个垂直领域 Agent比如本文中的测试用例生成 Agent。不要追求功能复杂先把一条链路走通再逐步增加工具和约束。第四阶段引入 RAG 和记忆让 Agent 能结合项目知识库和历史对话给出更精准的输出。第五阶段学习 LangGraph理解状态机编排将单一 Agent 升级为多 Agent 协作系统。第六阶段工程化落地包括模型评测、成本监控、日志审计、人工审核闭环、私有化部署。在实际项目中我建议先选一个价值明确、流程标准化程度高、结果容易验证的测试场景切入比如“接口测试用例生成”不要一上来就要覆盖所有测试类型。先把单点做到可用再逐步扩展这是 AI 测试落地最稳的路径。最后提醒一句AI 测试的定位应该是“测试工程师的超级助手”而不是“替代测试工程师”。工具能帮我们节省重复劳动时间但测试策略的制定、关键业务的判断、上线风险的决策仍然需要人来把握。把 Agent 当成一个能随叫随到、知识面极广但不一定了解你项目的实习生来看待可能更贴近实际情况。你要做的是教会它你的规范、你的业务、你的坑然后让它帮你干那些确定性高的脏活累活。