是的，我们也很奇怪为什么会是这种模式，就真的也测的很痛苦。说不好听的，就是在这里积攒的经验，出去其他地方根本用不上。而且现在时间太紧张，简单通用的什么新增删除审核啥的，有特殊说明的才写一下，更多都是业务逻辑是重点。可是业务 AI 又生成的不好，真的很纠结

有个疑问，就是需求前置拆分这里，这个正常来说是写用例之前自己思考的。
但是如果跟 AI 进行沟通的话，可能就需要前置说明很多关联业务逻辑。
我们可能很明白这个流程用例里为什么需要包含 3 个单据，但是 AI 如果不告诉他前后关联的话，他基本上不会理解
可是如果每次都做这个事情的话，那浪费的时间就相对较多
这部分能够通过知识库来解决吗？

其次就是，写用例的时候我们需要跟产品沟通很多细节，这部分很多时候是不会更新到需求文档里的，只能靠测试自己去当时就补充到测试用例里
而如果是跟 AI 沟通，这部分反而有可能会被遗忘，但是如果让产品去更新需求文档，那么时间耗费的更多，这部分一般是怎么解决的？

关于提示词模板，这里我不太明白具体是指什么
因为我们的迭代需求有可能是完全不同的模块或者是新增的功能，提示词模板这种真的具备通用性吗？

关于这个现有用例喂给 AI 这里，有个问题，就是我们的产品迭代了很多版本，很多功能都改变逻辑或者是被取消了。
测试用例如果是以前的版本也以前喂给 AI，这不就会出现业务逻辑打架的情况吗？
但是如果一个个去跟 AI 纠正沟通，那时间成本也很高
我们也想要搞知识库，但是操作手册也是乱七八糟，且 token 消耗巨大，感觉也是同样卡主了

感觉全流程测试点这里很难写清楚呢
关于长业务逻辑的，如果是我自己写用例，我只需要补充前置条件 + 步骤和结果，只要不是新人，大概都能依葫芦画瓢就明白要干啥了
但是喂给 AI，好像还需要把整个业务都给他讲明白，他才能理解我为什么是这样的组合模式
可是目前我们没有建立自己的知识库，需求文档基本都是增量的，换个新人开发，问题都不少，AI 生成的用例也是同样的问题，调教的话，也很难有复用的情况
这种是不是还是要先建立知识库，才能够改善？
（PS.没有前后端分离，所以基本上不做接口测试，而 UI 自动化维护很麻烦，主要精力都是功能业务的测试，总觉得提效真的好渺茫）

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

为什么上传的需求文档是 excel 呢？目前大部分的需求应该还是用 word 写吧，感觉会有大量的图片和文字才能够描述清楚需求，我们组的需求文档，每次都很长。excel 大多数用来进行任务拆分的简析说明，好像不能算具体的需求描述了

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

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

请问复杂业务场景是怎么训练 AI 的，这部分的前期投入大吗？
需求文档全是孤立的，且很多功能都是在反复改来改去。没有整合过一份完整的。
之前公司搞过一个 AI 用例生成，但是把需求文档扔进去，解析出来的用例也就是复制粘贴文档里的文字。
几乎没有什么智能化的提炼。甚至文档里有前后矛盾的逻辑，错别字啥的也都一并照搬了
没有接口文档，接口用例都是自己抓包或者是用录制的办法搞的。
想要让 AI 介入感觉都是一头雾水
这种是不是要先补前面的债再逐步推广 AI 介入比较好？

用我们领导的话就是：XX，你是项目经理吗？不是的话，你为什么要管这个事情

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