请问一下接口组合测试有没有好的方案，目前正纠结着一块

@sam_insist 不知道你的需求是什么，功能的自动化用例也完全可以由接口组合啊？
或者换个维度，用户故事算么？

就是现在单个接口的各种用例已经测试过了。。那流程性的组合要不要测试呢，比如一个用户完成一个事务操作需要调用 10 个接口，，那我要不要对这个 10 个接口做各种情况的组合测试呢。。或者说这个 10 个接口的组合测试有没有必要呢

@sam_insist 你这个是关键字组合的问题了。。。这个和自动化关系感觉不大。
我个人的意见是简单组合，复杂组合除非出过问题，没有必要专门进行接口组合覆盖。
当然还要看你们项目的要求，自动化到底要实现到什么程度。自动化不是万能的。。。~
PS：我能吐槽一下么，用户一个操作调 10 个接口，这个操作还不封装一下，这 10 个接口之间会没有顺序么？这要不封装的话，这用户体验，代码结构也算是奇葩了，个人建议结合业务流程，不要做太多无用用例~到最后还是要考虑执行时间的问题。

#4 楼 @yangchengtest @sam_insist的意思可能是一个测试点需要调用 10 个接口才能达到目的吧，而不是点一个操作调用 10 个接口

^{_，吐槽有点多~以下是我个人的观点，供吐槽~}
我个人是这样理解的，10 个接口，接口组合感觉这种就不是接口测试讨论的范畴了。这个应该是测试方法，测试架构讨论的内容。如关键字驱动之类的。
大家可能接触测试理论都会说要覆盖要完善，但怎么说呢，完备是需要成本的，有些覆盖在代码中是有约束的，比如条件 A 触发以后才会运行 B，某些完备是没有意义的。我们看到开发提供的接口可能有 10 个，你组合多少合适呢。这个感觉还是经验和项目需要或者是用户来驱动。呵呵，有不少东西，我知道自己项目怎么玩，但是别人的项目适用不适用就很难讲了。
我感觉自动化不是万能的，有很多内容比如 DB 同步，异常测试的一些内容，就需要自己去想办法挖掘组合。目前我感觉自动化把基本的跑跑通，降低回归测试的成本就很不错了，个人建议不要想太多，手工也是不可能完全替代的。
接口测试个人认为最大的优势就是 UI 改起来太痛苦，接口简单很多，也更贴近代码，更好操作。~
题外话：领导最后要看的是成果，至少最基本的内容要能跑过，接口最终还是要变成一个一个可呈现出来的东西~适当的组合还是必须的。

谢谢您的细心解答，或许我理解的接口不只是针对单个接口的各种用例测试，比如一个常见的网上购物的完整流程，要调用登录接口，获取商品信息接口，添加商品到购物车的接口，新增订单的接口.... 就是一般这种整个流程性的接口组合测试有没有必要呢。

@sam_insist 你上面说得都是一些基本的功能，我个人理解还是需要整合一下的，测试归根结底还是要验证功能。做完之后心理有底，给领导交差时也会好看些~个人建议只做简单的整合，不要搞得太复杂。

@yangchengtest 谢谢，我也觉得应该要测试一下，只是这种组合接口测试的深度和广度自己还是不知道怎么掌握，或许还是要公司具体的业务来吧。

“PS:最后吐槽下，和开发联调接口，哎，开发接口文档有误就得自己取抓包，看的多了，有些眼花。。。还有些同学爱理不理的。。。“这个需要规范 API 啊，比如 restful，而且有 BUG 就上 PMS 提给开发，BUG 和开发绩效挂钩吧。希望对你有用。

对了，你们接口测试的压力测试是怎么做的？

@halo_lan 目前还没有考虑压力测试，我们是家庭产品，一般来说不会有超过 5 个用户同时登录，目前只考虑了常规的一些性能测试，请问压力测试这部分有什么可以建议的么？多谢！~
呵呵，我们就是因为考核开发 BUG 数目，所以 API 都是扯皮的事情~必须要有实际操作异常，才会理会你。API 改了，只要实际功能能跑通，测试脚本跑不跑的通那是测试的事，和开发无关。。。这里槽点比较多，就不细说了~

#7 楼 @sam_insist 这个属于业务层的测试，在底层单个接口功能测试完毕之后，是有必要增加一些场景测试的，比如业务场景。这些场景就要根据各自系统的实际进行设计咯。这是我的经验。

@sam_insist 我们这边做接口组合测试，是先从比较重要的场景入手，使用 3 组合覆盖来模拟上层使用的场景，但是也有问题，就是会出现不少无效的场景，不过对无效和有效的定义也是因人而异的