按说，开发改动之后，应该对相关功能进行自测，以确保基本流程正常，且不影响相关主流程才发给测试。看来这步没有做到位。严格一点，这次提测就打回去了。

版本控制固然有不稳定的因素，这也正好是测试的活，怎么对多版本多分支的迭代进行测试，这需要好好思考

这肯定是合代码的问题

因为功能模块较多且需求改动较为小而频繁，所以每次改动的主流程验证目前看来不好实现，而且开发自测质量也比较一般。所以想从流程上请教下有没有优化方式

可能我表达的不清楚，这里的问题更多的是本地提交到 dev 导致无关功能受影响，是否有流程上的优化方案，这里在我理解应该不在测试负责的范围内

是的，就是不知道该怎么去避免这种负面影响

没看懂，你这两个版本是两个分支的意思？

近段时间发现测试环境内频发一些基础功能无法使用的问题（新增/运行等类型功能），而这些模块在近期是没有新增需求改动的。
经与开发了解，发现是因多人多需求改动相同代码文件导致

1、没有新增需求改动，为啥会有多人多需求改动相同代码？这个逻辑没看懂，建议再问清楚

2、多人多需求改动相同代码文件，从版本管理角度最容易出现的问题就是代码冲突，以及某些情况下自动合并后的逻辑会错误。这个确实有可能导致质量很不稳定（以前别的项目也有遇到过，客户端并行需求，分支管理没弄好，两个需求共用一个分支，经常相互影响）。解决方法也很简单，既然需求是相互独立的，短期内可以拆分为两个分支，分别独立去测试，上线前再合并并回归一遍；长期来说大概率是架构有问题，存在某个超级类，啥逻辑都往里面怼，所以大部分需求都要改到这个类，需要想办法把这个类拆散，解决多需求会改到同一个文件这个问题。

是的大佬，两个分支，一个开发共用，一个测试用
1.在有多需求改动时，可能会存在多人在同一代码文件内进行不同位置的更改，进而对非需求涉及范围的代码产生了影响。这是我咨询开发后的理解
2.大佬说的很贴切，只是因人力和环境限制，暂时只有两个分支，或者从 CI 角度来说只有 dev 一个分支，test 只要合代码就会变成与 deb 一致的状态。期间没有什么专项性测试或者单需求分支的环节，这可能就是问题点，没有进行
单需求测试 ok》合入总线测试 Ok
多谢回复，后面看看有没有机会推动这个环节

“多人多需求改动相同代码文件”——可以从这方面入手，让开发重构或者把需求拆解好一点。
我们一个 master 都没出你那些问题。

多谢大佬回复
现在主要是开发拍脑袋定流程，一切质量由 bug 来保证，就导致了这种现象。
这就来向大佬求经，等后面有机会或推动力的时候就从流程入手，参考恒捷大佬的建议，先加入单需求分支测试，再进行两次单需求/主线合入回归，需求分析时也会适时提出需求拆解的建议

提个建议，分支模型、测试环境这些会切实影响测试这边的东西，测试必须参与并把控好关键点。

比如你这里全部需求共用分支，且团队能力上没法保障这个分支质量保持稳定，就是一个对质量保障很不友好的分支模型。这个测试要主动去推，而且是要提要求。比如我之前说的那个情况，出现了同一个 bug 重开 1-2 次后，我当时就找开发 leader 说这个问题必须作为最高优先级优先解决。测试没有那么多时间精力去不断重复测试一个已经测试过没问题的模块。开发必须保障好这些已经测试通过的模块的稳定，而且开发老是花时间去修同一个模块重复出现的 bug，也很浪费自己的时间精力。

多谢大佬的建议
其实这个事情在我发现这种问题出现的时候就多次找开发 leader 以及我们的产品 leader 进行过沟通，也说明了这种事情所带来的风险，可惜所处位置的话语权不够以及产品整体的重心还是交付向，后面就不了了之了。
这次来请教各位同行大佬也是想确定下自己的认知是否正确，以及准备一套较为可行可信的改造方案，后面再就此事进行更好的推动

话语权不够这个确实没有什么好招，持续想办法扩大自己影响力，提高话语权吧。加油！

automation 可能可以帮助发现这类问题，但是也不一定。根子上还是需要解决过多的共同依赖。

这不完全是开发的问题吗？你们既然可以测到问题，那么由此产生问题的原因难道就没有推着去解决呢？还能反复因为代码合并的问题导致缺陷不断？

本质上是版本控制流程问题，所以来寻求解决方案。当时开发也确定了问题原因，但是并没有去思考解决方式，我就来找大佬们求援啦

听上去你们应该加强开发合并代码的能力（开发的基础能力），有些开发遇到冲突时，喜欢强制合并冲突，而不是选择解决冲突。不知道是不是内心想着：反正后面有测试呢。或者根本没想过测试的问题。然后发现了之后，道个歉就没了。。。一点也不重视

基于 tag 构建测试环境不就好了