求微信/短信/邮件通知的优化测试方法，请各位大佬指点
现在参加的项目产品中通知模块有下边的场景：
有N不同类别的对象，比如说账户、资源等（N大于10）
每个对象都设置了多种通知（账户临期预警通知、到期通知、余额不足通知、欠费等等通知；资源的CPU不足、内存不足等等通知）
系统定时检测这些对象是否触发了不同类别的通知是否触发了阈值，触发了之后就发出通知。其中定时还针对不同的对象的不同检测类别，设置了每个小时/天去定时检测。
系统有多种角色，如果通知触发了，给各种角色发相应的微信/短信/邮件通知。
（其中上述角色是否接收通知、接收邮件/微信/短信通知、哪些对象的哪些通知都是可以配置的）
针对上述这种通知场景，我们一直手工测试，绑定微信/短信/邮箱进行各种场景的手工测试。
但是测试起来太麻烦。首先我们没有那么多手机号和微信，其次我们等待一个通知可能需要1整体的时间，效率太低
期望各位大佬提一下建议，优化一下我们的测试策略
你要分开来测试，不要直接用系统级别的测试方法。
比如你要先测试下，每次变动是否会把推动消息的请求发到你的消息推送服务器，这部分不用验证短信有没有收到。只需要通过mock proxy或者消息推送的服务器的状态日期去检查有没有正确的触发请求。
第二步才是单独去测试消息推送服务器是不是真的可以推送微信和短信。要学会在中间加入mock或者代理去解耦整个系统的依赖。
google有篇文章介绍了这个
https://testing.googleblog.com/
原本的架构可能是这样的，比如中间的那个就是你们的消息推送服务器。前面的是你们的业务逻辑。
如果拦截消息推送的服务器，可以用这个方法， hook或者前面加代理都是可以的。
如果还想测试消息推送服务器后面的发送行为，用fake或者mock也是可以的。搞个假的发送短信的接口实现，别真的去发短信邮件，不然就太麻烦了。
最后理想的情况是你可以轻松控制每个过程。我们给一些大公司的客户做的方案也是这个样子的。
好的，谢谢思寒老师的回复，我尝试着解耦一下去测试