第 6 部分 - 测试和应用商店审批
测试
许多应用（甚至包括某些应用商店中的 Android 应用）在发布之前必须经历审批过程；因此，测试对于确保应用能够进入市场至关重要（更不用说在客户那里取得成功）。 测试可以采取多种形式，从开发人员级单元测试到跨各种硬件管理 beta 测试。
在所有平台上进行测试
.NET 在 Windows 手机、平板电脑和桌面设备上支持的功能之间存在细微差别，并且 iOS 上存在阻止即时生成动态代码的限制。 要么计划好在开发时于多个平台上测试代码，要么安排好时间在项目结束时重构和更新应用程序的模型部分。
使用模拟器/仿真器来测试操作系统的多个版本以及不同的设备功能/配置始终是良好做法。
还应该在尽可能多的不同物理硬件设备上进行测试。
云中的设备
手机和平板电脑生态系统会不断扩充，因此无法在不断增加的可用设备上进行测试。 为了解决此问题，许多服务提供了远程控制许多不同设备的功能，以便可以安装和测试应用程序，而无需直接投资购买大量硬件。
App Center 测试提供了在数百种不同设备上测试 iOS 和 Android 应用程序的简单方法。 有关详细信息，请参阅准备 Xamarin.Android 应用和准备 Xamarin.iOS 应用。
测试管理
在组织中测试应用程序或者为外部用户管理 beta 版程序时存在两个挑战：
- 分发 – 管理预配过程（尤其是 iOS 设备）并向测试人员提供软件的更新版本。
- 反馈 – 收集有关应用程序使用情况的信息，以及有关可能发生的任何错误的详细信息。
有许多服务可以帮助解决这些问题，方法是提供应用程序中内置的基础结构来收集和报告使用情况与错误，并简化预配流程以帮助注册和管理测试人员及其设备。
Visual Studio App Center 为这些问题提供了解决方法，可以提供测试版本分发、崩溃报告和复杂的应用程序使用情况信息。
测试自动化
Xamarin UITest 可用于创建可在本地运行的或上传到 App Center 测试的自动化用户界面测试脚本。
单元测试
Touch.Unit
Xamarin.iOS 包含一个名为 Touch.Unit 的单元测试框架，它遵循 JUnit/NUnit 风格编写测试。
有关编写测试和运行 Touch.Unit 的详细信息，请参阅使用 Xamarin.iOS 进行单元测试文档。
Andr.Unit
Android 上有一个相当于 Touch.Unit 的开源版本，名为 Andr.Unit。 可以从 github 下载该工具，并在 @spouliot 的博客中了解该工具。
App Store 审批
Apple 和 Microsoft 在其平台上运营着唯一一个应用商店：分别是 App Store 和市场。 这两家公司都锁定了自己的设备，并实施严格的应用审查流程，以控制可供下载的应用程序的质量。 Android 的开放性意味着有许多应用商店可供选择，从广泛使用且没有审核流程的 Google Play，到 Amazon 的 Appstore for Android，以及 Samsung Apps 等特定于硬件的商店，后者的分发范围更有限，并实施审批流程。
等待应用接受审核可能会有很大的压力 - 业务压力通常表示在“目标”推出日期之前提交应用程序进行审批，几乎没有犯错的余地。 该流程本身可能需要长达两周的时间，并且不一定透明：在最终被拒绝或批准之前，对申请进度的反馈有限。 拒绝可能意味着错过市场营销时机，特别是当这种情况发生多次，并且从最初推出日期与应用最终获批之间已过去数周时间时。
做好准备
第一条建议：提前规划好应用的推出，并为可能的拒绝和重新提交做好准备。 每个应用商店都要求在提交应用之前创建一个帐户 - 请尽早完成此操作。 如果你的应用是免费的，Google Play 的注册只需要几分钟；但如果它们是收费的并且需要提供银行和税务信息，则该过程会变得更加复杂。 Apple 和 Microsoft 的流程都比 Google 复杂得多，帐户可能需要一周或更长时间才能获得批准，因此请将此时间纳入推出计划中。
帐户获得批准后，就可以提交应用了。 以下文档介绍了提交应用的实际流程：
- 发布到 Apple 的 iOS App Store
- 准备好将应用发布到 Google Play
- Windows 开发人员应访问 Windows 开发人员中心来了解如何提交应用。
本部分的其余部分讨论应注意的事项，以确保应用顺利获得批准。
质量
获得批准听起来是理所当然的，但应用程序常常因为不符合一定的质量水平而被拒绝：毕竟，这就是策划的应用商店首先要有审批流程的原因！
崩溃是常见的拒绝原因。 如果你的应用很容易崩溃，则它肯定会被拒绝。 大多数开发人员在提交应用时并没有预料到它们会崩溃，但经常发生这种情况。 在提交应用之前对其进行全面测试，关注的重点不仅是确保一切正常，还包括处理常见的移动错误场景，例如网络问题和内存或存储空间等资源限制。 使用模拟器和物理设备进行测试 - 无论代码在模拟器中的运行情况如何，只有设备才能展示应用的真实性能。 使用尽可能多的不同设备，如果可以的话，请组建一个 beta 版测试人员团队 - 第三方服务可以帮助管理 beta 版分发和反馈。
所有移动操作系统都会终止启动速度不够快的应用程序。 允许的时间长短各不相同，但一般情况下，应用应该能够是在几秒钟内做出响应，并使用后台任务来完成任何需要更长时间的工作。 加载时间过长或在一般使用中响应不够灵敏的应用将被拒绝。 当后台发生某些情况时，请始终提供用户反馈，否则应用将看似崩溃，因而再次遭受拒绝。
检查边缘情况
开发人员遇到的常见陷阱是无法解决边缘情况，尤其是那些需要重新配置模拟器或设备才能正常测试的情况。 我们很容易忘记，并非每个客户都“允许”你的应用访问他们的位置，因为开发人员接受一次请求后，他们永远不会再次收到提示。 在审批过程中特别关注权限和网络使用，这意味着，在这些方面出现小小的疏忽就可能会导致被拒绝。
以下列表是检查可能遗漏的边缘情况的良好起点：
- 客户可能“拒绝”对服务的访问 - 尤其是在 iOS 中，仅当用户向应用程序授予权限时，才会提供对地理位置信息等数据的访问权限。 应用程序测试人员应该经常以初始状态重新安装应用程序，并禁止任何权限请求，以确保应用程序正常运行。 当客户改变主意时，可以打开和关闭权限以验证正确的行为。
- 客户无处不在 - 不要以为应用只会在其开发所在的城市或国家/地区使用！ 使用 GPS 坐标、日期和时间值以及货币的代码都可能受到客户位置和区域设置的影响。 所有平台都提供一个模拟器，可让你指定不同的位置和区域设置 - 请使用它来测试其他半球的位置，以及日期和货币格式不同的区域性。 纬度和经度值可以是正数或负数，小数分隔符可以是句点或逗号，日期的格式可以有多种 - 请妥善处理！
- 网络连接速度慢 – 应用开发人员往往在“理想的”快速且稳定的网络连接中工作，但在现实中显然不能保证这种网络质量。 在使用慢速网络连接（例如较差的 3G 连接）以及无法访问网络的情况下进行测试对于确保不会交付有 bug 的应用至关重要。 审批流程始终涉及到在飞行模式下对设备进行测试，因此请确保已亲自进行测试。
- 硬件各不相同 - 请记得在你打算支持的最旧、最慢的硬件上进行测试。 有两个方面可能会影响应用：性能（在旧设备上可能无法使用）以及对硬件功能（例如摄像头、麦克风、GPS、陀螺仪或其他可选组件）的支持。 当某个组件不可用时，应用程序应该正常降级（而不是崩溃）。
准则不仅仅是“指南”
Apple 以严格遵守人机接口准则而闻名，因为其平台的关键优势之一是一致性（以及可用性的明显提高）。 Microsoft 对实现流畅设计系统的 Windows 应用程序采取了类似的方法。 这两个平台的审批流程都涉及到评估应用是否遵守相关的设计理念。
这并不是说用户界面创新不受到支持或鼓励，但有些事情“不应该做”，否则应用将被拒绝。
在 iOS 上，这包括滥用内置图标或以不一致的方式使用其他已确立的象征；例如，使用“撰写”图标来执行除创建新内容之外的任何操作。
Windows 开发人员同样应该小心；一个常见的错误是无法根据 Microsoft 的准则正确支持硬件“后退”按钮。
请鼓励设计人员阅读并遵守每个平台的设计准则。
实现特定于平台的功能
在实现特定于平台的服务时，考虑因素要严格一点，尤其是在 iOS 上。 为了避免被 Apple 自动拒绝，以下 iOS 功能需要遵守一些规则：
- 应用内购买 – 应用程序不得为数字产品实施外部支付机制，包括游戏内货币、应用程序功能、杂志订阅等等。 iOS 应用必须使用 Apple 的基于 iTunes 的服务来实现此类功能。 有一个漏洞 - Kindle 阅读器等应用和一些基于订阅的应用允许在其他位置购买附加到“帐户”的内容，然后可以通过应用访问该内容，但在这种情况下，应用不得包含链接或引用应用外购买流程（否则，它同样会被拒绝）。
- iCloud 备份 – 随着 iCloud 的出现，Apple 审核人员对应用如何使用存储的要求更加严格（以确保为客户提供愉悦的远程备份体验）。 浪费可备份存储空间的应用可能会被拒绝，因此请适当使用缓存文件夹并遵守 Apple 的其他存储相关准则。
- Newsstand – 报纸和杂志应用非常适合 Apple 的 Newsstand，但应用必须实现至少一项自动续订订阅并支持后台下载才能获得批准。
- 地图 – 向移动地图添加叠加层和其他功能越来越常见，但请注意不要遮盖地图的“额度”信息（例如 iOS5 中的 Google 徽标），否则会导致拒绝。
管理元数据
除了可能导致应用程序被拒绝的明显技术问题之外，提交的内容中还有一些更微妙的方面可能会导致拒绝，尤其是与随应用程序一起提交的、要在 App Store 或市场中显示的元数据（说明、关键字和营销图像）。
- 图像 – 遵守有关应用程序图标和应用商店图片的平台准则。 不要使用带商标的图像，我们已经看到有些应用因为图标带有 iPhone 绘图而被拒绝！
- 商标 – 只使用自己的商标，避免使用其他任何商标。 有些应用因在应用说明甚至在 Apple 的 App Store 关键字中提及商标而被拒绝。
- 说明 – 不要使用“beta”一词或以任何方式表明来该应用尚未准备好在黄金时段推广。 不要提及其他移动平台（即使你的应用是跨平台的）。 最重要的是，确保应用完全与你所说的相符。 如果在说明中列出了一堆功能，则最好是清楚地知道如何使用每个功能，否则你将收到“应用程序说明中提到的功能未实现”拒绝原因。
在应用程序的元数据上投入与开发和测试一样多的精力。 应用程序确实会因元数据中的轻微违规而被拒绝，因此值得花费时间来纠正。
应用商店：不一定适合所有人
每个平台上应用商店的主要关注点在于消费者分布 – 能够接触尽可能多的客户。 但是，并非所有应用程序都面向消费者，内部和类似 Extranet 的应用程序数量正在快速增长，需要受限地分发给员工、供应商或客户。 这些应用不是“供出售”的，也不需要审批，因为开发人员会控制对封闭用户群的分发。 对此类部署的支持因平台而异。
Android 在这方面提供了最大的灵活性：可以直接从 URL 或电子邮件附件安装应用程序（只要设备的配置允许即可）。 这意味着，创建和分发内部企业应用程序或者向特定客户或供应商发布应用程序的过程非常简单。
Apple 为注册 iOS 开发人员企业计划的开发人员提供内部部署选项，该选项会绕过 App Store 审批流程，并允许公司向其员工分发内部应用。 遗憾的是，此许可证无法解决向其他封闭客户或供应商群体分发类似 Extranet 的应用的需求。 企业（和临时）部署
App Store 摘要
审核流程可能令人望而生畏，但与开发生命周期的其余流程一样，你可以通过一些规划和对细节的关注来帮助确保成功。 这一切都归结为几个简单步骤：阅读并理解必须遵守的用户界面准则，如果你要实现特定于平台的功能，请遵守规则，全面测试（然后进一步测试），最后确保应用程序元数据在提交之前正确。
针对在 Google Play 上发布应用的开发人员的最后一条建议：缺乏审批流程可能看起来会让工作变得更轻松 - 但客户的要求比审核团队更高。 请遵守这些准则，就好像你的应用可能会被拒绝一样，否则你的客户就会拒绝你的应用。