AutoTest我爱编程工作专题

接口自动化方案选型

2018-04-10  本文已影响262人  我为峰2014

what-接口是什么？

在计算机中，接口是计算机系统中两个独立的部件进行信息交换的共享边界。
举个例子，我提供加法的计算接口，你给我两个数，我就给你返回一个和。

what-什么是接口测试？

狭义的接口测试指的是对接口进行测试，上个例子中测试的是不同输入参数时，我加法的返回是否正确。一般讲的接口测试是这种。

广义的接口测试包含接口提供方、接口调用方的测试。
比如，你调用我的接口执行加法，我返回错误的响应，或者我响应超时，这时你的处理是否正确。

为什么要做接口测试？

一般做接口测试有如下原因：

How-怎么做接口测试？

接口测试实际上是黑盒测试（功能测试）

作为黑盒测试，基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑

做接口自动化有什么好处？

做接口自动化是为了节省人力成本而不是为了找bug。

减轻自己工作量

例如：回归测试等；

例如：篡改服务返回的数据验证前端对各种数据场景的处理，弱网模拟、特殊协议数据包解析验证等；

例如：数据层的存储过程、Package批量调用验证、接口自动化等偏底层的问题；

例如：接口层发现问题了，可以通过添加的traceID定位到日志错误或错误代码行，

例如，测试和运维的工作可能存在交集，我们不能把质量问题寄托于他人，一旦发现问题，立即报警通知到人，让损失到最小。

例如，测试环境的自动化编译、打包、部署、持续集成甚至持续交付等。

关于自动化介入的若干问题

是否要考虑成本？ 当然要考虑，我们总会遇到在成本和质量之间找平衡点，可能一些特殊的行业，特殊的项目，质量的权重更高点，如果引入自动化能提高质量，该介入的还是要介入。

是不是只有大公司能做， 小公司和初创公司就不适合搞自动化？这不是绝对的，还是要看公司的资源和人员配备，如果有能力做为什么不？况且小公司的自动化不一定要做到大公司的程度，只要能提高工作效率，提高质量就可以，滴水穿石，聚沙成塔。

自动化何时介入？ 条件许可的还是尽早介入，越是底层的Bug，影响面越广，修复成本也是最低的。但这不是硬性标准，一般公司都是从接口自动化开始积累经验的，拔苗不能助长。

如何开展自动化工作

抓住业务测试工作中的痛点和领导的痛点，多沟通多交流，优先解决基层的工作痛点，

技术选型和方案可行性调研，多投入时间和精力，有的人性子急，前期做的很快，如果一开始的方向错了，最终会得不偿失；
如果是比较复杂的解决方案，尽量前后端分离、保证各模块的独立性、可融合性、解耦不解体，做到灵活可扩展。

接口自动化需要的功能

1、校验（断言）
这个很好了解，如果没有校验，单纯的执行接口的话，那就谈不上测试了。所以支持对返回值校验是一个必须的功能。

2、数据隔离
数据隔离就是指具体的请求接口、参数、校验等数据做到与代码相隔离，便于维护，一旦需要调整接口用例、新增接口用例时可很快速的找到位置，隔离的另一个好处就是可复用，框架可以推广给其他团队，使用者可以使用相同的代码，只需要根据要求填写各自用例即可测试起来。

3、数据传递
做到数据隔离可维护后，数据传递是另外一个更重要的需求。
数据传递是指接口用例之间可以做到向下传参，例如我们通过创建订单接口创建一个订单，该接口会返回一个订单号，接下来我们要进行调用查询订单的接口，从返回的数据中与创建订单用例中的数据进行校验，此时第二个接口的请求数据是需要从第一个接口用例中的返回中提取的。这样的例子比比皆是，所以支持数据传递是又一个必不可少的功能。

4、动态函数
实际用例场景中我们可能会有随机生成一个手机号、字符串加密等需求，在数据与代码隔离之后，此时我们就需要代码可以支持做到识别对应关键字时可以执行对应的函数进行填充。例如在数据中填写phone()时，具体执行时会被替换成137XXXXXXXX，填写random(5)时，会被替换成一个五位的随机数。等等。

5、可配置
有时，我们的需求是用例不单单只能在一个环境上执行，可能需要同一份接口用例可以在QA、预发、线上等多个环境都可以执行。所以框架需要做到可配置，便于切换，调用不同的配置文件可以在不同的环境执行。

