集成底座流程测试总结

每当一款产品或是产品中的一项功能在完成之后都需要对其进行测试，去验证该产品或该功能是否可以正确工作，达成用户预期的效果；测试就是站在客户的角度，以产品或是功能预期能够达到的预期效果为模板去对产品或是功能进行实际操作，操作的结果是衡量该产品或是该功能上线还是需要继续完善的标准。

当根据客户的需求完成开发之后，就需要按照客户的需求去对开发完成的成果进行测试，以验证开发出来的成果是否可以实现用户的需求。本人在进行工作时，根据客户的需求，对前期开发完成的流程进行了一定程度上的调整，调整之后对流程进行了功能测试，并整理成本篇文档，以期后续在工作中有所遗忘时可以进行查看。

▎整体介绍

根据客户的需求以及反馈，对已经开发结束的流程进行了细节调整，同时由于项目即将上线，进行最后的流程联测，为后续项目上线做好准备，在下面将会对本次进行测试的流程进行简要介绍。

1.整体架构

集成底座以 IDM、MDM 和 ESB 产品为核心搭建基础的底座平台，打通信息系统的壁垒，同时为后续企业信息化的深度集成与建设提供支持。

集成底座在整个信息化系统架构中是偏向于基础的，一是通过 MDM 平台对接上下游系统实现组织、岗位、人员等基础数据的统一，为系统直接的对接以及后续的业务集成、单据集成、分析展现等提供基础数据支持；二是通过 IDM 平台完成账户统一与统一认证，实现各个系统的单点登录，满足建立统一、规范的应用中心的条件，从而奠定企业信息化的基础。

2.业务流程

1.以 HR 系统为源头，HR 负责提供组织、岗位、人员的源头数据；

2.HR 系统在进行新增、修改、启用、禁用等操作时进行提交，再调用技术底座的同步接口将数据以 JSON 的方式进行推送；

3.技术底座的同步流程接收 HR 系统的 JSON 数据后进行落地，同时自动生成数据分发的任务（增量，初始化需业务系统主动获取），并产生任务标识 TaskId；

4.技术底座将 TaskId 推送至下游业务系统的任务接收接口；

5.下游系统接收 TaskId 后，先调用技术底座的获取 tokenId 接口获取 tokenId，再调用技术底座提供的数据提供接口获取任务中的 JSON 格式数据，并将数据写入下游业务系统中，写入后调用技术底座的日志接口进行日志回写。

3.测试思路

由于项目即将上线，所以本次测试按照上线时的数据进行联测，包含数据的初始化以及增量数据的同步，下面是本次整体的测试思路。

1.传输数据情况下验证接口调用时间；

2.验证组织层级关系是否处理正确；

3.传输后的数据以及参考数据可正常显示；

4.传输大量数据时是否存在丢失的数据；

5.数据传输成功后查看日志状态是否更改。

▎测试目的

测试是在一款产品在正式投入使用前，对产品功能进行最终复审，是一款产品质量保证的关键步骤，也是为了发现错误而执行的过程。仅就测试而言，它的目标是发现产品中的错误，但并不是我们的最终目的，测试的目的大致分为两种，一是暴露缺陷，二是树立信心，这两点将在本章节中进行具体阐述。

1.发现缺陷

一次成功的测试是发现了曾经未发现的错误的测试。这句话其实也就对测试的其中一个目的进行了阐述：以最少的人力、物力和时间去寻找产品中潜在的各种错误和缺陷，并对发现的错误及缺陷进行处理，以此提高产品的质量，避免产品正式投入运行之后由于潜藏的缺陷而带来商业风险。

2.预防缺陷

每一款产品都不会是毫无缺陷的，那么如何最大程度上地避免缺陷的产生就是产品测试存在的意义之一，上文提到测试是为了让产品中的缺陷在产品未正式投入运行之前将其暴露出来并进行修复，在使产品暴露缺陷并修复的过程中吸取的经验也会让后续的产品开发去避免同样缺陷出现的情况，从而提高产品的质量，这也是测试的主要目标之一。

3.优化产品

用户拿到经过测试的产品和没经过测试的产品，对质量的信心是不一样的。所以测试可以树立用户对产品的信心。同时，如果在测试过程中很少出现或是不出现产品问题，那么会很大程度上提升开发者的信心乃至提升整个企业的信心，这种信心是隐性的一种特质，对自家产品有信心会使企业的销售人员更便捷的推出去产品，所以在产品正式投入使用之前进行测试是非常有必要的。

▎测试内容

本次主要项目上线前对人员组织岗位流程进行联测，保证数据传输过程中的准确性以及完整性，以便后续项目能够稳定上线。

1.测试要点

本次测试内容主要测试各业务系统间的连通性，保证数据可以正常进行同步及分发；其次针对各业务系统的数据显示情况进行测试，确保各业务系统中的数据显示正常；最后测试各业务系统在数据传输过程中数据格式映射的正确性，确保数据以正确的格式传输到目标系统，不会出现在数据传输过程中出现数据丢失的情况。

