★ FEATURED ARTICLE 1. 先盘一盘AI到底能在软件测试里干什么这几年只要聊到软件测试三句话离不开AI。团队里有人焦虑“AI会不会把测试岗位干掉”也有人天天拿AI写用例、刷接口效率确实翻倍。我自己的判断是AI目前还替代不了测试工程师但它能把测试里大量重复、机械、低价值的环节吃掉让你把精力腾出来干真正需要判断力的事。先厘清一个概念这里说的AI主要指大语言模型LLM和基于它构建的各类工具比如ChatGPT、Claude、国产的智谱、通义、DeepSeek以及各种集成了AI能力的测试平台和IDE插件。它们能读文本、写代码、整理数据、做推理但不懂业务、没有审美、也不会判断“这个bug用户能不能忍”。所以AI在测试里的准确定位是一个记忆力极强、输出极快、永远不嫌烦的助手而不是能做最终决策的测试负责人。那AI具体能干什么我用一张场景对照表给你说清楚测试环节传统方式AI介入后需求分析人工阅读PRD梳理测试点AI快速提取需求条目、生成测试点清单用例设计手工编写用例依赖个人经验AI根据需求生成覆盖度更高的用例草稿接口测试手写脚本、人工造数据AI生成脚本、自动Mock数据UI自动化录制脚本、手写定位符AI辅助生成定位器、推荐稳定的选择策略缺陷分析人工看日志、翻代码定位AI总结日志、聚类重复bug、推荐可疑代码段测试报告手工汇总数据、写结论AI生成结构化报告标注风险点回归测试人工筛选用例集AI基于变更代码推荐最小回归集这张表不是空想下面每一行我都会展开讲原理、讲实操、讲踩坑。你先记住一句话AI切入测试的最佳姿势是“人定规则AI跑量”而不是把整个测试流程交给AI。1.1 从测试工作流看AI的切入位置测试流程通常分这么几步需求评审、测试计划、用例设计、环境准备、测试执行、缺陷跟踪、回归验证、测试报告。AI在每一步都有活干但干的活类型完全不同。需求和计划阶段AI能做的是“信息压缩”。一份50页的PRD扔给AI它能几分钟内提取出功能列表、边界条件、异常场景还能顺带识别需求里自相矛盾的地方。我试过把一份特别啰嗦的需求文档丢给大模型让它列出所有涉及权限控制的场景它给的清单比我一个实习生花半天整理出来的还全。但前提是你要会问问得越具体输出越有用。用例设计阶段AI的价值是“覆盖面”。人的经验再丰富也容易漏掉一些边界值和异常分支。AI不一样它看过海量公开的测试案例和Bug模式能用组合覆盖的思路给你生成用例草稿。实际用下来AI生成的用例不可能直接拿来用但它的草稿能帮你打开思路特别是针对“输入组合爆炸”的场景它的补充价值非常明显。执行和缺陷阶段AI的作用是“省时间”。日志分析、调用链梳理、错误堆栈解读这些事特别耗时间又特别机械AI做起来又快又准。之前排查一个线上问题我手动翻日志翻了半小时后来直接把堆栈粘给AI它一眼就指出了空指针的触发条件还给了修复建议。这种效率提升不用AI的人是体会不到的。1.2 按测试类型拆解AI的具体应用场景按测试类型拆会更清楚。功能测试里AI能辅助生成测试数据和用例但它不懂业务规则所以核心的“预期结果”还得人定。接口测试是AI最擅长的领域因为接口描述Swagger、OpenAPI是结构化的AI读这些文档的能力极强能直接生成参数校验、边界值、异常流的测试脚本。性能测试这块AI能做的是分析压测结果。压测完了会输出一堆指标吞吐量、响应时间、错误率、资源占用率AI能帮你解读这些数据之间的关联定位瓶颈可能出现在哪个环节。但它不能替你调优因为调优需要理解代码和架构。安全测试比较特殊。AI能做基础的漏洞模式识别比如从代码里扫出SQL注入、硬编码密钥这类问题但真正的渗透测试需要攻击思维目前AI还差得远。我的建议是安全测试里AI只能当做辅助扫描器别指望它发现复杂的业务逻辑漏洞。App测试、兼容性测试这些AI的用武之地更多体现在“真机模拟测试软件测试不同手机机型免费”这类需求上。现在有不少工具结合云端真机加上AI脚本生成可以自动在不同分辨率、不同系统版本下执行冒烟用例把原来需要半天的人工回归压缩到半小时。这块对项目组来说是真香。2. 拿来即用AI辅助测试的五个实操套路说再多场景不如看实操。这一章我挑五个我实际用过的、效果明显的AI辅助测试套路每个都给出步骤、提示词模板和注意事项。你照着抄就行抄完就能用。2.1 用AI生成测试用例提示词该怎么写AI生成用例这件事网上讨论很多但大部分人用不好问题不在AI在提问方式。你问“帮我写几个测试用例”它给你的当然是泛泛而谈的东西。你得把需求、约束、特殊要求、预期结果格式全部告诉它。我自己常用的提示词结构是这样拆的你是一名资深测试工程师。请根据以下需求生成测试用例。 需求用户登录功能支持手机号验证码登录验证码有效期5分钟每天最多发送10次验证码。 要求 1. 覆盖正常流程、异常流程、边界值、权限相关场景 2. 输出格式为表格包含用例编号、用例标题、前置条件、测试步骤、预期结果、优先级 3. 对每个用例标注对应的需求编号需求文档中若未编号则跳过 4. 特别关注验证码有效期边界和发送次数限制这样问出来AI输出的用例质量会高一个档次。关键是要把“约束条件”说清楚比如验证码有效期5分钟那么“第4分59秒输入验证码”和“第5分01秒输入验证码”这两个边界用例AI才能生成出来。经验之谈AI生成的用例草稿至少要覆盖你手工用例的70%以上才算合格。如果覆盖率太低多半是你需求描述得太笼统。另外AI容易忽略“用户习惯”类的场景比如密码输入错误后提示语的准确性这类软性需求你需要在提示词里点名它才会关注到。2.2 用AI写接口测试脚本从零到能跑的完整案例接口测试是AI辅助测试里落地最顺畅的环节。因为接口的信息都是结构化的接口文档、参数定义、返回字段都清清楚楚AI理解起来几乎没障碍。举一个实际例子。后端给了这样一个登录接口的OpenAPI描述/user/login: post: summary: 用户登录 parameters: - name: phone in: query required: true type: string description: 手机号 - name: code in: query required: true type: string description: 短信验证码 responses: 200: description: 登录成功 400: description: 参数错误 401: description: 验证码错误或过期我把这段描述直接丢给AI提示词是“使用Pythonrequests库编写该接口的自动化测试脚本覆盖正常登录、验证码错误、验证码过期、参数缺失四种用例输出可直接执行的pytest代码”。AI生成的脚本基本可以直接用我只需要微调一下接口地址和测试数据。注意AI生成的接口脚本断言部分要重点审查。AI经常会把“响应码200”当成唯一的断言标准而忽略业务字段的校验。比如登录成功之后你还要校验返回的token格式、用户信息字段是否完整。这一块我都是手动补。补全断言之后测试脚本的质量就靠谱了。现在很多团队用Spring AI、Pycharm AI插件这类工具把接口测试脚本生成直接集成到开发环境里开发和测试用一套提示词模板协作效率提升非常快。2.3 用AI做缺陷分析与重复Bug聚类缺陷分析是AI的又一大强项。Bug描述、错误日志、堆栈信息这些非结构化的文本恰好是大模型最擅长的处理对象。以前我们收到一个线上Bug先要看日志、翻代码、问开发、再判断影响范围一折腾就是半天。现在流程变成了“Bug描述 相关日志 → AI总结 定位建议 → 人工确认”。AI的聚类能力更实用。一个版本提测之后测试群里经常收到一堆“看起来不一样但根因相同”的Bug人工去重特别费劲。我试过把一个阶段收集到的200条Bug描述全部丢给AI让它按“疑似根因”进行聚类它把重复上报、根因相同的Bug归成了一组还标出了每组出现的频次。这个结果对测试报告和开发排期都有直接价值。实操中有一个很实用的提示词模板分享给大家以下是我的项目在最近一次迭代中收集到的Bug描述请帮我 1. 按疑似根因进行聚类分组 2. 每组标注可能涉及的功能模块 3. 标记出可能是同一根因的重复Bug 4. 输出格式每组一个表格包含Bug标题、原始描述、聚类原因 Bug列表 粘贴Bug清单用这个模板处理完的Bug列表再贴到禅道或者Jira里做二次确认效率至少能提升一半。不过要注意AI的聚类是基于文本相似度推断的它不能替代真正的代码定位。碰到聚类结果有争议的还是要让开发介入确认。2.4 用AI补齐测试数据造数效率翻倍的思路每个做测试的人都有被测试数据逼疯的经历。真的要造一批符合各种边界条件的用户数据、订单数据、优惠券数据手写SQL能写到手软而且数据之间的关联关系很容易漏。AI在造数这块能帮大忙但方式不是“点按钮自动生成”而是辅助你写造数脚本。我常用的做法是把表结构和数据要求丢给AI让它生成SQL或Python脚本。比如要造100张订单覆盖“已支付、未支付、已退款、退款中、部分退款”5种状态而且每种状态下的时间字段要符合逻辑关系AI生成的脚本比我手写的还严谨。还有一类造数需求更隐蔽——线上数据脱敏。测试环境需要线上真实数据的结构但数据内容要脱敏。以前我们写脱敏脚本要自己梳理规则现在直接把数据字典丢给AI让它自动标注敏感字段并生成脱敏映射规则速度非常快。提示千万别把真实线上数据直接丢给公网AI工具这是数据安全红线。内部搭建的大模型或者本地部署的模型是更稳妥的选择。文章后面我会专门讲大模型本地部署在测试团队里的用法。2.5 用AI优化测试报告汇总速度快到离谱测试报告看着简单写起来烦。一堆测试数据、Bug统计数据、用例执行情况、风险评估还要整理成管理层爱看的汇报格式每次都得花一两个小时。AI的套路是这样你把原始数据和报告模板给它它按你的模板框架把内容填充好你再微调措辞就行了。AI生成测试报告的提示词同样有讲究下面是我这轮的测试执行数据请帮我生成一份测试报告。 需要包含测试范围、执行情况、Bug统计与分析、风险评估、结论建议。 执行数据 粘贴各种统计结果和原始数据 注意 1. 结论部分要有明确的测试通过/不通过建议 2. 风险要按高、中、低分级 3. 语言简洁不要废话AI生成的报告初稿通常能帮你省掉80%的整理时间。剩下的20%是你对业务的理解和对风险的把控这部分AI替代不了。特别是“这个Bug不上线行不行”的判断只能靠人。3. 工具链集成AI原生测试平台的现状与本地部署经验聊完单个场景再说说工具层面。目前AI和测试工具的结合有三种形态理解它们能帮你少走弯路。3.1 三种AI测试工具形态对比形态代表工具优势劣势IDE插件Pycharm AI插件、Copilot上手快开发/测试同用一套工具只能辅助编码不能管理测试流程独立测试平台Testim、Mabl、RobotFrameworkAI插件支持端到端流程可维护性强需要团队统一引入学习成本高大模型API接入Spring AI、LangChain灵活度高可深度定制需要开发能力维护成本不低个人建议团队刚起步的时候先从IDE插件和API调用入手别上来就买商业平台。先用AI解决单点效率问题跑通之后再考虑平台化。我们团队就是先在接口测试环节用AI插件效果好了才逐步扩展到用例设计、缺陷分析。3.2 本地部署大模型做测试辅助一次靠谱的尝试测试团队用得勤了之后很快会碰到数据安全的问题。测试用例、Bug描述、日志这些数据很多都涉及业务敏感信息不能直接发到公网模型上。解决办法不外乎两个一是买企业版API签数据协议二是本地部署开源大模型。本地部署这件事我用的是Ollama加Qwen系列模型。配置要求不算离谱一台32G内存的机器就能跑7B~14B参数的模型日常的用例生成、文本总结、脚本辅助这些任务完全够用。如果你想跑更强的模型就得考虑显卡了至少24G显存才能流畅跑70B级别的模型。部署步骤不复杂但有几个坑要提醒你模型下载要选对量化版本Q4_K_M是比较均衡的选择不然显存不够会非常卡。本地模型的“聪明程度”确实不如公网顶级模型尤其是复杂推理和代码生成场景表现差距明显。本地部署的价值在于“安全可控”不在于“能力最强”。如果你对效果要求很高混合方案更合理——敏感数据走本地非敏感数据走云端。我给测试团队推荐的组合是本地部署一个14B级别的模型专门处理包含业务敏感信息的任务公网模型处理公开的、不敏感的技术性问题。既满足安全要求又保证效果。3.3 AI编程提示词在测试脚本开发中的最佳实践AI辅助写测试脚本核心在于提示词的质量。很多人觉得提示词就是“帮我写个脚本”其实远没这么简单。我总结了一套适合测试场景的提示词公式角色设定 任务目标 输入数据 约束条件 输出格式 自检要求举个例子让AI写一个登录功能的安全测试脚本你是资深安全测试工程师。 任务编写一个登录接口的安全测试脚本使用Python和requests库。 输入接口地址 http://api.demo.com/login参数为username和password。 要求 1. 测试SQL注入、暴力破解、错误请求体三种场景 2. 每个场景单独一个测试函数使用pytest框架 3. 对每个用例添加断言语义说明 4. 生成后逐行检查确保没有调用不存在的库和函数这套公式看起来简单但每一段都有讲究。“角色设定”决定AI输出的专业深度“约束条件”控制代码风格“自检要求”让AI自己先过一遍代码减少低级错误。还要明确一个认知AI生成的脚本代码质量大概率比你团队里的初级成员手写的好但和资深测试开发写的还有差距。差距主要体现在对项目结构的理解、对框架约定的遵循、对异常场景的覆盖。所以我的原则是AI生成的脚本一定要经过人工审查尤其是断言和异常处理这两个位置。4. AI不是银弹这些坑我替你踩过了写到这里已经列了不少AI的好处但要客观地说AI在测试领域有它明显的局限和坑。这几条是我实际踩过的每一条都付出了时间成本。4.1 生成式AI在测试里的三大不靠谱第一大不靠谱AI会一本正经地胡说八道。你让它写一个断言它可能编造一个接口文档里根本不存在的返回字段。人如果看到不认识的字段会去确认AI不会它靠的是概率生成。所以AI生成的断言和预期结果必须逐条对照实际接口文档这一步不能省。第二大不靠谱AI对“业务正确性”没有感知。它能判断“这个参数格式对不对”但判断不了“这个业务逻辑对不对”。比如一个实名认证功能接口返回“认证成功”不代表业务成功可能还要校验身份证校验位的算法正确性。这种业务规则AI完全无感必须人来定义。第三大不靠谱AI对版本变化极其敏感。模型更新、接口调整、数据变化都可能导致AI的输出质量和之前不一致。你今天用得好好的提示词明天因为模型升级效果就可能变差。这要求你在团队里建立提示词版本管理机制别“昨天还能用今天不知道哪里出了问题”。4.2 UI自动化里的AI看起来美用起来要小心UI自动化是AI炒得最热的测试场景但我必须泼冷水AI驱动的UI自动化远没有吹得那么成熟。目前市面上的AI UI测试工具基本上是在传统脚本框架上加了“智能定位”和“自动修复”能力离“全自动智能测试”还有很大距离。实际使用中AI在UI自动化上帮我解决的具体问题是元素定位器的自动修复。以前脚本跑在版本迭代之后元素定位经常失效最常见的XPath变了脚本只能人工修。集成AI后工具能根据页面变化自动推断新的定位器这个能力非常实用节省的维护时间肉眼可见。但AI代替不了UI测试里更重要的两件事视觉验证和业务流程验证。一个弹窗样式错位的问题AI很难判断一个“下单成功后优惠券没有到账”的问题AI可能跑完了都不觉得有异常。UI自动化的最终把关人一定是人AI只是帮你降低了维护成本。4.3 哪些测试环节暂时不要指望AI诚实地说有几个测试环节AI目前帮不上大忙甚至可能帮倒忙。探索性测试别指望AI。探索性测试的核心是测试人员基于自身经验和对业务的理解去探索系统未被验证的角落。AI没有“灵光一现”的能力它只能在已知的框架内生成内容探索性测试这种高度依赖直觉和经验的活AI做不来。性能调优分析别指望AI。压测数据给AI它能帮你读报表、做归因但真正的瓶颈定位要求你深入理解代码、架构、数据库、中间件。这些环节需要多年的工程经验AI目前只是在“表面解读”而已。安全渗透测试别指望AI。安全测试本质上是一场攻防对抗攻击路径的设计、绕过手法的构造、漏洞利用的深度分析都需要攻击性思维。AI生成的“安全用例”基本停留在教科书层面面对真实系统还是得靠人。简单说凡是需要“业务理解”和“创造力”的测试环节AI都还不行凡是“基于已有知识做重复执行”的环节AI都干得不错。你用AI之前先按照这个标准判断一下场景是否合适能省很多事。5. 下一步AI Agent会给软件测试带来什么变化热搜词里“AI Agent”热度很高我也说说对测试行业的影响。如果说现在的AI是“你问我答”的工具那Agent就是“你交代任务我自己想办法完成”的智能体。这个变化对测试的影响可能比单纯用AI写脚本要深远得多。5.1 从“问答助手”到“执行助手”的关键一跳现在的AI辅助测试本质上是“人在回路”你提问AI回答你拿去用。Agent就不一样了它能自己规划任务、调工具、跑测试、分析结果人只在关键节点做决策。举个例子。未来的测试Agent可能是这样的你给它一个需求文档它自己拆解测试点、生成测试计划、编写测试脚本、在测试环境执行、汇总结果、生成报告。你只需要最后审核一遍。如果这套流程跑通了测试团队的角色分工一定会变——基础的用例设计、脚本编写、报告整理这些岗位会被极大削弱。但有一个关键路径问题Agent的可靠性。它自主执行时长越长出错的概率越大。测试行业的特点是对质量要求极高“九成准确”不能接受。所以我的判断是Agent在测试行业的落地会比其他行业慢会优先在低风险、高重复的环节如冒烟测试、回归测试跑起来高风险环节仍然保持“人工主导”。5.2 测试工程师怎么面对AI带来的变化这个问题很多人问我给出自己的真实看法AI不会淘汰测试工程师但会用AI的测试工程师会淘汰不会用AI的。这不是贩卖焦虑而是历史规律。当年自动化测试兴起的时候有人说“手工测试要被淘汰了”结果手工测试还存在只是价值重心转移到了探索性测试。AI这次也一样它改变的是测试工作的结构不是测试工作的存在价值。应对方式我有三个建议第一把AI当成“自己的首席助理”。每天的工作里找一个你做得最烦、最重复、最机械的任务想办法用AI解决。解决了就是效率提升同时你就学会了AI的使用边界。第二提示词能力是新的基础技能。不用学编程但要学会描述清楚任务。能把需求说明白的人用AI的效果就是比别人好。这个技能通过刻意练习很快就能掌握。第三把精力放到AI做不了的事情上。业务理解能力、系统架构认知、用户思维、风险判断力这些才是你真正的护城河。AI能帮你更快地完成“执行”但“做什么、为什么做、做到什么程度”这些决策永远需要人来判断。5.3 测试团队落地AI的好用路线图最后给想带团队落地AI的伙伴一个建议路线。建议分三步走。第一步选场景试点。挑一个足够痛、边界足够清晰、效果容易量化的场景比如接口测试脚本生成。定义好“AI介入前”和“AI介入后”的效率指标跑两周用数据说话。第二步建团队规范。制定AI工具使用规范、提示词模板库、数据安全红线、输出审核机制。这一步特别重要不规范的使用方式比不用AI风险更大。第三步逐步扩大范围。从单点场景到跨场景流程从辅助执行到辅助决策。每一步都做好效果评估和风险控制。稳妥推进比激进革新在测试行业更靠谱。我个人在实际操作中的体会是AI落地测试最大的阻力不在技术而在团队习惯。很多测试人员习惯了旧的做事方式不愿意改变。这时候别硬推找一个愿意尝鲜的人做出样板案例用实际效果说话比讲一百遍道理都管用。毕竟在测试这个行业价值是靠结果证明的。
阅读完成 · 觉得有帮助？
