现状是目前 UI 自动化是基于平台去做的，用例是 yaml 格式在平台上进行编写，这种方式不便于查看，有新增了一个查看用例步骤的展示弹框，大概情况是这样的。
目前的问题：
1、是否需要将 yaml 格式的用例，转换成页面组件的形式进行编写呢？
2、当前 yaml 内容步骤过多的时候，自己看的都有些费劲。不知道有什么好方法去改进这块。
想了解大家对这块的处理意见和思考思路🙏🙏
看了大佬们的建议，对于当前用例编写改进
1、增加了组件用例的编写方式，ai 生成前端页面，改下了部分逻辑就能使用了，yaml 在线编写和组件编写可以互相转换使用。
2、增加了用例步骤的封装功能，针对于重复较多的部分，也是通过 yaml 文件编写成用例，在其他地方直接引用就可以了。
现在需要思考的是，公共部分封装的颗粒度问题，如何做到合适的封装还得需要用例来衡量。
| 是否需要将 yaml 格式的用例，转换成页面组件的形式进行编写呢？
建议自己权衡吧。做成页面组件，好处是可以折叠省一些空间，以及对于小白友好，缺点是可能编写和查看效率降低（比如要知道某一步的参数，还得多展开一下）。
| 当前 yaml 内容步骤过多的时候，自己看的都有些费劲。不知道有什么好方法去改进这块。
做封装呀。参照 Page Object 把页面和页面上的常用操作封装一下，这样应该你的步骤应该就少很多了。
几年前做的样式，现在普通小白用起来还蛮简单，主要做法就是元素独立维护，用例里面选择元素，动作，入参等。
封装
陈恒捷
回复
目前 yaml 文件写的方式，是通过关键驱动的，看您的回答，可以将 po 模式也能封装成事件在通过关键字的方式调用，这个思路可以试试，还没尝试过。感谢提供的思路🙏
Ayo
回复
有个问题请教下，这种方式写的话，如果一个场景的步骤有改动了，比入一个查看个人信息的入口更改了位置，是不是所有相关联的场景用例涉及到这个入口的都需要改动
个人觉得：
1.脚本能快速生成
2.快速生成的脚本能用得上一到两次
类似接口文档，元素是一个接口可以服用给所有测试用例，测试用例只要入参就行，同时也支持模块化，提取入参，那么对应的用例调用模块时只要入参就行了，拓展和维护性就会高很多 l
看了大佬们的建议，对于当前用例编写改进
1、增加了组件用例的编写方式，ai 生成前端页面，改下了部分逻辑就能使用了，yaml 在线编写和组件编写可以互相转换使用。
2、增加了用例步骤的封装功能，针对于重复较多的部分，也是通过 yaml 文件编写成用例，在其他地方直接引用就可以了。
现在需要思考的是，公共部分封装的颗粒度问题，如何做到合适的封装还得需要用例来衡量。