其实最好就是把问题发给牛的模型，它会给你比较系统的方法
个人拙见就是增加代码静态检查的工作流，同时找人用 ai 快速搭建接口测试和自动化回归测试

这种真实的话题，社区是激不起什么浪花的，现在的风气是要为 AI 鼓掌，至于 AI 造成的麻烦怎么去合理解决，这里没人提

那也没有，主要是解决 ai 带来的麻烦，实在没时间来回复～

我比较赞同这位兄弟的看法，我们目前也是一使用 AI 快速搭建接口和 UI 的自动化。同时使用 AI 来完成各种专项，比如容灾测试、性能测试。还有一些其他的提升效率的比较散的地方。比如利用 AI 的总结能力去快速地理解需求文档，利用 AI 的能力快速完成一个调研行动。很多时候，来了一个任务没有什么特别好的思路，问问 AI 可能很快就能够把这个任务完成。我这里的更多的呢是在接到一些新的需求的时候，里面会涉及到一些我不懂的知识。尤其我在做这种技术型产品的时候，经常会遇到这种问题。用 AI 呢，我就能很快地去学习了解这方面的知识，并且拿到一个很好的解决方案来进行测试。 总结一下，就是多利用 AI 的能力来寻找方案。

有些时候，一些不起眼的地方，提升起效率来也挺夸张的。你比如说测试用例的编写，用传统的方式去写测试用例，花的时间很长。我们假设要编写 100 条测试用例。如果说要编写的相对比较详细一些，那么这 100 条测试用例的编写工作可能就会耗费一天时间，甚至更长。但用 AI 来去写的话，可能就是 10 分钟之内的事情。即便说你没有很好的知识库，让它自动探索出很好的用例。但我们就用人力来去编写测试点，然后让 AI 去生成更详细的步骤。这也是效率的一个很大的提升。

开发人员用 AI 编写代码带来的最大的问题就是质量会更差。起码现阶段是这样的，很多开发同学还不得的用 Harness 的理念去设计 Agent，所以导致出错的概率比较大。所以呢，我们为了解决这个问题需要利用 AI 来去快速地生成大量的自动化测试用例。我们现在公有云的门禁的运行时间，就需要跑 5 个小时了。这是大量的自动化测试用例积累的结果。基本上这个门禁能跑下来。产品的质量问题就不会很大了。

挑点活跃的新人出来当管理或者版主啦，去年又说要选点新人。不过时间点过了，估计有兴趣的也不多了

主要是用于生成测试用例，以及探索 UI 自动化方面的可行性

你应该庆幸，AI 还没在开发团队产生质量优化的效果。其实这一点的问题很容易解决，特别是你自己以测开的角色去做工具的开发和自测的时候你就能发现并解决问题，并将这个 skills 优化到团队里面。但是我目前是更倾向于还是迭代的慢点，给人留一条活路吧。反正我自己开发工具现在的开发质量是直线上升了，就看你们业务团队是否也去这样做。

请问下你们的测试用例生成是如何提升准确度的呢？
我们现状是：没有人做业务知识库，直接喂需求文档给 AI，他输出的很多都是简单的通用型校验。
但是在增量模式的需求文档中，让他生成一个有点复杂的业务逻辑，很多都是在瞎扯了。
是不是在生成接口测试用例上会更加有优势？
目前功能性的，只敢用通用校验的那部分，业务逻辑的都还是自己写，但是加上调教的时间，感觉并没有提效多少。

想要 AI 效果好，知识库必须要好好积累。 这个知识库不仅仅是业务功能文档，还有设计测试用例的方法论和你的产品的测试特点。 比如在我们的产品里，如果模型广场里新增了模型，或者动了模型的逻辑。 那需要遍历到整个产品里所有跟模型有关的功能点。 所以在我的知识库里，专门有个文档是记录所有与模型相关的功能点，并在 skill 里告诉大模型，在这种情况下一定要遍历这里的所有模型相关的功能点。 而如果是涉及到前端的逻辑，知识库里也写好了各个模块的前端交互的流程，并且在 skill 里写了工作流， 就是识别到跟前端有关的操作。 要反复向用户确定是否有 figma 的交互稿，如果没有，设计到的输入框是否有字符数的限制等问题。

