多版本并行，测试如何做好质量保障？
昨天的文章总结了从软件工程角度，如何进行项目管理相关的知识。正好上周末星球内部直播时候，有同学问了一个问题：他们公司经常存在多版本并行的项目，不知道怎么做好质量保障工作。
这篇文章就以昨天文章中提到的项目管理的方法，结合我自己的实际经历，来聊聊多版本并行，质量保障工作面临哪些挑战以及如何保障交付质量。
我们日常工作中版本迭代一般都是按照时间进行排版迭代的，但偶尔也会遇到其他情况，比如新业务拓展需要紧急上线，但日常的迭代也不能停止。
这个时候就会出现多版本或者说多项目并行的情况，这也给质量保障工作带来了很大的挑战。总结一下，比较大的挑战主要有如下四点。
环境问题
如上图所示，当时我们遇到了这样一个问题：在一个迭代周期内有2个业务迭代版本和3个独立项目差不多要同时上线。这个时候面临的第一个问题是测试环境的问题。
原则上来说，为了避免不同项目之间的互相影响，在测试环境上要做到彼此隔离。但要做到环境隔离，又面临2个挑战：
第一个是成本问题，单独搭建一套可用的测试环境，包括云服务器、缓存、消息队列和数据库，成本是很高的；
第二个是时间问题，搭建环境涉及到运维、研发和测试团队，需要运维准备资源、研发配合测试进行发布联调；
当时我们的测试环境很混乱，很多环境处于不可用状态，面临这个问题，我当时是这样解决的。
首先，4.1和4.2版本的时间可以错开，因此该两个版本可以共用一套环境，只是在代码部署上跟进下细节即可；
其次，独立版本1由于横跨了4.1和4.2版本，且涉及的业务域和对应服务和其他项目差异较大，因此独占T1环境；
最后，独立版本2和独立版本3提测及上线日期接近，且涉及的业务域和对应服务相差不多，可以将范围内的所有服务发布到T2环境，共用一套环境。
关于环境问题，我之前写过一篇详细的文章《被忽视的问题：测试环境稳定性治理》，大家可以参考。
业内比较好的解决方案是通过流量染色+stable环境来解决，架构图如下：
分支问题
多版本并行，其实最大的难点就在于代码分支问题。关于代码分支，主要考量如下几点：
- 每个项目是否都需要单独拉一个分支出来进行开发；
- 上线前代码merge，如果冲突较多，就需要尽早去做代码合并尽早发现问题；
- 如果没有明显的代码冲突，在UAT阶段做一轮快速的回归验证即可；
边界问题
这个问题其实很容易忽略，但在实际的工作中，面临多版本并行的情况，划分清楚边界其实是很重要的。
这样一方面可以减少不必要的工作量，另一方面也可以避免测试过程中遇到不同项目的交互区域，责任划分以及问题跟进问题。
边界划分，我个人的处理经验主要遵循如下几点：
- 需求评审时明确本次需求涉及的业务域；
- 按照业务域去确定该项目对应的应用服务名（便于区分代码分支）；
- 综合不同项目的调用依赖，判断公共服务是否有变更（如有可考虑mock等手段）；
- 解决不同项目在测试过程中的测试数据问题（测试数据准备也是多项目并行的一大难点）；
回归问题
其实多版本并行最大的工作量就在于回归验证，一方面要确保每个项目涉及到的变更影响部分都要回归到，避免遗漏；
另一方面针对不同项目的不同代码分支，还要考虑代码冲突的问题。针对这种情况，一般来说解决方法无非下面几种：
- 大量的自动化测试来节省回归测试的时间和工作量；
- 短期内通过增加人力的方式去尽可能覆盖涉及的业务场景；
结合上篇文章讲到的项目管理知识，可以看到：
- 在项目前期识别面临的问题，这是风险评估和风险管理；
- 在面临多项目并行时制定项目计划并逐步拆解为最小的可执行任务；
- 通过流程规范去约束代码分支和提测发布过程，并时时跟进；
- 通过工具去提升过程效率（如自动化等手段）；
综合来说，软件工程的方法论在实际的工作中，给了我们更高的一个观察视角，能让我们解决更复杂的问题。
