一、背景
公司新产品体验，发现不少交互、UI、功能设计上的小问题。于是花了点时间随意挑了几个功能深入的玩了一下，顺手提了BUG。接口层，看了一下接口文档，简单测了一下接口，BUG其实还挺严重的，后面详细分析，为了顾及服务器后台大佬（架构师）的面子，费时费力在APP测试短信验证码服务器与APP整体处理逻辑，提交BUG如下：
BUG：
解决结果：
哎！TX背景的架构师的解决结果，让我稍许失望。
二、BUG分析
1、先说结论：重点是可以短时间（1、2分钟）之内把短信平台的预充值费用全部用完
1).单手机号码可发送短信：40条+
2).可多手机号，短时间操作无限制发送短信验证码
3).对用户影响：可做短信炸弹恶意骚扰用户
4).对公司影响：短时间耗尽充值平台费用，导致注册、登录功能不可用；大量垃圾短信影响公司形象
2、第一个问题：单号码没有限制条数
a、06.12号当天实测，可以30来条，每15条换了一个通知号码而已
b、06.14号当天实测，确实超过15条是提示超出频率限制。（内心OS：我有当时短信截图，并有12号的其中部分日志在手，日志在手...）
测试想要不背锅，哥就大发慈悲教一条：不管大小BUG均记录在案，严重问题尽可能全的保留界面截图、日志文件等直接证据。
补充：一般第三方短信平台已有限制每个号码每天发送频率与条数：一般10条左右/天，1分钟内不超过2条
3、第二个问题：同设备、同IP、多号码请求无限制
a、文档设计，我们直接看业务层接口设计就能发现致命的缺陷！
接口文档
模拟请求
b、设计缺陷简单分析
1)、此接口为直接请求，基本没有其它前置接口处理（除了接入层路由）。
协议说明：APP请求走socket协议到接入层，再由其将请求内容改成