移动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的粘性。