如何进行MDM的产品测试
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产品熟悉
测试不仅是找问题的过程，也是产品熟悉的过程中，在使用前进行整体的、全面的测试，不仅是自己的工作任务，也是一个熟悉产品的过程。软件测试在公司中担当的是“质量管理”角色，可以及时纠正产品的错误并及时更正，确保产品的正常运作。
6.2方案熟悉
MDM不仅是一个主数据治理产品，它与我们公司的其他产品相互组合可以产生1+1>2的神奇效果，在搭配过程中，不同的产品组合可以解决企业不同的难题，在测试过程中去熟悉产品之间的关联和使用，也是自我提升的一种方式。
6.3能力提升
无论多么细致的测试，最终落实到项目中或多或少都会出现问题，想要在实际项目中进行不断地打磨，让产品更加完善，就需要技术部门与开发人员的共同努力，只有互相合作，互帮互助，才能将产品打磨成为一款精品。
产品测试是在发布前的最后一道保障，只有把控好最后一道关才能将产品安全的交付到客户手中。在我对公司的每款产品进行测试的过程中，不仅能把发现问题进行解决，还能在一次次的测试中提升自己对产品的理解。在熟悉产品的过程中，针对于产品的衍生方案、实际项目中的应用、可以解决的事情等，都是我所需要去了解的。