接口测试与服务虚拟化

Posted 2021-04-24 晨小菜

什么是接口测试?

       

前几年当我们提自动化测试时，很多时候是指UI界面层的自动化测试。但是近年来随着分层自动化测试（图1）概念的兴起以及自动化测试自身的发展与细分，自动化测试有了更多的内容。比如本文即将要谈到的接口自动化测试，就是其中一种。

   

                 图1：分层自动化测试

        

接口测试并没有一个标准的定义，老外的文章也较少提"Interface Testing"这个词，一般见到比较多的是"API Testing"。我们从百度百科可以查到，“接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等”。这几年随着微服务架构的流行与发展，在接口测试领域又蹦出了一个词，叫“契约测试”（Consumer-DrivenContracts Testing，简称CDC Testing）。但是正所谓万变不离其宗，无论如何称呼，始终都是围绕着系统与系统之间，接口与接口之间逻辑的正确性来开展测试，所以也是属于接口测试的一种。

 很多人一谈到接口自动化测试，首当其冲就想到SoapUI，Postmon或者JMeter等接口自动化测试工具。诚然，这些工具都是属于接口自动化测试的利器，解决了模拟客户端向服务端发请求并且校验结果的功能。但是在笔者看来，这些还不是接口自动化测试的全部内涵。让我们再回顾接口测试的定义，接口测试是测试系统组件间接口的一种测试，言下之意也就是说不仅要模拟客户端组件测服务端功能，也要模拟服务端组件测客户端功能，只有双向都能进行测试，才是完整“接口测试”的含义。而对于模拟服务端，我们有一个高大上的术语，叫“服务虚拟化”，在老外的文章中经常会看到这个词的英文翻译叫：“Service Virtualization”。

 

什么是服务虚拟化？

笔者最早接触服务虚拟化这个词，是在2013年左右。当时IBM收购了英国一家专门做接口测试工具的厂商叫“Green Hat”（这家公司在欧美很成功，四五十人的团队每年的营业额却能达到几千万美元）。由于Green Hat的中文翻译有点令人尴尬，所以IBM索性改名为Rational Integration Tester，同时还配套推出了一本电子书叫“Service Virtualization for Dummies”。这本书有六七十页，很系统的讲了服务虚拟化的知识。

那么，究竟什么是服务虚拟化呢？服务虚拟化是指通过录制或构造建模的方式产生服务仿真模块（图2），从而配合客户端组件进行功能测试。看到这里可能有人会说，这不就是桩（Stub）吗？我让开发人员码一个出来不就行了？确实，生成桩是结果，但是请注意生成桩的过程，服务虚拟化是通过录制或构造建模生成桩，而不是要靠开发人员大量编码来生成。设想，要是一个复杂系统有上百的不同协议不同报文格式的接口，开发人员一个个开发，那是何等大的开发量！

                    图2：服务虚拟化

       

服务虚拟化的价值

那么服务虚拟化究竟有什么价值呢？笔者认为主要有以下几点：

1. 节省建设测试环境的费用

 

大家知道，我们的测试环境一般有几套，像常见的集成测试环境、系统测试环境、系统集成测试环境等等；如果这些环境所需的硬件资源要求不高则罢，若是要求很高的话是很难为每套环境都配置资源的。比如银行corebanking有不少是用IBM system Z大机，这种一台动辄上亿投入的硬件，是根本不可能会随便能配几套做测试环境的。很多时候当进行前期的测试时如果需要跟核心系统联调的话，势必会存在资源不足的情况。这种情况下，如果能把核心系统的接口服务进行虚拟化，那么测试的过程则不必需要真的去调真正的接口，但同时也能使得整个交易的测试过程进行下去。这样就可以在前期测试阶段减少了大量的投入。

另外一个方面是关于第三方测试环境，比如大家知道万事达信用卡。如果您是作为银行系统的测试人员，要想随时和万事达接口联调是很困难的，而且每个月你还必须为联调测试环境附上一笔不菲的租赁费用。那么我们其实也可以利用服务虚拟化技术，在测试前期通过和虚拟服务桩的测试，确保早点完成业务交易测试过程，从而节省了第三方测试license的费用。

2. 缩减环境建设时间

        

