AI大模型功能测试用例生成

prd---llm【结构化抽取功能卡片】----确定规则(业务流程、边界、安全、端到端。。。。。)---llm【用例生成---规则检查【功能卡片+规则】---调整补充修改--自动审查清单(减少人工核对的工作量)
【结构化抽取功能卡片】---测试用例的身份契约(就是提取出每个功能点)
如登录 3.5.13，就是登录的唯一id
文档结构化---切文档(按照什么切？图和表之类需不需要提取内容)---功能点初步提取(提取哪些内容、推测项处理)--深度抽取(输入输出、业务规则、流程状态、异常、前置条件等)--溯源(检查抽取的内容是否都有原文来源)--避免冲突(避免规则冲突，提出疑问点)--换模型互查，这步很重要，如果功能点有遗漏、重复，生成用例的时候也会出现这些情况。
登录--需要了解这些(输入输出、业务规则、流程状态、异常、前置条件等)，要不然生成不出来。
文档结构化的目的是抽取核心-避免遗漏、重复，业务规则完整。到这步所有的测试点都已经提取出来了，接下来该设计哪些方面的功能用例了：
测试点的推导(并发进行)----功能用例的设计原则(幂等、原子性、一致性、边界、业务流程、状态、e2e、异常处理等)---生成测试点 ；
幂等：重复请求，结果只生效一次
原子性：事务内操作，要么全成功，要么全回滚
一致性：业务规则始终有效，数据合法
在功能用例的设计原则这里测试用例就已经设计好了，每个测试点是否要做幂等、原子性、一致性、边界、业务流程、状态、e2e、异常处理等测试，如果做就设计出来，不做就不用生成。
case的生成(并行)----llm【模块/功能点切片内容、测试点、经验(参考测试用例、历史测试用例、反例、模板)】----生成测试用例---校验(模糊词扫描、依据绑定、语义相似度校验)--换模型进行p0case生成然后比对---落盘
这里大模型就是进行用例填充，按照模板来填充，根据大模型里传入的这些生成测试用例。
测试用例生成完之后要进行检查，把预期结果里模糊词扫描出来，让大模型重新写或手动修改；
依据绑定是怕大模型产生幻觉；
语义相似度校验就是用例生成后，跟用例清单对的时候发现语义相似度很低，生成的内容不是特别相关，生成的用例也不特别准确，也属于幻觉。
换模型进行p0case生成然后比对，有这步更好，p0case比对，看生成的是不是一致，两个模型对需求理解有不一样的地方，可能需求哪里写的有歧义，导致两个模型理解的不一样，好处就是double check，坏处就是慢，又加了个大模型，就相当于使用两个llm的apikey，哪个生成case，哪个比对。
校验与去重-----去重，可能有重复的用例(多模块跨模块间描述不同但语义相同的用例)---有测试点无用例--格式检查(看模板的格式是否一致，是否按照模板去填充的，用例id是否是顺着的，因为有用例去重)---llm(只处理有问题的测试点)，因为上面是并行的，所以又做一次去重。

用例生成的流程：
在cursor里输入新建一个基于需求文档生成功能测试用例的空项目目录，目录生成后切换到plan模式，输入设计一个基于prd生成功能测试用例项目，基于设计原则是传入prd后，基于prd做需求结构化，需求结构化步骤为：文档机构化-功能点清单-功能点深度结构化(抽取输入、业务规则、流程、状态变化、异常处理、预期结果等以及溯源引文)-溯源校验-冲突校验-换模型互查，先与我澄清需求结构化的需求结构化的需求和设计，生成如下图：

勾选B，点击Continue，生成如下图：

点击Build，输入先澄清需求和设计细节，不要开始写代码，生成如下图：

输入每个问题单独进行交互式问答让我选择，生成如下图：

H3就是md文档里的三级标题，带三个#号的就是H3，也可以按照H4，根据prd的需要做，输入B，点击发送，生成如下图：

输入B，点击发送，生成如下图：

输入C，点击发送，生成如下图：

输入A，点击发送，生成如下图：

输入B，点击发送，生成如下图：

输入B，点击发送，生成如下图：

输入A，点击发送，生成如下图：

输入A，点击发送，生成如下图：

在cursor里输入
继续进行下一步的设计澄清，需求结构化完成之后，进行测试点的推导，测试点推导需要每个功能点按照测试规则生成推导的测试点，每个用例带id、推导来源、优先级和依赖，测试规则包括边界值、异常处理、交互-流程+状态变化、E2E、幂等/原子性进行生成，这一步可以采用每个模块并发推导加快推导速度，最终进行汇总+依赖链排序+每条测试点分配确定性，该阶段门禁需要保证每个功能点至少一条以上测试点，每个规则都有出口，生成如下图：

