1 什么是STF

STF（Smartphone Test Farm）是一个开源的web架构利用

  • 用户能够通过浏览器近程操作操作，调试手机利用，在设施上进行测试，实现真正意义的云端应用，调试，测试，治理真机。
  • 可近程调试超过160多个设施，为搭建机器提供了很好的形式
  • github上1万多的star https://github.com/DeviceFarm...


<br/>

相似产品：

  • AWS Device Farm
  • Google Cloud Test Lab
  • 百度MTC的近程真机调试
  • Testin的云真机
  • 腾讯WeTest的云真机
  • 阿里MQC的近程真机租用

其中OpenSTF是开源我的项目，其余的平台大多也都是基于OpenSTF原理实现的

2 为什么须要 STF

2.1 解决测试机的高效利用

  • 大家都须要设施，要相互借，还要保护借的表格
  • 大家在不同地区
  • android设施太多，而且始终有新的

2.2 进步测试效率

  • STF提供设施机的CPU，内存，电量等性能的监测
  • 对接monkey
  • 查看log
  • 自动化测试

2.3 测试机器的治理

  • 固化测试机器的零碎版本，零碎设置，不被篡改
  • 追踪查看测试机设置的人员

3 STF 性能介绍

3.1 OS 版本反对

  • 目前只反对android零碎， android 2.3.3 (SDK level 10) to android 10 (SDK level 29)

3.2 通过浏览器近程管制

  • 实时屏幕操作和显示。刷新速度能够达到每秒30-40帧，能够旋转屏幕 （minicap）
  • 反对从PC键盘输入到android设施
  • 反对复制黏贴
  • 反对多点触控 （minitouch）
  • 拖拽装置，launch apk文件
  • 通过minirev，能够间接从Android设施的端口转发本地服务，即使不在一个网段。
  • 能够应用任意浏览器拜访
  • 展现和过滤设施日志。
  • 当设施连贯到电脑上，且关上adb模式或在一个局域网时，就能够通过adb connnect近程连贯调试。
  • 能够拜访设施的文件系统。

3.3 在web上治理160+设施

  • 查看设施状态，能够看到设施的连贯状态：连贯、离线、不可用（连贯信号比拟弱）、未受权、未连贯
  • 查看谁在应用设施
  • 能够通过手机号码、IMEI、ICCID、Android零碎版本号、运营商、手机型号或者其它属性来搜寻设施。
  • 检测设施电量
  • 展现硬件详情
  • 提供API
https://github.com/DeviceFarm...
http://youripaddress:7100/api/v1/devices/

4 STF 架构介绍

4.1 平台语言

  • 查页面html应用Pug模版引擎
  • 前端应用的是Angularjs
  • 后端应用的是Nodejs
  • 数据库应用的是对象型数据库Rethinkdb

4.2 次要模块

STF的外围性能能够了解为：“同步图像” + “点击”。前者应用minicap实现，后者依赖minitouch。 具体构造看下图

4.3 架构介绍

设施端
  • STF在会在android设施上装置minicap和minitouch。应用minicap来捕捉屏幕和应用minitouch来触发多点触控事件，并通过adb应用socket在服务端和设施端进行数据传输。
  • STF还会在android设施上装置STFService.apk，它在设施后盾运行，提供了一组socket api能够用来监控和执行不同的action。 同理，它也是通过adb和服务端通信，不过它应用的是protocal buffer数据格式。
  • minirev，间接从Android设施的端口转发本地服务，即使不在一个网段
服务端

STF的服务端由多个不同的独立的，基于nodejs的微服务组成，这些服务之间是通过ZeroMQ通信。服务端能够进一步分成Provider 层和Application层

Provider 层

  • Provider层（stf-provider）次要负责和设施之间进行通信。
  • 通过adb来监控设施状态，当有新的设施连贯，或者有设施断开则会立即监控到
  • 如果是新的connect设施，则provider会folck一个新的nodejs过程（stf-device）， 这个过程次要负责与该设施的所有通信。
  • 总体说，stf由两个局部组成，别离是stf-provider和adb
  • 另外，须要留神的是，provider层的服务须要跑在物理机上，所有的设施须要连着这台物理机。

