新手区 一个菜鸟,想写一个接口自动化脚本,关于测试用例的设计疑惑,望有空的大佬解惑

测试通过 · 2021年01月23日 · 最后由 测试通过 回复于 2021年01月28日 · 6155 次阅读

在调研时,发现有接口关联的用例。有一个疑惑,假如我每个接口都有一个单独的用例,每个接口都可以正常调用了。那么接口关联用例,还有必要吗?或者说写接口关联用例有什么优点

共收到 10 条回复 时间 点赞

个人觉得接口关联用例复杂程度不是很高的话可以写。

可以根据用户使用流程设计流程测试用例,虽然单个没有问题,跑一遍流程是有必要的。

每个接口都可以正常调用了,那不就集成了关联的接口了吗?

我也好奇这个问题很久了。如果每个接口单独的功能都是正常的,是不是能认为一套流程下去相关的接口一定没问题?

凡事哪有这么绝对的。
单元接口的测试主要是为了校验这个接口功能性和健壮性,而关联起来跑流程是为了模拟多个接口的调用场景,主要是为了校验功能的调用情况和业务流程,两者还是有不差异的。

一个关注的是接口本身,一个关注的是接口间的流转情况,可以在保证接口无问题的情况下进行完整流程的接口间调用测试。其实这个就和单元测试后集群测试的性质差不多,个体与集体的关系

假如我每个接口都有一个单独的用例,每个接口都可以正常调用了

如果只是这种程度,其实校验点还是不够。写入数据库数据是否正确、调用下游服务接口的入参是否正确等都很重要,要不写错写漏这类问题容易遗漏。

当然这些都写全挺花时间的,还涉及和各种中间件的操作和校验信息获取。但你用一个多接口关联也可以解决这个问题。比如一个写接口,写入数据对不对?拿个对应的读接口查一下看返回结果是不是一致就可以反推了。

还是有必要的,原因有二:

  1. 单接口都有测试用例,并且都跑的没问题,只能证明这个接口在你当前的用例下是没问题的,这个接口生产的数据是不是符合下游接口的调用预期是未知的;
  2. 接口关联用例可以换一种角度来思考,抽象出一个业务场景,通过接口关联的方式来实现。这样就不仅仅是为了做接口关联而做了, 你是为了保证某个业务场景没问题才做的。这样既知晓了场景接口串起来能跑通,也知道了对应的业务场景没问题了

了解了,感谢各位大佬!!

测试通过 关闭了讨论 01月28日 15:34

如果每个接口都是一个单元,那么把这些单元编排成一个完整的业务。更加像集成测试吧。

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