我们用官方的 docker-compose 安装，好像没啥问题。

倒是后面改为实体机安装，费了不少劲。

好奇问下，dubbo 的传输协议，本身就支持 http 的吧？而且这个内部配置对 rpc 调用来说是无感知的，是否有和开发沟通过，测试环境切换为 http 协议，方便测试？

https://dubbo.apache.org/zh/docs/v2.7/user/references/protocol/http/

这个真的没能想到什么通用的标杆，只能说句正确的废话：能提高测试效率的就是标杆。

建议可以先去业务团队做几个迭代测试，自己记录下自己觉得低效的地方，也和团队聊聊看大家是否也是相同的观点。如果有共同点，把它工具化、平台化就对了。举个我司的例子：
1、每个迭代的用例，用 git 仓库管理，容易更新不及时和遗漏——搞用例管理平台，统一管理，在线更新
2、每次发版都要跑 monkey ，但 monkey 对环境要求比较高，很多时候跑起来还得一个人调半天环境——搞个内部云测平台，一键选设备跑 monkey

有没有搞到 100 分不重要，只要这个功能是大家需要的，大家也喜欢用，那就没问题了。

我的理解：

1、流程化和标准化其实都很重要，也有不少 devops 的文章有提及先标准化，后工具化这样的顺序。但实际做起来，成本高、见效慢、不可控因素太多，要真的做好需要天时地利人和，特别是上级领导的协助。而且很多时候测试团队在研发团队地位并不算高，自己的活都没能做的非常出彩，这时候去推动外面改变基本是不大可能的。所以做得好的相对少，做得好且大家看得到的更少而已。

2、流程化，标准化的工具却渐渐式微，我觉得只是这方面工具不再是由测试来做而已吧？tapd、jira、云效、teambition、乃至禅道，都挺多团队用的呀。只是这方面的理念这几年好像也没什么大变化，所以这些工具不管新老，用起来觉得合适就继续用下去了。

3、不用标准化的流程，不用测试计划、测试报告 这个，我待过的一些互联网公司，测试计划和测试报告确实有时候会省略，但只是不记录为正式文档或邮件，过程中还是要有计划（或者叫测试排期，确定测试内容，根据资源给出预计测试时间）和报告（或者叫测试结论，先说是否通过，然后说风险）的。至于标准化的流程，不知道楼主所说的标准化流程是怎样的？

想了解下，你们 gitlab ci 的 runner ，是运维管理还是测试管理？两个部门怎么分工？

我们之前用 gitlab ci 的时候，因为 gitlab 是运维管理的，所以 runner 也是运维管理。有些时候要装别的插件什么的或者出现本地无法重现的错误，都需要找运维协助，比较麻烦。后面 runner 迁到我们主机后，会好一些。而 jenkins 就是我们自己完全管理，相对方便一些。

这个是用 gitlab ci 取代 jenkins 完成部署和测试任务的触发？

只用过 gitlab ci 做一些组件库的自动测试和发布，没试过做镜像构建和部署之类的。用起来方便么，有没有什么坑？

好奇问下，你持续执行了多久？

我们刚接入云真机 ATX 的时候有测试了一下 wda 的持续运行稳定性，大概持续执行自动化 2.5 小时左右就会扛不住，提示连不上，得重启才能提供服务。配合 tidevice 的 wdaproxy（自动监听 wda 是否挂了，自动重启）可以做到自动重启。

但也见过有的手机死活重启不了 wda ，tidevice 一直报 socket 连不上，必须手动重启手机才能恢复。

看下你电脑是不是有别的程序会自动启动 adb ？可以看看进程列表里有没有。

jenkins 的 pipeline 可以控制多节点（前提是你有多节点）跑任务，但没法细到用例级别吧。

建议用 pytest ，匹配度最高，也简单（用多线程，比多节点成本低）。

你用的哪种证书签名的？
这个错是 iOS 系统给的，不是 macos，和钥匙串无关。能打出包就和 macos 没什么关系了。

确实是个 bug ，已记录 issue 。得周末才有空看了。

1、iPhone 是装上了 wda 但不能启动，还是连 wda 都装不上？
2、装上了不能启动，iOS 系统日志里应该会有更详细的错误信息，是否有抓取查看过？（用 mac 自带的 控制台 ，设备悬着那台 iOS 设备，就可以看到了）

模拟器相比真机，一些校验是会被省略掉的（比如应用签名校验），所以模拟器能起来，说明程序本身没问题，出问题的应该是在你的配置上。

你修改下你的正文吧？你的问题不是要怎么去做自动化，而是你觉得你现在的方法不大好，想看下有什么可以优化。

