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