前段时间团队里一个测试同学用 LangChain 搭完一版测试用例生成 Agent兴奋地丢给我一句话“好用爆了原来我每天写用例都是在重复同一套思考过程。”这话细想很有信息量——测试用例生成这件事真正难的不是让大模型写出像模像样的操作步骤而是把你心里那套“看到需求、拆业务规则、找边界、补异常、定优先级”的思考过程变成一条可执行、可校对、可批量跑的流程。下面不从“练完拿 40K”这个营销角度展开只聊工程上更值得关注的几个部分LangChain 在这里到底解决了哪一层问题最小可用 Agent 怎么搭从用例生成扩展到 UI 自动化脚本和性能测试分析报告时哪些套路能复用以及为什么单次跑通并不等于长期能用。1. 先搞清楚这个 Agent 真正解决的不是“省几分钟”先给一个核心判断用 LangChain 搭测试用例生成 Agent真正的价值不是把单条用例的生成时间缩短而是把“用例设计”从一个人脑里的隐性经验变成团队里可复制、可维护、可审计的显性流程。这个差异决定了你是在做一个玩具还是在做一个能长期放在工作流里的工具。1.1 单次 Prompt 和 Agent 执行链的差距用单个 Prompt 也能生成用例。你只需要写一句“请为以下需求生成测试用例”然后把需求文本粘贴进去。但实际用几轮就会发现单次 Prompt 有三个明显问题。第一需求一长模型容易漏掉负向场景。它会写“输入正确账号密码点击登录验证跳转首页”但未必会写“密码连续错误 5 次后账号锁定”。第二输出格式不稳定。有时候是 Markdown 列表有时候是表格有时候直接给你一段散文没法接进后续的用例管理和 CI 流程。第三它无法调用外部工具也没法在不同步骤之间保持任务状态。Agent 的思路是把任务拆成多步先理解需求再提取业务规则再列场景最后生成用例。每一步可以用不同的提示词甚至调用不同的工具结果再来一次结构化校验。这和让一个新人“先看需求、列边界、再写用例”的工作方式是一致的。所以不要把 Agent 理解成自动驾驶它更像一个高级副驾。你负责定目的地、认路、处理突发情况它负责把每个路口的动作记录成清单。1.2 测试用例生成为什么适合“先场景后用例”从工程经验看AI 生成的用例质量差很多时候不是模型笨而是跳过了场景直接生成用例。直接让模型“写用例”它倾向于先写 happy path边界和异常往往被挤到后面。而如果先让它“根据需求列出测试场景”再基于场景逐条生成用例覆盖度会明显提高。这个顺序也是有测试方法论支撑的场景是骨架用例是血肉骨架对了细节再修都容易。另一个实际收益是评审变简单了。测试负责人可以先审场景列表而不是逐条看 40 条用例。场景如果漏了边界马上能看出来场景如果覆盖合理再抽查几条用例细节即可。踩坑提醒不是所有“生成结果乱”都是模型问题。先确认需求文本里是否包含足够的业务规则。你喂进去的需求只有一句话别指望模型能生成出 20 条高质量边界用例。2. 从零搭一个最小可用测试用例生成 Agent很多人一上来就搜“Agent 框架”“LangGraph 状态图”其实没必要。测试用例生成这个场景第一版用一个两步链就能跑通先拆场景再生成用例。2.1 环境准备与依赖选择建议使用 Python 3.10 以上版本并且单独建虚拟环境。常见依赖包括langchain-core、langchain、langchain-openai以及pydantic用于结构化输出。如果你接的是 OpenAI 兼容接口langchain-openai的接入方式很直接如果你接的是团队内部的模型网关网关通常会提供兼容地址只需要把base_url指过去。这里有一个必须强调的点LangChain 迭代非常快同一段代码在不同版本里的写法可能完全不同。网上的旧代码不要直接复制落地前先确认你的版本组合然后跑一个最小示例。2.2 最小流程需求输入 → 场景拆解 → 用例生成 → 结构化输出一个最小可用的流程可以这么组织。# 示意结构具体类名和方法以你安装的版本为准 from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser scene_prompt ChatPromptTemplate.from_messages([ (system, 你是资深测试工程师。请从需求中提取业务规则列出需要覆盖的测试场景包括正向、边界、异常。), (human, 需求{requirement}), ]) case_prompt ChatPromptTemplate.from_messages([ (system, 请基于测试场景生成测试用例。每条用例包含标题、前置条件、操作步骤、预期结果、优先级。), (human, 场景{scenarios}), ]) scene_chain scene_prompt | llm | StrOutputParser() case_chain case_prompt | llm | StrOutputParser() scenarios scene_chain.invoke({requirement: 用户可以选择不同支付方式完成订单支付}) cases case_chain.invoke({scenarios: scenarios}) print(cases)为了让结果能被程序消费下一层应该引入结构化输出。常见做法是先定义一个用例的数据模型from typing import List from pydantic import BaseModel, Field class TestCase(BaseModel): title: str Field(description用例标题) preconditions: str Field(description前置条件) steps: List[str] Field(description操作步骤) expected: str Field(description预期结果) priority: str Field(description优先级)再配合 LangChain 里的结构化输出解析器把模型返回内容转换成 JSON 列表。这样做的好处是后续可以去重、做必填字段校验、导入用例管理平台而不是停留在“看起来能生成”的层面。如果你直接走 AgentExecutor 或create_agent的写法组件会绕一些但核心仍然不变给模型明确任务、给工具、给输出校验。第一版不需要追求完全自主先把两步链跑通。2.3 先别急着调参数但有两个参数要理解temperature 建议设置在 0 到 0.3。测试用例需要稳定、一致的输出低温能减少模型反复改写措辞但也不要一律设为 0否则边界探索能力会变弱。实际使用中可以在小样本上对比两到三个温度值的输出质量。另一个是输出长度限制。用例一多很容易截断尤其是要求一次生成十几条用例时。如果发现输出不完整先判断是 token 上限问题还是 prompt 里要求一次输出太多。我更建议减少单次输出数量而不是盲目调大 max_tokens。3. 把单条用例扩展到多场景和多格式两条链跑通之后下一步是把用例从“能生成”变成“覆盖度可用”。这里最有效的改动不是换模型而是拆提示模板。3.1 用不同提示模板覆盖功能、边界、异常、性能很多人让 Agent 一次生成所有用例结果功能用例一大堆边界和异常只占一小部分。这不是模型能力问题而是提示词里没有把测试方法论讲清楚。更好的做法是把任务拆成四类分别提示。功能正向正常操作路径、状态流转、关键业务规则。边界数值上下限、列表空与满、时间边界、分页边界、字符串最大长度。异常非法输入、权限不足、依赖服务不可用、超时、重复提交。性能并发量、响应时间、吞吐量、长时间稳定性。比如针对边界场景可以用这样的提示针对需求中所有数值输入、列表长度、时间范围等边界列出至少 3 个边界测试点并说明为什么它是边界。这个拆法的本质不是技巧而是把测试设计方法论写进 Prompt。模型本身不会天然知道什么时候该测边界你需要把方法论显式交给它。3.2 把需求文档、接口定义和缺陷记录接进来当需求比较复杂时可以把接口定义、历史缺陷记录作为上下文。文档内容不多直接放 Prompt 即可文档很大的时候才需要考虑 RAG也就是把文档切片、向量化再按需求检索相关内容。不要把 RAG 当成默认方案。它带来的检索服务、向量库、分片策略都会增加维护成本而且检索质量会直接影响生成质量。如果只是一个内部项目的用例生成直接读文件或者调用接口把相关字段塞进上下文可能更简单。当前周边也有很多把外部数据标准化接入 Agent 的协议方案本质是让 Agent 能统一调用外部工具。但如果只是内部流程直接用一个函数读取数据就够了不需要一开始就引入复杂组件。记忆也是一个容易被高估的需求。测试用例生成大多是单次任务不是多轮对话。只有当你要让 Agent 持续记住某个项目的命名规范、历史遗漏点、用户习惯时才需要显式设计记忆模块。否则每次任务都从需求文本开始反而更可控。3.3 批量生成最容易踩的三个坑第一输出截断和 JSON 解析失败。用例一多模型容易在结尾处截断导致 JSON 不完整。建议每次只生成 5 到 10 条用例再用脚本检查 JSON 完整性。第二重复用例过多。不同场景之间可能生成内容相近的用例需要加一层去重比如按“标题 前置条件 步骤”做归一化比较。第三边界场景逐步退化。批量任务跑久了会发现模型给出的边界越来越浅。这时候除了检查提示词还要定期用小样本回归对比新版本输出和基准输出。批量生成不是“一次性把需求全丢进去”。先小批量确认输入、输出、解析都正常再逐步扩大每批保留一次人工抽检这在当前阶段不可省略。4. 从用例生成走向 AI 测试常见场景实战用例生成只是入口。很多团队会继续往下延伸把 Agent 用于 UI 自动化脚本生成和性能测试分析报告输出。这两个场景都能复用前面搭好的架子。4.1 从用例到 Playwright 脚本别指望一次到位用例生成之后自然延伸是生成 UI 自动化脚本初稿。Agent 可以根据用例步骤生成一个 Playwright 脚本骨架。// Agent 生成的脚本骨架示意选择器和业务数据在回归时需要调整 test(支付流程-选择支付宝成功支付, async ({ page }) { await page.goto(/checkout); await page.getByLabel(支付方式).selectOption(alipay); await page.getByRole(button, { name: 提交订单 }).click(); await expect(page.getByText(支付成功)).toBeVisible(); });经验上这类脚本能省掉“从空白页面开始写流程”的时间但不能省掉“定位不稳定元素”的排查。Agent 看不到你的页面真实结构它生成的选择器很可能不可用。更合适的做法是让 Agent 生成初稿然后由人补齐可用的定位器和业务数据。不要把这种初稿直接跑在 CI 上。它的价值是让新用例的起点不再是空文件而是半成品。4.2 性能测试场景生成与分析报告输出性能测试是另一个很适合 Agent 的场景但它和用例生成有一个关键差异结果必须可计算、可验证。Agent 在性能测试里可以承担两块工作。第一块是生成压测场景配置比如根据业务预期生成并发数、ramp-up 时间、持续时长、监听器建议。第二块是解读压测结果把 JMeter 导出的 CSV 结果整理成可读的分析报告。第二块有一个非常重要的原则LLM 不擅长精确计算要让工具负责算模型负责解释。不要让模型直接“根据原始日志估算”指标它可能会把 p95 说成平均值。更稳的写法是先用 pandas 把指标算好。import pandas as pd df pd.read_csv(jmeter_result.csv) error_rate (df[success] false).mean() p95 df[elapsed].quantile(0.95) p99 df[elapsed].quantile(0.99)然后把这些已经算好的指标交给模型让它结合业务场景给出趋势判断和下一步排查建议。JMeter 本身就能生成 HTML 报告Agent 的真正价值在于解读异常指标、关联脚本片段、输出可执行的优化建议。LoadRunner 这类企业级测试工具流程类似只是报告格式和指标口径不同处理思路是一致的。4.3 一套可以复用的“输入-分解-生成-校验-输出”架子把用例生成、UI 脚本生成、性能报告输出放在一起看会发现它们共享同一个流程。场景输入分解生成校验输出用例生成需求文本业务规则、场景列表用例字段必填字段、去重Markdown、Excel、JSONUI 脚本用例步骤页面元素、动作序列Playwright 骨架语法检查、选择器确认代码文件性能报告JMeter CSV指标计算趋势解读、建议生成指标合理性Markdown 报告每接一个新的 AI 测试场景不用重新设计流程先把这五步填满再决定每一步用什么工具。如果流程分支很多、状态复杂LangChain 的链式写法会变得混乱这时候可以切到 LangGraph把流程定义成有向图节点状态清晰日志也好打。LangChain 和 LangGraph 不是互斥关系前者提供组件和工具后者负责编排复杂状态。5. Agent 不稳定先按这条链路排查Agent 接入真实项目后问题一定会出现。关键是建立一套稳定的排查顺序不要一遇到问题就怀疑模型。5.1 从“现象-输入-模型-提示-工具-解析-日志”逐层定位按这个顺序排查能快速缩小问题范围。先确认现象。是报错、空输出、格式错误还是内容质量差不同现象对应不同排查方向。再看输入。需求文本是否完整字段名是否统一文件路径是否正确有没有编码或多余空行问题。测试场景里最常见的是需求本身不够细。再看模型。上下文窗口够不够输出有没有被截断temperature 是不是太高导致结构不稳定。再看提示。system prompt 有没有把角色、目标、输出格式、示例讲清楚。不要只写“你是一个测试工程师”要写清楚“先列场景再写用例每条用例必须包含前置条件和预期结果”。再看工具。工具能否正常调用权限和 base_url 是否正确返回结果是否被截断。再看解析。JSON 里的中文转义、多余逗号、字段缺失都可能导致 Pydantic 校验失败。最后看日志。中间每一步都打印日志否则很难定位问题发生在哪一层。如果 Agent 不按预期顺序执行比如先调用工具再分析需求通常不是模型笨而是你给了它太大的自主权。测试用例生成属于确定性流程我更建议把步骤固定成链或状态图而不是用 ReAct 风格让模型自由决策。ReAct 适合探索型任务用例生成适合可控流程。5.2 从单次跑通到长期可用的工程化补全单次跑通只能说明链条没断离“能用”还差几块关键拼图。提示词要做版本管理。提示词的改动会直接影响输出质量建议把 Prompt 模板放进 Git 管理改坏了能回滚。日志和审计要落地记录每次生成的输入、模型、输出和耗时方便复现和复盘。人工审批闸口必须保留生成结果先经过测试负责人抽查再进入用例库。批量任务要处理限流、超时和局部失败加入重试机制。校验规则要脚本化检查必填字段、重复用例、非法步骤。数据安全也要提前想清楚敏感业务数据不要直接发到外部模型服务必要时用私有化部署或公司统一接入服务。很多团队做完 Demo 后没有落地不是因为模型不够强而是少了这些工程能力。Agent 生成只是其中一环真正花时间的是让它稳定地融入现有流程。6. 哪些人适合用哪些场景不要硬上最后聊一聊适用边界。任何工具都有边界测试用例生成 Agent 也一样。6.1 四类适合场景和三类慎用场景适合做的场景包括功能测试和接口测试的用例初稿生成UI 自动化脚本骨架生成性能测试前置场景设计和结果解读回归用例整理和覆盖度分析。慎用或者不要硬上的场景包括高合规要求的核心交易、医疗、金融系统输出结果必须逐条人工确认强依赖真实环境状态的集成测试Agent 看不到真实环境状态很难生成可靠步骤故障注入、安全攻防这类需要专业判断的测试也不属于这个 Agent 的边界。评估一个场景适不适合上 AI不是看“能不能生成”而是看“生成错了会造成什么后果”。后果越大越要保留人审环节。6.2 回到“练完拿 40K”这件事标题说练完不早拿 40K我不打算顺着这个说法往下写。更接近现实的情况是AI 测试会改变测试工程师的价值结构。只会手工写用例、不会判断用例质量的人工作机会会被压缩而能把需求拆成规则、能编排 AI 流程、能判断输出质量、能把结果接回 CI/CD 的人会更有竞争力。所以别把这篇当成速成指南。它真正想留给你的是一个起点先搭一个最小用例生成流程跑通后加一个场景加一个校验让它慢慢承担更多的重复劳动。省下来的时间应该花在更难的测试设计、风险评估和流程治理上。回到开头那个同事的感受。LangChain 搭测试用例生成 Agent体验最好的那一刻通常不是它第一次生成出完美用例而是你发现自己终于不用从空白文档开始写用例了。你只需要把需求讲清楚然后审它的草稿像审一个认真但偶尔粗心的新人。能走多快不取决于 Agent取决于你把流程设计得多清楚。
用LangChain搭建测试用例生成Agent：从单次Prompt到可复用流程
前段时间团队里一个测试同学用 LangChain 搭完一版测试用例生成 Agent兴奋地丢给我一句话“好用爆了原来我每天写用例都是在重复同一套思考过程。”这话细想很有信息量——测试用例生成这件事真正难的不是让大模型写出像模像样的操作步骤而是把你心里那套“看到需求、拆业务规则、找边界、补异常、定优先级”的思考过程变成一条可执行、可校对、可批量跑的流程。下面不从“练完拿 40K”这个营销角度展开只聊工程上更值得关注的几个部分LangChain 在这里到底解决了哪一层问题最小可用 Agent 怎么搭从用例生成扩展到 UI 自动化脚本和性能测试分析报告时哪些套路能复用以及为什么单次跑通并不等于长期能用。1. 先搞清楚这个 Agent 真正解决的不是“省几分钟”先给一个核心判断用 LangChain 搭测试用例生成 Agent真正的价值不是把单条用例的生成时间缩短而是把“用例设计”从一个人脑里的隐性经验变成团队里可复制、可维护、可审计的显性流程。这个差异决定了你是在做一个玩具还是在做一个能长期放在工作流里的工具。1.1 单次 Prompt 和 Agent 执行链的差距用单个 Prompt 也能生成用例。你只需要写一句“请为以下需求生成测试用例”然后把需求文本粘贴进去。但实际用几轮就会发现单次 Prompt 有三个明显问题。第一需求一长模型容易漏掉负向场景。它会写“输入正确账号密码点击登录验证跳转首页”但未必会写“密码连续错误 5 次后账号锁定”。第二输出格式不稳定。有时候是 Markdown 列表有时候是表格有时候直接给你一段散文没法接进后续的用例管理和 CI 流程。第三它无法调用外部工具也没法在不同步骤之间保持任务状态。Agent 的思路是把任务拆成多步先理解需求再提取业务规则再列场景最后生成用例。每一步可以用不同的提示词甚至调用不同的工具结果再来一次结构化校验。这和让一个新人“先看需求、列边界、再写用例”的工作方式是一致的。所以不要把 Agent 理解成自动驾驶它更像一个高级副驾。你负责定目的地、认路、处理突发情况它负责把每个路口的动作记录成清单。1.2 测试用例生成为什么适合“先场景后用例”从工程经验看AI 生成的用例质量差很多时候不是模型笨而是跳过了场景直接生成用例。直接让模型“写用例”它倾向于先写 happy path边界和异常往往被挤到后面。而如果先让它“根据需求列出测试场景”再基于场景逐条生成用例覆盖度会明显提高。这个顺序也是有测试方法论支撑的场景是骨架用例是血肉骨架对了细节再修都容易。另一个实际收益是评审变简单了。测试负责人可以先审场景列表而不是逐条看 40 条用例。场景如果漏了边界马上能看出来场景如果覆盖合理再抽查几条用例细节即可。踩坑提醒不是所有“生成结果乱”都是模型问题。先确认需求文本里是否包含足够的业务规则。你喂进去的需求只有一句话别指望模型能生成出 20 条高质量边界用例。2. 从零搭一个最小可用测试用例生成 Agent很多人一上来就搜“Agent 框架”“LangGraph 状态图”其实没必要。测试用例生成这个场景第一版用一个两步链就能跑通先拆场景再生成用例。2.1 环境准备与依赖选择建议使用 Python 3.10 以上版本并且单独建虚拟环境。常见依赖包括langchain-core、langchain、langchain-openai以及pydantic用于结构化输出。如果你接的是 OpenAI 兼容接口langchain-openai的接入方式很直接如果你接的是团队内部的模型网关网关通常会提供兼容地址只需要把base_url指过去。这里有一个必须强调的点LangChain 迭代非常快同一段代码在不同版本里的写法可能完全不同。网上的旧代码不要直接复制落地前先确认你的版本组合然后跑一个最小示例。2.2 最小流程需求输入 → 场景拆解 → 用例生成 → 结构化输出一个最小可用的流程可以这么组织。# 示意结构具体类名和方法以你安装的版本为准 from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser scene_prompt ChatPromptTemplate.from_messages([ (system, 你是资深测试工程师。请从需求中提取业务规则列出需要覆盖的测试场景包括正向、边界、异常。), (human, 需求{requirement}), ]) case_prompt ChatPromptTemplate.from_messages([ (system, 请基于测试场景生成测试用例。每条用例包含标题、前置条件、操作步骤、预期结果、优先级。), (human, 场景{scenarios}), ]) scene_chain scene_prompt | llm | StrOutputParser() case_chain case_prompt | llm | StrOutputParser() scenarios scene_chain.invoke({requirement: 用户可以选择不同支付方式完成订单支付}) cases case_chain.invoke({scenarios: scenarios}) print(cases)为了让结果能被程序消费下一层应该引入结构化输出。常见做法是先定义一个用例的数据模型from typing import List from pydantic import BaseModel, Field class TestCase(BaseModel): title: str Field(description用例标题) preconditions: str Field(description前置条件) steps: List[str] Field(description操作步骤) expected: str Field(description预期结果) priority: str Field(description优先级)再配合 LangChain 里的结构化输出解析器把模型返回内容转换成 JSON 列表。这样做的好处是后续可以去重、做必填字段校验、导入用例管理平台而不是停留在“看起来能生成”的层面。如果你直接走 AgentExecutor 或create_agent的写法组件会绕一些但核心仍然不变给模型明确任务、给工具、给输出校验。第一版不需要追求完全自主先把两步链跑通。2.3 先别急着调参数但有两个参数要理解temperature 建议设置在 0 到 0.3。测试用例需要稳定、一致的输出低温能减少模型反复改写措辞但也不要一律设为 0否则边界探索能力会变弱。实际使用中可以在小样本上对比两到三个温度值的输出质量。另一个是输出长度限制。用例一多很容易截断尤其是要求一次生成十几条用例时。如果发现输出不完整先判断是 token 上限问题还是 prompt 里要求一次输出太多。我更建议减少单次输出数量而不是盲目调大 max_tokens。3. 把单条用例扩展到多场景和多格式两条链跑通之后下一步是把用例从“能生成”变成“覆盖度可用”。这里最有效的改动不是换模型而是拆提示模板。3.1 用不同提示模板覆盖功能、边界、异常、性能很多人让 Agent 一次生成所有用例结果功能用例一大堆边界和异常只占一小部分。这不是模型能力问题而是提示词里没有把测试方法论讲清楚。更好的做法是把任务拆成四类分别提示。功能正向正常操作路径、状态流转、关键业务规则。边界数值上下限、列表空与满、时间边界、分页边界、字符串最大长度。异常非法输入、权限不足、依赖服务不可用、超时、重复提交。性能并发量、响应时间、吞吐量、长时间稳定性。比如针对边界场景可以用这样的提示针对需求中所有数值输入、列表长度、时间范围等边界列出至少 3 个边界测试点并说明为什么它是边界。这个拆法的本质不是技巧而是把测试设计方法论写进 Prompt。模型本身不会天然知道什么时候该测边界你需要把方法论显式交给它。3.2 把需求文档、接口定义和缺陷记录接进来当需求比较复杂时可以把接口定义、历史缺陷记录作为上下文。文档内容不多直接放 Prompt 即可文档很大的时候才需要考虑 RAG也就是把文档切片、向量化再按需求检索相关内容。不要把 RAG 当成默认方案。它带来的检索服务、向量库、分片策略都会增加维护成本而且检索质量会直接影响生成质量。如果只是一个内部项目的用例生成直接读文件或者调用接口把相关字段塞进上下文可能更简单。当前周边也有很多把外部数据标准化接入 Agent 的协议方案本质是让 Agent 能统一调用外部工具。但如果只是内部流程直接用一个函数读取数据就够了不需要一开始就引入复杂组件。记忆也是一个容易被高估的需求。测试用例生成大多是单次任务不是多轮对话。只有当你要让 Agent 持续记住某个项目的命名规范、历史遗漏点、用户习惯时才需要显式设计记忆模块。否则每次任务都从需求文本开始反而更可控。3.3 批量生成最容易踩的三个坑第一输出截断和 JSON 解析失败。用例一多模型容易在结尾处截断导致 JSON 不完整。建议每次只生成 5 到 10 条用例再用脚本检查 JSON 完整性。第二重复用例过多。不同场景之间可能生成内容相近的用例需要加一层去重比如按“标题 前置条件 步骤”做归一化比较。第三边界场景逐步退化。批量任务跑久了会发现模型给出的边界越来越浅。这时候除了检查提示词还要定期用小样本回归对比新版本输出和基准输出。批量生成不是“一次性把需求全丢进去”。先小批量确认输入、输出、解析都正常再逐步扩大每批保留一次人工抽检这在当前阶段不可省略。4. 从用例生成走向 AI 测试常见场景实战用例生成只是入口。很多团队会继续往下延伸把 Agent 用于 UI 自动化脚本生成和性能测试分析报告输出。这两个场景都能复用前面搭好的架子。4.1 从用例到 Playwright 脚本别指望一次到位用例生成之后自然延伸是生成 UI 自动化脚本初稿。Agent 可以根据用例步骤生成一个 Playwright 脚本骨架。// Agent 生成的脚本骨架示意选择器和业务数据在回归时需要调整 test(支付流程-选择支付宝成功支付, async ({ page }) { await page.goto(/checkout); await page.getByLabel(支付方式).selectOption(alipay); await page.getByRole(button, { name: 提交订单 }).click(); await expect(page.getByText(支付成功)).toBeVisible(); });经验上这类脚本能省掉“从空白页面开始写流程”的时间但不能省掉“定位不稳定元素”的排查。Agent 看不到你的页面真实结构它生成的选择器很可能不可用。更合适的做法是让 Agent 生成初稿然后由人补齐可用的定位器和业务数据。不要把这种初稿直接跑在 CI 上。它的价值是让新用例的起点不再是空文件而是半成品。4.2 性能测试场景生成与分析报告输出性能测试是另一个很适合 Agent 的场景但它和用例生成有一个关键差异结果必须可计算、可验证。Agent 在性能测试里可以承担两块工作。第一块是生成压测场景配置比如根据业务预期生成并发数、ramp-up 时间、持续时长、监听器建议。第二块是解读压测结果把 JMeter 导出的 CSV 结果整理成可读的分析报告。第二块有一个非常重要的原则LLM 不擅长精确计算要让工具负责算模型负责解释。不要让模型直接“根据原始日志估算”指标它可能会把 p95 说成平均值。更稳的写法是先用 pandas 把指标算好。import pandas as pd df pd.read_csv(jmeter_result.csv) error_rate (df[success] false).mean() p95 df[elapsed].quantile(0.95) p99 df[elapsed].quantile(0.99)然后把这些已经算好的指标交给模型让它结合业务场景给出趋势判断和下一步排查建议。JMeter 本身就能生成 HTML 报告Agent 的真正价值在于解读异常指标、关联脚本片段、输出可执行的优化建议。LoadRunner 这类企业级测试工具流程类似只是报告格式和指标口径不同处理思路是一致的。4.3 一套可以复用的“输入-分解-生成-校验-输出”架子把用例生成、UI 脚本生成、性能报告输出放在一起看会发现它们共享同一个流程。场景输入分解生成校验输出用例生成需求文本业务规则、场景列表用例字段必填字段、去重Markdown、Excel、JSONUI 脚本用例步骤页面元素、动作序列Playwright 骨架语法检查、选择器确认代码文件性能报告JMeter CSV指标计算趋势解读、建议生成指标合理性Markdown 报告每接一个新的 AI 测试场景不用重新设计流程先把这五步填满再决定每一步用什么工具。如果流程分支很多、状态复杂LangChain 的链式写法会变得混乱这时候可以切到 LangGraph把流程定义成有向图节点状态清晰日志也好打。LangChain 和 LangGraph 不是互斥关系前者提供组件和工具后者负责编排复杂状态。5. Agent 不稳定先按这条链路排查Agent 接入真实项目后问题一定会出现。关键是建立一套稳定的排查顺序不要一遇到问题就怀疑模型。5.1 从“现象-输入-模型-提示-工具-解析-日志”逐层定位按这个顺序排查能快速缩小问题范围。先确认现象。是报错、空输出、格式错误还是内容质量差不同现象对应不同排查方向。再看输入。需求文本是否完整字段名是否统一文件路径是否正确有没有编码或多余空行问题。测试场景里最常见的是需求本身不够细。再看模型。上下文窗口够不够输出有没有被截断temperature 是不是太高导致结构不稳定。再看提示。system prompt 有没有把角色、目标、输出格式、示例讲清楚。不要只写“你是一个测试工程师”要写清楚“先列场景再写用例每条用例必须包含前置条件和预期结果”。再看工具。工具能否正常调用权限和 base_url 是否正确返回结果是否被截断。再看解析。JSON 里的中文转义、多余逗号、字段缺失都可能导致 Pydantic 校验失败。最后看日志。中间每一步都打印日志否则很难定位问题发生在哪一层。如果 Agent 不按预期顺序执行比如先调用工具再分析需求通常不是模型笨而是你给了它太大的自主权。测试用例生成属于确定性流程我更建议把步骤固定成链或状态图而不是用 ReAct 风格让模型自由决策。ReAct 适合探索型任务用例生成适合可控流程。5.2 从单次跑通到长期可用的工程化补全单次跑通只能说明链条没断离“能用”还差几块关键拼图。提示词要做版本管理。提示词的改动会直接影响输出质量建议把 Prompt 模板放进 Git 管理改坏了能回滚。日志和审计要落地记录每次生成的输入、模型、输出和耗时方便复现和复盘。人工审批闸口必须保留生成结果先经过测试负责人抽查再进入用例库。批量任务要处理限流、超时和局部失败加入重试机制。校验规则要脚本化检查必填字段、重复用例、非法步骤。数据安全也要提前想清楚敏感业务数据不要直接发到外部模型服务必要时用私有化部署或公司统一接入服务。很多团队做完 Demo 后没有落地不是因为模型不够强而是少了这些工程能力。Agent 生成只是其中一环真正花时间的是让它稳定地融入现有流程。6. 哪些人适合用哪些场景不要硬上最后聊一聊适用边界。任何工具都有边界测试用例生成 Agent 也一样。6.1 四类适合场景和三类慎用场景适合做的场景包括功能测试和接口测试的用例初稿生成UI 自动化脚本骨架生成性能测试前置场景设计和结果解读回归用例整理和覆盖度分析。慎用或者不要硬上的场景包括高合规要求的核心交易、医疗、金融系统输出结果必须逐条人工确认强依赖真实环境状态的集成测试Agent 看不到真实环境状态很难生成可靠步骤故障注入、安全攻防这类需要专业判断的测试也不属于这个 Agent 的边界。评估一个场景适不适合上 AI不是看“能不能生成”而是看“生成错了会造成什么后果”。后果越大越要保留人审环节。6.2 回到“练完拿 40K”这件事标题说练完不早拿 40K我不打算顺着这个说法往下写。更接近现实的情况是AI 测试会改变测试工程师的价值结构。只会手工写用例、不会判断用例质量的人工作机会会被压缩而能把需求拆成规则、能编排 AI 流程、能判断输出质量、能把结果接回 CI/CD 的人会更有竞争力。所以别把这篇当成速成指南。它真正想留给你的是一个起点先搭一个最小用例生成流程跑通后加一个场景加一个校验让它慢慢承担更多的重复劳动。省下来的时间应该花在更难的测试设计、风险评估和流程治理上。回到开头那个同事的感受。LangChain 搭测试用例生成 Agent体验最好的那一刻通常不是它第一次生成出完美用例而是你发现自己终于不用从空白文档开始写用例了。你只需要把需求讲清楚然后审它的草稿像审一个认真但偶尔粗心的新人。能走多快不取决于 Agent取决于你把流程设计得多清楚。
