一、Macaca框架
![SouthEast]()
PS：上图所有模块均可以在官方github上找到对应的源码 https://github.com/macacajs
二、各模块浅析
2.1、Macaca
2.1. macaca-cli
Macaca提供的命令行工具
$macaca server 启动server
$macaca server --verbose 启动server并打印详细日志
$macaca doctor 检验当前macaca环境配置
2. app-inspector
macaca提供的元素查找工具，可以将app视图的结构以布局结构树的格式在浏览器上展示出来，用过点击某个元素，就可以方便的查询到该控件的基本信息，以方便查找。具体使用可参考官网: https://macacajs.com/inspector
3. UI Recorder
macaca提供的脚本录制工具，可以通过录制获得脚本，对于入门同学很有帮助。https://macacajs.com/recorder
2.2、WebDriver-Server
Macaca是按照经典的Server-Client设计模式进行设计的，也就是我们常说的C/S架构。WebDriver-server部分便充当了server这部分的角色，他的职责就是等待client发送请求并做出响应。
2.3、WebDriver-Client
client端简单来讲就是我们的测试代码，我们测试代码中的一些行为，比如控件查找、点击等，这些行为以http请求的方式发送给server,server接收请求，并执行相应操作，并在response中返回执行状态、返回值等信息。
也正是基于这种经典的C/S架构，所以client端具有跨语言的特点，macaca-wd，wd.java,wd.py分别是Macaca团队针对Js Java 以及Python的封装,只要能保证client端遵循webdriver的协议，任意语言都可以。
2.4、DriverList
自动化要在不同的平台上跑，需要有对应平台的驱动，这部分驱动接收到来自server的操作命令，驱动各自平台的底层完成对应的操作。
1. Android
Macaca针对安卓平台的驱动集合
- macaca-android 安卓驱动
- macaca-adb 封装了安卓的adb命令，来实现一些adb的操作，比如安装、卸载、启动app、获取设备列表这些操作
- android-unicode 经过封装后的输入法，解决中文输入的问题
- uiautomator-client 将来自server的操作指令转换为UIAutomator可以识别的指令，驱动uiautomator完成对应的操作
- android-performance 用于自动化测试安卓性能相关的支持
2. iOS
Macaca针对iOS平台的驱动集合
- macaca-ios iOS驱动
- xctest-client 同安卓的uiautomator-client异曲同工，对XCUITest的封装，将来自server的操作指令转换为XCUITest可以识别的指令，驱动XCUITest完成对应的操作
- ios-simulator 用于对ios模拟器的支持，可以通过模拟器运行用例
- remote-debug 用于远程调试
3. Hybrid
Macaca针对Hybrid的驱动集合。
- macaca-chrome web测试驱动
- macaca-chromedriver 驱动chrome浏览器
- ios-webkit-debug-proxy 适用于iOS平台对webview的调试
4. Electron
Macaca针对pc端网页应用的支持
三、Macaca执行流程图
了解了Macaca的组成模块以及他们各自的作用，下面我们看一下各个模块是如何组装起来实现自动化测试流程的
![SouthEast]()
四、结合实例讲解Macaca基本原理
文章以百度外卖APP（iOS版）为例，下面我们开始我们的用例执行。
1. 启动macaca server
![image2017-9-9%208%3A34%3A44.png?version=]()
![image2017-9-9%209%3A1%3A19.png?version=1]()
从这一步打印的信息我们可以看到，这一步实际上执行的是流程图中第一步的操作，启动server，建立连接，然后server返回所连接的ip以及端口号，因为我们是本地跑，所以ip实际上是本机的ip地址
2. 执行用例
以命令行为例，先执行“![image2017-9-9%208%3A42%3A30.png?version=]()
” build工程，稍作等待，就会看到项目构建结果，如下图所示
![image2017-9-9%208%3A40%3A30.png?version=]()
然后执行“![image2017-9-9%208%3A41%3A41.png?version=]()
”运行测试用例，稍作等待，就会看到系统自动启动了ios的模拟器并跑起来了用例。执行过程中的某个截图如下：
![image2017-9-9%208%3A48%3A51.png?version=]()
![image2017-9-9%208%3A47%3A17.png?version=]()
我们来看一下对应用例启动的client端核心代码：
在这段代码中，我们做的工作是根据不同的平台设置用例的一些基础启动信息，包含平台类型、安装包地址、设备id、是否覆盖安装等参数，设置完成后，通过driver.initDriver(desiredCapabilities)这个操作启动driver,这个过程便会按照流程图中的第二个步骤发送http请求，server会接收到这个请求并创建一个session，在这次的用例执行中，所有的操作都会基于这个session进行，来看一下针对这个操作控制台所打印的信息(为方便突出主要过程省略了部分无关日志)：
![image2017-9-9%208%3A59%3A16.png?version=]()
经过如上步骤后，连接便已经成功建立了，下一步我们以添加商品为例再分析一下具体操作，对应的client端的代码如下：
(因为框架层封装了一些操作，所以代码看上去比较少，具体的控件查找部分看不到，有需要详细了解的可以研究源码)
执行对应按钮的操作，我们会在控制台上看到如下的日志：
在上面的日志中我们可以看到，当我们查找登录按钮的时候，client发送了一个http请求给server，请求的操作是element（这个表示控件查找）,参数是{"using":"name","value":"搜索"}，这是告诉server我们要找的这个控件的name属性是“
搜索”，server收到这个请求，通过router路由转发给iOS的驱动(在启动driver的时候已经设置的平台类型，因此这里能知道找ios)，iOS驱动收到请求驱动XCUITest框架对模拟器上的目标app执行对应的控件查找操作，得到response后原路返回给client，这样就完成了一次请求的完整的生命周期。
