自动化接口测试方案（常用的接口自动化测试框架）

本篇文章给大家谈谈自动化接口测试方案，以及常用的接口自动化测试框架对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享自动化接口测试方案的知识，其中也会对常用的接口自动化测试框架进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、前后端自动化测试方案
• 2、接口自动化测试流程是什么？
• 3、接口自动化测试
• 4、Apifox写接口自动化测试用例总结-1
• 5、我眼中的接口测试和接口自动化测试
• 6、使用配置表+Mocha动态生成用例的JSAPI自动化测试

前后端自动化测试方案

这段时间我探索了点自动化测试方面的技术，探索结果如下
【后端】：任意后端工程 + python 自动化测试脚本（实现接口测试），服务器要求：指令服务器即可（即终端操作系统）
【前端】：任意前端工程 + python 自动化测试脚本（实现UI交互测试），服务器要求：必须是可视化服务器（即有交互界面的系统） （虽然说 phantomjs 可以实现无界面的情况下进行浏览器测试，但是还是不太推荐，毕竟对于前端而言，可视化才最好）

经过探索下来，发现 python 在实现自动化方案确实非常合适，且前后端都可以通过python实现自动化测试，如此一来自动化测试也就可以独立出一个工程，而无需受前后端工程语种、框架等各种不同的影响。只是前端自动化测试比较特殊，需要模拟用户交互，最好是有界面的系统（通过浏览器驱动器调用浏览器实现自动化交互测试），也就是说前后端的自动化测试服务器要么都用一台带交互界面的系统，要么就用2台服务器，一台终端服务器测后台接口，一台交互服务器测前端交互

接口自动化测试流程是什么？

了解了接口测试是什么之后，怎么做接口测试呢?接口测试的流程其实和功能测试流程类似：接口测试计划-接口测试用例-接口测试执行-接口测试报告。测试用例设计的依赖对象主要是需求说明书和接口文档。
接口测试因其不是针对普通用户，而是针对的另外一个系统组件，所以不能直接测试，需要使用工具测试，比如服务端http接口测试，常用的工具有jmeter、postman、httpclient等。用工具测试，所以目标就是准备要测试数据测试脚本后直接执行即可， 在进行测试执行编写时，有如下的原则：
1.不同的接口参数覆盖不同的业务场景;
2.在后台构造合适的数据来满足接口的测试用例;
3.根据接口的返回值，断言其是否返回期望结果，并查看数据库验证;
4.测试用例涉及多个步骤的，应对涉及的步骤都验证;
5.删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境

接口自动化测试

接口 ：外部系统与本系统之间以及系统内部的各个子系统间，以约定标准提供的服务，包括对外提供的接口/对内提供的接口。

在这块我们举一个比较生活化的例子，我们平常使用的笔记本，在笔记本的两端有很多小插口，最常见的就是USB插口，我们可以把鼠标连接在USB插口上，也可以把键盘、U盘连接在USB插口上，为什么同一个USB接口可以连接这么多设备呢，其实这个接口，他就有一个统一对外的连接标准。
在我们开发当中，也有一个对外暴露的接口，因为他们服务的协议都是统一的，最常见的就是hhtp协议，我们规定好一种格式，让客户端来调用我们。
这里面键盘鼠标属于调用方，插到笔记本的USB上，就可以连接设备，就可以进行操作了。对外暴露的一个统一的一个规范，这样去理解接口，更形象一些。

在了解完什么是接口之后，我们来说一下什么是接口测试。
接口测试 测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等，保证对外提供接口的正确性和健壮性。
我们在具体测试过程中，我们不用关心接口调用方和接收方的实现逻辑，我们只需要知道传入什么数据，返回什么的结果是否达到我们的预期。接口测试其实也是黑盒测试，他与UI测试的区别就是没有界面交互，是不可视化的。

测试前置 ：我们不能等到整个系统全部开发完成才能进行测试，我们可以通过调用接口来进行测试，把问题拦截在前期，降低问题修复成本。
Bug更容易定位 ：因为我们按接口进行测试，出现问题后在被测接口中排查就可以了，它比系统集成之后，发现问题更容易定位，系统集成之后有各种模块的调用，出现bug之后再排查，排查的链路非常的长。另外从机制上更接近出问题的地方更容易命中问题。
前后端分离结构 ：现在很多系统都采用前后端分离架构，各服务之间更多的是通过接口来实现信息互通，对接口进行直接测试，可以更全面的覆盖各类测试场景。
自动化测试落地性价比高 ：比UI自动化测试更稳定，我们上面已经说了UI层的元素时常发生变化，有时改一个简单的元素，都有可能导致我们的自动化测试走不下去，写一套自动化测试脚本比较容易的，但是维护起来，会耗费很大的时间精力，相对来说，接口就比较稳定，一个项目没有大的改造，入参和出参就是固定的，变化的概率比较小，这样维护起来也比较方便。
减少安全隐患 ：比如我们在平常的测试过程中，测试用户名和密码，密码格式要求不能输入特殊字符，前端做了校验，而后端没有处理，这样我们只测试页面，这条case就默认通过了，但一些黑客可能通过抓包的方式进行登录，这样安全隐患就比较大了。我们对接口进行安全测试，可以避免安全隐患。

