专项测试
　　在功能测试之后，需要来说说专项测试了。专项测试是很多测试类型的统称。在专项测试中，主要需要做性能测试、稳定性测试、兼容性测试、电量测试和网络测试。本文不会将这些测试类型的具体做法都进行介绍。针对 iOS 的特点，主要介绍性能测试中的内存测试、电量测试和网络测试方案。
　　内存测试
　　内存测试在 iOS 系统中特别重要。首先，iOS 系统会对应用有内存数限制，超过一定数量程序会被强行关闭。另外，不断少量的内存泄露会使程序卡顿，极大地影响了用户体验。内存测试需要有内存测试工具，主要使用 Xcode 和 Instruments 这两个 Apple 提供的工具。在检测内存时，首先推荐 Xcode 的代码分析功能。选择图 3 中的 Analyze，Xcode 会对项目代码进行内存分析，如果发现有循环引用等问题时，Xcode 会给出提示，以及详细的引用关系，如图 4 所示。

　　在对内存静态分析没有问题之后，需要使用 Instruments 这个工具对内存进行动态扫描了。在 Xcode 中选择 Product>Profile，编译程序并唤起 Instruments，选择 Leaks 模板，操作页面，查看程序是否有内存泄露。


　　
　　图 5. Instruments 分析结果

　　当 Leaks 模板显示红色条状时（如图 5），说明有明显的内存泄露，可通过 Leaks 的 Call Tree 来查看程序的调用树，如图 6 所示。


　　图 6. call tree 分析

　　选择 Call Tree 后，勾选左侧的 Invert Call Tree、Hide System Libraries 选项，此时可以看到右侧显示程序中存在内存泄露的方法，单击左侧箭头可以展开内存泄露下程序的调用树，如图 7 所示。在这里你可以详细地看到代码的调用过程，很清楚地定位到有问题的代码位置。


　
　　图 7. 泄露定位图

　　当然，有些并不严重的内存泄露 Instruments 不会用红色标示出来，这时需要通过查看内存的增长情况来判断是否有内存泄露。例如：内存的分配一直在增长，当退出某一个页面时，内存并没有丝毫的释放。这时需要仔细地分析和耐心地排查了。具体的一些更细节的内存排查方法，还需要参考苹果官方文档和一些内存专题的文章学习，以进行更加细节的内存问题定位。
　　电量测试
　　电量测试在专项测试的优先级中，并没有稳定性和兼容性测试高。但是稳定性和兼容性方面业内已经比较成熟了，在各种技术分享和一些技术文章中也有大量的实践讨论。所以，本文不再针对稳定性和兼容性测试进行描述，直接开始电量测试相关的测试总结。iOS 的耗电量都是一些硬件设备造成的，当然硬件的很多不合理和不必要的使用都是通过软件程序来控制的。所以 Instruments 工具的电量分析会帮助你扫描在 iOS 应用使用过程中各种耗电的硬件是打开还是关闭状态。比如，需要格外关心 GPS 的使用、Wi-Fi 和手机网络的使用频度等。如图 8 所示。此时的电量分析只能通过一些硬件的使用开发来定性地进行分析。


　　
　　图 8. 电量分析

