【TMQ（腾讯移动品质中心）是腾讯最早专注在移动 APP 测试的团队，网站专注于移动测试技术精华，饱含腾讯多款亿级 APP 的品质秘密，文章皆独家原创，我们不谈虚的，只谈干货！】
阅读原文欢迎访问TMQ官网

背景
2014 年初，当时了解到浏览器的项目组在说是不是可以用 KIF 做自动化测试的事。于是，我就想实践看看 KIF 能否做脱机 UI 自动化测试？ 经过实践不可行后，我就在想，其他自动化测试框架是否可以支持？仍没有找到能支持脱机自动化测试的框架。最后，就想有没有方法能够快速实现脱机自动化？很幸运的是，经过一周的摸索，实现了一套可行的脱机自动化方案，当时完成只是一个雏形，算是个试验品。该方案在浏览器上实践过，是可行的，也反馈到测试组，因为考虑到 KIF 维护成本，暂时没有采纳，因此框架一直停留在试验品的阶段。意外的惊喜是，两年过去了，这个试验品在地图产品存活下来了，运作在日常的自动化性能监控上。因此，经常有人问我这个框架是否有维护更新，考虑到本人精力有限，没法支持各位框架的更新维护工作，因此想把整个框架形成的思路和关键技术点给大家分享一下，希望大家可以通过这个分享了解到我这个脱机自动化框架如何形成的，同时也想利用大家的力量能够将这一套框架继续维护下去。

摸清现状

当时官方的框架 OCUnit 和 UIAutomation 都是需要联机测试的，想要看能否脱机自动化测试就先从第三方的测试框架入手。

从 KIF 切入

首先，是从项目组了解 KIF 这个自动化测试框架，因此先了解 KIF 这一套方案机制，重点观察能否支持脱机自动化测试。看使用方法，是在 test target 里配置添加 KIF，这样操作是通过 XCode 的 Product-> Test 触发启动测试，这样必然只能连机，XCode 才能触发。当时，不死心，我在想，如果不配置在 test target 里，直接放在编译 app 的 target 是不是就可以在真机跑起来呢，结果发现编译不过，SenTestingKit 不支持真机运行。追溯源代码发现 KIF 的用例管理是基于系统测试的用例形成的，而系统这一套用例 SenTestingKit 库是不支持真机的，代码如下：
terface KIFTestCase : XCTestCase
可以很明显看到对应的继承关系，这样实践过来是可以死心了，KIF 明确支持不了脱机自动化测试。
但是可以看出 KIF 有个特点：UI 控件识别能力，可以在测试工程里模拟用户的操作，同时支持自定义扩展。

发现 GHUnit

KIF 这条路走不通，就想着是不是还有第三方的框架能支持，后面就网上查找了一些第三方的框架。于是，发现有 GHUnit，也是开源的一个框架，从介绍上看 GHUnit 是单独做了一套用例管理的，可在真机上展示，如下：

找到这个框架，很兴奋，是不是 GHUnit 可以搞定脱机自动化测试的事。下载代码编译尝试。确实！GHUnit 框架是能支持用例在真机上运行的。感觉已经成功了一大半了，但又有个新问题，我们的测试除了接口类型的，其他基本都是和 UI 密切相关的，GHUnit 只显示用例 UI，无法看到我们被测 APP 的 UI，这样的框架能否满足我们 UI 自动化呢？
查看源码，发现 GHUnit 自己维护了一套类似 SenTestingKit 库这样的用例管理，但是没有做 UI 控件的识别机制。因此还是停留在接口类型的测试能力上。
但是可以看出 GHUnit 有个特点：用例管理能力。
这里也找了一些其他的第三方框架，从描述上看，没有发现能够满足我们想要的脱机 UI 自动化的框架。
方案尝试
从前面的描述上看，已经基本可以确定市面上目前还是没有这样的框架，可以支持脱机的 UI 自动化测试。也许是目前的测试中暂时不 care，因此脱机 UI 自动化测试框架也没有出现。
到这里，了解了现有测试框架的基本能力，差不多可以停步了。我们不太可能自己去实现一套这样的框架，工作量即大又没有强迫的需求。
不过，当时刚好开发完 iOS GT 的组件，又看到 KIF 具备 UI 控件识别的能力，GHUnit 具备用例管理的能力。于是，我就想，是不是可以将 KIF 的 UI 控件识别能力和 GHUnit 的用例管理能力结合在一起呢？然后放在 GT 的插件上，利用 GT 能够和被测应用共存 UI 的能力，是不是就能达到脱机 UI 自动化测试的效果呢？
我是这么想的，也是这么做的。将 KIF 里用例管理依赖的 SenTestingKit 库替换成 GHUnit 库，然后将 GHUnit 用例页面展示功能以插件的形式放在 GT 插件中。下面是在浏览器上实践的效果图：

该方案目前在地图产品已有使用，用例展示效果图如下：

进一步说明

前面已经描述了脱机 UI 自动化方案的形成历程。可以简单说一下本方案的好处，如果是之前需要脱机多次测试多个场景用户只能重复多次操作，只能一步步按照要求重复的测试。这时如果能有途径可以脱机自动化测试则可以大大减少用户的测试时间。
这里我们可以再进一步想想，这一个框架还有没有优化的空间，这一块没有实践，纯属一些思考。比如可以增强用例的管理，支持用例集选择及测试次数的设置，这样用户按照 KIF 协议接口调用模拟用户的操作将手工的操作都写到测试用例里。后续用户测试时直接可以选择需要执行的和设置相应的次数，点击启动即可达到自动化测试的效果。下面简单的示意图：

通过本方案，用户只需要完成一次用例的开发，简单几个步骤即可以达到替代用户重复多次的手工测试操作。对于需要大量的测试用例数据来说，能够很可观的节省用户时间，同时还能避免因人为操作失误导致的无效数据。目前该方案已申请专利保护。

最后附上 KIF，GHUnit 以及 GT 的地址，都是在 github 上开源的：
 KIF：https://github.com/kif-framework/KIF
 GHUnit：https://github.com/gh-unit/gh-unit
 GT：https://github.com/TencentOpen/GT
希望对大家工作有所帮助！如果考虑使用或升级该方案，欢迎加我讨论。