接口测试_米么接口测试框架探索之路

前言

米么是一家发展迅速的年轻公司，随着业务的迅速扩展，公司的技术架构也在不断更新和成熟中。相应的，对于测试同学的要求也越来越高，如何在不同的阶段选择合适的测试框架，从技术层面推动测试效率和开发提测质量的提高，是我们一直在思考的事情。

存在的挑战

1. 目前公司后台这块采用的是基于Dubbo的微服务架构，前后端实现了完全的分离。很多需求都是接口先行，这要求测试人员能够进行比较深入的接口测试。

 2. 测试团队的组成以功能测试人员为主，技术基础相对薄弱。而且测试团队分隔两地，前后端测试基本上都是分开的，联调和回归中的沟通成本较大。

技术选型

技术选型上我们的思路是从易到难，逐步推进。鉴于我们测试团队一开始主要以业务测试人员为主，大部分人没有什么代码经验，所以我们的目光投向了市面上比较流行的几套开源框架，譬如Fitness, Cucumber和Robot Framework等等。其中Fitness是一个轻量级的开源框架，支持多语言，和Wiki可以进行结合，但是测试脚本需要自己写代码，而且我们的用例也不是在Wiki上进行维护，首先排除。

接下来就是Cucumber和Robot Framework 二选一了，这两个框架对比如下：

综合比较下来，我们最终选择了Robot Framework作为我们的第一套开源框架。主要原因还是基于关键字驱动，上手程度低，同时提供了RIDE界面，操作起来比较简便

 Robot Framework实践

Robot Framework有比较完善的教程，但是它的内置关键字不能完全满足我们的要求。鉴于公司的接口分为HTTP接口和DUBBO接口两种，所以我们开发了一些底层的jar包来实现对于这两种接口的调用，Robot Framework的自定义关键字我们使用Python来编写，引用Jpype库调用jar包中提供的方法。具体的结构如下：

推行了一段时间，取得了如下成果：

 1. 推广迅速：经过若干次培训，业务测试人员基本都可以快速上手。图形化界面操作，上手快，成本低，case的可读性强。

 2. 提高了接口测试的覆盖率: 不仅可以对接口本身进行测试，也可以串联接口从后端进行部分E2E场景的测试。

3. 进行了简单的持续集成：挑选了BVT Case集成到Jenkins里面去，发布新版本的时候，如果有用例运行失败，说明主要逻辑分支有问题，该版本不是一个可测版本，直接打回。

但是使用开源框架也存在着诸多的问题：

1. 由于我们是使用Jpype来实现Python脚本对于Java的调用，所以无可避免的在类型转化过程中需要大量的定制化函数来进行处理，另外部分Python脚本本身运行良好，但是作为关键字在Robot Framework里面调用，偶尔会出现莫名其妙的编码问题。Robot Framework提供的日志信息比较有限，不容易定位。

 2. Robot Framework对于输入参数有一些自己的处理，导致参数中包含了一些特殊符号的情况时，不能正确识别，这些都需要自定义关键字来处理，导致我们的自定义关键字比预期要庞大了许多。写Case的人员需要对这些关键字都非常熟悉，提高了使用成本。

3. 接口很多前置条件的设置，也需要开发脚本来实现。譬如对于消息队列的处理，使用Java可以很快的实现，但是Jpype对于spring的支持不是很强大，导致用Python脚本来调用的时候，始终各种报错，类似问题耗费了大量时间。

4. 跨系统调用的场景，Robot Framework支持的不好。目录结构的管理不是很灵活，无法像TestNG那种以Group依赖的方式来运行链路比较长的E2E case。

5. 扩展性差。Robot Framework自成一套体系，无法对已有的用例进行资源的重复利用。如一些测试数据的生成,需要跑一个比较长的E2E case才能生成，鉴于上面第四点，我们往往只能另外又搭建一套测试工具，来生成和删除各种测试数据；压测Dubbo接口的时候，需要在Jmeter里自定义Java Sample Request,  这个时候需要把Robot Framework已有的Case用Java再写一遍，属于重复劳动。

 6. 功能Case和自动化Case无法对应。导致测试人员需要同时维护两套Case，维护成本高。

