如何选择接口自动化测试工具

当你准备给自己所负责的项目搭建接口自动化测试时，面对市面上多种多样的工具或者框架，是否遇到不知该选哪个工具的困惑？本片文章通过对时下使用广泛的接口自动化工具进行对比来介绍自动化工具或者框架选择策略，协助处于困惑中的小伙伴选择适合项目的接口自动化工具。

在讲工具选择策略前，我们先思考一下这三个问题

搭建自动化的价值是什么？

覆盖接口的哪些内容？

如何降低接口自动化测试维护成本？

对于以上三个问题，你有自己的答案了么？以下是笔者对以上三个问题的思考。

搭建自动化的价值

搭建自动化的目的是覆盖全面且能快速反馈被测应用质量。想像一下对于一个功能复杂的系统，开发在上线前刚刚修复了几个bug，测试问开发影响范围，开发可能会说“不好说，都测试一遍吧”。如果你遇到这样的答案是不是要抓狂，实际项目中这样的情况不仅存在，而且可能还比较频繁。此时如果有个覆盖全面的自动化脚本该多好，让自动化脚本跑起来，茶水间喝杯咖啡回来就知道质量结果了。

接口覆盖策略

1. 系统自己使用的接口覆盖测试场景而不是单个接口的response。

比如一个更新用户个人信息的接口，试想一下如果是手动测试，你会如何做？肯定是在页面上更新某个信息或某几个信息，然后查看对应的数据字段是否更新或者页面是否显示新的内容。你会单独查看接口的response是否和需求文档一致么？大部分情况下都不会。所以在搭建接口自动化测试时建议覆盖测试场景以此保证业务功能是否正确。

2. 对外提供的接口重点检查接口的response body和response schema。

有些小伙伴读到这里是否会犯迷糊，第二点似乎和第一点矛盾了呢？实际不矛盾，对于对外的接口，因为接口使用方是第三方，对于第三方在哪些业务场景下如何使用该接口不是接口提供方的测试范畴，故接口提供方只需保证接口返回的内容与格式与之前定义的一致即可。

3. 只要提供接口的地方就尝试进行覆盖，保证接口测试足够全面。

降低维护成本策略

1.管理测试数据，保证测试case独立性。即每一个测试案例需要的测试数据在案例运行前自动准备，案例运行完后自动清理。任何用例的执行不依赖其他用例是否执行成功。

2.管理配置信息，保证多环境运行无障碍。即当测试环境切换后，能通过环境变量简单快速切换到所测环境，无需任何手动介入，相同的一套测试脚本DEV环境能运行，切换到UAT环境同样能全部正常运行。

3.已实现的自动化脚本能快速重用。例如一个系统有3个角色，已经完成了“初始化用户为系统任意角色”的测试脚本，假设此时新增了一个功能，此功能只有系统某个角色才能操作，那么在准备测试数据时就可以调用之前的代码快速初始化所需用户。

4.清晰的代码分层。让新上项目的人也能快速上手开始自动化脚本编写。

5.默认等待机制，解决数据延迟问题。例如调用一个接口到数据全部落入数据库需要时间，如果没有默认等待机制，调用接口后立刻查询数据库数据可能出现错误假象。对于微服务，这类问题可能更突出。

6.Retry机制，对于部分不稳定的接口，适当的retry机制可以保证自动化用例成功率。

7.管理接口reqeust body，接口的request body修改频繁，要尽量引入其他工具协助更好的维护接口的request body，否则接口body的任何修改可能都会引起自动化的大面积修改。

8.集成到CICD平台，定时运行持续优化。

9.详细的日志打印，流水线上清晰知道错误原因。

10.测试工具是否支持脚本语言，是否有完善的帮助文档，github上start数量，是否还在持续维护。

在思考和回答了上面的问题后我们再来看目前市面上使用较广泛的能实现接口自动化的工具或者语言。

接口测试工具对比

Postman/SoapUI/Jmeter：

这三个工具放在一起的原因是都属于配置类工具，简单易上手，利用该工具可以很快调通一个接口，后续再学习一下如何配置测试集、如何进行断言、如何配置全局变量等，基本就可以实现接口的半自动化了。但如果要搭建覆盖全面且较低维护成本的接口自动化脚本，有太多理由否定采用postman或者soapUI。比如：无法连接数据库准备测试数据，即无法实施“降低维护成本”中第一条策略，一旦测试环境中测试数据遭破坏，case就会运行失败。再比如接口的request body都是写死在用例里面，即无法实施“降低维护成本”的第七条策略，开发修改任何一个接口，都可能需要修改多个测试用例的reqeust body。

Groovy+Rest-Assured

Rest-assured是一款测试REST api的自动化测试工具，除支持接口调用外，还提供了接口校验、日志打印、错误显示等功能，非常适合接口自动化脚本。Rest-assured配合脚本语言groovy前面提到的10点降低维护成本策略都能实施。例如利用脚本语言groovy可以方便连接数据库准备测试数据，可以用csv文件管理测试数据，yaml文件管理配置信息，轻松对接口返回的json格式或者xml格式数据进行解析处理等等。

Java+Httpclient

Httpclient是apache common下的一个子项目，引入该jar包即可完成接口调用，相比与rest-assured这类专门的接口测试工具，httpClient不提供接口response校验、接口request、response打印、错误信息显示等功能，这些都需要自己单独写代码实现。

Python+Request

Request是python下的一个包，引入该包后即可完成接口调用，和httpclient一样该包仅仅完成接口调用，如果需要接口response的校验、日志打印等都需要自己单独写代码实现。相比与java+httpClient组合，这个组合使用了脚本语言python，就实现接口测试而言，学习python的成本要远低于学习java的成本。相比groovy+rest-assured组合，python语言官网没有提供配套的BDD一类的框架，所以选用该组合还需要配合其他测试框架一起服用才行。

Python+Pyresttest

Pyresttest是一款rest api测试工具，和groovy+rest-assured的组合很像，都选用脚本语言作为编程语言，选用专门的接口测试框架调用接口。Pyresttest在github上的start是900+，rest-asssured在github上的star是4000+，要相信群众的眼睛是雪亮的，所以一定要选择，那肯定还是选择groovy+rest-assured组合。当然如果你一定要用python语言，那可以深入研究下pyresttest是否可实施前面“降低维护成本”的十个策略，如果可以，那选它也是ok的。

结束语

对比上述工具旨在告诉大家在选择工具或者框架时，首先需要明确你的项目需要完成怎样的自动化，然后再查看市面上的工具，看看这些工具以及支持的语言是否满足你的需求，只要有了明确的目标，选择就不再困难。比如要搭建覆盖全面且较低维护成本的接口自动化，选择工具时首先需要考虑是否能轻松获取到接口response body和校验response schema，另外还需考虑能否实施“降低维护成本”中提到的10个策略，如果都能实施，那就用它了。

如果对如何使用rest-assured+groovy编写接口自动化脚本感兴趣的小伙伴可以订阅gitchat上“接口自动化实战” 专栏约。https://gitbook.cn/gitchat/column/5dbbe297e29af65d1d01b8fc