API测试
什么是 API？
API 是(Application Programming Interface)首字母缩略词，即应用程序编程接口。 API 是一组用于构建软件应用程序的规程，协议和工具。API 充当软件应用程序之间的接口，并允许两个软件应用程序相互通信。 API 是一组软件功能，可以由其他软件执行。
什么是 API 测试？
API 测试是一种软件测试方法，涉及直接测试 API，也是集成测试的一部分，用于检查API 是否满足应用程序的功能和可靠性，性能和安全性方面的期望。在 API 测试中，我们主要关注软件架构的业务逻辑层。
常见的 API 测试类型有哪些？
API 测试通常涉及以下实践：
· 单元测试 ·
功能测试 ·
性能（负载）测试 ·
运行时/错误检测 ·
安全测试 ·
UI 测试 ·
互操作性和 WS 一致性测试 ·
渗透测试 ·
模糊测试
API 测试中使用的一些常用协议？
HTTP
dubbo
REST
SOAP
· thrift ·
JMS ·
UDDI ·
API 和 Web 服务之间的区别？
Web 服务：
所有 Web 服务都是 API ·
所有 Web 服务都需要通过 Web(HTTP)公开 ·
Web 服务只有三种使用方式：SOAP，REST 和 XML-RPC 进行通信
接口：
·API 有很多并不基于 HTTP ·
API 使用多种方式进行通信，例如 C / C ++中的 DLL 文件，java 中的 Jar 文件/ RMI，Linux 内核 API 中的中断等。
最常用的 HTTP 方法
· GET：从服务器检索数据
· POST：将数据添加到服务器中的现有文件或资源 ·
PUT：它允许您替换服务器中的现有文件或资源 · DELETE：它允许您从服务器中删除数据 ·
PATCH：用于对资源进行部分修改 选项：用于描述目标资源的通信选项 ·
HEAD：它要求响应与 GET 请求相同，但没有响应正文
聊一聊怎么设计接口测试用例，这是我个人的心得，欢迎指正。
考虑测试成本与测试覆盖面，尽可能多的对某个接口进行更多的测试，发现更多的问题，也要节约时间和成本，所以需要做组合与取舍，不要想着做穷尽测试，也做不到吧
接口测试用例的设计
举个简单的例子：
有一个接口，被调用会根据调用的参数类型，返回GIF动图或者静态图片的链接
请求参数
|
字段名 |
参数名 |
必填 |
参数类型 |
示例值 |
参数描述 |
|
phototype |
图片类型 |
是 |
Int(2) |
0 |
0:静态图片 1:动态图片 |
|
cusid |
请求方id |
是 |
String(20) |
cus001 |
请求方的id |
|
passkey |
通信密钥 |
是 |
String(20) |
f53ab43de4c5d2e4 |
服务方与请求方约定的通信密钥 |
|
timestamp |
时间戳 |
否 |
String(20) |
1469762577350 |
当次请求的时间戳无业务内容 |
返回结果
|
字段名 |
参数名 |
必填 |
参数类型 |
示例值 |
参数描述 |
|
res |
返回结果 |
是 |
String |
根信息 |
|
|
res:res_code |
返回码 |
是 |
String |
0 |
0:表示获取成功 其他码见表【错误码】 |
|
type |
类型 |
是 |
String |
0 |
0:静态图片 1:动态图片 |
|
purl |
图片地址 |
是 |
String |
http://pg.com/ss.png |
图片的url地址 |
请求示例
http://domainname/photoserver/getphoto?phototye=?cusid=?passkey=?timestamp=
返回示例
成功
{
"ret":
{
"res_code": "0",
"res_msg": "获取成功",
“type”:”0”,
“purl”:”http://pg.com/ss.png”
}
}
失败
{
"ret": { "ret_code": "28500", "ret_msg": "系统异常" }
}
错误码
|
错误码 |
描述 |
原因 |
解决方案 |
|
28404 |
无图片 |
图片资源找不到 |
查验图片服务器使之可用 |
|
28400 |
请求参数错误 |
参数内容/类型错误 |
传入正确的参数 |
|
28500 |
服务器错误 |
未知原因 |
开发人员排查 |
测试接口，注意关注的方面
所有业务逻辑一定要100%通过
异常情况校验（参考接口文档的错误码，进行扩展设计）
边界值（其实这个不是必须的，有些接口没必要做）
① 、针对业务逻辑的设计
思考一下这里有多少个业务场景？
一般来说首先都会想到的是这两个要达成的业务逻辑：
a:返回静态图片
b:返回动态图片
这个接口就是为了实现a与b而设计存在的。针对这两个逻辑，设计用例
cusid / passkey /timestamp都应该是符合接口要求的参数类型与内容，而phototype传入的是0/1/其他值，这里就验证是否按类型返回对应类型的图片资源
预期应该是
0：返回静态图片资源
1：返回动态图片资源
其他值：返回错误码28400请求参数错误
这两个逻辑，是最基本的了
还有两个参数：cusid/passkey，查看接口文档，这个两个参数组合起来是一个请求方的唯一认证，这其中逻辑就是，服务方通过这两个参数去鉴别过来请求图片资源的请求方是否合法，不合法就不可以请求，合法了才能继续请求，所以这里这个逻辑要进行验证，有如下情况
A:cusid与passkey合法，可以继续请求
B:cusid与passkey不合法，处理到此终止，返回错误码28400，参数错误
针对B，再进行细分，两个参数组合其一非法，二者都非法共三种情况
（当然啦，这里有个安全问题，passkey一般不是这么用的，但是我只是为了解释方便，就先这么用了把它用在参数上面，正常这个passkey应该用在加密算法当中来加密请求参数，然后服务端解密参数再进行处理，而不是暴露在参数当中）
② 、针对入参设计
- 必传值不传
- 非必传都不传
- 非必传都传
（针对传不传，其实有时候可以看下代码会一清二楚，比如spring-java中对参数传与不传有注解：required=true/false代表必须非必须）
- 传值规则，传空值/空格串（也可以先看看代码有没有做判断，一般会写一个校验参数的工具类，JSR303规则Validator类）
③ 、针对返回结果设计
④ 、针对异常情况设计