论APP UI自动化测试的可行性分析

Posted 2022-06-19 WEL测试

背 景

    在这个科技时代，app数量也是逐年递增，只要能想到，大多数都可以在相应的平台找到相关的app!

      那一款app在市场上出现之前，会经过哪些“加工锻造”的过程呢？又经过哪些流程，来确保从市场上下载下来的app能正常使用呢？在这里我，以测试的视角来说我对app一些粗浅认知,在这过程一些意见，纯属个人臆断，如有不对欢迎指正！

    不管是何种事物的产生，都是基于需求，有需求才能存在发展的内在驱动力，因此app的产生的第一阶段是需求；有了需求就要基于该需求，调查市场上的用户的群体，分析获取用户的功能性需求，设计app的功能性需求，因此这一阶段为产品设计；根据产品的文档，开始app的制作加工阶段，这个阶段不展开解说，包括内容太多，例如开发框架的选择、UI设计、编码等等，这个阶段为app设计与实现阶段；根据app设计与实现完成，要确保能正常使用，需要进行相应的测试，该阶段称为app测试阶段；测试完成之后，app上线，至此一个app的产生就完成了，至于市场运营，那是以后的事情了！

   因此，app的加工锻造的过程，大致为：获取市场需求、提取需求设计产品文档、根据需求设计并实现app、app测试、app上线！

   该篇文章，是针对app测试阶段中的UI自动化测试的可实施性进行分析作为背景，从需求、技术、维护三个阶段来分析UI自动化测试在app的可行性！

 

需求变更频繁

    不管是测试还是开发，所有的出发点都是基于需求，那么目前市场上一些app，为了保持用户的新鲜感，不断的更新版本，来确保用户获得更好的体验！在App每个版本更新过程中，一些功能入口会发生变化、页面的一些元素会发生变化、之前有的一些功能会被替换掉、增加新的功能等！

  这点对于自动化测试是致命的威胁，目前自动化测试都是通过编码实现的，来实现模拟用户点击行为，一旦app进行版本更新，就要对自动化脚本进行维护，维护成本比较高，由于需求变更频繁，造成开发完成，后期没人维护，被废弃。

      不过这可不是来说通我们的boss，放弃App UI自动化测试想法的重要砝码！他们会给你新的想法，不过这些想法，有时候会让我头疼，但是他们说的确实在理，无法反驳，那就按着他们的想法去试试，万一成功了呢？这不是发现了测试中的一个新大陆吗，对自己的能力增长那是很大的不是吗？就以我遇到的一些问题为例，每个app产生的时候，都有自己的一些核心业务，后期的版本更新都是基于这些核心业务来扩展设计新的功能，这些核心业务基本很少甚至不发生变化，那么能不能对于app中成熟的业务来设计UI自动化测试用例呢？那么对于这个想法，我做了如下尝试，把遇到坑归纳如下：

(1)  核心业务是否有单独稳定的UI入口？

      核心业务是否有单独稳定的UI入口，这是重中之重，这能保证测试的正常进行，自动化测试的初期，都是对业务流进行梳理分析，选择一些成熟稳定的业务流！这么做的好处主要有：需求变更对业务流影响较少、有效的数据比较多、业务之间的边界清晰！

      如果核心业务没有单独稳定的入口，那么UI的自动化还没开始就会遭遇滑铁卢，因为入口变更频繁的话的，那么业务流就无法成功走下去，后续的测试用例也无法成功执行！其实测试做到后期，都有个认识，UI自动化测试都是基于业务流的测试，业务流发生变化，直接影响的是一个测试集的，因此针对APP的UI自动化测试而言，业务流的选择是基石！

(2)  一些开发的编码格式是否规范？

      开发人员的编码规范与否，对于自动化测试的也是有一定影响的，规范的编码，对于后期的技术实现影响是相当大的，所以早期，最好能与开发协商，你测试过程中需要的一些元素属性一定不能为空，方便后期元素定位，因此开发人员编码规范也是相当重要的！

(3)  App开发框架更新？

      APP开发框架一般对于业务流影响不大，可能会影响部分测试集中的测试用例，导致测试用例无法正确执行，这个影响程度要看测试用例的数量，因此这个对UI自动化影响大小看情况而定！

      因此，根据上述可以看出，APP UI自动化测试可行性在一些场合下是可行，在一些场合下是不可行的！可行场景：产品变动小、页面UI改动小，这些是可以做的；其他一些可以通过接口测试，来实现业务的自动化！

 

