其实生成单接口的用例还是蛮简单的，就是生成基于场景的接口用例。这块知识库应该如何建立，才能让大模型在现有的自动化测试框架上生成用例。
我的想法是，但是第二步效果不太好，很多步骤关联不上，或者断言只有最基本的 code 和 msg 断言
1、根据需求文档生成测试点 + 生成测试用例，然后生成基于场景的测试流程。
2、大模型读取场景的测试流程然后分析前后端开发代码，将场景步骤转化成对应的接口调用链、以及断言
3、然后拿到第二部的产出文档，按现有自动化框架规范生成脚本
4、让 AI 自动运行并修复

就是把测试用例转成接口自动化测试用例，如何正确的建立映射关系，不需要让 AI 分析开发代码然后让功能用例正确的映射接口？或者说没有完整的接口文档的情况喜下，直接让 cursor 工具读取需求和功能测试用例后反向分析开发代码来生成接口用例

大佬，这 “把测试用例转成接口自动化测试用例” 这个场景，有拿着需求文档和测试用例给 AI 分析开发源码将接口与功能用例进行映射，然后以接口维度分析源码相关功能点生成接口用例么？

让 AI 分析服务端代码，并生成对应接口链路关系。然后将功能用例前置和步骤语义转换为对应的接口步骤，是不是效果就会好一点

只要工资 ok，外包也能接受了。

武汉找工作这么难么，还想着回武汉呢

https://github.com/wintests/pytestDemo 应该是跟这个比较像，因为我最开始按照这个去调整的，后面觉得调用链太长把 api 给砍掉了，operation 我觉得每个接口一个方法很重复就直接封装 post、get、put、delete 四个方法适应所有 method 方式的接口。不过在 testcase 类是一个接口一个方法，yaml 不用指定 method,因为在 testcase 的方法里是知道该接口的请求方式，直接调用 operation 封装的方法就好，至于 path 放 yaml 或者 testcase 都没问题，放 yaml 是为了完整性，因为框架写好了，最多的工作还是在写 ymal。

这里可以优化成维护对应的 post、get、put、delete 的四种类型 API。至于每个接口加密，可以写个通用的加密方法，让 api 调用

写在一个类中不同 test 方法里，然后每个方法执行完成后恢复到初始页面。如果是同一个账号的操作的化可以把登录放在前置中只执行一次就好。