我们一定会遇到这样的情况：就只改了一行代码，只用对这个改动的地方回归下就好了，为什么上线的时候影响到了其他的业务需求了？

　　在解决上面的问题之前，我们先简单做两个问答题吧：

　　问题1：如果两个业务操作的数据载体不会有交集（包括增删查改），这两个业务在系统上会相互影响吗？

　　问题2：如果两个业务操作的代码写在两个完全不同的地方（代码上没有交集），这两个业务会相互影响吗？

　　对于数据业务型系统，我现在还没有遇到两个数据载体没有交集的业务操作会相互影响，如果大家有例子，可以分享下哦。

　　如果两业务代码上没有交集，那我们完全不能保证他们业务上不会互相影响了，大家可以看下下面这张图。

　　注：这里的数据实体，即数据的载体。

　　同一个数据实体，会面临不同业务需求的操作，每个业务对该数据实体的操作范围会不同，但是数据实体中数据的变更会对业务造成影响。往往这些影响，局限在本业务范围内是发现不了的，一些暴露出来的缺陷，反而会让人感觉时现时不现（因为只是部分数据被其他业务修改了），很多同学会联想到是不是并发之类的问题导致的。其实如果跳出这个业务范围，站在全局的角度，就很容易发现问题。

　　所以我们经常需要回归测试，我们现在有大量的回归脚本支持回归测试，但是某些缺陷是无法通过回归脚本发现的，往往需要我们通过对业务的嗅觉，进行回归点的挖掘，来实现对缺陷的预防。

　　下面举一个现有回归脚本无法发现的缺陷：

　　前提：业务一的开发早于业务二

　　（业务二）对某一实体进行修改操作，该改动涉及到一个（业务一）同样关心的字段。

　　（业务一）对该实体进行查询操作，在解析上面的字段时，由于无法解析而报错。

　　在单纯对业务一的持续集成脚本的维度来说，无法解析的属性，应该是要报错的，这个异常流程走的很对。

　　所以如果单纯从之前的回归脚本进行回归而判断这次修改是否影响到了之前的逻辑，是武断的。

　　同样依靠同学们对业务的熟知度，来挖掘业务二对业务一的影响。这种做法并非科学，任何一种完全依靠人脑来做决定，是会有遗漏的，是有风险的。