点击Build，跳转到这里，如下图：

3个待完成的步骤一个一个实现了，生成如下图：

在cursor里输入需求结构的需求和设计文档落下哪了，输出如下图：

继续输入全部写入一个文档，点击发送，生成如下图：

点击Build，跳转到这里，如下图：

3个待完成的步骤一个一个实现了，生成如下图：

如果prd里加了一句话需求，需要调一次知识库，输入需求结构化的时候需要调一次知识库类，获取历史prd该功能点的具体描述，切换到Plan模式，生成如下图：

输入Q1-A，Q2-A，点击发送，生成如下图：

点击Build，跳转到这里，如下图：

然后输入第三步是进行用例的生成，用例生成先传入每个功能/模块的正文切片+第二步生成的本模块测试点清单+知识库注入(反例、历史用例、参考样例等)，然后结合提示词生成结构化的测试用例，用例生成后做可判定性检查(模糊词扫描、依据绑定、语义相似度判定)，然后在调用另外一个模型进行独立编写用例和预期结果进行对照，对分歧点列入观察清单，第三步门禁是可判定性=100%(模糊词0逃逸、证据绑定100%、语义相关100%)，生成如下图：

点击Build，有3个Todos要做，如下图：

To-dos完成后，生成如下图：

继续输入第四步进行合并输出，按照依赖链进顺序合并--规则去重--llm语义去重，去掉跨模块间表述不同但语义重复的用例，e2e用例单独步骤生成，生成时候要进行格式检查以及遗留检测(测试点无用例、用例无对应测试点、证据引用失效、内容一致性等)，点击Build，生成如下图：

3个To-dos完成后，生成如下图：

第三步模板忘写了，输入第三步生成用例时候需要按照用例模板生成，生成如下图：

点击Build，3个To-dos待完成，如下图：

3个To-dos完成后，输入加上记忆能力，记录正确的用例生成方式和错误的用例生成方式，便于在以后生成时候做参考和指导，生成如下图：

回复C，点击发送，生成如下图：

有3个To-dos待完成，完成后，如下图：

到这里需求就完事了，然后整体看一下，输入@流水线设计.md    不是传入一个md格式的prd，prd格式大概率是word文档，文档里的表格内容需要进行提取，当做功能点深度结构化的一部分内容，在整体看看这个需求和设计是否有问题，生成如下图：

在cursor里输入同意，并在文档里加上一个详细的流程图，生成如下图：

详细流程图不是特别符合预期，输入流程图改成架构设计流程图，当前流程图不方便看设计和实现是否合理，生成如下图：

还是不符合预期，输入流程图改成人阅读性强的方式，第一步做什么，产生生什么，第二步、第三步，都用中文描述，生成如下图：

输入@测试用例模板.xlsx  用例模板按照这个模板进行生成，生成如下图：

输入需求基本确定，基于需求文档进行架构设计，架构设计单独写入新的文档，生成如下图：

点击Build，两个To-dos待完成，如下图：

To-dos完成后，输入增加一个日志路径，记录每步过程产物、输入、输出，方便溯源，生成如下图：

输入基于需求和设计，进行代码生成，生成如下图：

输入llm全部用cursor本身路由即可，@heading_map.yaml @pipeline.yaml   文档里加上中文说明，生成如下图：

输入基于   商城前端产品需求文档_PRD_v2.md  生成测试用例，生成的用例质量很差，因为没有调用大模型，输入调用当前cursor生成测试用例(前提要知道cursor的apikey)。
prd--文档结构化---提取功能点【知识库(历史prd、历史case)】----功能点的测试点-----llm生成case【知识库、记忆】，最重要的步骤是prd结构化，这一步做不好，后面抽功能点就不是很好，功能点抽不好后面一连串效果都不好。基于功能点生成测试点，测试点完全是规则，要做哪些测试。

生成的用例需要优化，首先是优先级，高/中/低或者P0/P1/P2/P3，高/中/低要定义好，有的公司是主流程的优先级高，让开发拿着跑冒烟测试。P3的用例就会少一些，其次就是还没做知识库、记忆库正负反馈飞轮，正常应该在项目里建起知识库和记忆卡，因为是新项目，没有历史prd、历史case。

1、prd文档的结构化(结合自己公司prd格式和排版以及质量)   
2、知识库(如果公司有就用公司的，没有就用第三方(阿里云)或自己搭建一个知识库)   
3、正负向case反馈