在整个测试过程中，测试环境的搭建是非常花费时间的。据业界统计，大概有40%的测试时间都花在环境搭建上面。我们如果在前期测试阶段的环境中某些子系统或者组件利用服务虚拟化的技术，简单的生成可测试的桩，这样不仅能保证测试的业务流程不会阻塞，还能大大简化整个测试环境的搭建时间，给项目带来非常大的帮助。

3. 降低风险

      

我们在做系统联调测试的时候最怕的就是那种所谓的“Big-Bang Testing”，也就是在测试的前面阶段由于环境不具备、对端接口没完成等各种环境问题导致测试人员在不停的等待，直到所有的环境接口都开发完后而测试时间所剩无几的情况下再进行测试。这时的情况就像定时炸弹一样随时都有可能爆炸。为了避免“Big-Bang Testing”，就需要我们在前期阶段就开始测试，这时需要通过服务虚拟化，先对自己的接口模块进行自测，尽早发现问题并且尽早解决，从而降低了项目的质量风险。

 

服务虚拟化的局限

任何事情都有两面性，前面谈了服务虚拟化这么多好处，当然它也是有局限性的，比如它就不是很适合在用户验收测试阶段。因为用户验收测试阶段已经到了测试尾声阶段，这时需要在最接近生产系统的环境进行测试，而如果还用假的服务来测试当然会影响到结果的正确性。所以服务虚拟化最佳的适用测试阶段应该是单元测试、集成测试、接口联调等测试前期阶段。

 

接口测试工具

现在一般开源的接口测试工具只能解决模拟客户端测服务端的单向接口测试，而能做到模拟服务端提供服务虚拟化能力的开源工具几乎没有。具有双向测试能力的工具基本上都是商业工具，比如CA的Lisa，IBM的Rational Integration Tester（图3），惠普（现在被MicroFocus收购），Parasoft，Smartbear等。

            图3：IBM Rational Integration Tester架构图

抛开商业开源之分，单从技术上来说，什么样的接口测试工具是好的测试工具？笔者认为好的接口测试工具必须具备以下几个条件：

1. 能一个工具同时支持双向测试过程。也就是即能模拟客户端，也能模拟服务端。

从这点看，大部分的开源接口测试工具功能都太有限。而其实即使是惠普的接口测试工具，也是客户端和服务端分开成两个工具（至少在2016年前是这样）。这样会给测试人员带来很大的不便，同时也不能充分利用录制或构建一次测试报文可以同时给双向的测试用例使用。

在客户端接口自动化测试功能方面：

        * 需要支持正则表达式；

        * 需要支持实际测试结果与预期结果自动比较，自动告知成功/失败，同时自动高亮显示失败的行数，杜绝人肉观察的情况；

        * 需要支持复杂逻辑，比如分支、循环、判断、会话连接和参数传递

        * 需要可扩展功能，支持自定义函数；

 

在服务端虚拟化功能方面：

       * 需要能根据不同的请求返回不同的结果；

       * 需要支持复杂逻辑，比如分支、循环、判断、会话连接和参数传递

       * 需要能支持多并发，多用户同时使用

        * 需要能支持桩的定时起停；

       * 需要能支持CI持续集成和DevOps

 

2. 支持越多的通讯协议、消息报文和行业标准

         

接口自动化测试工具的强大与否，很重要的一点就是能否支持更多的协议、报文和标准。如果不能支持协议，通讯就好像鸡同鸭讲；如果不能支持报文格式，就好像获取了天书，根本不知道里面是什么内容，也就无法进行正确的解析。至少工具需要对业界流行的协议、报文和标准支持，才能更加方便的让测试人员使用一个工具能进行更多的接口自动化测试。比如:

Web方面：Http/Https、Webservice，Soap等；

中间件方面：WebSphere、WebLogic、Tomcat等

消息中间件方面：MQ、Tuxedo等；

传输方面：FTP、TCP等；                          

数据库方面：Oracle、DB2等；

报文格式方面：XML、Json、Stream等；

行业标准方面：Fix、Swift、银联ISO8582等

 

总结

接口测试一般是在集成测试阶段进行，很多时候都是在没有界面的环境下进行测试，所以借助接口测试工具来进行测试是一个比较合适的方式。当然，在选择接口测试工具的时候最关键的还是要根据实际情况来选择，商业的工具功能强大操作方便但是贵；开源的工具功能较弱但是免费，针无两头尖。如果只是简单的接口，找个开源工具进行测试，又何必非得花钱买商业工具杀鸡用牛刀呢？