作者简介
虞斌，携程机票BU资深测试开发工程师，主要负责携程机票测试工具以及基础组件的研发。对自动化测试领域有较深刻的认识，对新技术有着浓厚的兴趣。
前言
在互联网企业中，开发项目的快速迭代是必不可少的。这就导致了大多数情况下，很多测试人员的回归测试速度远远跟不上项目开发的迭代速度。
传统的接口自动化测试是测试人员事先编写好测试用例，写好相应的验证点，然后通过手动执行或者Jenkins自动执行用例，来达到接口回归测试的目的。
但是对于一些结构复杂度高、内容大的报文（如机票引擎的报文）来说，通过手动编写测试用例来做回归测试的成本很高，而且很难做到全面覆盖。
所以我们致力于寻找一种解决方案，使其能够低成本、高效率地解决上述问题，接口通用比对工具随之应运而生。
一、传统的比对思想
大家都会说，报文比对么，直接用beyondcompare等第三方的工具，把需要比对的文本粘贴进去，直接就能出结果了。确实，这么做也是比对的一种方法，但是这个只适用于结构比较简单的接口。
在实际的项目中，有一些接口的结构被设计的非常复杂，且自身结构还带有复杂的业务属性。这种情况下，传统的比对思想就变得不那么适用了。
二、什么是带有业务逻辑的比对思想
比对逻辑的本身其实很简单，就是同一层节点的“一对一”对应，然后分别进行比对，但是如何能找到这“一对一”的对应呢？
首先，我们可以把接口报文的节点分三种情况：
a）节点是叶子节点。（即：节点值的类型是string、int、float等基本类型，已经无法再遍历进去的节点）这种情况最简单，只需要通过节点name就可以找到对应关系。
b）节点是一个自定义的类型。这种情况需要对自定义类型的每个属性进行遍历，然后通过属性名找到“一对一”的对应关系。
c）节点是一个数组集合。这种情况下的对应关系是最难确定的。因为集合中的元素通常并不是有序的，所以集合里面元素的对应关系就不能简单暴力地通过index的方式来确定了，所以我们需要另寻解决方案。
为了解决数组集合中“一对一”对应关系的确定，我们提出了一个业务逻辑key的概念。业务逻辑key是指在数组集合中某个元素的一个或者多个属性值的组合，并且在这个数组中可以唯一确定这个元素。
举一个机票的例子：在一个航班信息的无序数组中，航班号（flightNo）和日期能够唯一确定一个元素，那么flightNo和date的组合就是这个集合的业务逻辑key。
通过业务逻辑key，我们能够以更贴近业务的方式来确定集合中元素的对应关系。也能够很好地解决集合的乱序问题。以达到带有业务逻辑的比对思想的目的。
三、对于关联结构的比对思想
机票的一些核心报文体量是非常大的。为了能够进一步压缩报文，我们设计了一种我称之为Agg结构的报文结构。即把同一类可能会被重复使用的节点抽出放到另外的节点数组中进行统一管理并编号，在原来使用的地方引用该编号作为关联关系。
举个例子：在查询国际航班的时候，大多数情况下返回的是航班组合。这种情况下，同一个航班可能会有不同的组合而出现很多次，如果每出现一次就把该航班的所有信息都放进报文里，那么报文中就会出现很多重复冗余的航班节点，这大大增加了报文的体积。
而Agg结构的出现，则把所有航班节点都放在FlightList的节点中去重复，然后按顺序编号，原则上每个航班号只会在数组中出现一次。而在航班组合节点中只输出航班号对应的编号的组合，有点类似于关系型数据库。这么做的好处就是大大减小了报文的体积。
但是对于我们测试或者比对逻辑来说，这却是一个巨大的新的挑战：
a）如何处理编号。编号是在抽出重复节点过程中，为了能够唯一确定某个节点而顺序给的唯一编码，它本身并没有并不具备任何业务意义，且在重复请求中，同一个节点的编号可能会不同。所以，在比对过程中，我们不能简单的将它们直接进行值的比较，那样没有任何意义。
b）为了解决这一问题，我们引入了reference的概念。即在接口业务逻辑配置的时候，通过编号设置节点之间的关联关系，在比对之前通过该关联关系先计算出所有关联节点的业务逻辑key，这样，在之后的比对过程中，通过已经计算出的业务逻辑key准确的找到需要比对的关联节点。再通过通用比对逻辑，递归遍历所有节点。
基于以上，我们设计开发了一个针对复杂报文接口的通用比对工具。该工具的特点是比对逻辑通用，业务逻辑可配置。通过这种方式，可以有效地降低后续的维护成本。
四、功能介绍
1、接口管理
a）接口信息配置——获得接口的请求、响应报文契约结构。
b）测试用例模板管理——该功能可以将测试用例绑定到接口上，方便测试套件添加测试用例。
c）响应报文业务逻辑key配置——可以为每个数组节点添加业务逻辑key，不设置默认按顺序进行比较。
d）响应报文Reference配置——适用于Agg报文的结构。用于嵌套计算业务逻辑key。
2、测试套件管理
a）基础配置——每个测试套件对应一个接口，里面可以有若干个测试用例，测试用例可以从接口模板克隆而来，也可以另外创建。
b）例外节点排除——可以排除一些不需要参与比对的节点，如时间戳等。
c）用例执行——并发的执行套件中所有的测试用例。
d）结果展示——展示比对结果，测试人员只需关注并分析执行错误的测试用例即可。
3. 比对流程
特点：
a）业务逻辑配置——可以理解为把接口的业务属性翻译成一条一条的规则，录入系统，然后让系统能够理解报文的结构。
b）比对逻辑通用——针对任意一种报文结构，比对的逻辑是不会变的，即找到一对一的对应关系后，逐一比较对应节点的属性，直到最后的叶子节点。
c）降低复杂接口的测试门槛——所有接口的逻辑关系只需要在新建的时候配置一次，通常会由最熟悉该接口的开发人员来配置。然后使用方只需要执行用例，然后分析用例中不同点是否符合预期即可。这样的话，即使是新接手的开发或者不太熟悉接口结构的测试人员也能够很快上手并完成一轮接口的回归测试。
结束语
以上是我对复杂报文比对的一些理解，在这里和大家分享，希望文章能对大家有所启发，欢迎大家在学习的过程中一起交流讨论。
【推荐阅读】
