一起学习

测试人员永远不会被时代抛弃。在实际工作中，测试正变得越来越不可或缺。AI 打破了传统开发的技术壁垒，过去只有高级开发或架构师才能掌握的技术，如今不再需要高昂的沟通成本 —— 借助内置开发工具或直接询问 AI，就能快速实现需求，甚至完成代码打包等步骤。因此，AI 对传统开发者的冲击是巨大的。
而测试的核心在于测试思维，并非模板化、格式化的标准答案，这部分能力 AI 仍需要大量数据与场景训练才能真正成熟。即便如此，测试人员也应掌握基本的代码逻辑，才能更好地借助 AI 提升效率。
目前用 AI 做测试，成本与产出基本成正比，未来前景广阔，我们要提前做好准备。

现在使用 ai 去梳理 prd 文档的测试点和测试用例的话，请问你是如何做的？是使用 deepseek 还是使用 cursor，我现在不知道该如何将 ai 应用到现在的偏手动功能测试的工作当中

学习这种是学生思维，未来需要的是独立创造价值。
解决什么商业问题，客户问题。
所以你会用 AI，能降本增效，能压缩人力，能把别人不愿意干的干好，才有价值。
AI 目前还只是工具，技术最终是为解决问题服务的。

为什么会有测试职位？因为传统软件开发的流程下，让开发者自己去发现自己的问题，多少有点违背人性。
当工业软件复杂到一定程度的时候，需要有个兜底和融合的角色。
如果当软件开发这个工作都在极致压缩，AI AGENT 可以自己 CODING，自己测试，自己融合的时候。就算你会 AI，会做单测，这也就是一锤子的买卖。
未来测试不会消失，可能一部分会被解决方案的岗位用 AI 工具替换，另一部分作为专业人士为整体交付兜底。这些都不是单纯的测试技术。

做技术要么就卷生卷死，要么就别做了。--说句不客气的话，但凡有些追求，也不会这回才来接触 AI。
对大部分人来说是越来越不友好了。
还不如降低欲望，反而活得开心。

这就和很多年前问是学 PYTHON 好还是 JAVA 好，测试要不要学自动化差不多。。。
你问 AI 都比你问旁人靠谱的多，不熟悉的人哪知道你什么状态。你现在和 AI 可以有交互，可以结合你当前的状态去交流。可见行动力之差。。。

PS:
软件行业受 AI 冲击之大，一两年前我认为大概也就 50%。
现在真的不好说，如果没有政治介入，能剩 1/3 可能就不错了。
我去年从上家离职的时候还和研发的老大说只要是网上能查到的接口这种 API，AI 都能解决了，有啥好看的。没想到一年不到，CUDA 都能自己写了。。。
在这种前提下，测试岗位怕是能剩下的会更少，小公司可能都得绝迹了，外包化还会更严重，缩岗缩编是必然趋势。

说到底，但凡你有个强大的心理素质，该卷卷，该躺就躺着。
别总想有的没得，与人友善，能抗压扛事，比什么学 AI 靠谱多了。还能没口饭吃？

1. llm 辅助生成测试用例
2. llm 辅助开发测试工具
3. 至于执行测试，等大模型和 ai 再进化一段时间

我刚试了一下用 ai 去给流量回放 diff 降噪。。。。主要是因为懒的一个一个接口/字段分析。。。不过感觉测试没啥意思，年龄到了没搞到钱

我也很奇怪，话说作为一个测试，使用 ai 写写用例写写自动化，就算跟上 ai 发展了嘛？好像跟 ai 测试半毛钱关系都没有啊。测试学习 ai 不应该是学用 ai 去测试，而是学习怎么测试 ai 相关的业务吧？

cursor，就是最简单的问答模式

但不是所有的被测业务都和 ai 相关的吧？如果和 ai 不相关呢？

有道理，但是想不被抛弃，不就得跟上吗

加油！

ai 被寡头蚕食，国内基本只有大厂烧的起钱，有多少私企能搞 ai 呐？所以测 ai 的岗位本来就很稀缺，门槛很高，名校进大厂可能是最简单的途径。而且以后 ai 的格局固定下来了，感觉基本都变成几家天下了，普通人还是着眼于 ai 赋能相关的行业比较容易找到工作吧

我们目前基于公司基建，主要在 AI 用例生成 和 AI 用例执行 两方面实践提效，当然现阶段都没法完全自动化，AI 生成一版后还是需要人工确认和按需调整，但通过 AI 辅助确实已经很大幅度提升了效率了。

