简介
最近，我接到一个任务，要处理几个已经实现的接口。所有这些接口都是相似的。
我将根据其中一个（供应商主数据）讨论我的问题。
这是一个将供应商主数据从SAP系统发送到外部系统的接口。
最大的挑战是在许多不同的系统上实现了相同的接口。三个PI系统和四个ECC系统。下面是接口的数据流是什么样子的
如果接口没有改变，一切都会很好，大数据市场，但实际情况完全不同。在现有的接口中总是有很多更改或修复。此特定接口的大多数更改都是在SAP PI映射中进行的。
随着时间的推移，很难跟踪哪些更改转移到了哪个系统，哪些更改仍然需要转移。一般来说，一个地方的映射变化可能会导致另一个地方的意外结果。
我想最好有一些工具，可以让我测试映射的结果。
我在ABAP中创建了一个简单的工具，可以向PI发送消息，物联网概念股，PI系统执行映射，返利联盟，然后工具读取映射后产生的消息。将此消息与参考消息进行比较，服务器租用，并检查参考消息与实际消息是否相同。
接口测试工具
事务的总体外观如下所示。在左边你可以看到一棵树，上面有项目。在右边，您可以看到特定项目中的测试用例。
最重要的列是：
测试用例ID测试用例的描述测试用例状态（成功/失败）测试类型（PM–PI映射）系统名称接口名称Message Guid–PI系统中的消息Guid映射前消息（有效负载）Guid–此列表示映射前的消息（有效负载）。此消息存储在数据库中，可以修改。它的第一个版本是从PI系统下载的。映射后预期的消息（有效负载）Guid–此列表示映射后预期的消息（有效负载）。此消息存储在数据库中，可以修改。它的第一个版本是从PI系统下载的。映射实际后的消息（有效负载）Guid–此列表示"执行测试"操作后PI映射后的消息（有效负载）
PI系统中的消息流如下所示
现在我将展示该工具在特定示例中的工作方式。
任务：更改PI系统中的映射–在供应商name已经有引号了。
示例：
输入：Supplier"name"=>Supplier"name"
现在我们可以运行剩下的测试，数据和大数据，检查我们的更改是否在意外的地方进行了更改。
在我看来，这个工具虽然很简单，提供了很大的可能性。
我想到的好处：
我们不怕做出改变，因为我们有一套在做出改变后必须通过的测试很容易看出我们的更改是否影响了接口的另一部分，在进行更改之后，其余的测试应该通过我们可以很容易地检查更改是否已转移到其他系统-只需为另一个系统创建具有相同内容的新测试
还有几个缺点：
该工具仅适用于映射不是1:1的接口。我认为测试没有逻辑的映射毫无意义在使用之前，该工具需要大量的手动配置，其中包括配置到PI系统的连接、创建逻辑端口、配置接口和系统。这个工具比最终版本更能证明概念。有很大的改进空间，例如记录PI系统中发生错误的消息，更好的错误处理
我计划在将来将此工具作为一个开源项目提供。我需要先重构一些代码，使之更具可定制性。
我和几个人谈过这个工具，但票数不一。所以我想征求你的意见。您对这种接口维护方法有何看法？什么时候创建映射测试才有意义？创建测试用例有意义吗？还是需要太多的工作？还应该在工具中实现什么使其更有用？
