前言
　　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. 基于场景的混合式测试方法

　　有经验的测试工程师会说，这么多组合功能怎么可能测试完成了。是的，测试根本无法完成，探索式测试还强调给测试工程师足够的自由，哪些需要进行测试，哪些功能不需要进行测试都由测试工程师决定。测试工程师应该测试用例的运行情况来决定具体运行什么样子的测试用例。当然，探索式测试在国内不太被接受的点也在于给测试工程师太多的自由，团队中别的成员角色会质疑。
　　我个人认为，探索式测试可以在局部的地方使用，这个局部包含局部的功能点，也包括极个别团队的测试工程师。很多漏测都是因为想不到有某种场景或某种情况，而探索式测试能帮助我们想到更多的测试场景。