接口测试用例编写要点,Apifox写接口自动化测试用例总结-2

接口测试用例编写要点,Apifox写接口自动化测试用例总结-2详细介绍

本文目录一览： 接口测试用例编写要点有哪些？

您好，对于接口测试，首先测试人员要懂代码，你只需要知道接口的作用是什么就可以了（有文档更好，但大部分都没有）；其次，自己去读开发的代码；然后，根据该接口功能及代码写测试用例。 用例设计： 1：写一个程序去调用该接口
测试每个参数类型不合法的情况(类型不合法容易遗漏NULL型)
* 测试每个参数取值范围不合法的情况
* 测试参数为空的情况
* 测试参数前后台定义的一致性
* 测试每个参数的上下限(这里容易出致命的BUG，如果程序处理不当，可能导致崩溃)
* 如果两个请求有严格的先后顺序，需要测试调转顺序的情况
更多内容可以从黑马程序员获取相关资料进行了解

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

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

一、 ? 前言 ??

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

二、 ? 测试用例设计思路 ??

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输入不为空的测试用例重复，所以选择一条用例验证 。 ），以上的测试用例满足自动化的要求，手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性，无需检查输入参数的类型。

接口测试的测试用例该怎么写呢？

接口测试：
接口：主要是子模块或者子系统间交互并相互作用的部分。
这里说的接口是广义的，客户端与后台服务间的协议；插件间通信的接口；模块间的接口；再小到一个类提供的方法；都可以理解为接口。因此，可以分析，系统间的接口包含三部分：输入、处理逻辑、输出。
接口测试：是指针对模块或系统间接口进行的测试。
分析一个接口：
获取接口文档：和黑盒测试一样，我们是从需求文档中去挖掘测试点，设计测试用例。对于接口测试，同样是有对应的接口文档的。
分析接口文档，提取测试点：
1）输入：接受哪些参数、参数的类型、可选参数和必选参数等；根据输入参数采用等价类、边界值分析法等进行设计。
2）业务逻辑：对于一个接口，不同的输入参数或组合，流程或状态的转移是不同，可以根据业务逻辑画出流程图或状态转移图，确保每种状态至少被访问了一次。
3）输出：根据文档规定的输出，反向设计测试数据，使所有的输出状态都被包含了；
测试用例：同时对输入、业务逻辑、输出进行考虑时，肯定会存在用例的冗余，在最大限度覆盖业务功能和规则下，选取最优用例集合。同时，需要考虑异常数据和场景。

测试接口应从哪几方面考虑。请写出接口测试用例的框架？

? ? 1.输入的实际参数与形式参数的个数是否相同;

? ? 2.输入的实际参数与形式参数的属性是否匹配;

? ? 3.输入的实际参数与形式参数的量纲是否一致;

????4.调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;

????5.调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;

????6.调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;

????7.调用预定义函数时所用参数的个数、属性和次序是否正确;

????8.是否存在与当前入口点无关的参数引用;

????9.是否修改了只读型参数;

????10.是否把某些约束作为参数传递。、

? ? 11.对全程变量的定义各模块是否一致;

如果模块内包括外部输入输出,还应该考虑下列因素:

? ? 1.文件属性是否正确;

? ? 2.OPEN/CLOSE语句是否正确;

? ? 3.格式说明与输入输出语句是否匹配;

? ? 4.缓冲区大小与记录长度是否匹配;

? ? 5.文件使用前是否已经打开;

? ? 6.是否处理了文件尾;

? ? 7.是否处理了输入/输出错误;

? ? 8.输出信息中是否有文字性错误;??

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

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

接口测试用例怎么设计

