Appium的入门使用

ps：有没有人和我同样以为Appium官方文档写的很烂的， 这官方文档，还不如不少人写的博客详细，并且对于初学的入门者实在是不够友好，
官网:https://github.com/appium/java-client

移动测试神器：带你玩转Appium

移动测试神器：带你玩转Appium

以移动应用的自动化测试为主题，介绍目前主流的移动应用自动化测试框架 Appium。Appium 是一个开源的自动化测试框架，支持 iOS 和 Android 上 Web App、Native App 和 Hybrid App 的自动化测试。

因为基于 Appium 的移动应用环境搭建相对复杂，虽然网上也有很多教程，可是知识点都比较零碎，并且大多都是基于早期版本的示例，因此我会使用最新版本的 Appium Desktop 1.6.2 和 Appium Server 1.8.1 来展开今天的内容：

• 首先，我会展现如何在 Mac 环境下一步一步地搭建 Appium 测试环境；
• 接下来，我以 iOS 为例，实际开发两个测试用例，一个是 Native App 的测试用例，另外一个是 Web App 的测试用例（由于 Hybird App 的测试用例实际上是相似的，Native App 的壳，Web App 的内容，因此就再也不单独举例子了）；
• 而后，我会在 iOS 的模拟器上实际执行这两个测试用例（之因此选择 iOS 模拟器，而不用 iOS 真机作例子，是由于 iOS 真机的测试须要用到 Apple 开发者帐号，还须要对被测应用进行签名等，会在环境搭建过程当中引入不少额外步骤，而这些步骤对于讲解 Appium 并无直接的关系）；
• 最后，当你已经经过实际使用对 Appium 造成感性认识后，我再来简单介绍一下 Appium 的内部原理，让你作到知其然知其因此然。

移动应用的自动化测试需求

在开始设计测试用例前，咱们首先须要明确要开发的这两个自动化测试用例的具体测试需求。

1. Native App 的测试用例，被测 App 我选用了 Appium 官方的示例 App，被测 App 的源代码能够经过“https://github.com/appium/ios-test-app” 下载，而后在 Xcode 中编译打包成 TestApp.app。
   具体的测试需求是输入两个数字，而后点击“Compute Sum”验证两个数字相加后的结果是否正确。
2. Web App 的测试用例，具体需求是在 iPhone 上打开 Safari 浏览器，访问 Appium 的官方主页“http://appium.io”，而后验证主页的标题是不是“Appium: Mobile App Automation Made Awesome”。

图 1 Native App 和 Web App 的 GUI 界面示例

接下来，我将从最初的环境搭建开始，和你来一块儿开发 iOS 上的 Native App 和 Web App 的测试用例。首先咱们看一下 iOS 的环境搭建，若是你以前没有接触过这部份内容，你能够跟着个人步骤一步一步来作；而若是你已经比较熟悉 Xcode 的话，能够跳过这部份内容，直接从“Appium 环境搭建”部分看起。

iOS 环境搭建

在正式搭建 Appium 环境前，咱们先来搭建 iOS 开发环境：

• 首先，下载安装 Xcode；
• 而后，在 Xcode 中下载 iOS 的模拟器；
• 接着，使用 Xcode 编译打包被测试 App；
• 最后，在 iOS 的模拟器中尝试手工执行这两个测试用例。

在 iOS 模拟器中，手动执行测试用例的具体操做步骤以下：

1. 启动 Xcode，导入 ios-test-app 下的 TestApp.xcodeproj 项目。
2. 在 Xcode 中，打开“Preferences”中的“Components”，完成 iOS 10.0 Simulator 的下载。
3. 在 Xcode 的“General”页面，将 TestApp 的“Deployment Target”设置为 10.0，而且将“Devices”设置为“iPhone”，如图 2 所示。

图 2 TestApp 的 General 配置

1. 在 Xcode 中编译运行 TestApp，以后系统会自动启动 iPhone 模拟器，自动完成 TestApp 的安装，并在 iPhone 模拟器中自动启动 TestApp。
2. 在 TestApp 中手动执行自定义的加法测试用例。
3. 退出 TestApp，而后打开 Safari 浏览器，在 Safari 中执行访问 Appium 官方主页的测试用例。

