昨天和一位在鹅厂做测试开发的老同学聊了将近两个小时。本来只是例行电话结果从团队最近的项目聊到AI工具话题就彻底收不住了。他现在所在的团队已经不是在“尝鲜”AI而是真正把AI用在了日常测试流程里还沉淀出了一套内部的使用思路。聊完回到家我又把几个关键点记成了笔记今天整理出来分享给所有正在琢磨“测试人员该怎么正确用AI”的同行。这篇文章不打算追热点也不做工具列表式的介绍重点讲清楚三件事测试人员用AI最容易在什么地方翻车AI在测试工作中的正确定位是什么以及哪些场景现在就能落地、具体该怎么操作。不管你是偏手工的测试工程师还是做自动化、做测开的这些思路应该都用得上。1. 聊下来最反直觉的一点AI让不少测试人员变“懒”了1.1 最典型的现象答案来得太快判断力却跟不上了老同学提了一个他们组里很普遍的现象AI工具刚铺开的时候大家热情非常高遇到任何问题都先丢给AI。不管是写用例、查文档、解释报错还是规划测试方案全都问AI。最开始确实感觉效率变高了但一个月后再复盘的时候发现有几个人不但没有变强反而变得依赖。他举了一个很具体的例子。组里有个同事让AI帮忙补充登录接口的测试用例AI很快就生成了一份看起来非常完整的用例覆盖了正常登录、密码错误、账号锁定、参数缺失、Token过期等等大概六七十条。同事很满意直接贴进用例平台就准备拿去执行。结果测试一跑才发现很多用例的预期结果根本就是错的——AI把接口文档里的字段描述直接当成了预期值比如“当密码错误时返回错误码1001”但实际上这个接口的真实错误码是1002。更离谱的是AI还把“输入密码时按Shift键导致大小写混乱”列成了一条高优用例这种想当然的场景放在真实业务里根本不存在。这个例子很典型因为它说明了AI在测试场景里的一个本质问题AI能快速给你一份“看起来正确”的答案但它不会为答案的正确性负责。如果一个测试人员习惯了直接相信AI的输出不再去核对需求文档、接口定义和业务逻辑那他的判断力就会越来越钝。这就像天天开着导航开车一旦导航出错你自己连东南西北都分不清了。1.2 关键不是“用不用AI”而是“用AI的人处在什么水位”其实我和老同学都认同上面这些坑不是AI本身造成的而是使用者的思路不对。同样是AI有人能借助它把测试效率和覆盖面提升一个档次有人却因为AI制造的“虚假效率”把质量给带偏了。区别在哪里区别在于这个人是在“用AI放大自己的专业能力”还是在“用AI替代自己的专业判断”。我拿生成测试用例来举例不会用的人把需求文档丢给AI让它“生成测试用例”然后把AI生成的用例全部当成最终交付物不做任何筛选和修改。会用的人自己先分析需求梳理出核心业务流程和重点风险然后让AI“根据以下测试点补充边界条件和异常场景”把AI当成一个辅助补充信息的工具最后再逐条review。同样是AI生成用例前者是“AI主导人配合”后者是“人主导AI配合”。两者出来的结果差距非常大。这也是我那位老同学最想强调的一点AI能不能在测试里发挥价值取决于使用者的思路而不是工具本身有多强。2. 测试人员用AI最容易踩的三个坑2.1 坑一把AI当搜索引擎拿到答案直接信现在很多人习惯用AI替代搜索引擎问“pytest怎么mock某个接口”或者“JMeter怎么做参数关联”。AI确实能给出答案但问题是AI的技术答案很可能过时、不准确甚至在某些冷门细节上是临时编的。我之前就踩过一回让AI写一段Python脚本处理测试数据它用了一个Python 3.10才有的语法特性而项目的运行环境还是3.8一跑直接报语法错。测试人员如果拿AI给的命令、脚本去搭建测试环境或者写自动化脚本至少要带着“验证”的心态去用关键信息去官方文档核对脚本先在小范围试跑。对AI的技术回答我更建议做“信息来源判断”——如果它给不出依据或者来源本身就模糊就要提高警惕。很多时候AI给你的答案只是一个“概率上像正确答案”的文本而不是真的经过了验证。2.2 坑二期望AI直接交出“成品代码/成品用例”这个坑在AI编程工具流行之后尤其普遍。不少测试开发把AI生成的自动化测试脚本直接粘贴到项目里结果一跑全是问题。不是AI生成的代码完全不能跑而是它缺少与具体项目的结合没有用项目里的统一封装、没有处理好登录态、没有考虑测试数据清理、断言写得过于简单或者干脆有逻辑错误。老同学在这方面给了一个很实用的原则把AI当成一个“能快速产出初稿的高级外包”。外包写的代码你敢不review就直接用吗不敢。那AI生成的脚本也是一样必须走完整的code review流程。而且他觉得AI最适合做的不是“从零写一个大模块”而是“在你已经搭好框架的情况下帮你补齐单个用例、单个函数”。这个定位如果不摆正很容易被AI生成的、看着很完整但一用就废的代码带进沟里。2.3 坑三不看上下文乱把项目信息丢给AI这里说的上下文有两层。第一层是“上下文信息”缺失。很多测试人员让AI分析问题结果只丢一句“这个接口报500帮我看看原因”。AI拿不到请求参数、后端日志、代码上下文只能给你一段“可能是XX原因”的通用分析这些分析往往没有实际价值反而还会误导排查方向。第二层是“信息安全”层面。把包含敏感信息的日志、生产环境的SQL、未脱敏的用户数据直接贴给外部AI工具这在很多公司的规范里是不被允许的。我自己的习惯是在上传任何信息之前先判断一下里面有没有敏感内容必要的时候先把手机号、身份证号、用户名这一类信息替换掉再发。同时对AI给的建议永远先判断“它看到的信息是否足够回答我的问题”。信息不够就先补信息而不是反复用同一个残缺的问题去追问AI。3. 正确的使用姿势AI在测试里是“副驾”不是“司机”3.1 定位一信息整理器而不是决策者测试过程中充满了信息噪音。一份需求文档可能有几十页里面散落着各种规则一份测试报告可能有几百条失败用例需要从中提取规律一堆报错日志里要定位最可疑的异常点。这些场景非常适合AI介入因为AI擅长做总结、归纳和关键信息提取。但注意AI的归纳可能失真它会在你不注意的时候把重要细节静默忽略掉。老同学团队的做法是让AI做“整理”人做“决策”。比如用AI把需求文档里的所有“必须”“不能”“仅限于”“除外”这类约束性词汇抓出来整理成一份测试约束清单但最终哪些约束要转化为高优用例哪些只是业务背景说明需要人来判断。AI负责把信息嚼碎了摆在桌面上但“怎么吃、吃哪些”这种事必须由人来定。3.2 定位二初稿生成器而不是最终产物这个定位在处理测试用例、自动化脚本、测试报告、甚至提给开发的Bug单时都成立。核心做法是让AI先生成初稿再由人来打磨。问题在于你要拿这份初稿当“索引”还是当“答案”当索引用把AI生成的用例当成线索从里面发现自己没想到的边界点再结合业务经验去增删改。当答案用把AI生成的用例直接提交入库省掉自己的思考环节等于把质量判断权交了出去。真正成熟的测试人员一定是用第一种方式。AI生成的初稿只是素材你的判断才是让它变成可交付物的关键。3.3 定位三学习加速器而不是权威知识库老同学特别提了一点AI对于测试人员来说其实是一个极好的学习工具但前提是你要把它当成“教练”而不是“答案机”。举个例子。如果你完全不熟悉性能测试与其直接让AI“帮我写一份压测方案”不如让它“先讲一下性能测试的整体流程、常用指标、常见瓶颈再结合一个典型的电商登录场景给一份压测设计思路”。第一种问法你得到的是一份不确定可不可用的方案第二种问法你学到的是解决这一类问题的思路。区别很明显。我个人也补了一句AI给出的知识必须交叉验证尤其是遇到版本差异、行业规范、合规要求这类问题一定要去一手资料确认。AI很多时候会用一种非常权威的语气说出并不靠谱的内容这种“权威感”是语气上的不是事实上的。4. 可以从明天开始用起来的五个AI测试实践场景4.1 场景一需求分析阶段用AI做测试点挖掘测试人员在需求评审前最耗时间的工作就是把PRD里的功能点拆成测试点。这个工作非常适合让AI先做一遍初筛。做法把PRD或需求描述整理成精简版注意去掉敏感信息发给AI让它结合需求列出功能测试点、异常场景、边界值、潜在风险。提示词可以参考下面这个模板你是一名资深测试工程师。下面是我负责的一个需求粘贴需求内容。 请帮我完成两件事 1. 列出所有需要测试的功能点区分主流程和次流程 2. 针对每个功能点补充3-5个容易遗漏的边界条件和异常场景。 输出格式功能点 / 测试点 / 优先级。 先不要解释直接输出结果。这里有一个容易踩的细节AI不了解你的业务背景所以提示词里要补充“用户是谁”“这个需求的核心价值是什么”“哪些模块是本次改动重点”。这些业务上下文AI猜不到你不给它就会跑偏。4.2 场景二测试用例设计阶段用AI补边界值我自己最常用的做法不是让AI一口气生成全套用例而是先设计好主干用例然后让AI“找漏洞”。这个用法更安全因为主干用例是经过你思考的AI只是作为补充视角。下面是我为登录功能设计的测试用例粘贴已有用例。 请帮我从边界值、异常输入、并发、安全性、用户体验几个维度补充我可能遗漏的测试场景。 只输出补充的场景不要重复已有的。 请为每个补充场景标注补充理由。这个做法相当于让AI扮演一个“挑刺的同事”。它提出的补充不一定全都合理但往往能给你一些平时想不到的角度比如极端输入组合、重复提交、缓存导致的脏数据等问题。最后你把这些补充场景和自己的理解融合一下再用业务经验做一轮筛选测试用例的完备度就会高很多。4.3 场景三缺陷分析阶段用AI做初步定位当测试环境出现一个比较难定位的Bug时我习惯把核心报错日志做脱敏处理后丢给AI让AI做第一轮分析。注意我强调的是“第一轮分析”——目的不是让AI直接告诉我根因而是让它帮我列出一个排查方向清单。以下是页面/接口报错的关键日志粘贴日志。 请从日志中提取关键异常栈列出可能导致这个错误的原因按可能性从高到低排列。 为每个原因附上对应的日志证据。 如果日志信息不足请直接告诉我还需要补充哪些信息不要猜测。这样做的价值在于AI能帮你快速覆盖那些你不熟悉的技术栈尤其是遇到一些冷门中间件、老代码框架的报错时它能给出很多你完全想不到的排查方向。但根因最后一定得自己去看代码、复现、确认不能AI说什么就信什么。4.4 场景四自动化脚本生成与维护阶段用AI做“填空”AI编程工具现在确实很强但测试脚本生成时尤其要注意它和项目的耦合。我见过很多人让AI“生成一个完整的接口自动化脚本”结果AI生成的代码自成一套体系跟项目现有的框架完全对不上根本没法用。我的做法是把项目里的自动化框架结构、公共方法、已有脚本样式作为背景信息给AI让它在“你的框架”里补脚本而不是让它从零生成。我们的自动化测试框架是Python pytest requests。 公共方法在 common/api_helper.py 里已有登录态获取函数是 def get_token(user):。 请参照现有脚本的写法和风格为“修改用户信息”接口编写一条完整的测试用例。 断言要包含状态码、响应码和关键字段。 先输出脚本再简要说明脚本中需要适配本项目的部分。AI生成完脚本之后一定要在本地跑通再提交。跑不通也没关系把报错信息回喂给它让它带着报错继续修。这个过程里你既完成了脚本也顺便把框架的基础用法过了一遍。4.5 场景五测试报告与质量数据分析每周写测试报告、发质量周报是很多测试人员的固定负担。AI可以把这部分繁琐的整理工作减轻很多。把原始测试数据整理成文本或表格让AI生成报告初稿效率会高不少。以下是一周的测试执行数据粘贴数据。 请帮我生成一份测试周报包含 1. 总体执行情况 2. 缺陷分析按模块、按严重级别分布 3. 风险与建议。 要求数据必须完全基于我提供的内容不得编造。 如果数据不足以得出结论请明确说明数据不足。这里要特别警惕AI有“脑补”倾向它会为了答案的完整性而编出一些看起来合理的结论。所以你必须在提示词里明确要求它“只基于事实不做主观推测”。报告生成之后所有数字都要人工核对一遍这步不能省。我把上面五个场景汇总一下方便参考场景AI适合做什么人必须做什么需求分析抓约束词、列测试点、补异常流判断优先级、结合业务补隐性规则用例设计补边界值、补异常场景筛选合并、加业务语义、审核可执行性缺陷定位提取异常栈、列原因假设复现Bug、看代码、做根因判断自动化脚本按框架风格补脚本、生成数据构造代码调通依赖、改断言、维护稳定性测试报告整理数据、生成初稿核对数据来源、修正结论、补充建议5. 老同学反复强调的“提示词能力”到底是什么5.1 提示词的本质是结构化表达不是咒语聊到后半段老同学反复强调一个点会用AI的人和不会用AI的人差别往往不在技术背景而在“能不能把问题讲清楚”。这句话当时给我的触动挺大因为这不就是我们测试人员天天在做的事吗我们写Bug单要写复现步骤、写预期结果、写实际结果我们做测试设计要描述场景、前置条件、操作步骤。这些都是结构化表达。所以老同学觉得测试人员学写提示词其实是有天然优势的。一个好的提示词本质上就是把“背景信息、任务目标、限制条件、输出格式”一次性表达清楚。这不是什么玄学就是沟通能力在AI场景下的延伸。5.2 一个可以直接套用的提示词框架结合我自己的使用习惯我整理了一个适合测试场景的提示词模板你拿去改一改就能用角色你是一名测试角色有X年经验。 背景描述项目/模块/技术栈/当前阶段越具体越好 任务请帮我具体任务如设计测试用例/分析日志/写脚本。 限制只基于我提供的信息不要做超出信息的推测不要使用某些不想要的方式如果信息不足请先提问。 输出请以表格/列表/代码块的形式输出包含字段1/字段2。这个模板里最关键的是“背景”和“限制”两部分。背景决定了AI输出的相关性限制决定了AI输出的可靠性。很多人觉得AI答案质量差往往就是因为背景信息给得太少边界条件没有说明白AI只能基于一堆模糊的假设来猜。5.3 会提问比会念咒更重要所以我其实不太建议大家去网上背一堆所谓“AI魔法咒语”那些东西的效用往往是暂时的。真正有效的是你对自己问题的理解深度。当你能把“我的需求是什么、我希望AI做什么、我不要它做什么”这三句话讲清楚的时候不管AI工具怎么迭代你都能把它用得很好。这个观点老同学也特别认可。他说他们团队现在培训新人第一课不是教哪个AI工具好用而是教怎么把自己的测试思路结构化地表达出来。工具会变提示词的表面形式会变但底层这个能力不会过时。6. AI替代不了的那部分才是测试人员的核心价值6.1 AI能做的和做不了的聊到后面我们不可避免谈到了焦虑感AI会不会让测试人员失业我的看法是我们先把AI能做什么、不能做什么这个问题看清楚再讨论焦虑也不迟。维度AI能做的事AI做不了的事测试设计快速产出用例初稿、补边界判断业务价值、权衡测试成本与风险缺陷发现分析日志、聚类、初步定位理解用户真实使用场景和真实痛点自动化生成脚本、修复简单报错评估框架选型、维护复杂依赖质量决策统计数据、生成报告初稿承担质量责任、决定是否上线团队协作生成沟通文案说服推动、跨部门协调这张表其实已经说明问题了。AI能做的更多是“执行层”和“整理层”的工作而真正决定一个测试人员价值的恰恰是“判断层”和“决策层”的工作。6.2 测试人员未来的四种核心能力基于上面的分析我觉得未来测试人员的核心竞争力会越来越集中在四块业务理解力懂用户、懂业务规则知道什么值得测、什么不值得测。测试设计力能设计出高效的、不冗余的测试策略而不是简单地堆用例数量。工程化能力能把AI工具和现有的测试框架结合起来搭出完整高效的测试工具链。推动力能把质量风险讲清楚推动团队和业务方一起解决质量问题。老同学当时说了一句话我记录下来“AI会让很多初级的、重复性的测试工作消失但也会让真正懂测试的人价值变大。关键在于你能不能从执行者变成设计者和决策者。”这句话我觉得是会慢慢被验证的。6.3 与其焦虑不如从一个小场景开始最后聊到心态。我给测试同行的建议是不用焦虑到把AI神话也不用装作看不见。老老实实挑一个自己最痛、最频繁的场景用AI去解决它完整地走一遍“人主导、AI配合”的流程亲身感受一下什么样的输出能用、什么样的输出不能用。走完这个流程你对“AI到底能帮我做到什么程度”就有了真实的体感这比看任何文章都管用。聊天结束的时候老同学说他还总结了一句话AI不是来替代测试人员的AI是来逼着测试人员变得更强的。这话听起来有点鸡汤但结合我们聊的那些案例我觉得它确实是现在正在发生的事情。未来的测试人员大概率不会是被AI淘汰的而是会被那些“会用AI的测试人员”拉开差距。与其停在原地纠结不如今天就挑一个重复劳动最多的场景认真用AI走一遍。等你自己跑通了你心里自然会有答案。