接口测试用例中 调用时机（接口测试用例编写要点）

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

本文目录一览：

• 1、如何简单设计接口测试用例
• 2、如何做接口测试
• 3、如何做好接口测试？
• 4、接口自动化测试测试用例设计

如何简单设计接口测试用例

接口测试是项目测试接口测试用例中 调用时机的一部分 ，它测试的主要对象是接口 ，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。 如何设计接口测试用例？首先，明确出发点，和所有的测试一样 ，接口测试出发点是接口测试用例中 调用时机你要证明所测的程序是错误的。以这个出发点为导向 ，你的设计行为就会尽量朝这个方向，更易发现问题 其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口 ，每个接口如果分别测试 ，那将是很痛苦的一件事情，而且任何一个内部接口的变动 ，都将导致我们用例的不可用。 可将这些最外层的接口分为两类：一类是数据进入系统的接口；一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用 ，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。数据从哪里流出，流出时的状态如何 ，此时系统又是什么状态都是我们所应该验证的。 然后，确认完整的测试对象的功能：确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。 最后当出发点、对象、功能都确定接口测试用例中 调用时机了，就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。 接口测试用例设计和测试用例设计一样，用例设计的内容应该包括：主要测试功能点、测试环境、测试数据、执行操作以及预期结果。 1）接口测试环境分为两种：一种是程序内部的环境；一种是程序的所调用外部接口的环境。 2）接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列 ，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据 ，使用例更容易发现问题。 3）测试功能点，如果一个接口功能复杂时推荐对接口用例进行结构划分 ，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。 4）接口测试用例执行操作非常简单，就是所测接口的调用。 5）预期结果验证，这也是接口用例设计的很关键的一步 ，应该细而不冗余。每个用例均需验证 ，避免一个用例中重复做相同的验证 ，提高测试用例的效率。 如何设计接口测试用例小例子： 简单划分可以按照2个基本组成要素进行划分：1. 参数 2. 业务 以下为最简单的一种划分用例的方法，可能涵盖不全，但只为说明一种划分接口用例的方法方式以及需要考虑的测试用例的测试点 为何要如此设计，是为了更好的将用例分类为程序规定型以及业务限制型，尽量的保证覆盖，尽量细化到点的划分形式来保证工作时间的预估和计划。 所有的自动化接口的测试用例 都基本围绕三部曲进行，传数据，执行，校验返回的数据和期望数据是否一致来构成每个简单的测试用例。 有清晰的线路和清晰的思维，才能做好整体测试的掌控。

如何做接口测试

1、可以使用postman软件进行接口测试，这里以较复杂的上传图片的接口为例进行测试，首先打开postman软件选择Post方式，输入后台接口调用地址。

2、然后填写Headers，注意这里的Headers部分不要写任何东西，如果之前是有Content-Type头信息， 那么就会上传失败。

3、接着填写Body，选择form-data，填写Key后台规定的接收文件的名称参数，格式选择为File，此时value会自动变成选择文件。

4、最后点击Send，可以发现下方返回了接口的响应，说明上传图片是成功的，这样简单的图片上传的接口测试就完成了。

如何做好接口测试？

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 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。尽量减少这些功能单元集成起来出错的可能性，单元测试一般是由开发人员自己去完成，单元测试可能不会考虑业务是如何的，会更多的考虑，我这个单元模块逻辑是否正确。 接口测试指的是针对程序内部的或者外部的接口进行的测试，一个接口方法可能会包含多个单元模块，而且，一个接口会有自己特定的业务定义，所以，做接口测试的时候，更多的需要从业务的角度去考虑如何测试这个接口。 不管是接口测试还是单元测试，其实都属于白盒测试的一个阶段，白盒测试具体的方法有很多种，比如代码审查，比如代码覆盖。

接口自动化测试测试用例设计

浅谈接口自动化测试测试用例设计

一、   前言   

很多中台项目，大部分为接口测试。为了使新入职的测试同事尽快融入项目，以及迭代开发中方便管理测试用例。完成该总结。

二、   测试用例设计思路   

1、 接口类型概述及优先级  

1） 提供给第三方调用的接口  

2） 内部系统使用，核心功能接口  

3） 内部系统使用，非核心功能接口  

基本按照1）2）3）的顺序进行测试，特别情况除外

2、 单接口测试优先级  

1） 优先测试正向测试用例，保证基本功能实现  

2） 设计逆向测试用例，确保接口的健壮性  

3） 满足前提条件的测试用例  

4） 默认参数是否满足  

5） 参数校验  

6） 参数间联动关系

