接口测试方案（Rest类型接口）

1.1 测试需求及范围

           目前提供的接口多为Rest 规范的接口，需要使用Postman 进行接口测试。也可以尝试考虑使用JMeter 工具进行接口测试和压测，核对接口入参及返回报文格式、内容的正确性。

1.2 测试方法

           根据开发人员提供的接口访问地址、入参格式、请求格式，进行接口请求数据拼接，并查看返回结果及返回报文、响应时间，检查返回Json内容是否符合接口定义规范，是否符合预期的返回结果。

1.3 测试工具

            Postman/Jemeter

 

1.4 工具使用示例

         根据接口设计文档，获取访问url 、接口访问方式、参数、参数值，分别录入工具中，请求后，查看返回的Body 体 显示 接口返回的json串信息，测试操作参考如下图:

1.5 测试思路

首先根据接口设计的技术架构方案，了解清楚被测接口对应的公共入参、入参、出参及返回数据的Json 结构规范，根据测试场景进行测试。

1、理解接口参数，熟悉接口参数的输入要求、输入值范围、必填项等；

2、理解接口输出，熟悉返回json的结构构成、返回值类别、返回值范围、返回data的不同类型等。

3、理解接口的逻辑、接口的业务关联，熟悉技术方案中的接口相互关联、依赖的关系，接口与接口之间的数据传递等。

4、寻找测试点，根据输入(参数名、取值范围)、输出(参数名、返回值范围)、关联关系，进行测试点分析，具体分析方法可参考1.6 通用测试场景、1.7 逻辑测试场景。

1.6 通用测试场景

对于接口测试的入参需考虑以下几个方面，设计测试用例时需要考虑交叉的情况：

1、测试参数名称的正确性

1. 参数名缺失，比如参数名错误，导致参数不存在；
2. 必填参数缺失，选填参数缺失；
3. 参数名必须匹配大小写时，考虑英文大小写的传参测试；
4. 分别考虑参数名称错误的情况，
5. 参数名包括特殊字符：如中文，空格，数字，特殊符等；

 

2、测试参数值的正确性

1. 长度限制，考虑输入参数值是否字数限制；
2. 非空判断，是否可为空（不输入，即””），是否为null,是否为空格；
3. 输入值是否在正常范围内（如int 类型参数 是-32768~32767 ，输入区域外的数值）；
4. 参数传入的类型错误，如要求传入int类型，结果传入String类型；
5. 输入参数值个数不正确；
6. 必填项参数值，传入为空；
7. 参数值传入特殊字符等；
8. 参数值模糊匹配查询；

 

1.7 逻辑场景

逻辑场景考虑是对功能测试的补充，对于接口的业务逻辑场景，需要根据需求方案、技术架构中的设计的接口业务逻辑进行用例设计，例如：分页查询接口（分页查询接口涉及数据分页共5页，传入-1 表示查询全部数据），设计场景如下：

1. 传入查询页码为空，提示缺少查询页码参数；
2. 传入页码为-1，查询返回全部数据；
3. 传入页码为1，查询返回第一页数据；
4. 传入页码3，查询返回第三页数据；
5. 传入页码为5，查询返回第5页数据；
6. 传入页码为6，提示查询无数据；
7. 传入页码为0，提示查询页码参数值不正确；
8. 传入页码为01,03,05 ，可查询出1、3、5页数据；
9. 传入页码为all ，提示查询页码数据不正确；

 

1.8 测试结果检查

           对接口测试返回的结果进行核对，验证返回JSON数据的结构是否正确、返回数据值是否正确、返回数据值是否有缺失等，比如

 用户注册接口的接口返回值：

接口返回结果

1

2

3

4

5

6

7

8

9

10

11

12

{"error_code":"0",

"msg":"注册成功",

"redirect":"",

"data":{

    "rsid":"xxxx",//session会话主键

    "userinfo":{

        "userid":"xxxxxxxxx", //用户主键  

        "username":"12345678",    

        ..... 

        "create_time": 14221221124, //创建时间,int型,时间戳,

    }  

}

需要验证如下：

1、返回参数error_code ，msg,redirct ,data 是否正确返回

2、msg,error_code对应的value 不为空；

3、error_code的错误码在错误码列表范围内；

4、验证data返回的数据结构正确性、返回的参数值是否全面完整；