借助工具 ： Postman、Jmeter、jsf平台、jsf测试工具、easytest
编写测试脚本 ：Java+TestNG

请关注下一篇如何使用Java+TestNG进行接口自动化测试

Apifox写接口自动化测试用例总结-1

最近决定用Apifox写接口自动化测试用例自动化接口测试方案，于是研究自动化接口测试方案了这个工具自动化接口测试方案的具体实践，下面把最近实践过程中遇到自动化接口测试方案的问题和解决方案进行总结，方便回看。

Apifox它是集自动化接口测试方案：接口文档管理、接口调试、Mock、接口自动化测试于一体的全流程集成工具，覆盖从开发-测试-管理等环节，等同于 Postman + Swagger + Mock + JMeter几款工具功能累加。

下面从以下几个方面来进行总结：
1json path语法及使用
2.参数化使用
3.结果验证

JsonPath语法要点：
$ 表示文档的根元素
@ 表示文档的当前元素
.node_name 或 ['node_name'] 匹配下级节点
[index] 检索数组中的元素
[start:end:step] 支持数组切片语法
** 作为通配符，匹配所有成员**
.. 子递归通配符，匹配成员的所有子元素
(<expr) 使用表达式
?(<boolean expr)进行数据筛选

直接从返回结果中获取第一个元素

从返回结果中获取iata=3Q的子节点中的id号

1.用两个{}的形式来传参，如{{flightId}}
2.如果提取变量是列表形式，可以取其中某一个，如{{flightId[0]}}
3.可以选择右侧的“魔法棒”动态值来选择变量/常量或动态变量

我眼中的接口测试和接口自动化测试

接口测试的目的是为了增加测试覆盖度、深入度 ，对接口的各个参数做实际场景中很难遇到的异常场景的测试，保证接口的稳定性。如果在这个前提下接口测试还是没有发现 bug，那么可以 review 下历次迭代中是不是业务测试发现的所有 bug 都是前端的。如果是，那么说明你们的后端开发工程师能力实在很强，应该恭喜你们遇到了这么给力的队友。在测试压力很大的情况下就可以酌情考虑不做接口测试，前端测试完成就上线了。

如果不是那就应该 review 你们的接口测试用例了。是不是用例设计的还不如业务测试全面？是不是用例设计的时候默认按照正常的取值范围？按照正常的业务逻辑进行的用例设计导致用例的覆盖还不如业务直接黑盒测出来的覆盖全。

自动化测试的主要目的不是发现多少 bug ，而是为了快速对接口做回归、做线上监控等，避免接口出现了低级问题、阻碍问题但是大家不能第一时间知道，等过了很长时间线上出了强反馈或者在错误接口的基础上又做了很多开发才被大家发现。当然，在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要，思路就会清楚一些。

整体上测试是为了保证业务中的 bug 能够在有限的资源下最大量、最快速的发现，业务实际情况不同、测试团队规模不同、测试与业务的合作模式、测试团队成员的技术能力等等都会影响测试方案的制定。

个人觉得如果团队有专人做接口测试，这种情况下接口测试定位到用来发现更多 bug 是没有问题的，如果没有发现 bug 那就需要仔细找找接口测试用例设计的问题。接口测试的目的不是取代业务测试，而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量。接口自动化测试的目的是在回归场景节约业务测试的工作量，在新业务测试中实际反倒会占用更多的测试资源。

以上是作者拉拉肥对接口测试以及接口自动化测试的理解。你怎么看？欢迎点击 原文链接 在原帖共同讨论。

使用配置表+Mocha动态生成用例的JSAPI自动化测试

一、版本发布前，接口测试之痛

App版本发布前，我们都要手工做接口测试，目的是保证App内部H5页面所使用的JSAPI的功能正常，而对所有H5页面进行的P0级功能测试。为什么要做接口测试呢？因为JSAPI无法抓包，测试难度比较大，所以只能通过对H5页面的功能进行校验。但是手工测试，场景覆盖不全面，且耗时耗力。

