接口测试

接口测试：接口是联系前端和后端的桥梁，负责数据的传输，或者移动端和服务端的桥梁。
1. 接口分类：a.get， b.post， c.delete， d.put
2. 接口测试工具三剑客：Fildder， postman，python自己开发
3. get和post请求的区别：
a.get以“？”为分隔，有参数数据；post直接显示的接口，post请求的数据是放在WebForm里面，以表单形式提交的
b.将数据放在地址栏中（get请求），提交数据小一些；WebForm以表单的形式请求数据多；
c.以表单的形式请求数据较为安全

为什么要做接口测试?
不同端的工作进度不一-样
需要对最开始出来的接口进行接口测试

1、节约时间,缩短项目时间
2、提高工作效率
3、提高系统的健壮性

示例：
postman中
在最上面的地址信息栏输入地址点击发送：
下面是服务器端返回的信息，选为json格式：

如果将发送的请求中loginname去掉，那么就会报错了
客户操作，然后系统会不断地调用接口，比如银行，支付宝

接口的分类

接口测试流程

为什么要设计测试用例
理清思路,避免漏测
提高测试效率
跟进测试进度
告诉领导做过

对于接口的用例设计

1.功能
2.逻辑业务
3.异常
4.安全

用例设计–功能用例设计
1.看功能是否都能实现
（比如在postman中，输入连接，如果返回的数据，数据结构是正确的，那么认为功能是正确的）
2.功能是否按照接口文档实现
例1：比如博客园添加随笔，需要登录才能添加。也就是业务要求不支持游客添加随笔功能，如果设计一个没有登录的用户，然后去测试添加随笔接口，结果接口能添加到随笔，说明功能不正常，不符合需求和接口文档描述。
例2：接口文档里描述了登录，而且他有两个参数，一个是用户名，一个是密码：

虽然功能实现了，但是写的时候把loginname写成了user，虽然功能实现了，但是这样是不合理的，因为开发的接口文档是给所有的开发用的，其他人都用的login，他自己用了user，最后肯定是会出问题的呀

用例设计–逻辑用例设计
是否依赖业务
比如你要下单，那你是不是应该先登陆成功呢？登陆之前需要短信验证

用例设计–异常测试用例设计
参数异常
1.关键字参数（开发语言里的关键字，html，mysql，php等）
比如把以下的登录名和密码改成关键字

返回提示账户名不能为空，说明是没问题的
2.参数为空
将以下本来是loginname的变为空，返回提示账户名不能为空，说明是没问题的
3.多、少参数、
No1.多参数：多写一个email邮件

竟然返回成功了？？那是不是应该给开发反馈呢？因为这是接口测试呀，这是不合理的

No2.少参数：把下图框起来的给删掉，

返回账户名不能为空，说明没问题

4.错误参数
把以下的loginname，password如果改成username，pdd会是什么反应呢？

用户名改了：

密码改了：

数据异常

1.关键字数据关键字
把loginname对应的内容改成NULL，提示用户不存在，说明他把null转义成了一个用户

2.数据为空

3.长度不一致
数据库建表的时候对每个字段有长度限制，所以在请求验证的时候，应当验证输入的内容是否超长
比如将loginname=123123123123234354666…非常长，却只提示了用户不存在，那么是不是就不大合理呢？特别是对银行这种，这种情况是不允许存在的

4.错误数据
输入错误的账号信息，当然就

总结：
不管数据异常还是参数异常，测试点差不多，一个参数有key和value，key表示参数，value表示数据。第一，看看参数和数据能不能支持关键字，例如Java中的保留关键字等等。第二个就是参数和数据都为空，看看是否做了判断。第三个，参数多和少，例如有两个参数的接口，你需要设计一个三个参数的用例，一个只有一个参数的用例。数据那边长度不一致，例如设计很长的字符串是否支持，因为数据库创建表过程都设置好了每个字段的长度。输入错误的参数和数据，例如故意输出单词等等。

用例设计–安全接口测试用例设计

1)cookie：有cookie才能获取数据，如果不带cookie还有信息返回，说明有问题
2)header：正常接口带header信息，删除header看是否能够返回数据。
3)唯一识别码：app手机识别码，一般是唯一的。
安全测试主要从上面三点检查。第三个是唯一识别码，主要是指app上手机的识别码，一般很少用到，除非很严格的接口测试，例如银行app登录，需要指纹，而指纹来源手机，一般有一个手机识别码判断过程。

1、cookie；
下单或者一些逻辑依赖业务用，比如说如果用户都没登录，就可以下单，那是不是不应该成功，如果成功的话，是不是就应该报错。
例子：
有header值，有cookie信息

是会把从服务器端获取的一些信息返回给我们

如果把这个header信息的cookie删掉，服务器端却没有验证，而是仍然返回了信息，说明这个接口是不合格的。