至此，你已经搭建好了 iOS 开发环境，而且成功编译打包了 TestApp。接下来，咱们再一块儿来搭建 Appium 测试环境，并尝试在 Appium 中开发上述的两个测试用例。

Appium 测试环境搭建

经过 Appium 的官方网站下载并安装最新版本的 Appium，截止本文写做的时间，最新版本是 Appium-1.6.2.dmg。

须要注意的是，早期版本和网上不少教程都建议用命令行的形式启动 Appium Server，但在这里我是想强调的是，你彻底能够经过界面启动（在 Launchpad 中找到 Appium 的图标，点击便可启动），并且新版本的 Appium 也推荐这个启动方式。经过界面启动，是目前最简单直接的方式。

而后，你须要用命令行“npm install -g appium-doctor”安装 Appium 的环境诊断工具 appium-doctor，用于检查 Appium 所依赖的相关环境变量以及其余安装包是否都已经配置好了。若是尚未，就须要逐个安装，并根据 appium-doctor 的提示配置环境变量。

这里，Appium 最主要的依赖项主要有：Java、Node.js、Xcode、Carthage、Android SDK、adb 等。若是你全部的环境依赖都正常配置的话，你就会看到 appium-doctor 返回这样一个截图，如图 3 所示。

图 3 正常配置环境依赖后，appium-doctor 返回的截图

按照上面的步骤，配置好 Appium 的环境依赖后，就能够继续启动 Appium Server 了。

Appium Inspector 的使用

为了后续测试用例的顺利执行，咱们能够先来熟悉一下 Appium Inspector 的使用。Appium Inspector 主要是用来协助对界面元素进行定位的工具。

首先，咱们来看看如何使用 Appium Inspector 启动 iPhone 的模拟器，并在模拟器上运行 TestApp，以及如何经过 Inspector 定位 TestApp 界面上的元素（了解元素的定位是后续开发自动化脚本的基础）。具体的操做过程以下。

1. 经过 Appium Server 的“Start Inspector Session”按钮，进入 Session 配置界面。

图 4 点击“Start Inspector Session”按钮打开 Session 配置界面

1. 在 Session 配置界面完成必要参数的配置。这里你须要根据选用的移动设备操做系统、模拟器 / 真机等具体状况来完成参数配置工做。须要配置的参数主要包括：platformName、platformVersion、DeviceName、automationName 和 app。
   其中，automationName，指自动化测试框架的名称，这里采用了 XCUITest；app 指被测 Native App 的安装包路径，这里使用以前 Xcode 打包生成的 TestApp.app，这样启动模拟器时，就会自动把 TestApp.app 安装到模拟器中。
   其余参数的配置很是简单，我就再也不一一展开了。

图 5 Session 配置界面

1. 完成配置后，点击 Session 界面的“Start Session”按钮，启动 iPhone 模拟器，并在 iPhone 模拟器中启动 TestApp，同时还会打开 Inspector 窗口。如图 6 所示。

图 6 启动 Session 后的 Inspector 窗口

1. 在 Inspector 窗口，咱们能够利用“Select Elements”功能，经过点击元素显示 Native App 上的元素定位信息。如图 7 所示。

图 7 “Select Elements”功能示例

1. 在 Inspector 窗口，能够经过“Recording”功能生成不一样语言的自动化脚本。好比在启用了“Recording”功能后，点击“Compute Sum”按钮，就会生成如图 8 所示的自动化脚本片断。

图 8 “Recording”功能示例

了解了如何经过 Inspector 获取元素定位信息的方法以后，咱们就来正式开发基于 Appium 的第一个 Web App 和第一个 Native App 的测试用例。

基于 Appium 开发你的第一个 Native App 的测试用例

第一步，创建一个空的 Maven 项目，而后在 POM 文件中加入如图 9 所示的依赖。

在这个案例里面，咱们会使用 TestNG 组织测试用例，因此代码的第 14 行加入了 TestNG 的依赖。

第 19 行的 java-client 是关键，java-client 的做用是利用 Java 代码将测试用例中的操做步骤发送给 Appium Server，而后由 Appium Server 自动完成这些操做。