6、日志
日志包含执行的具体执行接口、请求方式、请求参数、返回值、校验接口、请求时间、耗时等关键信息，日志的好处一来是可以便于在新增用例有问题时快速定位出哪里填写有问题，二来是发现bug时方便向开发反馈提供数据，开发可以从触发时间以及参数等信息快速定位到问题所在。

7、可视化报告
用例执行后，就是到了向团队展示结果的时候了，一个可视化的报告可以便于团队成员了解到每次自动化接口用例执行的成功数、失败数等数据。

测试工具（框架）脱离业务使用场景都是耍流氓！所以我们不妨先来看下日常工作中的一些常见场景。

流程

接口测试的根源就是从接口文档开始的，接口文档中的参数贯穿了整个接口测试测生命周期。

API接口在设计时往往需要编写大量的文档，而且编写完成之后还会经常改动，文档编写维护工作量大。接口文档编写好后，实际的代码可能会与文档有出入，这个时候文档是不准确的，文档与代码保持修改同步也是一个很大的工作量。随着接口版本的迭代，接口文档需要同步更新，所以很多开发甚至都不去编写接口文档，项目小还好办，当项目大了，需要对接的地方多了，就会很麻烦。特别是接口数量多，参数复杂的情况，测试工作量大。接口在版本迭代后，旧的接口常常需要做回归测试，这个工作量也是非常大的。

解决思路

API接口管理系统化或平台化，可以直接在可视化API管理界面上方便的维护接口。而且最好有版本管理和权限管理。可视化维护好的接口可以直接生成对应语言的代码，节省代码开发量。

代码有变更时，最好还可以与界面上的接口进行同步。API界面能够提供模拟接口实现方的调用功能，这样就能解耦接口调用方与服务方的强进度依赖，可以先按API接口的消费方基于接口管理系统或平台模拟调用，待服务方准备好后再真实调用（mock）。而且这里的模拟最好能做到自定义规则的模拟返回。接口实际开发完成后，可以根据接口管理系统或平台的可视化测试界面，直接进行接口的实际调用测试。

附加点：接口平台能够支持自动化测试，可以自定义测试案例，然后自动化测试并生成可视化报告。这个功能在旧版本接口复测时非常有用。

国内解决方案

EasyAPI

这是一家国内的在线API管理平台，提供API管理、API测试、API监控、API文档管理的综合性API服务。在前面提到的解决思路上额外还提供了API监控的功能。另外平台在一定使用人数下提供免费服务。

eoLinker

这是一家国内的在线API管理平台，同时也提供开源精简版本。该平台提供的功能非常全面，除了代码生成与同步这个功能外，基本涵盖了前面提到的解决思路中的所有功能。

DOClever

这是国内一家在线API接口管理平台,完全开源免费；该平台的功能十分全面，也十分完善；拥有根据业务场景进行接口自动化测试、API管理、API文档管理、团队协作、版本快照与回滚、Mock无缝对接、状态码管理等；可以说是现阶段国内接口管理平台中功能做的最好最完善的一家；产品更新迭代比较频繁

RAP

这是阿里巴巴公司的团队做的一个开源的API管理系统，功能也还比较全面。除了没有代码生成与同步、自动化测试、状态码管理功能，解决思路中提到的功能基本都有。
RAP的应用范围非常明确，是一个面向开发人员自测和联调的工具性平台，它更适合以开发为核心对接口进行维护，但目前基本不在维护

CrapApi

这是国内的一个开源的API管理系统，提供了文档管理、项目/组织管理相关的功能，在测试管理与代码管理这块是缺失的。

国外解决方案

SwaggerHub

这是国外的一个非常有名的基于Swagger的一个在线平台，提供了API全生命周期管理的工具集，基本涵盖了解决思路中提到的全部功能。Swagger是一个开源的设计与描述Rest API的框架，它有自定义的接口规范和很多非常实用的工具集，比如Swagger Editor可以用来设计接口，Swagger Codegen可以用来生成代码和测试桩，Swagger UI可以用来生成可视化接口文档等。

Swagger更多的是用在开发的层面上，Swagger的学习和接入成本相对较高，需要开发与测试的深入配合

Apiary

这是Oracle公司收购的一家API管理的公司，也是一个在线的API管理平台，除了代码生成功能，基本提供了解决思路中提到的所有功能。它有自己定义的接口描述语言API Blueprint。
这个也是一个基于Swagger的在线API管理平台，可以做接口管理、接口模拟测试。整体的功能相对比较简单。

从设计上来说，国外的Swagger和apiary都有统一的开源接口规范，这样就有了搭建生态的前提，然后创建对应的工具集就会非常实用有效。这里相比而言Swagger的生态又更加成熟些。

