文章系列
[质量提升之道]－Code Review
[质量提升之道]－UT&Coverage
[质量提升之道]－测试左移动&提测质量管控
[质量提升之道]－Phabricator 的安装

前言

一晃到年底了，没想到工作忙得会拖这么久，为了完成年初立下的 flag，这段时间会多分享，算是对今年的回顾。
对于接口测试，在招聘中很多应聘者知其然而不知其所以然，所以说要做好一项工作，就要脚踏实地，做深做细，这样有利于成长。
本篇基于 Http 协议的接口测试，来自于工作中的总结，不足之处请斧批。

基础知识

常用的请求方法：
GET（获取）、POST（修改）、PUT（上传）、DELETE（删除）
常用状态码分类
2xx：成功
3xx：重定向
4xx：客户端错误
5xx：服务器端错误
常用状态码说明
200---/请求已经正常处理完毕
301---/请求永久重定向
302---/请求临时重定向
304---/请求被重定向到客户端本地缓存
400---/客户端请求存在语法错误
401---/客户端请求没有经过授权
403---/客户端的请求被服务器拒绝，一般为客户端没有访问权限
404---/客户端请求的 URL 在服务端不存在
500---/服务端永久错误
503---/服务端发生临时错误

报文解读

重点介绍下通用头部和请求头部
通用头部
Request URL: 如果是 GET 请求，url 会以［?参数名 1=参数值&参数 2=参数值......］的形式带上请求参数
Request Method: 指定请求方法
Status Code: 状态码，能帮助定位问题

请求头部
Accept: 端客户端能接收的内容格式类型，服务端收到后就知道该返回什么格式类型的 response
Content-type: 请求的内容类型，服务端收到后就知道，对请求参数按何种类型解析。这是容易忽视的知识点，测试开发必须掌握。
常用类型说明
application/xml： XML 数据格式
application/json： JSON 数据格式
application/octet-stream： 二进制流数据（文件下载）
application/x-www-form-urlencoded： form 表单数据以 key/value 格式发送到服务器（默认的提交数据的格式）
multipart/form-data： 在表单中进行文件上传时，使用该格式

响应头部

传参途径

1.GET 方法传参
以下示例，表示请求第 1 页，每页显示 10 条数据，项目名称不限
http://localhost:8018/project/queryByPage?projectName=&pageNo=1&pageSize=10
2.POST、PUT 等方法，通过 Content-type 指定内容格式传参
以 Json Body 为例

3.URL 路径传参，常用于 RESTful 风格的接口，参数就在路径中可以看到
以下示例，表示发出请求，删除参数为 598529da5cf6476389fa5bbccf42caa8（主键）的数据
http://localhost:8018/project/delete/598529da5cf6476389fa5bbccf42caa8
4.Request Headers 传参
示图中，Authorization: cf4e0c15-b2ae-4f6f-abb3-c2c3fbf1fe11，就是请求头部发送给服务端的 Token

测试要点

总则：
设计测试用例，接口定义、预期结果以接口文档或等价于接口文档的介质为准，所有接口都必须包含正向用例和反向用例。
1.必填/非必填校验
2.取值范围校验
请求参数的取值必须限定在某个范围内（例如：1~99），或指定枚举值（例如：男、女），范围内、外的场景都要覆盖
3.非法参数类型试错
尝试使用非法的字段类型，接口是否能正确处理
4.长度校验
5.精度校验
6.边界值校验
7.开关控制校验
由某个请求字段控制切换，使用不同的功能（为了减少强耦合，一般不允许这么设计，每个尽量保持原子性）
8.空字符串校验
9.权限校验
有的接口必须获取 ticket 或 token 之后才能访问
10.错误码校验
确保每个错误码都能对应相应错误场景
11.幂等性校验
有的接口必须保证多次调用和一次调用的效果是一样的
12.安全性校验
有的项目对数据安全敏感，需要脱敏、掩码、加密等处理，当然，这只是安全性的一小部分
13.返回数据的正确性校验
确保返回的数据和数据库拉取的数据是一致的
14.数据入库的正确性校验
确保接口处理的数据在数据库已正确插入、更新、删除
15.数据唯一性校验
有的写入接口，对数据有唯一性要求，重复插入应反馈给调用方
16.冗余数据检查
检查查询接口是否返回了不需要的冗余数据
17.业务性校验
有的接口和业务强相关，例如：登录接口，账密连续错误会触发锁账号的处理
18.大数据查询设计检查
如果接口查询可预期的数据量会增长的很大，必须使用分页查询，否则就是接口设计的缺陷
19.异步接口校验
如果接口是异步处理的，报文只是告诉你已经在处理了，必须确保其真的在工作了
20.单接口性能
平均响应时间如果耗时过长（超过 3~5 秒），需要从整个调用链的每个节点来排查性能问题

性能测试

按场景设计！按场景设计！按场景设计！重要的事说三遍
要求业务方给出使用场景、预估调用量、业务场景。因为不同的场景，会有不同的数据输入，相同的接口＋不同的请求参数，往往其性能会有很大差异。
关于需要关注的性能指标，包括但不仅限于：吞吐量/秒、平均响应时间、网络 I/O、磁盘 I/O、内存、CPU 等。
相对于执行性能测试，更核心的工作还是性能结果分析，例如：内存溢出是配置不合理还是代码问题、频繁 GC 是 JVM 配置不合理还是代码问题、调用量大而失败，网络 I/O 不再增长说明存在带宽瓶颈等。

关于测试先行

测试先行需要靠测试、开发、产品一起完成，这个对团队、流程管理、提出更高的要求。
测试先行不止适用于接口测试，接口测试只是一个切入点。
说到这里，有必要搬出 TDD，测试驱动开发（Test-Driven Development），TDD 包含 UTDD 和 ATDD
验收驱动测试开发：ATDD（Acceptance Test Driven Development），ATDD 其实是包含 BDD（Behavior Driven Development）、EDD（Example Driven Development），FDD（Feature Driven Development）、CDCD（Consumer Driven Contract Development）等各种的实践方法。
单元驱动测试开发：UTDD（Unit Test Driven Development）就是我们通常理解上的 TDD
说的通俗一点，就是以下几种场景：
先写设计代码，再写业务代码！
先写设计代码，再写测试用例/单元测试，最后写业务代码！
先写测试用例，再写接口设计/单元测试，最后写业务代码！
Swagger 大家应该都知道，可以自动生成接口文档，往往很多团队使用不当，接口文档和接口同时生成，是不是感觉有点奇怪？正确的姿势如下：

@ApiOperation(value = "获取API信息", notes = "获取API信息")
@PostMapping("/info")
// 先定义接口设计：接口名、资源路径、请求方法、请求参数、响应结构
/**
   约束条件
   字段A：String类型，最大长度8，必填
   字段B：枚举类型，取值范围（男、女）
   ......
   错误场景：
   ......
**/
public ResponseDto<DocResp> getApiInfo(@RequestBody final DocReq request) throws Exception {
    ResponseDto responseDto;
    // 业务代码可以生成接口文档后再补充
    return responseDto;
}

有了明确的设计契约，开发人员就可以思路清晰的编写单元测试，最后再写业务代码。这样，代码质量会不会有质的提升呢？
关于 TDD，可能很多人理解的比较模糊甚至是错误的，推荐看这篇文章，TDD 已死？让我们再聊聊 TDD