移动app通知和消息展示测试项详解

使用 App 过程中，最烦的莫过于接收到各种已安装的 App 发送的各类通知，而这些通知的行为和触发的方式又各有不同，让用户感到无所适从。

测试 App 安装时是否明确申明在用户使用 App 时需要用到的权限，否则 App 在提交到操作系统官方应用商店时会被拒绝，或者在用户安装 App 的时候被拒绝。

测试 App 在用户使用过程中是否有合适的通知和消息显示，例如 GPS 、蓝牙、用户照片或短信、用户位置等资源。如果测试人员在使用 App 过程中改变权限获取本不该得到的权限时，在 iOS 上 App 会访问不到它想获得的资源，在 Android 平台上，操作系统会弹出安全性异常的提示框，并强制关闭 App 。

在此时，如何才能提高向用户申请访问权限的成功率？不妨检查一下 App 在需要用户授权时是否遵循以下的设计原则和实践：

第一点， App 向用户申请访问权限的第一次很关键

第一次申请访问权限的契机很重要，一旦用户点击了“不允许”后很难再改变用户的想法，例如 iOS 系统设置中如需改变权限需要较为繁琐的步骤。因此，不要在用户第一次打开 App 时候直接申请访问权限，过于突然，安全考虑，用户更倾向于选择“不允许”。而是先向用户讲述授权后的便利，用户有所了解后再次申请访问权限。

第二点，给用户更多机会了解 App 之后再次申请权限

在申请权限时，“ Not Now ”比“ Don't Allow ”更有效，可以等用户对 App 有更多了解后再次询问。虽然这种方***向用户询问两次，但是避免了第一次被用户直接拒绝。另外，也可在第一次申请时使用图片等形式更形象地展示授权的好处。

第三点，让用户来触发什么时候对 App 进行访问权限的授权

让用户来触发什么时候对 App 进行访问权限的授权，因为只有用户在清楚自己下一步想要做什么的时候，才会对 App 申请的访问权限作出正确的判断。但是这种方式在考量和设计方面最为复杂。

可以看出，对于用户越是友好和便利的 App 申请访问权限的方式，测试用例的设计也就越复杂，因此测试用例中需要覆盖能触发每种 App 申请访问权限的方式的测试路径。

测试 App 在后台运行时是否有合适的通知和消息显示，由于用户可以在 iOS 的通知中心中对 App 的通知方式进行单独设置，如果为 App 设置了不同通知方式，测试人员需要对这几种通知方式都进行测试，来避免出现诸如用户关闭了锁屏页面的 App 消息通知，但是却看到了 App 通知的状况。

还有两个 App测试 点需要注意：

第一点， iOS 的状态栏在通话、导航、录音、使用热点等情况下会变为双倍宽度显示，需要测试人员在使用 App 中状态栏从标准宽度变为双倍宽度，还有从双倍宽度变为标准宽度的情况进行测试。另外，根据 App 展示通知和消息时，需要思考用户可以对 App 进行什么样的操作，比如点击通知或消息，进入 App 等。

第二点， iOS 允许 App 在其图标右上角显示未读信息的计数。值得注意的是，计数显示是由 iOS 操作系统处理的，但是计数的数字却是 App 提供的。这样会出现一个问题：已经通过通知栏等方式读取了信息，但是并没有从 App 计数中减去，导致 App 图标右上角未读信息的计数显示和真实的计数不一致。

测试 App 的消息推送功能，针对不同的推送消息方式，测试人员需要为它们单独设计测试用例。

对 App 自己完成消息推送的情况，测试人员需要测试关闭 App 自身服务或 App 后台服务器时， App 是否会崩溃， App 对于新消息的处理，以及 App 消息推送的性能等。

对 App 采用推送通知框架的情况，测试人员可以让推送通知框架的提供商关注后台服务器出错的场景，但是依然需要测试在 App 接收到错误的推送通知，推送通知框架服务不可用时 App 会如何处理。

测试 App 在出错时是否有合适的通知和消息显示。在测试正常功能的消息显示之外，测试人员还需要测试在出错的场景中 App 是否给用户显示了恰当的信息。显然，给用户只显示便于技术人员定位问题的错误代码并不能解决用户的问题；给用户显示很长或者步骤很多的解决方法或提示也不能解决用户的问题；给用户显示的提示信息里打印出 log 就更不可取了。在信息过剩的时代，用户不会一直停留在 App 中关注消息的变化，所以我们需要通过消息的推送和展示，增加用户对于 App 的粘性。