在开始接口测试之前，我们想一下，接口测试的流程是什么？说到这里，有些人就会产生好奇和疑问，心里mmp：接口测试要什么流程哈？？？不就是参考接口文档，直接利用接口测试工具（例如jmeter和postman）测试。。。其实，如果一个project中，只是几个接口，你完全可以做临时的接口测试，但project可不止几个接口，少则几十条接口，多则成百上千接口。另外，如果你公司的这个项目，第一次做接口测试。而且古人说过：“无规矩不成方圆。”所以哈，我们还是有必要严格遵守接口测试的流程。
二、接口测试的流程
　　接口测试属于功能测试，接口测试的流程类似于以往的功能测试。接口测试的流程如下：
测试尽早找开发拿接口文档（需求文档）；
根据接口文档编写测试用例（用例编写可按照以往规则写，比如等价类划分，边界值，场景法等设计方法）；
执行测试，查看不同的参数请求，接口返回的数据是否达到预期
?
三、为什么要写用例
理清思路，避免漏测和重复测；
提高测试效率；
跟进测试进度；
更好的发现问题，记录问题，复现问题；
跟进重复性工作；
告诉领导：我做过；
接口测试流程中的一个产物（测试用例）
　　上面7点，有用例，自己心中有数，不用一个测试点重复测好多次，也避免漏测。

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

下面从以下几个方面来进行总结： 1.设置环境 2.设置变量 3.自定义脚本写法 4.python脚本调用
在界面的右上角，是 环境管理 的入口，选择管理环境后进入。
可以在左侧新建或删除环境，右侧可以对某个环境进行编辑。
如果在系统测试时需要多个系统来测试，可以在添加默认服务的基础上，再添加其他系统的URL，在编写对应的接口时，手动选择对应服务信息。
根据需要，可以在页面右上角，快速切换为你所需要的环境。
打开环境管理（软件右上角设置形状的按钮），选择全局变量 tab。
1.添加一个名为my_variable的变量，将本地值设置值为hello，点击保存。 2.打开一个接口，在运行 tab （或接口用例）的参数值里输入{{my_variable}}即可引用该变量。 3.点击运行按钮，发送请求，实际运行的时候系统会将{{my_variable}}替换为hello，然后发出请求。
本地值和远程值的区别: 1.所有使用到变量的地方，实际运行的时候都是读写本地值，而不会读写远程值。 2.本地值仅存放在本地，不会同步到云端，团队成员之间也不会相互同步，适合存放token、账号、密码之类的敏感数据。 3.远程值会同步到云端，主要用来团队成员之间共享数据值。 4.注意:由于本地值仅存放在本地，使用一些清理软件清理 Apifox 文件缓存会导致本地值被清空，请务必注意。 变量类型: 1.环境变量是最常用的变量，同一个变量可以在不同的环境设置不同的值，变量值会跟随环境切换而改变。环境变量在环境管理模块设置 2.全局变量 使用方法类环境变量类似，但全局变量不会跟随环境切换而改变。 3.临时变量 仅在单次运行接口用例或测试管理里的测试用例或测试套件过程中有效，不会持久化保存。
使用方式: 以下两个环节可添加脚本： 在将请求发送到服务器之前，使用前置脚本。 收到响应后，使用 后置脚本(断言测试)。
接口请求的执行流程如下： [全局前置脚本] -> [分组前置脚本] -> [接口前置脚本] -> [发送接口请求] -> [返回接口结果] -> [全局后置脚本] -> [分组后置脚本] -> [接口后置脚本] 调试脚本: 调试脚本可以在 前置脚本 和 后置脚本里编写，使用console.log('hello')方式将调试信息写入控制台，打开 控制台 即可查看。
使用python进行前置脚本编写：
第三步：python环境变量配置完成后重启电脑和apifox 第四步：前置脚本编写

接口测试怎么才能做好？

这个问题还是从需求、测试用例设计、执行来说吧。

A.需求 首先要了解这个接口提供的服务的需求定义，那么我们就知道大概测试的结果是啥。同时理论上要先提供接口规范，方便后续测试，以及给调用者联调的一个文档约定。

B.测试用例设计
根据测试的接口规范，基于业务进行场景设计，再结合边界值设计方法、等价类划分等常用设计方法进行用例设计。

