大家的自动化用例来源是什么，我们公司是手工用例翻译为 python 代码，一个脚本覆盖一条手工用例（领导这样要求的），这样做合理吗

绝不能存放在 yaml 和 excel，你可以一个接口对应一个 py 文件用例

前面我还在多接口用例集成在一个脚本内，最近想优化框架发现难度陡增，然后就一个脚本一个接口的处理了

木有合不合理，只能说参数化可以降低工作成本和维护工作量

1. 我们的用例是以 json 形式来表达，里面会包含用例描述、用例优先级、用例编号、用例入参、用例断言等相关信息。如果你觉得用例有必要做参数化处理，你就考虑把用例单独拎出来存放，大前提是这些用例共享同一套运行逻辑，或者框架能很好解读用例并执行；否则就是在增加无效工作量，尤其是用例数量不多时（比如只有两位数）
2. PO 模式，自行百度。建议结合用户操作视角，以及业务聚合视角一起来分层。比如一个接口是获取订单信息，这个接口的用例可能放在订单页模块下，这个模块下又聚合了订单页相关业务的上下游接口。

别想太多，先跑起来再说

先跑起来，哪里不舒服就改哪里，别怕没有设计模式太简单，能起到作用才是王道

API 测试 可以参考 flask 蓝图
用例编写 - 发布运行 - 结果自动保存
(对上可以汇报为: 自动化测试平台化 )

语义化关键词驱动的用例，存在数据库里，一条记录就是一个用例，包含名称，前置条件，步骤，预期，及其他维护字段

做一个自动化平台，写数据库里

我是把接口不同方法封装成 py 文件，然后把接口相关信息抽离到 execl，用着还可以啊！ 所以你们说的 execl 缺点是什么？

1、存储一直用的 excel，也尝试过使用纯文本的 yaml 或 json 一类存储，但是编辑效率比 excel 低太多了，只能作为项目配置文件。数据库也可以，不过同样是二维表结构其实和 excel 也没有实质上的区别，而且还要维护前端。

我个人感觉，excel 最主要的问题是二进制文件版本管理时不方便比较历史差异。其他方面都还好

2、层级多可以使用 文件目录 - 文件-sheet 页 - 自定义字段来区分

华为的机器视觉部门的自动化用例也是直接把手工用例翻译成 python 代码

写多了用例脚本耦合模式就知道数据驱动的好
写多了数据驱动就知道关键字驱动的好
写多了关键字驱动就知道 po 模式的好
写多了 po 模式就知道智能维护的好