我觉得流程应该是发消息——消息到服务器上——服务器推送——客户端接收——客户端返回确认——服务器收到
如果说没收到的话，服务器应该收不到客户端的确认信息，如果是网络原因导致客户端返回确认丢包了，TCP 协议应该会保证重发，而且现在微信有的时候消息也会收到两边。。。。可能这个问题没解决吧。

打电话问

我觉得这题好像不是在考你的测试场景设计能力，而是在考察你是否能够、是否有意愿为了测试而去探究设计实现的模式，然后给出对应的方法
如果已读回执在消息服务器上有日志记录，那么 less msg.log | grep 'WTF' 就结了啊，如果是其他的实现就见招拆招吧

服务端 ack 了。还得看客户端吧，再看下客户端的埋点。他这里说 500 个应该是有性能的问题需要考虑。

消息一般是推送机制，一般推送不是可靠连接。
除非客户端和服务端有定时同步机制或连接同步机制。
你问怎么测试，大部分推送都是 SDK，比如云信（有一堆成功率和手机适配的坑）我个人是不知道里面具体怎么实现的。
测试要测试只能说沟通成本会很高，很难。

客户发送 - 服务器 接收- 服务器标记 需要传输的对象 - 数据批量传输，将复杂的业务进行分割后就能针对单个功能进行功能测试

嘛，我说假设有【已读回执】，像 email 那种设计
我觉得应该是基于设计模式去回答，而不是自己去想怎么设计，那样要求是在太高了，8 成 8 的码农也不具备把 “微信” 设计的像微信现在这样可靠的实力啊

那肯定，还是得看架构怎么设计，链路怎么设计

微信开发团队据说内部其他部门过去需要 6 轮左右的面试。。。难度不说 Nightmare ，也是 Hard 级别的。。。
码农也分很多层的。。。
前面在说消息推送。貌似跑偏了。。。
微信的消息推送是有后台进程保活的，通过进程活着，就接收消息，这个还不是那种通知推送消息。。。
看已读，如果我自己设计，简单点的做到人这层，打开会话就认为全部已读。
复杂点做到消息层，直接跳到最后一条，开始回溯消息，屏幕内的都算已读，然后打包发个消息把消息号给服务器。
我觉得微信就没有消息层的已读展示，应该就是人这层的。（不排除自己内部有这种逻辑，只是我们看不到。。）
术业有专攻，我不是做 IM 这种通讯的，只是个人的感觉，供参考。
测试查看率根据开发设计去跟踪服务端消息就可以了。

嗯嗯，谢谢回复，我记得当时我也只说了查看此功能对应模块下的日志看有没有标记，但是面试官好像更注重的是 499 人全部收到，还是 399 人收到，有些人没收到，没收到的原因可能是什么，如何确定原因，没接触过这类产品不晓得一般开发是怎么设计的，当时没答上来。

ack 本地存储 时间戳 回执

我感觉这题本来就不是需要来验证 499 人是否收到
而是把 499 人面对这条信息的所有可能写出来，随便想想
多平台，跨平台，前台，后台，安全设置，隐私设置，弱网等等情况去正交组合

那又不告诉实现逻辑，又不告诉侧重点，这种问题怎么回答？

如果每送一条信息都去查一下日志看看有没有发送成功，是不是不现实
这个题目感觉上考察的还是如果在消息没有发送成功或者接收成功时候，怎么能够快速找到出现未成功接收到的人，并能再次把消息重发

个人主观评论下。面试官想问的其实是一个消息广播的测试问题，这实际上是需要使用自动化工具去验证稳定性的问题。生产者产生相当规模的消息，消费者是否都能正确消费（没有遗漏、没有重复接收）。工具的实现就不用说了吧