二、JSAPI自动化测试方案

首先思考几个问题：一个APP有多少个JSAPI？它的用例场景有多少？如何能做到对用例的高效管理？

答案：对于我们app，有22条JSAPI，每条JSAPI多的话可能有几十个场景。传统的自动化方案，通常是一个场景需要手工编写一条用例，这种自动化的方案成本可以说也是非常高的，好在JSAPI并不常变动。但是，我们想实现一种更高效的自动化方式，不需要编写和管理那么多条用例，提升执行效率，同时降低学习成本。

2.1先来看看JSAPI是什么？

Html通过Jsapi，与app收发数据，形如：WebViewJavascriptBridge.callHandler

("API名称", {调用参数},  <回调函数); js调用app的指定api，该方法由页面主动触发举个例子：

如上，getMainInfo是html中一个button的响应函数。我们在js中，通过JSBridge实现对相应JSAPI的调用，如下：实现H5页面可以直接获取到APP的maininfo数据。

2.2方案与原理

1、首先要解决用例管理的问题，我们实现了一种基于配置表的自动化测试方案，不需要编写脚本，只需把所有用例（含请求参数及返回参数的预期值），放到excel配置表中，通过解析器把所有的参数读出来，再通过模版字符串自动生成用例集。

2、jsapi不能脱离app执行，因此在app增加彩蛋入口，连接到一个网页，打开网页时，由js文件自动加载用例集去调用相关的jsapi接口，并用chai断言库对结果进行校验。

3、jsapi有两种，一种是有参数返回的，一种是会引发UI变更的，下图分别是两种jsapi的自动化校验方案。第一种在下文进行了详尽的描述，第二种需要基于UI的自动化去实现，解决了h5页面的控件在app中无法识别的问题。采用js定时传参给html，配合前端自动化去触发调用的方式实现。

2.3用例管理

如下图：第一行是参数名，蓝色是请求参数，绿色是所有返回参数，用‘/’分隔。返回参数的预期值，用正则表达式来表达。

2.4用例解析器

将上述表格解析为如下格式，params和result是两个数组，每个sheet有几行，数组就有几个值，表格中每行代表一个场景。解析器基于Node.js，在服务端运行。

2.5使用Node.js+模版字符串动态生成api.js

在解析得到的所有JSAPI名称后，将调用方法以字符串的方式写入文件中，动态生成我们要调用的所有JSAPI的调用方法，再被html所引用即可：

动态生成的api.js文件是下图这样的：

我们的用例配置表中有n个sheet，即有n个JSAPI的用例，我们这里就自动生成这几个JSAPI的调用方法，传入的req就是我们在配置表中读到的每一行用例中的请求参数。拿到回包的res，再去校验是否与解析配置表得到的所有返回参数一致。

2.6使用Node.js+模版字符串动态生成测试用例

Mocha是JavaScript的自动化测试框架，既可以运行在nodejs环境中，也可以运行在浏览器环境中。如下图，通过调用mocha.setup(‘bdd’)，开启 Mocha 的测试功能（testing helpers）。然后，加载需要的测试项和相应测试的文件。最后，调用了 mocha.run() 执行相应测试。

下图所示部分，自动生成测试用例，也是采用解析JSAPIList的同时写test.js文件的形式。

Ps：describe：称为"测试套件"（test suite），表示一组相关的测试。它是一个函数，第一个参数是测试套件的名称，第二个参数是一个实际执行的函数。

it：称为"测试用例"（test case），表示一个单独的测试，是测试的最小单位。

所有测试用例均为动态生成，如下图：

2.7Mocha框架自动化执行测试用例集

JSAPI的测试页面已经完成了，我们需要把它放到app中才能执行。在app的彩蛋页面放一个入口，加载这个html，当打开这个html的时候，服务自动的去执行并展示结果。如图，执行12条用例，只用了0.14s。

2.8自动化效果

目前，jsapi覆盖率已达70%，用例场景171个，执行耗时1.98s，Android和iPhone两个平台发现bug16个，涉及场景共35个，必现crash2个。

三、效果分析

在h5高产的今天，JSAPI的接口自动化测试解决了手工测试低效且覆盖不完全的苦恼，该方案在复用程度上也是非常友好的高度可复用的。只需创建自己的用例配置表，修改html中JSAPI的连接方式即可。 关于自动化接口测试方案和常用的接口自动化测试框架的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 自动化接口测试方案的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于常用的接口自动化测试框架、自动化接口测试方案的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。