Application 层

  • application层则是由STF -api、STF -app和STF -auth等微服务组成，这些微服务组成了一个残缺的STF
  • 从部署的角度来看，这些服务能够跑在任意中央，惟一的要求就是，这些服务可能通过网络和provider通信。这也就是意味着他们须要在同一个网段上

Client 层

  • 应用Angular JS实现
  • 通过websocket与服务进行通信

4.4 比照美团云真机架构

  • Agent - 相当于stf的provider
  • 音讯核心 - 相当于stf的triproxy
连贯手机和Server的枢纽，音讯核心次要解决屏幕的操作以及手机的状态变更等音讯
  • 数据存储模块 - 相当于stf的RethikDB
数据存储模块用来保留整个平台的数据，例如手机的状态、用户应用记录等。 - RethikDB
  • Server模块 - 服务端，websocket，nignx
Server用来集中管理和调度手机，与OpenSTF构造不同的是，咱们的Server端蕴含Web服务器、Websocket服务器、动静代理以及音讯解决服务等局部，Server将用户的拜访动静代理到对应的Web服务器和Websocket服务器上，并通过音讯解决模块向音讯核心传递音讯，实现用户与Agent端手机的交互。

4.5 STF 中的消息传递

在STF中，只有用户点击按钮，这台手机会被标记为占用状态，其余用户立即就能看到这个最新的状态。同时其余用户也没法应用这个手机。这种即时的消息传递不能靠一般的接口的形式进行，STF中次要是通过ZeroMQ和Protobuf来实现这种即时的消息传递。

4.5.1 ZeroMQ 用到的三个模式

  • push/pull是单向模式，音讯只能由push端收回，由pull端进行拉取。一般来说pull端对音讯进行解决，如果一个pull端不能及时处理，能够同时有多个pull端，这种状况下，一条音讯只能被 一个pull端拉取，拉过之后其余pull端就不能再次拉取。如果没有pull端拉取，音讯过多的时候可能会溢出。
  • publish-subscribe这属于公布订阅模式。与push-pull所不同的，pub会向所有曾经连贯的sub发消息，如果没有sub连贯，音讯会被抛弃。
  • dealer/router是路由模式，实用于有多个发送端和多个接收端的状况，这样能够实现负载平衡。在stf中，同时有多个用户和多台手机在线，dealer-router很实用于这种状况下的消息传递。

4.5.2 Protocol Buffer

zeromq只是负责音讯流的解决，而具体如何组织音讯，则是通过其余的形式，stf应用了Protocol Buffer，它是Google的数据交换的格局，与protobuf相似的货色其实是json和xml，protobuff的劣势在于更小的体积，这样在大量数据传输的时候节俭了带宽资源。与json和xml所不同的是，protobuff自带了一个编译器，protoc，只须要用它进行编译，能够编译成JAVA、python、C++代码，简略来说，它能够生成对应语言的数据类型，比如说生成java的一个类等等。

4.5.3 Websocket

  • 启动一个websocket，负责前端页面和服务端通信

4.5.4 Processer

  • 连贯了设施和前端页面的所有通信

4.5.5 Dev

  • 设施单元：文档没有阐明，不过看源码，这部分封装了对设施操作的逻辑，譬如理论的apk装置，touch操作，实时显示图像，调用adbkit装置app等逻辑。

4.5.6 Provider

  • 给每个设施启动一个work process，负责和设施的通信

4.5.7 Reaper

  • reaper过程保护着一个TTLSet，次要负责对超过存活工夫的设施进行收割

