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

首先，按网络接口角度，网络接口调用的核心目的，主要有 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 楼的回复吧，写得比较全面了。

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

xcuitest 应该本身就支持 Macos app 吧，没太明白为何要额外关联个 ios ？可以具体说明下你想做什么不？

看 appium 的 https://github.com/appium/appium-mac2-driver ，底层也是用的 xcuitest 做的。你可以研究下。

1、登录这个 token 有效期多久？是否可以预先准备，压测时直接使用，而不是压测时才获取？

2、TPS 达到多少合适，要看你业务峰值压力预估情况，没有通用参考值。如果是已经上线有线上数据的，可以根据线上数据以及业务预估业务峰值（比如搞活动）会比日常的峰值多多少倍，来预估；如果未上线，那就要自己结合业务情况评估了，最好评估后拉上开发、产品一起确认，达成共识。举个例子，假设预估业务高峰期会达到一小时 1000 人左右进行驾驶证申请，那驾驶证申请接口的 TPS 要求就是 1000/(60*60)=0.27 。

PS：不要盲目用什么二八原则按天估算，这就是纯 yy 的。实际日常业务高峰期情况怎样，各个接口负荷情况如何，找运维拉个单日各接口调用量的图表看更靠谱。

运行期才出现的、通过反射等方式的调用大家是怎么分析调用的。

前面忘了回答，这种原理上就无法通过静态分析来做了，只能通过运行时的动态调用链路记录来做，而且没法保障是否全（没跑到就不会被记录），只能作为补充。

首先，我理解你的链路每个节点，具象到代码层面，应该就是每个函数的入口了吧。那确认链路是否有被覆盖，你得用会记录每个函数入口信息组合的链路跟踪工具（比如一些服务端 APM 工具），记录每个从服务入口进来后的链路。

代码覆盖率工具一般关注的只是是否覆盖这个结果，不关注通过什么链路覆盖这个过程，也不会记录这种信息。

哈哈，这种情况，直接走就好了，说明现在新的领导对技术非常不看重。让我想起了《凤凰项目》书里面的情节，非技术的领导，确实容易觉得技术不是公司核心竞争力之一，看轻技术。

没看懂问题描述。标题说是 xcuitest 和 macos app 的 usb 通讯（还混了个 swift 不知道想表达什么），正文里写 ios app 和 macos app 的 usb 通讯且有结果了，只是用 xcuitest 执行这个通讯就断了。

能不能明确说下，你想实现什么效果，遇到什么问题？

google 了一下：
https://social.msdn.microsoft.com/Forums/en-US/293437b1-cc3b-4a73-9549-2e737afc14d3/can-be-my-silverlight-application-been-atacked-with-xss?forum=silverlightjavascript

大概意思是：
silverlight 1.0 理论上可能受到 XSS 攻击（因为原理上用的是 XAML + javascript ），2.0 开始用 XAML + C#/VB.NET ，应该就不会受到 XSS 攻击了。

但我自己本身对这块也不熟悉，只是搬运下别人的答案，仅作参考哈。

个人理解：

1、这个图里的总体吞吐量，实际计算公式是总样本数/总压测时长，因此你会发现和上面每个接口吞吐量加起来的和差不多。

2、对于 “系统能处理的吞吐量” ，我觉得需要加上前置条件，就是 “在存在 xxx 、xxx... 接口调用，且比例为 xx:xx:xx... 时，系统可处理的总吞吐量”。原因很简单，你的接口调用个数（调 3 个不同的接口改为调 4 个不同的接口），或者比例一旦变化，这个吞吐量的数值可能就会变了，所以没有这个前置条件，可以有无数个 “系统能处理的吞吐量” ，且都是真实压测采集到的数据。

3、一般性能测试，关注的是典型业务场景下性能是否可以抗住，所以主要是通过模拟典型业务场景下的接口调用比例去调用接口，观察此时的性能是否达标（吞吐量 + 响应时间）。此时的总体吞吐量一般会简称为 “xx 场景下的系统总体吞吐量” 。从你图上看，样本数各个接口基本是 1:1 的，感觉不像是真实业务场景（最简单的，登录和申请办证的比例一定是 1：1 么？个人经验应该不会）。如果场景本身就和现实情况差异很大，那这个场景下的性能数据就没啥意义了。

1.想问下各位大佬的公司用例评审都是用的什么格式的文档，接收程度如何？

我们全部用 xmind ，写和执行都是，并且用了基于开源 xmind 用例管理平台 AgileTC 二次开发的内部平台做在线管理，接入了公司 sso 相当于每个人自带账号。

2.你们用例评审的时候，是一条条讲吗，还是挑重点讲？

看有多少用例，大部分时间是一条一条，但不会每条都细到每个字级别，大概几秒一条的速度，只有觉得不确定会需要讨论的才会细一些，如果确实数量太多会挑重点。毕竟用例评审目的是再一次对齐产品、开发、测试对需求的理解，并且是最细粒度的，有些需求评审、技术评审遗漏的点就靠测试用例评审来统一了，所以能全部过尽量全部过。