随着公司业务复杂度的增长,系统的数量也不断增加,系统间的交互变得更多也更频繁,系统间接口作为各系统交互的一个主要途径,其作用和地位也越来越重要。前两年咱们IT在架构与开发方面都做出了一定的成果以支持接口数量增长的需要。今年上半年,测试团队在接口质量保障方面也有所突破,完成了核心业务系统(dubbo接口)的自动化测试项目。
目前公司各系统接口众多,特别是核心业务系统,处于整个交互网络的中心位置,它提供了繁多的各类业务接口供其它系统调用。核心系统接口的重要性与日俱增,但它自身比较复杂的业务逻辑,使得每次代码的变更都难以评估是否会影响到接口的功能,这使得我们开始在手工测试之外,去寻找更适合的回归测试方法来保障这些接口功能的正确性,也就催生了本次的接口自动化测试项目。
要做自动化测试,工具是必不可少的,但在大部分系统间接口从webservice转到dubbo之后,测试工作面临着一个难题,那就是没有针对dubbo接口的、现成的测试工具。之前针对http这种文本化协议的测试工具非常容易找到,但对于dubbo这种二进制协议由于各种各样的原因,基本上是找不到相同定位的工具的。
于是,我们先从工具入手,利用开源测试工具Jmeter提供的自定义协议接口,开发了一个dubbo协议的测试插件,实现了测试脚本(文本)与交互数据(二进制数据)之间的转换功能,使得快速编写和维护dubbo协议的测试脚本成为可能。
解决了测试工具的问题后,剩下的就是测试脚本的编写。我们对生产中核心业务系统各接口按调用量进行统计分析,最终选择73个接口(它们的调用量之和,占该系统接口总调用量90%)进行了测试脚本覆盖。每个接口按照白盒测试路径覆盖的原则设计了测试用例,确保测试脚本能够执行到大部分的系统功能。
最后,再利用操作系统的定时任务和自定义的报告与邮件功能,就构成了整体的执行与结果收集的框架。
目前整套系统以每日定时执行2次的方式在测试环境运行,基本可以实现在程序发布到测试环境的第一时间,在手工测试还未开展时就已经回归测试了一遍接口。
此外,由于在自动化测试工作中看到了dubbo测试工具的便利性,我们将开源工具中的自定义插件独立了出来,做成了一个可独立运行的dubbo接口文本化调用客户端,以此来帮助手工测试人员更好的测试dubbo接口。现在即使在调用方系统不可用时也能够单独测试dubbo接口的服务方了,而且测试人员在调接口时不用关心链接的建立与关闭,不用关心业务java bean的生成与释放,能够将更多的精力集中在测试数据的构造与准备上,相应的提高了测试的效率。
领取专属 10元无门槛券
私享最新 技术干货