可以把你现在用例怎么写的，也举个例子说明下吧，要不不知道你用的方法和大家理解的是否一致。

同样后台搜索不到。 @Lihuazhang 有空看下？

iPhone 上面已经有 webdriveragentrunner app 安装了，但是好像无法启动？

看下 iPhone 的日志输出，看有什么报错？

另外，你用 xcode 界面启动 wda ，有启动成功么？（启动成功会看到在 running ，并且 xcode 底部有应用日志打印）

额，不至于吧。自动化的我看你问自动化的问题，应该已经有基础了。至于说清自己测试业务核心接口背后逻辑，问下开发应该也可以问到。

加分项不用关注那么多，基本要求才是核心。

直接写接口调用去调？grpc 可以直接根据 proto 文件生成不同语言的调用函数吧。

可以看看：https://testerhome.com/topics/28953

社招的基本要求是有一些自动化/写代码的经验，熟悉自己测试的业务，能说清自己测试业务系统核心接口背后的逻辑（类似技术方案里的时序图，先到哪个服务，后到哪个服务，服务间用什么中间件传输等）。能 review 开发代码，或者有做过工具平台有自己思考的，会是加分项。

现在还在招聘中，有兴趣可以直接投递简历给我哈：chenhengjie@lizhi.fm

这个不大方便那么公开说。。。

目前了解到的一些公司，提高设备使用率的方法基本都是把使用频率较低（比如机型用户量不大）的放到平台上，通过平台借用，减少大家手上长期持有测试机的数量。

以前大会也有听过直接在测试机安装 app 或者某个底层服务，只要网络连通，就自动连上云真机服务端随时用来跑自动化的，和你这个思路接近。实际用起来效果怎样，不大了解。

当然这只是我自己的思考，没有实际实践过，不确定是不是这些问题是否会这么突出。鉴于技术上是直接可行的，你也可以小范围试验下，看看效果？

有几个点想确认下：

1、你说的 windows、mac 上没问题，是这两个系统上的 jenkins 没问题，还是纯粹这两个系统上普通用户执行命令行没问题？
2、跑下 npm list --depth=0 ，看下你实际 npm install 装了哪些包；也 cat package.json 看看，是不是里面定义的 dependencies 都装上了？
3、可以把你没问题环境上的 npm install 和 npm list --depth=0 输出日志也补充上来，对比下有啥差别？

从目前日志上看，有两个比较特别的点需要留意，但需要先确认上面几个点：

1、npm install 没报错，但装的包有点少，才 6 个（added 6 packages, and audited 3909 packages）。一般前端项目应该不至于只有这么点依赖。
2、编译报错里面，除了少数是外部依赖（如 React），其他大多是内部依赖（如 /var/lib/jenkins/workspace/t/src/pages/TrailUser/register in ./src/.umi-production/core/routes.ts）。不确定是不是路径解析时根路径不一样或者别的原因导致。

你这个不解决稳定性问题呀。

举个场景：
张三在 atx 上用李四的华为 mate 10 测试，刚操作完一个用例正在登记 bug，李四刚好也要用，反正设备在自己手上，看起来也没在动，直接拔掉自己用了。张三登记完发现设备没了，没法继续用。

如果你是张三，来一两次这样的场景，是不是会放弃用 atx 而改为直接去借手机？

从设备拥有者角度，也有几个问题要解决：
1、怎么标识啥时候我想共享，啥时候我不想共享而是自用？这个标识方式尽可能要自动，手动总容易忘记。比如息屏时间超过 5 分钟自动进入共享模式。
2、共享到退出共享的这个时候，怎么通知拥有者现在有人在用，暂时不要退出共享，需要找使用者沟通？

个人更建议，可以直接收集一波日常使用率不高的设备（比如一周也就用 1-2 次的），统一放到云真机平台。谁要用都直接上平台用，这样可能更简单有效。

建议你趁着现在想法还热乎，抓紧时间看看 httprunner 的设计思路和试用一下吧。消化掉 httprunner 应该能给你带来不少新的想法思路。

很多框架毕竟不方便完整开放，有些设计思路不方便说得太直白，或者不一定通用。既然你已经找到了 httprunner 这个不错的学习对象，而且李隆也有在自己公众号持续分享整个过程中的设计思路和思考，先赶紧学起来吧。

先在无头浏览器里截个图看看界面和你正常打开有啥不同吧？

思路可以，技术上也可行。只是难点是怎么保障稳定性，毕竟每个 provider 控制权在每个人手上。

稳定性保障不了，这个借用方式可能很快会被放弃。