备注：postman接口测试插件（谷歌开发） 1.接口测试流程:需求讨论-需求评审-场景设计-用例设计-数据准备-执行 2.为什么设计用例（重） （1）理清思路，以防漏测 （2）提高测试效率 （3）跟进测试进度 （4）告诉领导做过 （5）跟进重复性的工作 2.接口测试用例设计着手点 (1)功能(2)逻辑业务（3)异常(4)安全 3.前提 （1）功能测试-找产品要需求文档 （2）接口测试-找开发要接口文档 4.接口测试-功能测试用例设计方法 （1）功能是否正常（显示success） （2）功能是否严格按照接口文档实现 （开发文档登录名写的loginname，开发时写成username是不行的，要严格按接口文档执行） 5.接口测试-逻辑业务测试用例设计方法 （1）是否依赖业务 （没有登录成功就下单是不可能的，下单时检查是否登录成功，存在依赖关系） 6.接口测试-参数异常测试用例设计方法 （1）关键字参数（将loginname该关键字改为echo，显示用户名为空，说明没有问题不能修改成功） （2）参数为空（为空时提示：账号名不能为空，服务端经过处理，没有问题） （3）多、少参数（多输入一个email参数和数值执行，如果scuess的话，说明有问题；将loginname参数和数值删掉，执行，提示用户名不能为空，正确） （4）错误参数（将关键字loginname改为username执行，点jsion查看数据结构，提示用户名为空为正常。username为错误参数，与接口文档不一致，应严格按照接口文档） 7.接口测试-数据异常测试用例设计方法 （1）关键字数据（将数据改成loginname=null，执行，提示用户不存在，把null当成一个用户或字符，所以正确） （2）数据为空（将loginname后面数据删掉，执行，提示账户名不能为空，正确） （3）数据长度不一致 （4）错误数据（输入错误的数据信息） 8.接口测试-安全测试用例设计 （1）cookie（下单、逻辑依赖业务。如不登录就下单，逻辑不通肯定会出错，如果返回数值是对的，那就说明有问题，即把cookie值删掉，点击执行，数据仍能请求成功，说明是错的） （2）header（移动端接口测试，为安全需要验证header，如果把header信息删除再执行，服务端报错） （3）唯一识别码（只在移动端接口测试应用，手机验证码）

1. 接口测试用例四个方向：功能、逻辑业务、异常、安全 

   1）功能用例：

1.功能是否正常（是否能正常返回数据）

2.功能是否按照接口文档来实现（字段名字、字段值含义）

2）逻辑用例：

1. 是否依赖业务（下单是否登录？）

3）异常测试：

1. 参数异常：

   1. 关键字参数（参数名字错误）

   2. 参数为空（参数名为空，只有参数值）

   3. 参数多、少（多出一个参数或少一个参数）

   4. 错误参数（参数名字错误）

2. 数据异常（参数值异常）：

   1. 关键字数据（参数值为NULL）

   2. 数据为空（参数值为空）

   3. 参数值长度不一致（大于数据库字段长度）

   4. 错误数据（不存在的数据）

3. 安全测试：

   1. cookie（带cookie和不带cookie）

   2. header（包含header和不包含header）

   3. 唯一识别码

一、为什么要做接口测？

1、节约时间，缩短项目时间

2、提高工作效率

3、提高系统的健壮性

二、不同接口类型的差异

1、参数提交方式

2、请求数据大小

3、安全性

三、四种不同接口： get post delete put

get和post的区别： get的数据写在地址栏，post放在表单中；post请求的数据大小可以很大，get则有限制；post提交的数据更安全。

post：后仅有接口，数据存放在WebForm中，以表单形式提交，安全性高于get；

get：后会跟一串字符串，提交数据小于post，通过地址栏的方式提交；

 接口测试概念：

1、接口的由来：连接程序前后端及移动端；不同端的工作进度不一样，需要对最开始出来的接口进行接口测试，或有时要调用其他公司接口

四种http的接口分类：post、get、delete、put;
区别：post采用的是数据放在WebForm里面以表单形式提交，数据大小更大，更安全；get直接将数据拼接到接口地址中，更小，但相对不安全

