测试老司机教你:小公司如何实现APP的UI自动化测试

发表于:2018-6-12 16:53

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:黄允聪    来源:51Testing软件测试网采编

分享:
  作为一个在软件和互联网行业浸润了20年的老兵,我接触了很多司,也面试了很多人,发现国内现在能实现APP的UI自动化测试的公司很少,我的一个之前在淘宝测试团队工作的同事也讲,在淘宝也是部分实现了自动化测试,因为很多业务变化很快,实现自动化测试意义不大。我面试过的很多测试人员,有些是工作了快10年的也是这种观点。我们公司是一个创业型的汽车后市场O2O企业,因为老板的平台化战略,我们的APP非常庞大,安卓我们有5个APP,IOS我们有4个APP,功能覆盖洗车、保养、维修、拼车、租车、代驾以及交友朋友圈等等,复杂度堪比淘宝,我不是在这里故弄玄虚,大家下载看看就知道了,在应用宝搜索逸休联盟就可以看到了。
  创业公司面临的自动化测试之痛点
  因为我们基于精兵战略,我们的开发和测试人数一直都很少,安卓和IOS开发巅峰时候也就是各自5个人,现在缩减到各自3人,测试人员从之前的2人变成了1人。因为是个创业公司,我们的业务现在还是非常不稳定,功能经常是变来变去,这也是很多创业公司遇到的,但我们还有2个困难,功能庞大,人员少,根据我的了解很多创业公司的功能比我们少很多,但人员多很多,提升开发效率和测试效率就变成了我们需要解决的问题。今天这里,我主要谈谈我们怎么样基于现在流行的Appium解决自动化测试的问题。
  上面是我们APP的架构图,安卓和IOS都是相同的,独立组件层是一个重用性非常高的模块,只依赖安卓和IOS自身类库,和知名的类库,如百度地图等,这个模块可以脱离我们APP使用。在这个层上面,网络层是和后台进行交互的,一切数据请求包括图片都通过这个层面,我们学习了几个开源代码基础上面独自开发的,这样做的考虑有很多,这里不在多讲了。数据模型层用于和后台的数据交互,也同时用于APP界面的VIEW的交互。项目组件层是项目当中可以重用的组件,因为依赖数据模型,不能独立出来。最上面一层就是我们的插件层,就是具体的业务功能实现。
  其实自动化测试需要解决下面几个棘手的问题:
  1.怎么样找到能够完成这个工作的人
  2.怎么应对频繁的业务变化和UI变化
  3.怎么样设置断言,怎么样建立标准库
  我面试非常多的测试人员,发现真正懂自动化测试的人太难找,如果非要找就得去BAT挖人了,这当然是不现实的。很多测试人员是不会编程的,即使会编程,也是太低级的水平。我们的办法是测试人员和开发人员合作完成,开发人员编程能力很强,但他们不知道怎么去做测试,他们互相合作形成优势互补解决了人员问题。这个合作关系当中,测试人员就是产品经理,开发人员通过理解他们的测试用例,来形成需求文档设计。我们的目标是基于我们的APP,开发一个测试框架,这个测试框架具有很高的重用性,可以大大降低测试人员的编程门槛,他们只要简单的调用几行API就完成了测试,测试人员关注的是测试的流程和角度,不需要关心具体底层的实现。下面是我们的工程截图:
  我们的测试工程包含了两个包,一个是开发人员维护的,一个测试人员维护的,开发人员去学习Appium框架和API,基于Appium设计和开发出我们自己的框架,同时可以测试IOS和安卓,测试人员不需要去关心这两个平台的区别,因为IOS和安卓的功能都是相同的,所以他们是可以只写一套测试代码的,下面是测试人员的代码:
  虽然这是首页的更换城市,我们还有很多其它需要更换城市的地方,其实就是需要换个ID就行了,测试人员是知道怎么通过工具获得ID的,而且这些ID也是相对比较稳定的。
  这是一个相对复杂的测试用例,对于测试人员只要知道理解我们的API就行了。
  解决问题的方法和类型
  怎么样应对业务和UI的快速变化没有一个统一的解决办法,这是需要针对不同情况找不同的办法,但前提是我们需要对产品,开发和测试有个全局的考虑,从而发现解决的办法。因为我们的软件是基于组件化开发的,实现快速应变有着先天的优势。我们组件化提升我们的开发效率,同时在测试方面我们也应用了针对组件的组件化测试。下面我来举例说明一下,当然这只是我们解决的问题当中的2种类型:
  搜索排序是一个非常常见的场景,所有电商APP都有这个场景,我们的也不例外,下面是一些我们的场景图:
  上面两个图,一个是进行商家查询,一个是进行服务查询,这两个场景看似不同,但对我们测试框架来讲实现是一样的,没有区别,我们的界面都是组件化的。比如左边的截图包含了题头组件+地址选择组件+赛选组件+列表组件,右边截图也包含了相同的组件,我们的题头组件定义了很多不同展示形式,其实都是一种组件,因为我们的测试框架也是针对组件做的,自然就保证了测试用例的灵活性。上面的赛选排序测试用例就简化成了下面这样,就几行代码,我们的赛选条件可以只多级的,这个示例只是两级,如果我们要设置地区条件排序条件,则filter(“行政区,登州市”),sort(“好评优先”),写测试用例变得非常简单和直接,如下图所示:
  其实这个赛选函数可以使用到很多地方,如车型选择,城市选择等等,我们的框架每个函数都是解决的一类问题,而不是一个问题,具有非常好的灵活性。
  如何建立界面变化的问题
  下面我讲讲怎么建立界面变化的问题,拿商家查询来讲,列表当中的每个CELL,产品那边是经常变化的,赛选条件也是经常变化的,赛选条件变化,我们就是把传入的参数变化一下就行了,对于CELL的变化有稍微复杂些。做过测试的人都知道,测试这个商家列表,我们可以从很多角度进行测试,角度有:排序和赛选条件是否正常工作,正常查询是否能进行,点击CELL是否能成功进入详情等等。
  因为CELL是经常变化的,但CELL的变化会影响我们排序和赛选的测试用例吗?如果你使用截图对比方式,当然是影响的,因为你的CELL变化了,说明标准图例也必须变化,否则用例就是失效的。但如果我们使用逻辑进行判断呢?情况就完全不同了,我们的CELL可以任意变化,但商家名称这个字段是永远不变的,没有商家名称,这个列表也就没有意义了,所以可以讲这个字段是100%肯定不会变化的,那么通过截取列表当中商家名称的序列,我们就可以判断排序和赛选条件是否有问题。比如,一组赛选和排序条件设置后,我们希望的商家排序是:
  汽车快修保养,盛大汽车装潢,大拇指汽车美容…
  但实际上是:
  汽车快修保养,大拇指汽车美容,盛大汽车装潢
  通过对比两个LIST,我们就可以知道,排序和赛选逻辑是否发生了变化,程序是否出现了BUG,所以我们能做逻辑判断的地方,就不会使用图片对比判断。使用逻辑判断的另外一个好处就是,我们不需要考虑机器的适配性,安卓机器市面上太多了,每种机器的截图都是可能不同的,劳动量显然是我们这样做的几十倍。通过这个例子,我就是想说明一个道理,业务变化快是事实,但不能说自动化测试成本就会非常高,关键是产品+开发+测试的全局的思维和解决问题的方式。
  关于断言的设置和标准库的建立
  断言的设置和标准库的建立也是一个比较棘手的问题。我们有一个自动化测试标准库,这个库有的是生产数据,有的是后台创建的数据,由后台团队进行维护和升级,这个数据库表结构和生产环境保持同步,就是生产环境的一个特制版本,可以支持生产流程当中的全部业务逻辑。为了保证自动化测试的可重复性,我们使用的DOCKER技术进行映像回滚,APP测试框架可以通过SOCKET连接远程触发数据库回滚和服务器代码回滚。有了标准数据库,下面就是怎么建立对比标的数据。
  前些时间我面试了一个做测试的老兵,8年做测试的经验,曾经任职于阿里及百度,最后于2014年离开百度到了现在的一家公司。当时我问她的问题是,怎么继续断言的逻辑比对。她给我的答案是,他们测试团队也有开发,他们会编程从数据库读取数据,然后和APP的读取数据进行比对。这虽然是个解决办法,但测试人员需要有良好的开发技能,而且因为业务逻辑变化,他们测试团队读取数据库的方式也需要不断修改。我看过很多人的测试用例代码,包括一些国外的示范例子,很多人喜欢把测试断言判定条件直接写在代码上面,比如ASSERT(result==’example’),这种Hardcode的方式重用性和维护性极差,我们的测试代码是绝对不允许这样做的。我们提出了一个标的数据集的概念,标的数据集就是你需要对比的标准值,这个标准值可以是一段文字,数字,一个字符串LIST(例如商家查询的对比标的),也可以是图片,可以是任何形式的数据,下面的数据就是怎么来建立这些标的数据集。
  之前我在网上看到一些例子,都是人工去处理的,人工去设置到EXCEL表格当中,人工截图然后放到指定的文件夹里面,每次业务逻辑变化,这个标的数据集的建立本身就是一个费力的事情。我们的解决办法是标的数据集建立的自动化,我们的框架里面有两个测试环境变量,一个是数据标定流程,一个是测试流程,测试流程不用讲了,标定流程其实就是自动化生成标准数据流程。当测试手工完成业务测试后,我们就认为现在的数据可以作为标的数据集了,会启动标的数据集流程,这个流程,系统会截取界面数据,或者自动截图,把这些数据保存在我们规定的目录之下。例如,前面的商家搜索案例,系统会把商家名字排序截取处理,保存到一个字符串LIST的数据集当中,同时也会截图手机图片,作为图像对比的标准图片,并且保存到对应的文件目录中。每个测试用例都需要加入一个数据标定流程,数据标定也提供了API,测试人员只要直接简单调用就行,他不需要关心数据是怎么截取的,怎么保存,或者保存到了什么地方,他都不需要关心,他只需要指定需要针对什么生成什么数据集。例如,商家搜索案例,测试需要指定,按照商家名称的ID,生成一个字符串LIST的数据集,其它的他都不需要去关心。
  总结
  通过上面的一些措施,我们现在就一个测试人员来维护9个APP,如果有不能完成的测试用例流程,则让开发人员协助帮助他完成。当然基于人员储备考虑,我们后面会增加一个测试人员,保持2个测试人员的水平。



上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • sillybug
    2020-1-02 15:27:24

    学习一下

  • hjf1118
    2019-10-10 16:14:30

    好文

  • huaxiaorong
    2019-9-12 11:45:11

    思路很清晰,受益匪浅,会好好消化,谢谢

  • zhaobinhs
    2018-10-08 14:38:43

    受教了

  • 说你的好
    2018-8-09 15:32:44

    不错,这样的干干货可以多搞几个来

  • testviper
    2018-7-06 14:55:48

    mark

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号