我们一定会遇到这样的情况：就只改了一行代码，只用对这个改动的地方回归下就好了，为什么上线的时候影响到了其他的业务需求了？
在解决上面的问题之前，我们先简单做两个问答题吧：
问题1：如果两个业务操作的数据载体不会有交集（包括增删查改），这两个业务在系统上会相互影响吗？
问题2：如果两个业务操作的代码写在两个完全不同的地方（代码上没有交集），这两个业务会相互影响吗？
对于数据业务型系统，我现在还没有遇到两个数据载体没有交集的业务操作会相互影响，如果大家有例子，可以分享下哦。
如果两业务代码上没有交集，那我们完全不能保证他们业务上不会互相影响了，大家可以看下下面这张图。
注：这里的数据实体，即数据的载体。
同一个数据实体，会面临不同业务需求的操作，每个业务对该数据实体的操作范围会不同，但是数据实体中数据的变更会对业务造成影响。往往这些影响，局限在本业务范围内是发现不了的，一些暴露出来的缺陷，反而会让人感觉时现时不现（因为只是部分数据被其他业务修改了），很多同学会联想到是不是并发之类的问题导致的。其实如果跳出这个业务范围，站在全局的角度，就很容易发现问题。
所以我们经常需要回归测试，我们现在有大量的回归脚本支持回归测试，但是某些缺陷是无法通过回归脚本发现的，往往需要我们通过对业务的嗅觉，进行回归点的挖掘，来实现对缺陷的预防。
下面举一个现有回归脚本无法发现的缺陷：
前提：业务一的开发早于业务二
（业务二）对某一实体进行修改操作，该改动涉及到一个（业务一）同样关心的字段。
（业务一）对该实体进行查询操作，在解析上面的字段时，由于无法解析而报错。
在单纯对业务一的持续集成脚本的维度来说，无法解析的属性，应该是要报错的，这个异常流程走的很对。
所以如果单纯从之前的回归脚本进行回归而判断这次修改是否影响到了之前的逻辑，是武断的。
同样依靠同学们对业务的熟知度，来挖掘业务二对业务一的影响。这种做法并非科学，任何一种完全依靠人脑来做决定，是会有遗漏的，是有风险的。
再举一个例子通过查代码去发掘回归点可能遗漏的例子
如何发现一段代码的影响范围，大家是不是做过去看下这段代码将会被哪些代码调用，即对应的下游代码。无疑这么做确实可以发现同一流程下的影响点。但如果不在一个流程里面呢？如果相关同学对将会影响到的业务其实并不熟悉，该怎么办？
我们就需要一张大图，一张业务逻辑大图。这张大图的组成为实体+沉淀+入口。
为什么要做这张大图，这张大图是什么样子的？
我们的系统是基于MVC模型，通俗说法就是通过V调用C去操作Ms（因为M可能很多，哈哈）。所以归根结底，变化的是M，影响的也是M。
M，即Model，它主要与数据载体交互的功能。我们将与M交互的数据载体，称为实体。
沉淀，即业务沉淀，即对应的功能点的IO与控制器的综合体，是业务的精华。
入口，就是记录入口在哪里，方便区分业务。
如果我们有了这样一张大图，同一个实体被多个业务使用到，我们可以轻松得通过实体反向抓取出对应的业务，然后通过对业务沉淀的分析，获取相应的功能影响点。
这张图，我们需要一个好的载体，这里选择MM图。下面我做了一个简单的示例：
其中用了几个标签：t 功能点标签；a 业务沉淀标签；e 实体标签；l 入口标签。
标签的好处就是在编写完成之后，可以方便得进行数据提取，进行业务分析。
MM图化有什么好处呢？
1、大容量
可以把一个系统，甚至一条业务线的业务整理到一个MM图里面。
2、树状结构，方便业务梳理
3、规范化编写
规范化编写，可以方便利用工具进行提取，也方便人工阅读和挖掘。
业务沉淀图形化，规范化，对后续的回归和业务变更会带来很多好处，也会对回归点的判断上，做出更加科学的判断。
精准回归，核心在业务层面，是对业务的充分理解和剖析，是对业务的有效管理和挖掘，但是我们可以在技术层面上为这一系列管理更加高效而实用，大家可以继续关注后续的博客哦。