备注：postman接口测试插件（谷歌开发） 1.接口测试流程:需求讨论-需求评审-场景设计-用例设计-数据准备-执行 2.为什么设计用例（重） （1）理清思路，以防漏测 （2）提高测试效率 （3）跟进测试进度 （4）告诉领导做过 （5）跟进重复性的工作 2.接口测试用例设计着手点 (1)功能(2)逻辑业务（3)异常(4)安全 3.前提 （1）功能测试-找产品要需求文档 （2）接口测试-找开发要接口文档 4.接口测试-功能测试用例设计方法 （1）功能是否正常（显示success） （2）功能是否严格按照接口文档实现 （开发文档登录名写的loginname，开发时写成username是不行的，要严格按接口文档执行） 5.接口测试-逻辑业务测试用例设计方法 （1）是否依赖业务 （没有登录成功就下单是不可能的，下单时检查是否登录成功，存在依赖关系） 6.接口测试-参数异常测试用例设计方法 （1）关键字参数（将loginname该关键字改为echo，显示用户名为空，说明没有问题不能修改成功） （2）参数为空（为空时提示：账号名不能为空，服务端经过处理，没有问题） （3）多、少参数（多输入一个email参数和数值执行，如果scuess的话，说明有问题；将loginname参数和数值删掉，执行，提示用户名不能为空，正确） （4）错误参数（将关键字loginname改为username执行，点jsion查看数据结构，提示用户名为空为正常。username为错误参数，与接口文档不一致，应严格按照接口文档） 7.接口测试-数据异常测试用例设计方法 （1）关键字数据（将数据改成loginname=null，执行，提示用户不存在，把null当成一个用户或字符，所以正确） （2）数据为空（将loginname后面数据删掉，执行，提示账户名不能为空，正确） （3）数据长度不一致 （4）错误数据（输入错误的数据信息） 8.接口测试-安全测试用例设计 （1）cookie（下单、逻辑依赖业务。如不登录就下单，逻辑不通肯定会出错，如果返回数值是对的，那就说明有问题，即把cookie值删掉，点击执行，数据仍能请求成功，说明是错的） （2）header（移动端接口测试，为安全需要验证header，如果把header信息删除再执行，服务端报错） （3）唯一识别码（只在移动端接口测试应用，手机验证码）

二、postman能做到的 如何自动反复测试一个需要携带header的post请求，并且对针对线上、测试环境同一个数据进行测试。并对实际结果做比较，以作为测试结果？ 关键字：自动 反复 线上 线下 三、post的headers旁边的body里有内容，get会把数据都放到url中，body不可以点击。 但是cookie都是在headers里添加的 四、把接口放到collections里同一个文件夹下，可以批量执行。<箭头之后点击run就可以了 iteration：迭代次数 五、enviroment：环境 如何编辑测试环境：右上角的设置按钮，选择manage environment，输入环境名称和url 六、点击右边的code，可以选择自己熟悉的代码，选择之后，根据选择生成接口测试的代码。 七、测试：逻辑清晰、表达理解能力强、看懂代码、会写代码、会改代码、我来做。

备注：postman接口测试插件（谷歌开发） 1.接口测试流程:需求讨论-需求评审-场景设计-用例设计-数据准备-执行 2.为什么设计用例（重） （1）理清思路，以防漏测 （2）提高测试效率 （3）跟进测试进度 （4）告诉领导做过 （5）跟进重复性的工作 2.接口测试用例设计着手点 (1)功能(2)逻辑业务（3)异常(4)安全 3.前提 （1）功能测试-找产品要需求文档 （2）接口测试-找开发要接口文档 4.接口测试-功能测试用例设计方法 （1）功能是否正常（显示success） （2）功能是否严格按照接口文档实现 （开发文档登录名写的loginname，开发时写成username是不行的，要严格按接口文档执行） 5.接口测试-逻辑业务测试用例设计方法 （1）是否依赖业务 （没有登录成功就下单是不可能的，下单时检查是否登录成功，存在依赖关系） 6.接口测试-参数异常测试用例设计方法 （1）关键字参数（将loginname该关键字改为echo，显示用户名为空，说明没有问题不能修改成功） （2）参数为空（为空时提示：账号名不能为空，服务端经过处理，没有问题） （3）多、少参数（多输入一个email参数和数值执行，如果scuess的话，说明有问题；将loginname参数和数值删掉，执行，提示用户名不能为空，正确） （4）错误参数（将关键字loginname改为username执行，点jsion查看数据结构，提示用户名为空为正常。username为错误参数，与接口文档不一致，应严格按照接口文档） 7.接口测试-数据异常测试用例设计方法 （1）关键字数据（将数据改成loginname=null，执行，提示用户不存在，把null当成一个用户或字符，所以正确） （2）数据为空（将loginname后面数据删掉，执行，提示账户名不能为空，正确） （3）数据长度不一致 （4）错误数据（输入错误的数据信息） 8.接口测试-安全测试用例设计 （1）cookie（下单、逻辑依赖业务。如不登录就下单，逻辑不通肯定会出错，如果返回数值是对的，那就说明有问题，即把cookie值删掉，点击执行，数据仍能请求成功，说明是错的） （2）header（移动端接口测试，为安全需要验证header，如果把header信息删除再执行，服务端报错） （3）唯一识别码（只在移动端接口测试应用，手机验证码）

get 请求比POST的要小，get请求数据在请求头，并展示在地址栏中，但是地址栏是有数量限定的，post请求在请求体中，存放于（wefrom）表单中

