这么说吧，原理上，不提供 debug 包，或者更明确说，应用包里面 webview 没有打开 debug 开关的话，那就没法从 webview 内核拿到元素树等信息，也没法操作里面的元素。

这种情况下，图像识别是目前认知里面唯一能用的招了。

如果你的 h5 功能和 app 没有耦合或者调用，那还有一种方法，你另外用浏览器单独测试这个 h5 。

用 airtest 之类的，通过图像识别来做？

好奇想了解下，一线团队忽略流程，忽略的是什么流程，他们反馈的是什么原因？

我们以前推一些流程，比较有效的做法是问题驱动。比如多次开发不经过测试评估直接上线出问题，就上线流程上改为只有测试才有权限；开发自测经常没做好冒烟不通过，就直接改为开发演示，在测试和产品面前演示核心流程可以跑通，然后直接提测，测试也省掉冒烟（开发演示的和冒烟的内容差不多）。至于没怎么出过问题的地方，也说明团队已经磨合好没太大问题，所以推流程急迫度也不高。

我们流程推动，一般都是先有流程并开始小范围试点，这个阶段主要靠领导强推和持续反馈。跑通了且有效果，再工具提效和巩固。

流程最终落地靠的是一线的同学，自顶而下可以破局，但如果下面持续不认可，最后这个流程其实也落不下去。这个时候领导也容易觉得这个流程其实推不推关系不大（本来就没做到位，自然出不了效果），继续强推反而容易反弹，也不会再继续强推了。

嗯嗯，明白

我们之前用 dubbo ，本身底层选择的就是 http 协议，所以做接口测试和普通的接口差异不大，http 的工具可以复用。不过你们开发如果不允许换的话，那就只能从外部绕了。

对，具体不是我装的，是同组的其它同学弄得。我周一问下他。

我们用官方的 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 或者某个底层服务，只要网络连通，就自动连上云真机服务端随时用来跑自动化的，和你这个思路接近。实际用起来效果怎样，不大了解。

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