Appium核心应用(四)
从识别到的页面元素来看,该“用户名”文本框并没有对应的resource-id属性,也没有相应的content-desc属性,所以我们只有通过XPath来完成对象的操作,其它页面元素也是如此。另外,针对Web应用的测试,Appium的代码并没有其它特别之处,唯一有一些变化的是需要指定浏览器名称和对应的启动浏览器应用程序的Package和Activity而已。下述代码完成了对蜗牛进销存系统的登录操作。
本周分享《Appium核心应用》实验中的Web应用测试。
回顾上周内容,请点击:
Web应用程序(即基于浏览器的应用)也是移动设备上很常见的应用类型,但是由于其操作基于浏览器,基于Web规范,所以即使不使用Appium,直接使用Selenium WebDriver也是可以进行测试的。只不过由于浏览器类型不一样,所使用的硬件设备不一样,即使我们在PC端完成了Web应用的测试,我们也无法直接给定明确的结论。所以更保险的方式还是基于移动端来对Web应用进行测试。这个过程中,Appium同样可以帮助我们完成测试工作。
首先在移动设备或模拟器上打开浏览器,再访问一个Web页面,比如蜗牛进销存。同时利用UI Automator Viewer对页面中的对象进行识别,我们来看如下的画面。
根据上述截图可以看到,默认情况下UI Automator Viewer并不能识别到Web页面中的元素,其识别到的最小元素为当前浏览器窗口,而无法进一步识别到其中的元素,如登录界面的文本框或按钮等。那么针对这一情况又该如何解决呢?事实上,Appium已经为我们提供了良好的解决方案。通过如下步骤即可完成对Web页面元素的识别处理:
1)确保AppiumBootstrap.jar文件已经成功运行(可通过Android文件管理器查看目录/data/local/tmp是否存在该文件即可,并且确保该文件是与当前Appium配套的最新版本)。
2)打开Windows命令行窗口,并通过ADB运行如下命令,让AppiumBootstrap.jar启用UI Automator Viewer完成对页面元素的获取。
adb -s 127.0.0.1:62001 shell uiautomator runtest AppiumBootstrap.jar -c io.appium.android.bootstrap.Bootstrap -e disableAndroidWatchers false |
3)运行上述命令后,按Ctrl+C退出该命令,同时退出浏览器,重启Lazy UI Automator Viewer。
4)再次打开Web浏览器,并访问相应网址。同时打开Lazy UI Automator Viewer,在上方工具栏中点击“Device Screenshot with Compressed Hierarchy”按钮完成Web页面元素的识别。如图所示。
从识别到的页面元素来看,该“用户名”文本框并没有对应的resource-id属性,也没有相应的content-desc属性,所以我们只有通过XPath来完成对象的操作,其它页面元素也是如此。另外,针对Web应用的测试,Appium的代码并没有其它特别之处,唯一有一些变化的是需要指定浏览器名称和对应的启动浏览器应用程序的Package和Activity而已。下述代码完成了对蜗牛进销存系统的登录操作。
from appium import webdriver from time import sleep
desired_caps = {} # 定义webdriver的兼容性设置字典对象 desired_caps['platformName'] = 'Android' # 指定测试Android平台 desired_caps['platformVersion'] = '4.4.2' # 指定移动端的版本号 desired_caps['deviceName'] = 'Appium' # 指定设备名称 desired_caps['broswerName'] = 'Chrome' # 指定浏览器类型 desired_caps['unicodeKeyboard'] = 'True' # 指定可输入中文 desired_caps['appPackage'] = 'com.android.browser' # 指定要启动的包 desired_caps['appActivity'] = '.BrowserActivity' # 指定启动的主类程序 desired_caps['udid'] = '127.0.0.1:62001' # 指定模拟器设备编号(adb devices输出结果)
driver = webdriver.Remote('http://127.0.0.1:4723/wd/hub', desired_caps)
driver.get("http://192.168.2.29:8080/WoniuSales/") sleep(5)
# 找到用户名文本框并输入用户名 driver.find_element_by_xpath("//android.view.View[@content-desc='蜗牛进销存-首页']/android.widget.EditText[1]").send_keys("admin")
# 找到密码文本框并输入密码 driver.find_element_by_xpath("//android.view.View[@content-desc='蜗牛进销存-首页']/android.widget.EditText[2]").send_keys("admin123")
# 找到验证码文本框并输入验证码 driver.find_element_by_xpath("//android.view.View[@content-desc='蜗牛进销存-首页']/android.widget.EditText[3]").send_keys("0000")
# 找到登录按钮并进行点击 driver.find_element_by_xpath("//android.widget.Button[contains(@content-desc,'登录')]").click()
sleep(3) # 利用登录成功后的销售出库页面中的条码文本框是否存在来进行断言 barcode = driver.find_element_by_xpath("//android.view.View[@content-desc='蜗牛进销存-销售出库']/android.widget.EditText[1]") if (barcode != None): print("登录功能测试-成功.") else: print("登录功能测试-成功.")
driver.quit() |
从上述测试脚本可以看出,Appium在处理Web页面元素时,几乎全都依赖于XPath的识别方式。而Web页面元素自带一些重要识别属性如ID或Class等,均无法发挥用途,而是被映射成了Android系统的控件类型。比如一个Web页面的文本框<input>标签,却被映射成了android.widget.EditText,这自然就违背了Web元素应有的意义。另外一个方面,随着浏览器版本的更新,以及Appium开发的相对滞后,很有可能存在无法对浏览器应用进行对象识别的情况。
事实上,Appium针对纯Web页面的处理方式,其实反而更适合于混合应用的测试。同样的,我们也可以看出,Appium虽然的确可以对原生应用,混合应用和Web应用进行测试,但是明显是把重心放在原生应用上。当然,从另外一个角度来说,针对Web应用而言,由于使用标准的浏览器,统一遵循HTML和JavaScript规范,在功能和兼容性方面的测试相对出问题的概率不会太高。
所以多数情况下,可以通过Selenium在PC端来进行,也能解决大部分问题。