- 系统之间的接口
- 服务之间的接口
- 系统内部的接口
- 接口自动化测试与界面自动化测试
- 接口自动化测试比界面自动化测试收益高，优先级高
- 界面开发、后台业务逻辑的开发是不同的人，前后台的开发进度不一样。接口测试让测试迁移，在界面尚未开发出来时，测试人员就能投入测试，投入越早，发现缺陷修复的成本越低
- 接口测试可以发现一些界面发现不了的问题
- 界面对参数做了检查，非法的值限制输入，通过接口可以做一些异常测试
- 一些场景比较复杂，通过界面很难构造出来
- 淘宝：APP版本、小程序版本、网页版本、平板、IOS，功能一样，对应后台的数据一样
- 数据存储、业务逻辑的处理在服务端完成，通过接口测试可以模拟更多场景
- 前台只是负责页面的展示
- 数据存储、业务逻辑的处理在服务端完成，通过接口测试可以模拟更多场景
- 接口测试的成本低、收益高、界面是频繁变换的。后台的接口一旦固定，很少变化
- 界面对参数做了检查，非法的值限制输入，通过接口可以做一些异常测试
- 界面开发、后台业务逻辑的开发是不同的人，前后台的开发进度不一样。接口测试让测试迁移，在界面尚未开发出来时，测试人员就能投入测试，投入越早，发现缺陷修复的成本越低
- 获取接口文档：
- 接口功能
- 接口URL
- 请求方法
- 请求参数
- 返回包数据的实例
- 返回码的解释
- 接口功能
- 分析文档及需求
- 设计接口测试方案
- 设计接口测试用例
- 开发测试脚本
- 接口测试执行
- 输出接口测试报告
- 用工具或代码模拟客户端向服务器发送请求报文，服务器接收请求报文后，对相应的报文做处理并将处理的结果返回给工具或代码，工具或代码对返回的结果进行校验。
- 接口测试是黑盒测试
- 参数测试：
- 参数的边界值、等价类
- 必填的参数、可选参数、异常：必填的参数不填，或者必填和可选之间参数组合
- 参数为空、参数值为空
- 多参数、少参数
- 参数的默认值是不是正确，是不是合理
- 参数的边界值、等价类
- 业务逻辑：
- 单接口
- 业务交互的测试：提交订单，先去校验用户有没有登录
- 登录>>提交订单，成功
- 用户未登陆>>提交订单，报错
- 登录>>提交订单，成功
- 返回值的测试
- 各种错误码
- 查询类的接口，可能没有参数。比如说查询用户列表
- 0条数据
- 1条数据
- 100000条数据
- 1000000条数据
- 0条数据
- 报表类的接口，大数据，数据库中有大量的数据，通过（算法）接口生成一个报表/趋势图，如何测试
- 通过构造不同的数据，看上你工程的图表是否正确
- 通过构造不同的数据，看上你工程的图表是否正确
- 各种错误码
- 性能测试
- 安全测试
- 敏感信息是否加密，密码、简单的密码，同一个密码每次加密后的字符串是否相等
- 敏感信息不能记录到日志。pwd（操作日志、系统日志）
- 接口防攻击的处理，在1分钟内调用100次以上的话，认为受到攻击，限制IP/用户访问系统
- 参数前后台都要去校验
- 前台的校验（界面测试）是为了提示给用户，防止用户输入不合法的数据，且出错时能有提示
- 后台的校验（接口测试）是防止黑客绕过前台，通过接口直接访问后台，如果后台不校验，非法数据可以直接写入数据库，且遭到攻击
- 前台的校验（界面测试）是为了提示给用户，防止用户输入不合法的数据，且出错时能有提示
- 敏感信息是否加密，密码、简单的密码，同一个密码每次加密后的字符串是否相等
- 单接口
- 特点：
- 媒体独立
- 发送给种类型的数据：文本、图片、音视频...
- 发送给种类型的数据：文本、图片、音视频...
- 无连接
- C/S结构，基于TCP/UDP，长链接的，登录后保持连接的状态
- B/S结构，基于HTTP，短连接，连接只在一发一收时保持，收发结束的时候连接断开
- C/S结构，基于TCP/UDP，长链接的，登录后保持连接的状态
- 无状态
- 因为是短连接，本次发送请求前，不知道以前发送过什么
- 因为是短连接，本次发送请求前，不知道以前发送过什么
- 媒体独立
- 传输内容：HTTP请求：
- 请求报文：
- 请求行，方法，url（get请求的参数在url中）、协议版本号
- 请求头部
- 空行
- 请求体，post请求带的参数
- 请求行，方法，url（get请求的参数在url中）、协议版本号
- get请求：百度搜索
- post请求：百度翻译
- Content-Type: application/x-www-form-urlencoded; charset=UTF-8
- Content-Length: 17
- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
- Content-Type: application/x-www-form-urlencoded; charset=UTF-8
- 请求报文：
- 常用的方法：get、post
- get：获取资源，查询类的参数
- post：增删改查资源
- get和post区别：
- 传参的方式不一样
- get把参数放到请求中，url？key=value&key=value&key=value
- post请求吧参数放到请求体中
- get把参数放到请求中，url？key=value&key=value&key=value
- get请求不安全，post请求安全
- get请求参数暴露在url中
- get请求的参数在url中，url有长度的限制，但是post参数在请求体，没有参数的限制。
- get请求传的参数是key=value格式的，post可以传任意类型的参数，content-type设置参数的类型。
- get请求和参数可以保存成浏览器的历史记录，post的参数保存不到历史记录中。
- get请求可以保存为书签，post请求不可以。
- get请求参数暴露在url中
- 传参的方式不一样
- HTTP是无连接、无状态的
- 比如访问淘宝，A用户浏览商户，B用户将商品加购物车里。系统怎么判断把商品加到B的购物车，而不是A的购物车
- 比如访问淘宝，A用户浏览商户，B用户将商品加购物车里。系统怎么判断把商品加到B的购物车，而不是A的购物车
- 用户识别的功能，Cookie、Session、Token技术
- Cookie：识别客户身份的信息记录在客户端。（身份证）
- 存储在客户端
- 不可跨域
- 名字：就是给Cookie起一个名字。
- 值：Cookie中记录的信息内容。
- 路径与域：Cookie的作用范围。
- 过期时间：如果不设置过期时间，称作会话Cookie，浏览器关闭的时候失效；设置过期时间后，称作持久Cookie，等到过期时间时失效。
- 其他
- Set-Cookie：服务器响应头中带的
- Cookie：客户端请求头中带的。
- Cookie存放在客户端的本地，同一个用户多次登录、多台机器上登录，服务器分配的Cookie信息不同。
- Set-Cookie：服务器响应头中带的
- 存储在客户端
- Cookie：识别客户身份的信息记录在客户端。（身份证）
- Session：识别客户身份的信息记录在服务器端，客户端有一个Sessionld（比如工厂来访的人在客户列表才可进入）
- Cookie与Session对比
- Cookie保存在客户端，Session保存在服务器，Session更安全
- Session在服务器的内存中、数据库、文件，如果用户量比较大，会占用服务器的资源
- Cookie有效期长，Session有效期短
- Cookie保存在客户端，Session保存在服务器，Session更安全
- Token：
- 客户端频繁登录服务器，服务器每次都要判断用户名密码，查询比较频繁，服务器压力大
- 客户端频繁登录服务器，服务器每次都要判断用户名密码，查询比较频繁，服务器压力大
- HTTP与HTTPs的差别
- 使用HTTPs的网站要去数字认证机构申请CA证书，证明服务器与浏览器的身份。证书需要年费。
- 默认端口号不一样。HTTP端口号是80，HTTPs端口号是443。
- HTTPs的技术门槛较高。
- HTTPs加重了服务端的负担，降低了用户的访问速度。
- 使用HTTPs的网站要去数字认证机构申请CA证书，证明服务器与浏览器的身份。证书需要年费。
- 对Requests加断点：比如注册接口，界面对密码做了限制，只能输入5~18位的密码，超过这个范围的不能输入。要测试密码异常的场景，可以用Fiddler先抓到正常的报文，然后将参数的值修改为非法的，比如19位的密码后，再发送。看服务器是否能正常处理。
- 增加断点：bpu https://www.baidu.com/s （https://www.baidu.com/s 是百度搜索的接口地址）
- 取消断点：bpu
- 增加断点：bpu https://www.baidu.com/s （https://www.baidu.com/s 是百度搜索的接口地址）
- 对Response加断点
- 增加断点：bpafter https://www.baidu.com/s
- 取消断点：bpafter
- 增加断点：bpafter https://www.baidu.com/s