你这个是通过加 java agent 来弄的，属于 On the fly 。至于引入这个依赖，我理解是主要给单测覆盖率采集用的吧？没怎么玩过 java 服务的 offline 插桩（因为 On the fly 很香，没有什么改用 offline 的理由），不大清楚。

也补充说明下，一切覆盖率工具，原理上都得给原版代码加额外代码。加的这个代码主要是一个标记，让给某个指令/某一行代码的运行前后，改变这个标记（比如默认标记是 0，有跑过就变成 1），标识这一个指令/代码行执行了。
只是由于 java 这门语言支持运行时字节码增强技术，也提供了 java agent 这样的不用改源码就能改字节码的玩法，所以才出现了这种特别的看起来 “无侵入” 的加代码姿势。所以官方把这种方式比较形象地称为 on the fly（直译是飞行中，你可以理解为运行中插桩）。

但要注意，因为 java agent 本质上还是在运行时改了字节码的，所以原理上是完全可以改变代码逻辑的（比如 jvm-sandbox 官方例子里的，不改源码直接改变某个函数的行为来修 bug ），接入多个 java agent 也有可能产生相互影响出 bug ，所以不要觉得这个方式真的 “不侵入、无风险” 哈。

@jiazurongyu 大猫知道么？

小程序的菜单不一定属于 webview 的一部分吧，你先 dump 整体界面控件树看看？

@Fhaohaizi 标题帮你改了，不要把正文直接作为标题。。。

看出问题概率高不高，高的话就要在灵活和安全两个里面做取舍，牺牲灵活性。比如收回多部门的编辑权限变为某个部门集中设置，或者每个这种规则的变更都需要上级审核确认后才能生效（比如线上数据库变更的玩法）。

个人理解，测试没办法对所有业务人员的配置正确性负责（权限上线上业务人员权限分分钟比测试还高，测试没法把控），但需要对系统的健壮性负责，即要能尽量确保系统配置不符合业务规则时，能明确提示；对应的降级容错措施能把业务问题降到最低。

不过大部分内部配置系统规则都会比较复杂，全部做校验成本比较高，产品和开发是不愿意的。而且运营人员流动性很大，本身也不一定熟悉系统，配错漏配真的是常事，最终造成线上故障，测试肯定逃不掉要协助排查处理。所以我们内部实际落地还有一种方式，就是重要活动/配置在配置完未发布时，给测试在预发环境进行验证，确保配置正确无遗漏。既然配置容易出问题，出问题后测试都是要投入，事前投入保障没事故，比出故障后费劲排查要高效得多。

行，讨论到此结束吧，我们继续保持双方的观点就好。也希望后续的文章，这些概念性的内容，请做好审核，最好是加上参考资料或者出处，经得起大家的推敲。

关于言论自由这个，也特别说明下，社区一直保持言论自由，这个帖子一直没有被屏蔽就是一个证明。但也请注意，社区的初衷是为了帮助新人成长，提高测试地位，推进质量发展，因此会保持对内容进行审核。遇到内容不大正确，经不起推敲的，会有人站出来指出；太不靠谱的，我们也会直接屏蔽。

每个人角度不一样这个没问题，只是你这个分类，特别是 RPC 和 gRPC 并列，这个分类方法会让新手很迷惑这两个 rpc 有啥差异，实在有点说不过去。

既然要给新同学布道入门接口自动化，内容里给读者一个经得起推敲的指引，这个是基本要求吧。如果有些不确定的，建议特别说明 “个人观点，不一定正确，欢迎探讨”。

hmm，你想办法和领导沟通好吧。

不是所有手工都适合自动化的，也要考虑投入产出比，不要为了自动化而自动化。

现在这个还是不大对。。。我说下我的个人理解。

首先，按网络接口角度，网络接口调用的核心目的，主要有 2 个：把约定好格式的信息，发送给指定的目标

传输协议的目的是为了解决发送给指定的目标这个目的的。有多种协议，比如 http、https、tcp 等。tcp 也是常说的长连接，http 是基于 tcp 的但无法支持任意一方随时发起通知，所以对于一些实时通信要求比较强的，会直接基于 tcp 来进行网络连接。tcp 典型的使用场景有微信的消息传输、直播应用的公屏消息等。至于怎么定义指定传输目标？http/https 用的是 url ，tcp 用的是 ip 。