目前 Appium 支持多种编程语言，每种语言都有本身的 client，好比这里使用 Java 语言，因此引入了 java-client；若是你使用 Python 语言，那么就须要引用 python-client。

图 9 POM 文件加入 TestNG 和 java-client 的依赖

第二步，建立一个类，并命名为“iOS_NativeApp_DemoTest”，而后按照如图 10 所示的代码实现这个 class。

注意，这里的代码是真实的可执行 Java 代码，你能够直接拿去使用。

图 10 Native App 测试用例实例

• 代码第 21 行的 @BeforeTest，第 38 行的 @AfterTest，以及第 44 行的 @Test，都是利用了 TestNG 的 annotation 对函数进行标注。
  标有 @Test 的函数是真正的测试主体，全部测试相关的步骤都放在这个函数中；
  标有 @ BeforeTest 的函数会在 @Test 函数以前执行测试的相关准备工做，图中的代码用这个函数完成了 DesiredCapabilities 的设置，并用该 Capabilities 构造了 iosdriver；
  标有 @ AfterTest 的函数在 @Test 函数执行结束后执行，主要用于环境的清理和收尾，图示的代码用这个函数完成了 iosdriver 的退出操做。
• 代码的第 24-33 行构造了 DesiredCapabilities 对象，并对 APPIUM_VERSION、PLATFORM_VERSION、PLATFORM_NAME、AUTOMATION_NAME、DEVICE_NAME 和 APP 等参数进行了设置。其中 APP 的值是被测 Native App 安装包的绝对路径。
• 代码的第 46-58 行是测试用例的主体部分，主要分为三部分：
  第 47-50 行经过 iosdriver 的 findElementByAccessibilityId 方法定义了页面上的四个元素，分别是输入参数框 A、输入参数框 B、计算按钮和加法结果显示框。代码中具体的 AccessibilityId 能够经过 Inspector 获取。
  第 53-55 行经过自定义元素的操做执行加法运算。
  第 58 行经过断言方法 assertEquals 验证加法运算的结果。

第三步，为了运行这个 TestNG 的测试用例，咱们须要再添加一个 testng.xml 文件， 具体内容如图 11 所示。

图 11 testng.xml 文件示例

第四步，在保证 Appium Server 已经启动的状况下，就能够运行 testng.xml 执行测试了。 测试开始后，首先会自动启动基于 iOS 10.0 的 iPhone 7 模拟器，而后依次自动完成 WebDriverAgent（WDA）和被测 Native App 的安装。

WDA 是由 Facebook 开源的支持 iOS 自动化的代理工具，其底层经过 XCUItest 实现自动化。

接着，就会自动运行被测 Native App，并根据 @Test 函数中定义的步骤完成自动化测试的步骤和验证。

到此，咱们的第一个基于 Appium 的 Native App 自动化测试用例就设计完了。

基于 Appium 开发你的第一个 Web App 的测试用例

有了 Native App 测试用例的设计基础，再来实现一个基于 Appium 的 Web App 自动化测试用例就简单得多了。

第一步，在上述的 Maven 项目中再建立一个类，并命名为“iOS_WebApp_DemoTest”，而后按照如图 12 所示的代码实现这个类。

图 12 Web App 测试用例实例

代码的总体结构和上述 Native App 测试用例的彻底一致，只有一个地方须要特别注意：代码的第 29 行，因为 Web App 是基于浏览器的测试，因此这里不须要指定 App 这个参数，而是直接用 BROWSER_NAME 指定浏览器的名字便可。

对于测试用例的主体部分，也就是代码的第 45-47 行就比较简单了，首先打开 Safari 浏览器并访问“http://appium.io/”，接着用断言方法 assertEquals 验证页面的 Title 是否是“Appium: Mobile App Automation Made Awesome.”。其中，实际页面的 Title，能够经过 mobiledriver 的 getTitle 方法得到。

第二步，在 testng.xml 中添加这个 Web App 的测试用例，而后咱们就能够在 Appium Server 已经启动的状况下执行这个测试用例了。

这个测试用例，首先会自动启动基于 iOS 10.0 的 iPhone 7 模拟器，而后自动打开 Safari 浏览器并访问 Appium 的官方网站。执行完成后的界面以下图 13 所示。

