严禁转载！
最近整理的接口测试规范，待改进中。

目标

为了确保软件的功能符合业务或用户的需求，把尽可能多的问题在发布或交付之前发现并改正，确保数据服务开发的质量。

测试任务要求

开发提交测试任务：

• 需要在每个需求的正式系统测试前，预测试（冒烟测试）通过；
• 涉及鉴权、计费或白名单的接口，需要配置好；

测试内容

测试基本流程

步骤描述：根据具体情况完成各项操作

| 测试准备 |

• 需求分析、需求评审，分析业务的需求可行性。
• 完成编写测试计划和测试用例
• 测试计划、用例评审

| 测试过程 |

• 测试数据准备
• 执行脚本，测试环境打包
• 执行测试用例
• 提交缺陷并跟踪缺陷至验证通过
• 完成回归测试
• 编写测试报告

| 上线准备 |

• 验证鉴权和计费
• 验证生产环境账户是否有对应的表权限
• 接口是否有熔断配置；
• 执行sql记录查询时间，超过预期指标（目前预期指标为3s内）需要联系开发优化，并跟进直至优化达到预期目标。
• 检查接口管理系统，接口信息是否已维护

| 生产测试 |

• 测试基础功能
• 维护接口管理系统信息，例如：接口状态改为：生产
• 关注性能，例如接口响应时间；

| 生产跟踪 |

• 持续关注接口性能情况；
• 持续关注线上监控报警邮件；

API测试内容

URL规范

1、 针对公司整体业务和需求，拟定三大类url格式，在服务对接客户时 进行筛选填充

• 规范管理url地址
• url地址含义可读
• 产品编码确认
  2、产品命名 ：符合公司具体的标准要求
  3、特殊命名，特殊业务的url命名

发送信息

• 获取资源，使用 GET 方式；
• 新增、修改、删除、查询资源，使用 POST 方式

| 请求头 |

• 采用 RESTful 风格
• 请求头内容包括： Content-Type=application/json、
Authorization （授权码）

| body内容|
基础要求
参数校验：
正常的入参：

• 根据接口设计文档的入参标准，输入正常的参数，参数名需要符合标准命名；
• 请求体使用 JSON格式，命名格式小驼峰；
• 是否分页，例如：除仅查询记录一条的情况外，均需做分页处理（有特例再讨论），分页数量1000；
• 时间格式（一般为yyyy-mm-dd hh24:mi:ss）；

参数异常：

• 参数为空
• 多参或少参
• 错误的参数

数据异常：

• 数据类型错误
• 非空参数为空
• 长度不符合设计
• 不在字典范围内的数据
• 不合法的成员
• 特殊字符和敏感字符
• 存在关联关系的参数数据异常等

{
 "lastupdateddtStart": "2020-09-03 09:56:33",
 "lastupdateddtEnd": "2020-09-20 09:56:33",
 "start": 1,
 "end": 1000
}

响应信息

| 响应头 |

• 命名方式为小驼峰
• 返回基础格式固定
• 响应码（具体查看后面的响应码图）

| 响应内容 |

正常的输出参数：

• 命名方式小驼峰；
• 参数名是否符合数据接口清单标准命名；是否和数据库查询结果一致；
• pageCount是否无误（确认是否需要计算总数）；
• 时间格式（一般为yyyy-mm-dd hh24:mi:ss）；

{
    "statusCode": 200,
    "msg": "",
    "pageCount": null,
    "reqData": {
        "dataList": []
    }
  }

输出处理检查：

• 返回的数据需要有两条以上记录（只能查询到一条结果的情况除外）；
• 服务期限：检查数据时限范围是否满足数据接口清单文档要求，例如三个月、两个月等；
• 分页数据是否重复；
• 接口定义返回的错误码是否合理
• 提示是否友好，是否出现敏感信息等
• 响应耗时，是否有添加熔断配置。超时处理不当，可能会引起进程阻塞。