APPUI自动化技术

    目前市场上主流的APP UI自动化工具包括Appium、UiAutomator、UIAutomation、XCUITesting等等。这些自动工具都是通过页面元素一些属性来定位页面元素，来实现用户一些日常操作行为的模拟操作，元素点击、拖动、截图等！

      那下面以Appium这个目前最火一款工具，来分析它有哪些弊端。

(1)  环境部署

      针对Appium环境部署，这里不讲如何安装配置，如果想学习Appium+Python在Windows下面的安装，这里给我之前的一篇博客链接：​

      这个安装方法，我试过，是可以成功安装，如果在安装过程遇到一些问题，可以在该博客下留言，我会及时回复的！本人在刚开始，配置部署这个开发环境时，就踩了好多坑，环境配置是我目前最麻烦的之一，比Spark集群稍微简单点，但是它的需求太多，好多想要使用该工具的人，估计90%的人被环境配置难住！

      环境配置结束之后，那就是需要跑一个测试，来了解下简单的操作流程。本文不做赘述，链接​

(2)  元素定位

      接触过selenium的，对于元素定位，以Python语言为例给出方法名称：

      find_element_by_id()：根据元素的id属性进行定位； find_element_by_name()：根据元素的name属性进行定位；

      find_element_by_class_name()：根据元素的class属性值进行定位；

      find_element_by_tag_name()：根据元素的tag名进行定位；

      find_element_by_link_text()：根据链接文本进行定位；

      find_element_by_partial_link_text()：根据链接文本中包含的部分文本信息进行定位；

      find_element_by_xpath()：根据xpath进行定位；

      find_element_by_css_selector()：根据css进行定位；

      关于定位元素组的，只需要把find_element改成find_elements就可以。上述是selenium的定位方法，目前ios使用XCUITesting后，元素定位方法与selenium元素定位方法一致。这是Appium+XCUITest的Python链接：

​

      那么appium如何在安卓设备上进行定位呢？在安卓设备上使用的是uiautomator，以Python为例，使用方法如下：find_element_by_android_uiautomator()，该方法与Uiautomator的UiSelector()联合使用来定位元素。      具体该脚本信息，可以查看我的博客链接： ​

(3)  性能

      appium对设备的要求比较高，如果设备配置的比价低的，运行脚本时会相当卡顿，不能及时响应操作，总体来说性能不怎么好！

(4)  使用难度

      从环境的配置，到编码的使用，都要求较高，需要有一定的编码基础，不然很难入门使用，所需要花费的成本较高！不过可以与robot framework结合使用，使用者不需要关心后台代码逻辑！关于如何与robotframework可以从网上查找，比较多的！

      针对上述可以发现，app UI自动化测试上技术是可行的，不过对于测试人员的技术要求比较高，学习成本比较大！需要专业的人员指导，才能顺利实施！

   关于在windows下对安卓进行的自动化测试，我做了做了一个研究，把adb+python结合起来，把adb的命令和Python结合起来，来实现元素点击操作，具体代码链接​

  改脚本实施原理是，通过adb命令把设备当前页面的信息dump下来保存为xml文件，通过xml的树定位元素在页面所在的位置，具体可以看上述代码链接，具体实施是可行的，只要是页面中有都可以定位点击，准确度和性能都不错！

      缺点是需要adb支持，不支持ios。我把该脚本封装好，与robot framework结合起来，链接​

 

 

自动化测试脚本维护

    在需求稳定，页面稳定的时候，自动化测试脚本维护成本比较低；在需求变化比较频繁、页面变化比较大，维护成本比较高！自动化测试脚本，也需要定期的进行迭代管理，需要制定合理规范化的管理流程！要有规范化的测试用例编写规范、测试集模块功能介绍、各测试集管理人员、操作手册等相关文档，避免人员在流失导致自动化测试脚本废弃！

      脚本维护，是保存自动化测试持续的必要条件，人员流失、文档少，是自动化测试脚本废弃的主要问题！

 

 

总结

    其实，在研究app UI自动化测试可行性分析，发现最大的问题是：入口和UI经常变化、时间紧，导致维护成本高！其实，app UI自动化脚本开发都是提高工作质量，但是由于app更新频次快，时间紧，手动测试比较自由及时，使用脚本还要去调试校验、编写代码，比较耗时！

      总而言之，APP UI自动化因公司而定，如果有规范化的管理流程，自动化测试在回归测试方面还是很高效的！