　　在电量分析中，更需要有一款能定量输出具体电量消耗的工具。电量分析可以使用 iOS App 进行检测，具体的 App 名称在此不具体说明了。App 检测电量都是通过一些软件的算法，虽然已经非常准确，但是还是存在一定的电量误差。准确的电量测试方法需要使用精密仪器——电量测试仪。电量测试仪的原理是中断所有手机供电（包括电池供电），然后电量测试仪为手机供电。电量测试仪测试出来的电量是手机整体的用电情况，并不是某一个应用使用的电量。所以，在使用电量测试仪时，需要尽量关闭其他应用。
　　电量测试的过程中为了减小误差保证测试数据的准确，需要注意以下几点：
　　Case 要有重点；
　　Case 要尽量的小；
　　Case 好是可持续时间长的，比如导航计算，视频播放和音频播放；
　　Case 如果不可持续，需要重复多次，取平均值。
　　小黑屋测试法
　　之前介绍的测试方法都需要有专业的测试工程师介入，进行测试工作的统一规划管理。很多初创的公司，可能还没有测试工程师，或者有很少的测试工程师，没有办法把测试工作做得非常细致。有没有什么好办法呢？其实，有一个效果还不错的方法——小黑屋测试法。
　　首先下来强调一下小黑屋测试法的偶然性，小黑屋测试法不适合对产品质量要求非常高，也不适合有一定用户规模的产品。小黑屋测试法只是在人力严重不足的前提下，一种投入产出比比较高的测试方法。
　　小黑屋测试方法是一个团队，无论你是开发工程师、设计师或产品经理。大家利用 2-4 个小时的时间，每个人拿着不同版本的手机，安装一个新版本的程序，大家在一起使用，并且给出一些功能方面的问题反馈或者建议。小黑屋测试法不只可以发现功能问题，还可以收集很多用户易用性或用户体验方面的问题。小黑屋测试法是大家一起测试，使用不同版本的机器，兼容性测试和稳定性测试也会被涵盖一些。
　　在小黑屋测试法的使用过程中，需要注意一些问题：
　　参加测试的成员需要进入一个相对比较封闭的空间，这样能保证所有成员的注意力和沟通顺畅度。
　　需要有一个懂技术懂产品的 Leader 进行方向引导，这一点非常重要。在所有成员进行发散的任意使用时，会出现很多问题。有些问题可能需要进行深挖，尽可能多地找到一些问题。有些问题可能是不太重要的问题，不需要分散其他成员注意力，在临场问题方向的把控需要这名 Leader 来完成。所以，一次成功的小黑屋测试，Leader 的引导非常重要。当然，Leader 还需要开放的心态，以免自己主动回避一些主要问题，导致本次测试跑偏。
　　参加测试的成员，需要认真仔细地跟随大家一起完成这次小黑屋测试方法。不能空谈，需要动手一点一点地确认。有时，需要在别人的反馈问题上进行排查确认，有时需要给别人提供复现思路。
　　需要有人记录问题。在大家热情反馈问题的时候，需要有记录员记录所有的反馈的问题。问题的优先级别和重要程度也需要当时经过大家讨论之后马上确认。在小黑屋测试完成以后，把完成的记录整理成修改意见发给所有成员，这样可以保证大家的积极的心态。
　　小黑屋测试法，非常高效且适合初创团队。大家集思广益，会发现很多问题。但是小黑屋测试法也会有一定的弊端，例如比较细致，需要设备仪器测量的问题，不会被发现。还有很多团队，小黑屋测试法组织得不好，大家测试的积极性不高。导致小黑屋测试法效果非常差。方法是方法，怎么使用还需要大家结合自己团队的特点，找到适合的使用方式。
　　小流量发布及线上监控
　　小流量发布
　　无论测试是仔细还是粗糙，发布才是目的。不管怎么样的测试，总是不能把所有的问题都扼杀在发布前阶段。为了降低风险，一般都不会把刚开发完成的应用直接发布给全量用户。这时，需要通过一些技术手段，把新版本的 iOS 应用发布给一些种子用户或某一部分用户。iOS 平台不允许随意对外发布产品，必须经过 App Store 的审核上架。对外发布小流量需要有一定技术平台来保证。之前 iOS 小流量发布平台比较的是 TestFlight，之后被 Apple 收购，TestFlight 平台发布小流量也需要审核。另外，TestFlight 服务在国外，国内访问网速等问题导致小流量发布不太方便。
　　国内在 iOS 小流量分发平台也有一些厂家的服务支持。个人比较喜欢 fir.im。fir.im 是国内早服务 iOS 小流量分发的厂家，而且一直以来服务都非常不错，工具链建设完成。开发者可以通过一行命令进行小流量发布。
　　在小流量分发这个领域，需要严格遵守苹果官方对于应用发布的一些规章制度。切忌不要为了一时痛快，使用一些非常规手段，短期看貌似增加了测试用户数，也可能是在一段时间之后永远地损失了很多忠实用户。先来说说 iOS 证书的事情吧，iOS 开发者分为个人开发者和企业开发者两种身份。当然，两种开发者的区别并不是字面上的意义的区别。个人开发者必须发布应用到 App Store，并进行审核。企业开发者只能在内部发布自己的 iOS 应用。个人开发者和企业开发者的证书是不一样的，当然如果违规发布，苹果官方会封闭你的证书，取消你的开发者资格。企业证书需要企业提供一些法律信息，例如人数规模等。没有企业证书的只能通过 AdHoc 证书对外发布，证书有设备数量限制，数量为 100 台。国内的一些 iOS 小流量分发平台，为了争取用户，会免费为开发者提供一些企业证书，发布小流量时没有用户数的限制。小流量测试可以很快速地扩散。但是当这个证书被苹果察觉并且查封的时候，开发者必须更换证书，使用之前证书的用户这样失去了联系，没有办法收到任何的升级提示。
　　在选择小流量分发平台时还需要考虑一些安全方面的因素。在 MDCC 2015的平台与技术 -iOS 专场，看到了阿里巴巴安全工程师郑?（蒸米）的分享，iOS 系统在企业证书分发这个领域上有一些安全隐患还没有及时处理。所以，在挑选 iOS 小流量发布平台的时候，还需要多考察一下。
　　用户反馈和线上监控
　　产品发布之后，需要一定手段的数据收集工作。通过数据的分析和加工来确定，是否到达了本次发布的目的。也是通过数据来确认是否有一些高危的问题在扩散。在相关测试领域内的数据，可以分为用户主动上报数据和程序自动上报数据两类。
　　让用户上报使用过程中的问题和疑惑。因为在使用 iOS 应用的过程中，可能会遇到各种各样的问题。其中包括，移动网络方面、地理位置方面和一些复杂场景的问题。在发布小流量或者全量版本以后，需要密切注意用户反馈方面的问题。反馈信息会上报用户使用的 iOS 应用的版本、iOS 系统的版本，用户的描述信息还可能有用户遇到问题时的截图等信息。一般 iOS 应用都会有用户反馈的一些功能，但是功能入口都隐藏的比较深，用户不太容易找到。国外的厂商 Instabug一直在做用户反馈相关的开发和优化工作。国内比较的知乎使用 Instabug 提供的服务，用户反馈变得越来越方便。Instabug 自动帮助用户截图，还可以在截图中标示出重要区域。Instabug 还可以记录，问题出现前的用户操作行为。一个反馈的信息非常全面，可以帮助开发工程师更方便的定位问题。
　　当然，有些用户还喜欢在 Weibo、Twitter 或微信公众账号里反馈问题。所以，可能还需要时刻关注用户在社交网络方面的情绪发泄。业内把这种数据监控叫做：舆情监控。舆情监控在市场上也有一些收费的服务存在，也可以利用爬虫自己进行开发。在拿到第一手的用户反馈以后，可能还需要查看一下 iOS 应用的性能数据，来更进一步确认是否有一些质量风险。
　　有些问题用户会主动上报，但有些用户则无法主动上报，这时需要有一定的数据收集机制。例如：用户的 Crash 日志、程序启动时间、主要后台 API 的访问速度、页面的渲染速度等。这些数据需要一个专门的平台负责数据的存储、加工和分析。在收集性能数据领域，不得不说 Fabric。Fabric 是 Twitter 推出的实时数据分析平台，通过简单的设置可以帮助收集 Crash 信息、用户启动数、新用户数等数据。但是非常遗憾的是，由于网络上的一些连通性问题，Fabric 在国内的表现并不是特别好。国内在数据收集方面的知名品牌有 Bugly和 BugHD。
　　Bugly 是腾讯出品的一款 Crash 信息收集数据平台。数据殷实可以帮助开发很快定位问题，并且非常实时地分析问题是否得到了解决。BugHD 是 fir.im 出品的 Crash 实时收集数据平台，用户 UI 的设计非常出众，很大程度提升了数据展现的效果，而且加入了问题标注功能，方面开发工程师跟踪问题。
　　当然，如果还想收集更多的用户数据进行各种个性化分析的话，可能需要自己开发大数据平台进行数据分析了。国内很多大公司都有自己的数据平台。当然投入也是非常大的，在这里不再过多阐述。
　　线上监控的意义是，随时监控 iOS 应用的表现，随时发现问题，随时处理。iOS 平台的应用发布决定了，要真正地处理一个问题必须通过 App Store 发布一个新版本，并且引导用户更新，这个问题才能被真正解决掉。有的时候监控平台发现了一些很严重的问题，不能快速修复也是非常着急的。iOS 能不能做到线上问题热修复呢？
　　线上问题热修复
　　线上问题热修复是指，不通过 App Store 发布程序，能在线动态地改变 iOS 程序的运行方式，从而达到改变 Bug 修复的目的。在之前，一般使用 WaxPatch 的工具，通过动态下发一段 Lua 脚本来实现这个功能。但是在 iOS 平台转向 64 位时，WaxPatch 没有及时跟进，无法继续满足广大 iOS 开发者。国内的 iOS 开发者在这时推出了 JSPatch。JSPatch 是一个 iOS 动态更新框架，只需在项目中引入极小的引擎，可以使用可以使用 JavaScript 调用任何 Objective-C 原生接口，获得脚本语言的优势：为项目动态添加模块，或替换项目原生代码动态修复 Bug。
　　在拥有线上问题热修复以后，线上监控才变得更加实用和敏捷。线上监控和线上热修复形成了从一个问题的发现到解决的闭环。很好地解决了 iOS 发布的实时性的问题。当然，在线热修复带来的版本管理也需要有一个内部的管理系统来支持在线热修复技术更好落地。
　　结束语
　　在介绍完发布前测试和发布后测试两大部分以后，iOS 测试实践基本功能介绍完成了。当然，其中忽略了很多笔者认为已经比较成熟的方案和技术。例如：兼容性测试和稳定性测试。还有一些由于数据保密的问题，也没有办法展开来讲。一直特别想给大家介绍一下 iOS Crash 收集和分析方面的小细节，但也是由于数据的一些问题没有办法展开细致的描述，欢迎大家能线下交流一些特别具体的问题。