扫码阅读
手机扫码阅读

多版本并行,测试如何做好质量保障?

312 2023-08-25
昨天的文章总结了从软件工程角度,如何进行项目管理相关的知识。正好上周末星球内部直播时候,有同学问了一个问题:他们公司经常存在多版本并行的项目,不知道怎么做好质量保障工作。
这篇文章就以昨天文章中提到的项目管理的方法,结合我自己的实际经历,来聊聊多版本并行,质量保障工作面临哪些挑战以及如何保障交付质量。

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

环境问题

如上图所示,当时我们遇到了这样一个问题:在一个迭代周期内有2个业务迭代版本和3个独立项目差不多要同时上线。这个时候面临的第一个问题是测试环境的问题。
原则上来说,为了避免不同项目之间的互相影响,在测试环境上要做到彼此隔离。但要做到环境隔离,又面临2个挑战:
第一个是成本问题,单独搭建一套可用的测试环境,包括云服务器、缓存、消息队列和数据库,成本是很高的;
第二个是时间问题,搭建环境涉及到运维、研发和测试团队,需要运维准备资源、研发配合测试进行发布联调;
当时我们的测试环境很混乱,很多环境处于不可用状态,面临这个问题,我当时是这样解决的。
首先,4.1和4.2版本的时间可以错开,因此该两个版本可以共用一套环境,只是在代码部署上跟进下细节即可;
其次,独立版本1由于横跨了4.1和4.2版本,且涉及的业务域和对应服务和其他项目差异较大,因此独占T1环境;
最后,独立版本2和独立版本3提测及上线日期接近,且涉及的业务域和对应服务相差不多,可以将范围内的所有服务发布到T2环境,共用一套环境。
关于环境问题,我之前写过一篇详细的文章《被忽视的问题:测试环境稳定性治理》,大家可以参考。
业内比较好的解决方案是通过流量染色+stable环境来解决,架构图如下:

分支问题

多版本并行,其实最大的难点就在于代码分支问题。关于代码分支,主要考量如下几点:
  • 每个项目是否都需要单独拉一个分支出来进行开发;
  • 上线前代码merge,如果冲突较多,就需要尽早去做代码合并尽早发现问题;
  • 如果没有明显的代码冲突,在UAT阶段做一轮快速的回归验证即可;

边界问题

这个问题其实很容易忽略,但在实际的工作中,面临多版本并行的情况,划分清楚边界其实是很重要的。这样一方面可以减少不必要的工作量,另一方面也可以避免测试过程中遇到不同项目的交互区域,责任划分以及问题跟进问题。
边界划分,我个人的处理经验主要遵循如下几点:
  • 需求评审时明确本次需求涉及的业务域;
  • 按照业务域去确定该项目对应的应用服务名(便于区分代码分支);
  • 综合不同项目的调用依赖,判断公共服务是否有变更(如有可考虑mock等手段);
  • 解决不同项目在测试过程中的测试数据问题(测试数据准备也是多项目并行的一大难点);

回归问题

其实多版本并行最大的工作量就在于回归验证,一方面要确保每个项目涉及到的变更影响部分都要回归到,避免遗漏;另一方面针对不同项目的不同代码分支,还要考虑代码冲突的问题。针对这种情况,一般来说解决方法无非下面几种:
  • 大量的自动化测试来节省回归测试的时间和工作量;
  • 短期内通过增加人力的方式去尽可能覆盖涉及的业务场景;

结合上篇文章讲到的项目管理知识,可以看到:
  • 在项目前期识别面临的问题,这是风险评估和风险管理;
  • 在面临多项目并行时制定项目计划并逐步拆解为最小的可执行任务;
  • 通过流程规范去约束代码分支和提测发布过程,并时时跟进;
  • 通过工具去提升过程效率(如自动化等手段);
综合来说,软件工程的方法论在实际的工作中,给了我们更高的一个观察视角,能让我们解决更复杂的问题。

原文链接: http://mp.weixin.qq.com/s?__biz=Mzg2NDAwMjM1NQ==&mid=2247486102&idx=1&sn=25c4b847f99a4172a81c689f5e3f6f5b&chksm=ce7142caf906cbdc55b461a3ee22474e22eac3de4297f829f27a1110182f2bd409af647e697b#rd