每个接口_【笔记】接口测试理论知识

什么是接口测试&＃xff1f;

接口测试是测试系统组件间接口的一种测试&＃xff0c;主要用于检测系统内部各个子系统之间&＃xff0c;系统内部与外部系统之间的交互、相互逻辑依赖等。

通俗讲就是接口的提供方、接口的调用方之间的交互、逻辑处理。

相较于UI测试&＃xff0c;接口测试提前了一步&＃xff0c;在客户端和服务器交互的中间做接口测试&＃xff0c;可以不用等待前端开发好&＃xff0c;提前开始测试。

目前我们做的是软件接口的测试&＃xff0c;本质是基于某种协议&＃xff08;http&＃xff09;&＃xff0c;发送一个Request请求给服务器&＃xff0c;然后服务器返回一个Response响应数据&＃xff0c;然后对响应数据进行分析&＃xff0c;判断是否与我们预期的返回一致&＃xff0c;从而验证功能是否正确&＃xff0c;这就是接口测试。&＃xff08;属于黑盒测试&＃xff09;

如何获取接口信息&＃xff1f;

1、开发提供详细接口文档&＃xff08;实际测试常用&＃xff09;

2、通过工具抓包&＃xff08;charles、fiddler、web端F12&＃xff09;

&＃xff08;tips&＃xff1a;浏览器按F12可以快捷打开调试页面进入开发者模式&＃xff0c;或者右键进入开发者工具&＃xff09;

URL&＃xff1a;http[s]://host[:port]/[abs_path]?[parameter]

host&＃xff1a;域名/ip

port&＃xff1a;端口

abs_path&＃xff1a;进入目标软件后想要找的地址

parameter&＃xff1a;参数

http知识点&＃xff08;下面只做简述&＃xff0c;详细参考https://zhuanlan.zhihu.com/p/101158095&＃xff09;

Header&＃xff1a;头信息&＃xff0c;包含报文的描述信息&＃xff0c;一些限制要求&＃xff1b;

Method&＃xff1a;请求方法

Request Parameter&＃xff1a;请求参数

Response Status&＃xff1a;响应状态码

Response Status常见几种

2开头&＃xff1a;正确&＃xff0c;eg&＃xff1a;200

3开头&＃xff1a;需要重定向&＃xff0c;eg&＃xff1a;302

4开头&＃xff1a;请求有问题&＃xff08;你错了&＃xff09;&＃xff0c;eg&＃xff1a;404

5开头&＃xff1a;服务器错了&＃xff08;开发错了&＃xff09;&＃xff0c;eg&＃xff1a;500

为什么做接口测试&＃xff1f;

UI测试模拟用户真实操作&＃xff0c;更贴合实际应用&＃xff0c;但缺点是强依赖于UI页面&＃xff0c;前端页面一改&＃xff0c;自动化脚本就要修改。

接口测试并不依赖UI&＃xff0c;更加稳定&＃xff0c;一般的接口写好后就不会随意更改&＃xff0c;当一个系统提供了大量的后台服务&＃xff0c;有较少甚至没有页面操作&＃xff0c;就比较适合开展接口测试。

测试难度&＃xff1a;UI>接口>单元测试&＃xff08;开发在做&＃xff09;

工作中接口测试流程&＃xff1a;

1.准备阶段&＃xff08;25%&＃xff09;

拿到开发的接口文档&＃xff0c;理解每个接口的参数和含义&＃xff1b;

了解被测系统的业务流程&＃xff1b;

编写接口测试用例&＃xff1b;

2.执行阶段&＃xff08;70%&＃xff09;

测试用例/测试场景执行&＃xff08;照着用例去Postman中配置&＃xff09;

测试数据/系统数据收集

3.分析阶段&＃xff08;5%&＃xff09;

数据汇总/日志分析

测试报告

接口测试规范文档&＃xff1a;

为了提高测试效率&＃xff0c;前期需要推动开发规范接口说明文档&＃xff08;TDD模式&＃xff0c;测试驱动开发&＃xff09;

web端如何获取接口&＃xff1f;

Charles、fiddler、F12

通过接口也可以判断bug原因&＃xff0c;若接口返回正常则为前端bug&＃xff0c;返回错误则为后端bug。

接口测试用例内容&＃xff1a;

用例ID、项目名称、模块、接口名称、请求方法&＃xff08;get/post&＃xff09;、URL、请求参数、前置条件、操作步骤、预期结果、实际结果、测试人员、备注&＃xff08;post的话需要到数据库查看&＃xff09;

接口用例编写要点&＃xff08;重点还是参数的取值&＃xff09;&＃xff1a;

1.测试每个参数类型不合法&＃xff08;注意null&＃xff09;

2.测试每个参数取值范围不合法&＃xff08;边界值&＃xff09;

3.参数为空&＃xff08;不同于null&＃xff0c;空值为传参&＃xff0c;但是该参数为空&＃xff09;

4.参数前后台定义一致性

5.参数的上下限处容易出致命bug

6.参数取值不合理的情况&＃xff08;比如取的值在该阶段不应该出现&＃xff09;

7.如果两个请求有严格的先后顺序&＃xff0c;应考虑调换顺序

注意&＃xff1a;用例设计一般考虑参数的组合、极值、是否必填&＃xff0c;类型一般不测&＃xff0c;因为在数据库中会现在类型&＃xff0c;前台用户没办法发起错误类型的请求。

接口测试流程&＃xff08;团队中&＃xff09;&＃xff1a;

与测试流程类似

1.与开发、产品梳理需求&＃xff0c;确定实现哪些接口和功能

2.编写测试计划&＃xff08;开发预估开发时间&＃xff0c;风险评估及解决时间&＃xff0c;测试人员用例准备&＃xff0c;数据准备&＃xff0c;环境准备&＃xff0c;与开发和产品协调测试时间&＃xff09;

3.测试计划review&＃xff0c;请各部门再沟通&＃xff0c;确定最终计划

4.编写测试用例和自动化脚本

5.用例review&＃xff08;该用例为最终版本&＃xff09;

6.执行测试&＃xff0c;bug提交&＃xff0c;回归

7.测试总结&＃xff08;包括测试、开发中遇到的问题&＃xff0c;如何解决&＃xff0c;对自己的启发等&＃xff09;

fiddler原理&＃xff1a;

fiddler作为浏览器的代理&＃xff0c;在信息请求和响应中间进行了拦截&＃xff0c;所有的浏览器都可以抓取。

COOKIE&＃xff1a;浏览器生成的一串标志身份的信息&＃xff0c;相当于身份证&＃xff0c;有失效时间&＃xff0c;在测试时用变量填充。

Postman中的传递参数&＃xff1a;

Params&＃xff1a;请求参数&＃xff0c;url中&＃xff1f;后面的&＃xff0c;一般为get请求中的参数&＃xff0c;用来筛选所需要查询的信息。

Header&＃xff1a;请求头&＃xff0c;一般是content-type&＃xff08;传递参数的类型&＃xff0c;post时需要加&＃xff09;&＃43;COOKIE&＃xff08;身份信息&＃xff09;

Body&＃xff1a;需求上传的数据写在Body中&＃xff0c;一般Post中才需要。

接口断言

1.响应状态码

2.响应中包含某字符串&＃xff08;html格式&＃xff09;

3.json中某个key值&＃xff08;json格式&＃xff09;

4.断言响应时间