不知道大家是否听过一个词，叫全链路压测。也就是直接对整个功能的链路进行压力测试，压出最弱的那个环节 好进行优化和加固。
小刘是一家大型公司的测试开发，他最近要负责一个定时监控线上登陆接口的功能，实际上就是每个5分钟跑一遍本地的几条requests脚本。
可是他身为资深测开，这么一个小脚本直接写个for循环 来轮询实在是low，所以他打算做一套很大的东西。
1.首先是接口的结构， 他准备从接口文档中时时提取最新的结构，并监控上线日志，对上线的接口，进行实时更改监控脚本。
2.接口的数据，他不满足写死，所以一部分从压测平台的日志中进行提取线上真实数据，而另一部分从公司数据库调用。
3.执行间隔，他使用公司的jenkins，在上面设置好了奴隶机进行控制执行间隔时间。
4.脚本代码，他使用jenkins的钩子自动获取gitllab的最新代码，自动部署。
5.底层驱动，他使用了接口测试平台的request底层微服务。
6.验签算法，他懒得自己新写一个，所以直接调用公司中台的验签接口。
7.手动触发，每日上线通过监控邮件，一旦收到上线通知邮件，便立即触发执行一次。
8.报告结果，自动生成的报告结果会发送给相关责任人，所以他去动态从公司的用户数据库和组织结构关系中获取邮箱地址。
9.报警系统，包括邮件报警，电话报警，短信报警，他全部利用公司中台提供的接口，直接调用，简单方便。
10.数据量化，他把所有的请求日志都存放了起来，并且又做了一个小功能，定期统计成功率等数据。
整个组织架构设计就是这样了，说干就干，在他辛辛苦苦花费了好几天的时间终于搞定了这套接口监控功能后，开心极了。但是之后的稳定性却成了他的心腹之患，他收到的很多报警，和反馈，去查，发现都是因为种种网络/支撑服务等问题 导致的，今天是中台升级，明天是服务维护，后天是文档地址更换，大后天是数据库权限，大大后天是压测平台token过期...... 。
他到底也不明白 ，错在哪里，整个架构即高端又实用，无懈可击。但是为什么会造成这个局面呢？其实很简单，他整个架构太复杂了，模块太多，支撑服务太多，调用的太多了。
牵一发动全身的道理，他没有履行好高内聚/低耦合的思想。
后来他关注了公众号：测试开发干货。他突然想到，他一开始就不该设计这么复杂，但是既来之则安之，所以他准备再开发一个专门的维护机器人，用来定时检测他的所有支撑服务的稳定性.......
很多时候 是和 效率 成反比的。领导所说的既追求效率 又 追求质量，如果成本固定的话，会很难实现。所以方法论存在的目的，就是让我们不要盲目的去做浪费成本，反而降低稳定性的事。
标签：方法论,测试,压测,报警,稳定性,接口,调用,监控 来源： https://blog.51cto.com/u_15282986/2970968
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。