我們一定會遇到這樣的情況：就只改了一行代碼，只用對這個改動的地方回歸下就好了，為什么上線的時候影響到了其他的業務需求了？
在解決上面的問題之前，我們先簡單做兩個問答題吧：
問題1：如果兩個業務操作的數據載體不會有交集（包括增刪查改），這兩個業務在系統上會相互影響嗎？
問題2：如果兩個業務操作的代碼寫在兩個完全不同的地方（代碼上沒有交集），這兩個業務會相互影響嗎？
對于數據業務型系統，我現在還沒有遇到兩個數據載體沒有交集的業務操作會相互影響，如果大家有例子，可以分享下哦。
如果兩業務代碼上沒有交集，那我們完全不能保證他們業務上不會互相影響了，大家可以看下下面這張圖。
注：這里的數據實體，即數據的載體。
同一個數據實體，會面臨不同業務需求的操作，每個業務對該數據實體的操作范圍會不同，但是數據實體中數據的變更會對業務造成影響。往往這些影響，局限在本業務范圍內是發現不了的，一些暴露出來的缺陷，反而會讓人感覺時現時不現（因為只是部分數據被其他業務修改了），很多同學會聯想到是不是并發之類的問題導致的。其實如果跳出這個業務范圍，站在全局的角度，就很容易發現問題。
所以我們經常需要回歸測試，我們現在有大量的回歸腳本支持回歸測試，但是某些缺陷是無法通過回歸腳本發現的，往往需要我們通過對業務的嗅覺，進行回歸點的挖掘，來實現對缺陷的預防。
下面舉一個現有回歸腳本無法發現的缺陷：
前提：業務一的開發早于業務二
（業務二）對某一實體進行修改操作，該改動涉及到一個（業務一）同樣關心的字段。
（業務一）對該實體進行查詢操作，在解析上面的字段時，由于無法解析而報錯。
在單純對業務一的持續集成腳本的維度來說，無法解析的屬性，應該是要報錯的，這個異常流程走的很對。
所以如果單純從之前的回歸腳本進行回歸而判斷這次修改是否影響到了之前的邏輯，是武斷的。
同樣依靠同學們對業務的熟知度，來挖掘業務二對業務一的影響。這種做法并非科學，任何一種完全依靠人腦來做決定，是會有遺漏的，是有風險的。
再舉一個例子通過查代碼去發掘回歸點可能遺漏的例子
如何發現一段代碼的影響范圍，大家是不是做過去看下這段代碼將會被哪些代碼調用，即對應的下游代碼。無疑這么做確實可以發現同一流程下的影響點。但如果不在一個流程里面呢？如果相關同學對將會影響到的業務其實并不熟悉，該怎么辦？
我們就需要一張大圖，一張業務邏輯大圖。這張大圖的組成為實體+沉淀+入口。
為什么要做這張大圖，這張大圖是什么樣子的？
我們的系統是基于MVC模型，通俗說法就是通過V調用C去操作Ms（因為M可能很多，哈哈）。所以歸根結底，變化的是M，影響的也是M。
M，即Model，它主要與數據載體交互的功能。我們將與M交互的數據載體，稱為實體。
沉淀，即業務沉淀，即對應的功能點的IO與控制器的綜合體，是業務的精華。
入口，就是記錄入口在哪里，方便區分業務。
如果我們有了這樣一張大圖，同一個實體被多個業務使用到，我們可以輕松得通過實體反向抓取出對應的業務，然后通過對業務沉淀的分析，獲取相應的功能影響點。
這張圖，我們需要一個好的載體，這里選擇MM圖。下面我做了一個簡單的示例：
其中用了幾個標簽：t 功能點標簽；a 業務沉淀標簽；e 實體標簽；l 入口標簽。
標簽的好處就是在編寫完成之后，可以方便得進行數據提取，進行業務分析。
MM圖化有什么好處呢？
1、大容量
可以把一個系統，甚至一條業務線的業務整理到一個MM圖里面。
2、樹狀結構，方便業務梳理
3、規范化編寫
規范化編寫，可以方便利用工具進行提取，也方便人工閱讀和挖掘。
業務沉淀圖形化，規范化，對后續的回歸和業務變更會帶來很多好處，也會對回歸點的判斷上，做出更加科學的判斷。
精準回歸，核心在業務層面，是對業務的充分理解和剖析，是對業務的有效管理和挖掘，但是我們可以在技術層面上為這一系列管理更加高效而實用，大家可以繼續關注后續的博客哦。