做接口测试的时间（什么阶段进行接口测试）

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

本文目录一览：

• 1、Jmeter实现接口测试
• 2、接口测试的使用范围
• 3、如何做接口测试？
• 4、如何做接口测试
• 5、如何做好接口测试？

Jmeter实现接口测试

利用Jmeter做接口测试怎么做呢？过程真的是超级简单。

明白了原理以后，把零碎的知识点填充进去就可以了。所以在学习的过程中，不管学什么，我一直都强调的是要循序渐进，和明白原理和逻辑。这篇文章就来介绍一下如何利用Jmeter做接口测试的流程，主要针对的是功能测试。暂不涉及到自动化测试和性能测试的内容。

一把来说，主要的步骤都大差不差。

第一步：通过分析API文档和需求文档提取接口清单 。

也就是说，接口测试工作人员工作的开始就是从API文档和需求文档开始的。所以进入公司的第一件事情就是要拿到API文档和需求文档来了解，来看，来分析。从其中提取接口清单的话，主要是因为API文档中有很多冗余，不必要的信息。这些信息可能对于开发人员是有用的，但是对于我们测试人员是没有用的，所以要去除冗余，提取关键信息。

那么怎么提取呢？方法也很简单，从功能模块和方法模块对API文档中的内容进行提炼，提炼的关键是接口三要素：url+方法+参数+返回值。我的建议是可以先将所有的url提取出来，基本上一个url就是对应一个接口的，这样一条线把整体拎起来，就感觉混乱的局面清晰多了。

当然工作中，有的时候我们是可以直接拿到接口清单的，因为清单这个事情一个团队做一份就好了，并不是说要每个人都做一份。但是我们自己得会，得有这个能力。之前看到过一个面试题，问的是，如果没有API文档，怎么做接口测试？

其实问的就是如果没有API文档，应该怎么提取接口清单的问题。很简单，根据需求文档和原型图来提取。有的公司不正规，确实是没有API文档的。或者有的公司API文档写的不规范，那提取的时候，就很考验测试人员的经验和能力了。所以如果能找到遵循restful风格写的优秀API文档，那就好了，提取的时候很方便。

第二步：针对接口清单，做单接口测试和关联接口测试。

在实际测试过程中，单接口测试和关联接口测试的时间是不一样的，这涉及到业务逻辑测试和功能点测试等。但是在测试的时候，他们的逻辑和方法是类似的。

当然这里主要介绍的是单接口测试，因为单接口测试时会考虑各种可能的情况，而关联接口测试一般是建立在单接口没有问题的前提下的。换个角度来说，就相当于是两个层次，单接口测试是基础，而关联接口测试是拔高。

那么具体应该怎么做呢？比如我们这里已经选定而来某一个接口来测试。

首先，根据选定的接口来搭建测试框架 。

接口不是什么大不了的事情，无非就是url、方法、参数、返回数据这四块。这样就意味着，一个接口的框架是固定的，只不过每次传输的数据和返回的数据可能会不一样而已。所以我们要做的第一步就是搭建测试框架。

那么怎么搭建呢？这里就要用到从API文档中整理出来的接口清单和Jmeter了。从接口清单里，可以拿到当下接口的url+方法+参数+预期返回数据。这就是我们搭建测试框架的依据。接下来用Jmeter搭建。

首先需要打开Jmeter，然后基于测试计划，创建线程组，基于线程组创建HTTP请求。考虑到单接口测试，一个框架，要测试N多个数据，而且后面的接口可能也要用到同样的ip地址、同样的content-type，所以一般会先创建一个HTTP请求默认值，将一些可能会重复用到的信息填进去，比如说端口号、协议之类的。如有必要还需要添加HTTP信息头管理器，放一些user-agent、content-type等内容。

好的，有了这两个基础就可以来创建HTTP请求。在新的请求里，已经填写的端口号呀、ip地址呀之类的就无需填写了，只需要填写方法之类的即可。那么搭建框架在哪里搭建呢？一般会考虑para或者body里。比如说，要提交一段json格式的数据，那么就要用body（消息体）来提交，如下图所示。

将从接口清单里拿到的json数据填写到消息体数据里，然后将需要不断传入的数据进行参数化设置，那搭建测试框架就算是完成了。接下来只需要把数据一条一条传入进行测试即可。

那么如何把数据进行传入呢？

其实我们在下面的这篇文章里已经介绍了，传入数据的方法有四种，但主要使用的还是csv data set config 和函数。做功能接口测试，用csv就足够了。那么具体怎么用呢？

星空下：软件接口测试工具Jmeter使用核心详解12 赞同 · 0 评论文章

基于当前的线程组或者请求创建CSV数据文件配置组件。如果这份数据只有这一个请求会用，那么就基于请求创建即可。如果这份数据会被这个线程组里的多个请求使用，那么就基于线程组创建。

