自动化接口测试用例（接口自动化测试案例）

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

本文目录一览：

• 1、接口自动化测试测试用例设计
• 2、Apifox写接口自动化测试用例总结-1
• 3、Apifox写接口自动化测试用例总结-2
• 4、关于自动化测试用例失败重试的一些思考
• 5、如何简单设计接口测试用例
• 6、如何写好自动化友好的测试用例

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

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

一、   前言   

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

二、   测试用例设计思路   

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

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.可以选择右侧的“魔法棒”动态值来选择变量/常量或动态变量

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
第四步：前置脚本编写

关于自动化测试用例失败重试的一些思考

自动化测试用例失败重跑有助于提高自动化用例的稳定性，那我们来看一下，python和java生态里都有哪些具体做法？

如果是在python生态里，用pytest做测试驱动，那么可以通过pytest的插件pytest-rerunfailures来实现失败用例重跑，具体的使用方式有两种，一种是通过命令行指定pytest --reruns 2 --reruns-delay 1，reruns表示重复运行次数，reruns-delay 表示重复运行是的延迟时间。另一种方式是通过@pytest.mark.flaky(reruns=2, reruns_delay=1)，这种方式一般运用，不想全局所有的测试用例都重跑，只是特定的测试用例需要跑，那就在特定的测试方法上使用这个标记。

如果是在java生态里，用junit做测试驱动，junit5提供了注解@RepeatTest(2)，可以试下测试类或者测试方法的重复运行，也可以自定义，通过实现个TestRule接口，来控制测试用例的运行。

还有就是如果使用到了maven可以添加一个rerunFailingTestsCount参数，不过这个是控制所有的用例了。

为什么要让失败用例重跑呢
因为自动化一般都会在测试环境或者其他非线上的环境，由于环境的不稳定可能会导致测试用例莫名其妙的失败，是用例的稳定性大打折扣。这个时候加入失败重跑机制，能够在一定范围内提高测试用例的稳定性，做出更多的产出。

接口自动化测试用以建议可以加入这种失败重跑，而对于UI接口接口自动化，失败重跑的话，觉得意义不大，因为往往当用例的失败的时候，要么是由于界面元素没加载出来，要么是用例的逻辑有问题，要么是意外的弹窗影响，这个时候应该让错误尽早的抛出来，好尽快的修复，而不是在哪儿一个劲的重试，没啥用。UI自动化应该做好显式和隐式等待。

在测试框架中，最好能区分出什么样的异常时服务异常，什么是测试框架本身的异常，对于服务异常可以适当重试，对于框架异常不进行重跑，直接抛出。断言失败当然更不需要重跑。所以在控制测试用例执行的时候，不要一股脑儿的全都重跑，有选择性的，既要保证稳定性，还要保证效率，让自动化发挥价值。

测试要做到有的放矢，在合适的时候做合适的事情，自动化测试的价值就是因为它能快速的检查系统，如果因为重试导致运行的时间成倍增加，是没有任何意义的，还不如抛出错了，尽快去解决。而且自动化测试用例的运行顺序也要控制，处于业务前方的接口尽量先跑，处于业务后方的接口尽量后跑。比如登陆接口和下单接口，登陆接口属于业务靠前的，下单是靠后的，一般在测试下单接口的时候都要初始化登陆状态，这个时候会调用登陆接口，在测试用例批量执行的时候，可以先让登陆接口测试用例先跑，如果这个接口有问题，那么其他需要登陆接口配合的用例全都会失败，那这样后面的用例就不用跑了，这样会节省很多的时间。

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

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

如何写好自动化友好的测试用例

1.步骤和数据的分离自动化接口测试用例：
好的测试用例，在执行的步骤(Step）的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：
1) 密码正确的登录
2) 密码错误的登录
3) 密码输入三次错误，卡被锁定
4) 取少于余额的款项
5) 尝试取大于余额的款项
6) 尝试取等于余额的款项（考虑手续费）
6) 取款额度大于当次的限制
7) 取款额度大于当天的限制
8) 取款次数大于限制次数
等等
不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下（此处只列出自动化接口测试用例了操作的步骤，略去了系统的交互中的反馈结果）：
1) 插入卡-A:输入密码-B:按“确定”键-重复A-B
2) A:选择取款功能-B:填写取款金额-C:点击“确定取款”的按钮-D:取现金-重复A-D
因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢自动化接口测试用例？
2. 单独的测试基础数据准备工作
第一个例子中的输入数据比较简单，但我们同样需要考虑的一个问题是：在测试中究竟我们输入什么样的具体数据呢？什么是”正确的密码“？什么又是”大于余额的款项“呢？
对
于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至也有其自动化接口测试用例他外部系统导入、传输或计算出的数据。一个比较好的做法是，将这些测试数据提前准备好，

