影响稳定性的元素有很多，比如架构的复杂度，空间利用度，整个功能的链条长度。
本篇主要说的一个情况就是链路长度。
不知道大家是否听过一个词，叫全链路压测。也就是直接对整个功能的链路进行压力测试，压出最弱的那个环节 好进行优化和加固。
那么在我们测试开发的工作中，当开发一个功能时，如果实现此功能的链路过长，支撑服务越多，那么其稳定性会大大降低。众所周知，车链子质量决定于最弱那节。
在一个功能的全链路中，但凡一个环节出现错误，都会导致整个失败。
小刘是一家大型公司的测试开发，他最近要负责一个定时监控线上登陆接口的功能，实际上就是每个5分钟跑一遍本地的几条requests脚本。 可是他身为资深测开，这么一个小脚本直接写个for循环 来轮询实在是low，所以他打算做一套很大的东西。 1.首先是接口的结构， 他准备从接口文档中时时提取最新的结构，并监控上线日志，对上线的接口，进行实时更改监控脚本。 2.接口的数据，他不满足写死，所以一部分从压测平台的日志中进行提取线上真实数据，而另一部分从公司数据库调用。 3.执行间隔，他使用公司的jenkins，在上面设置好了奴隶机进行控制执行间隔时间。 4.脚本代码，他使用jenkins的钩子自动获取gitllab的最新代码，自动部署。 5.底层驱动，他使用了接口测试平台的request底层微服务。 6.验签算法，他懒得自己新写一个，所以直接调用公司中台的验签接口。 7.手动触发，每日上线通过监控邮件，一旦收到上线通知邮件，便立即触发执行一次。 8.报告结果，自动生成的报告结果会发送给相关责任人，所以他去动态从公司的用户数据库和组织结构关系中获取邮箱地址。 9.报警系统，包括邮件报警，电话报警，短信报警，他全部利用公司中台提供的接口，直接调用，简单方便。 10.数据量化，他把所有的请求日志都存放了起来，并且又做了一个小功能，定期统计成功率等数据。 整个组织架构设计就是这样了，说干就干，在他辛辛苦苦花费了好几天的时间终于搞定了这套接口监控功能后，开心极了。但是之后的稳定性却成了他的心腹之患，他收到的很多报警，和反馈，去查，发现都是因为种种网络/支撑服务等问题 导致的，今天是中台升级，明天是服务维护，后天是文档地址更换，大后天是数据库权限，大大后天是压测平台token过期...... 。 他到底也不明白 ，错在哪里，整个架构即高端又实用，无懈可击。但是为什么会造成这个局面呢？其实很简单，他整个架构太复杂了，模块太多，支撑服务太多，调用的太多了。 牵一发动全身的道理，他没有履行好高内聚/低耦合的思想。 后来他关注了公众号：测试开发干货。他突然想到，他一开始就不该设计这么复杂，但是既来之则安之，所以他准备再开发一个专门的维护机器人，用来定时检测他的所有支撑服务的稳定性.......
除上述以外：
稳定性， 也算是测开工具的质量的一部分。
很多时候 是和 效率 成反比的。领导所说的既追求效率 又 追求质量，如果成本固定的话，会很难实现。所以方法论存在的目的，就是让我们不要盲目的去做浪费成本，反而降低稳定性的事。
