接口测试 接口测试所需要的特殊数据:如不同状态的 ID,怎么自动构造数据和清除数据呢

Leticia · 2017年06月06日 · 最后由 cukes 回复于 2017年06月07日 · 1501 次阅读

场景

现在有一个接口,为 POST 方法的接口 (购买某个产品).

接口

如该接口所需的参数为某个产品 id,需要测试该产品不同状态的接口后端处理情况:

  1. 该产品已经无货
  2. 该产品已经过期
  3. 该产品已经下架 .....

此时测试该接口时,需要传递以上不同状态的产品 ID。

问题

  1. 如何在测试该接口时,自动创建这些不同状态产品的 ID
  2. 如何测试完该接口后,删除与该产品 ID 相关的所有数据
共收到 10 条回复 时间 点赞

方法 1:在测试用例中构建数据
setup: 创建一条 XX 状态的产品
test steps : ....
teardown: 删除该产品

方法 2:事先准备好数据库
setup: 加载数据库
test steps : ....
teardown: 还原数据库

kanchi240 回复

方法 1:在测试用例中构建数据
setup: 创建一条 XX 状态的产品
test steps : ....
teardown: 删除该产品

创建 XX 状态的产品存在如下问题

  1. 如产品无货,传递给后端的参数不能为 0,如果库存为 0 则该产品不能上架,且不能使用该购买接口。
  2. 如产品下架,需要先调用创建商品接口,调用设置数量的接口..等..所以在测试该接口的时候必须保证其他接口先正确,多数接口互相依赖的时候怎么办呢。

方法 2:事先准备好数据库
setup: 加载数据库
test steps : ....
teardown: 还原数据库

通过数据库创建和删除数据有如下问题
通过数据库直接操作必须特别了解各个表之间的关系,多数需要链表插入,且每个表的字段的规则都需很清楚,且同一个业务可能数据分散在多出,mysql,mongo, redis 等,这样会不会增加很大的工作量

以上,可以话再请教一下~~

3楼 已删除

数据准备的不同策略:

1 走 DB
制约条件:多数据源不适合
数据源不透明,数据源被隔离不适合
规则复杂,数据源数据结构有复杂、动态依赖性不适合
(其他都可以的)

2 走系统入口,比如页面、接口等
制约条件:业务会有依赖性,比如先要搞定商品分类等

至于如何使用数据,就看你是采用物理清除、标记无效的软清除、采用随机数据策略保证互斥等了。看场景吧。

如果使用事务策略,则接口应用本身跟测试程序必须复用同一个数据源事务,而且不能有改变 DDL 的操作,就可以的。

具体情况要看你自己系统的业务哦,比如是否商品管理系统的接口,内部跟库存或者 ERP 系统有关系等等来权衡了。

cukes 回复

如果接口未提供 delete 的功能呢,且如果直接插入数据库,怎么测试研发在写数据到表里面的处理逻辑是正确的呢
@kanchi240 同问

Leticia 回复

只要能接触到数据源比如数据库,无论如何都建议直接读取表比对业务后的真实数据的。
否则,需要组合其他接口,间接尝试暴露录入的数据。

cukes 回复

最后一句没有看懂呢:😹

Leticia 回复

从我之前接触的商城商品购买等接口来看:
1.产品下架,产品信息页应显示无法购买,这时候应该测试产品信息接口查看产品状态
2.产品无货,当购买选择数量时,会调用产品接口查看库存,如果无库存是无法进行购买的。
3.产品过期同产品下架
本身感觉 LZ 所列的接口测试用例并不是单接口测试,而是购买业务逻辑接口串联的测试。就好比 app 调用第三方支付宝支付接口,测试的前提是能调用这个接口查看返回的订单等信息数据是否正确,我需要传个产品 id,数量和单价等等,那么支付宝接口肯定不会去校验你产品状态,因为那些是有别的接口去完成的。当然也可能 LZ 公司的接口是这样写的,那样去做这样的用例设计也正确。

Leticia 回复

比如通过下订单再查询订单接口,返还商品信息给外部 API,商品跟 ERP 整合等其他接口来验证该接口本身录入数据的正确性了,在接触不到数据源的情况下

lcw 回复

而是购买业务逻辑接口串联的测试

非常同意这句话!!

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册