接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试的流程和功能测试流程类似，依据的对象是需求说明书和接口需求，接口测试流程如下：
1) 业务功能（包括正常、异常场景是否实现）
2) 业务规则（覆盖度是否全面）
3) 参数验证（边界、业务规则是否达到要求）
4) 异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
5) 性能测试（响应时间、吞吐量、并发数、资源要求）
6) 安全测试（权限验证、SQL 注入等）
接口测试的主要测试对象是接口，但是随着系统复杂度越来越高，接口越来越多，完全覆盖所有接口是很难的一件事情，并且实际过程中任意内部接口的变动都可能导致我们的测试用例的不可用。
优先级-->针对所有接口
暴露在外面的接口，因为通常该接口会给第三方调用；
供系统内部调用的核心功能接口；
供系统内部调用非核心功能接口；
优先级-->针对单个接口
正向用例优先测试，逆向（异常）用例次之 (通常情况，非绝对)；
是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制
| 是否满足前提条件 | 有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆 Token。逆向用例：针对是否满足前置条件 (假设为 n 个条件)，设计 0~n 条用例 |
| 是否携带默认值参数 | 正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的 “常规” 值，其它不填写，设计 1 条用例； |
| 业务规则、功能需求 | 这里根据实际情况，结合接口参数说明，可能需要设计 n 条正向用例和逆向用例 |
| 参数是否必填 | 逆向用例：针对每个必填参数，都设计 1 条参数值为空的逆向用例 |
| 参数之间是否存在关联 | 有些参数彼此之间存在相互制约的关系,逆向用例：根据实际情况，可能需要设计 0~n 条用例 |
| 参数数据类型限制 | 逆向用例：针对每个参数都设计 1 条参数值类型不符的逆向用例 |
| 参数数据类型自身的数据范围值限制 | 正向用例：针对所有参数，设计 1 条每个参数的参数值在数据范围内为最大值的正向用例,逆向用例：针对每个参数 (假设 n 个)，设计 n 条每个参数的参数值都超出数据范围最大值的逆向用例,针对每个参数 (假设 n 个)，设计 n 条每个参数的参数值都小于数据范围最小值的逆向用例 |
1.不同的接口参数覆盖不同的业务场景；
2.在后台构造合适的数据来满足接口的测试用例；
3.根据接口的返回值，断言其是否返回期望结果，并查看数据库验证；
4.测试用例涉及多个步骤的，应对涉及的步骤都验证
5.删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境
抓包工具
个人比较喜欢 Charles,但是也可以使用 fiddler 或者其他的抓包工具jmeter 使用 dome
（1） 基础配置，如域名、环境配置等，单出文件配置，方便不同环境测试、脚本维护
（2） 明确接口实现什么样的功能，实际需要什么样的功能，是否一致
（3） 接口测试数据太多，用该数据驱动模式更有层次，且易于维护
（4） 要在众多测试用例中选出冒烟测试用例及可用于性能测试的用例
（5） 先单接口测试，在多接口业务测试
（6） 测试完成以后，需要清洗脏数据
接口测试环境准备
针对以上五种生产 jmeter 脚本快速生产的方案，都可以很好的辅助编写 jmeter 的脚本，在这里很多同学肯定会问为什么不使用 metersphere，这个项目本身很优秀了，但是由于公司的原因，所以最后放弃，很多同学肯定想，录制生成，直接回访就完事，我只能说太简单，这样你的脚本使用一次基本就报废， 会造成脚本的重复编写费时费力，这个时候，需要测试强硬一点了大家采用统一的录制控制方式去录制，同意脚本编写的方案，毕竟在怎么录制都是不行的，所以最好的实践方式就是采用录制为主，修改为辅的解决方式，去编写复用率高的脚本
相信 jmeter 很多测试小伙伴都很熟悉，肯定也都熟悉他有一个最大通病，就是 case 太多的时候，一点都不方便管理， 其实这个问题，我也遇见了，因为现在的团队不只是我一个人单打独斗，我还有队友，所以对 jmx 脚本的管理，我在团队里面采用的时 git 管理我们的脚本，我们在团队内部和开发约束，测试环境的时候，所有的部署都走 test 的一个代码分支，这样做的好处，就是为了减轻 jmx 脚本的复杂性，同时也避免了在发布生产环境的时候，将脚本发布到生产环境，因为最初的初中使用 jmeter 做接口测试的情况下，就是因为团队开发的同学不写单元测试，测试同学会 Java 的只有一两个，服务又多，公司的迭代速度又快，开发提测的功能一直没有很好的健壮性，所以，我在想能不能在开发部署成功的时候或者定时轮询执行一下每个服务的接口，以达到提测的质量。在团队实践中也遇到了一些问题如下：
针对以上的问题，我个人是如下解决的，首先 token 校验的问题，纯在这个问题的根本原因，是因为我们每次登录都是图片验证码的登陆，但是我又不能识别，只能求助开发经理，让他在测试环境给我们测试写了一个万能验证码，再拿这个这个验证码去刷新 token 和或获取对应的 op（op 参数是内部特有的验证）
数据的唯一性，这个当时头疼了好久，最后只能去百度，最后发限 jmeter 还有很强大的功能，就是函数助手，里面有各种函数，例如获取时间戳，随机数，生成 uuid 等，直接开箱即用
熟悉 mysql 的小伙伴都知道 MySQL 的默认最大连接数是 200 数据库连接池老是超标，最后查看了 mysql 日志发限连接数占用最大的是开发的代码里面写了很多多表联查的大 SQL，尤其是公司大数据那帮人的 sql 一个 SQL 语句执行半个小时，，，，因为去年 mtsc 深圳站的时候，听了唯品会的同学分享接触到了，sql 扫描检查，当时在 sonar 扫描代码的时候，加入了 sql 的扫描，和开发老大商量，去除了项目中大部分的长 sql 语句，最后去请教了运维的同学和公司 dba 的大佬，当时运维同学有点不配合的，最后买了一包好烟，在加各种舔，最终终于同意扩大数据库的连接数，最终勉强解决了这个问题
jenkins 并发机制的问题，这个是 jenkisn 本身就存在的瓶颈，当时给公司运维提了个需求，让他多起几个 jenlkins 的的节点，测试专门使用一个节点
由于使用了 jmeter 为了测试的时候，可以实时查看，个人建议使用 influxdb+cadvisor+grafana 搭建一套配合 jmeter 的报告可视化的监控系统
创建容器挂载目录
mkdir -p /dockerdata/influxdb
mkdir -p /dockerdata/grafana
安装 influxdb 数据库
docker run -d \
-p 8083:8083 \
-p 8086:8086 \
--expose 8090 \
--expose 8099 \
--name influxsrv \
-v $PWD:/var/lib/influxdb \
influxdb;
安装 cadvisor 容器监控
docker run \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:rw \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
-p 8081:8080 \
--detach=true --link influxsrv:influxsrv \
--name=cadvisor \
google/cadvisor:latest \
-storage_driver=influxdb \
-storage_driver_db=cadvisor \
-storage_driver_host=influxsrv:8086;
安装 grafana
docker run \
-d \
-p 3000:3000 \
-e INFLUXDB_HOST=localhost \
-e INFLUXDB_PORT=8086 \
-e INFLUXDB_NAME=cadvisor \
-e INFLUXDB_USER=root \
-e INFLUXDB_PASS=root \
--link influxsrv:influxsrv \
-v $PWD:/var/lib/grafana \
--name grafana \
grafana/grafana;
最终结果如下
需要注意的点
接口测试经常遇到如下的 bug 和问题：
（1）传入参数处理不当，导致程序 crash;
（2）类型溢出，导致数据读出和写入不一致；
（3）因对象权限为进行校验，可以访问其他用户敏感信息；
（4）状态处理不当，导致逻辑出现错乱；
（5）逻辑校验不完善，可利用漏洞获取非正当利益等；
接口自动化框架：Jmeter+maven+Jenkins+git
<dependency>
<groupId>org.apache.jmeter</groupId>
<artifactId>ApacheJMeter_components</artifactId>
<version>5.4.1</version>
</dependency>
因为在上面我们说了我们使用了自己的 Backend Listener 插件，由于网络原因，所以在运行 docker 容器的时候，我们需要将 jmeter 容器使用-v 参数挂在到本地
在加上网络的原因，我们只能自己制作镜像了，制作镜像的 dockerfile 如下
FROM java:8
ENV http_proxy ""
ENV https_proxy ""
RUN mkdir /jmeterdocker
RUN mkdir -p /jmeterdocker/test
RUN mkdir -p /jmeterdocker/test/input/jmx
RUN mkdir -p /jmeterdocker/test/input/testdata
RUN mkdir -p /jmeterdocker/test/report/html
RUN mkdir -p /jmeterdocker/test/report/jtl
RUN mkdir -p /jmeterdocker/test/report/outputdata
RUN chmod -R 777 /jmeterdocker
RUN cd /jmeterdocker
ENV JMETER_VERSION=5.4.1
ENV JMETER_HOME=/jmeterdocker/apache-jmeter-${JMETER_VERSION}
ENV JMETER_PATH=${JMETER_HOME}/bin:${PATH}
RUN wget https://archive.apache.org/dist/jmeter/binaries/apache-jmeter-${JMETER_VERSION}.tgz
RUN tar -zxvf apache-jmeter-${JMETER_VERSION}.tgz
RUN rm apache-jmeter-${JMETER_VERSION}.tgz
需要注意的点
因为使用了 docker 启动运行容器，那么在运行完成之后，需要在对应的 shell 脚本中接入如下命令在每次运行构建之前删除对应的容器
docker rm - f [容器name]
测试前置、开发自测
关于持续自动化回归测试的建议：
