区别于传统意义上的系统级别测试，很多测试人员在接触到接口测试的时候，也许对测试执行还可以比较顺利的上手，但一提到相关的归档，比如测试用例和报告，就有些不知所措了。
今天就用这篇文章来说说接口测试用例和报告。
1. 接口用例模板
提到测试用例，我们知道，其中最重要的两个要素就是：
- 测试步骤
- 预期结果
其实对于接口测试也同样如此；接口测试的步骤中，最重要的是将实现向接口发送预设请求，结果则要关注响应信息及后续处理。
所以接口测试用例编排可以考虑下列两种形式：
要注意的是，实际工作场景中我们可能还会对接口之间的串联和混合场景进行测试。
2. 测试报告模板
接口测试报告很多时候会和接口性能测试报告一起，如果要单独报告的话，可以考虑以下内容：
2.1 系统接口概况
简要描述与测试项目相关的一些背景资料，如被测系统简介，项目上线计划等。
对于系统接口的定义和设计做出介绍，比如系统一共有多少个接口？采用哪种协议？都涉及到哪些发送方法？采用怎样的请求格式？使用怎样的返回标准？可用表格说明。
2.2 测试目的与范围
描述本次接口测试的目的、范围与目标，内容应与本次接口测试的《接口测试实施方案》中的对应内容保持一致。
2.2.1.测试目的
本次测试的目的在于确保系统接口功能和逻辑处理已验证，符合《接口定义说明书》的定义和要求，满足系统需要。
2.2.2. 测试对象范围
说明测试的对象是哪些
- 单场景接口功能测试
- 混合场景接口功能测试
详见《项目接口测试用例》可考虑贴出x-mind图
2.2.3. 测试指标范围
- 被测接口接收请求和返回报文
- 被测接口返回状态
- 被测接口对应业务逻辑处理
- 涉及数据沉淀的处理
- 复杂场景下多接口串联交互
2.3 测试工具及资源
2.3.1. 测试工具
说明本次测试使用到的测试工具和辅助工具
1. 测试工具：该测试将使用Postman（例）
Postman是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get、 post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运 行，并支持用例导出、导入。
2. 辅助工具：略
2.3.2. 测试资源
|
组 |
成员 |
职责 |
|
总负责 |
张三 |
各组间工作协调、方案评审 |
|
测试组 |
李四 |
需求分析，测试方案编写，脚本编写，执行测试以及编写测试报告 |
2.4 测试记录及结果分析
2.4.1. 单场景接口测试
2.4.1.1 测试结果数据
给出本次单场景接口测试的测试结果数据
|
用例 |
场景描述 |
被测接口 |
测试结果 |
备注 |
|
API001 |
用户登录接口 |
/user/login |
通过 |
|
|
API002 |
用户登出接口 |
/user/logout |
失败 |
Defect:41335 |
|
...... |
|
|
|
2.4.1.2. 测试问题及结果分析
结合测试中发现的问题对于整体测试结果进行分析，做出判断。
- l 接口业务功能错误类缺陷情况
- l 接口异常处理类缺陷情况
- l 接口处理数据沉淀缺陷类情况
- l 接口安全性缺陷情况
2.4.2. 混合场景接口测试
2.4.2.1. 测试结果数据
给出本次混合场景接口测试的测试结果数据
|
用例 |
场景描述 |
被测接口 |
测试结果 |
备注 |
|
APIm001 |
用户登录、搜索商品、查看商品 |
/user/login /commodity/search /commodity/pdp |
通过 |
|
|
APIm002 |
用户登录、修改个人信息、上传头像 |
/user/login /user/personalInfo /user/personalInfo/portrait/upload |
失败 |
Defect:41510 |
|
...... |
|
|
|
2.4.2.2. 测试问题及结果分析
结合测试中发现的问题对于整体测试结果进行分析，做出判断。
- l 混合接口业务功能错误类缺陷情况；
- l 混合接口业务数据传递类缺陷情况；
2.5 测试结论
给出本次性能测试的测试总结论，一般以测试结果与测试目标的比较结果作为测试结论。