而序列化方式则是为了解决约定好格式的信息这个问题的，常见的有 proto buffer 、json、xml 等。序列化方式保障发送者和接收者用一致的格式解读数据，确保数据传输正确性的同时根据传输场景进行优化（比如一样的信息，用 json 占用的空间比 xml 小，proto buffer 又比 json 小）。当然，除了序列化方式，部分协议也有定义信息格式这类字段，比如 http header 。

然后，在实际编码中，不管什么传输协议、序列化方式，都得自行基于网络库来建一大堆封装方法，接口多了这部分逻辑也有不少的工作量，所以就有了 RPC 调用，把网络库部分自动封装好，开发不用管底层网络库，直接引用 api 包，调用里面提供好的对象和函数即可，大幅度降低开发的调用成本。

而 dubbo、grpc 属于实现了 RPC 理念的具体框架，由于它们封装了底层的传输协议、序列化方式，因此也具备切换多这个协议的能力，比如 dubbo 支持 http、dubbo、thrift 等多种协议。同样由于 RPC 本身就是一种调用方式，本质就是对传输细节的封装，所以一样会有 一个rpc框架封装另一个rpc框架 的情况。比如 dubbo 底层也支持通过 grpc 来进行调用。

至于 RESTful（Representational State Transfer），不属于以上任何一类，它是一种针对 http 协议的接口风格。核心思想是把最常见的数据库的增删改查，和 http 协议的 post、delete、put、get 方法进行一一对应，便于简化服务端逻辑（这种直接增删改查数据的，可以直接基于数据库生成完整的调用逻辑，现在实际也有相关的工具）。当时时代背景是接口协议定义没有任何统一指导思想，大家随心所欲，经常会出现同样是删除资源，每个人创造一种风格的接口路径（有的叫 delete，有的叫 remove 等），复用度也不高，所以产生了这种定义清晰简单，扩展性复用性也强的接口风格，并受到很多开发的欢迎。只是传播过程中很多一知半解的，把它等同于 http 接口了，讲着讲着变了味。

可能有的人会觉得，概念不重要，也确实很多人即使把概念搞混，也不影响工作。但基于这篇文章是想给新人们宣导用的，所以里面的概念还请理清，避免新人们不同地方看到不同的概念，陷入混乱，这就违背了初衷了。

根据调用特性，接口大致可以分为以下几类：
http
https
RPC
webservice
Restful api
...

这个分类方法表示不认同。http、https 代表的是传输协议；RPC 代表的是调用方式；web service 代表是个 web 服务（有点废话）；restful api 代表的是接口定义风格

这几个东西不是同一个维度的，不能进行并列分类，比如这句话是没问题的 “某某 RPC 调用方法，背后采用了 http 传输协议和 web service 进行通讯” 。

基础概念非常重要，请说明清楚，不要误导别人。

bing 搜索了一下，还是有挺多信息的：
https://cn.bing.com/search?q=android+app+mac+%E5%9C%B0%E5%9D%80&form=QBLH&sp=-1&pq=android+app+mac+%E5%9C%B0%E5%9D%80&sc=0-18&qs=n&sk=&cvid=949235060128449D8766F2A9E6132DE1

楼主可以看看？

没操作，因为没用到。好奇问下，你们那为啥要弄 frame ？移动端本身界面就不大，很少见到还会往这么小的 h5 弄 frame 的。现在就算桌面端 h5 用 iframe 也越来越少了。

而且测试去修改 开发的代码也不太现实

不知道你们公司是什么氛围，在我的经历里面，测试去修改开发代码，做一些自己需要的增强或者修改功能，让测试更便利，是非常正常的且被鼓励的（当然，改动后要开发 review 通过才能合并）。而且这样也更容易产生产出。不修改代码，你能做的和一个用户能做的差不多，实际会非常有限。

比如我们做 UI 自动化，如果元素不加唯一标识，要定位会非常费劲，而开发只需要加一行和业务逻辑无关的代码，就可以加上这个唯一标识了。
比如验证码，开发做个万能验证码支持，我们就不用费劲去搞各种验证码识别了。
再比如一些 rpc 通讯协议，只要网络组件支持多通讯协议切换，并支持使用 http+json ，那测试就有一大堆现成的工具可用，而不需要再重新自研针对这个自家通讯协议的配套测试工具。

你在跑哪个命令的时候报错？可以把完整的日志发一下不？