图 13 测试用例执行完成的界面

进行到这里，咱们基于 Appium 开发的第一个 Web App 的自动化测试用例，也就开发完成了。

通过前面 Appium 环境搭建，以及两个测试用例的设计，相信你已经对 Appium 有了一个感性的认识了。那么，Appium 的实现原理又是怎样的呢？理解了 Appium 的使用原理，能够帮助你更好地使用这个工具，设计更加“有的放矢”的测试用例。

Appium 的实现原理

Appium 做为目前主流的移动应用自动化测试框架，具备极强的灵活性，主要体如今如下 5 个方面：

• 测试用例的实现支持多种编程语言，好比 Java、Ruby、Python 等；
• Appium Server 支持多平台，既有基于 Mac 的版本，也有基于 Windows 的版本；
• 支持 Web App、Native App 和 Hybird App 三大类移动应用的测试；
• 既支持 iOS，也支持 Android；
• 既支持真机，也支持模拟器。

实际应用中，你能够根据项目状况灵活组合完成移动应用的自动化测试。好比，用 Java 写 iOS 上的 Native App 的测试用例，测试用例跑在 Mac 平台的 iPhone 虚拟机上；或者，用 Python 写 Android 上的 Web App 的测试用例，测试用例经过 Windows 平台跑在 Android 的真机上。

这样的组合还有不少不少。那你有没有想过，Appium 为何能够作到如此强大的灵活性呢？这就要从 Appium 的基本原理讲起了。

要真正理解 Appium 的内部原理，你能够把 Appium 分红三大部分，分别是 Appium Client、Appium Server 和设备端。这三部分的关系如图 14 所示。

图 14 Appium 内部原理

咱们先来看看处于中间位置的 Appium Server。

Appium Server 有 Mac 和 Windows 版本，也就是说 Appium Server 能够运行在 Mac 或者 Windows 电脑上。本质上，Appium Server 是一个 Node.js 应用，接受来自 Appium Client 的请求，解析后经过 WebDriver 协议和设备端上的代理打交道。

• 若是是 iOS，Appium Server 会把操做请求发送给 WebDriverAgent（简称 WDA），而后 WDA 再基于 XCUITest 完成 iOS 模拟器或者真机上的自动化操做；
• 若是是 Android，Appium Server 会把操做请求发送给 appium-UIautomator2-server，而后 appium-UIautomator2-server 再基于 UIAutomator V2 完成 Android 模拟器或者真机上的自动化操做。

Appium Client 其实就是测试代码，使用对应语言的 Client 将基于 JSON Wire 协议的操做指令发给 Appium Server。

总体来讲，Appium 的内部原理能够总结为：Appium 属于 C/S 架构，Appium Client 经过多语言支持的第三方库向 Appium Server 发起请求，基于 Node.js 的 Appium Server 会接受 Appium Client 发来的请求，接着和 iOS 或者 Android 平台上的代理工具打交道，代理工具在运行过程当中不断接收请求，并根据 WebDriver 协议解析出要执行的操做，最后调用 iOS 或者 Android 平台上的原生测试框架完成测试。

总结

目前网络上，Appium 工具使用相关的资料都比较零散，为此我以最新版本的 Appium Desktop 1.6.2 和 Appium Server 1.8.1 为例，手把手地带你搭建了 iOS 环境，以及 Appium 测试环境，并介绍了如何经过 Appium Inspector 来定位页面元素。

搭建好了测试环境后，分别针对 Native App 和 Web App 这两类移动应用，基于 Appium 实现了两个测试用例，这也是我在这个专栏里面，为你实现的第一个移动应用的测试用例。虽然测试需求比较简单，可是你也能够从中体会到移动应用测试用例设计的思想、方法。

最后，介绍了 Appium 的实现原理：它属于 C/S 架构，Appium Client 经过第三方库向 Appium Server 发起请求，Appium Server 接受请求，而后和移动平台上的代理工具打交道，代理工具在运行过程当中不断接收来自 Appium Server 的请求，并解析出要执行的操做，最后调用移动平台原生的测试框架完成测试操做。