2.3 iOS平台的特殊性
iOS平台作为一种独立的操作系统平台，有很多其他平台所没有的特性。
2.3.1 证书
我们在找工作时，需要向用人单位出示学校颁发的毕业证书，同理，要想我们开发的应用能够在iOS设备上安装启动，就需要向iOS设备提供由苹果公司颁发的证书，证明我们的应用是经过苹果公司官方认证的。iOS设备在启动App前，会先验证证书是否合法，这个过程被固化在了iOS系统中，除非手机越狱，否则都要经历这个过程。
要想开发iOS应用，首先要成为苹果公司认证的开发者（虽然Xcode 7之后可以用个人非付费Apple ID进行真机调试，但是不适合团队开发和正式提交AppStore发布，因此非付费Apple ID没有算作开发者账号来进行介绍）。开发者账号有四种不同的类型，分别是个人账号、公司账号、企业账号和教育账号。其中个人账号和公司账号为99美元/年，企业账号是299美元/年，教育账号是0美元/年。我们在开发和测试iOS应用的时候，不能一直在模拟器上进行，总是要在真机上进行调试和验证，通过非AppStore渠道安装的应用，如果想要安装到设备上，就要将这些应用导出为iOS可识别的ipa格式安装包，在导出安装包时，最重要的一个因素就是包所使用的证书，即包的签名方式。刚刚提到的两种不同金额的开发者账号可以申请的证书类型也是不同的。苹果的证书体系非常烦琐复杂，这里不再赘述，先简单列举一个表2-1说明一下与发布有关的证书。
下面详细介绍这三个在iOS项目中经常见到的证书类型。
AppStore方式：可以提交AppStore发布的最终极版本，但是只能通过AppStore下载安装。三种开发者账号均可以申请该签名方式。
Adhoc方式：允许设备不通过AppStore下载而直接安装，然而，对于Adhoc方式发布的App或者在真机调试时，苹果公司会由一个文件来限制可安装的设备列表，里面是iOS设备的UDID（设备标识），每个设备只有一个独一无二的UDID，只有在文件中添加了UDID的设备，才允许安装Adhoc的包，每个开发者账号在缴费周期内只允许100台设备添加到文件中，也就是最多只有100台设备可以安装Adhoc签名的包。同样，三种开发者账号均可以申请该签名方式。
In House方式：又称企业签名方式，可以不通过AppStore下载，也不限制安装的设备数。这种签名方式只有企业账号可以申请。虽然不限制安装的设备数，但是苹果公司严禁企业签名的包流入用户手中，只允许公司内部小范围内安装体验，一旦发现有违规，就会做永久下架处理。所以iOS平台没有可供大量用户提前体验的灰度渠道。
本节只简单介绍苹果公司的账号和证书体系，以及对App开发和测试带来的影响，对于其中涉及的具体实现细节和一些加密算法没有做重点说明，网上相关的资料很多，感兴趣的读者可以自行查阅。
2.3.2 越狱
前面介绍的是开发或者安装App所必须有的证书。但是，如果iPhone手机本身越狱了，那么就不存在任何证书问题。每一个iPhone或者iPad用户，应该都听过越狱这个词。越狱就是获取iOS设备的Root权限，打破手机原版系统的限制，用户可以自由安装各种插件、访问和获取系统文件，从而更便捷地控制手机。
iOS系统与Android系统最大的区别就是对用户权限的限制。Android系统是完全开放用户权限的，用户可以访问甚至修改系统文件，可以从各种渠道下载应用；而iOS系统则要封闭许多，用户的权限非常低，无法访问系统文件，应用只能从苹果认证的AppStore中下载。iOS系统的封闭性会让刚使用iPhone和iPad的用户很不习惯，因此会有很多用户选择越狱。
越狱有什么优点？越狱后可以获得更高的系统权限，可以自己修改和管理系统文件，可以安装需要高系统权限的应用，例如浏览器插件、蓝牙传输文件等功能；越狱后既可以安装AppStore提供的免费应用，也可以免费安装破解版的收费的应用；越狱后可以随意更换主题、图标等，让手机更有个性。
越狱的这些优点同样可以为测试所用。如测试性能用到的远程连接工具openssh、用于录屏的display recorder，以及启动App和抓取数据包等操作要用到的命令行工具等，都只有在越狱设备上才可以安装。
越狱也同样存在不容忽视的缺陷：越狱后会导致系统不稳定。开放了系统权限，同样意味着系统暴露在无保护的状态下。你可能会修改它，软件也可能篡改它，导致系统崩溃；越狱有一定的失败率，且有一定概率会对硬件造成损伤，而且一旦越狱，将无法享受保修服务；设备越狱后，一旦升级新系统，以前的越狱就会失效，需要重新越狱。
2.3.3 灰度
产品在正式发布之前，都会发布一个Beta灰度版本，也就是对所有用户公开的测试版本，又称公测。因为开发者和测试人员的时间和精力有限，总是没有办法涵盖所有用户所处的网络条件和用户操作场景，所以会提前放出一个经过测试的、功能完整、性能相对稳定的灰度版本，让用户帮忙验证是否在不同的场景下还会遇到问题。我们总是希望有大规模不同使用习惯的灰度用户能够使用我们的Beta版本，以提供更多的反馈，帮助我们发现未知的缺陷，不断优化和提升产品质量。可以说，灰度版本是软件生命周期的必经阶段。然而，由于苹果公司规定，iOS平台软件的正式版本必须通过苹果官方应用商店AppStore才能发布，而用于内部开发和调试的版本也受到签名和设备的限制，不能随意推送给用户。于是iOS应用的灰度渠道只能寄希望于越狱用户，通常采用91助手越狱版向越狱用户进行推送。
随着时间的推移，人们已经适应了iOS简洁、友好的交互界面，而且免费的iOS应用越来越多，加上越狱可能带来的系统稳定性下降和硬件损伤等风险，因此，选择将设备越狱的苹果用户越来越少，灰度渠道的用户也越来越少。在iOS 8上，苹果提供了一种新的灰度渠道，将TestFlight整合进了iTunes Connect，开发人员可以通过电子邮件邀请用户通过TestFlight下载应用一起来参与测试。这个渠道看起来没什么问题，实际上最大的问题就是TestFlight的活跃用户太少。要用TestFlight来发布灰度版本，有以下几个条件。
（1）开发者自己收集总数不超过2000个的邮箱账号提交TestFlight。
（2）提交的App版本要审核三天（这已经比AppStore审核快了N倍）。
（3）用户需要下载TestFlight客户端到手机，登录自己的Apple ID并填写邮件里的邀请码。
（4）一个邀请码只能在一个Apple ID使用。
（5）第二次发布体验版的时候，用户需要手工去TestFlight里点击更新。
实际上我们遇到的问题还有以下几方面。
（1）通过各种论坛收集的用户邮箱账号提交后，有三分之一的用户收不到邀请码。
（2）剩下三分之二的用户里又有二分之一的用户不会去下载灰度体验版本。
（3）仅剩的下载了体验版本的用户使用不活跃，也没有什么反馈提交。
（4）反馈的信息不足，联系用户困难，基本联系不上，复现问题的概率很低。
最后我们采用了企鹅众测（tesly.qq.com）作为灰度发布的主要渠道，企鹅众测又称Tesly，主要是通过建立iOS测试军团的方式将测试任务发布给普通用户，用户获取任务后进行测试并提交反馈获取积分奖励。通过这种方式可以有效调起TestFlight上灰度版本的下载和体验率，获取项目组需要的质量信息。
然而，尽管有了这些途径，相比Android平台一款应用动辄几万甚至几十万的灰度用户量，iOS应用的灰度用户杯水车薪，甚至没有灰度，这就给测试人员带来了更大的挑战。产品没有经过批量用户的检验就要直接接受苹果的审核，审核通过后才能正式上架推送给正式用户。用户对正式版本的忍耐度普遍没有对公测版本的高，一旦集中爆发某个问题，可能就会给用户带来质量极差的感知，导致用户大量流失。
2.3.4 AppStore审核
AppStore是苹果公司提供给开发者发布和用户下载的应用平台。如前文提到，为了给发布者营造一个公正、良性的发布环境，给用户提供安全、可靠的应用,苹果公司制定了一套严格的审核规范，每个提交AppStore的应用都会经过苹果公司在技术、内容和设计规范等一系列多重规范的审核。详情见苹果AppStore审查官方指南：https://developer.Apple.com/APP-store/review/guidelines/。
苹果审核，是iOS应用从业者又一个不得不说的痛，绝大多数公司都有过产品被拒的经历，可以说是一言不合就会被苹果以各种理由拒绝。苹果审核时间一般需要一周左右，一旦被拒，修复后再提交，前后两次就要耗费两周，如果多次被拒，就很可能成为苹果的重点审查对象，审核周期无法保证，这无疑严重影响了产品的正常发布进度。每位iOS平台相关的从业者都应该系统理解苹果审核的规则，尽量规避这些情况的发生，保证产品的正常发布周期。
作为一名测试人员，既要尽可能挖掘产品隐藏的缺陷，保证产品的质量，还要根据AppStore审核规范协助项目组对App进行提交前的验收，减少不必要的错误，降低审核被拒的风险，为App顺利上线把好最后一道关。
根据苹果AppStore审查官方指南，同时结合之前曾经出现过的审核被拒的案例，我们建立了一套上线前的checklist，每次版本提交AppStore之前，项目组的不同角色分工合作，对提交材料进行验收，验收合格后正式提交苹果审核。
验收对象按照模块可以划分为三部分：应用的ipa包、应用说明资源、应用内容和功能。
应用的ipa包验收主要是对info.plist中的配置文件、私有API、第三方SDK库、文件大小、是否有Crash上报，以及64位和32位等内容是否符合苹果要求进行检查。
应用说明资源验收主要是对应用的介绍和用以辅助说明的图片、视频等进行检查，确保内容真实，规格属性符合苹果要求。
应用内容和功能是苹果审核最为严格的部分，通常苹果公司的审核人员会安装应用体验功能，稍有问题就可能会被拒绝，这也是在经过迭代、集成和回归测试后，在上线前仍要走查功能的原因。
除此之外，由于苹果公司的审核团队是在美国，因此在上线前验收还要关注是否兼容IPv6网络，美国VPN网络下是否能正常连接等，避免在这些场景下出现问题而被拒。
2.3.5 自动化测试工具
iOS平台还有一个特性是自动化测试工具比较少。说起Android的UI自动化工具，人们总可以说出很多现成的自动化框架来，如UIAutomator、Cabalash、Appium、Robtium等。虽然各个框架都有自己的优缺点，有不同的适用场景，但是现有的框架基本可以满足自动化测试的需求。即使有特殊的要求，因为Android系统是开源的，完全开放用户权限，测试人员也可以根据实际需要进行二次封装开发就可以轻易实现。
在iOS平台上就没有这么方便了，虽然iOS平台的自动化工具有UITest、XCTest、KIF、Cabalsh、Appium等，但是距离运用到每日迭代持续集成还有很长的距离。
（1）框架稳定性不高。当用例数目比较少、运行时间较短时，现有的自动化框架基本没有问题，但是随着用例数的增多，框架可能要连续运行多个小时，这时大部分框架就会暴露出稳定性不高的问题，频繁出现闪退，只能重新启动项目，增加了人为干预的时间。目前只有XCTest在这方面比较有优势，这会在第5章进行详细讲解。
（2）无法获取底层接口。由于iOS系统的封闭性，导致无法获取系统root权限和系统状态等，这就无法对文件进行操作，也没办法根据系统辅助判断运行结果，给自动化的运行带来了难处。
（3）无自动分析运行结果的日志系统。脚本运行不是目的，最重要的是要看到运行结果，对异常情况能够快速定位问题。框架自身的日志系统需要人工去逐一排查用例运行结果，不能满足用户结合自动化脚本分步骤展示日志的需求，这就延长了自动化运行后确认结果的时间，增加了新人的学习成本。这个问题通过对框架的二次开发和封装解决，会在第6章介绍。