背景：公司开发用的是 java，项目 A；测试接口自动化用的 python，项目 B。打算做持续集成，期望达到的效果是任何一名开发人员提交代码后会去触发 pipeline 的执行，pipeline 就包含两步 build + test，然后将 test 的失败结果通知到开发，达到一种快速反馈的效果。
有个问题：A 开发在某次迭代的时候开发了一些功能，比如 F1、F2、F3，push 代码的时候，如何只执行 F1、F2、F3 对应接口测试呢？ 不能执行全量的测试，因为其他开发人员可能有些 function 还没有开发完成，但是这时测试代码已经开发完成了，这个时候去执行未开发完成的功能肯定跑不通。
你这个往大里说就是精准测试了。
用最笨的方法。指定执行对应的方法不就可以了。
如何只执行 F1、F2、F3 对应接口测试呢？
简单的方法：测试手动在测试集里屏蔽掉还没开发完的接口对应用例就行，开发开发完了同步下测试，测试手动执行确认没问题后再去掉屏蔽。
复杂点的方法：特别写一个程序，识别开发这个接口有没有开发完（识别方法可以是和开发约定一个标志写在 controller 上，或者能找到现有就会有的标志直接识别也可以）。如果没有开发完，那就 skip 掉相关的用例（执行用例前调整默认用例集的内容）
个人建议用方法 1 就可以了，简单有效。
PS：这个玩法略特别，一般持续集成关注的是原有功能是否被破坏，执行的是已有功能的自动化测试。新功能一般是开发完甚至提测后才开始关注（除非开发用正统 TDD，先写测试再写实现，但这时候的测试也不是放持续集成里跑的，而是本地跑的，因为前期一定会失败）。
太早关注反而因为还没完全开发完导致不稳定额外耗费时间精力。
首先下结论，不赞同这种做法。
jenkins pipeline + gitlab 是确保回归测试的，确保新功能对之前的功能没有造成影响。
按题主说的，开发中的就不应该跑这种测试，没有意义，开发中的代码测试通过（经由你写的测试代码验证而言）后，同步到其他分支。例如在 F1、F2、F3 的是 develop 分支，你测试代码在 develop 分支验证，验证通过后同步到 test 分支，你的 jenkins pipeline + gitlab 应该在 test 分支跑的。
同时 develop 分支能做的是除了 test 之前的其他事情，比如 CI/CD、静态扫描就行了
陈恒捷
回复
是的，我的问题场景可能不符合持续集成的想法。因为新开发的功能可能会影响到之前的代码，应该还是跑全量的测试。
开发和测试同步进行编码，开发完成功能代码，测试完成接口测试代码。这里有个开发与测试之间进度快慢的问题。如果 A 开发将功能开发完成时，测试还没有写完接口自动化测试，这时提交代码后跑的是之前的接口测试，先可以合并到主干分支，后续测试完成编码后，下次开发提交也会把上次未进行测试的接口进行覆盖到。那么如果测试比开发速度快，可以按照你说的第一种方法。比如 A 开发完成的功能，对应的接口已经完成，但是 B 开发还未完成开发，对应的接口测试已经完成，这个时候 B 开发可以告诉测试让把这些未完成的功能给屏蔽掉。
Heyniu
回复
测试代码也可以在 dev 环境跑。对开发新功能开发的反馈时机我认为还是应该按上图所示，开发提交代码后就开始跑单元测试，接口测试，快速反馈结果给开发人员。dev 环境在开发每次提交代码的时候跑，test 环境在 dev 合并到 test 分支的时候全量跑，可能因为环境的影响接口也会发生失败的情况，还有 test 环境每日定时跑。