其次，如果业务有涉及 AI，最好去接触下 AI 评测，这块我觉着未来会变得很普遍。AI 评测模式上和功能测试还是有挺大差异的。

最后，比较认可 4 楼的观点，按照现在 AI 的发展速度，很快研发团队就不需要那么多人了，QA 也是类似。想办法让自己能独立创造价值，可能前途更光明一些。

我昨天和组里同学在脑暴，我发现整个测试过程中的单点基本都已经完成提效了。

一个中大规模迭代，

1. 测试分析，分钟级别产出，以前至少 1 到 2 天。
2. 测试用例，30 分钟左右可以生成，review 花半小时。
3. 测试执行，这里还是有些困难，得拆解，比如接口测试基本完全可以用 AI 生成。
4. 测试报告：包括缺陷提报，缺陷报告，测试报告，全部可以 AI 来做
5. 测试工具和平台：对任何测试来说，编码已经没有门槛，人人都会用 AI 生成测试工具和平台。

现在真的只有测试执行，或者更底层的是，架构可测性的问题了。一旦研发用 AI 设计和编码的时候，AI 把可测性建设好，那测试执行也可以完全用 AI 来做。

https://testerhome.com/topics/43564

我们组的思路是在研发自测大背景下，帮助研发自测得更快更好。

1. 对于已有的用例，从不同类型的风险视角，评估哪些用例要留下，哪些可以去掉
2. 结合现有的各种自动化、监控报警、专项兜底，第 1 步中留下的用例，是不是还能进一步删减
3. 最后剩下的少量用例，是否除了执行本身外，还需要关联去建设自动化、监控报警、专项兜底等，给出执行和建设引导

上面是用例评估的，结合用例生成，自测留痕、bug 验证，就都闭环在一个质量平台下了，最后结论是 QA 自己把自己干掉

好奇一点, 这是预测, 还是已落地

我年前想搭一个 AI AGENT 直接把我需要执行的脚本帮我在实机上跑一遍。
简单搞搞应该不行就放弃了。和资源相关的应该还有门槛。
然后 AI 告诉我，我给他提方案，他写代码，我去跑然后给他修 BUG 就是价值。。。

现在 AI 拆解任务的能力稍弱以外，写脚本那可比我速度快多了，完全是分钟级的。
25 年年初还觉得 AI 大部分还是智障，下半年明显感觉突飞猛进。
尤其是写代码，设计结构那都是杠杠的，我那时候的第一个反应是软件开发是活不了太久了。。。

现在大点的厂都在推 AI CODING 吧，就看还能挨几年了。
人很多时候比机器草台多了，如果能看到草台的一面，我估计还能多活一段时间。

以后 AI 使用者，应该只存在产品角色和 AI 工程师（AI 上层工具搭建）了吧，当 AI 在完成代码开发的时候，已经不担心 AI 自测能力了。基于 MCP 和 skills 可以高质量完成。

甚至以后真的还需要这么多 UI 界面都存疑，当智能终端真的有 AI OS 的时候，所有 APP 估计都要消亡了。 过年期间的千问购物场景已经是很好的证明了。

那你错了。什么时候研发有非常好的质量意识，才有可能自测。

落地了

大佬，能分享一下吗

团队的力量，技术很简单，思路比较重要。

一个人的团队，特别希望能够学习到别人的经验

您好，你说的 AI 评测模式是指什么？有点没太看懂，能稍微简洁的说一下嘛？

我现在还没有将 cursor 应用到工作当中，还处于探索 cursor 使用的阶段，但我在使用前有一点很困惑，我如果想用 cursor 来根据 prd 写测试用例，那这个测试用例会漏掉很多的功能点，因为新的一期的迭代所覆盖的功能点可能是在旧迭代之上的。
麻烦大佬解答一下我的困惑

感觉以后研发和测试就不分你我了

一直秉持一种想法：只要通用大语言模型的幻觉在、垂直和私域数据不用来训练 AI，企业内部的研发通过 AI 成产的代码和最终产品都会包括缺陷，独立测试才有生存的价值和心理学基础。悲观主义者 vs 乐观主义 在看待上述推演的时候所持的立场本身就不同。但是在 AI 大时代下，做点儿具体工作，让自己觉得自己还能行，不会被社会淘汰，似乎在心理上才有补偿作用，但是可能也是没啥作用的。

