实战演练：10分钟玩转Appium脚本转换+自动化测试实例

2.2 Appium与手机的联通性验证

在执行脚本前，需确定被测终端是否可以与Appium server进行通讯，验证被测app是否能被调起，Appium desktop提供的会话检查器可以满足此需求。Appium desktop会话管理器提供了一个编辑器可以生成desired_caps。SoloPi提供的converter转换后该变量需要根据实际重新赋值，参数包含platformName，platformVersion，deviceName，appPackag，appActivity，automationName等，具体如下

1、deviceName可以通过命令adb devices获取。

2、appPackag、appActivity获取前，测试手机连接电脑，启动被测APP，执行以下命令：

adb shell dumpsys activity |find "mFocusedActivity"（注：android 7.0以下）或adb shell dumpsys window w|findstr \/|findstr name=（注：android 7.0及以上）。执行后获得appPackage 和 appActivity ，其中appPackage = com.android.bankabc，

appActivity=com.alipay.mobile.quinox.LauncherActivity。

需要注意的是，对于有启动页的app来说，appActivity需要设置启动页的值，也就是说在启动页打开后立即使用adb shell命令。目前Appium 1.51.1和安卓10使用uiautomator2有兼容性问题，automationName使用uiautomator1。启动Appium desktop打开会话管理器，将上述值填入，编辑器自动生成JSON格式的字符串，该JSON串需要赋值给desired_caps变量，如下图所示，会话管理器启动后，如显示Appium编辑窗口，即证明连接成功。

2.3完善Appium脚本

SoloPi Converter将导出的JSON文件转换为Appium脚本，转换后的代码需要简单修改即可执行，需要修改的内容如下。

1、修改连接参数

SoloPi转为的Appium脚本缺少关键参数，首先将上文中的JSON赋值给desired_caps，定义remote server，测试用的一部安卓10系统的手机存在兼容问题，这里指定automationName为uiautomator1。

2、修改脚本截图存储路径

此段代码由转换工具自动生成，获得的SCREEN可供测试人员后续使用，如无需要可将该段代码注释以避免编译失败。通过使get_screenshot_as_file获取设备屏幕截图后得到其width, height值，存入SCREEN变量中。这里脚本的临时存储路径默认为“/tmp/xxx.png”，修改为本地实际路径即可。

3、修改步骤函数

① 在原代码中使用tag_name定位元素，该函数是通过H5的tag标签查找，测试过程中转换时选择的是classname，需要修改。此处生成的代码首先获取app当前节点类型的rect属性（该属性获取元素的大小和维度，这里没直接使用返回屏幕大小的相关函数，可能为了考虑app在窗口模式运行/或是有底部bar的情况），为后续屏幕滑动的相关参数提供基础。

② 下图中自定义函数swipe将Appium框架的滑屏函数swipe进行封装，Appium框架函数swipe的参数包括startx、starty、endx、endy，duration，其中startx，starty，endx，endy需要输入屏幕的像素坐标。SoloPi原始脚本中记录的起始和终止位置的坐标偏移区间为[0,1]（该值表示位置相对屏幕中心点的偏移量，默认屏幕左上角为(0,0)、右下角为(1,1)）。

在原始代码中，结束滑动的坐标值出现了负数，手动将其改为正确的值，这里最好手工debug获得满意的位置。

自定义swipe方法将参数传送给了load_x_y加工成屏幕像素坐标，将2组偏移值用load_x_y处理，得到滑动的实际像素坐标值(fx,fy)和(tx,ty)。

注：在load_x_y中，rect.left和rect.top也是转换工具自动生成的，从步骤①返回的字典中并无此项，要删除。在索引width、height值时，也要改为字典的取值方式。此外，swipe中的driver参数也要删除。

③修改具体执行步骤，从Appium 1.5开始已经移除对by_name的支持。

替换为uiautomator方法来查找text：

assert driver.find_element_by_android_uiautomator('text(\"尊敬的用户，您好\")').text == "尊敬的用户，您好"

隐藏键盘需做如下替换：

④ 修改后，脚本执行完成。

4、截屏记录每一步执行过程

执行过程可以通过写日志的方式来记录，但对于移动端判断错误具体发生的情况来说，并不是最优。对每一步骤执行后进行截图保存，更有利于测试人员定位问题原因。执行过程中，通过增加一个截图函数放在每一步的后面。测试结束后，截图即可自动生成在文件夹中。

2.4使用jenkins远程调用执行

使用jenkins之前，需要先在远程机器上使用PyCharm执行，验证客户端与服务器端的联通性，然后启动jenkins，通过建一个空项目，并为测试用例的目录建立一个环境变量，便于后续修改。然后输入编译命令，保存该项目后编译，结果执行成功。

需要注意的是，脚本中截图路径要改为jenkins服务器的路径，而非Appium server服务器上的路径，这取决于jenkins是否和Appium server部署在一起。

2.5真机并发执行

上述的操作中，只使用了1台android设备，下面介绍多台设备执行的方法。首先验证和服务器的联通性，修改desired_caps，使用2台安卓设备，分别为安卓7.0和10.0，首先使用会话编辑器做联通性验证。

使用命令查看2台设备已经连接到Appium server后，启动2个Appium server，每个server与其中一台手机通讯，如果4台手机，需要启动4个Appium server。启动2个Appium时，要对第二个Appium设置独立的端口。服务器正常启动后，执行脚本中，用例主流程定义在run方法里，run方法包含3个参数，url和desired_caps是启动会话必须的参数，picloc是指定截图生成的位置。

通常编写多线程或者多进程多做使用threading和multiprocess来实现，2种方法，如图所示：

上述代码执行后，实际是按CPU时间分片来执行的，如果代码逻辑很短，或执行很快，就会立即得到结果，如果代码执行效率很慢，最后的结果实际上是在串行操作。上述代码中，MEIZU和honorV20在实际执行过程中，MEIZU会先执行一遍，然后honorV20才会执行，循环反复。

因此，这里使用concurrent.futures模块下的ProcessPoolExecutor进程池，该方法可以利用多核cpu的优势，让脚本并行执行。Submit将实例提交到进程池中，如果CPU有空闲核心，就会调度进程执行。

主函数如下，这里需要注意的是，当多台设备并行执行的时候，需要在 desired_caps中指定参数udid，通过adb devices获取，newCommandTimeout指服务器新获得命令的超时时间：

执行后，可以看到进程完成不是“串行”执行的，最后的执行结果，两台机器可以同步一起执行，并将截图保存在各自的文价夹中。

本文主要从实践操作的角度，以手机银行界面测试为例，比较详细地描述了基于SoloPi执行过程录制转为Appium脚本的过程，并对需要使用的工具和环境、参数等配置进行了说明。通过将Appium脚本集成式jenkins，实现了脚本的自动化部署及自动化执行和结果存储，并描述了单机执行和多机执行的实践过程。