1.设计的方向是常规的测试用例设计：协议规范测试、接口入参、接口出参。
协议规范测试：比如HTTP协议：URL地址、Header测试。不过一般情况下，默认调用者按照接口规范正常调用。这个不用过于详细测试。

2.接口入参：参数个数测试(注意是否必传字段），参数值测试（为空、正常值、非法值等，以及首尾有空格是否过滤）。

3.接口出参：至少涵盖一条成功的响应和一条失败的响应，当然我们测试出更多错误码，我们的覆盖率也就更全面。

4.业务场景用例： 这个需要你对于这个接口的业务的了解程度，而且这是最重要的部分。
比如中间使用了缓存服务（第一次缓存没有，是不是直接读数据源，并存入缓存；第二次直接读取缓存是否正确）；
比如需要考虑请求外部的接口获取相应的信息的时间损耗（连接不上外部接口，外部接口下线了，外部接口响应太慢）；

C.测试用例执行
1.需要你对接口协议有一定的了解，选择适当的开源工具（如postman）或者自己编写脚本进行模拟请求。
2.需要熟悉接口所使用的中间件等知识（比如redis、kafka、mysql数据库）。
3.需要模拟外部接口返回给你现在正在验证的程序的接口。（比如扣费业务，你不可能每测一个业务，就去调真实扣费）。

是web开发接口吗？建议使用Postman
一、什么是接口？
接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点，定义特定的交互点，然后通过这些交互点来，通过一些特殊的规则也就是协议，来进行数据之间的交互。
二、 常用接口采用方式：
1、webService接口：是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。可以使用的工具有apipost、jmeter、loadrunner等；
2、http api接口：是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和
post等方法，这也是最常用的两种请求方式。可以使用的工具有apipost、jmeter、loadrunner等；
三、前端和后端
前端：网站前端是对网页静态页面的设计，通俗的来说，就是我们肉眼能看的到的东西，当我们浏览网站的时候所看到的页面上的内容几乎都是属于前端，前端的工作就是网站页面，静态的页面是没有后端成分的，前端主要包括html和css外加js等一些样式和布局。
后端: 网站的后端就是动态网站的技术，比如网站上的一些注册登录和一些弹窗，这些都是后端的逻辑，常用的后端语言有php，jsp等，后端的数据库也包含myspl等，都是对后端进行存储数据。
四、 接口测试概念
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等(通俗来说就是，检查业务逻辑是否满足业务需求，校验字段是否正常你实际结果是否满足预期)
五、 接口的组成:
a、接口说明
b、调用url
c、请求方法（getpostput等）
d、请求参数、参数类型、请求参数说明
e、返回参数说明
六、为什么要做接口测试，接口测试的目标
接口其实app和前端交互用的,所以好多人问，为啥做功能测试还要测接口，目标是啥不是多此一举吗?首先我告诉大家，这种想法是错误的
那么举一个例子:
例如一个登陆接口，例如产品上规定用户名6-10个字符数字下划线，但后端没做判断。但我们业务人员测试肯定验证，但只是前端做了校验，后端压根就忘了这个小需求.那么后果来了如果一个懂的直接抓包去篡改你的接口，然后绕过校验，通过sql注入直接随意登录。如果你这是一个下单业务，是不是给公司造成了很大损失
所以此时此刻接口测试目标来了:
1.可能发现客户端没有发现的bug(那么也叫隐藏bug)
2.及早爆出风险（保证质量正常上线）
3.接口稳定了，前端随便改
4.最重要检查系统安全性，稳定性
七、如何进行接口测试
1.使用接口测试工具进行测试，接口测试和接口文档生成工具apipost，接口测试和性能测试工具jmeter
2.接口状态码表示含义
例如:200(成功)/300（重定向别的地方）/400（请求语法错误）/500(服务器异常)
测试点:
B. 参数组合（传入不同值）
C. 接口安全(绕过验证/绕过身份验证/参数是否加密等)
D. 异常验证（输入异常参数边界值）
练