Dubbo接口的回归测试利器

随着公司业务复杂度的增长，系统的数量也不断增加，系统间的交互变得更多也更频繁，系统间接口作为各系统交互的一个主要途径，其作用和地位也越来越重要。前两年咱们IT在架构与开发方面都做出了一定的成果以支持接口数量增长的需要。今年上半年，测试团队在接口质量保障方面也有所突破，完成了核心业务系统（dubbo接口）的自动化测试项目。

目前公司各系统接口众多，特别是核心业务系统，处于整个交互网络的中心位置，它提供了繁多的各类业务接口供其它系统调用。核心系统接口的重要性与日俱增，但它自身比较复杂的业务逻辑，使得每次代码的变更都难以评估是否会影响到接口的功能，这使得我们开始在手工测试之外，去寻找更适合的回归测试方法来保障这些接口功能的正确性，也就催生了本次的接口自动化测试项目。

要做自动化测试，工具是必不可少的，但在大部分系统间接口从webservice转到dubbo之后，测试工作面临着一个难题，那就是没有针对dubbo接口的、现成的测试工具。之前针对http这种文本化协议的测试工具非常容易找到，但对于dubbo这种二进制协议由于各种各样的原因，基本上是找不到相同定位的工具的。

于是，我们先从工具入手，利用开源测试工具Jmeter提供的自定义协议接口，开发了一个dubbo协议的测试插件，实现了测试脚本（文本）与交互数据（二进制数据）之间的转换功能，使得快速编写和维护dubbo协议的测试脚本成为可能。

解决了测试工具的问题后，剩下的就是测试脚本的编写。我们对生产中核心业务系统各接口按调用量进行统计分析，最终选择73个接口（它们的调用量之和，占该系统接口总调用量90%）进行了测试脚本覆盖。每个接口按照白盒测试路径覆盖的原则设计了测试用例，确保测试脚本能够执行到大部分的系统功能。

最后，再利用操作系统的定时任务和自定义的报告与邮件功能，就构成了整体的执行与结果收集的框架。

目前整套系统以每日定时执行2次的方式在测试环境运行，基本可以实现在程序发布到测试环境的第一时间，在手工测试还未开展时就已经回归测试了一遍接口。

此外，由于在自动化测试工作中看到了dubbo测试工具的便利性，我们将开源工具中的自定义插件独立了出来，做成了一个可独立运行的dubbo接口文本化调用客户端，以此来帮助手工测试人员更好的测试dubbo接口。现在即使在调用方系统不可用时也能够单独测试dubbo接口的服务方了，而且测试人员在调接口时不用关心链接的建立与关闭，不用关心业务java bean的生成与释放，能够将更多的精力集中在测试数据的构造与准备上，相应的提高了测试的效率。