同一个模型， 不同的人用的效果天差地别，就在于使用的 “人” 是否有耐心，愿意去学习如何跟 AI 打交道。

请问一下飞哥, 知识库怎么累积呢?只要把测试用例和需求都放进去, 然后写一些注释,分类索引一下?
有什么技巧吗?

首先用例和需求肯定是要积累成一些文档的， 然后生成 case 的方法论和产品测试要点也要有。 再然后你可以搜一下 harness 的设计方法论， 这个方法论是能让 Agent 稳定高效运行的方法论，按这个思路去设计。如果你觉得 harness 太耗时或者太废 token， 那你也可以单纯遵循 “渐进式披露” 原则， 先写一个生成 case 的 skill 出来试试看。 你可以搜一下我提到的这几个设计方法。

但是没有人想一下功能测试过程中耗时最长的是测试执行吗？ 测试用例固然 AI 可以辅助生成（目前我司也实现了），但是实际过程中不写用例的公司也大有人在，对于 AI 辅助生成接口自动化脚本（其实接口也是体现的接口底层的逻辑，对 AI 设计的接口场景能否覆盖底层逻辑存疑），和 ui 自动化脚本，但是这些都不是能够解决【当前迭代】的问题，题主问的是 “目前开发的 ai coding 目前提效很好，原来开发 3 天 测试 1 天， 现在开发能在 1 天完成，测试如何在 0.3 天内把这些东西测完，测好的问题”，我在各层楼的回复中没看到有效的解决方案。

想了解测试执行的这一步，想知道 AI 如何替代测试人员在测一个模块时，构造出的多种测试场景（包含复杂造数，不同的交互逻辑等等）AI 如何执行

以目前的 AI 能力，基本替代不了测试执行，基本还是人的测试执行效率会更高
大家提供的思路主要还是说如何用 AI 去提高项目质量，实际题主主要问题是 bug 从 100 变成了 300，可能用 ai 介入后，一些逻辑上或者代码风险上的的 bug 就能快速发现了，但是如果说是这多出来的 200 个 bug 都是显示上的问题，实际 AI 很难发现

月均 100 左右到月均 300。领导问怎么还没上线，答：开发的 BUG 没修复完，现在的质量不满足上线条件。不就搞定了，如果非要上线，那就把风险抛出来，然后由领导决策要不要上线。

这个真的是痛点，抛开用例设计，造数据，接口测试（如果时间允许可以左移），目前最大痛点还是在执行测试方面，特别是需求并行提测的时候，这个实打实的消耗时间，ai 没法很好介入

我觉得测试执行是 ai 最好做的，可控也可监测。不像用例生成，生成的好不好完全需要人再审查一遍。好的用例才是一切测试活动的开始……

目前测试执行的不好关键的问题还是用例生成的不够精确 + 没有对应数据构造能力。
用例生成不够精准体现在：“xxx 数据正确存入数据库” -------数据详情是什么？数据库是哪个库哪个表？
没有数据构造能力体现在：“生成一个 xxx 类型的订单 ，之后修改这个订单的 xxx 信息” ----------有对应的数据构造能力么？
除了用例生成不够精确外，数据构造能力是可以建设解决的。

并不是用例执行 ai 做不到。而是生成的用例执行性太差了。
比如
用例描述 “在商城页面点击商品详情，加入购物车后使用优惠券结算” 人看没啥问题。直接交给智能体就很难有效执行。

需要翻译成：“在 http://xxx页点击 xxx 元素查看商品详情，等待跳转完成后点击 xxx 元素加入购物车，再点击 xxx 元素输入商品数量，再点击 xxx 选择优惠券，再…，最后验证 xxx 数据的 xxx 字段需要为 xxx 值”

这只是用例的一个细节，全量的转换难度可想而知，目前 1M 的上下文根本扛不住…

确实是这样，你让智能体执行，写的需要非常详细清楚。即使是这样有时候他还是会找不对地方然后自己探索发挥，乱操作一气，这点就很难受。另外使用智能体执行测试用例也很费 token，给我的感觉是可操作但目前可行性有点低。

我说的执行是 ui 层面的测试 T=T，我们系统涉及 web 和微信小程序还有 pos 机