随着移动终端的普及，手机应用越来越多，也越来越重要。而作为测试的我们也要与时俱进，努力学习手机App的相关测试，前一段时间我们介绍了Robotium手机自动化测试框架，从本章开始，我们介绍另一个手机自动化测试框架Appium。那究竟什么是Appium呢？我们引用Appium官网的介绍如下：

英文官网：http://appium.io/introduction.html?lang=zh

1.1 Appium 简介

Appium是一个开源的自动化测试工具，其支持iOS和安卓平台上的原生的，基于移动浏览器的，混合的应用。

原生应用：仅使用iOS和安卓标准SDK编写的应用

基于移动浏览器的应用：用移动平台的浏览器访问的应用（Appium支持IOS上的Safari和安卓上的Chrome或内嵌的“浏览器”应用）

混合应用：把基于一个WebView实现的所有功能包装成一个应用的应用，WebView是一个可以和网页各种元素交互的原生控件（译者注：因为所有的移动平台都会有浏览器，所以基于浏览器封装起来的应用就可以轻易做到跨平台了）。Phonegap这些项目可以很方便的把那些基于web技术实现的功能打封装成一个混合应用。

重要的是，Appium是跨平台的：它允许你采用同一套API在不同的平台（iOS,Android）上编写测试代码。这就让测试套件在iOS和Android平台上实现代码复用成为可能。

至于有关Appium跨平台支持和测试自动化模块化的具体意义，请参考platform support doc.

1.2 Appium 理念

Appium是基于以下的四个理念设计来满足移动平台测试自动化的要求的：

（1）您不应该因为需要自动化测试您的应用而不得不以任何形式去重新编译或者修改你的app。

（2）您不应该把自己固定在一门特定的语言和一个特定的框架上去实现和运行你的测试。

（3）当说到测试自动化APIs的时候，一个移动测试框架不应该做“重新发明轮子”的事情。

（4）一个移动测试自动化框架应该是开源的，无论是在精神上，实际上，还是名义上！

1.3 Appium 设计

那么Appium项目的架构是如何满足这些理念的要求的呢？为了实现第#1个要求，我们在背后使用的是移动平台供应商（译者注:iOS的UIAutomation和Android的Instrumentation及UIAutomator)提供的标准自动化测试框架。这样一来，我们就不需要往你的app里面编译进去任何的Appium相关的或第三方代码或框架。这就意味着“你测试的是你将要发布的那一个应用”。我们使用的移动平台供应商提供的框架如下：

?  IOS: 苹果公司的 UIAutomation。

?  Android 4.2+: Google公司的 UiAutomator。

?  Android 2.3+: Google公司的 Instrumentation. (Instrumentation 的支持是通过绑定另外一个独立的Selendroid项目来实现的)。

为了实现第#2个要求，我们的做法是把不同的移动平台供应商的自动化测试框架进行一次更高层次的封装，做成一套统一的API暴露出来，也就是我们要说的WebDriver API了。WebDriver（也叫做“Selenium WebDriver”）指定使用了一套客户端-服务器端协议（也就是JSON Wire Protocol),基于这一套协议，客户端无论是用什么语言编写的都能够通过HTTP请求恰当的发送到服务器。事实上现在已经存在有使用不同流行语言编写的客户端了。这也就意味着您可以随便使用任何你喜欢的测试执行过程管理平台和测试框架，因为你使用到的Appium客户端的库仅仅是一个HTTP客户端而已，你可以用任何你喜欢的方式把它嵌入到你的代码里面去。换一个说法就是，Appium&WebDriver客户端实际上并不是真正的”测试框架“，而是"自动化测试库”，你可以借助它们按照你自己喜欢的方式来搭建管理你的测试环境。

我们使用同样的方法实现了第#3个要求：鉴于WebDriver事实上已经是网络浏览器自动化测试的标准，并且已经立为W3C的工作草案，那么我们有什么必要针对移动设备再重新建立一套标准呢？没有必要！我们只需要扩展相应的WebDriver API来方便移动平台测试自动化的使用就行了。

至于第#4点就不言而喻了--你现在在读这篇文章这些内容就是因为Appium是开源的。

1.4 Appium 概念

1.4.1客户端/服务器端架构

Appium的核心是一个暴露了REST API的网络服务器。它接收客户端过来的连接，监听（客户端过来的）命令，在移动设备上运行命令，然后把代表命令运行结果的HTTP响应包发送回客户端。

我们使用客户端/服务器段的架构事实上为我们打开了很多可能性：我们可以在任何支持http 客户端API的语言上面实现我们的测试代码，当然使用我们提供的”Apppiu客户端库“会更加方便高效。我们可以把服务器端放在跟我们的测试运行机器完全不一样机器上。我们可以低头安心编写测试用例然后依赖远程的云服务平台如“Sauce Labs”来接收和翻译我们的测试命令。

1.4.2会话

自动化往往都是在一个拥有会话的上下文中进行的。客户端往服务器端发起一次会话的方式根据具体不同的库而会有所不同，但相同的是它们最终都会发送一个包含所谓的“desired capabilities"JSON对象的Post/session的请求到服务器端。这样服务器端就会开启一个自动化会话并把会话ID发送回客户端以便往后的持续的命令传递。

1.4.3 Desired Capabilities（不好翻译，所以当成专用术语不翻译算了）

Desired Capabilities是由客户端发送给Appium服务器端的用来告诉服务器去启动哪种我们想要的会话的一套键值对集合。当中也有一些键值对是用来在自动化的过程中修改服务器端的行为方式的。

比如，我们可以把键为platformName的capability的值设置成iOS来告诉服务器我们想要开启的是一个iOS的会话，而非Anddroid的会话。或者我们可以把键为safariAllowPopups 的capability的值设置成true来确保在Safari自动化会话的过程中，我们可以使用JavaScript来弹出一个新窗口。要查看Appium支持的完整的capabilities列表，请查看capabilities doc。

1.4.4 Appium 服务器

Appium是一个由Node.js编写的服务器。可以通过源码或NPM进行编译和安装。

1.4.5 Appium 客户端

存在很多对WebDriver协议进行扩展的Appium客户端库（针对以下语言的库：Java，Python，PHP,JavaScript，以及C#).当使用Appium的时候，相对常规的（译者注：没有扩展的）WebDriver库，我相信你更会选择使用这些扩展后的库。你可以在这里查看所有的库。

1.4.6 Appium.app, Appium.exe

这些Appium服务器的GUI封装版是可以下载的。事实上这些在配置appium服务器可运行环境时已经和其他东西一起打包安装了的，所以你并不需要担心要用Node再去下载安装。当中有一个Inspector也会一起安装，你可以用它来查看你的app的结构，这样你就可以在它的协助下很方便的编写测试脚本了。

开始

恭喜！你现在已经装备好足够的知识来开始使用Appium了，何不去getting started doc获取更加详细的需求描述和建议呢？

1.5 本章小结

     本章我们引用了Appium官网的介绍来作为我们这个教程的开始，先让大家对这个框架有一定的了解，然后在接下来的章节，我们将详细讲解如果利用这个测试框架来编写我们的自动化测试用例。而语言上我们采用python，当然也可以使用java。我们先介绍python+appium,如果大家有需求，我们后期会介绍java+appium，希望对大家的学习有所帮助。

第一章 Appium简介