接口测试要点

前言:

接口和界面功能一样,都是为了达成某一个用户场景的业务。故在接口测试中,要以场景测试为主

什么是接口?

百度百科:接口泛指实体把自己提供给外界的一种抽象化物(可以为另一实体),用以由内部操作分离出外部沟通方法,使其能被内部修改而不影响外界其他实体与其交互的方式

简单来讲:把某些功能封装好,方便其他人调用。调用的人可以很方便使用这些功能,并且可以不需要知道这些功能的具体实现过程。

通俗例子(摘自知乎)
到了饭店,喊一场服务员,点餐。服务员拿出来菜单给你看,你点什么,她在小本本上记什么。点好了之后,再把菜单送到后厨去。这里服务员就是提供服务的(不然也不叫服务员),提供什么服务呢?点餐服务。
谈一个服务,通常就是要谈输入是什么,输出又是什么。从这个例子来看,输入就是一道道菜品的名字,输出的结果就是端过来的一道道菜。有了输入和输出,这个接口就实现了点餐的业务I,顾客就是调用者,服务员就是服务的提供者。

什么是接口测试?

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等

操作接口调用-接口测试调用参考

1、看接口文档

先看下需要测试的接口gateways格式的接口,还是封装的api接口。两种格式的接口调用方法不一样。看接口文档的目的是为了知道传入参数值,哪些必传,查看接口返回值对应的含义。

2、获取token

用到postman等其他接口工具,需要填写对应的接口地址
请求参数:即接口需要传入的参数字段,在例子中这里有两个字段需要传入,用户&密码。对应登录客户端时的用户密码即可进行验证,获取到token
比如存在用户xiaom,密码123456
获取到token:9e29c436-a262-4671-9d77-131494f9ebc9

3、调用接口

示例:【Api 接口增加客人电话、性别、生日返回参数】
以此接口需求为例,是增加返回的响应字段,则需要找到对应的接口
然后查看需要传参什么数值
选择调试传入对应的数值
示例:
{
“integratedRequest”: {
“hostName”: “xiaom”,
“lang”: “zh-CN”,
“optCode”: “xiaom”,
“orgUnitNo”: “00000075”,
“securityToken”: “9e29c436-a262-4671-9d77-131494f9ebc9”,
“userCode”: “xiaom”
},
“logicSymbol”: {
“map”: {}
},
“pageNum”: {
“pageNum”: “-1”,
“pageSize”: “-1”
},
“params”: {
“accDate”: “2022-03-22 00:00:00”,
“orgUnitNo”: “00000075”
}
}

接口文档有注释返回字段的含义:

示例中的需求是增加返回响应的字段,则可以先查看这里文档的响应字段是否已增加相关的说明,再调用接口查看返回的结果正确性

进行接口测试准备-接口用例编写要点

1、检查接口文档接口说明,包括接口格式,接口名称,接口请求参数/响应参数说明
注意:这个是基本,开发自己需要保证好的东西。如没有相关接口需求说明,则拒绝测试,要求提供具体实现的接口方案。

2、测试响应参数的正确性(以场景测试为主)
测试误区1:按着接口已经实现的接口传参返回开始测试 (X)
更正:需先把接口现在实现了什么先不看,而且注重这个接口需要实现什么。如何知道它需要实现的内容?
1、接口需求文档
2、需求场景说明

测试误区2:现有的请求参数和响应参数存在ID等,又无地方提供查询到这些值的地方,从数据库去找ID进行传参(X)
更正:假设已有一个查询房价代码接口,会返回房价代码编码
如要查询房价,接口如只提供房价代码的ID值去查询,这是不合理的。ID值存在数据库中,又没有其他接口提供查询房价代码ID值,则这里正常应该是传房价代码编码值,这样子才是一个合理的接口。

接口测试场景案例参考
下文中以查询房价接口为例进行说明
场景为:第三方需要知道酒店指定时间内的房价。

测试思考:
1、房价信息是从房价代码设置的获取?
2、指定时间内是指无限期的时间范围吗
3、接口取值是实时计算出来实时房价?还是有其他方式计算

接口提供了请求参数用于实现:查询房价。即有以下三大场景:
● 没有输入必填的条件或输入为空,查询不到房价(系统给出对应提示信息,此内容为最基本的测试步骤,无需花费过多的测试用例在这上面)
● 条件匹配,查询到房价
○ 有房价的场景进一步细化(细化的内容是重点,需说明准备了什么数据进行查询)
■ 对应房价存在套票信息
■ 对应房价不存在套票信息
● 条件不匹配,查询不到房价
○ 条件不匹配的场景进一步细化(此处需要了解房价代码的构成(和业务知识有关系):即房价代码由销售组织管理,房价代码内可以设置可用渠道,房价明细内可以设置房类和对应房价、套票信息)(细化的内容是重点,需说明准备了什么数据进行查询)
■ 查询的销售组织和房价代码不匹配
■ 查询的销售组织和房价代码匹配,但渠道不可用
■ 查询的销售组织和房价代码匹配,渠道可用,但不存在对应房类的房价
■ 查询的销售组织和房价代码匹配,渠道可用,存在对应房类的房价,但查询时间内无对应房类的房价、套票
在测试场景过程中,对返回的响应参数进行贴图说明,验证响应参数的正确性。
有必要时在测试报告中将传参以附件的形式贴在步骤描述中

多系统联调时应关注到接口

1、营业系统提供的接口是否符合业务场景,比如业务中需要获取到订单号,而接口返回传参中无订单号
2、接口调用顺序是否正确
比如消息模板的天气需要调用短信接口,再拼接在客人消息中进行发送。对于酒店来说,同一天的天气查询一次即可
错误案例:两个预订同一天抵店的客单,查询天气信息却调用两次,造成调用频率高

猜你喜欢

转载自blog.csdn.net/bihu2018/article/details/127652007