从功能完备度或商业化程度上来说，国内的EasyAPI、eoLinker、DOClever、RAP，国外的Swagger、apiary都还不错；

其中以DOClever、Swagger最为突出。综合比较下来，
Swagger是在API管理这方面做得最好的，商用的话eoLinker和EasyAPI都可以考虑，如果考虑到成本或者需要开源的系统，那DOClever系统不错。当然实际需求不同公司是千差万别的，最适合的才是最好的，至于哪个更适合就需要自己根据实际情况去比较了

EasyAPI eoLinker DOClever RAP CrapApi SwaggerHub Apiary
版本管理和权限管理，文档管理 ✔ ✔ ✔ ✔ ✔ ✔ ✔
可视化接口编辑管理 ✔ ✔ ✔ ✔ ✔ ✔ ✔
是否支持 mock ✔ ✔ ✔ ✔ ✔ ✔ ✔
接口调试运行生成代码 ✔ ✘ ✔ ✘ ✘ ✔ ✔
数据导入/导出 ✔ ✔ ✔ ✔ ✔ ✔ ✔
团队协作功能 ✔ ✔ ✔ ✔ ✔ ✔ ✔
是否开源 ✘ ✘ ✔ ✔ ✔ ✔ ✔

API测试的工具

Postman

有Mac, Windows, Linux, and Chrome 各平台对应的软件，可以支持API接口的记录和测试。另外也支持接口的文档化与监控。

Soapui

自称是最好的REST & SOAP 测试工具，跟Swagger一样都是smartbear这个公司做的产品。可以支持做接口的功能测试、压力测试、安全测试、模拟测试。-------商业收费

还有就是开发自己的debug接口

接口自动化框架

让“自动化”代替“手动”

在我看来，初期的自动化测试，目标很明确，就是要让“自动化”代替“手动”，让自动化真正地跑起来，凡是“自动化”跑过的内容，尽量不要用手工重复执行一遍。这样至少有一个很明确的收益：每完成一条自动化用例，就减少了一条手工用例的执行时间。

必须要提醒的是，让“自动化”完全替代“手动”，其实对自动化用例的稳定性、容错都有一定的要求。需要花一定时间去思考用例执行过程中的异常场景，是否足以充分替代手工测试。

让“回归”自动化

让每次回归或上线验证“不得不”执行的用例优先自动化进行收益最大化。如果完成了回归用例集的全部自动化，就可以用它来替代版本的日常回归，和上线回归工作，极大地释放手工验证时间。

我们的调度项目其实是一个对系统稳定性的要求比较高的后台项目，所以它的核心功能是比较固定的，核心功能聚合、对系统的稳定性要求高。这就需要保障系统的核心功能完善。所以我们可以先将“核心功能”的验证完成自动化。

让“自动化”持续进行

自动化是一个持续的过程，我们会不断的加入新的用例来完善自动化的过程，所以，发展了持续集成CI，通过对自动化的持续集成，我们也可以对自动化过程的质量进行监控。

持续集成的优点

使用自部署CI（Jenkins）能对构建环境有完全的控制权，够得到完全的定制性，使得效率最高，但需要花费很多的精力来搭建环境和配置，尤其是当规模变大了之后，想要优化资源的配置，需要花费更大的精力。

使用云CI（阿里云持续交付平台CRP），在基本上不用自己去配置相应的环境------商业软件，它就可以能够满足大多数场景的需求，但是对构建环境缺乏控制权，构建环境也非完全定制化的，所以很难保证效率最高。

技术选型

在明确了目标后，要开始技术选型。常见的自动化测试类型，包括

接口自动化

UI自动化

基于shell交互命令执行的自动化

此外，不属于测试范畴，但是也可以实现自动化、释放手工时间的还有
1.数据准备自动化
2.环境编译、部署、打包自动化
3.稳定性测试/性能测试结果指标获取、校验自动化
4.机器资源监控、报警自动化
5.其它所有手工重复执行的操作

在开始自动化之前，首先要分析项目的架构和状况。对于一个后端的服务，它如果是纯粹以接口的形式提供给其它组件去调用，那可以采取“接口自动化”；对于一个Web产品，如果前后端都在测试的保障范围，而且前端页面相对比较稳定，可以考虑采用“UI自动化”（此时接口自动化其实已经不足以保障产品的端到端功能）；对于更后端的组件，如果想测试组件自身的基础核心功能，可以采用“基于shell交互命令执行的自动化”，通过自动化脚本的方式封装shell命令的调用。

