自动化测试系列（三）--实战：选择适合你的接口自动化测试工具

导读

上一篇已经跟大家讨论了自动化测试的分层理论，这一篇给大家换换胃口。老说理论大家肯定会想睡觉，天天实战大家也会觉得吃不饱。因此，这个系列后边会理论和实践穿插，把鄙人自己肚子的那点东西拿出来，跟大家一块讨论吧，欢迎留言！
说到接口自动化测试工具，想必做web测试的TX们肯定不会陌生，接口自动化测试是产品测试走向成熟之路的必经阶段，因此，现在有很多开源或者商业的工具供大家选择，那么如何选择适合自己或者是自己团队的工具呢？这一篇咱们就来掰扯掰扯吧。

适合自己的才是最好的

经常看到有些文章要评出哪一个接口自动化测试工具是最好用的。首先，我很感激有这些小伙伴能把这些经验总结出来分享给大家，这对正在选工具的TX来说是极好的，可以帮助有需求的小伙伴走出混沌之潭，走向光明之路。但是，对不同的读者来讲，我还是要告诫大家，你走的路虽然是光明之路，但也有可能比较坎坷。为什么这么说呢？不是说这个工具不好，而是说你需要根据你所处的情形去选择工具，而不是茫然的根据工具哪个最潮流、最好用去决断我是不是要去用它。适合自己的才是最好的，下面我会跟大家从两个维度去讨论如何选择自动化测试工具。

• 工具的门槛级别
  这里指的门槛主要是指编程能力，因为很多工具用例的实现需要小伙伴们具备编程能力。要选择接口自动化测试工具，我们首先应该确认我们现在的能力以及我们的团队能力。下面一块来看一下吧：

1. 不需要编程经验，纯工具类（此处不含二次开发）：Postman、Swagger等。像这两类工具用起来比较简单，可以说是手动的自动化测试工具。Postman不用多说，想必大家会经常去用。Swagger其实主要是用来写接口文档的工具，但是小伙伴可以直接通过接口所在的页面触发，比较方便，适合开发调试接口。总的来说，这类工具主要适用系统端测试人员或者是开发人员做简单的接口积累、校验和调试，上手很快，适合测试团队大都不具备编程能力，刚引入接口测试或者只是作为日常的接口校验。这类工具本身的灵活性不够强，适合单一场景测试，无法通过处理返回结果引入业务场景。比如说我要查看网站的个人信息需要先调用登录接口拿到token，再调用查看个人信息接口并带上token，而且token是每次需要重新获取的，因为有时效性。像类似的场景，使用此类工具就力不从心。
2. 需要一定的编程经验：Jmeter、Roberframework等。我所说的一定的编程经验实际上是相对于两类职责。对开发自动化测试用例的TX来讲，其实不需要具备高水平的编程能力，只需要有一定的编程基础即可，比如变量的定义、变量类型的转换等等，因为这一部分在编写测试用例的过程当中是常用的。另一类就是指自动化测试架构师，也可以说是自动化测试工具的支持人员，这类职责就需要有较高水平的编程能力，因为涉及到一些通用功能的实现，对于RF来说就是关键字，对于Jmeter可能涉及到一些插件。总体来说，这类工具用的团队比较多，就是因为它们具备较高的灵活性，而且对开发用例的人来说门槛相对也不是很高。因此，追捧的人就比较多。但是，对一些特殊的业务或者产品来讲，它们的灵活度还是达不到团队的要求。比如说一种通信产品中模拟打电话，整个流程需要开启多个终端启动相关的测试设备，并且整个功能需要在不同的终端中按顺序执行不同的命令并查看命令执行的结果。类似这种特殊的需求，如果用RF实现起来可能就没那么简单，但是用贝尔实验室开发的EXPECT脚本就比较方便。
3. 纯撸代码：此类工具不用多说，需要开发用例的小伙伴具备较高的编程能力，通过集成不同的工具包或者是使用原生工具完成接口自动化测试用例的开发。比如说TestNG、Python+Unittest+Request等等。但是，虽然门槛高，框架的灵活性也相对来讲是最高的，像现在很多大厂以及技术型的公司采用自研工具的比较多，因为他们不缺牛人 😃

• 根据引入接口自动化测试工具的场景

1. 初次引入自动化测试：如果是初次引入自动化测试，那么除了要考虑上面提到的工具的门槛级别，还要考虑领导对自动化测试的期望程度，个人能力的发展（毕竟这是你拓宽自己职业领域的好机会）等等。
2. 公司已有自动化测试工具：此类情形下，适合刚跳槽到公司或者公司别的部门已有自动化工具可用，建议调查当前工具的使用程度及优缺点，在满足当前使用的情况下还是选择已有工具比较好，一是团队人员已熟悉工具，换工具毕竟容易引起“民愤”；二来是团队有一定的基础，效率比较高。当然，如果在使用过程中发现已有工具已经不适合使用，就可以考虑自动化测试工具改进或替换。

• 扩展性

1. 引入持续集成的难易度：如果研发团队计划或已经引入持续集成，此时要引入接口自动化测试，就需要考虑你所选的工具是否会比较容易的接入持续集成工具。总的来说，如果自动化测试工具具备命令行的形式执行都不难集成到持续集成工具。另外，除了考虑自动化测试工具的执行方式还要考虑是否能够拿到详实的报告。因为，持续集成的结果主要是给非自动测试的人员看的。比如说持续集成工具Jenkins，如果自动化工具具备Jenkins对应的插件，那自然是极好的，报告的事一般就解决了。
2. 工具是否适用于其他自动化测试：根据团队对自动化测试发展方向的预设，可以考虑工具是否适合多类自动化测试使用，包括UI自动化测试、单元测试等等。学习一种工具所花的时间肯定要比多种工具所用的时间少，而且在后续与其他平台集成的过程中也比较容易，因此，如果决定要做多种自动化测试可以考虑是否某一种工具可以胜任，比如RF既可以做接口自动化也可以做UI自动化。

总结

这一篇没有介绍怎么去使用一套接口自动化测试工具，因为已经有很多前辈同仁分享了，而且分享的肯定比我好 😃，我只是根据我自己的经验跟大家笼统地，定性地讨论怎么去选择一套适合自己的接口自动化测试工具，有什么考虑不周的地方欢迎各位讨论哈。