项目本身没有依赖 python ，估计是项目某些依赖有需要用 python 安装。

这个话题略庞大，很难回答，只能说从我自己经历角度，给个参考回答吧。

要掌握哪些技能？

测试的：接口自动化、UI 自动化、脚本造数据等
开发的：web 前后端开发、app sdk 开发（视情况而定）

从哪里学起？

建议从自动化学起，先学会写脚本跑起自动化，然后把脚本重复部分抽离成框架让你的维护成本和编写成本降低。同时日常中多用自动化脚本解决批量问题，锻炼自己按需随时可以写脚本的经验

测开的工作是怎样的？

目前接触，测开一般有两大类，一类是业务测开，一类是平台测开。

业务测开一般在业务团队里，属于业务测试团队里的技术担当，日常会承担一些迭代测试，但更关注自动化、专项测试（如性能测试）这些方面。同时也会肩负如何提高业务测试效率的责任，针对业务开发对应的提效工具（比如造数据脚本）

平台测开一般在独立的效能团队，属于整个测试部门的技术担当，日常主要负责部门各个测试平台的建设、优化和推广落地。典型产出是类似接口测试平台、UI 自动化平台等。这类测开基本专注在平台开发了，对开发技能要求高于测试技能，偶尔也会支援业务完成一些业务需要的工具平台开发。这类测开一般是从业务测开做上来，又或者是直接从开发转过来。

技术上可以考虑 adb 直接发键盘事件

但建议涉及实际付款的，先别自动化了吧。一个是跑多了你的钱很快就不够了，另一个是支付页面各家都会做安全方面的防护确保是用户本人操作，自动化成本会比较高。

1、为啥无法预先准备呢？你先跑一遍模拟登陆，把 token 拿到，然后再把这些 token 用到后面接口就可以？你原来用登录接口也是分 登录获取 token 和 其它接口使用 token 两步吧，现在只是把第一步拆出来而已。
2、我只是举个例子。如果你已经确认了 TPS 要 300，那就按 300 就好。

个人能想到的三个方案

方案一：把你的真机也搬到机房，人工需要控制时，通过远程真机连接控制。
方案二：找运维加白名单，打通链路。
方案三：不要部署到机房服务器，自己申请个 mac mini 当服务器用，放在自己工位。

我们目前用的是方案三，原因：
1、方案一，idc 机房一般不愿意接受放手机进去的，手机电池长时间充电容易过充产生危险，不满足机房安全方面要求。
2、方案二，运维加白了之后，如果没有专线网络（真正的专线，不是 vpn 这种走公网的虚拟专线），网络会不稳定，导致自动化执行不稳定。

你是在行车记录仪的开发公司是么，那应该有行车记录仪的源码吧？

有的话，直接改源码里面的视频信号入口，把原来从摄像头硬件来的流，改为从你指定的另一个地方（比如你要播放的视频）来，是否就可以？

没有 MFI 认证，用破解 lighting 芯片的就会这样，系统升级之类的就会因为无法适配失效。
预算可以的话，确保采购的都是有 MFI 认证的就可以了。

从主贴描述，你应该还在自动化起步阶段，建议一步一步来

1、先把主流程列出来（先不要管是否涉及端到端交互，列全了先），然后逐条评估自动化实现及维护成本。
2、按自动化成本排序，进行分阶段。先做成本低的部分，快速出效果，让你的自动化得到认可进而获得长期投入的机会。剩下的成本高的，先继续人工覆盖。
3、逐步补充剩下的成本高的自动化用例。
4、偶尔出现的一些线上出过大事故且自动化成本不算特别高的，也可以加到自动化里面，避免再次遗漏。

不知道你们团队对于自动化用例的编写维护经验如何，如果都是新手的话，最晚第二阶段产出一部分用例后，就要考虑维护成本，优化写法了。要不用例越来越多，维护成本会越来越高。

从严格意义上说，这种不能反推调用链就覆盖到了，也可能实际这几个节点是在好几个调用链里分别覆盖到的，不是真的有走过一条直接就是这几个节点的调用链

不过从工程角度，要真的那么细成本很高也很难，做到这个也足够了。

也是，前面回答的时候没想太全面。

你参照 6 楼的回复吧，写得比较全面了。

人工哪个跑得最多，就写哪个。自动化首先是为了降低人工成本的，人工本身就不怎么跑，说明不重要，自动化也没必要跑。