我是觉得可能有点太乐观了，这一套搞下来需要的前置条件目前很多公司应该都没法实现。

“测试分析，分钟级别产出”，这点不是很认可，测试分析并不是仅仅只为了产出一份文档，更多的应该是测试执行人员有自己的分析及思路，完全交给 AI 那就不叫测试分析了。

给 cursor 尽可能完整的 prd，老的功能加新的功能，最好再有老的功能的用例吧，然后提示词尽可能强调让 cursor 生成比较全面的用例。当然即使是在这个基础上，你最后也可定需要自查一下的

比如功能测试上，因为代码都是确定性的东西，所以直接通过 步骤 - 预期结果 ，就能验证是否 ok

而 AI 则是概率性的事情，类似的内容可能换个说法，AI 的理解就会有很大偏差，人肉去测试成本很高。需要通过足量的评测集覆盖尽可能多的典型的场景 + 离线评测保障基础能力达标 + 线上持续监控优化 badcase。

是的，这些点提效都很明显。我们现在用例编写基本都是 AI 先生成，然后再人肉 review 调整，甚至调整也是借助 AI 去批量调整，而不是直接上手改。

测试执行很多时候涉及具体环境、上下游等，以及过程中可能有些需求变更、操作体验啥的前期用例没法覆盖的，暂时还没有很完善的方案。

不过如果是研发自测程度的测试执行，现在其实已经能做得很不错了。我自己写一些平台功能，让 AI 生成技术方案同时生成对应的测试用例和去执行用例，确认代码可跑通且逻辑结果符合预期，都做得挺不错的。

这种一般两个路径

一个是反推提升 PRD 质量，把这些涉及的历史能力也说清楚。不过比较难，毕竟增加产品工作量，且对产品来说价值不大。
一个是建立知识库，让 AI 生成用例时，也通过 RAG 到知识库查看相关的知识（历史 PRD、历史用例等），进行补充完善。这个主要难点在于知识库的及时维护和召回内容准确度。

公司的 prd 比较粗糙简陋，里面有较多的图片，大部分的需求都是要结合文字和图片才能理解到需求，所以在把 prd 喂给 ai 的时候，ai 很难生成质量高的用例，或者说几乎是无法生成实质性有用的用例。
如果是我上面这种情况，我该怎么做呢？麻烦老师给我解惑一下

做了一年多 AI 提效相关的活，有上头派下来的，也有内部孵化的。目前我这这边团队内共识的是测试分析和测试用例生成目前不适合 ai。看起来是能快速出结果，但结果可用性不高，主要问题在于输入的语料太多导致分不清重点是什么，导致实际可能的实际业务场景无法列全，对新项目稍微好一点，对于迭代中的业务基本没有价值。

这个问题在上下文受限的当下是无解的，除非人把 prd 和技术方案进行二次处理梳理好重点业务场景和细节。可这样和让 qa 写用例区别不大了。 这样的成本不如人写完用例让 ai 做 review 呢

智能体做的比较好的是测试执行和验证这类根据用例可以明确步骤的事情，qa 生成指令 (用例) 之后让智能体执行，等执行结果 review 就好了。目前通过不断调优正在做的更好

长期的行业发展鄙人目光短浅看不到，中期来看 AI 时代是对 qa 的要求更高了，需要产出能让智能体执行的用例，另外需要能通过调整用例和优化测试智能体，提升测试执行和结果检查的质效。

测试分析和测试用例做绝对没错，但是很需要足够的知识库和上下文，不能让 AI 太发散，范围要约束好（第一个坑就是上来就让 AI 对通用需求提供通用用例，应该是具体某方向的需求提供某些具体维度用例）。我们内部也有实践，虽然也是效果很差，但我判断是提示语设定的 AI 工作目标太发散 & 业务知识库匮乏的原因。这些短板慢慢补上去之后，肯定会越来越好。

向量库库模式我们试过的，先不说知识库的维护难度。真正复杂的业务，需要知识库的内容是海量的，包括业务场景的介绍，操作步骤，数据构造方式，核心关注点这些。一旦某一条召回的不够准确，就会跟下毒一样产生蝴蝶效应。
目前没找到能自动根据业务重点返回刚刚好 “合适” 分片的知识召回模式。 目前也没发现有大模型能在海量业务上下文中还能完全遵循提示语圈定的范围进行用例生成。

