接口自动化测试,Apifox写接口自动化测试用例总结-2
接口自动化测试,Apifox写接口自动化测试用例总结-2详细介绍
本文目录一览： 我眼中的接口测试和接口自动化测试
当然，在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要，思路就会清楚一些。
前后端分离结构：现在很多系统都采用前后端分离架构，各服务之间更多的是通过接口来实现信息互通，对接口进行直接测试，可以更全面的覆盖各类测试场景。
就是使python去实现接口测试，说白了就是写一些测试逻辑。python去写，速度快，简单python也有很多自动化测试相关的工具。roboframework，是一个自动化测试框架，写自动化非常简单。
说简单的接口自动化大致三个步骤：a-发送请求；b-解析结果；c-验证结果为了方便起见，你应该自定义三个和业务相关的测试类：一个用来封装httpclient，用来发送请求的类，昌平java课程建议用于发送各类测试请求。
接口编写方便。方便调试接口。支持数据初始化。生成测试报告。支持参数化。robotframework优点关键字驱动，自定义用户关键字。支持测试日志和报告生成。支持系统关键字开发，可扩展性好。支持数据库操作。
接口自动化测试俗称
冒烟测试。接口自动化测试俗称冒烟测试，接口自动化，其基本原理就是：模拟前端向后台发送http请求，得到响应的请求数据，对数据进行分析，从而判断接口是否正常。接口自动化不会浪费大量的人力、物力、资源的信息，对产品的测试程度相对来说比较高。
接口自动化测试框架？
关于自动化测试项目中会分成许多的不同的测试模块，而今天我们就一起来了解一下，关于接口的自动化测试框架都有哪些比较常见的类型。下面回龙观java课程就开始今天的主要内容吧。
需求：
1、接口编写方便。
2、方便调试接口。
3、支持数据初始化。
4、生成测试报告。
5、支持参数化。
robotframework
优点
关键字驱动，自定义用户关键字。
支持测试日志和报告生成。
支持系统关键字开发，可扩展性好。
支持数据库操作。
缺点
接口测试用例写起来不简洁。
需要掌握特定语法。
结果：不考虑，没人愿意这么写接口用例。
JMeter
优点
支持参数化
不需要写代码
缺点
创建接口用例效率不高。
不能生成查看每一个接口执行情况的测试报告。
总结：不考虑，接口编写不方便，主要是不能生成测试报告，如果做接口性能的话可以考虑。
HttpRunner
优点:
基于YAML/JSON格式，专注于接口本身的编写。
接口编写简单
生成测试报告
接口录制功能。
缺点:
没有编辑器插件对语法校验，容易出错。
官方文档没有详细的说明。
扩展不方便。
接口自动化测试测试用例设计
浅谈接口自动化测试测试用例设计
一、 ? 前言 ??
很多中台项目，大部分为接口测试。为了使新入职的测试同事尽快融入项目，以及迭代开发中方便管理测试用例。完成该总结。
二、 ? 测试用例设计思路 ??
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输入不为空的测试用例重复，所以选择一条用例验证 。 ），以上的测试用例满足自动化的要求，手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性，无需检查输入参数的类型。
我眼中的接口测试和接口自动化测试
接口测试的目的是为了增加测试覆盖度、深入度 ，对接口的各个参数做实际场景中很难遇到的异常场景的测试，保证接口的稳定性。如果在这个前提下接口测试还是没有发现 bug，那么可以 review 下历次迭代中是不是业务测试发现的所有 bug 都是前端的。如果是，那么说明你们的后端开发工程师能力实在很强，应该恭喜你们遇到了这么给力的队友。在测试压力很大的情况下就可以酌情考虑不做接口测试，前端测试完成就上线了。
如果不是那就应该 review 你们的接口测试用例了。是不是用例设计的还不如业务测试全面？是不是用例设计的时候默认按照正常的取值范围？按照正常的业务逻辑进行的用例设计导致用例的覆盖还不如业务直接黑盒测出来的覆盖全。
自动化测试的主要目的不是发现多少 bug ，而是为了快速对接口做回归、做线上监控等，避免接口出现了低级问题、阻碍问题但是大家不能第一时间知道，等过了很长时间线上出了强反馈或者在错误接口的基础上又做了很多开发才被大家发现。当然，在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要，思路就会清楚一些。
整体上测试是为了保证业务中的 bug 能够在有限的资源下最大量、最快速的发现，业务实际情况不同、测试团队规模不同、测试与业务的合作模式、测试团队成员的技术能力等等都会影响测试方案的制定。
个人觉得如果团队有专人做接口测试，这种情况下接口测试定位到用来发现更多 bug 是没有问题的，如果没有发现 bug 那就需要仔细找找接口测试用例设计的问题。接口测试的目的不是取代业务测试，而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量。接口自动化测试的目的是在回归场景节约业务测试的工作量，在新业务测试中实际反倒会占用更多的测试资源。
以上是作者拉拉肥对接口测试以及接口自动化测试的理解。你怎么看？欢迎点击 原文链接 在原帖共同讨论。
接口自动化和功能自动化的区别
区别是测试的功能性质不同。1、接口自动化测试是根据数据的入参返回相应的结果，不考虑实际行为，只根据输入来得到输出数据，重心在于数据的传入输出是否符合规范。2、功能自动化测试方案是为XXX系统功能测试使用自动化工具，实现以自动化测试为主的目标而编写的技术和实施方案。
Apifox写接口自动化测试用例总结-1
最近决定用Apifox写接口自动化测试用例，于是研究了这个工具的具体实践，下面把最近实践过程中遇到的问题和解决方案进行总结，方便回看。
Apifox它是集：接口文档管理、接口调试、Mock、接口自动化测试于一体的全流程集成工具，覆盖从开发->测试->管理等环节，等同于 Postman + Swagger + Mock + JMeter几款工具功能累加。
下面从以下几个方面来进行总结： 1json path语法及使用 2.参数化使用 3.结果验证
JsonPath语法要点： $ 表示文档的根元素 @ 表示文档的当前元素 .node_name 或 ['node_name'] 匹配下级节点 [index] 检索数组中的元素 [start:end:step] 支持数组切片语法 ** 作为通配符，匹配所有成员** .. 子递归通配符，匹配成员的所有子元素 (
) 使用表达式 ?(
)进行数据筛选
直接从返回结果中获取第一个元素
从返回结果中获取iata=3Q的子节点中的id号
1.用两个{}的形式来传参，如{{flightId}} 2.如果提取变量是列表形式，可以取其中某一个，如{{flightId[0]}} 3.可以选择右侧的“魔法棒”动态值来选择变量/常量或动态变量
接口自动化测试环境搭建jmeter+ant+git+jenkins
1、安装java
方式一：安装java环境：yum install java-1.8.0-openjdk* -y
使用命令检查是否安装成功 java -version
到此安装结束了。这样安装有一个好处就是不需要对path进行设置，自动就设置好了。jdk安装在/usr/lib/jvm目录下
方式二：先下载对应版本到本地，然后解压缩，配置环境变量（详细步骤百度即可）
2、安装jmeter
(1)登录自己服务器，在usr/local下创建文件夹jmeter,命令mkdir jmeter
(2)通过官网下载jmeter到本地
(3)通过xhell上传到对应的目录（cd到要上传的目录）
(4)yum -y install lrzsz（安装了lrzsz，执行该命令是因为服务器有的文件不让上传。让上传就不用执行）
(5)使用 rz -y命令进行文件上传，此时会弹出上传的窗口，进行上传即可
(6)上传成功之后进行解压 unzip apache-jmeter-5.4.zip
(7)配置环境变量vi /etc/profile
esc+shift # 键盘同时按住，退出编辑模式
:wq # 保存退出
:q # 不保存退出
添加如下内容：
# set Jmeter enviroment
export JMETER_HOME=/usr/local/jmeter/apache-jmeter-5.4
export PATH=${PATH}:${JMETER_HOME}/bin
(8)source /etc/profile # 使配置文件生效
(9)jmeter -version
3、安装ant
（1）在usr/local下创建文件夹ant,命令mkdir ant
（2）通过官网下载ant到本地
（3）使用 rz -y命令进行文件上传，此时会弹出上传的窗口，进行上传即可 sz 文件名(服务器文件下载到本地)
（4）上传成功之后进行解压 unzip
（5）配置环境变量vi /etc/profile
# set Ant enviroment
export ANT_HOME=/usr/local/ant/apache-ant-1.10.10
export PATH=${PATH}:${ANT_HOME}/bin
（6）source /etc/profile # 使配置文件生效
（7）ant -version
4、ant的配置
（1）将jmeter安装包extras文件夹里ant-jemter-1.1.1.jar 复制到antlib下
cp ant-jmeter-1.1.1.jar /usr/local/ant/apache-ant-1.10.10/lib
（2）进入apache-jmeter-3.0extras运行ant ，查看该目录下是否出现Test.jtl、Test.html文件，若有，则构建成功
5、编写Ant的build.xml文件
（1）创建Jmeter_Test目录，放在/usr/local/下
（2）Jmeter_Test目录下创建build.xml、ResultLog（html,jtl）、Script（放脚本）
（3）build.xml文件内容去https://www.cnblogs.com/L-Test/p/9736808.html下复制，需要修改里边的路径
6、jenkins安装
（1）Jenkins下载地址：https://jenkins.io/download/
（2）下载的是jenkins.war
（3）在Linux下启动Jenkins有两种方式，一种是在jenkins.war的存放目录下使用命令java -jar jenkins.war启动，
另外一种是把jenkins.war放在tomcat的webapps目录下，然后启动tomcat就可以了（本次用的第一种）
（4）在浏览器中输入http://服务器ip:8080/jenkins/
如果是用的阿里云服务器，启动成功之后，在浏览器访问，无法访问。解决办法就是登陆阿里云服务器修改一下安全规则，把端口范围调大
（5）访问成功之后输入管理员密码
（6）安装推荐的插件，创建管理员用户
7、jenkins的其他配置
（1）修改为中文依赖的三个插件localization-zh-cn、locale、localization-support
jenkins插件下载地址https://blog.csdn.net/qq_39530199/article/details/90266654
（2）不知道依赖于那个插件，可以看看manage Jenkins里边的报错 plugin is missing
8、git的安装
（1）git下载地址：https://mirrors.edge.kernel.org/pub/software/scm/git/
（2）usr/local下新建git目录，cd到git,安装包上传上来， tar -zxvf v2.17.0.tar.gz
（3）安装编译源码所需依赖，命令为： yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl- ExtUtils-MakeMaker 耐心等待安装，出现提示输入y即可；
（4）安装依赖时，yum自动安装了Git，需要卸载旧版本Git，命令为： yum remove git 出现提示输入y即可；
（5）进入解压后的文件夹，命令 cd git-2.17.0 ，然后执行编译，命令为 make prefix=/usr/local/git all 耐心等待编译即可；
（6）安装Git至/usr/local/git路径，命令为 make prefix=/usr/local/git install ；
(7)打开环境变量配置文件，命令 vim /etc/profile ，在底部加上Git相关配置信息
# set Git enviroment
export GIT_HOME=/usr/local/git
export PATH=$GIT_HOME/bin:$PATH
（8）git version
9、jenkins安装相应插件
（1）安装源码管理选择git需要的插件git、git-server、git-client、github-api、plain-credentials、github
上传插件的时候可能会报错，可以把插件上传顺序改一下在上传
(2) jenkins设置git的安装路径，点击全局工具配置/usr/local/git/bin/git（whereis git 命令可查看）
（3）windows本地安装git，把代码推送到github(需要在github创建一个仓库)，参考自动化测试的 《
（4）jenkins配置源码管理选择git，地址输入github项目地址，账号可以先在jenkins凭据配置中添加github账号
输地址或账号的时候可能会报403的错误。解决办法刷新一下或者 在Configure Global Security中开启 启用代理兼容
（5）配置完源码管理，直接进行构建，代码自动下载到/root/.jenkins/workspace/git/路径下
10、接下来需要把build.xml中脚本路径改为/root/.jenkins/workspace/git/进行构建，可以在Github里提交一个jmx文件构建一下试试
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 第四步：前置脚本编写
自动化测试框架都有哪些
按框架的定义来分，自动化测试框架可以分为：基础功能测试框架、管理执行框架。按不同的测试类型来分，可以分为：功能自动化测试框架、性能自动化测试框架。按测试阶段来分，可以分为：单元自动化测试框架、接口自动化测试框架、系统自动化测试框架。按组成结构来分，可以分为：单一自动化测试框架、综合自动化测试框架。按部署方式来分，可以分为：单机自动化测试框架、分布式自动化测试框架。