最近有个和客户合作的项目由于客户要的非常紧急，所以产品想尽快上线提出在开发没有整体完成的情况下分批提测功能，但我是比较排斥分批提测的，原因如下：
1.如果已经提测的功能和未提测的功能有交互，那么未提测功能的改动会影响已经提测的功能。
2.客户的系统没有区分开发环境和测试环境，所以只能和公司的某一个环境交互。如果是开发环境，那么 QA 在测试环境没法对整个功能做闭环测试，因为需要向客户的系统同步数据；如果是测试环境，那么 RD 没法在开发环境开发未提测的功能。
3.在没有整体提测的情况下提 bug，RD 是比较抗拒的，容易产生摩擦，但是不提 bug 又体现不出 QA 的工作成果。
请问大家对功能分批提测有什么看法？
我们一直是分批提测。服务端和客户端各自测试。等客雾端和服雾端联调完成后，再做集成测试。
下面是我们的一个流程，供参考
提前介入测试流程
开发做完一个需求，需求的状态改为：
编码结束，已送内评测试组对
编码结束，已送内评的需求提前介入测试，每天花少量时间（暂定 1 小时）进行验收冒烟测试，提交发现的阻塞性、未实现的 bug。并提醒开发修复。 其他严重的、普通的缺陷只记录 Redmine，正式提测后开发再修复冒烟测试通过后，需求状态改为：
内评通过，已送测试
目标
正式提测前，阻塞性、未实现的 bug，全部修复
分批测试有什么问题呢？ 如果所有模块一起提测，你就不用分先后顺序了吗？
项目时间紧的情况下，相对于全部一起提，分批提测下测试执行的时间更为充足。相对于提前介入了
分批提测理论上是可以提高交付速度分批提测 分批验证 分批 UAT 提高并行度 但是需要需求分解好 同时沟通频率也加大 测试工作量是提高了的 环境问题吗 能做的还是需要基础设施能力 挑战肯定是加大了 能不能快只能说看能力 都说不准 如果马上试肯定会有点混乱的
我们也一直提倡分批提测，理论上一个完整的 story 完成就可以提测，被依赖的 story 优先提测，这样比整体提测的效率高很多
国内所谓的敏捷不就是这种节奏么，我们公司一直都是这样，但是环境还好都是开发和测试都是分开的
分批提测，拥抱敏捷吧。
不过大多数公司身处瀑布追求敏捷，结果可能不太理想。
如果贵司的 CI、冒烟和以及接口自动化到位，我觉得可以尝试去分批测试。
如果没有达到敏捷的条件，确实可能需要整体交付一个版本后统一测试、再修复、在测试。。。。。。
谢谢大家的回复，看来在环境，流程，能力都满足的情况下，大家对部分提测还是持赞成意见的。
我们之前这么做过，是 APP， 也是分开模块提测，开发可以分开模块提测，但是过程中 bug 全部记录，后期相关模块提测再去验证，最后一周集成测试，这个流程是开发率先提出来的，我们当时 每天进行站立会。来碰头进度。推动各个环节的协作。这种模式在快速开发，快速交付过程中我感觉很普遍的做法。