哎，光长了个会学习的脑子🧠，其他事情太迟钝💥
说说最近合作的开发，今年有一个重点项目，可以理解为在原有功能的基础上又加了新项目，这就涉及到了对原项目的改造，简单来说就是新功能+老代码改造，老代码的改造也是为了新功能服务。
开发那边把功能分的很细，并且一个完整功能没完成就要上线，比如举例来说，定义了一个api，没有任何实现，也要先推上线，或者是query db的两个funciton，写完了也要立马上线，不会跟着调用方写完调用再一起上线。
讲真我不太理解，我能想到的就是，他们怕代码积压，怕以后产生过多代码合并冲突，怕代码回滚。从我的角度来讲，代码要上线，不管啥代码肯定是要经过测试的，至少要保证代码覆盖率，但这个实际情况跟想像中有很大差别，本次上线的代码不会有流量，但是却一定要上线，这无疑是要承担风险的。按以前来说，我一定会要求先放到一个分支暂存，等对应的功能开发完成再上线。但是开发不同意这样做，并且很反对。
最好的肯定是和开发align好，相同功能分批上线的节奏以及功能拆分，保证每次上线的代码都是经过测试的，保证代码覆盖率
现实总是骨感的，我们属于半路接手这边的测试工作的，也许我leader以前跟这边开发leader聊过也许没聊过，也可能最近这个问题太困扰我，我应该跟他聊一聊。
最后，实在没办法，开发把功能切的太碎太细，我们从QE的角度，怎么才能既节省人力又保证质量？把风险降到最低？
- 分析改动点，与开发一起确定测试scope
- 一定要做好已有功能的回归，尤其是主flow
- 至于那些上线后暂时也用不到的部分，尤其指domain内部调用的，可以暂不覆盖
- 虽然暂时不覆盖，但是case可以先设计出来
- 对于对外提供的接口，是需要做完全测试的
以上是个人愚见，仅从功能测试角度思考。
如果再来一次，应该咋办？
- 我应该会再提前了解到是新功能+老代码改造并行的时候，就跟开发align好，尽量相同功能一起上线，如果实在不能，要做功能拆分，需要根据可测性来拆分，并且暂时无法上线的部分，要维护在单独分支里。
为什么会有问题？
- 本质上来讲是质量意识问题。
可以通过流程来控制吗？我觉得有可能
产品和PMO参与吗？不参与
如何给开发团队渗透质量意识？
欢迎各抒己见
