从技术上看，消息系统有如下的测试难点:
业务逻辑不清，测试用例不足
许多应用因为年代久远，中间又几经转手，大部分都没有测试用例了。再加上大部分团队都不是很清楚老应用的业务逻辑，需要大量的时间来读代码，制定实际测试方案，从而进行测试。
数据流向不固定，消费对象难定位。
消费者并行地消费消息，很难保证特定的消息被特定的消费者消费。
数据流动非同步，跟踪测试不直观。
消息系统是一个异步系统，这样大大地增加了追踪测试数据，衡量测试结果的难度。
根据以上困难，迁移团队认为理想的测试方案应该具备一下特性：
可控制
消息的流向是可以完全被控制的，这个目标主要是解决测试中消息跟踪难的问题。
自动化
每个应用中消费的消息类型种类繁多，要通过自动化的测试来覆盖所有的消息类型。这个目标要解决效率和测试用例覆盖率的问题，要在没有人为干预的情况下高效、高覆盖的完成测试。
可衡量
无论对于功能完整性，还是对于非功能的性能、JVM 内存使用、GC Overhead 等性能指标要有办法比较。这些可比较可衡量的指标，不仅对于交付的质量有信心，同时也会使得用户对于接下来的验证工作有信心。
引流测试 -- 以彼之道还施彼身
如果能将老的系统消费的消息引流到新的系统中，然后比较两边消费消息的结果，不就是一种低成本高覆盖的无需深度了解内部逻辑的测试之道吗？这就类似武侠小说中常出现的招数， “以彼之道还施彼身”或者“借力打力”，借线上流量之力，引流回放，比较新旧系统的处理结果，从而达到测试迁移后新应用的目的。同时利用大规模的线上消息做回放也能完成新应用的性能测试，简直是一举两得。
如何控制消息流向
解决了数据来源后，我们又发现了另一个问题: 因为新老平台上的消费者都是等价的，对消费者来说很可能出现我们为新应用准备的引流消息被老应用夺走消费了，这样也达不到我们比较消费结果的目的了。如何使得引流的消息定向地被指定的消费者消费是引流回放机制必须要解决的问题。
一个完善的消息系统平台应该提供消息隔离的机制，具体来说就是特定的消息可以定向的被指定的消费者消费，称之为消息亲和(Affinity)。所谓消息亲和即在消息和消费者上都做相应的配置，类似打上相同的标签，使得消费者只会识别消费具有相同标签的消息。利用亲和机制，引流回放的策略就应该是从消息数据库中获取消息并且复制一份，为两份消息打上不同的标签，对新旧平台之上的消费者都也打上相应的标签。这样具有相同标签的消息就会被分别引流到新旧平台上消费，再通过比较两个平台上的消费结果是 否一致(对照测试），来确保迁移后的消息系统能够保持和之前一样的行为。
如何衡量测试结果
当引流的消息被消费后，就需要追踪测试结果，并且进行多维度的结果比较，包括：
比较消息的处理状态
如果消息被两边平台处理后的状态都是成功，那从某种角度来说新老应用的行为没有因为迁移而发生变化。
比较日志系统中生成的日志
如果在新的平台上产生了异常信息，而在老平台上没有相应的异常，那就说明迁移中应用行为发生了改变，需要花时间去解决。
比较消息处理的时间以及系统的性能参数
对于消息处理的SLA的比较，以及消费者机器的CPU，Memory，GC overhead等性能的比较，能够确保迁移后的应用没有任何性能上的问题。
成果
我们基于这个理念开发了一套测试工具，所带来的效果是非常显著的，它很好的解决了迁移过程中的测试问题。主要表现在以下几个方面：
测试时间短
自动化的测试流程大大缩短了测试所需要的时间，一个中大型的消息系统，如果要从头去理解内部逻辑，整理回归测试集，没有几个月时间根本完不成。但是这个工具，大大的简化了这个过程，只需要提供简单的配置 ，一键便能完成测试，总过程只需要大约1天时间，同时这个工具提过的多维度的自动比较，并通过丰富的GUI很好的展示出来，帮助迁移团队节约了大量的发现问题的时间。
测试效果好
利用引流回放的测试方法，可以在无需知道应用内部逻辑的前提下，覆盖所有的消息类型。从而保证各种的边界情况都被照顾到，各种边界的问题较早的暴露了出来并且被及时的修复了，上线再也不用心慌慌了。
团队信心高
在这个数据为王的时代，测试数据为各种决策提供了依据，为迁移团队和用户提供了信心，迁移的客户在看过测试的报告后常常会提前他们的迁移计划，在短时间内完成迁移。
使用范围广
这个自动化测试平台不仅可以用来满足拆迁的需求，更能被广义的用来测试消息系统应用，满足用户新功能开发，维护和系统升级的测试需求