1. 接口分类：get post pul delete
   

2.  测试用例：功能、逻辑业务、异常测试、安全

3. fiddler  postman  pyhon开发
   

接口测试流程

需求讨论-需求评审 - 场景设计- 用例设计- 数据准备- 执行

用例设计：功能 逻辑业务  异常  安全

用例设计-异常测试用例设计

参数异常：关键字参数 。 参数为空。 多，少参数。 错误参数。

数据异常：关键字数据。数据为空。长度不一致。错误数据。

安全测试用例设计：1.cookie 2.header.3.唯一识别码

【【李师师笔记】】

借口分类： post get delete put  【参数提交方式不同】

接口post和接口get的区别：【请求数据大小不同，安全性不同】

post后面跟了只有一个接口，其请求数据放在webform里面，以表单形式提交；比较安全。

get 后面很多字符串（所有的数据都拼接在地址栏里面），通过地址栏提交，提交的数据是要小一些的，因为地址栏提交的大小有上限，从而安全性也较差。

#定义代码格式
#-*- coding:utf8 -*-
from urllib import request
from urllib import parse
from urllib.request import urlopen
url = "http://xapi.kybyun.com/user/login"
#定义请求数据并赋值
headers = {}
headers = {
        'Host': 'xapi.kybyun.com',
        'Connection': 'keep-alive',
        'User-Agent': 'BangXueTang AipBot/1.0(BangXueTang-IOS/2.1.3.1;IOS/9.30;iPhone 6 Plus)',
        'KY-UKEY': '940cd0dffd371d41eb0acbb7694fd5e9',
        'KY-SYDEV': 'iPhone 6 Plus',
        'KY-SPEID': '10010101',
        'KY-SCHID': '1044',
        'KY-APPCHG': 'AppStore',
        'Connection': 'keep-alive',
        'KY-UUID': '6ff7563dbd47c8077905c3920bc0d8b3',
        'KY-YEAR': '2017',
        'Accept-Language': 'zh-Hans-CN;q=1',
        'KY-SYSVER': '9.3',
        'Accept': '*/*',
        'Content-Type': 'application/x-www-form-urlencoded',
        'KY-APPVER': '2.1.3.1',
        'KY-APPVERS': '4',
        'KY-APPTYPE': '21'
}
data = {}
data['appchg'] = 'Appstore'
data['apptype'] = '21'
data['appver'] = '2.1.3.1'
data['email'] = 'mushishi01'
data['isblind'] = '0'
data['passwd'] = '111111'
data['sysdev'] = 'iPhone 6 Plus'
data['sysver'] = '9.3'
data['uuid'] = '6ff7563dbd47c8077905c3920bc0d8b3'
#对数据进行编码
data = parse.urlencode(data).encode(encoding='UTF8')
#对post的数据进行合并
req = request.Request(url, data, headers)
#打开请求获取对象
requestResponse = urlopen(req)
#读取服务端返回的对象
responseStr = requestResponse.read()
#将密码进行转译（因为密码用的是MD5的，对应上边）
ResponseStr = responseStr.decode("unicode_escape")
#打印数据
print(ResponseStr)

一、接口测试流程：

需求讨论->需求评审->场景设计->用例设计->数据准备->执行。

二、为什么要设计测试用例？03:10

1. 理清思路，避免漏测（如果没有理清思路就开始测试，而且是随机测试，肯定会有一些漏测的地方、一些关键的逻辑点，在上线后就难免会出现一些bug）

2. 提高测试效率（当我们有了思路，后期只需要按照思路执行就可以，提高了效率）

3. 跟进测试进度（测试了多少，还剩下多少）

4. 告诉领导做过（确实测过，有可能是其它问题导致的问题）

5. 跟进重复性工作（如果大量的重复同一件事，能保证每一次都一样吗？但根据用例，每一次都按照用例去执行就OK）

就不会有漏测、丢失的情况了，所以我们要设计测试用例。

三、用例设计05:15

接口测试需要从以下设计：

1. 功能（功能是否实现了05:30，功能是否按照需求进行设计的【接口测试：是否按接口文档实现06:31】）

2. 逻辑业务（是否依赖业务08:00）

3. 异常（见四、异常设计08:43）

4. 安全（cookie、header、唯一识别码(移动端)18:30）

四、异常测试用例设计：参数异常 ，数据异常

1、参数异常08:48

（1）关键字参数异常

（2）参数为空

（3）多、少参数

（4）错误参数

2、数据异常14:53

（1）关键字数据（数据部分为关键字如null）

（2）数据为空

（3）长度不一致（规定长度）

（4）错误数据

接口的类型 ：post  get  delete  put 

一、get和post的区别：

1. post：post请求的数据是放在WebForm里面的，以表单形式提交

2. get：get 请求的数据都拼接在地址栏里，地址栏有数据大小限制，不安全