创建了以后就需要填入文件了呢？可是文件在哪里呢？这个时候就要稍微停一下jmeter的操作，先去针对当前接口设计测试用例并形成有关文档了。有关于功能接口测试的用例设计，我们之后会专门用一篇文章来介绍，这里先带过。这是因为设计测试用例是做测试过程中最核心的一步。

在测试用例设计完之后，可以将其保存在一个txt文档里，采用utf-8编码，保存到Jmeter脚本的同一父目录下。然后按照上面那篇文章里的设置方法进行设置即可，注意路径可以采用相对路径，便于数据文件的拷贝和使用。

csv组件设置好以后，数据源有了，变量名有了，变量名的赋值也有了，接下来就只剩引用参数就可以了。在测试框架里需要引用参数的地方引用，引用的格式是${参数名}。到这里，针对于某一个接口的测试工作就准备完成了。

然后在Jmeter里面添加查看结果树组件，执行请求，依次查看结果 。看一看返回的数据和我们的预期结果是否一致，不一致，那可能就是一个bug。

做一个小小的总结吧，用jmeter做功能接口测试，其实很简单的。逻辑和原理都是类似的，如果遇到新的项目，可能说会用一些新的组件而已，那百度一下几分钟的事情。在学习软件测试的时候，最重要的就是不要怂，不要看起来说怎么要学的东子这么杂这么多，只要能够拎出其中的线索和主干，然后把一些零碎的点给组装上去，就会感觉，哇，忽然之间，好有条理。

接口测试的使用范围

接口测试一般会用于多系统间交互开发做接口测试的时间，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统做接口测试的时间，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。
接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比，接口测试天生为搞复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
不是所有的团队都可以在一个隔离的测试环境中进行测试工作的，因此使得对外部接口的测试显得困难。我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试。等等这些都增加做接口测试的时间了实际测试执行中遇到的风险，但有些时候是可以避免的。
假设/预处理
项目的责任人/开发人员必须已经成功完成做接口测试的时间了单元测试、功能测试和集成测试，一些错误都已经被列出。测试策划人员拿到的是最新版本的源代码
期望
正如前面提到过的那样，最重要的是关于外部接口的测试，这需要依赖于外部接口的相关数据，而这可能是极其复杂的
测试项目需要一系列的测试计划以及和外部组织的协调工作，主要包括：
负责人选
预定的测试时间
如果没有合适的测试环境，测试可能需要在周末或者工作时间以外的时间里进行
需要什么类型的测试用例，需要多少以及这些用例分别是用来测试什么的
提供测试用例的副本及相关文件给相关合作人员
如果外部组织有一些特殊用例需要执行，我们也需要拿到相关副本及文件
谁将提供测试数据，这些测试数据包括哪些方面的内容，是以什么形式给出的（纸质，电子档还是只是一些数据的底稿并且需要相关的人员整理成可用的数据）
谁将对测试结果进行确认并且判别这些数据就是我们所需要的
每隔多久时间我们需要各路人马聚在一起讨论测试中遇到的问题以及测试进度
所有正常的情形和异常的情形都需要测试，测试的各个方面（数据的各个出口，路径，入口）都需要尽可能考虑周全。我们不仅需要用一般大小的数据量去测试，也需要用预期的或者规定的最大数据量去测试
如果允许的话，我们还可以测试各个部分处理一批数据的时间数据
如果因修复bug等改动代码从而改变了接口的某一端，相关的决定，到期时间，再测试等过程都应该被记录在案，并且分发到各个相关组织或人员。

如何做接口测试？

对于接口测试，首先测试人员要懂代码，你只需要知道接口的作用是什么就可以了，其次，自己去读开发的代码。

然后，根据该接口功能及代码写测试用例：根据该接口参数，构造不同的用例，测试接口在参数合法及非法情况下能否达到预期效果，根据该接口中的逻辑，测试该接口实现代码的逻辑，进行容错及健壮性测试，静态检测代码，看是否有内存泄露、或永远走不到的分支、代码规范及逻辑是否合理，对于一些接口，需要进行多线程测试。

接口测试一般会用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统。

主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。

如何做接口测试

做接口测试流程：

测试接口文档。

根据接口文档编写测试用例（用例编写方法完全可以按照黑盒测试的用例编写规则来编写，如：边界值、正交表等等设计方法）。

执行测试，查看接口返回的接口数据是否正确，主要检查返回的接口是否和接口文档中定义的一样，还有要检查返回的数据是否和数据库中的保持一致。

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

①目的：测试接口的正确性和稳定性；

②原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；

③重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；

④核心：持续集成是接口测试的核心；

⑤优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显（提高测试效率，提升用户体验，降低研发成本）。

