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

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

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

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

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

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

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

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

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

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

还是有必要的，原因有二：

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

了解了，感谢各位大佬！！