7）多参数错误处理的优先顺序校验

三、   设计分析   

1、 满足前提条件的测试用例  

测试目标接口需要满足前置条件才能成功获取数据。

例如：需要登录token，通过传入参数获取下游接口数据

2、 携带默认参数的测试用例  

携带默认参数的测试用例仅需要设计一条，所有默认参数的字段都不填写，其他字段输入正常。

[if !supportLists]3、 [endif]参数校验  

参数校验包含如下几方面：

[if !supportLists]1）[endif]输入参数是否为必须输入项

[if !supportLists]2）[endif]输入参数的类型

[if !supportLists]3）[endif]输入参数的枚举值校验

[if !supportLists]4）[endif]输入参数长度校验

以上测试用例最好根据字段一一校验，排除互相干扰

[if !supportLists]4、 [endif]参数间联动  

有些参数见存在彼此制约的关系，根据实际情况设计测试用例

例如:A字段为1时，B字段一定为空。否则报错。

那么测试用例设计时应为：A字段为1时，B字段为空；A字段为1时，B字段不为空；A字段不为1时，B字段为空；A字段不为1时，B字段不为空；四条测试用例

这样基本覆盖所有分支流程。

[if !supportLists]四、 [endif] 测试用例实践操作

接口测试用例样例:

多条件查询接口

测试方法：使用robotFramework测试doubbo接口

协议请求方式：post

接口协议：JSON

消息请求列表

字段名数据类型默认值必须项备注

IDint 是长度为2

Tokenstring 是设备令牌

Statusstring 是1：正常

2：异常

typeint  Status为1时，为必须输入项

sizestring  默认值
消息返回列表

字段名数据类型必须项备注

Codeint是正常：20000

异常：20001

Messagestring是 

typeMessageint Status=1的所有ID

 

用例设计

 

NO. 测试内容 前置条件 输入参数 输出参数 用例属性

1目标数据为一条预置一条符合条件的数据Status=1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

正向测试用例

2目标数据为多条预置多条符合条件的数据Status=1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

正向测试用例

3 Token必须项检查 预置多条符合条件的数据Status=1，token输入为空，其他参数输入正常返回code=20001

typeMessage中返回为空

满足前提条件

4 Token正确性检查 预置多条符合条件的数据Status=1，token输入错误，其他参数输入正常返回code=20001

typeMessage中返回为空

满足前提条件

5 Status 必须项检查 预置多条符合条件的数据Status为空，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

6 Status枚举预置多条符合条件的数据Status为1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

参数校验

7 Status枚举预置多条符合条件的数据Status为2，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

参数校验

8 Status枚举预置多条符合条件的数据Status为3，其他参数输入正常返回code=20001

typeMessage中返回null

参数校验

9 Status=1，时联动校验预置多条符合条件的数据Status为1，type为空；其他参数输入正常返回code=20001

typeMessage中返回null

联动校验

10 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type为空；其他参数输入正常返回code=20000

typeMessage中返回对应ID

联动校验

11 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type不为空；其他参数输入正常返回code=20000

typeMessage中返回对应ID

联动校验

12 Size默认值输入校验预置多条符合条件的数据Size输入为空，其他参数输入正常返回code=20000

typeMessage中返回对应ID

默认值校验

13 Size默认值输入校验预置多条符合条件的数据Size输入不为空，其他参数输入正常返回code=20000

typeMessage中返回对应ID

默认值校验

14 ID 必须项检查 预置多条符合条件的数据ID为空，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

15 ID 长度检查 预置多条符合条件的数据ID长度大于2，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

16 破坏性测试预置多条符合条件的数据输入的参数类型错误请求未接收，返回404 稳定性测试

17 破坏性测试预置多条符合条件的数据输入的参数与提供的参数名称不一致请求未接收，返回404 稳定性测试

18 破坏性测试预置多条符合条件的数据输入的参数与提供的参数数量不一致请求未接收，返回404 稳定性测试

19 破坏性测试预置多条符合条件的数据输入的参数与提供的参数格式不一致请求未接收，返回404 稳定性测试

 

总结：自动化测试过程中会有一条自动化测试用例覆盖多种情况的可能（例如：正向测试用例与联动性验证的 Status=1，type输入不为空的测试用例重复，所以选择一条用例验证 。 ），以上的测试用例满足自动化的要求，手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性，无需检查输入参数的类型。 关于接口测试用例中 调用时机和接口测试用例编写要点的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口测试用例中 调用时机的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口测试用例编写要点、接口测试用例中 调用时机的信息别忘了在本站进行查找喔。

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