接口测试范围：

a)业务功能（包括正常、异常场景是否实现）

b)业务规则（覆盖度是否全面）

c)参数验证（边界、业务规则是否达到要求）

d)异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）

e)性能测试（响应时间、吞吐量、并发数、资源要求）

f)安全测试（权限验证、SQL注入等）

如何做好接口测试？

sgbtmy：基于selenium的自动化框架开发，我主要是想问一下，你的框架除了前台的自动化，后台的数据的测试是否集成在你的测试框架中？ 小刀：你好，个人理解的你所说的后台的数据的测试是指的是对数据的校验，不知理解的是否正确，那么根据这个理解，我的解释是，在我们框架中，增加了很多的功能方法用来帮助进行自动化脚本的编写和结果校验，其中就包括后台数据校验方法，当我们的测试用例需要在后台进行数据校验的时候，调用这些数据校验方法即可。相当于是，前台页面操作的自动化是封装selenium的方法去操作页面，而对后台数据的校验是通过增加功能方法来实现的，可以理解为不同的两部分，但是在编写测试脚本的似乎，根据测试用例的设计，这两部分都可以拿过来使用。 不知道是否解答了你的疑问，如果没有，请你指出，谢谢你。 tjy688：你们做接口测试的流程一般是怎么样的？ 小刀：接口测试的流程其实和功能测试的流程类似，因为接口测试依赖的主要对象也是需求说明书，所以，最初的流程就是参与需求讨论，评审需求。 需求确定以后，开发会根据需求进行接口设计，会产出接口定义，在开发设计过程中，有能力的话，可以给出一些针对设计的建议，提高可测性，针对需求及设计，进行测试计划，测试设计，然后还需要和配管确定测试环境相关的事情。 在开发完成接口定义之后，就根据需求文档及接口定义进行测试用例设计，测试用例设计主要从业务场景，功能，以及异常测试几个方面考虑。 测试用例设计完成后，针对测试用例进行评审，然后，如果开发代码部分可测时，即可进入测试了，因为是部分可测，可能会使用到mock方法。 已有测试代码时，就要进行测试代码的持续集成了，我们是使用hudson来进行持续集成的 在项目结束后，会对每个项目进行总结。 如果有问题，请指出，我们一起讨论。 xinhuayw：我想了解一下你们现在是怎样保证项目测试用例的重复运行的。 小刀：对于接口测试来说，项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的，也就是说，每一个测试用例的运行除了依赖被测对象和对应的数据库环境外，是不依赖于其他任何测试用例的，并且这个测试用例执行完毕后，对系统来说，也是没有任何痕迹的，这样就保证了每个测试用例运行时，都在一个干净的环境中运行。要实现测试用例的独立性，就必须对被测系统的设计有详细的了解，这样，不会出现测试用例执行后遗漏数据，环境未改变，另外，还需要对测试用例进行详细的设计。另外，要保证测试用例的重复使用，还需要做到测试用例的及时更新，在这个方面，我们是做接口测试的人会维护对应的系统的接口测试用例，要保证，代码每次更新，测试用例都必须全部执行通过。 csun888：什么是接口测试，基础知识什么的讲讲吧！ 小刀：你好，接口可以分下面几种 1、系统与系统之间的调用，比如银行会提供接口供电子商务网站调用，或者说，支付宝会提供接口给淘宝调用 2、上层服务对下层服务的调用，比如service层会调用DAO层的接口，而应用层又会调用服务层提供的接口，一般会通过 3、服务之间的调用，比如注册用户时，会先调用用户查询的服务，查看该用户是否已经注册。 而我们所要做的接口测试，先要了解是基于哪一种类型的接口测试，不同类型的接口测试方法可能是不一致的，总体来说，不管是那种类型，我们只要把被测接口当做是服务方，而把我们的测试手段当做是客户方，我们的目的就是，通过我们的测试手段，去验证服务端满足了他声明提供的功能。 至于说到具体的测试方法，http协议的接口测试，一般会用jmeter去测试，jmeter的好处是不用写测试代码，直接使用jmeter提供的http请求去测试，也可以使用HTTPClient去测试，好处是可以方便集成和自动化。java接口的测试，则需要编写测试代码去测试，有点类似于单元测试，但是需要更多的考虑业务场景。 gulun：接口测试的数据准备，应该怎么做呢？ 小刀：接口测试的数据准备，可以从下面几个方面去考虑： 1、如果是只测试一次的接口，可以使用硬编码的方式准备测试数据，在写测试代码的时候，使用到什么数据就写什么数据，为了避免数据重复，可能比较多的会用到随机字符或随机数 2、可以直接通过调用其他API的方式准备测试数据，这种情况在测试最上层服务的时候比较有用，比如测试团购购买服务，就需要准备要购买的团购数据，购买团购的用户数据，这个时候，可以直接调用生产团购的api和生成用户的api直接生成测试数据. 3、使用excel或xml准备测试数据，这种准备测试数据的方式，主要针对对象数据的准备，比如可以将一条团购数据对应excel中的一条数据，因为一般开发都会使用pojo映射，而在准备测试数据的时候，这些pojo对象属性的设置往往是重复和大工作量的，用excel或XML方式准备，则可以减少在代码当中重复去准备这些数据。 4、也可以使用工具方法的形式去准备测试数据，通过在代码中写工具方法去实现数据生成，而在测试代码中调用工具方法去得到所需数据。 水生哥哥：你好，我想问一下：接口测试怎么设计测试用例呢？ 小刀：你好，我觉得接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的，而接口测试所依赖的也是需求说明书，但是，因为接口测试毕竟是通过代码去测试代码，所以，为了保证覆盖率，可能会使用到单元测试的方法，具体的测试用例设计，我考虑的如下，请参考，如果有错误，一起讨论。 输入参数测试：针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长； 功能测试：接口是否满足了所提供的功能，相当于是正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。 逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常； 异常情况测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何的异常都进行处理。 永远的测试者：才开始测试，对接口测试感兴趣，可是，当前的能力又无法进行接口测试，怎么样才能进入接口测试呢？ 小刀：你好，如果要做接口测试，是需要一定的编程能力的，需要学习相对应的开发语言的，然后还需要学习开发所使用的一些框架，比如ibatis，spring等，对数据库的操作也需要了解一些，还有eclipse操作，这些内容并不需要了解的多么深入，如果只是一般的做做接口测试，这些能够使用就可以了，当然，要做好接口测试，就另当别论了。 我不知道你当前是什么样的能力，所以，我的建议就是， 1、学习编程语言，基础的语法，循环，条件等 2、学习项目工程管理及开发框架：eclipse，maven，svn，ibatis，spring等 3、学习Xunit 4、自己尝试去写测试代码 其实，上面的过程除了第一步是必须具备的意外，其他的都可以一边写测试代码，一边学习，最好的办法就是看开发写的代码，并且，请开发写一个正常的测试代码，然后照着开发的测试代码去模仿。 iTest99：你认为接口测试由开发团队做好还是测试团队好？各有什么优势和弱点？ 小刀：我觉得，还是要区分一下单元测试和接口测试，单元测试一般来说，是针对具体的代码逻辑进行测试，尽量减少这些功能单元集成起来出错的可能性，一般是由开发人员来完成，而接口测试，更注重从用户的角度设计用例，更偏向于功能测试，单元测试设计测试用例的时候，可能更多的考虑是代码覆，而接口测试，则需要更多的考虑业务覆盖。单元测试由开发人员来做，可以保证从代码角度来看是没有问题的，但服务保证业务角度来看也是没有问题的，而接口测试，则通过业务的角度去设计测试用例，其实，也可以说是从更早的时候，以功能测试的方法，先保证项目的流程及功能是正常的，而不至于在页面开发完成后，又修改主要功能代码，导致项目赶工及一系列的重写。 所以，我觉得，单元测试由开发人员来做，接口测试由测试人员来做。 至于你说的学习接口的成本，我觉得这个成本并不高，原因是： 1、接口测试的用例也是依赖需求文档的，并不是根据开发代码去设计 2、接口测试的用例可以在功能测试中复用。 3、接口测试看似增加测试时间，实则不然，因为，接口测试会更早的发现bug，而使得修改bug的成本更低，接口测试会减少功能测试的时间，应该接口测试会确保主要流程功能的正确性，接口测试更容易实现持续集成，从而减少回归测试的次数。 txTester11：我想请问：接口测试盒单元测试有什么区别？接口测试和白盒测试又有什么区别？ 小刀：单元测试是针对具体的代码逻辑进行测试，主要测试被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。尽量减少这些功能单元集成起来出错的可能性，单元测试一般是由开发人员自己去完成，单元测试可能不会考虑业务是如何的，会更多的考虑，我这个单元模块逻辑是否正确。 接口测试指的是针对程序内部的或者外部的接口进行的测试，一个接口方法可能会包含多个单元模块，而且，一个接口会有自己特定的业务定义，所以，做接口测试的时候，更多的需要从业务的角度去考虑如何测试这个接口。 不管是接口测试还是单元测试，其实都属于白盒测试的一个阶段，白盒测试具体的方法有很多种，比如代码审查，比如代码覆盖。 关于做接口测试的时间和什么阶段进行接口测试的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 做接口测试的时间的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于什么阶段进行接口测试、做接口测试的时间的信息别忘了在本站进行查找喔。

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