可以的，是下一个版本的 feature

什么思路

正如 todo 所说，目前每次同步接口文档，没法感知到版本迭代变化，所以在考虑做一个迭代时的可视化 schema diff 精准定位变更，然后对用例影响范围和用例迭代变更可能还是需要人工介入判断（自动推导用例层的变更可能需要花点功夫，目前还没细想，may be AST or AI?），同时用例层的设计还是要有足够的分层抽象，降低变更影响。

单接口或者场景串联都是可以的，标准化积木有了，怎么搭都可以

我这边主要的场景是将项目的自动化测试打包为镜像，实施团队在部署新环境后，可以快速启动自动化进行环境验收测试。

私以为测试平台的核心价值是 “数据度量”，而不是一个 web 版的 postman。

如果是 python，即使是测试平台，底层的自动化测试引擎终究还是 unittest 和 pytest 这俩单元测试框架吧，难道自己造了个轮子？

为什么要在平台上写 ui

开课吧高飞老师，迫切需要这块的（AI+ 云原生）体系化学习~

啊？现在红线都缩减到 30 岁了吗..

excalidraw

群里提供了 demo 项目

升级到 2.4.2

高飞老师，k8s+AI 的应用，如 kubeflow 啥时候能讲讲，我看书里讲到和大数据的结合就没了

永冬之地

大可不必面向小白编程。。在我们这平台负责自动化可视化的数据度量和一键调度执行，至于自动化 case 的编写还是回归硬编码

aomaker 了改一下

windows 有个编码 bug，v2.4.2 解决了（暂时还没发），也可以加我 v 先发你离线包

明明可以直接写代码，就硬要整一层 yaml 转换。

需要更多信息，在群里吗？
“数据驱动时，yaml 里面可以写断言不” -- 可以，只要在 yaml 里定义好预期就行

用 pw 最好用它提供的定位方式，css,xpath 是最后才考虑的，这个用 get_by_role 应该很容易定位

ao 就是对接口的抽象封装，这一层抽象里包含了这个接口的前置（依赖参数提取）和后置（异步处理），可以看作一块积木，场景用例无非就是不同积木的组合。
其中，@aomaker.dependence，就是这个前置，是用来标注这个接口的需要哪些依赖参数的。
举个例子，比如一个创建集群接口，输入参数需要依赖一个网络 id 和存储 id，而这两个 id 需要对应的查询接口来获取，那通过@dependence就可以标注出这两个查询接口，当调用创建集群这个接口的时候，自动去查询、自动去提取出网络 id 和存储 id 这两个依赖参数注入到创建集群的请求参数中。
那问题来了，如果并没有创建网络和存储，那压根就查不出来，那就无法创建集群了？这种情况，从业务层面来看相当于有一个隐藏的前置条件，就是如果没有网络和存储，得先创建。那针对创建集群这种可能会高度复用的场景，可以单独抽象一层业务层，这里的逻辑包括：调用网络和存储的查询 ao，检查是否已存在网络和存储，如果不存在，调用创建网络和存储的 ao，然后再调创建集群 ao。
不知道通过这个例子能不能解答你的疑惑。

这没用例执行呀。。

看下代码

这应该是你没装 allure 的客户端，如果是的话，看下楼上的回复