实际问答过程中每次给 openai 的信息都是片段的，不是完整内部信息都给出去。

从楼主的工程结构来看，这是 v2.3 之前的老版本了，该更新了。

这个看着是 108 版本 chromedriver 报错，可以用纯脚本的方式试试能正常启动 webdriver。

是的，可以的。

可以截图上面些报错，或者把日志保存到文件我看看

browsers/safari，详见：https://hub.docker.com/r/browsers/safari

是的，理解正确。核心点将通过这个代理的流量转发 + 对比。

safari 有两种方式：

1. 通过 linux 模拟的 safari 内核的 docker 镜像。 2.基于 macosx 真机多账号的管理系统（已经初步调研完成，开发中）。

能自己的车子跑起来的，就是好轮子。

似乎大家不太明白我在说啥

m1 pro 入门版，你上面的需求完全够用了。

127.0.0.1:4444 这个是本地的 selenium-grid 服务地址，这个是要先自己搭建的，并确保能访问哦。另外从 v1.1.1 开始，增加了很多可配置项，用于差异代理下的浏览器对比，yutu 的 init 只提供一个初始化后的工程，具体的配置，要手动改下 config.json，然后在 yutu start。

不能，这个是快速验证链接可用性的。具体的业务检查可以用 UI 自动化。

驱动部分已经开源：https://github.com/t880216t/yutu-tools.git
欢迎体验反馈

加群无门

能，不过不完全能，要看被阉割的程度。

上面大家说的兼容覆盖、代码逻辑覆盖自然是解决问题的有效措施，但在项目在范围、时间、成本固定的情况下，落地难度谁用谁知道。@ 今晚打老虎 总结的很好，短时间内要达到效果，可以从这 2 个本质问题入手：

1.怎么解决偶发性问题？
调整测试用例方法，分析领导这种特殊干系人以及用户的真实使用场景，针对性补充测试场景。但这只能降低大问题的出现概率，程序除了自身代码有漏洞，外部运行环境也可能有问题，没人能彻底解决，除非你有无限的时间和资源。

2.怎么防止此类问题导致领导对测试团队的信任危机?
首先应该分析出老板这出现问题的客观原因，同时从问题 1 可以看出，我们此时能做的是主观上反思并拿出态度，然后在从客观原因中划出边界、甩出黑锅。建议以产品核心利益为中心，与上下游一起，确认核心覆盖范围并达成共识，这样起码可以保证出问题的部分，不会造成太大的影响，而且超出部分出现问题，也不会说是测试一方的问题。

不是的，这是同时启动多个不同浏览器，在 chrome 操作时，其它浏览器也会实时同步操作，并可以对比不同浏览器的页面情况，最后会自动生成执行过程的自动化脚本（暂时没有用）。

是的，只是我们现在已有的 UI 自动化工具是基于 RF 关键字的用例 https://testerhome.com/topics/33179 ，这里录制得到的是 macaca 的用例，需要做个转换。

项目周期较赶，代码有些糙，梳理清晰后，会把核心驱动部分开源的。

哈哈哈，说说你的需求是啥呢。

你要下哪个插件，我这是的 firefox 的插件，虽然已经上架，但是不建议下载使用，有自己定制开发的功能。

新版本还没开源，很多是参考我之前开源的老版本的。希望也能给你些思路 https://github.com/t880216t/uat 。

可以先请求下/rest/api/latest/issue/createmeta，获取下自定义字段可选值，根据类型组装数据，之前 js 写过这块逻辑，给你参考下：https://github.com/t880216t/buger/blob/6db7698f7f9a613da31fa397c87684feaf55d96d/app/containers/AddPage.js#L121

试了下，幕布还是不错的，不过不知道限制够不够用。