与外部系统交互的哪些坑？

瑜伽老师经常说：

一个人心情不好时，完全拉伸完了就会开心一些，这是因为他的胸腔被拉开了，要忍耐现在的痛，才能更好地享受后面的爽。

我觉得我现在就特别适合来一个完全拉伸，最好是能把胸腔像撕裂一般地拉开，这样心中的那团吞之不下，吐之不出的郁闷之气才能完全被释放出来。

言归正传，说说第一件让人郁闷的事情:

今天我所负责的系统出现了一个重大bug，预估导致的直接损失达到一百多万，对于金融系统来说，一般出现不可逆的问题，那直接就是金钱上的损失，对老板来说这又是最不可容忍的事情，这基本可以算得上一个事故了。

虽然主要责任不在我，但在自己负责的系统上出现这样的事故，也是相当难受的，每当事故出现之后，想和总结都会觉得这样的事故不应该出现，当时只要多想一点，多谨慎一点就有避免掉，但坑总是踩不完的，比如像这次。

这次事故主要是因为外部系统修改了费率编号未知会到我们系统人员，从而没有在线上添加费率编号，导致资产到期之后未按照既定规则刷新逾期利息，出现用户少还钱的现象。

分析这次事故出现的原因：

（1）外部系统在设计修改方案时，未完全考虑到与之相关的其它系统，然后就自故自地大刀阔虎地自己悄咪咪的修改了，然后上线了，然后就引起了外部系统出现不兼容或历史数据等问题。细想一下这种问题无论是哪一个系统，只要与外部系统交互得多了，都非常有可能或者必定会出现。

如何避免出现这样的情况？

a.在项目修改之前先设计方案，从代码层面上，梳理出修改点与外部系统交互的相关接口；从业务层面上，梳理出与外部系统交互的业务场景、历史数据兼容性、异常情况处理（比如外部系统挂了、查询的数据不存在。。。）等测试点。

b.测试过程中根据列出的来测试点和接口模拟交互测试，一旦出现有与外部系统的交互，在测试过程中都需要与外部系统联测。

c.上线之前，一定要知会相关外部系统，本次上线的项目修改点是什么？可能引起的问题？确定外部系统是否有代码或配置上线，一定要知会到必要的相关责任人，重点！！！

d.上线之后，通知相关外部系统我方已上线，看是否有必要灰度一笔数据，或直接观察数据即可。

一般来说修改大的功能，都会按上面的流程来走，反而是一些小的改动，经常容易出问题，比如就添加一个字段，开发分析了觉得不会与外部系统交互，测试赛程中也觉得没有必要联测，但上线之后就出现问题了，这只能说是开发业务能力不足和测试不够谨慎引起的。

（2）系统健壮性不够，在与外部系统交互时，就应该要考虑到交互系统可以引起的一些问题，例如系统不够稳定、返回的参数有误、错误码不对，甚至还有可能抽风等，那我们在设计这些与外部系统交互的过程中，需要考虑到这些并合理处理，必要时监控报错通知人工来处理。

今天这个问题若在这一部做好了，虽然不能解决问题，但能提醒并及早处理，可以将损失降到最低。

（3）线上数据的合理监控，这个方法只能起到辅助作用，在项目上线之后，就需要考虑哪些数据需要时时监控，其实我们有很多监控，但就是针对这一个值的没有，这也算是一个漏洞。

同时问题出现这么久了，每天都在看线上数据，竟然也没有发现数据的值有问题，只能说对线上数据敏感性还是不够。

培养对数据的敏感性也是非常重要的，这需要测试人员对业务数据熟悉，如何培养这种熟悉？那就是每次测试时尽量使用与线上数据相同的数据，看得多了，一旦出现不同的、异常的数据能立马发现，这也是今天刚好讨论到的一个点。

今天这篇文档就分享这些感悟，虽然有点马后炮，但出了事故总得在其中得到一些教训和总结出一些经验才行，下一篇文章打算分析一下自己最近的状态，只有剖析清楚自己，才能知道接下来要怎么做对自己才是最好的。

资深Tester

公众号ID：zishentester

QQ号：524612202

关注