一个小公司怎么实现APP的UI自动化测试

测试积点老人

作为一个在软件和互联网行业浸润了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个测试人员水平。

Miss_love

支持分享