其实生成单接口的用例还是蛮简单的，就是生成基于场景的接口用例。这块知识库应该如何建立，才能让大模型在现有的自动化测试框架上生成用例。
我的想法是，但是第二步效果不太好，很多步骤关联不上，或者断言只有最基本的 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 方法里，然后每个方法执行完成后恢复到初始页面。如果是同一个账号的操作的化可以把登录放在前置中只执行一次就好。

向我这样使用绝对路径试试

感觉武汉的行情也不好啊，失业一个月了

使用 mitmproxy 可以实现

应该是使用 setatter() 和 getatter() 进行存储和获取吧

1.接口文档中接口命名和入参出参字段正确描述
2.接口入参和出参只显示需要的字段，不需要的移除
3.针对添加接口，响应体最好返回该条记录 ID
4.有添加接口，一定要有删除接口
5.针对 post 接口，响应体 result 返回受影响行数或者相关更新结果，不要只返回 null
暂时只想到了这些

可以提一些接口输出规范

看看这个框架是否满足你
https://github.com/94louischen/test_api

不需要为了参数依赖，每个接口写一个 case 吧，可以把参数依赖写一个通用方法去处理
1.用例执行完成后，使用 setatter() 把依赖参数存在内存中。
2.把需要依赖的其它接口的字段用形参替代，然后在请求时使用正则提取相关形参并使用 getatter() 进行替换。

我是直接从 Windows copy 过来直接打开的，应该不用设置啥吧。是 1 楼说的那个原因

这个不是入口，只是单独运行这个调试一下。也只能用这个方式了 sys.path.append

学到了，下次写清楚点

先了解一下微服务架构其中前台和中台是干嘛的，再去分析问题。第二题我也不会，我还傻 XX 的以为是前端通过 js 实现的 笔试其实就 20 分钟，写没写完都会进入面试

哈哈，能说出大概就可以了吧

明白了，谢谢大佬耐心指点。我决定还是在公司先沉淀一下了，还是太菜了，这么一说感觉没啥拿出手。一心想着怎么搞自动化，其实没有去想怎么用技术解决问题和提效，只是浮在表面，人家稍微问点架构方面的知识就懵了