版权说明
本文为 InfoQ 中文站特供稿件，首发地址为：文章链接。如需转载，请与 InfoQ 中文站联系。
前言
在 2014 年 QCon 北京 大会上，羋峮进行了他的新书 《iOS 测试指南》 的签售会。在大会中，我代表 InfoQ 与羋峮进行了一次专访，羋峮分享了他在 iOS 平台做自动化测试的一些经验。
羋峮有着多年的测试经验，先后在高德、豆瓣以及豌豆夹从事过测试相关的工作。他在豆瓣工作时，实现并且开源了 iOS 的自动化测试工具 ynm3k，并且刚刚完成了系统介绍 iOS 自动化测试的新书《iOS 测试指南》。
InfoQ：羋峮你好，我想请你先介绍一下你的测试工作经历。
羋峮：我是 03 年毕业的，修了三年地铁以后就转行做软件测试工作了。到现在，做测试有七到八年的时间，我是从豆瓣开始做的移动测试相关的工作，当时移动测试也正好赶上一个起步的阶段，所以还有一点小小的心得。
InfoQ：我想问的第一个主题是关于自动化测试和持续集成的方面的问题。就我所了解的情况，现在大部分的互联网公司关于移动端的测试的工具都还处于比较初级的阶段，很多公司也没有真正应用上那个自动化测试。我昨天跟阿里的 iOS Leader 聊，他们没有用到移动端自动化测试，我之前在网易工作，他们也没有做移动端自动化测试，你觉得是什么原因造成移动端自动化测试还没有流行起来，没有大规模的应用？
羋峮：测试的投入产出比，尤其是自动化测试的投入产出比一直都没有一个非常简单有效的说明方法。当投入产出比的说不清楚的时候，可能很多人选择观望。tinyfool 在给我写这本书的书序的时候，他也做了一个小调查，基本上就是不测试，或者简单测试的占很大的比重，比较细致的测试非常少。测试做的非常少主要有这么几方面的原因：
1、移动端是一个新生事物，总结出来的方法还没有被普遍的认可。移动端承接了更多 UI 展现方面的工作，其中有很多的和人交互的东西。不但功能复杂，并且还没有唯一的标准。测试的注意力很容易不分散，并且效果非常的不明显。
2、移动端现在更多的是市场行为，需要有产品的占领地盘。还没有到精雕细琢的时代。所以，测试在这个时候明显不如产品或者设计师有话语权。并且现在需要的是 “有”，还没有到 “精” 的程度。
3、国内测试界相对比较浮躁，更多的不是从技术角度去解决问题。所以导致测试需要关注点过于分散，没有真正的定义好自己的工作职责和范围。什么事情都需要关注，最后就是什么事情都没有关注好。
我比较幸运，当时去了豆瓣。豆瓣当时明确的定义了 QA 的工作职责——推荐新技术或者开发新工具，让开发工程师更好的测试。并且设计师在测试阶段也会投入很大的精力去 review 设计稿中各种交互方面的不足。
InfoQ：你在豆瓣开始尝试 iOS 的自动化测试，那我想知道你在这个过程中取得哪些成果？
羋峮：刚去豆瓣接手工作的时候自己思维还是有局限性的，只是把自己工作定位在去实现一些基于界面操作的自动化的东西，这个其实现在看来可能它是一个切入点，但是可能并不是一个非常好的切入点，其实还有很多工作要做，由于当时自己思维局限所以就做了。
另外一方面，就是因为只想到这一点，所以就是精力比较集中 , 更容易出一些成果。2011 年年底的时候开始做这些工作，自己先后找了有五款自动化测试工具调研。调研的方法是先写一些 demo 的东西，然后再看看工具的源代码。搞清楚工作的架构和底层原理。最后发现，当时的工具都有一些这样那样的问题。然后自己就开始幻想写一个适合自己的这个自动化工具。
当 iOS5 发布以后，苹果的对于 UI Automation 进行了一个改进，增加了
performTaskWithPathArgumentsTimeout接口。通过该接口可以实现 UI Automation 和外部程序的简单通信。基于这个改进，自己拉了在豆瓣的一个开发的同事，两个人就用一个半月的时间写了一个自动化测试工具。也是因为有了 performTaskWithPathArgumentsTimeout 接口的发布，所以淘宝也当时利用那个接口写了另外一种实现的 iOS 的测试工具。
在完成 ynm3k 的开发以后，使用它为豆瓣 FM 和豆瓣电影写了一些自动化测试用例。效果还可以。
InfoQ：淘宝那个开源了吗？
羋峮：淘宝那个开源了，叫 athrun ，我那个也开源了叫 ynm3k，当时是 12 年 7 月份，那个 ADC 的专门都有分享，在网上应该也都有链接 Athrun instrument driver 和 豆瓣 iOS 自动化测试实践和经验 。
InfoQ：当时你们花一个半月开发这个自动化测试工具是用 20% 的工作时间，还是完全的工作时间来做这个事情？因为我觉得你在开发这段时间内肯定也有普通的正常的测试任务要完成，你们公司是怎么平衡这件事情的？
羋峮：我们应该是业余时间完成的这个框架。主要就是晚上，或者是快下班的时候，自己挤出来一些时间做这个事情。
InfoQ：跟同事的配合也是在那段时间来进行的？
羋峮：当时就是我俩分工相对来说很明确，一方面需要有更好的遍历控件和定位控件的方法，是由我来现实的；另一方面，需要引入一个 JavaScript 语言的单元测试框架。这部分由我豆瓣的同事 @SeanLionheart 完成，他在正式发布的时候已经去美国上学。
我们两个之间的配合非常顺畅，因为各自的部分是完全解耦的，互补不影响。在交流的时候，还能相互给出自己的想法和意见。
InfoQ：你们做这件事情，豆瓣有从文化上，或者从其他方面对你们这件事情有鼓励或者激励吗？我想知道，是否这个公司的文化对于促进了你们做这件事情？
羋峮：这个肯定是促进的。首先这个想法是我在一次周会上提出来的。提出来以后，当时我的 Leader 解彦博老师就特别鼓励我们去做这件事情，并且大家都很感兴趣，当时的整个测试团队都给我们提供意见或者交流过想法。
第二，在豆瓣的骨子里，就有很多工程师去愿意去用自己的业余时间去写一些小工具来改进效率，或者是提高效率，或者改进流程，这个在豆瓣都是很流行。自己写的工具，在豆瓣内部得到了广泛的应用，对工程师来说这是很高的荣誉。
InfoQ：当你产品在快速迭代的时候，它的整个页面的组织，界面逻辑都会在快速变化，这个时候自动化测试是否是在这种场景下不太适合？自动化测试是怎么解决产品快速迭代的问题呢？
羋峮：无法适应变化一直是自动化测试的软肋。首先，有一些变化需要测试做兼容，这个兼容可能需要测试框架本身来支持，也可能需要自动化测试脚本通过一些更加层次化的方法来兼容。举一个例子来说，一个登录按钮，从 NavigationBar 上移到了可能在中间页面的一个 LoginButton 上面，所以这种情况下是应该去兼容的，因为它只是位置发生了变化，它大的业务逻辑没有发生变化，这种是需要测试框架去兼容的。如果是更大一点的变化，需要测试脚本一定量的维护。
其次，测试脚本一定要不断的维护。有很多自动化测试最终失败是因为期间放弃过自动化测试脚本的维护。自动化测试脚本不但需要维护，还需要有很好的代码结构。相关测试脚本的代码结构可以参看一些 PageObject 的思想，也可以看看 cucumber 等 BDD 工具，都会帮助你最小改动的维护自动化测试脚本。
当然，自动化测试接入工程的时机等因素也很重要。这些都没有固定的模式，需要结合自己团队的特点来开展。自动化测试和持续集成是一对好基友。自动化测试执行和结果展示都需要持续集成的帮助。有了持续集成，自动化测试才会被更多的人认可，可才会有更多的人加入到自动化测试的维护中来。
最后，可能需要更新一下对自动化测试的认识。自动化测试不会降低成本，自动化测试不会主动发现 bug。自动化测试可以更标准更快速的重复回归一些功能测试。所以，对自动化测试有一个更加客观的认识，才会帮助你在具体的工程项目中更好的开展自动化测试实践。
InfoQ：刚才你提到你在豆瓣开源的 ynm3k 这个开源测试工具，然后你同时也提到淘宝也开源的 athrun，你有没有比较过你们两者之间工具各自有什么特点？
羋峮：首先两款工具都同时用到了一个接口，接口的名字是：performTaskWithPathArgumentsTimeout，这个接口可以去运行一个本地的命令行程序。这个接口提供了 UI Automation 和命令行工具的一个交互的可能。
我用那个接口用的非常轻量，需要把运行完的测试结果通过那个接口写文件写出来，写成标准的 XML 以后，通过 Jenkins 或者是 Hudson 这些持续集成的工具，把它展现在持续集成工具的页面里头。
我只是写了文件，淘宝的 athrun 做了一个进程之间的通信，所以他那个工具解决的问题是：用户可以不用 JavaScript 来写 UI Automation 的东西。athrun 自己定义了通信协议，并且通过 performTaskWithPathArgumentsTimeout 接口来完成和 UI Automation 的通信。用户可以使用 Java 语言来做 UI Automation 的自动化测试。
同样类似的国外也有，就像 eBay 的 ios-driver，还有就是最近特别火的 appium，原理上都是通过那个接口实现了两个进程间的通信来驱动 UI Automation 来完成自动化测试的。appium 在驱动 UI Automation 的基础上还兼容了 WebDriver 的 Json Wire protocl 协议。使用者可以使用 Java、Python、Ruby 等语言直接调用 WebDriver 的 API 来完成 iOS 的自动化测试。WebDriver 对很多 Web 端的测试工程师来说都很熟悉。由于 appium 兼容了 Json Wire protocl 协议，使用者还可以使用 Gird 来并发的测试。当然，appium 也支持 Android 的一些自动化测试。
在《iOS 测试指南》书中，大概也进行了一个分类，ynm3k 属于扩展型的，扩展型的工具只是提供了一些 JavaScript 的开发库，用户只需要 import 进来，可能就会有更简化的写法和更强大的功能，然后但是对本身的 UI Automation 的，就基本上没有改变。
但是通过苹果提供
performTaskWithPathArgumentsTimeout接口进行进程间通信的这种自动化测试工具，我在书里面把它归类为驱动型的测试工具。使用驱动型的测试工具，用户可以有更多种语言的选择，并且可以拥有动态的调试功能。但是驱动型的测试工具，无法在 instruments 的图形界面下运行，也就失去了，运行自动化测试的时候同时检查内存泄露，统计网络流量等功能。所以，工具对比下来只有适合不适合的说法，并没有绝对意义上的好与坏。
InfoQ：刚才也都是提到你的 UI 测试的书本，我希望你简单介绍一下这本书适合哪些读者，有没有什么你觉得特别值得推荐的书里面的内容可以分享给大家？
羋峮：我书里前两章写的很短，就说了一些基本的概念；第三章说的是单元测试的一些实践，并且完成一个简单的 app 的单元测试。
第四章就简要的介绍一下 Automation 的基础知识，很多自动化测试工具都是基于 UI Automation 来做的。不管是用哪个工具，从底层了解一些 UI Automation 的 API，都是有帮助。
第五章写的是 iOS 端的 Web 测试的一个方案，介绍了两种工具，其中也提到了 Appium，我也更推荐使用 Appium 来做自动化测试；然后第六章介绍了持续集成方面的事情，就是三到六章应该都是一个综合解决方案中的各个部分的技能的分散介绍。然后第七章介绍了一下，除了功能测试，手机端还需要去做哪些类型的测试，或者借助工具，我们应该怎么样简单的去确认，或者是去更精确的衡量；第八章是基于第三、四、五、六章然后做了一个最后的一个汇总介绍。因为书写的比较慢，在书稿还没有完全完成的时候，苹果就发布了 XCode5 和 OS X 10.9。在这一次更新以后，苹果本身也提供了一个持续集成的解决方案。在 XCode5 中还升级了单元测试框架。所以这一系列的变化就有了第九章的内容。
书的内容本身是想给刚入门 iOS 测试的工程师来看的。最早写书的主要目的也是，为了汇总一些资料。因为相关 iOS 测试的资料实在是太少并且太分散了。但是当书写完以后，才发现原来用到了 3-4 种变成语言。所以，现在看来可能还需要读者有一定的编程功底。所以本书的最适合读者是有编码能力或者测试经验的人需要了解移动端测试的这样一个人群。
InfoQ：你刚才讲到你的工具是开源的，然后你花了业余时间在这个上面，然后你的这本书是你的一个人通过业余时间写作完成的作品，我就想知道你开源和写作大概花费了你多少的业余时间，业余时间里面你是如何安排这些事情的？
羋峮：做开源的时候还好了，只需要挤出来一定的时间把框架搭完了，慢慢的可以用零散的工作去实现个别功能，或者优化个别功能。写书的话，整个过程中，其实还是需要一些大块的时间去投入，因为自己语文水平比较差，有的时候明白一件事，可能还要去想一想怎么能写明白。对于我而言，往往需要大块的时间去写书，需要写一个小时以后感觉才能进入状态，进入状态之后写作效率还算 OK。一般一次写作的时间会在 4 个小时以上。我自己估了一下，如果一页的内容，代码和截图占到一半以上的话那一页的时间，大概是 1.5 个小时，如果是这一页内容是纯文字的话，那一页的时间大概是两个半小时。所以整个大概写了四百个小时左右。
InfoQ：这确实是一个很大的工作量。感谢你为大家带来的开源工具和作品，谢谢你！