问答 封装 playwright，写了一个 UI 自动化平台，有一些问题想问问大家怎么处理
首先介绍一下我的平台
如图，平台分为了 3 层：
piece 层：一个点击（输入、keyword）操作 + 一个等待某元素加载（或等待一个固定时间）+ 一个对元素截图（获取文案）校验=一个 piece
我称之为一个最小操作单元，不可被分割
process 层：多个 piece 合成一个 process；对一个 process 添加数据集，可生成 N 个 case
case 层：对案例执行的管理，并可查看执行结果
结果校验：文案直接做比对，图片用的 AI 做图片比对
技术栈：python+django+playwright+tensorflow+docker+gitlab CI/CD
问题：
1、执行时使用的线程池开 8 个线程跑，现在案例有 200+ 条，执行的很慢；现在在做分微服务和代码重构，以前都是一个镜像搞定，现在要把平台分为三个微服务，一个调用接口处理数据库数据，一个执行案例（跑 playwright），一个 AI 图片比对；
我想问，在多线程执行案例时，playwright 异步执行会不会比同步执行效率更高？这样分微服务是否能提高一点性能，是否还有更好的做法？是否还有其他的方法提高性能？
2、接口请求 100+ 张图片时，部分图片接口报错 502 加载不出来，图片已经是压缩图片了（一个图 5KB 左右），感觉不是网络 IO 的问题，不知道从哪里下手解决。
3、被测系统，部分页面会有通过接口做的控制蒙层、loading 状态、toast 提示，这个时候做截图校验总是会不准确；想等待蒙层、loading 状态、toast 提示结束再做截图，但是这些瞬时的元素又很难捕捉，不知道怎么处理，想请教大家有什么好的办法？
4、如图，我生成 piece 的方式，是用这样点击添加组建的方式。我现在想，可以直接写一个长串的文案，后端读取文案的关键字的方式，来自动生成案例；但是不确定那种方式会更好；后者的话我没发现明显的优势，但后期我感觉以后可以做到，直接通过 chatgpt 读取 prd 输出特定格式的文案来生成 piece。
信息量不太多，我尝试宏观给点建议：
- 同步比异步执行效率低的前提是你可以有多个操作可以并行完成，如果平台中 piece 层的操作互相独立不耦合，那肯定是异步更快。更具体的说，用例之间是可以并行跑提高效率的，而一个用例中的三个 piece 看起来似乎只能顺序执行。
- 没什么信息量，502 加载不出来可能是图片存储服务扛不住那么多 QPS 挂了，如果是这个原因而且你无法优化存储服务，你就只能考虑把图片进一步压缩，或者把多张图片打成一个压缩包去存储与读取以减少磁盘小文件 IO；又或者降低你请求的 QPS 如引入请求队列来控制请求峰值。
- 这种弹窗什么典型的解决办法就是图像识别 + 控件识别点掉。图像识别是为了识别到弹窗，但想要去除弹窗就只能去点击（除非让开发留后门或配置去关弹窗）。单一技术栈的解决办法是等待一段时间，然后控件识别是否有弹窗，有就点掉。
- 爱怎么做都行，但 chatgpt 真的免了，这玩意儿就一本正经的胡说八道，你引入这个工具要考虑到它引入错误的风险，如果能接受那可以试试。
有完整的项目么？感觉只是个初版的 demo
王稀饭
回复
我详细解释一下，playwright 支持同步和异步执行；我的平台核心就是封装好的 playwright，通过 json 调用这些封装好的函数；有两个接口可以执行案例，一个接口是调用后单独执行一个案例，用于调试；一个就是生产上，一次调用执行所有案例；问题在这个执行所有案例上，我用了线程池 concurrent.futures.ThreadPoolExecutor(max_workers=8)；
第一个问题，具体一点就是问，现在性能很差，我用的是同步调用 playwright，用他自带的异步调用会不会快点，我现在的理解是不会更快，已经放弃了；
第二个问题，图片存我们公司内的服务器上，内存/cpu/网络资源充足，但是一次性获取的图片多了，就会出现 502 报错；你给的建议我去尝试一下；
第三个问题，我所说的 loading、蒙层、toast 提示，就是那种出现一会，很快就消失的页面元素，我现在的处理是固定等待时间，但这样做显然不够稳定；我想做到的是等待这些瞬时的状态消失后，再截图；playwright 有等待元素加载、消失的方法，但显然这些临时出现的元素我捕捉不到。
第四个问题，梦想还是得有的；这个先放一边，你们觉得这两种方式你们觉得哪种好？1、用添加一个方块 - 填写内容（如下图）；2、按固定格式写一段文案
可以说说你这个平台，对比原生的 playwright 写 ui 测试的优势是什么吗？就多了一个图片用的 AI 做图片比对？
高高
回复
你可以说 playwright 录制很方便，但是录制出来的脚本往往无法执行成功的，你得调试，后期页面变了要维护，我写的这个平台主要两个优点：
1、提高案例的高可复用性 --- 多个 piece 组装成 process，多个 data+process 生成一个案例；
2、降低案例的维护成本 --- 前端页面有维护更新，只用修改一点点相关 piece 即可更新整个案例执行流程；
如果你有更好的建议欢迎讨论
有开源计划嘛，或者可否一起写 哈哈
始终觉得在这种平台上写 case 简直是折磨，效率太低太低。
大桥
回复
这个框架写好基础步骤后，process 和 case 只需要配置就好，而且这个平台的使用者只需要会 css 或者 xpath，不需要会一点点代码；
肯定没有录制方便，但录制就跟我上面说的那样，有两个问题；
1、录好了也不一定执行成功 --- 比如你等待的时间，录制不会体现出来，再跑就直接失败了；
2、维护成本很高 --- 被测系统修改之后就会执行失败；我的系统只需要修改 piece 里的对应步骤，就修改了所有应用这个 piece 的 case；而录制的脚本，每个相关案例，都需要重新维护代码才行；肯定是后者更加麻烦
目前工作很闲，也想写一个 ui 平台，但是设计了好几版 有一般跟楼主你的一样细，但是后来琢磨，我想让降低脚本编写难度 (方便公司随便一个人使用)，所以我设想了两层结构，项目 - 测试用例 ，测试用例如何编写呢。
设计的是 playwright 自带录制，然后直接转换代码，保存成.py 文件 然后在前端勾选需要执行的测试用例直接执行
第二种就是先封装 playwright 方法 然后将 playwright 生成的代码转成使用我封装后的代码，然后进行跑，跑完生成 allure 测试报告进行查看
目前还在构建