接口测试基础之入门基础-接口测试流程

为什么要讲接口测试流程？

面试用

熟悉接下来该干的事情

掌握基础知识

接口测试流程中的重点是什么？

测试用例！

为什么要设计测试用例

理清思路，避免漏测

提高测试效率，按照前面的思路执行

跟进测试进度，一目了然

告诉领导做过

跟进重复性工作

用例设计

1、功能

2、逻辑业务

3、异常

4、安全

用例设计-功能用例设计

功能是否正常，是否安装需求设计

功能是否按照接口文档实现

用例设计-逻辑用例设计

是否依赖业务

入参名称为其他入参、入参名称为空、入参名称多、入参名称少、入参名称错误

数据为关键字、为空、长度不符合数据库字段、错误

需要cookie的接口

header缺失

1

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.功能：是否正常

2.逻辑业务

3.异常

3.安全

mark:

笔记

为什么要设计测试用例

接口测试流程

接口测试流程

安全测试用例设计：

1、cookie

2、header

3、唯一识别码

异常测试用例设计：数据异常

异常测试用例设计：

参数异常：

功能用例设计：

1. 功能是否正常

2. 功能是否按照接口文档实现
   

为什么设计测试用例

接口测试流程：

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

安全测试用例设计，考虑3个方面：
cookie、header、唯一识别码；

设计测试用例的好处：

接口测试流程：需求评审--场景设计--用例设计--数据准备--执行

接口请求方式为get时，请求参数附在接口地址后面，以？分隔的；当接口请求方式为post时，需要在header输入参数。

接口文档

异常测试用例：

1. 参数异常：

   关键字参数，echo，http关键字

   参数为空

   多、少参数

   错误参数

2.数据异常：

关键字数据;null

数据为空

长度不一致

错误数据

接口测试的重要流程：设计测试用例

为什么要讲接口测试流程？

1、面试用

2、熟悉接下来该干的事情

3、掌握基础知识

为什么要设计测试用例

1、理清思路，避免漏测

2、提高测试效率

3、跟进测试进度

4、告诉领导做过

5、跟进重复性工作

用例设计

1、功能

2、逻辑业务

3、异常

4、安全

用例设计-功能用例设计

①功能是否正常

②功能是否按照接口文档实现;代码接口参数名应该和接口文档统一

用例设计-逻辑用例设计

①是否依赖业务

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

①参数异常：

.关键字参数java,python,mysql这些，可以用键改为关键字进行测试。

.参数为空

.参数 多一个或少一个

.参数错误

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

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

用例设计-安全测试用例设计

①cookie

②header，移动端需要特别测试header

③唯一识别码

这里面长度不一致的情况下，是不是就不应该查询数据库了？因为长度和数据库可存储长度不同，直接属于不合法的用户名称，再执行查询的话，是不能允许也完全不需要的。

get请求中有意添加新的参数，后台返回信息表示正确，是不是应该算是业务实现上存在风险？

我记得前端如果用户添加了新的功能，在业务部分会更新到数据库。那么我在页面传参时加入权限信息，就会改变用户的权限操作范围。个人认为业务风险在此。

我在想如果我能将业务场景的相关接口都测到，在项目功能上应该不存在遗漏bug的可能性吧？但是这是不是违反了穷尽原则？