明确需求
1.什么情况下触发推送。比如：淘宝物流通知，快递已签收
2.推送给正确的用户+设备。比如：快递已签收应该推送给相应的购买人
3.设备端正确展示推送的结果，以及交互情况【iOS+Android】
4.长连接断开的情况，重连，推送消息正常推送
接入第三方推送平台
了解推送的一般流程
推送是一种服务器主动push消息到设备端的行为，因此依赖于设备端和服务器的长连接。
iOS推送具体流程：
- 设备和推送服务器建立长连接
- 设备会根据某些规则生成或从推送服务器获取到一个Device Token，推送服务器可以根据Device Token定位到具体的设备
- 设备会上报Device Token到应用服务器（由应用自己完成）
- 应用服务器根据需要调用推送的服务端接口发起推送
- 推送服务器收到推送请求，根据请求中的Device Token定位到具体的设备，下发推送通知
- 设备收到推送消息，可以进行通知栏弹窗或者其他行为
推送方式梳理
-
客户端不断的查询服务器，检索新内容，也就是所谓的pull 或者轮询方式
-
客户端和服务器之间维持一个TCP/IP长连接，服务器向客户端push【苹果的推送系统和googleC2DM推送系统】
-
服务器又新内容时，发送一条类似短信的信令给客户端，客户端收到后从服务器中下载新内容，也就是SMS的推送方式
分析细节
1.长连接的建立原理？可以分为哪些情况。或者说安卓推送与iOS推送的区别
前提：推送的前提是需要与推送服务器建立长连接，应用服务器将推送的消息推送到推送服务器，推送服务器将其推送到相应的客户端
iOS的长连接是系统来维护的，也就是应用服务器将推送消息推送至苹果服务器，再由苹果服务器通过系统的长连接，推送至相应的客户端，iOS系统的所有APP的长连接都是统一管理的。所以
- 在手机终端始终只要维护一个长连接即可，而且由于这个长链接是系统级别的不会出现被杀死而无法推送的情况。
- 省电，不会出现每个应用都各自维护一个自己的长连接。
- 安全，只有在苹果注册的开发者才能够进行推送
- Android的长连接实际上也有类似的推送构架：C2DM,云端推送功能，但国内对Google的限制，导致无法使用。Android的开发者不得不自己去维护一个长链接，于是每个应用如果都24小时在线，那么都得各自维护一个长连接，这种电量和流量的消耗是可想而知的。虽然国内也出现了各种推送平台，但是都无法达到只维护一个长连接这种消耗的级别。
2.Device Token是怎么生成的？何时会发生变化？
device token是APNs用于区分识别每个iOS设备和设备上不同app的一个标识符，还可以用于APNs通过它将推送消息路由到指定设备上。
device token = device id + bundle id：其中device id用于识别iOS设备， bundle id用于识别iOS设备上的app。device token我们是通过设备和APNs服务器建立的长连接后，通过注册推送服务，由APNs生成后加密反馈给app的。
所以Device Token何时会发生变化呢？- 重装相同版本的app，device token 会发生变化，不能影响正常的消息推送。
- device token会在更新系统、擦除设置重置【手机恢复出厂配置】后变化。
- device token会在一定时间后过期。
- 注意：开发时，我们需要在每次app重新启动时，请求最新的device token，并同步给自己的服务器，避免device token失效造成推送失败。
3.Device Token不变【也就是设备与app不变】，切换登陆用户验证–服务器必须自己管理DeviceToken-用户账号的映射关系
1.相同设备可以切换用户登录，且推送消息正常
2.相同用户可以在不同设备上登陆，且推送消息正常
3.退出登陆APP，不能接收推送通知
4.杀死APP进程，不能接收推送通知【具体要看连接的状态】
5.当前登陆用户失效token
4.不同的操作系统版本对推送的影响？
5.推送app版本兼容的影响
6.不同设备上的推送兼容
7.系统配置的推送总开关、设备的通知开关、APP的通知开关等验证
8.点击推送消息的跳转：
深层次的功能页面，跳转
1.当前APP所在不同页面，跳转【不同类型的页面验证，复杂功能的情况下格外要注意】
2.跳转之后的功能逻辑验证、交互验证（比如：返回按钮）
推送服务的测试
推送-性能相关的测试
参考文章：https://blog.csdn.net/u013378580/article/details/52004675