背景

我所在的公司是一家传统互联网+教育公司，推送业务是从去年开始的，前后也经历了多次迭代，没有大牛，也没有架构师来统筹，一路踩坑，一路填坑。我们经历了大晚上给用户一直重复推送的严重事故，也有上线后用户收不到推送的尴尬，今天就从一个测试的角度来聊聊推送通知，因为鄙人只负责IOS端的业务，所举的例子多以IOS为主。

推送架构

服务器后端——第三方推送SDK——APP，画了一个简易的流程图如下：

大意就是APP启动后，去第三方请求注册（目前实现安卓用的是信鸽，IOS用的是极光），第三方返回注册id（Device token）即设备别名给APP，APP将用户id和Device token提交到服务器，服务器将其存储到数据库，发推送时只要将要发送的用户或设备信息和待发的数据参数发送给第三方便可实现推送。

注册

先来说说第一步注册，APP向第三方请求注册，什么时候请求，登录？APP启动？注册失败后该怎么处理，是否有重试机制，重试机制重试多少次呢，是否会有死循环？

关于Devicetoken，IOS的官方文档是这么描述的：

If the user restores backup data to a new device or computer, or reinstalls the operating system, the device token changes

An application should register every time it launches and give its provider the current token

大致是说，当进行备份恢复、或恢复出厂设置之类的操作时，Device token会发生改变，建议 APP 在每次启动时都获取Device token，有博客上说删除手机上的 APP 之后，再次下载安装，Device token会改变，我自己试了一下，IOS7卸载重装Device token不会改变，IOS10卸载重装后Device token发生了改变，后来我在这篇博客上找到了答案，同一设备上APP的Device token确实会发生改变，只是旧的Device token是无效的。即使这样，仍需要将最新的Device token传递个服务器，这篇博客上也提供了解决方案。

通常，一个用户是可以绑定多个设备即Device token，这也给用户多终端同时登录推送通知提供了可能。如果一个账号在多台设备登录，指定别名下发通知，理论上多台设备都可以收到推送。而用户退出登录后，怎么确保不再收到推送，需要考虑在退出登录去注销绑定。如果是跳过退出登录这一步，对应的绑定关系仍在，比如说卸载后再重装，如何去解除账号与设备绑定就需要重新考虑了。同一设备上设备别名通常情况下都不会改变，意味着一台设备可能绑定多个别名，就可能存在该设备已经登录另一个账号，但仍然可以收到推送，所以最保险的方式还是在退出登录时，解除账号与设备的绑定。

所以在测试之前弄清注册的机制和服务端如何去存储用户和设备的绑定关系，尤为重要。

关于通知设备选择

通过极光给出的API文档，可以很清晰的看到设备的选择有多种方式：

指定所有人推——只要告诉第三方推送服务器指定所有人

指定账号推——告诉第三方需要发送用户的ID，可以是1个用户，也可以是批量用户

指定设备别名推——告诉第三方设备的别名，可以是1个，也可以是多个

指定标签推——即具有同一属性的用户放在一个标签下，比方说省份，年级等。创建推送的时候只要将标签发给第三方推送，就可以实现标签下绑定的设备都可以收到推送。

毫无疑问，指定所有人推，肯定是效率最高的，只要告诉第三方一个指令，就可以坐等通知了，但实际的业务场景往往比这复杂的多。

假设有这么一个场景，我要对报名一场直播的10000个用户定时发推送通知，首先在用户报名后，需要获取报名用户的账号和绑定的Device token，存储在数据库。接下来有两种方式可以选择，一、用户报名后，就获取用户的userid和Device token，然后写到第三方推送服务器，定时发送；二、在一个时间段比如说直播开始前1个小时去往第三方推送服务器写入useid或者Device token。在userid还是Device token的选择上，肯定是userid更为合理，可以避免报名后更换设备这类问题。如果是第一种方式，如此高频率的调用写入接口，即使第三方没有问题，自己的服务器性能是否会有问题。假设是第二种方式，怎么来保证在规定时间能把全部数据写入到第三方，对于过了时间段的报名用户又该怎么处理这是个问题。对于出现调用接口失败，该怎么处理，会不会影响后面的写入，同样值得推敲。

当然，有第三种方式，也就是后面提到的指定标签的方式，也是目前我们使用的方式。

标签推送

