作者-芈 峮
前言
iOS 开发从 2010 年开始在国内不断地升温，开发和测试相关的问题不绝于耳。iOS 测试主要涉及哪些内容？又有哪些挑战呢？带着疑问我们开始第一个大问题的讨论。
iOS 测试的范围和可能遇到的挑战
iOS 测试范围
一般来说，每一个 iOS 应用的背后都会有一些后台服务。后台服务会给 iOS 应用提供丰富的数据和精彩的内容，后台服务的测试必须要包含在 iOS 测试中。当然，本文主要讨论一些 iOS 测试领域的内容，后台服务的测试在此就直接掠过。因此，下文提到的 iOS 测试主要指在 iOS 移动端需要做的测试。
iOS 测试需要着重从以下 5 个方面入手：
- 功能测试
- 性能测试
- 稳定性测试
- 兼容性测试
- 电量测试
当然，还可能有一些测试类型没有被归纳进来，这里是从 iOS 测试共性上来归纳的测试类型，还有一些 iOS 应用需要格外注意以下安全性的问题等。
功能测试一般会花费测试工程师 7 成以上的精力，每一个新功能点，都需要自己的验证。老版本功能点也要进行严格的回归。稍有疏忽可能就会造成遗漏。当然，功能测试方面不光需要细心，也有很多技巧和经验，之后的内容会进行重点阐述。
性能测试的范围可大可小，很多公司把稳定性、电量等内容都会算作性能测试的范围。当然，怎么划分都是合理的。本文中的性能测试特指 CPU、内存和 I/O 三项指标。CPU 的过度占用说明应用程序存在着一些潜在风险和优化空间，CPU 的过度使用也会损耗大量的电量。内存的持续上涨，说明程序可能存在一定的内存泄露，并且 iOS 系统会对应用内存进行严格的限制，一旦超出限制，程序会被系统杀死。I/O 的合理性也需要在测试中观察，频繁的 I/O 会导致程序变卡变慢，用户体验非常不好，严重的甚至会致使用户失去耐心，造成用户流失。
稳定性测试是检验应用程序长期稳定的运行能力。程序频繁地异常退出非常影响用户体验，次数过多会导致用户无法使用 iOS 应用，这时，用户可能会永久删除应用。一般的稳定性测试会通过一些边界值和非常规的操作，来验证应用程序的问题性。稳定性测试也需要探索，因为有时稳定性测试的通过，也不能说明应用程序足够稳定。
兼容性测试又被称为适配测试，主要由硬件兼容性测试、软件兼容性测试和数据兼容性测试组成。兼容性测试的目的是要确保应用程序可以在所支持的系统平台上正常运行，而兼容性测试 iOS 设备的多样化使得兼容性测试更加地重要。
随着 iOS 设备的硬件不断更新和用户越来越多地依赖移动设备，iOS 设备的电量逐渐成为用户非常关心的问题。如果 iOS 应用由于某些缺陷造成了设备电量的迅速下降，用户会毫不犹豫删改应用。由此，电量测试就显得愈发重要。
iOS 测试可能遇到的挑战
如果你是一位经验丰富的测试工程师，但是还没有接触过移动应用相关的测试，可能会有这样的疑问。从 iOS 测试范围来看，并没有什么新的测试类型，之前所有的测试也都会做很多的功能测试，关注性能测试、稳定性测试、兼容性测试等，还会遇到什么挑战？虽然从测试类型上并没有引入新的测试类型，但是 iOS 相关的特点决定了，iOS 测试的工作量将会是之前软件测试工作量的好几倍。具体可能会遇到以下一些挑战：
- 和时间赛跑。iOS 绝大部分应用只能通过 App Store 发布。所以，开发商都会尽量频繁地发布自己的应用，并尽可能获取更多的用户。每次发布前的测试都不会有特别充分的时间进行特别详细的测试。所以，iOS 测试工作者必须在测试之前进行分析和选择，找重点和容易发生错误的地方测试。
- 网络情况异常复杂。在测试一个需要网络数据的 iOS 应用时，网络状态对应用影响非常大，而且网络状态还非常多。从网络数据接入点来划分可以分为：Wi-Fi 和手机网络。从网速来进行区分可以分为：弱网络和强网络。在这些网络情况下，程序可能使用不同的网络策略。弱网络如果处理不好，会直接影响到用户感受。如果需要播放一段视频或音频文件时，是否需要提示用户注意一下流量费用等。
- 纷乱复杂的用户场景。iOS 应用的开发者，完全没有办法控制用户什么时候打开应用，是横屏还是竖屏使用。更没有办法知道，在应用正在被使用时，用户是否需要接听一个电话呼入或浏览一下短消息；更不会了解到用户这时是很悠闲地开启了 iOS 应用还是很急切地打开应用需求帮助。在以上这些复杂的场景中，怎么能保证用户体验？而 iOS 应用的功能正常等也都需要测试来论证。
- 非统一化的运行环境。iOS 应用可以运行在 iPhone 上，也可以运行在 iPad 或 iPod 上。虽然 iOS 的用户有着很好的更新系统的习惯，但依然不能保证 iOS 运行在统一的 ROM 下。兼容性测试的挑战非常大。
发布前的测试
针对以上 iOS 测试的一些挑战，和过去 iOS 测试领域的实践与总结。我们更倾向于把一个测试过程分为：发布前的场内测试和发布后的用户测试或用户反馈。之后的内容主要会围绕发布前测试和发布后测试两大部分进行详细的阐述。
功能测试方法阐述
在每次发布前的测试，功能测试都是最主要的测试内容。测试工程师不但要仔细验证新功能点的功能是否正常，还要关心之前的老版本功能点是否正常。功能测试虽然工作量很大，但如果有一份比较详细准确的测试用例作为指导，工作就会变得有条不紊一些。所以，本文将详细阐述一下测试用例的设计方法。
- 传统测试用例方法
传统的测试用例方法，无非是等价类、边界值、因果图分析法和正交分解法等几大方法。一般测试工程师都会对这几种方法纯熟使用，在此就不多赘述。一个功能点，可以根据以上几个方法产生出正常的功能测试点和异常的功能测试点。但是，移动端有一些特点决定了，传统的测试用例设计法是不够用的。比如：测试“大众点评”App 的“附近的餐厅”功能。随着位置的变化，看到的餐厅数据可能完全不一样。再比如，一段音频的播放功能测试，可能会受到耳机插拔、电话呼入、别的音频播放等场景的影响，表现出来的结果也完全不一样。iOS 应用还有很多这样的场景，所以测试用例设计方法也需要更新一下了。
- 探索式测试方法
探索式测试方法是由 Google 测试专家 James A. Whittaker 发明，并为此撰写了一本《 探索式软件测试》书籍来详细介绍其中的一些方法。过去的几年，国内的测试领域也对该方法有过一些实践和讨论。重要成果是好友高翔所著的《 探索式测试实践之路》和好友徐毅主持翻译的《 探索吧！深入理解探索式软件测试》。
在学习探索式测试方法的时候，一定不能着急实践，应该找本书认真的看，并且做一些学习笔记。当对探索式测试有一个全面的认识以后才可以进行实践。探索式测试方法分为：全局探索式测试方法和基于场景的混合式探索测试方法。全局探索式测试方法会分为 6 大类测试类型和 23 种测试方法。更加详细的可以参看下图。
图 1. 全局探索式测试方法
全局探索是用来设计所有的测试点该怎么测试的，但测试点不应该是独立的，而需要组合才能完成一个完整的功能测试。通过基于场景的混合式测试方法，将之前的功能点混合到一起。基于场景的混合式测试方法一些大体的路径分支可以参看下图。
图 2. 基于场景的混合式测试方法
有经验的测试工程师会说，这么多组合功能怎么可能测试完成了。是的，测试根本无法完成，探索式测试还强调给测试工程师足够的自由，哪些需要进行测试，哪些功能不需要进行测试都由测试工程师决定。测试工程师应该测试用例的运行情况来决定具体运行什么样子的测试用例。当然，探索式测试在国内不太被接受的点也在于给测试工程师太多的自由，团队中别的成员角色会质疑。
我个人认为，探索式测试可以在局部的地方使用，这个局部包含局部的功能点，也包括极个别团队的测试工程师。很多漏测都是因为想不到有某种场景或某种情况，而探索式测试能帮助我们想到更多的测试场景。
专项测试
在功能测试之后，需要来说说专项测试了。专项测试是很多测试类型的统称。在专项测试中，主要需要做性能测试、稳定性测试、兼容性测试、电量测试和网络测试。本文不会将这些测试类型的具体做法都进行介绍。针对 iOS 的特点，主要介绍性能测试中的内存测试、电量测试和网络测试方案。
- 内存测试。
内存测试在 iOS 系统中特别重要。首先，iOS 系统会对应用有内存数限制，超过一定数量程序会被强行关闭。另外，不断少量的内存泄露会使程序卡顿，极大地影响了用户体验。内存测试需要有内存测试工具，主要使用 Xcode 和 Instruments 这两个 Apple 提供的工具。在检测内存时，首先推荐 Xcode 的代码分析功能。选择图 3 中的 Analyze，Xcode 会对项目代码进行内存分析，如果发现有循环引用等问题时，Xcode 会给出提示，以及详细的引用关系，如图 4 所示。
图 3. 选择 analyze 分析
图 4. analyze 结果
在对内存静态分析没有问题之后，就需要使用 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 收集和分析方面的小细节，但也是由于数据的一些问题没有办法展开细致的描述，欢迎大家能线下交流一些特别具体的问题。
转载处：
https://www.ibm.com/developerworks/cn/mobile/mo-cn-ios-testing/index.html