• 从0搭建新项目平台后台测试环境


    写在前面

    前两天微信突然发来一条系统消息,提示DebugTalk可以开通原创标识了(同时也有了评论功能),虽然一直在期待,但没想到来得这么快,着实是个不小的惊喜。

    另外,最近在公众号后台也收到好几个朋友的信息,有的是询问某某部分什么时候能发布,有的是希望能加快更新速度。说实话,收到这样的信息虽然会有压力,但真的挺开心的,因为这说明DebugTalk至少能给一部分人带去价值,这说明这件事本身还是值得坚持去做的。

    不过,在更新频率这件事儿上,的确是要跟大家说抱歉了。因为DebugTalk发布的内容全都是原创,主题基本上都是来源于我日常测试工作的经验积累,或者我近期学习一些测试技术的收获总结,这也意味着,我写的东西很多时候并不是自己完全熟悉的(完全掌握的东西也没有足够的动力专门花时间去写)。

    就拿最近连载的《从0到1搭建移动App功能自动化测试平台》系列来说,由于我也是边探索边总结,因此中途难免会遇到一些意想不到的坑,造成额外的耗时,而且为了保证文章能尽量通俗易通,我也需要对涉及到的内容充分进行理解,并且经过大量实践进行验证,然后才能站在半个初学者、半个过来人的角度,重新整理思路,最后以尽可能流畅的思路将主题内容讲解清楚。

    基于这些原因,DebugTalk要做到每日更新是很难了,但是保证每周发布1~2篇还是可以的,希望大家能理解。

    关于UI控件

    在上一篇文章中,我们成功地通过Appium Inspector调用模拟器并运行iOS应用,iOS的自动化测试环境也已全部准备就绪了。

    那么接下来,我们就可以开始实现自动化测试了么?

    貌似还不行。在开始之前,我们先想下什么是APP功能自动化测试。

    APP的功能自动化测试,简单地来说,就是让功能测试用例自动地在APP上执行。具体到每一个测试用例,就是能模拟用户行为对UI控件进行操作,自动化地实现一个功能点或者一个流程的操作。再细分到每一步,就是对UI控件进行操作。

    因此,在正式开始编写自动化测试用例之前,我们还需要熟悉如何与APP的UI控件进行交互操作。

    在iOS系统中,UI控件有多种类型,常见的有按钮(UIAButton)、文本(UIAStaticText)、输入框(UIATextField)等等。但不管是对什么类型的UI控件进行操作,基本都可以分解为三步,首先是获取目标控件的属性信息,然后是对目标控件进行定位,最后是对定位到的控件执行动作

    获取UI控件信息

    在Appium中,要获取iOS的UI控件元素信息,可以采用两种方式:一种是在前一篇文章中提到的Appium Inspector,另一种是借助Ruby实现的appium_console,在Terminal中通过命令进行查询。

    Appium Inspector

    运行Appium Server,并启动【Inspector】后

    现对照着这张图对Appium Inspector进行介绍。

    在右边部分,是启动的模拟器,里面运行着我们的待测APP。我们可以像在真机中一样,在模拟器中执行任意功能的操作,当然,模拟器跟真机毕竟还是有区别的,跟传感器相关的功能,例如摄像头、重力感应等,是没法实现的。

    在左边部分,就是Appium Inspector。Inspector主要由如下四个部分组成:

    • 预览界面区:显示画面与模拟器界面一致;不过,当我们在模拟器中切换界面后,Inspector的预览区中显示图像并不会自动同步,若要同步,需要点击【Refresh】按钮,然后Inspector会将模拟器当前UI信息dump后显示到预览区;在预览区中,可以点击选择任意UI控件。
    • UI信息展示区:展示当前界面预览区中所有UI元素的层级关系和UI元素的详细信息;在预览区中点击选择任意UI控件后,在“Details”信息框中展示选中控件的详细信息,包括name、label、value、xpath等属性值;通过层级关系,我们也能了解选中控件在当前界面树状结构中所处的具体位置。
    • 交互操作区:模拟用户在设备上的操作,例如单击(tap)、滑动(swipe)、晃动(shake)、输入(input)等;操作动作是针对预览界面区选中的控件,因此在操作之前,务必需要先在预览区点击选择UI元素。
    • 脚本生成区:将用户行为转换为脚本代码;点击【Record】按钮后,会弹出代码区域;在交互操作区进行操作后,就会实时生成对应的脚本代码;代码语言可通过下拉框进行选择,当前支持的语言类型有:C#、Ruby、Objective-C、Java、node.js、Python。

     

    在实践操作中,Inspector最大的用途就是在可以可视化地查看UI元素信息,并且可以将操作转换为脚本代码,这对初学者尤为有用。

    例如,在预览区点击选中按钮“BUY NOW”,然后在UI信息展示区的Details窗口就可以看到该按钮的所有属性信息。在交互操作区点击【Tap】按钮后,就会模拟用户点击“BUY NOW”按钮,并且在脚本区域生成当次按钮点击的脚本(选择Ruby语言):

    find_element(:name, "BUY NOW >").click

    如上就是使用Appium Inspector的一般性流程。

    Appium Ruby Console

    有了Appium Inspector,为什么还需要Appium Ruby Console呢?

    其实,Appium Ruby Console也并不是必须的。经过与多个熟悉Appium的前辈交流,他们也从未用过Appium Ruby Console,这说明Appium Ruby Console并不是必须的,没有它也不会影响我们对Appium的使用。

    但是,这并不意味着Appium Ruby Console是多余的。经过这些天对Appium的摸索,我越发地喜欢上Appium Ruby Console,并且使用的频率越来越高,现在已基本上很少使用Appium Inspector了。这种感觉怎么说呢?Inspector相比于Ruby Conosle,就像是GUI相比于Linux Terminal,大家应该能体会了吧。

    Appium Inspector的功能是很齐全,GUI操作也很方便,但是,最大的问题就是使用的时候非常慢,在预览界面区切换一个页面常常需要好几秒,甚至数十秒,这是很难让人接受的。

    在上一节中也说到了,Inspector最大的用途就是在可以可视化地查看UI元素信息,并且可以将操作转换为脚本代码。但是当我们对Appium的常用API熟悉以后,我们就不再需要由工具来生成脚本,因为自己直接写会更快,前提是我们能知道目标控件的属性信息(type、name、label、value)。

    在这种情况下,如果能有一种方式可以供我们快速查看当前屏幕的控件属性信息,那该有多好。

    庆幸的是,在阅读Appium官方文档时,发现Appium的确是支持命令行方式的,这就是Appium Ruby Console。

    Appium Ruby Console是采用Ruby语言开发的,在使用方式上面和Ruby的irb很类似。

    在使用Appium Ruby Console时,虚拟机的配置信息并不会从GUI中读取,而是要通过配置文件进行指定。

    配置文件的名称统一要求为appium.txt,内容形式如下所示:

    1. [caps]
    2. platformName = "ios"
    3. platformVersion = '9.3',
    4. app = "/path/to/UICatalog.app.zip"
    5. deviceName = "iPhone Simulator"

    其中,platformName指定虚拟机操作系统类型,“ios”或者”android”;platformVersion指定操作系统的版本,例如iOS的’9.3’,或者Android的’5.1’;app指定被测应用安装包的路径。这三个参数是必须的,与Inspector中的配置也能对应上。

    在使用Appium Ruby Console时,首先需要启动Appium Server,通过GUI或者Terminal均可。

    然后,在Terminal中,进入到appium.txt文件所在的目录,执行arc命令即可启动Appium Ruby Console。arc,即是appium ruby console首字母的组合。

    1. ➜ ls
    2. appium.txt
    3. ➜ arc
    4. [1] pry(main)>

    接下来,就可以通过执行命令查询当前设备屏幕中的控件信息。

    使用频率最高的一个命令是page,通过这个命令可以查看到当前屏幕中所有控件的基本信息。

    例如,当屏幕停留在前面截图中的页面时,执行page命令可以得到如下内容。

    1. [1] pry(main)> page
    2. UIANavigationBar
    3. name: HomeView
    4. id: Home => Home
    5. => m
    6. 去看看 => View
    7. UIAButton
    8. name, label: tabbar category gray
    9. UIAImage
    10. name: debugtalk_logo.png
    11. UIAButton
    12. name, label: tabbar cart gray
    13. UIATableView
    14. value: rows 1 to 4 of 15
    15. UIAPageIndicator
    16. value: page 2 of 2
    17. UIATableCell
    18. name: For the first time ever in a hand held camera, the Osmo brings professional, realtime cinema-quality stabilization.
    19. id: 米 => m
    20. UIAStaticText
    21. name, label, value: For the first time ever in a hand held camera, the Osmo brings professional, realtime cinema-quality stabilization.
    22. id: 米 => m
    23. UIAStaticText
    24. name, label, value: OSMO
    25. UIAButton
    26. name, label: SHOP NOW >
    27. UIATableCell
    28. name: Ronin
    29. UIAStaticText
    30. name, label, value: Ronin
    31. UIAStaticText
    32. name, label, value: Phantom
    33. id: 米 => m
    34. ... (略)
    35. UIAButton
    36. name, label: Store
    37. value: 1
    38. id: 门店 => Store
    39. ... (略)
    40. UIAButton
    41. name, label: My Account
    42. id: My Account => My Account
    43. nil

    通过返回信息,我们就可以看到所有控件的type、name、label、value属性值。如果在某个控件下没有显示label或value,这是因为这个值为空,我们可以不予理会。

    由于page返回的信息太多,可能不便于查看,因此在使用page命令时,也可以指定控件的类型,相当于对当前屏幕的控件进行筛选,只返回指定类型的控件信息。

    指定控件类型时,可以通过string类型进行指定(如 page “Image”),也可通过symbol类型进行指定(如 page :cell)。指定的类型可只填写部分内容,并且不分区大小写。

    1. [2] pry(main)> page "Image"
    2. UIAImage
    3. name: debugtalk_logo.png
    4. nil
    5. [3] pry(main)> page :cell
    6. UIATableCell
    7. name: DebugTalk’s smartest flying camera ever.
    8. id: 米 => m
    9. UIATableCell
    10. name: Ronin
    11. UIATableCell
    12. name: Phantom
    13. id: 米 => m
    14. nil

    如果需要查看当前屏幕的所有控件类型,可以执行page_class命令进行查看。

    1. [4] pry(main)> page_class
    2. 14x UIAButton
    3. 8x UIAStaticText
    4. 4x UIAElement
    5. 4x UIATableCell
    6. 2x UIAImage
    7. 2x UIAWindow
    8. 1x UIAPageIndicator
    9. 1x UIATableView
    10. 1x UIAStatusBar
    11. 1x UIANavigationBar
    12. 1x UIATabBar
    13. 1x UIAApplication
    14. nil

    基本上,page返回的控件信息已经足够满足绝大多数场景需求,但有时候情况比较特殊,需要enabled、xpath、visible、坐标等属性信息,这时就可以通过执行source命令。执行source命令后,就可以返回当前屏幕中所有控件的所有信息,以xml格式进行展现。

    定位UI控件

    获取到UI控件的属性信息后,就可以对控件进行定位了。

    首先介绍下最通用的定位方式,find。通过find命令,可以实现在控件的诸多属性值(namelabelvaluehint)中查找目标值。查询时不区分大小写,如果匹配结果有多个,则只返回第一个结果。

    1. [5] pry(main)> find('osmo')
    2. #<Selenium::WebDriver::Element:0x..febd52a30dcdfea32 id="2">
    3. [6] pry(main)> find('osmo').label
    4. "Osmo"

     另一个通用的定位方式是find_element,它也可以实现对所有控件进行查找,但是相对于find,可以对属性类型进行指定。

    1. [7] pry(main)> find_element(:class_name, 'UIATextField')
    2. #<Selenium::WebDriver::Element:0x31d87e3848df8804 id="3">
    3. [8] pry(main)> find_element(:class_name, 'UIATextField').value
    4. "Email Address"

    不过在实践中发现,采用find、find_element这类通用的定位方式并不好用,因为定位结果经常不是我们期望的。

    经过反复摸索,我推荐根据目标控件的类型,选择对应的定位方式。总结起来,主要有以下三种方式。

    针对Button类型的控件(UIAButton),采用button_exact进行定位:

    1. [9] pry(main)> button_exact('Login')
    2. #<Selenium::WebDriver::Element:0x..feaebd8302b6d77cc id="4">

    针对Text类型的控件(UIAStaticText),采用text_exact进行定位:

    1. [10] pry(main)> text_exact('Phantom')
    2. #<Selenium::WebDriver::Element:0x1347e89100fdcee2 id="5">

    针对控件类型进行定位时,采用tag;如下方式等价于find_element(:class_name, 'UIASecureTextField')

    1. [11] pry(main)> tag('UIASecureTextField')
    2. #<Selenium::WebDriver::Element:0x..fc6f5efd05a82cdca id="6">

    基本上,这三种方式就已经足够应付绝大多数测试场景了。当然,这三种方式只是我个人经过实践后选择的定位方式,除了这三种,Appium还支持很多种其它定位方式,大家可自行查看Appium官方文档进行选择。

    另外,除了对控件进行定位,有时候我们还想判断当前屏幕中是否存在某个控件(通常用于结果检测判断),这要怎么做呢?

    一种方式是借助于Appium的控件查找机制,即找不到控件时会抛出异常(Selenium::WebDriver::Error::NoSuchElementError);反过来,当查找某个控件抛出异常时,则说明当前屏幕中不存在该控件。

    1. [12] pry(main)> button_exact('Login_invalid')
    2. Selenium::WebDriver::Error::NoSuchElementError: An element could not be located on the page using the given search parameters.
    3. from /Library/Ruby/Gems/2.0.0/gems/appium_lib-8.0.2/lib/appium_lib/common/helper.rb:218:in `_no_such_element'

     

    该种方式可行,但比较暴力,基本上不会采用这种方式。

    另一种更好的方式是,查找当前屏幕中指定控件的个数,若个数不为零,则说明控件存在。具体操作上,将button_exact替换为buttons_exact,将text_exact替换为texts_exact

    1. [12] pry(main)> buttons_exact('Login').count
    2. 1
    3. [13] pry(main)> buttons_exact('Login_invalid').count
    4. 0

    除此之外,基于Ruby实现的appium_lib还支持exists方法,可直接返回Boolean值。

    1. [14] pry(main)> exists { button_exact('Login') }
    2. true
    3. [15] pry(main)> exists { button_exact('Login_invalid') }
    4. false

    对控件执行操作

    定位到具体的控件后,操作就比较容易了。

    操作类型不多,最常用就是点击(click)和输入(type),这两个操作能覆盖80%以上的场景。

    对于点击操作,才定位到的控件后面添加.click方法;对于输入操作,在定位到的输入框控件后面添加.type方法,并传入输入值。

    例如,账号登录操作就包含输入和点击两种操作类型。

    1. [16] pry(main)> find_element(:class_name, 'UIATextField').type 'leo.lee@debugtalk.com'
    2. ""
    3. [17] pry(main)> find_element(:class_name, 'UIASecureTextField').type '123456'
    4. ""
    5. [18] pry(main)> button_exact('Login').click
    6. nil

    To be continued …

    在本文中,我们学习了对iOS UI控件进行交互操作的一般性方法,为编写自动化测试脚本打好了基础。

    在下一篇文章中,我们就要正式开始针对iOS应用编写自动化测试脚本了。

    感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

    这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取 

     

  • 相关阅读:
    「设计模式」六大原则之开闭职责小结
    由于找不到vcruntime140_1.dll文件的解决方法,带你了解vcruntime140_1.dll这个dll
    MyBatis中使用#{}和${}占位符传递参数的各种报错信息处理
    计算机网络—eNSP搭建基础 IP网络
    ArrayList为什么线程不安全以及三种解决办法【详细】
    R语言基于正则表达式筛选dataframe数据列、使用grepl函数按照正则表达式筛选数据列
    [stm32]温湿度采集与OLED显示
    K8s---Pod搭建LNMP
    高性能MySQL实战第09讲:如何做到MySQL的高可用?
    在 React 项目中全量使用 Hooks
  • 原文地址:https://blog.csdn.net/chengxuyuznguoke/article/details/134443051