4.5.8 Triproxy

  • triproxy其实是一个三端的音讯转发器，它蕴含三个端口，pull、pub和dealer，别离对应zmq的三种工作模式。triproxy模块最大的用处是模块的解耦。
  • 的pull端用来拉取websocket模块或者provider模块的音讯，之所以用pull的模式是因为音讯从websocket或者provider到triproxy的消息传递是单向的，而push-pull模式能够保障消息传递的可靠性，就是说，如果pull端断开，push端的音讯依然会被保留而不会失落，直到pull把音讯拉走，例如，provider发现一台手机的在线状态产生了扭转，就是通过push的形式推给triproxy。
  • 而pub端则用来播送音讯，播送的特点就是一个发送端能够对应多个接收端，这些接收端能够同时接管到音讯，例如设施状态的扭转须要播送给所有的websocket模块，进而播送给所有的在线用户。当然播送的另外一个特点是如果播送时客户端不在线，那么这条音讯就永远收不到了，因而，播送的音讯也能够说是不太重要的音讯，比如说如果provider的一台手机没有收到用户占用的音讯，最多是用户占用失败，而不会造成太大的影响，而provider占用胜利的音讯如果用播送的形式就麻烦了，用户没收到占用胜利的音讯，会持续做占用的操作而不会胜利，除非手机超时主动勾销占用。
  • triproxy和processor的通信是双向，因而用了dealer模式。dealer模式尽管能够一对多，然而一条音讯只能惟一的传给一个接管方，就是说如果做了processor扩大，存在多个processor的状况下，同样的音讯只会被一个processor解决，这点儿须要留神。

4.5.9 咱们通过一个例子看下消息传递的过程。

看看stf是如何发现有新的设施连上usb的

  • 设施连上usb
  • Provider 发现设施状态发生变化 （监控add，change，remove）
client.trackDevices().then(function(tracker) {  log.info('Tracking devices') ...}
  • Provider 通过zmq向processor发送一个protoBuf音讯DeviceIntroductionMessage
  • Processor 过程收到DeviceIntroductionMessage
  • Processor 调用dbapi.saveDeviceInitialState()办法将音讯中携带的设施信息保留到rethinkDB
  • Processor 向provider发送DeviceRegisteredMessage
  • Processor 将DeviceIntroductionMessage播送进来（websocket、reaper）
  • Websocket过程收到DeviceIntroductionMessage
  • 通过websocket(协定)向前端发送一个’device.add'音讯，前端页面会依据该音讯更新设施连贯状态。
  • Provider收到DeviceRegisteredMessage会通过flippedTracker发送一个以deviceId为音讯名称的音讯，参数为’register’（至此设施注册就算实现了，接下来就是启动device过程）
  • Provider 启动device过程，接下来就是设施和device过程之间的监听
  • device过程启动胜利之后会向父过程发送一个message，内容是'ready'，示意device过程启动胜利了，至此整个设施连贯就曾经实现了。

4.6 存在的问题

  • 不同android设施的兼容性问题
  • 本地 STF 内网穿透公网拜访
  • provider启动多了，有点耗资源
  • 如果对方遗记release 设施，设施会始终被占用，除非认为的把设施拔掉从新连贯
  • 如果是动静ip的话，会失败，所以须要申请static ip
  • 不同地区如果网络弄不好的话，会提早很厉害
  • OpenSTF应用RethikDB作为数据库，RethikDB是一个NoSQL型数据库，它有十分多的毛病，比方解决大量数据时的性能很差，材料十分匮乏，排查问题和数据库保护都十分艰难。

4.7 装置的坑

  • node.js只反对8.x版本的 ，所以能够用nvm来治理node.js的版本，装置多个node.js
  • 设施始终显示disconnect或者preparing，之后disconnect，这是他们的一个bug，当数据线很差当时候会呈现。换一条数据线。
  • 小米设施须要sim卡关上通过usb装置的权限才能够
  • 如果在docker上装置，最好是linux零碎，mac上能够装一个linux虚机来装置
参考：
因为参考的文章切实是太多了，没法一一列举进去，敬请体谅