多版本并行，测试如何做好质量保障？

昨天的文章总结了从软件工程角度，如何进行项目管理相关的知识。正好上周末星球内部直播时候，有同学问了一个问题：他们公司经常存在多版本并行的项目，不知道怎么做好质量保障工作。

这篇文章就以昨天文章中提到的项目管理的方法，结合我自己的实际经历，来聊聊多版本并行，质量保障工作面临哪些挑战以及如何保障交付质量。

我们日常工作中版本迭代一般都是按照时间进行排版迭代的，但偶尔也会遇到其他情况，比如新业务拓展需要紧急上线，但日常的迭代也不能停止。这个时候就会出现多版本或者说多项目并行的情况，这也给质量保障工作带来了很大的挑战。总结一下，比较大的挑战主要有如下四点。

环境问题

如上图所示，当时我们遇到了这样一个问题：在一个迭代周期内有 2 个业务迭代版本和 3 个独立项目差不多要同时上线。这个时候面临的第一个问题是测试环境的问题。

原则上来说，为了避免不同项目之间的互相影响，在测试环境上要做到彼此隔离。但要做到环境隔离，又面临 2 个挑战：

第一个是成本问题，单独搭建一套可用的测试环境，包括云服务器、缓存、消息队列和数据库，成本很高；

第二个是时间问题，搭建环境涉及到运维、研发和测试团队，需要运维准备资源、研发配合测试进行联调；

当时我们的测试环境很混乱，很多环境处于不可用状态，面临这个问题，我当时是这样解决的。

首先，4.1 和 4.2 版本的时间可以错开，因此该两个版本可以共用一套环境，只是在代码部署上跟进下细节即可；

其次，独立版本 1 由于横跨了 4.1 和 4.2 版本，且涉及的业务域和对应服务和其他项目差异较大，因此独占 T1 环境；

最后，独立版本 2 和独立版本 3 提测及上线日期接近，且涉及的业务域和对应服务相差不多，可以将范围内的所有服务发布到 T2 环境，共用一套环境。

关于环境问题，我之前写过一篇详细的文章《被忽视的问题：测试环境稳定性治理》，大家可以参考。

业内比较好的解决方案是通过流量染色+stable 环境来解决，架构图如下：

分支问题

多版本并行，其实最大的难点就在于代码分支问题。关于代码分支，主要考量如下几点：

• 每个项目是否都需要单独拉一个分支出来进行开发；

• 上线前代码 merge，如果冲突较多，就需要尽早去做代码合并尽早发现问题；

• 如果没有明显的代码冲突，在 UAT 阶段做一轮快速的回归验证即可；

边界问题

这个问题其实很容易忽略，但在实际的工作中，面临多版本并行的情况，划分清楚边界其实是很重要的。这样一方面可以减少不必要的工作量，另一方面也可以避免测试过程中遇到不同项目的交互区域，责任划分以及问题跟进问题。

边界划分，我个人的处理经验主要遵循如下几点：

• 需求评审时明确本次需求涉及的业务域；

• 按照业务域去确定该项目对应的应用服务名（便于区分代码分支）；

• 综合不同项目的调用依赖，判断公共服务是否有变更（如有可考虑 mock 等手段）；

• 解决不同项目在测试过程中的测试数据问题（测试数据准备也是多项目并行的一大难点）；

回归问题

其实多版本并行最大的工作量就在于回归验证，一方面要确保每个项目涉及到的变更影响部分都要回归到，避免遗漏；另一方面针对不同项目的不同代码分支，还要考虑代码冲突的问题。针对这种情况，一般来说解决方法无非下面几种：

• 大量的自动化测试来节省回归测试的时间和工作量；

• 短期内通过增加人力的方式去尽可能覆盖涉及的业务场景；

结合上篇文章讲到的项目管理知识，可以看到：

• 在项目前期识别面临的问题，这是风险评估和风险管理；

• 在面临多项目并行时制定项目计划并逐步拆解为最小的可执行任务；

• 通过流程规范去约束代码分支和提测发布过程，并时时跟进；

• 通过工具去提升过程效率（如自动化等手段）；

综合来说，软件工程的方法论在实际的工作中，给了我们更高的一个观察视角，能让我们解决更复杂的问题。