旁述：测试过程中如何应对频繁的版本变更？

 

旁述：测试过程中如何应对频繁的版本变更？

对于这个问题，其实要视实际的情况，如企业、团队、项目、产品、市场等等多个方面的因素，不能一概而论，所以，解决的办法有多种。今天我没有回答”如何应对“频繁的版本变更这个问题，下面的内容，当作提醒，呵呵。

1、为什么会有频繁的变更？

2、多少变更可以集成为一个“版本”？测试的对象如何确定？

3、从“应对”转为“避免”

一、为什么会有频繁的变更？

1、首先需要解释一下：

1.1 这里所指的“变更”多数情况下理解为版本内容变更，即软件产品内容需求的变更，而不是软件配置管理中定义的”配置项(Configuration Item)"的变更。

1.2 这里所指的“版本”是指软件产品版本，并不是某个配置项（Configuration Item）的版本。

2、该问题的提出，主要原因应该是“需求”的变更过于频繁。

3、需求的变更频繁的原因有很多，比如商业合作计划变更导致、用户需求变更导致、产品定位和市场营销变更导致等等。。。

二、多少变更可以集成为一个“版本”？

1、并不是每次变更都需要构建成一个“软件版本”的。比如，昨天张三（程序员）改了一个函数名称，李四在今天上午加了一个功能，王五在今天下午删除了一个界面按钮。。。我们没有必要对这三次在相临的不同时间里所做的变更分别构建和定义成三个版本。。。

2、“软件版本”应该是有明确的原因或计划的。如上述所说，对于相临的不同的时间里所做的多次变更并不需要分别构建不同的版本。那么多少次变更、或者什么时候才需要构建一个版本出来呢？其实这就是“版本计划”要管理和关注的了。版本计划定义了有多少版本、每个版本的内容有什么、版本的开发周期、版本的发布时间等等。近几年，软件行业好像在主推“敏捷开发”，“每日构建”（Daily Build）是敏捷开发的核心思想，每日构建放在我们讨论的这个问题上，会出现什么情况呢？我们是不是需要对每个Daily Build版本做一次“完整”的测试？答案当然是否定的！版本确认测试（Build Verification Test）就是简化版地测试活动。因为实际上，我们不太可能在人工测试的情况下每天测试一个新的版本。所以，实际上，对于版本测试（基于可运行的和测试的版本），我们是需要花费一定的时间去做全面的测试的。这个时间段我们叫做【版本测试周期】，一个版本的测试，需要一个【版本测试周期】。有的版本需要2至3天完成测试，有的版本可能需要一个月来完成测试。

三、从“应对”转为“避免”

1、让我们（特别是测试人员）感觉的版本变更频繁的原因，主要有几点：

1.1 需求变化过快、同时又急于发布。

1.2 测试时间不足，计划中的测试方案没有执行、测试用例没有执行。

1.3 需求变更的成本过高（变更过程长、复杂，版本构建时间长）。

1.4 需求变更的提出、决定过程短，没有多方协商，致使涉及到的人员没有得到知会、没有时间调整计划。比如需求变更时没有与开发团队、测试团队确认，产品/项目负责人在短时间内要求实现变更。致使开发团队、测试团队来不及调整开发、测试计划。

说了那么多，前面其实只是一些”提醒“，提醒大家不要掉进这个”命题误区“。