| 响应格式 |

• 一般默认选择json格式查看
• 选择HTML或TEXT、XML格式，检测显示是否无误

响应码，例如：
200 ：成功
202 ：数据错误
400 ：语义有误
403 ：无权限
404 ：资源不存在
415 ：调用内部接口错误
429 ：访问次数过多
500 ：未知错误

设计用例分析

| 性能测试 |

• 并发测试：仅成功一条数据，不会出现多条重复数据。
• 负载测试：大数据量测试的情况下功能是否正常，接口响应速度是否符合预期标准；

| 接口处理逻辑 |
数据库操作：

• 对数据库操作是否频繁，写库完成后进程是否释放，
• 业务数据入库是否正常，插入数据需要考虑失败时的处理是否合理，是否会出现重复数据入库，是否出现乱码；日志数据入库是否正常。
• 数据更新是否正常，尤其是时间类字段，时间是否为24小时制的格式。异步操作更新数据库同个表信息时，是否会导致锁表，特别是两个操作时间相近的情况下。
• 数据删除、备份是否正常。物理删除/逻辑删除
• 接口查询数据，输出内容是否和数据库查询结果一致

需调外部接口：

• 异常情况需考虑：存储处理、日志监控；

需推送信息接口

• 需要考虑推送失败的处理；
• 是否可以多次推送或者去重规则；

复杂的处理逻辑：

• 时序分析：复杂的系统中，是由一系列的接口按照指定顺序进行，这些接口形成一个业务流程，只有按照顺序依次执行，才能得到预期的结果，考虑在执行过程中发生其他的分支动作，程序应该怎么处理。
• 状态转换的分析：状态之间的切换是否正常；需要考虑如果没有按照正常业务流程进行操作，状态显示是否可控，是否会出现异常状态，具体怎么处理。

| 考虑历史版本的兼容性 |
与历史版本的兼容性分析：

• 是否在某种特定情况下会触发历史版本的接口，导致调用出现意想不到的问题。例如已废弃的类名或接口，代码并未注释。
• 涉及同一个系统，新接口是否受历史接口的影响，尤其是新旧接口都对同一个功能进行处理，是否存在业务不兼容的问题

| 特殊业务 |
具体参照自己公司的业务内容

| 接口设计 |
接口设计是否合理：

• 接口定义字段是否满足所有调用者的需求。例如：涉及前端联调，需先确认好接口定义字段是否满足前端页面要求。
• 接口调用是否方便，是否可扩展。例如：可以增加表来存储转换数据信息，减少使用代码。
• 接口的参数使用是否方便，是否存在歧义。例如参数，当用来“仅查询”使用‘0’，“删除”使用‘1’。

缺陷管理

缺陷应该具备以下属性：
属性名称： 描述
缺陷状态： 缺陷等级：缺陷引起的故障严重程度
缺陷标识： 产品号，缺陷的标识信息
系统名称： 缺陷所属的模块，例如接口服务
重现步骤： 详细的缺陷重现操作步骤
缺陷内容： 提供出现缺陷的信息，例如：请求信息、报错信息等，方便开发排查问题
附件 ： 与缺陷相关的附件，例如截图、文档等
优先级 ： 缺陷需要修复的紧急程度
环境 ： 明确缺陷产生的环境是测试环境还是生产环境
修复人 ： 确定需修复该缺陷的开发人员
备注 ： 对缺陷的其他描述

测试方法

使用黑盒测试方法，例如边界值测试、等价类划分法、错误推测法、因果图法等
测试工具：使用postman、jmeter等工具。

完成准则

• 对所有案例的通过率达到99%。
• 确保覆盖所有路径。
• 确保所有接口工作正常。
• 执行测试的结果要跟踪、评审。

附录

测试任务依据

测试人员必须真正弄懂需求和详细设计才能更好的完成测试工作，需要获得的相关资料的地址：