1.检查组织、人员、岗位的相关数据管控，查看日志信息是否回写或修改完成。

2.MDM 系统、IDM 系统分发完毕后，检查系统表组织和人员是否同步完毕。

3.检查组织、岗位，人员的相关数据管控，查看日志信息是否回写，数据是否已启用。

4.检查组织数据父节点类型是否跟源头推送过来的结构保持一致。

5.IDM 系统分发完毕后，检查系统表人员是否同步完毕。

2.同步流程

同步流程主要用来让客户完成客户数据的修改操作，或是在客户数据集体录入结束，产品正式上线之后让客户进行单条客户的录入操作。客户在进行新增、修改、启用、禁用等操作时进行提交，源头系统自动调用 ESB 的同步流程，将数据以 JSON 的方式进行推送，完成客户数据从源头系统到主数据系统的字段映射处理，并调用主数据系统提供的数据同步接口将数据同步至主数据系统，后续通过主数据系统的自动提交接口将数据的任务 ID 送到目标系统，再由目标系统的流程进行一系列处理之后存储到目标系统。

1.检查组织、人员、岗位的相关数据管控。

2.检查组织、人员、岗位查看日志信息是否回写或修改完成。

3.检查组织、人员、岗位数据状态是否正确。

4.检查组织、人员、岗位数据父节点类型是否跟源头推送过来的结构保持一致。

3.分发流程

分发流程主要接收主数据源头系统的组织、人员、岗位主数据，调用 ESB 的分发流程，根据 TaskId 调用数据提供接口获取数据，再将数据写入下游系统。

1.检查组织、岗位、人员的相关数据管控，查看日志信息是否回写。

2.检查组织、人员、岗位数据状态是否正确。

3.检查组织、人员、岗位数据父节点类型是否跟源头推送过来的结构保持一致。

▎效果展示

在完成流程的调整之后，本人对流程进行了测试操作，用以保证流程的可用性，暴露潜在的功能缺陷，在本章节中，将对本次测试的预期效果、测试过程以及测试完成的效果展示进行阐述。

1.预期效果

HR 系统在进行新增、修改、启用、禁用、等操作时进行提交，调用技术底座的同步接口将数据以 JSON 的方式进行推送，在通过主数据系统的自动提交接口将数据的任务 TaskId 送到目标系统，推送成功后各业务系统相互间的调用正常、数据传输正常、传输字段无缺漏的问题，同步分发皆可传输至目标系统，并在目标系统正常显示。

2.测试过程

本次同步的数据源头为 HR 业务系统，本次测试模拟 HR 进行业务操作，直接调用同步接口进行测试，通过 Postman 进行接口调用如下：

查看刚才同步的任务效果如图：

数据同步值主数据系统中效果如图：

在主数据系统中选中一个数据，点击生成任务进行数据下发，如图：

点击提交即可将数据分发至目标业务系统，如图：

经验证数据已分发至目标业务系统，如图：

3.效果展示

在本文档中，页面展示以主数据系统为例，首先对层级关系数据进行验证，以人员数据为例，查看组织下是否有人员存在，以及是否挂载于正确的组织之下，如图：

经验证，人员与组织关联关系正常，如图：

经验证，传递的参考数据显示正常，传递的数据确为 CODE 值，如图：

▎心得体会

在本次同步分发流程开发工作中我学到了很多知识，对同步分发操作更加的熟练，加深了我对各个产品的认识，并且对各个产品的组合使用有了更清晰的理解，现将我在本次工作中的收获进行总结。

1.经验收获

在联测过程中收获了许多经验，包括使用 ESB 方面和联测方面等。这次联测让我在 ESB 使用方面变得更加熟练，学会以前不会使用的功能，还了解到许多在开发流程时需要注意的地方；认识到联测时出现的问题不会只是其中一方系统的问题，在处理这些问题的时候需要双方都做系统调整来解决问题。

2.能力提升

通过本次对开发的流程测试之后，本人对所开发的流程有了更深层次的了解，对客户的需求也更为明确，同时在修改流程中暴露出来的缺陷之后，更加丰富了本人对开发流程的经验，在后续的开发工作之中，这些暴露出来的缺陷将不会再次出现。

3.心得体会

测试是一个系统而复杂的工程，测试的目的就是确保产品的质量、确认产品以正确的方式做了你所期望的事情，所以工作的主要任务是发现产品的错误、针对于这些一次次的测试优化让产品更加的完善，产品测试对逻辑思维、学习能力、反应要求很高，是否有严密的思维和逆向思维也非常重要。

做测试还要考虑到所有出错的可能性，有时候还要用一些非常规的测试方法。产品测试还很注重软件性能问题，也就是要保证产品运行得很好；不同的使用环境下，考虑产品的兼容性同样重要。对于测试员来讲，会比开发人员更加重视软件产品的质量问题。在测试过程中，测试者要站在客户的需求角度考虑。