标签推送可能是仅次于指定所有人的推送方式了。指定一个标签或者多个标签取并集或交集，前提是不要把or或者and写反了。只要告诉第三方推送需要发送的标签，就可以对一批用户发通知，是不是感觉很easy。标签的创建既可以是APP内置的SDK来实现，也可以通过后台调用第三方推送提供的API来实现，目前公司有一部分标签通过APP创建，一部分标签通过后台调用API来创建。第三方对于标签的创建都存在一些限制，了解这些限制方便我们更清楚可能潜在的问题，这里可以看一下极光更新标签的API文档说明

为一个标签添加或者删除设备。

POST /v3/tags/{tag_value}

Example Request

Request Header

POST /v3/tags/{tag_value}

Authorization: Basic (base64 auth string)

Accept: application/json

Request Body

{

"registration_ids":{

"add": [

"registration_id1",

"registration_id2"

],

"remove": [

"registration_id3",

"registration_id4"

]

}

}

Request Params

action操作类型，有两个可选："add"，"remove"，标识本次请求是"添加"还是"删除"。

registration_ids 需要添加/删除的设备registration_id。

add/remove最多各支持1000个；

极光最多创建1000个标签，1次请求则最多支持1000个绑定和删除，换到信鸽则是最多创建10000个标签，1次请求则最多支持20个绑定和删除。这里有三个问题：1、标签绑定 如果达到上限该怎么处理；2、绑定标签是否会有性能问题，同时有大批量的标签需要绑定，是否会出现排队问题；3、标签绑定失败，怎么解决？

标签更新

标签选择客户端来绑定还是服务端来绑定？选择在什么时候去更新标签，如果时客户端，在启动or登录？当然标签时客户端来实现还是后台来实现，有些问题是不一样的，所以一开始，就应该明确标签的是实现方式。

另外用户信息发生变化，是否能及时去更新？打标签采用覆盖的方式还是增量的方式？之前我们就出现极光的SDK采用覆盖的方式来绑定标签，导致APP绑定标签后，服务端绑定标签全部被覆盖掉。用户的属性可能发生变化，是否能够及时去更新，比如说版本号升级，用户省份切换，新的标签需要覆盖旧的标签，需要解绑再重新绑定。

标签与设备Device token绑定，但我们希望收取到通知的使我们的用户，如果用户切换设备，怎么去更新标签的绑定，以及怎么去解除旧的设备与标签的绑定。假设在退出登录去解除设备与标签的绑定，怎么解除，客户端来解除还是服务端来解除？重新登录后怎么去保证标签能够重新绑定上？即使退出能够解决问题，卸载呢？退出登录碰上网络断开呢，是不是很疯狂？

APP要做什么

前面说了那么多，都是在说怎么将通知发给正确的用户，跳过这一步。假设对的人收到对的推送，是不是就万事大吉了呢？

如何保证不同的操作系统以及各种版本能够正确展示通知，包括旧到IOS7，新到IOS11，安卓亦是。在IOS10以前，如果在APP界面是收不到通知横幅的，但是在IOS10以后，又发生了改变，即使正在操作APP一样可以收到通知横幅。IOS8APP界面如果没做判断，会自动打开通知消息，在字符串转数值类型，IOS8带有符号会导致过期时间变成负数。虽然处于兼容性考虑确实会影响代码的进步，但是用户是上帝啊。

APP未启动如何收到通知，IOS通过APNs进行分发不会有此类问题，那么安卓呢？未启动点击通知能成功吊起APP进程吗，点击横幅的时候怎么来确认我是否登录，我是否有权限来访问这条通知呢，假设用到了缓存，进入通知消息后，缓存是否及时去清除。横幅过期了怎么办，等到你过期我再点，你能识别出来么。

关于IOS的角标怎么处理，该死的产品经理就要求角标得和APP里面的未读数量对应，首先，不管是PUSH通知还是PULL消息（由第三方推送给用户的叫PUSH，APP向服务端请求的消息列表叫PULL）都需要标记已读，在不同的场景下home到桌面或者杀死进程，角标的数量得能对应上。

最后说句感性的话

在我刚进入这个行业的时候，别人告诉我，软件测试就是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。神他妈预期预期结果，哪有那么多预期结果，找出已知的问题，分析潜在的风险，凡事多问问这能行么，要不成咋办啊，呵呵。