之前把某个新业务花了好几天终于调好了，用例生成的也基本能看到了，等业务一迭代就完蛋了。知识库要更新，提示词也要改，调试成本超级高。给老板演示完就搁置了，打算等哪天模型能力够强了再捡起来吧。

另外光知识库也不够，还需要配合源码级别改动点的输入，光把 code diff 传进去也是不够的，需要系统性的分析改动方法的调用关系，从入口方法传到改动点的方法源码，不然模型无法通过改动对应到场景，用例的可执行性超级差。 这又给本就不富裕的上下文雪上加霜。

总的来说就是，上下文给少了生成效果不知所云。 上下文给多了注意力涣散胡言乱语

还有一点就是，在给 cursor 喂 prd 和以前用例的时候，在 cursor 拿到一个新的 prd 的时候，它似乎无法做到理解各个模块之间的联系，从而也导致在输出新 prd 测试用例的时候，无法将这部分的用例写出来

和我们团队现在的方向很类似，我们也差部分预估 26 年 Q2 就能完成这个方向的建设了。越是深度的参与使用 AI 越发对行业前景感到悲观。好在我一向奉行先吃螃蟹的人能多吃几口螃蟹，而且已经 33 奔 4 了本来就没多少之前发展时间了，后面就留给新一代人操心吧

第一个问题，明显是行业术语，背景知识库的维护。这 2 块没有进行设计和维护的原因，单纯靠调整 prompt 是没用的。这也是 AI 目前最大的问题，也是需要人的地方。如果 AI 连这一层都突破了，人就真的就要那几个就行了

个人觉得知识库中背景知识这部分靠人是堆不好的。它不像操作手册数据构造这类基本不变化可以沉淀为 skills/prompt，也不像天气时间这类可以通过 mcp 实时获取阅后即焚。业务背景知识是不断随着系统迭代变化的。某个场景今天需要这样支持，明天需要改成那样，甚至再过几天下线也是常有的。甚至还有灰度这种同业务不同处理模式的情况，只有建立和人脑类似的结构才能很好的处理归纳这类知识。

真突破了的那天直接给 cursor 或则 Claudecode 一份 prd + 知识库就可以了，开发先一步下岗了哇，

这个你可以通过提示词方面强指定试一下，或者是分模块生成

最好是自己再二次编写一下 prd，把那些图片化的东西变成明确的文字说明。即使让 AI 生成测试用例，也得确保自己对每个功能是了解的状态，而不是一股脑都丢给 AI

请问目前测试用例的生成是通过简答的聊天模式吗？

问下大佬提效这块比较容易出成果的是哪块呢，结合你司目前已经投入使用的

明白了，谢谢老师的建议

是的是的，一看就是有真实践的哥们。

确实除了业务知识库，业务的一切资产也是尽量精简一些喂给 AI，包括业务代码、业务配置、业务文档等。

这里面比较蛋疼的是，往往很多东西都跟公司内部平台绑定，很多概念性的东旭需要让 AI 先知道；另外发展快的业务用起来确实极差，目前相对更适合迭代成熟，需求偏向在原有功能上改的类型（而不是起全新功能的需求）

你说得对，全新功能的需求只有第一次好用，再迭代就跟迭代中的需求一样难受了

你说的这个东西，就是建立一套动态的知识库体系，让 AI 自己去做这个分类，以及结合流程，在不同阶段接入不同的 prompt 去迭代这个知识库。相当于是执行 agent+ 维护 agent 的组合才能完成这个事情。也是现在有这么多开源的流程节点 AI 但是落地到实际项目的时候，很多人一脸懵逼的原因。这一块必须要有这个思路和结构

大佬谈不上哦，个人比较建议后端 qa 做用例执行和验证方向。
只要用例明确，从接口维度是可以走通场景执行 + 验证流程的，且通用性较高，不太受业务复杂度影响。
别的不敢说太多，怕被敲门查水表

不是的，在某个 AI 聊天框上的问答模式显然没法满足，体验割裂的同时也没有上下文一说。都是通过 api_key 调模型接口的。然后固定好提示词，以及一些业务资产的输入。

确实单纯的问答模式确实是不太适用。学到了。
请问:
这个是不是有一个简单的前端支持上传 prd 或一些别的辅助文档然后丢给 AI，再结合已固定好的提示词。
这整个搭建过程复杂吗？一个人再通过 AI 大概多久能完成呢？

