聊《测试转大模型一次新的项目切入》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。最近大厂都在讨论大模型应用从 Demo 走向生产环境的门槛焦点不再是“模型有多聪明”而是“权限控制、日志追踪和可观测性”。对于做测试出身的同学来说这其实是个好消息。我们比纯开发更懂边界更在意异常分支也更能接受“系统是不完美的”这一事实。但这并不意味着我们可以直接跳过基础去搞 Agent 框架。很多测试同事转型时容易陷入两个极端要么死磕 Prompt Engineering 的玄学要么盲目追逐最新的 LangChain/LangGraph 版本最后发现连最基本的 LLM 调用稳定性都没搞定。今天不谈虚的结合我最近帮团队重构 AI 质检系统的经历聊聊测试背景的同学如何一步步补齐能力栈以及哪些东西现在可以先放一放。目录测试岗位的新变化从“找 Bug”到“定义质量”AI 辅助测试别只把它当 Copilot自动化用例生成从“记录回放”到“意图驱动”Agent 测试框架LangGraph 还是自研质量评估RAGAS 和人工标注的结合总结先补什么暂时放什么测试岗位的新变化从“找 Bug”到“定义质量”传统测试关注功能正确性、性能指标和安全漏洞。但在大模型应用中质量定义变了。LLM 的输出具有概率性Non-deterministic同样的输入在不同时间、不同温度下可能产生不同结果。这时候传统的断言Assert失效了。你不能指望assertEquals(expected, actual)。我参与的一个项目初期直接用 JUnit 测试 LLM 生成的 SQL。结果很惨烈因为 LLM 偶尔会加注释或者改变字段顺序导致精确匹配失败。后来我们引入了“基于规则的模糊匹配”和“执行验证”——即不仅检查生成的 SQL 语法还要在沙箱里预执行看是否报错。启示 测试工程师的优势在于设计测试用例和评估维度。你需要学会从“功能测试”转向“效果测试”和“安全测试”。AI 辅助测试别只把它当 Copilot很多人以为用 GitHub Copilot 或 Cursor 写测试脚本就是 AI 测试。这只是效率提升不是能力跃迁。真正的 AI 辅助测试是利用 LLM 去生成测试数据、分析错误日志甚至自动构造对抗样本。比如在一个电商搜索项目中我们遇到大量长尾查询导致的召回率下降问题。手动构造测试用例太慢于是我们训练了一个小的分类模型对历史搜索日志进行聚类找出低质 query 分布。然后利用 LLM 针对每个簇生成变体同义词、错别字、口语化表达批量注入测试环境。import openai from datasets import load_dataset # 假设我们有一个低质查询列表 low_quality_queries [手机壳支架坏了怎么办, 苹果15promax多少钱] def generate_test_variants(query): 利用 LLM 生成同义变体覆盖更多边界情况 prompt f 你是一个测试专家。请为以下查询生成 5 个语义相同但表达方式不同的变体。 要求包含口语化、简写、错别字等常见噪声。 原始查询: {query} response openai.ChatCompletion.create( modelgpt-4o-mini, messages[{role: user, content: prompt}] ) return response.choices[0].message.content for q in low_quality_queries: variants generate_test_variants(q) print(fQuery: {q} - Variants:\n{variants})这段代码很简单但它体现了测试思维通过生成多样化的输入来探测系统的鲁棒性。自动化用例生成从“记录回放”到“意图驱动”传统自动化测试如 Selenium依赖 DOM 结构和固定流程。一旦 UI 变动脚本就挂。在大模型时代我们可以尝试用 LLM 理解用户意图自动生成测试步骤。但这中间有个巨大的坑幻觉。LLM 可能会编造不存在的按钮或 API。我的建议是人机协同验证。1. LLM 根据 PRD 生成初步的测试步骤伪代码或自然语言。2. 测试人员人工审核逻辑完整性。3. 使用工具调用Function Calling将自然语言转化为可执行的 API 请求或 UI 操作指令。4. 执行后由另一个轻量级模型或规则引擎检查结果是否符合预期。不要试图完全自动化端到端的大模型测试流程目前成本太高且不稳定。保留人工介入的关键节点才是工程化的务实做法。Agent 测试框架LangGraph 还是自研最近 LangGraph 很火它解决了传统 LangChain 循环引用的问题更适合构建有状态的 Agent。但是作为测试工程师我不建议你一开始就深入研究 LangGraph 的内部实现。你应该关注的是如何测试一个 AgentAgent 的核心能力是感知、规划、行动、记忆。测试重点应放在规划合理性Agent 分解任务的路径是否最优是否有死循环风险工具调用准确性是否正确调用了外部 API参数是否越界上下文管理在多轮对话中是否遗忘了关键信息或引入了噪声我推荐先用简单的 Python 脚本模拟 Agent 的行为流记录每一步的工具调用和状态变化而不是直接搭建复杂的编排框架。等你理解了 Agent 的运行轨迹再去考虑如何用 LangGraph 或 AutoGen 来构建测试骨架。质量评估RAGAS 和人工标注的结合大模型应用的评估Evaluation是转型的最大难点。没有 Gold Standard怎么测业界常用 RAGASRetrieval Augmented Generation Assessment框架它通过生成合成数据来评估检索质量和生成质量。实战建议1. 建立小规模黄金数据集哪怕只有 100 条也要保证每条都有标准答案和评分依据。这是所有自动化评估的基础。2. 多维度评估* Faithfulness回答是否忠实于检索到的上下文* Answer Relevance回答是否与问题相关* Context Precision检索到的上下文是否精准3. 不要迷信分数LLM-as-a-Judge 本身也有偏见。定期抽样人工复核校准模型评分的标准。总结先补什么暂时放什么从测试转到 AI 质量工程能力栈的优先级如下必须补Priority P0Prompt Engineering 基础理解 Token 限制、温度设置、Few-shot 技巧。Python 数据处理Pandas, JSON 处理因为测试数据通常是半结构化的。LLM API 交互熟练使用 OpenAI, Azure, 或国内主流模型的 SDK。评估方法论知道如何定义“好”的答案而不仅仅是“对”的答案。可以缓Priority P1模型微调Fine-tuning除非你有大量专有数据且业务场景极度垂直否则优先用 RAG Prompt。复杂 Agent 架构设计先跑通单步工具调用再考虑多步规划。底层向量数据库优化先用 Milvus 或 Pinecone 托管服务关注检索效果而非存储细节。永远不要丢Priority P0.5测试思维边界值分析、错误注入、混沌工程。这些在 AI 系统中同样适用甚至比在传统系统中更重要。转型不是抛弃过去而是用新的工具重塑旧的能力。当你不再纠结于“这个 bug 是谁的代码写的”而是思考“这个响应是如何产生的为什么会产生偏差”时你就已经迈出了最关键的一步。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
聊《测试转大模型一次新的项目切入》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。最近大厂都在讨论大模型应用从 Demo 走向生产环境的门槛焦点不再是“模型有多聪明”而是“权限控制、日志追踪和可观测性”。对于做测试出身的同学来说这其实是个好消息。我们比纯开发更懂边界更在意异常分支也更能接受“系统是不完美的”这一事实。但这并不意味着我们可以直接跳过基础去搞 Agent 框架。很多测试同事转型时容易陷入两个极端要么死磕 Prompt Engineering 的玄学要么盲目追逐最新的 LangChain/LangGraph 版本最后发现连最基本的 LLM 调用稳定性都没搞定。今天不谈虚的结合我最近帮团队重构 AI 质检系统的经历聊聊测试背景的同学如何一步步补齐能力栈以及哪些东西现在可以先放一放。目录测试岗位的新变化从“找 Bug”到“定义质量”AI 辅助测试别只把它当 Copilot自动化用例生成从“记录回放”到“意图驱动”Agent 测试框架LangGraph 还是自研质量评估RAGAS 和人工标注的结合总结先补什么暂时放什么测试岗位的新变化从“找 Bug”到“定义质量”传统测试关注功能正确性、性能指标和安全漏洞。但在大模型应用中质量定义变了。LLM 的输出具有概率性Non-deterministic同样的输入在不同时间、不同温度下可能产生不同结果。这时候传统的断言Assert失效了。你不能指望assertEquals(expected, actual)。我参与的一个项目初期直接用 JUnit 测试 LLM 生成的 SQL。结果很惨烈因为 LLM 偶尔会加注释或者改变字段顺序导致精确匹配失败。后来我们引入了“基于规则的模糊匹配”和“执行验证”——即不仅检查生成的 SQL 语法还要在沙箱里预执行看是否报错。启示 测试工程师的优势在于设计测试用例和评估维度。你需要学会从“功能测试”转向“效果测试”和“安全测试”。AI 辅助测试别只把它当 Copilot很多人以为用 GitHub Copilot 或 Cursor 写测试脚本就是 AI 测试。这只是效率提升不是能力跃迁。真正的 AI 辅助测试是利用 LLM 去生成测试数据、分析错误日志甚至自动构造对抗样本。比如在一个电商搜索项目中我们遇到大量长尾查询导致的召回率下降问题。手动构造测试用例太慢于是我们训练了一个小的分类模型对历史搜索日志进行聚类找出低质 query 分布。然后利用 LLM 针对每个簇生成变体同义词、错别字、口语化表达批量注入测试环境。import openai from datasets import load_dataset # 假设我们有一个低质查询列表 low_quality_queries [手机壳支架坏了怎么办, 苹果15promax多少钱] def generate_test_variants(query): 利用 LLM 生成同义变体覆盖更多边界情况 prompt f 你是一个测试专家。请为以下查询生成 5 个语义相同但表达方式不同的变体。 要求包含口语化、简写、错别字等常见噪声。 原始查询: {query} response openai.ChatCompletion.create( modelgpt-4o-mini, messages[{role: user, content: prompt}] ) return response.choices[0].message.content for q in low_quality_queries: variants generate_test_variants(q) print(fQuery: {q} - Variants:\n{variants})这段代码很简单但它体现了测试思维通过生成多样化的输入来探测系统的鲁棒性。自动化用例生成从“记录回放”到“意图驱动”传统自动化测试如 Selenium依赖 DOM 结构和固定流程。一旦 UI 变动脚本就挂。在大模型时代我们可以尝试用 LLM 理解用户意图自动生成测试步骤。但这中间有个巨大的坑幻觉。LLM 可能会编造不存在的按钮或 API。我的建议是人机协同验证。1. LLM 根据 PRD 生成初步的测试步骤伪代码或自然语言。2. 测试人员人工审核逻辑完整性。3. 使用工具调用Function Calling将自然语言转化为可执行的 API 请求或 UI 操作指令。4. 执行后由另一个轻量级模型或规则引擎检查结果是否符合预期。不要试图完全自动化端到端的大模型测试流程目前成本太高且不稳定。保留人工介入的关键节点才是工程化的务实做法。Agent 测试框架LangGraph 还是自研最近 LangGraph 很火它解决了传统 LangChain 循环引用的问题更适合构建有状态的 Agent。但是作为测试工程师我不建议你一开始就深入研究 LangGraph 的内部实现。你应该关注的是如何测试一个 AgentAgent 的核心能力是感知、规划、行动、记忆。测试重点应放在规划合理性Agent 分解任务的路径是否最优是否有死循环风险工具调用准确性是否正确调用了外部 API参数是否越界上下文管理在多轮对话中是否遗忘了关键信息或引入了噪声我推荐先用简单的 Python 脚本模拟 Agent 的行为流记录每一步的工具调用和状态变化而不是直接搭建复杂的编排框架。等你理解了 Agent 的运行轨迹再去考虑如何用 LangGraph 或 AutoGen 来构建测试骨架。质量评估RAGAS 和人工标注的结合大模型应用的评估Evaluation是转型的最大难点。没有 Gold Standard怎么测业界常用 RAGASRetrieval Augmented Generation Assessment框架它通过生成合成数据来评估检索质量和生成质量。实战建议1. 建立小规模黄金数据集哪怕只有 100 条也要保证每条都有标准答案和评分依据。这是所有自动化评估的基础。2. 多维度评估* Faithfulness回答是否忠实于检索到的上下文* Answer Relevance回答是否与问题相关* Context Precision检索到的上下文是否精准3. 不要迷信分数LLM-as-a-Judge 本身也有偏见。定期抽样人工复核校准模型评分的标准。总结先补什么暂时放什么从测试转到 AI 质量工程能力栈的优先级如下必须补Priority P0Prompt Engineering 基础理解 Token 限制、温度设置、Few-shot 技巧。Python 数据处理Pandas, JSON 处理因为测试数据通常是半结构化的。LLM API 交互熟练使用 OpenAI, Azure, 或国内主流模型的 SDK。评估方法论知道如何定义“好”的答案而不仅仅是“对”的答案。可以缓Priority P1模型微调Fine-tuning除非你有大量专有数据且业务场景极度垂直否则优先用 RAG Prompt。复杂 Agent 架构设计先跑通单步工具调用再考虑多步规划。底层向量数据库优化先用 Milvus 或 Pinecone 托管服务关注检索效果而非存储细节。永远不要丢Priority P0.5测试思维边界值分析、错误注入、混沌工程。这些在 AI 系统中同样适用甚至比在传统系统中更重要。转型不是抛弃过去而是用新的工具重塑旧的能力。当你不再纠结于“这个 bug 是谁的代码写的”而是思考“这个响应是如何产生的为什么会产生偏差”时你就已经迈出了最关键的一步。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
