接口测试用例设计
接口测试的必要性
可以发现很多页面操作发现不了的问题
检查系统的异常处理能力
检查系统的安全性、稳定性
前端随便变，接口测好了，后端不用变
接口测试的流程
需求评审，熟悉业务和需求
开发提供接口文档
编写接口测试用例
用例评审
提测后开始测试
提交测试报告
接口文档 是接口测试的参照，至少包括：
1、接口说明
2、调用url
3、请求方法（get\post ……）
4、请求参数、参数类型、请求参数说明
5、返回参数说明
6、支持格式（xml/json）
接口测试用例设计
通过性验证：首先保证接口好用，按文档正常传入，查看是否可以返回正确的结果。
参数组合： 按接口文档中对参数的要求进行有目的的组合，比如必填未填是否通过，标志类参数值的切换是否能对应正确的功能等。（这部分很关键）
接口安全：
1)、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
2)、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
3)、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
4)、密码安全规则，密码的复杂程度校验
异常验证：不按照接口文档上的要求输入参数，来验证接口对异常情况的反应。
接口测试用例模板 （可根据项目实际情况设计增减）
1、项目 测试针对哪个项目
2、模块 哪个功能模块
3、用例id
4、接口名称
5、用例标题 测试用途概括
6、请求方式 GET/POST
7、请求url URL地址
8、请求参数
9、前置条件 执行当前请求依赖的条件，不满足就不能正确执行
10、结果验证 预期结果
11、请求报文 可以不写
12、返回报文 一定要写，这里应该是你请求返回的真实结果
13、测试结果 通过/失败
14、测试人员
测试http接口
请求常见有Get请求和Post请求。Get请求通常用来接收数据，Post请求通常用来发送数据；测Get请求可用浏览器完成，参数都可以写在URL里面，测Post请求需要借助工具如Postman，因为客户端需要提供给服务器的信息较多，你要写body传输大量数据。
接口调用有两种传参方式：key-value形式，Json串传参形式。
key-value形式可以把参数拼接在url的后面由?相连，多个参数之间用&相连，如url?parameter1=key1¶meter2=key2…
Json串传参不能把参数直接连在url中，需要写在请求的body里面，可借助工具Postman，打开请求的body写入Json格式参数（由花括号括起来的‘键：值’对）如
{
“count”: 1,
“start”: 0,
“total”: 1
}
请求发出后，http会返回一个状态码表示请求是否成功，状态码有三位，其中开头一位确定了状态类型：
2xx： 表示请求发送成功，常见200。
3xx： 代表重定向，要完成请求必须进行更进一步的操作，或把请求重定向到别的地方了，最常见的是302。
4xx： 客户端错误，请求有语法错误或请求无法实现。400代表客户端发送的请求有语法错误，不能被服务器所理解；401代表访问的页面没有授权；403服务器收到请求，但是拒绝提供服务，比如没有权限访问这个页面；404请求的资源不存在，比如输入错的URL没有这个页面。
5xx： 代表服务器有异常，500代表服务器内部异常；503服务器当前不能处理客户端的请求，一段时间后可能恢复正常；504代表服务器端超时，没返回结果。
测试WebSevice接口
不需要像测http接口那样拼报文，直接把wsdl地址或wsdl文件（这两个都由开发人员提供）填写或导入到工具SoapUI里面，工具里可显示所有相关接口或报文，直接填入参数发送请求参照接口文档查看结果即可。
Cookie 和 Session
Cookie是存在于本地的一个键值对，Session是存在于服务器端的一个键值对，通常保存在数据库或缓存里。Cookie和Session在第一次发送某个请求时成对生成，两端都会记录下生成的时间，超出既定的时限后便会自动删除。当请求在时限内再次发出后，Cookie和Session两者会相互比对，匹配上了便执行某些操作，匹配不上则不允许执行某些操作，以此实现快速处理，它们并不是孤立作用的。
