小推送，大烦恼

“又是什么鬼？是不是有毒？你不是说没问题吗？”办公室里一次又一次传出我鬼畜的三连问。

刚进公司没多久的我，对新环境充满了干劲和热情。接手了第一个项目某知名电商“物流APP”，怀着满腔热血想把项目迅速高效的完成。然而没多久，就出现了上面那一幕，时而传来鬼畜连问的我越来越丧。不过还好技术大佬们很给力，项目最终顺利结束了。

成功的革命背后自然少不了让我心痛的血泪史。本篇就该项目的一个小功能——消息推送——遇到的问题给大家踩个坑，如果觉得不错的话，记得给我加鸡腿哦！

项目中消息推送部分需要实现的功能一句话就可总结：驾驶员收到派单消息，点击派单消息，跳转至消息详情页面。看起来是不是so easy？容易确实容易，但是坑也是确确实实存在的。

情景一：“APP一点消息就闪退，什么鬼啊？是不是有毒啊”。没错，就是本人又去找开发了。在我测试的时候发现Android客户端收到了推送消息后，点开消息进入APP必闪退，iOS正常。虽然我自己也用着安卓机，此刻的我只希望这世界上只剩下苹果机。

把问题反馈给开发后，开发抱着怀疑的态度， 嘟嚷着“我调试时都是ok的，是不是你操作有问题啊“，亲眼看到BUG后，才开始抓耳挠腮的找原因，可见程序猿的特征不是流言。

最终发现的原因让Android开发很是忿忿不平。测试时是服务端发送的消息，消息类型是字符串，不是约定的标准json格式，iOS系统自带两种类型的转换（天生优势），而Android前端不具备，导致推送出错，一点就闪退。拼爹拼娃的时代，万万没想到还要拼系统，也是很心疼受到暴击的Android开发了。没办法，只能后天努力，增强代码的健壮性才是唯一出路。

情景二：嗡叮嗡叮……叮~嗡叮嗡叮……叮~3个测试机在桌上叫个不停，要是在平时，心情好的时候，我可能会觉得这是在演奏交响曲吧！然而发生在推送了一条消息之后，我希望是我幻听了。查看了一下，每台手机各收到五条一毛一样的通知，没有买一送五的惊喜，相反，有一种又要加班的心肌梗塞的感觉。

虽然内心是奔溃的，但是作为一个专业的测试，怎么可以因为自己的情绪影响到我们的技术大佬呢。保持微笑，和开发人员反馈了问题。开发人员debug发现就只有一条消息(排除了服务器重复发送消息的可能)。又进行了一段紧张刺激的排查工作之后，问题定位在消息显示代码，查资料发现notification的notify方法参数id不能为固定值，后来改为随机数，就ok了。

翻过了几座大山，终于尘埃落定，部署到了UAT。没过几天好日子，客户方验收人员就反馈收不到消息推送通知。

情景三：生产环境收不到消息通知。Emmm，orz，是不是有什么没测试出来的隐藏bug被发现了，自我怀疑的同时开始了测试。在测试环境进行了多次测试，都是正常的。那么问题来了，用的是同样的代码，为何会出现这样的情况呢？有问题不可怕，有问题却找不到才是最可怕的。

我们做了很多假设：手机版本原因、网络原因……结果发现都不是。最终开发同学灵光一现找出了问题，原来是UAT环境的机器未申请对个推服务器的访问，可以说也是一个很奇葩的部署问题了。

至此，此次项目中关于消息推送的血泪史就结束了。接下来给大家讲一讲比较出名的ofo小黄车的推送BUG和“何文辉“事件。

在网民看来，这是APP出BUG了，在我们看来，里面的文字内容却异常亲切。不要以为我们测试的工作就很无趣哦！在测试时，我们也自己找乐趣，开森的工作。你看到的36氪”何文辉“就是逗比的测试们互相玩闹的话语。如果是在测试环境，那便是同事之间的玩笑逗乐。然而推送到了生产环境，这对于开发人员和测试人员来说，就是一个超级超级严重的失误了。

弄错生产环境和测试环境，让使用中的客户收到这些逗乐的测试消息，对用户形成打扰，客户的体验感会变得极差，丧失用户信任。所以测试小伙伴们在测试消息推送的时候不能太马虎哦。

总结感悟

关于消息推送部分，给大家提供个测试参考思路

1、注意推送的环境：不同的测试/生产环境，不同的账号，不同的设备是否按照设定收到或没有收到推送。

2、推送的标题和内容：内容是否展示正确（推送过程中，会出现推送的消息内容变为乱码的情况）

3、推送条数的检查：（服务器推送了一条，收到了多条通知。）

4、推送权限的检查：没有开启消息通知是否会收到？后续打开了消息推送能不能补到一份？如果设置了长驻可不可以待在通知栏？

5、点击了推送能不能跳转到app特定页面；

6、如果app开着，收到了推送是如何表现的；

7、推送时间的检查：服务端设置了定时发送，有没有及时收到？