开发新框架

鉴于Robot Framework使用过程中出现的种种局限，我们组建了自动化组，重新搭建了一套后端框架。这套框架采用Spring+Mybatis+Maven+TestNG搭建，直接从代码层面调用应用服务, 类似于不同开发项目之间的调用。拿Dubbo接口来说，我们用Robot Framework的时候，是使用泛化引用的方式，然后还要写Python脚本来调用这个jar包，再把这个Python脚本转变成自定义关键字，才能在Case里使用，十分麻烦；现在我们直接在Spring配置文件里加上Dubbo接口的注册信息，即可在用例里直接调用。

自己搭框架的好处如下：

 1. Case即文档。大部分业务Case的生命周期其实都很短，需要不停的投入人力进行维护。我们有了这套新的框架之后，只要在里面做好注释工作，那么相当于将文字Case和自动化用例结合起来了，长期来讲只需要维护一套即可。

2. TestNG支持Group之间的依赖，这对于跨系统之间的长链路E2E Case的实现就不成问题。同时测试开发都使用Java，技术实现上不存在跨语言调用的问题。

3. 可复用性强。首先测试数据的构造，都可以通过跑接口集成场景的用例来实现，不需要再额外开发工具。其次压测Dubbo接口的脚本，可以直接拿现有框架中的Case来改造扩展为Java Sample Request，省时省力。

4. 更便于持续集成。TestNG是支持XML格式来运行的，我们可以在XML里定义不同的Test Suite来满足不同测试环境，跑不同颗粒度的Case来达到持续集成的目的。Test Suite里面的具体用例是可以灵活定义的，指定对应位置即可，相对Robot Framework的目录式结构要灵活很多。譬如刚开始提测，Jenkins里面集成的是BVT Case，如果全部通过，那说明是可测版本，如果有用例失败，那么大概率说明主要逻辑有问题，该版本不可测；在验收和回归环境，由于已经经过比较详细的测试，可以集成比较全面的集成场景，相当于一轮后端的全量回归。

5. 维护成本低。这套框架在第一轮测试的时候，写Case的时间比较长，门槛比较高，但是后面各轮测试，基本上只需要跑代码就可以了。直接写代码另一个好处就是非常灵活，可以进行各种封装，减少代码耦合度，公共的步骤都可以最大范围的进行复用，而且可读性强。后续各个迭代，除非接口契约改变，或者是进行整体的重构，这套Case不需要进行大批量的改动。而且由于我们这套框架是Java Project，开发自己也可以维护，因此可以在部分项目上（测试场景不复杂，现有自动化用例基本都已经涵盖到）实现开发自测，降低人力成本。

6. 更有利于团队成员技术水平的提高。业务条线上的测试，可以通过测试代码入手，熟练以后，辅以各种相关的培训，更有利于提高测试人员的技术水平，同时Case直接转换成代码，相对于关键字驱动那种描述性Case，也会更有成就感。

新的框架最大的问题在于门槛提高了，Case不再是描述性的，而是需要自己写测试代码，培训成本比较高，但是这套东西推出来以后，好处还是很明显的，前期有一些成本是可以接受的。现在我们采用的方式是自动化组的人帮忙来写一些重点项目的Case，然后进行培训，逐步移交给功能测试人员，一个项目一个项目的推广。

未来

目前我们是采取两套框架并行的机制。公司一些业务中心的项目相对来讲比较独立，基本都是Http接口，对其他系统的依赖也比较少。这种项目我们还是继续使用Robot Framework。对于一些纯后端的项目，有多个接入方调用的系统，譬如金融相关，我们采用新的集成框架来提高后端接口测试的深度和覆盖率。对于不同的框架，其实没有高低之分，更多的还是从实用性的角度来考虑，更适合项目的才是更好的。当然本文探讨的主要还是基于业务覆盖层面进行的接口测试，对于后端测试的其他方面，譬如怎样进行破坏性测试来验证服务的稳定性和容错能力，我们还需要进行持续的探索，任重而道远。