某老板开发已经用AI提升了数倍的效率与产出那测试呢如果测试在AI时代掉队了那是不是不需要测试了某测试人员我折腾了大半个月的AIAI根本没办法给测试人员提效它就像个弱智一样。我相信很多同学都在网络上捡到过上面那两句话 甚至亲身经历过这两句话。因为我就经历过我本身在国内的顶级大厂。公司对AI的重视程度之高前所未有。为员工分发的token数量十分丰厚就是希望员工能利用AI成本的提效。而上面引用的老板的话就是我们管理了整个部门几万人的大老板所担心的。PS 如果对我的文章感兴趣请在知识星球中搜索测试开发之路实际上这个担心已经变成了现实。我们业务线上的开发人员全部都在用AI编程产出效率提升的十分恐怖。所以整个质量部的老板们也都陷入了焦虑中。他们最怕的就是业务团队反馈测试人员的效率跟不上节奏。所以测试领域的AI提效路线基本上是整个行业板上钉钉的大趋势。如果测试人员想在这个行当里混到第一梯队那AI测试的能力是绕不开的一道坎儿。昨天有个同学加入星球后找我聊天还说现在的面试都在考核AI技能了所以我们回到一开始的那两句话来。 第一个我们已经有答案了AI测试是大势所趋非万钧之力不可违抗。那我们来说说第二个为什么很多测试人员感受到的是AI并没有给测试领域带来什么有效的提升其实这个问题不仅仅是测试人员会感受到很多其他角色也会有此感受。这是为什么呢答案很简单使用AI也是需要学习的它跟很多人的第一印象是不一样的很多人想的是把需求扔给AI再用一两句话就可以让AI干活了。但事实上如果真这么干了一些简单的任务还没什么问题。但场景稍微复杂一点大模型就会开始放飞自我各种跳步幻觉自欺欺人的事情就会出现。这就是为什么很多人会觉得AI不是很靠谱。使用AI也是需要学习的是需要专业知识的它根本就不是一个傻瓜式的谁都可以用的东西。很少有开发人员会抱怨AI的能力是因为开发同学天然就会去学习这些东西如果大家去看各种开发社区甚至只要去B占上搜一下就会发现各种Agent设计方法论十分流程很多人在很早的时候就开始讨论harness讨论渐进式披露讨论多Agent协同讨论如何让Agent稳定高效的执行一个需要几十个小时的大型的复杂的任务。而测试领域呢我很少看到有人讨论这些反而是很多人在高举反对AI的旗帜妄图对抗大势。即便不反对也是在发帖各种抱怨。有些时候我们跟开发同学的差距就在这里。实际上我很喜欢开发人员他们永远都在拥抱最新的技术永远都在探索更好的方案。OK说了这么多那测试人员当前应该怎么办说一些我自己的观点当前阶段我们应该跟开发人员一样去学习如何更高效的运行一个Agent任务如果有关键词那就是harness。harness是目前行业里广泛被认可的用来保证Agent稳定高效运行的方法论。事实上这个关键词并不重要重要的是要不停的去学习更好的让Agent来辅助工作的方法。然后用在我们的日常工作中。就目前而言我用AI做的事情AI分析需求并生成测试用例。把测试用例转成接口自动化测试用例AI驱动UI自动化测试AI执行性能测试AI执行容灾测试高可用测试以上都各自有相关的skill而这些skill也都是按照harness的原则进行设计。我工作中基本上90%的内容已经交给AI来完成。而这些工作量在没有AI之前大概需要4到5个人才能完成。学习如何使用AI是测试人员以后的硬通货当然我提到了这么多次harness那harness究竟是怎么来的这里我也介绍下harness的发展历史。借由这个发展历史我们也可以给大家说明一下为什么不同的人用同一个模型会有完全不同的效果。提示词工程 → 上下文工程 → harness 工程先抛一个现象同样一个大模型在不同人手里产出的效果可以差出几个量级。为什么我自己总结下来主要是三个原因a.模型本身有非常广阔的知识但它不知道在你当前这个具体场景下应该调用哪一部分知识。b.模型同样有知识盲区尤其是你公司内部的业务、私有 API、历史遗留的奇怪约定这些它从训练数据里学不到需要你来补。c.哪怕模型知识齐全了它也不知道在你这个场景下先做什么、再做什么、最后做什么——也就是工作流。于是就有了我们最熟悉的提示词工程PromptEngineering它要做的事情其实就两件1.补齐缺失的知识和经验把场景、约束、术语、示例喂给模型2.指导模型按什么样的工作流去完成任务步骤、顺序、判断点、产出格式。下面这张图大致能说明这件事图左模型像一个塞满知识的大球但它自己也不知道当前该用哪些。图右那颗球上其实是有洞的那些洞要靠用户去填。图下用户通过提示词把该走哪条路明确告诉模型。结论很朴素模型再强也需要人来指导它的能力才能真正释放出来。从提示词工程走向上下文工程提示词工程能解决不少问题但用着用着会发现新的痛点业务场景越来越复杂对话轮数越来越多每次新开一个会话都要重新交代一遍背景、规范、目录结构、历史决策……人会烦的。于是大家又提出了上下文工程ContextEngineering把每一轮对话里沉淀下来的信息——背景知识、决策、产物、约定——结构化地记住让用户从重复输入中解放出来。这些上下文是可以被压缩、复制、删除、挑选的可以在不同的会话之间流转也可以在不同的 Agent 之间共享。本质上它给模型外挂了一份项目记忆。上下文太多模型反而会腐化但事情没完。当上下文越堆越多之后新的问题又出现了模型开始忘记前面定下的关键规则海量信息互相干扰模型被带偏给出南辕北辙的答案越长的上下文越容易出现看起来在认真做其实早就脱轨的情况。这种现象可以粗暴地称为上下文腐化。为了应付这件事又有了harness工程harness 本意是马具。harness 的思路非常直白给模型套一层约束让它不要那么跳脱而是必须在规定好的框架和工作流里完成任务。具体表现可能是把一个大任务拆成若干个明确的阶段每个阶段有固定的输入产物和输出产物用多个子 Agent 各司其职互相之间通过文件而不是口头转述传递信息对每一步都设置检查点不通过就不允许进入下一步即使重试也要在受控的范围内进行不允许模型自由发挥。我们这套AI驱动的UI自动化工程里用来编写自动化测试用例的那个skill本质上就是基于harness理念做的。它把分析—实现—验证拆成三个 agent按状态机推进产物落在固定目录失败重试有上限未经审批不允许改老函数——这些都是 harness 的味道。回到那个问题所以为什么同样的模型在不同人手里效果差这么多有的人希望一两句话就让模型干活剩下全凭模型自由发挥有的人则会认真给模型设计一套严格的工作流、约束和反馈机制。差距就出在这。顺带说一句这篇文章的正文也是 AI 生成的但大纲是我写的。这本身就再一次印证了上面的观点——AI 是放大器输入端的人决定了它的产出质量。以上就是harness的由来。开发都用AI提效了质量风险被放大测试人员怎么办我们再回到这个问题上 现在的情况其实挺微妙的开发同学普遍开始用 AI 写代码单人产出效率被显著放大但有些开发同学并不懂 harness 那一套或者用的不是太好他们用 AI 的方式更接近提个需求、复制粘贴、能跑就行结果就是代码产出变多了但每行代码里潜在的质量风险也变多了——逻辑漏洞、边界遗漏、隐蔽的安全问题、莫名其妙的副作用都比以前更难一眼看出来。与此同时老板们的关注点是怎样的效率是看得见的上线快了、需求吞吐量上去了质量风险是看不见的它要等到线上出问题那一刻才变成数字。并且认为如果测试时间无法被压缩将是测试人员自身的问题。这就导致一个尴尬的局面AI带来的提效被高估AI带来的质量风险被低估而中间承压的恰恰是测试人员。那怎么办焦虑是没用的唯一的出路是我们自己也用AI把自己的效率拉起来跟上行业节奏。我自己的几个落地方向分享一下1. 用 AI 快速沉淀自动化资产以前很多自动化工程跑不起来不是因为技术不行而是人力成本算不过账写一条用例的时间够手测跑很多遍了而且写完还要长期维护。产品一变就要修改很多东西。而AI 介入之后这笔账完全不一样了用例生成、定位元素、写断言这些机械活AI 干得又快又稳维护成本也被压缩——失败用例可以让 AI 先做一轮归因配合 harness 化的 skill比如我们教程里的那一套用例质量是可控的不会越积越烂。结果就是以前因成本太高而被砍掉的自动化覆盖面现在可以重新捡起来。2. 思维切换到 AI First这一点是态度问题不是技术问题。遇到任何事情不管自己会不会先问一句这件事AI能不能帮我先走一遍需求分析让 AI 先帮你拆解、提问、找疑点用例设计让 AI 先生成一版你来做减法和补充专项测试性能、安全、兼容性让 AI 帮你列检查清单和工具选型甚至执行让AI来运行。技术方案调研让 AI 先做信息整合你来做判断文档、周报、总结这些是 AI 收益最高的场景之一没必要硬扛。不一定每次都用得上但养成先问AI的反射长期下来差距非常明显。3. 把 AI 当作随身学习入口测试这个岗位本身就涉及大量横向知识新业务、新技术栈、新协议、新工具遇到知识盲区是常态。以前的做法是搜索引擎 文档 社区效率不算高。现在的做法是先让AI帮你建立一个60分的认知框架然后再去看一手资料补细节。这中间省下来的是大量我现在到底该看哪本书、该从哪里入手的时间成本。三、写在最后我个人对未来的判断是这样的AI 现在势头很猛但短期内绝大多数企业仍然需要大量人工来做测试工作所以也没必要陷入那种我马上要被替代的焦虑但长期看行业里能留在第一梯队的人画像基本都是特种兵AI方向感强、判断准、产出快AI 是他们的放大器不是替代品。后续更多精彩教程可以在知识星球中搜索测试开发之路最终再重申一遍以后测试行业能混在第一梯队的人一定是 特种兵 AI 的组合模式。我们需要持续的去学习如何利用好AI的能力。