1. 从手工用例到智能体协作软件测试岗位正在经历什么这两年跟不少测试同行聊天大家普遍有一种被夹在中间的感觉。一方面业务迭代越来越快一个版本从需求评审到上线可能就两周留给测试的时间被压缩得厉害另一方面公司开始要求测试团队提效但提效的手段往往不是加人而是让你自己想办法。就在这个节骨眼上AI大模型和Agent开发这两个词开始频繁出现在测试团队的周会里。我自己是从传统功能测试一路做过来的写过几万行手工用例也搭过接口自动化框架后来慢慢接触到用大模型辅助测试。说实话一开始我是怀疑的——大模型写用例不就是把需求文档丢进去让它生成一堆看起来像那么回事、实际没法用的东西吗但真正深入用下来尤其是把Agent的思路引入之后我发现事情没那么简单。大模型不是替代测试工程师而是把测试工程师从重复劳动里解放出来去做那些真正需要判断力的事情。这篇内容我想聊的是AI大模型赋能软件测试与Agent开发这个方向具体会拆解大模型在测试场景里到底能干什么、Agent开发的核心思路是什么、一个测试工程师要往这个方向转型需要补哪些能力。适合两类人看一类是还在做传统功能测试、想搞清楚AI到底会不会取代自己的同行另一类是有一定开发基础、想往AI应用开发方向走的测试或开发人员。我不会只讲概念会把能落地的思路、踩过的坑、以及实际项目里的取舍都摊开来说。2. 大模型在软件测试链路里到底能插进哪些环节2.1 需求分析与测试点提取大模型最被低估的用法很多人一提到大模型做测试第一反应就是生成测试用例。但我的经验是直接让它生成用例质量往往不稳定因为用例的颗粒度、前置条件、预期结果这些细节模型很容易漏。真正好用的切入点是需求分析阶段的测试点提取。具体怎么做把需求文档、原型说明、甚至产品经理在群里的聊天记录整理成一段结构化的文本然后给模型一个明确的指令从这段需求里提取出所有可测试的功能点、边界条件、异常场景按模块分类输出。这个环节模型的表现相当不错因为它本质上是信息抽取分类而不是创造。我实测下来一个中等复杂度的需求文档人工提取测试点大概要两三个小时用模型辅助加上人工复核能压缩到四十分钟左右。关键在于提示词的设计。你不能只说帮我提取测试点而要告诉它这是一个电商下单流程重点关注库存扣减、优惠券叠加、支付超时这三个高风险区域输出格式按模块-测试点-风险等级来。提示模型提取的测试点一定要人工过一遍尤其是涉及金额计算、并发、状态流转的地方模型很容易想当然。它不知道你们系统里优惠券和积分能不能同时用这种业务规则必须你来补。2.2 用例生成与用例评审把模型当挑刺的同事测试点提取完之后下一步才是生成用例。这里的技巧是分步生成而不是一次性让模型输出完整用例。我的做法是先让模型针对每个测试点生成测试场景描述确认场景覆盖没问题之后再让它把场景展开成标准用例格式用例编号、前置条件、操作步骤、预期结果。这样做的好处是你可以在场景层面就把控覆盖度避免模型在细节里跑偏。而且场景描述比完整用例短你复核起来也快。用例评审环节大模型也能派上用场。把已有的用例集丢给模型让它从是否覆盖了异常场景是否存在冗余用例步骤是否可执行三个角度挑问题。它挑出来的问题不一定都对但经常能提醒你一些遗漏的角落。我印象很深的一次模型指出我们一批用例里完全没有考虑用户在下单过程中修改收货地址的场景这确实是人工评审时容易忽略的。2.3 缺陷分析与日志排查把非结构化信息变成线索测试工程师每天要花大量时间看日志、分析缺陷。大模型在这个环节的价值在于把非结构化的日志和报错信息翻译成人能快速理解的语言。比如一段几百行的服务端日志里面夹杂着堆栈信息、SQL语句、时间戳人工看要半天。把关键片段喂给模型让它总结这次请求在哪个环节失败、可能的原因是什么、建议优先排查哪几个点能省下大量时间。当然模型不懂你们系统的内部逻辑它的分析是基于通用经验的推测但作为排查的起点非常有用。还有一个用法是缺陷描述的规范化。很多开发提的缺陷单写得含糊测试转述时又容易丢信息。让模型把口语化的描述整理成复现步骤-实际结果-预期结果-环境信息的标准格式团队协作效率会明显提升。2.4 接口测试与自动化脚本模型写代码的边界在哪接口测试是测试工程师绕不开的活。大模型写接口测试脚本的能力这两年进步非常明显。给它一个接口文档Swagger或YApi导出的JSON让它生成基于Python requests或pytest的测试脚本基本能跑通。但这里有个关键的边界模型擅长写单接口的请求-断言这种模板化代码不擅长处理多接口串联的业务流程和复杂的测试数据构造。比如一个下单流程涉及商品查询、库存锁定、订单创建、支付回调四个接口接口之间有数据依赖模型生成的脚本往往在数据传递上出问题。我的做法是让模型生成单接口的测试函数业务流程的编排和测试数据的管理由我自己来写。这样既利用了模型的效率又保证了脚本的可靠性。另外模型生成的断言经常过于简单只判断状态码200实际业务里还要判断返回体里的关键字段这部分必须人工补。3. Agent开发让大模型从问答工具变成能干活的手3.1 Agent和普通大模型调用的本质区别很多人分不清用大模型和开发Agent的区别。简单说普通调用大模型是你问它答它没有记忆、没有工具、不能主动做事。而Agent是给大模型装上了手脚和记忆——它可以调用外部工具查数据库、发请求、读文件、可以记住上下文、可以根据任务目标自主决定下一步做什么。举个例子。你问大模型帮我查一下昨天订单表里支付失败的记录普通调用它只能告诉你你需要执行一条SQL大概是这样写的。而一个Agent可以自己生成SQL、连接数据库执行、拿到结果、分析失败原因、最后给你一份报告。这就是本质区别Agent具备行动能力。对于测试场景来说Agent的价值在于把测试流程里的多个环节串起来。比如一个回归测试Agent它可以自动拉取最新代码、部署测试环境、执行自动化用例、分析失败用例、生成测试报告。这里面每一步都是一个工具调用Agent负责编排。3.2 Agent的核心组件工具、记忆、规划要理解Agent开发得先搞清楚它的三个核心组件。工具Tool是Agent能调用的外部能力。在测试场景里工具可能包括执行SQL查询、调用接口、读写文件、执行shell命令、查询测试用例库等。每个工具都要有清晰的描述告诉模型这个工具是干什么的、需要什么参数、返回什么。工具描述写得好不好直接决定Agent能不能正确使用它。记忆Memory分短期和长期。短期记忆就是当前对话的上下文让Agent知道之前做了什么。长期记忆通常用向量数据库存储比如把历史缺陷记录、测试用例库存进去Agent需要时检索出来参考。规划Planning是Agent最核心也最难的部分。面对一个复杂任务Agent需要把它拆解成多个步骤决定先做什么后做什么遇到失败怎么调整。目前主流的做法有两种一种是ReAct模式让模型在思考-行动-观察的循环里逐步推进另一种是Plan-and-Execute模式先让模型制定完整计划再逐步执行。3.3 用Agent重构测试流程的一个真实思路我拿一个具体的场景来说智能缺陷分派Agent。传统流程是测试提缺陷单测试负责人看一遍根据模块和经验手动分派给对应的开发。这个流程的问题是人一忙就容易分错、分慢。用Agent改造的思路是这样的测试提交缺陷后Agent先读取缺陷描述调用历史缺陷检索工具在向量库里找相似的历史缺陷看它们当时分派给了谁、是怎么解决的。然后调用代码仓库工具查看最近提交记录判断哪个开发最近改动了相关模块。综合这些信息Agent给出分派建议测试负责人确认即可。这个Agent涉及三个工具向量检索、代码仓库查询、缺陷库写入。规划逻辑是先检索历史再查代码最后综合判断。实际跑下来分派准确率能到八成以上剩下的两成人工调整整体效率提升明显。注意Agent不是越自主越好。在测试这种对准确性要求高的场景里关键决策一定要留人工确认的环节。让Agent做建议人做决定这个边界要守住。3.4 Agent开发的学习路线别一上来就啃框架市面上Agent开发框架很多LangChain、LlamaIndex、AutoGPT等等。我的建议是先别急着上框架。框架封装了很多细节你如果不懂底层原理出了问题根本不知道怎么调。正确的路线是先用最朴素的方式手写一个Agent。就是用一个循环让模型输出下一步要调用什么工具、传什么参数你解析这个输出、执行工具、把结果塞回给模型如此往复。这个过程能让你彻底理解Agent是怎么运转的。手写一遍之后再去看框架你会发现框架帮你解决的就是那些你手写时觉得麻烦的事情。然后才是学习工具定义、记忆管理、多Agent协作这些进阶内容。至于具体的框架选型等你手写跑通一个Demo之后自然就有判断力了。4. 大模型本地部署测试团队该不该自己搭4.1 什么情况下需要考虑本地部署云端大模型API用起来方便但测试团队在几种情况下会考虑本地部署一是数据敏感测试数据涉及用户隐私或商业机密不能往外传二是调用量大API费用扛不住三是需要离线环境比如某些内网测试场景。本地部署的核心门槛是硬件。一个能跑起来的中等规模模型比如70亿参数级别至少需要一张显存16G以上的显卡。如果想跑更大的模型或者追求响应速度硬件成本会陡增。所以我的建议是先算清楚账。如果只是偶尔用用API的费用远低于买显卡的钱如果团队每天都要用、调用量很大本地部署才划算。4.2 本地部署的常见方案与取舍目前本地部署大模型主流的方案有几种。一种是直接用Ollama这类工具它把模型下载、量化、推理服务都封装好了几条命令就能跑起来适合快速验证。另一种是用vLLM这类推理框架性能更好、并发能力强但配置复杂一些适合有一定运维能力的团队。模型选择上开源模型里中文能力比较好的有几个系列参数量从几十亿到几百亿不等。参数量越大效果越好但对硬件要求也越高。测试团队如果只是做用例生成、日志分析这类任务70亿到140亿参数的模型基本够用。这里有个容易被忽略的点本地部署不是装完就完事了还要考虑模型的更新、多用户并发、服务稳定性。如果团队里只有你一个人懂这个哪天你休假了服务挂了没人修这就是隐患。所以本地部署要么不做要做就得有至少两个人能维护。4.3 本地部署和云端API的混合策略实际项目里我见过比较务实的做法是混合使用。敏感数据用本地模型处理通用任务用云端API。比如缺陷描述规范化、用例格式整理这种不涉及敏感信息的任务走云端涉及真实用户数据的日志分析走本地。这种策略的好处是兼顾了成本和合规坏处是要维护两套调用逻辑。我的经验是在代码层面做一个抽象层把用哪个模型做成配置项切换起来就方便了。5. 测试工程师转型AI方向能力补齐的优先级5.1 编程能力Python是绕不过去的想往AI大模型和Agent开发方向走Python基本是必须的。不是说要写到多高深的程度但至少得能熟练处理字符串、调用HTTP接口、读写JSON、用pandas处理数据。这些是跟大模型打交道的基础。如果你现在只会点点点我的建议是从写自动化测试脚本开始练手。用pytest写接口测试用requests发请求用jsonpath提取响应。这个过程既练了Python又跟测试本职工作相关一举两得。5.2 提示词工程不是玄学是手艺提示词写得好不好直接决定大模型输出的质量。但提示词工程不是什么神秘的玄学它是有方法论的。核心就几条指令要具体、给例子few-shot、分步骤、明确输出格式。我见过太多人写提示词就是一句话帮我写测试用例然后抱怨模型输出质量差。你换成你是一个有十年经验的测试工程师现在需要针对以下需求编写测试用例。要求1. 覆盖正常流程和至少三个异常场景2. 每个用例包含前置条件、操作步骤、预期结果3. 输出为Markdown表格。需求如下……效果完全不一样。提示词能力是练出来的。建议你建一个文档把每次效果好的提示词存下来慢慢就形成自己的模板库了。5.3 系统设计能力从写脚本到做系统测试工程师转型AI最容易卡在的一步是从写脚本到做系统。写个脚本调用大模型生成用例这个不难。但要做一个稳定的、多人能用的测试辅助系统就涉及架构设计了怎么管理提示词、怎么处理模型调用的失败重试、怎么存储和检索历史数据、怎么做权限控制。这部分能力没有捷径只能通过实际做项目来积累。我的建议是先从一个小工具做起比如一个用例生成助手一个人用。跑通之后再考虑加用户管理、加历史记录、加多模型切换。一步步来别一上来就想做个大平台。5.4 面试准备这个方向会问什么如果你是想找AI测试或Agent开发相关的岗位面试大概会问这几类问题一是大模型的基础概念比如什么是token、什么是上下文窗口、temperature参数的作用二是提示词设计的实际案例会让你现场设计一个提示词三是Agent的原理比如ReAct模式是怎么工作的、工具调用怎么实现四是项目经验你做过什么、遇到什么问题、怎么解决的。准备的时候别只背概念一定要有能讲清楚的项目。哪怕是你自己业余做的一个小Demo只要能说清楚设计思路和踩过的坑就比空谈概念强。6. 实操中那些没人告诉你的坑6.1 模型幻觉在测试场景里的具体表现大模型的幻觉Hallucination在测试场景里特别危险因为它会一本正经地胡说八道。我遇到过几次让模型根据接口文档生成测试脚本它凭空捏造了一个文档里根本不存在的字段还写得有模有样。如果测试人员不仔细核对直接拿去跑就会浪费大量时间排查一个不存在的问题。防范的办法是交叉验证。模型生成的任何涉及具体字段、接口路径、参数类型的内容都要跟原始文档核对。另外可以让模型在生成时标注哪些信息来自文档、哪些是推测这样你复核时就有重点。6.2 上下文长度限制带来的信息丢失大模型有上下文窗口限制超过长度的内容会被截断。在测试场景里这意味着如果你把一份很长的需求文档整个丢进去模型可能只看到了前面一部分后面的内容它根本没读到。解决办法是分块处理。把长文档按章节切分逐块处理最后汇总。或者用检索增强RAG的思路把文档存进向量库需要哪部分就检索哪部分。这个坑我在做需求分析时踩过模型漏掉了文档最后的风险提示章节导致测试点覆盖不全。6.3 成本控制别让API账单吓到你用云端API做测试如果不加控制费用很容易失控。尤其是做批量任务时比如一次性处理几百条用例token消耗量很大。控制成本的手段有几个一是用更小的模型处理简单任务复杂任务才用大模型二是优化提示词减少不必要的上下文三是做缓存相同或相似的请求直接返回缓存结果四是设置用量告警超过阈值就停下来检查。6.4 团队协作怎么让同事接受新工具技术再好团队不用也是白搭。推广AI测试工具时我的经验是先做小范围试点用效果说话。别一上来就要求全员使用先找一两个愿意尝试的同事一起用一段时间把效率提升的数据拿出来。有了真实数据再推广就顺理成章了。另外工具要做得傻瓜化。如果使用门槛太高同事宁愿手工做也不愿意用。把复杂的部分封装起来让使用者只需要填几个参数、点一下按钮接受度会高很多。7. 关于学习资料和进阶路径的一些个人建议市面上AI大模型和Agent开发的学习资料很多质量参差不齐。我的建议是以官方文档和论文为主视频课程为辅。官方文档更新最快、最准确论文能让你理解原理。视频课程适合入门但很多课程内容滞后讲的东西可能已经过时了。书籍方面大模型相关的书这两年出了不少但因为这个领域变化太快书的内容往往跟不上。我的做法是把书当地图看了解知识框架具体细节还是查文档和论文。至于学习路线我建议按这个顺序先补Python和基础的大模型调用会用API就行然后学提示词工程接着手写一个简单的Agent理解原理再学RAG和向量数据库最后才是多Agent协作和复杂系统设计。每一步都要有实际动手的项目光看不动手学完就忘。这个方向最大的特点是变化快今天好用的方法明天可能就被新的替代了。所以保持学习习惯比掌握某个具体技术更重要。我自己是每周固定花几个小时看新的论文和开源项目不一定都深入但至少知道这个领域在往哪个方向走。最后说一点体会AI大模型和Agent开发不是要取代测试工程师而是给测试工程师提供了一个能力跃迁的机会。那些愿意拥抱新工具、愿意动手实践的人会在这个变化里找到自己的位置。而那些固守手工测试、拒绝了解新技术的人压力会越来越大。这个判断不一定对但至少是我这几年在一线看到的趋势。