在每个阶段性测试前导入到系统中。一个比较典型的例子，假设要求你单独去测试几张复杂的财务报表，用其自动化接口测试用例他的模块和外部系统，自己逐一的去创造数据，那会非
常耗时耗力。这时，基础数据的准备就显得尤为重要，以此才能保证测试工作是高效的、测试结果是精确的。
如果有可能，复杂的测试基础数据最好是提前准备好的，类似这里例子中简单的
一个帐号为1234567890，密码为66666的有效银行卡，里面有人民币1000元正，等等。将这些内容预先准备好（可以用自动化工具来准备，或导
出已有的数据为一个SQL的脚本），写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。
3. 测试用例的前置条件和后置条件
除
了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。比如准备一个初始设置条件下的IE
浏览器和已安装过老版本该软件的XP系统。这些可重用的准入条件，可以考虑不作为特定用例的Step，而是把它提取出来，作为Setup
Section或叫Pre-Condition。
对于后置条件或Post-
condition，往往我们用它来做一些处理或恢复，比如在上面的取款例子中，如果我们要用相同的帐号重复测试，在正好取完所有金额，余额为零的情况
下，可以通过一些步骤或数据库脚本重置帐号余额。同样，您为某个用例设置浏览器禁用了Cookie，执行完该用例后，是不是也是需要回复到默认设置的状态
呢？
集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。
顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。
4. 常用业务操作(Knowledge Base)
对于一个大型的应用，比如银行系统，开发和测试工作是长期的，持续的一个过程，这样的系统很适合引入自动化测试。它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell，Python等），也存在了很多可用的遗留脚本。
这些完成一些预定业务操作的脚本单元，是可以直接借用的。为了在公司和产品层面，管理好这些可复用的资源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即可。
举
例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信息，并保存结果，这可能是个复杂而底层的处理过程，对一般员工是不
需要，也没有权限去深入掌握的。这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统一建档，在以后的项目测试中，只要调用就可以了。如
此，可以大大提高各个有相关接口的模块的自动化测试工作效率。
根据以往工作中常见的一些问题，对于如何写好测试用例（不仅针对自动化测试），做以下做几点补充：
推荐
不推荐
将用例的内容描述清楚，强调怎么操作，验证什么，然后期待的结果是什么。
Copy需求和设计文档中的内容；描述成：什么条件下，逻辑会是怎样。这样对测试用例的阅读和执行人员，不具有可操作性。
期待的结果要写具体，如：系统反应是什么；结果数字是多少；用户被带到什么页面；显示什么成功信息；后台或数据库中该记录的修改后结果是怎么样的。
描述成：”验证系统返回正确结果“；”页面元素显示跟SPEC一致“；”操作成功“等 比较抽象的说法。
业务逻辑性较强的应用软件，做到以业务流为主线，来组织用例。
以页面形式组织用例。
以Module、Function、测试类型、基本业务流、备选业务流的树状结构形式，分层次组织用例；使用用例管理工具。
Word格式的扁平组织结构，不利于管理和阅读。
用一个属性字段，建立用例和Spec等文档的某个章节间的映射。
无法和需求对应，以后难以计算 用例覆盖率，测试执行覆盖率。
每个Module、Function、特定业务的一组测试用例，之间做到独立、没有耦合。
用例之间有依赖，无法做到：挑选30%的用例做回归测试。
在时间和成本允许的情况下，尽量做到：用例粒度为“一种不同的操作，得到不同的结果，就单独写一个用例“。
在用例中的操作步骤中，甚至期待结果中，仍然存在条件分支。
对于复杂的业务操作过程，如”一次顺序的表单签核过程“和”一次完整的信贷手续“，单独增加一些贯穿整个业务流的大型测试用例。
对于一个长业务操作，只存在比较零散的细节用例。
将用例分优先等级，便于在回归测试时挑选核心业务或用户操作密集的用例。
用例 没有优先级和重要程度的定义。 关于自动化接口测试用例和接口自动化测试案例的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 自动化接口测试用例的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口自动化测试案例、自动化接口测试用例的信息别忘了在本站进行查找喔。

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