接口测试 [质量提升之道]-接口测试

扫地僧 · December 06, 2018 · 2027 hits

文章系列
[质量提升之道]-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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
No Reply at the moment.
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up