严禁转载！
最近整理的接口测试规范，待改进中。
目标
为了确保软件的功能符合业务或用户的需求，把尽可能多的问题在发布或交付之前发现并改正，确保数据服务开发的质量。
测试任务要求
开发提交测试任务：
- 需要在每个需求的正式系统测试前，预测试（冒烟测试）通过；
- 涉及鉴权、计费或白名单的接口，需要配置好；
测试内容
测试基本流程
步骤描述：根据具体情况完成各项操作
| 测试准备 |
- 需求分析、需求评审，分析业务的需求可行性。
- 完成编写测试计划和测试用例
- 测试计划、用例评审
| 测试过程 |
- 测试数据准备
- 执行脚本，测试环境打包
- 执行测试用例
- 提交缺陷并跟踪缺陷至验证通过
- 完成回归测试
- 编写测试报告
| 上线准备 |
- 验证鉴权和计费
- 验证生产环境账户是否有对应的表权限
- 接口是否有熔断配置；
- 执行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%。
- 确保覆盖所有路径。
- 确保所有接口工作正常。
- 执行测试的结果要跟踪、评审。
附录
测试任务依据
测试人员必须真正弄懂需求和详细设计才能更好的完成测试工作，需要获得的相关资料的地址：
