AEAI MDM是數通暢聯産品家庭裡的基礎資料治理平台，保證主資料在各個系統中的正确性、重用性和通用性。從系統應用度而言，主資料管理是把企業的多個業務系統中最核心的、最需要共享的資料（主資料）進行整合，集中進行資料清洗和标準化，并且以內建服務的方式把統一的、完整的、準确的、具有權威性的主資料，分發給需要使用這些資料的應用系統，包括各業務系統和決策支援系統等。
一款産品在上線前，會存在這樣或那樣的bug，随着後續MDM産品不斷擴充功能，雖然其界面UI或功能會産生調整，但整體的建構和使用思路并不會改變。本人也進行了MDM的産品測試，通過在測試過程中總結出的經驗，為後續進行産品測試的人員提供參考。
1總體概述
MDM可以将企業的黃金資料進行高度的資料統一，各業務系統複用一套主資料，就像一個大系統的各個業務功能子產品，企業IT架構可以實作柔性調整、更新、改造，進而支撐企業的業務戰略目标落地。
1.1産品說明
主資料作為一個統一管理基礎資料的平台系統，其中的基礎資料都是完整的、統一的、準确的，主資料平台的使用者為各個應用系統的相關負責人員，在主資料中存放的是各系統的基礎資料，各個應用系統中存放的是其業務資料。主資料分為MDM和MDC兩部分，MDM的功能以顯示、管理各系統基礎資料為主，MDC的功能以配置基礎資料模型為主。
1.2功能架構
MDM功能架構圖如下所示，分為主資料管理平台和MDC管理控制台兩部分：
主資料管理平台主要用于資料的全生命周期管理，資料的同步下發，對資料進行清洗，保證其品質，并針對于資料管理情況進行可視化的視圖展現。
而一個完整的主資料生成方式就需要在MDC進行配置，包括了資料模組化，功能模組化，分發時用到的流程模組化，系統對接以及參考資料、校驗規則等配置。
1.3解決方案
應用內建方案 ESB + MDM
統一身份方案 IDM + ESB
基礎資料方案 MDM + ESB
數倉建設方案 DAP + ESB
內建底座方案 IDM + MDM + ESB （iPaaS方案）
資料中台方案 MDM + ESB + DAP （dPaaS方案）
應用中心方案 MDM + ESB + Portal （aPaaS方案）
全域內建方案 ESB + MDM + DAP + Portal + IDM （ePaaS方案）
2測試内容
MDM測試過程中需要注意測試流程，測試的V模型如下：
由于本次測試是内部測試，是以到不了驗收測試階段，但如果隻是功能方面的單元測試，那麼肯定無法達到測試的整體效果。
2.1測試流程
MDM的主體測試流程如下：
1.測試流程的主體是三個子產品：資料模組化—功能模組化—資料管理；
2.在測試時，資料模組化過程中字段的關聯定義可以和參考資料功能關聯，字段的規則定義；
3.功能模組化在測試過程中，如果需要配置widget元件切換到功能元件中進行配置和測試；
4.主資料類型如果為關聯樹，這時需跳轉到分類資料模組化中進行測試；
5.在建立主資料前，進行資料下發對接的流程模組化和應用配置子產品的測試；
6.資料管理子產品進行功能測試完畢後，進行資料清洗的功能測試，針對于品質管理子產品的功能測試完畢後，将資料導入到資料管理中；
7.資料豐富或進行流程測試後，在資料分析中檢測資料統計是否準确。
2.2資料模組化
資料模組化可以作為整體的測試開端，包括了整個後續的功能模組化，資料管理等，都是基于資料模組化進行落實的。
包括了資料模型的建立，字段的校驗方式等，都是從資料模組化開始的。
主資料建立成功後，從詳情頁進行模組化頁面的跳轉和清單頁進行模組化的跳轉，檢查是否有不一樣的地方。
來源系統與分發系統進行配置檢視功能是否完備。
在資料模組化頁面，新增字段，選擇select、radio、widget字段就可以進行參考資料的配置。
點選參考資料按鈕，跳轉到參考資料頁面進行配置和測試。
測試完畢後，添加校驗規則進行測試。
如果不會正規表達式，可以到網上查找正規表達式的公式，進行配置測試。
2.3功能模組化
資料模組化完畢後，進行功能模組化的測試，功能模組化是作用于整個資料管理子產品的定義。
包括了表單資訊頁面，針對每個字段的樣式，頁面的樣式等都會在這裡進行配置。
甚至于頁面中的每個按鈕都可以進行設定。
如果在功能模組化中選擇了樹關聯，則可以跳轉到分類模組化頁面進行功能的相關測試。
在分類模組化頁面進行不同組織的關聯，不同的sql配置等。
在表單的頁面配置中，選擇一些字段設定為widget元件，然後切換到功能元件中進行配置和測試。
針對不同的元件類别和資料源類型，共可以組合出來6種元件配置，需要一次排列進行測試。
流程模組化部分可以讓MDM與外部接口進行關聯，主要作用于資料的分發。
在流程調用節點中，配置相應的流程服務或資料庫讀寫，既可以測試接口功能是否好使，也能測試該功能是否滿足接口調用。
應用配置也是MDM與其他業務系統進行打通，或者其他系統與MDM打通的重要功能之一。
應用的新增修改、配置完畢後的token接口調用、主資料的關聯情況、字段是否能夠準确過濾等都是需要進行測試的。
2.4資料管理
功能模組化測試完畢後，可以進行模型部署，部署完畢後對主資料頁面進行重新整理，剛剛新增的主資料就會在左邊導航欄進行顯示。
針對于不同類型的主資料要進行不同主資料的生成和測試，保證一個流程完畢後在進行下一個測試。
在基礎的功能測試完畢後，切換到資料清洗頁面進行清洗測試。
根據功能配置中的清洗導出規則進行相應的測試。
測試完畢後将資料導入到對應的主資料中，導入确認無誤後切換到資料分析中進行資料比對，檢測是否無誤。
2.5功能聯測
正如上邊的資料模組化—功能模組化—資料管理這三步是循序漸進的，生成單表那麼單表生成完畢後，再進行下一次的模型建立是最好的測試方式。包括在功能模組化過程中，如果關聯樹後跳轉到分類資料模組化頁面中。
在這時，根據操作的順序進行分類模組化的測試即可。
2.6其他功能
MDM的其他功能也是圍繞着基礎資料的管理而使用的。在整體的主流程測試完畢之後，針對于其他部分的使用也需要進行相關的測試，例如：widget元件的配置：
但是頁面配置完畢後，需要記得回到功能配置中進行字段擴充，并實際生成主資料後，才算測試完畢。
3功能測試
介紹完MDM的測試流程，那麼針對于MDM的基礎功能資料管理的測試方式如下。
3.1資料模組化
資料模組化中根據模闆類型和模闆特性，可以組合出多種主資料類型。
但在測試過程中，針對于每種主資料類型進行單獨的一套測試，這樣才能保證測試過程中的連貫。
3.2功能模組化
功能模組化是根據資料模組化進行的進一步配置，根據不同資料模型生成不同的功能模型，主要的測試點為表單資訊子產品，其中包含了很多針對字段的調整功能，不同的顯示類型、提供方式、限制方式等，都是在功能模組化中需要進行測試的。
3.3詳細配置
在生成主資料前，有很多可以讓主資料更加豐富的地方；
在流程定義清單中，針對于資料的分發流程的測試。
字段的限制操作等。
3.4資料管理
資料管理即為最終生成的主資料，簡單清單、簡單清單關聯樹、樹形表格、主從表等，這些都是在每一次主資料建立完畢後，在資料管理中整體測試到位後才算是測試完畢。
删除節點、資料修改等基礎功能需要測試外，針對于生成任務子產品，在資料生成完畢後就會在分發任務中，生成對應的任務資訊。
如果是結合了ESB流程進行測試，那麼針對于接口是否回寫日志等，也可以進行關聯性測試。
4業務聯測
想要将一款産品測試到位，不僅隻是對功能進行點選測試，一款産品的實際作用，需要各個子產品之間的互相關聯才是實作産品價值的必要條件。
4.1接口服務
在生成主資料後會，生成對應的API接口用于增删改查等主資料操作，這個接口是管控着主資料針對于上遊系統的資料接收和下遊系統的資料分發。在位址欄的字尾加上openapi會進入api頁面（http://localhost:4040/mdm/openapi）。
在将位址複制到soapUi中可以進行接口測試，接口的出參入參可以在MDC的API接口中進行檢視。
4.2應用配置
MDM基礎資料平台的作用是用于基礎資料治理，而資料治理涉及到了資料同步和資料分發，在整個流程全部測試完畢後，就需要考慮主資料的實際應用功能，應用配置就是打通主資料與各個業務系統之間關聯的必要一環。
MDM無論是進行上遊系統的資料同步，還是下遊系統的資料接收，都需要擷取其tokenId，是以在資料管理測試完畢後，就需要對于系統同步分發的必要功能進行測試了。
4.3任務日志
資料同步和分發也是在主資料的生成過程中進行測試的。如果在BPM中配置了ESB流程或者進行了資料同步測試，那麼同步的日志資訊就需要進行檢查測試。
資料分發時的分發任務，是否生成了分發的日志資訊，資訊是否回寫等，這些在流程配置完畢後都需要進行全面的細緻測試。
4.4品質管理
品質管控是MDM的重要功能之一，通過定時或手動等方式進行資料的品質管控，資料清洗方式通過不同的測試方式與應用配置中的互動邏輯都是需要測試的。
5注意事項
在測試過程中也有不少的測試要點，無論是産品在測試前的學習，熟悉産品之間的功能聯系，亦或者是産品測試方式都會讓測試有一個很好的效果。
5.1功能熟悉
在測試MDM前，首先要對MDM的整體功能進行熟悉，了解整個産品的使用流程，但不要産生固定思維，固定思維包括：對功能過于熟悉産生了肌肉記憶、對這部分的功能非常熟悉，在開發過程中經常通過這種方式操作。所謂當局者迷旁觀者清，跳出固定思維才能保證測試的客觀性。
5.2流程閉環
在整個MDM系統中，所有的功能都是圍繞着最後的主資料治理功能，是以在實際測試過程中，可以思考如何才能将整個功能串聯起來。例如：資料模組化-功能模組化-資料管理是一套流程，然後進行資料分發，生成的任務管控，在生成完任務後，到監控統計中進行檢查。
在一套業務流程走完後，才算是一套流程閉環，而每次測試都是基于這種思路進行，不僅會讓我們對于産品測試更加順手，還能夠提高産品的使用熟悉度，在後續的産品實際使用中，也省去了不少的學習時間。
5.3破壞測試
在測試過程中，如果按照産品的既定功能去操作，很大機率不會出現問題，但是客戶不一定會按照産品的功能去操作，可能會點選很多功能，或者不按照順序操作，是以在測試的過程中，不僅要對已有功能進行測試，還要進行一些非正常功能測試，例如：在之前的功能模型測試中，将所有表單都删除後，再進行部署儲存等，在整個的測試過程中要時刻進行破壞測試。
6心得體會
在測試的過程中，通過進行産品測試，以及與之前使用的産品相結合，讓我對于這款産品有了新的認知。
6.1産品熟悉
測試不僅是找問題的過程，也是産品熟悉的過程中，在使用前進行整體的、全面的測試，不僅是自己的工作任務，也是一個熟悉産品的過程。軟體測試在公司中擔當的是“品質管理”角色，可以及時糾正産品的錯誤并及時更正，確定産品的正常運作。