移动端APP的测试处于不断探索，不断进化的过程中，而手机银行是目前各大银行金融科技战争的主要阵地，如何更好更快地对手机银行进行测试是个热门话题，也是个值得深入研究的课题。本文以某行手机银行测试为例，描述了SoloPi用例执行录制转为Appium脚本后集成至jenkins，并完成自动化部署后的真机并发执行实践流程，并对Appium 1.15.1和安卓10使用中存在的一些问题提供了解决方法，希望能够对移动端APP的测试提供更多的借鉴。
1、SoloPi与用例的自动化构建及测试
SoloPi是蚂蚁金服研发的一款移动端APP测试工具，提供脚本录制、编辑、回放，结果展示以及一机多控，即通过设备间的socket通讯实现1台手机可以控制多台手机执行脚本，等功能，其测试用例的录制和执行等操作均在手机端的SoloPi APP中完成。通过官方提供的转换工具可将SoloPi用例转换为Appium脚本，这为用例的自动化部署及构建之jenkins执行提供了条件。如下图所示，本流程可以总结为以下四个步骤，
1、SoloPi录制测试的交易，回放通过后，导出测试用例为JSON文件；
2、例用SoloPi官方提供的转换工具，将JSON文件转换为Appium脚本；
3、修改脚本中的desired_caps{}，webdriver.Remote()参数，并完善脚本步骤实现并发；
4、使用jenkins管理Appium脚本执行。
2. 以手机银行为例的过程分解与实践
执行之前，需要保证基本的环境和工具可用，主要需要安装的工具和设置如下，
1、安装android studio，设置环境变量Path，
C:\Users\XXX\AppData\Local\Android\Sdk\platform-tools\
C:\Users\XXX\AppData\Local\Android\Sdk\build-tools\29.0.3\
2、安装python3和Appium-python-Client v0.5，
3、安装Appium Desktop v1.15.1，
4、安装Jenkins 2.190.3。
2.1 SoloPi用例录制及JSON文件导出
启动SoloPi，需要连接电脑开启adb授权，这里以某行手机银行APP的金融小秘书执行登录为示例进行步骤分解。首先在APP首页下滑到金融小秘书，点击小秘书，完成登录操作，具体步骤如下图所示，使用SoloPi Converter将导出的JSON文件转换为Appium脚本，这里需要选择生成脚本使用的元素查找方法，包括class_name，ResourceId，Xpath，Text...如节点含文本就选Text。
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是指定截图生成的位置。
Class case1:{ ... Case method def run(self, url, desired_caps, picloc): Run method... ... } |
通常编写多线程或者多进程多做使用threading和multiprocess来实现，2种方法，如图所示：
上述代码执行后，实际是按CPU时间分片来执行的，如果代码逻辑很短，或执行很快，就会立即得到结果，如果代码执行效率很慢，最后的结果实际上是在串行操作。上述代码中，MEIZU和honorV20在实际执行过程中，MEIZU会先执行一遍，然后honorV20才会执行，循环反复。
因此，这里使用concurrent.futures模块下的ProcessPoolExecutor进程池，该方法可以利用多核cpu的优势，让脚本并行执行。Submit将实例提交到进程池中，如果CPU有空闲核心，就会调度进程执行。
主函数如下，这里需要注意的是，当多台设备并行执行的时候，需要在 desired_caps中指定参数udid，通过adb devices获取，newCommandTimeout指服务器新获得命令的超时时间：
if __name__ == '__main__': desired_caps_honorV20 = { # 这里定义荣耀V20的连接参数 "newCommandTimeout": "180", "udid": "5ENDU19425000819" } honorV20 = Case1() desired_caps_meizu = { # 这里定义魅族的连接参数 "newCommandTimeout": "180", "udid": "91QTBNQ22N7D" } MEIZU = Case1() executor = ProcessPoolExecutor() # 不填则默认为cpu的个数 task1 = executor.submit(MEIZU.run, "http://192.168.1.21:4725/wd/hub", desired_caps_meizu, "MEIZU") task2 = executor.submit(honorV20.run, "http://192.168.1.21:4723/wd/hub", desired_caps_honorV20, "honorV20") task = [task1, task2] for t in task: print(t.result()) |
执行后，可以看到进程完成不是“串行”执行的，最后的执行结果，两台机器可以同步一起执行，并将截图保存在各自的文价夹中。
本文主要从实践操作的角度，以手机银行界面测试为例，比较详细地描述了基于SoloPi执行过程录制转为Appium脚本的过程，并对需要使用的工具和环境、参数等配置进行了说明。通过将Appium脚本集成式jenkins，实现了脚本的自动化部署及自动化执行和结果存储，并描述了单机执行和多机执行的实践过程。手机银行测试的方式方法需要在实践中不断探索，优秀的互联网测试前沿技术和工具，对商业银行的引领和借鉴意义正在不断加强，希望本文的测试实践能够对移动端APP界面级测试提供有益借鉴，促进测试领域不断开拓新思路，新境界。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
