感谢支持。客户端性能方面我也只是入门，分析调优这块大头目前接触还比较少，算不上大佬哈，只是分享点个人经验。

简单版这样足够了。

第一点重复性工作太大，可以考虑用 airtest 之类的可以低成本做自动化脚本的工具，把你的自动化脚本弄出来。

第二点报告怎么分析，这个你得先确定通过指标（怎么算通过，怎么算不通过），然后看报告里面有没有不符合指标要求的，不符合的再进行具体分析。

一般最关注的是
CPU 占用高不高（影响耗电量以及发热，一般应用最高应该在 15% 以内）
内存是否有泄露或接近系统内存的上限（重复操作这个场景 5 分钟以上，内存会持续上涨且不会回落。内存占用达到系统上限后，会被系统强制杀掉，给用户感受是偶发性闪退、应用不稳定）
是否卡顿（看 Jank 以及主观感受，给用户感受是不流畅）。

另外，机型选择，建议也结合线上用户使用占比来决定，优先选择整体占比高的或者高价值用户（如大额消费的用户）用得多的，不要拍脑袋。

不过我也只是互联网公司的经验，可能有的传统企业有这方面需求。这块还是要以你们受众的需求为准。

哦哦，明白了。那你们场景和我以前的不一样。

从我的经历看，每个公司这方面的流程都不大一样，用的系统也都不大一样。经历了 4 家公司，除了 jira ，没见到两家公司用同一个流程工具的。而且虽然用 jira ，但自定义的工作流也是有不少差别的，基本都不会用自带的默认流程。

如果你们是在初创期，建议先专注做自己特色吧。测试计划、测试报告在不少互联网企业，可能一个 wiki 文档就可以满足了，没有那么强的需要。真有强需要的，也基本有自家模板，需要适配定制，对你们来说投入产出比也不高。更关键的是，如果购买方是测试团队，相比流程，需求更大的应该还是你前面提的技术、工具。流程这块一般是公司整个研发团队甚至全部工作项的管理，才会有采购需求。

这么说吧，原理上，不提供 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 底部有应用日志打印）

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

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