您好，麻烦请教一下，对于测试报告和缺陷报告的生成是使用的哪个工具呢

没有工具，自己写啊。

我还是比较认可你说的，至少我目前看到的，你这个实践是最符合我体感的，生成用例这块我觉得就是属于死党 - 上下文少不行，上下文多也不行，受限于模型本身能力。加上人工迭代等等。除开少数业务是那种定向分析的，能开拓一下分析视角。我个人觉得 ai 还是用于编码方面是更适配的，强行拉到测试这个版子有点过于强求了

给的东西太多了 那 AI 的上下文不会爆吗？ 对话 token 越大 AI 智能会下降？

真的流程跑通以后，效率大幅度提升，是不是会大面积裁员

如果要用户体验好，肯定得和目标系统耦合在一起，不一定是什么前端，可能就直接是后端把 ai 整合在一起调用了。

【这整个搭建过程复杂吗？一个人再通过 AI 大概多久能完成呢？】这个问题太 case by case 了，没法回答

感谢认可，测试领域的智能探索免不了都要涉及用例生成。这个方向确实也是最好出结果的。简单搭个工作流，针对某个需求特调几天，演示时放个 prd 进去就能出一个像模像样的用例。但非特调的效果只有一线真正背质量风险的 QA 才知道了。

我这边演示也是特调的，但是和老板公开了从生成的狗屁不通到像模像样的特调过程，除了要在提示词加一堆限定，还需要不断调整知识库的分片和需求文档的细节，比把用例直接写给智能体还费劲

时隔几年冒个泡，也是希望大家谨慎入坑用例生成方向。在模型和 rag 有质量的飞跃前，出结果容易出效果难

我司正在做模型蒸馏加 UI 自动化，看起来高大上，实际上只是完成领导的指标而已

你好 大佬 关于测试执行和验证能具体讲讲吗 是自己编写完测试用例让智能体执行？ 是通过智能体生成的接口去执行还是生成自动化脚本去执行呢？

真不是大佬
目前是用户写手工用例，之后让智能体生成代码用例去执行。

想做好这套依赖完善的基建。基建不完善是搞不定的，至少要支持：
1.实时维护的依赖数据生成器
2.查询接口声明
3.执行后影响的数据查询
4.用例维度的代码覆盖

那这种是不是可以理解为，如果产品的逻辑总是重复改，文档也不够完善的情况下，还是先人力沟通，完善场景。
写出比较完整的测试用例，再让 AI 去做执行？
但是这种覆盖面，能够比接口测试更广吗？
个人体感工作中测试的困境时，场景在测的时候才发现之前需求讨论、研发设计时根本没人考虑到，但是测试环境却容易想起来，这种纯靠人的，AI 能够想到吗

测试覆盖面的广度是用例设计中需要考虑的，如果 A 设计用例，B 完全按照 A 的用例执行用例。后面发现场景覆盖不全导致线上问题，会找设计方 A 还是找牛马 B？

在测试过程中想起来遗漏场景的情况，我理解有两种情况：

1. 用例执行失败了，排查的时候发现了一个遗漏的场景。 这种通过 ai 也会执行失败，需要人介入排查之后也是可以兜住的。
2. 通过执行用例，人对场景的理解越发深入，发现有些操作可以变化一下，变化后会导致一个未评估过的结果。这个可以在全部用例执行前和全部用例执行后各加一个反思环节，让智能体多次判断是否存在可能遗漏的场景。

单纯从权责的角度上来说，因为用例已经三方 review 过了且严格执行和验证了，指望在用例执行过程发现遗漏场景是不负责任的赌神行为

有时候很难界定呢
我们之前就遇到一个特殊参数组合，才出问题。
是 4 个参数组合，才出现。而且当时是只有 1 个参数是新加的，其他的参数是之前就有的。
单一参数的验证都是没问题，就只有一种特殊组合才出现。
从目前项目的迭代周期来看，这种复杂的场景，就算用 AI 来做遍历回归，写用例时也很难考虑到这么深层的。

不过领导都是默认算漏测了

目前针给稍微复杂点的业务生成一份可行的用例都很难，还是别指望 ai 做深度的漏测评估了。
你问就是 “漏测” 了，保险起见你还是测一下吧，甚至还可能带出来几十个其他 “漏测” 的场景，人是测还是不测呢。