把前两个接口都调用一遍获取订单信息再作为参数给到支付这里

老哥，你搞错了吧，接口自动化本身不是给你跑新需求涉及的用例的，而是怕影响地方进行的回归测试，新的需求测试用例还是需要手工的，而且还要维护这部分的自动化用例

那么基于场景得接口自动化意义在哪里？

个人理解主要有几个意义：
1、能高频跑，更早发现问题。我们之前最高频率是每 30 分钟跑一次，失败立马预警，开发立马修复。这个换成人力跑成本太高了，而且有些核心问题如果到末尾回归再发现和修复，时间会很紧，改过的代码多，找问题原因也会更加费时费力。
2、减少人工测试要跑的场景数量。主流程人工过一遍这个省不了，但工作量比全部过一遍要少不少了。
3、如果自动化校验点足够齐全（包括数据库校验等所有人工测试会验证的都有验证到），且修改点确认只有服务端，不涉及其他端，那我觉得跑完直接上线是没问题的。

例如一个支付接口他需要先添加购物车 =》下单 =》支付，那么在测试下单接口得时候，是把前两个接口都调用一遍获取订单信息再作为参数给到支付这里，还是直接在数据库里构造这部分信息测试支付呢？

建议是都调用一遍，主要是从可维护性角度考虑。一般服务提供的接口，会保障向下兼容，且保障按顺序调接口没问题的。至于插库，这个特别姿势一般不会保障，意味着需要测试自己保障；而且这部分也是很可能会改动的，依赖的数据不一定都来自数据库，也可能是第三方服务什么的，那这个方式就行不通了。

感谢解答，看了您 15 年发的接口测试感悟还是能收益不少

哈哈，感谢支持。当时其实也是刚入门接口测试，会有挺多困惑的，所以写下来也是为了帮助自己更好总结理解。

后面你对这个自动化意义有新的感悟，也欢迎来社区分享哈。学习了很多东西后，个人感觉，对术（怎么做、遇到的典型问题可以怎么解决）了解多了后，总结成道（能做什么不能做什么，什么时候适合什么时候不适合），会更容易记忆和应用，也避免跑偏用错，产生负效果。

测试下单接口的时候应该先调用前两个接口，再用生成的数据调用下单接口。因为万一前面接口的结果变了，你直接构造的数据没变，实际上就漏测了

自动化测试只是一个手段，要不要测由你自己决定。