appium自动化测试环境搭建,python appium自动化测试框架

　　先看整体流程图。

　　APP整体架构为C/S模式，整体流程(返回顺序相反):

　　脚本请求—— 4723端口appium server ——解析参数到PC 4724端口3354发送到device 4724端口3354，通过device 4724端口发送到bootstrap.jar 3354 bootstrap.jar，发送命令到uiautomator。

　　1.该脚本请求—— 4723端口appium服务器：

　　首先我们要打开appium服务，即appium server，也就是在命令行用appium命令打开的东西。默认情况下，端口4723受到监控。端口723处理脚本，基于WebDriver协议。Webdriver是按照服务器-客户端的经典设计模式设计的，它的功能是启动基于WebDriver Wire协议的appium服务。接下来，脚本和appium服务器之间的通信实际上是对appium服务器的HTTP请求。在请求的主体中，将使用WebDriver Wire协议指定的JSON格式字符串来告诉appium服务我们希望设备接下来做什么。读到这里，难免有同学会有疑问，因为有文档说脚本发送请求是基于Json wire协议的。首先这是完全正确的。接下来解释一下：

　　APP中的Json wire协议继承了selenium的webdriver wire协议，并进行扩展，使Json wire协议能够控制不同移动设备的行为。如果你对webdriver这个术语感到陌生，下一个词会很熟悉——Selenium。Selenium是一个浏览器自动化框架。Selenium主要由三个工具组成。第一个工具SeleniumIDE是Firefox的扩展插件，支持用户录音和回访测试。录音/回访模式有局限性，所以不适合很多用户。因此，第二个工具——Selenium WebDriver提供了各种语言环境中的API，以支持更多的控制权，并编写符合标准软件开发实践的应用程序。最后一个工具——SeleniumGrid，通过使用Selenium API，帮助工程师控制分布在一系列机器上的浏览器实例，并支持并发运行更多测试。在项目内部，它们分别被称为“IDE”、“WebDriver”和“Grid”。

　　那么什么是webdriver wire协议呢：

　　在创建WebDriver的过程中，Selenium会首先确认浏览器的原生组件是否可用，版本是否匹配。然后在目标浏览器中启动一整套web服务。这套web服务使用的是Selenium自己设计定义的协议，名字是The WebDriver Wire Protocol，，但是我们这里对应的浏览器指的是Appium。

　　WebDriver Wire协议是通用的，也就是说，无论是启动FirefoxDriver还是ChromeDriver，都会在某个端口启动基于该协议的Web服务。对应Appium，可以理解为AppiumDriver。接下来，当我们调用WebDriver的任何一个API时，都需要借助aComandExecutor发送一个命令，这个命令实际上是对端口上的Web服务的HTTP请求。在我们的HTTP请求体中，我们将告诉Selenium我们希望浏览器(设备)下一步用WebDriver Wire协议指定的JSON格式的字符串做什么。

　　这里可能会有一些疑问。上面说的是脚本请求操作设备，但前提是，我们要测试谁的操作？这里我们引入一个新术语：desiredCapabilities。了解了以上内容之后，再来看看脚本是如何将desiredCapabilities传输到appium server的就好很多了。脚本通过json Wire协议将测试设备信息以Json格式发送到服务器，测试设备信息被携带在期望的能力中。这个东西本质上是一个键值形式的对象，所需功能最重要的功能是告诉服务器这个测试的上下文。这次是要进行浏览器测试还是移动测试？如果是移动测试，是android还是ios？如果是android，应该测试哪个app？这些服务器想要的能力的问题一定要回答，否则，服务器是不会买的。对于我们现在所说的，Android的影响就是无法完成app的推出。

　　那么，测试设备信息告知后，是否可以开始测试？答案是：不会，这里我们要引入另一个名词：session。会话就是会话。在webdriver/appium中，您的所有工作都可以在会话开始后完成。客户端创建一个会话，在会话中通过http向appium server发送请求，appium server解析请求，完成相应的操作并返回响应。

　　会话在计算机中被称为“会话控制”，尤其是在网络应用中。Session对象存储特定用户会话所需的属性和配置信息，实际上是desiredCapabilities中的配置信息参数。该脚本可以通过POST /session的URL打开会话，然后传入所需的功能。由于这是第一次请求创建会话，因此没有创建会话id。所以appium服务器会调用AndroidDriver(app ium升级到2.0.0后，原来的AppiumDriver函数变成了抽象函数，需要改成Android driver)为客户端生成一个会话，以及与这个会话相关联的一个会话id。该会话id将被返回给客户端，以便保存在该响应中。当下一个脚本发送操作请求时，它会将自己的会话id作为惟一标识符，代表打开的设备。Appium server将根据此会话id检索此会话以供使用，脚本发送给appium server的请求存在于创建的会话中。

　　Session的作用是将设备的状态信息保存在appium service上，以备随时访问。在许多操作中，存储在会话对象中的配置信息不会丢失，而是会一直存在于整个用户会话中。整个测试过程中，设备和程序的连接不会断开，不需要每次都发送一个带有配置信息的请求。程序知道要测试哪个设备。测试完成后，您需要关闭webdriver。driver.quit()将关闭所有相关的窗口和会话，还将关闭进程。

　　2.将参数解析到PC的端口——，并将它们发送到设备4724的端口——。通过设备的端口4724向uiautomator发送命令到bootstrap.jar 3354 bootstrap.jar:

　　在成功创建会话之前，将bootstrap.jar放入手机，并开启了设备上基于appium bootstrap的socket服务。该机器和boostrap之间的通信端口号4724用于与Android设备通信。默认情况下，它监听端口4724并等待客户端的连接。

　　Appium server将脚本请求解析到端口4724，并通过设备的端口4724转发解析后的请求。此时Appium server作为socket服务的客户端，通过端口4724主动请求设备上的socket服务，即向socket服务发送请求。也就是Bootstrap.jar，bootstrap.jar再把Appium的命令转换成uiautomator的命令，供uiautomator处理。有所求，必有回报。当套接字收到请求时，它会做出响应。原始路由将返回给脚本，然后脚本将发出下一个请求。

　　网络上的两个程序通过双向通信连接交换数据，通信连接的一端称为套接字。appium和手机的通信过程主要是一个数据交换的过程。socket的作用是实现双向通信。它需要一对端口号，对应4724。手机的bootstrap是socket-server，appium server是socket-client。

　　关于socket的通信原理，先从服务器说起。服务器首先初始化套接字，然后绑定到端口，监听端口，调用accept来阻塞，等待客户端连接。此时，如果客户端初始化一个套接字，然后连接到服务器，如果连接成功，则客户端和服务器之间的连接建立。客户端发送数据请求，服务器接收并处理请求，然后向客户端发送响应数据，客户端读取数据，最后关闭连接，一次交互结束。

　　本文转载自：https://www.jianshu.com/p/30b3b2d6b901

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。