碰到这种问题我的第一反应是，是不是接口测试用例设计之初就不够灵活？按说开发的接口不应该变化很大，否则为什么不重新设计接口呢？

频繁变动的接口，就只设计确保单接口涵盖， 不考虑 E2E 场景。这样可以快速维护

接口和用例之间用工厂模式就可以解决

可以试试将接口及报文、断言做成配置，可以试试

时间紧急方案一，时间充裕方案二

每次都全跑，但是测试报告里需要特别标明，受改动影响导致的失败用例数，以及扣除这部分的用例后的真实通过率。然后安排人员在一周（时间根据自身需要来确定）内将用例修改好，保证下次测试前，成功率恢复到正常水平。

频繁大改的。。接口？这显然是需求或者设计问题，建议在这个阶段就避免。
实在避免不了，调整下测试脚本的结构，让架构支持这种频繁的改动

其实还有 一种方式，也是现在测试开发 和 高级测试 要做的事情，你可以提前做 ；那就是自己搞一个 接口调试平台 可以仿照 postman 写，这样 他们的 接口数据就会直接落地到数据库，你做后续的事情 ，不久简单了么 ；

大改为什么不直接设计新的接口？

接口测试平台不能让维护接口测试工作变得简单。

我们的测试团队这样做过，存在两个问题。

1. 产品变更后，不受影响的用例会保持上个版本一样的执行结果，而受影响的测试用例 ---- 真正反映变更造成的结果的用例却没执行，得到的测试报告还有价值意义吗？
2. 给了自动化测试团队两周的时间 (开始是给一周)，没修好新版本就又出来了，又有新的用例受到影响需要修复，前两周修复过的用例再次受到影响需要重新修复，技术债务越积累越多。

这是挖坟了，4 月份的帖子了。
第一个问题，接口测试的接入时间，应该是前后端联调完成时。所以，如果在执行接口测试的时候，功能变更的部分没有更新的话，应该要考虑流程，执行力等方面的问题。类似楼主这种时间不够的情况，确实要做出取舍，只要和开发协定好了最终要的效果，也不存在没有意义这种说法。
第二个问题，两周都改不好用例吗？吃干饭？整天浑水摸鱼？以两周迭代为例，开发联调一般一天就能完成，最多两天，调人家一天就能做完的事，算上你数据准备的时间，两周都做不完吗？别做了好吗？

感谢回复！
我能接受你对第一个问题的观点。
第二个问题，测试团队两周确实改不好，这是现实或事实。大家也确实努力了，加班了，应该不存在偷懒的情况。感觉做不完不是因为任务重任务多人手不够，加人估计并不能解决问题。你这边如果有相关经验，希望能指点一二。

你们的具体情况，我不是很了解，按照我的经验来看，开发联调完接口之后，同样时间下，一个人做三四个开发调的接口是没问题的。如果你说的任务重，任务多，是指除接口外的任务都算进去的话，我还可以理解，如果只算接口，那你们要考虑自己的代码结构是否有问题，导致非常多冗余/复杂的修改，最重要的就是解耦和聚合。我修改接口内容的时候，只需要关心数据和验证，旧有功能的修改只需要修改验证即可，新功能则两个都需要修改，这样可以非常快速的适配新的接口内容。

为什么你们维护用例两一周甚至两周?需要这么长的时间？

我们使用的就是题主所列的方案二。
二、对应的去修正脚本，修正完再跑版本的的自动化脚本。
第二种方案就是耗时耗力，而且有没有足够时间调试脚本。可能会不稳定。