此外，还需要对编程语言的选择，是用Java还是Python还是Shell，或者其它语言等等。这个我觉得其实没有定论，可以根据自己对语言的偏好和熟练程度，但是必须要考虑团队成员的普遍技术栈，因为后期可能其他人来接手这个项目时需要代替你去维护测试工程。通常来说，测试框架的选择（不管是接口自动化、UI自动化）推荐使用Java的TestNG框架；对于简单的基于命令行执行的自动化脚本的编写推荐使用Shell（Shell非常地强大）；对于稍复杂的一些自动化的脚本的编写，推荐使用Python，在Python中可以非常方便地封装Shell命令，同时Python区别于Shell的一个特性就是它支持面向对象的封装，可以将一些对象封装在特定的类中，增加程序的可读性和健壮性。

编写代码的方式：

优点：提升自己的编码能力，问题定位能力，具备更高的灵活性和可操作性。
缺点：结果展示不直观，不易于协作。其他人维护代码困难，难以推动开发执行。

接口平台的方式：

优点：简便，上手容易，可以在项目组间很好的协作和维护，测试记录和结果一目了然。
缺点：离开了平台，可能又要回归手动。

建议使用接口平台加编写代码的模式来实现接口自动化

对于测试人员而言，如果有精力和时间的话，我建议是两种都要掌握，甚至是自己去开发接口测试平台的能力。

分割线------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Jmeter+Ant/Mavan+Jenkins

jmeter工具特征，jmeter是以线程请求为单位，不是以脚本或测试用例为单位，既然这样，就可以每次循环获取接口或对应数据进行测试了，
而且jmeter有可视化界面，我们只需要调用它的逻辑处理器，基本上可以帮助我们解决大部分问题。jmeter是由java开发并且开源的，我们可以根据自身情况对jmeter的函数做定制，和二次开发。

参考：https://testerhome.com/topics/10160

image.png

Robotframwork+Requests+Jenkins

Robotframwork在业界也算是大名鼎鼎了，是一款通用型自动化框架，也被称为关键字框架，主要使用就是在于封装关键字，然后进行调用，

Robotframwork是使用Python来开发的，对测试的学习来说是非常友好的。使用Robotframwork来进行接口自动化的话，主要是通过Python的一个库Requests，来对接口进行请求，当然，我也可以对它进行二次开发，封装我们自己需要的关键字。

参考：https://testerhome.com/topics/5596

TestNG+Ant/Maven+Jenkins

TestNG是一个设计用来简化广泛的测试需求的测试框架，从单元测试（隔离测试一个类）到集成测试（测试由有多个类多个包甚至多个外部框架组成的整个系统，会用在开发的单元测试比较多，主要写的话是使用XML格式把用例关联起来，需要比较深入了解代码，

Hitchhiker

Hitchhiker 是一款开源的 Restful Api 测试工具，支持Schedule, 数据对比，压力测试，支持上传脚本定制请求，可以轻松部署到本地，和你的team成员一起管理Api

功能

Func Hitchhiker Postman DOClever
协作性 ✔ 通过Share，Pro收费 ✔
脚本 ✔ 强，可以上传脚本 ✔ 一般，只能用内置的脚本库 ✔ 一般，只能用内置的函数
Schedule ✔ ✔ 需要借助Newman, Jenkins ✔
数据对比 ✔ ✘ ✔
压力测试 ✔ ✘ ✘
参数化请求 ✔ ✘ ✔
文档 ✘ 模板化的文档在计划中 ✔ 固定格式 ✔ 文档多样话
Api Mock ✘ ✔ ✔
细节，稳定性 一般，待加强 强 持续更新
安全性 本地部署 数据上传 本地部署

参考：http://doc.hitchhiker-api.com/cn/

HttpRunner

HttpRunner 是一款面向 HTTP(S) 协议的通用测试框架，只需编写维护一份 YAML/JSON 脚本，即可实现自动化测试、性能测试、线上监控、持续集成等多种测试需求。

因为后台做了大量工作，因此我们只需要维护少量的json数据，工作量减少，效率提高。

灵活性：可根据自己需要，定义合适的方法或者数据缓存机制。

httprunner也提供了基于locust的性能测试，可根据需要直接运行json文件即可！

同时，最重要的是，测试用例和代码的分离。这样使得稍有编码功底的人迅速上手。

接口用例可通过har文件录制转换得到，也可自己定义.

image.png

核心特性

参考：http://cn.httprunner.org/

自己研发

Rest-Assured

上一篇下一篇

猜你喜欢

热点阅读