谈工程变更

在这里只谈纯粹软件意义上的工程变更和配置管理相关规范流程，不涉及到产品级的工程变更包括的硬件和各种配套件层面，以方便按一个简化的思路来理解工程变更的流程和核心模型。

变更分需求类变更和实际故障bug两种，在定制的时候由于两种不同类型的变更本身处理流程也有差别，因此本身也可能进行不同的流程定制，最终归集到代码和实现层面。对于需求类变更往往涉及到需求的CCB评审，需求方案的讨论，需求和设计文档的修改，最后可能才涉及到代码层面的变更。而对于缺陷故障则流程简单，直接故障分析后可以分配到代码修改层面。

完整的工程变更模型包括了变更请求，变更单和变更活动的三层复杂1对多的层层展开结构，由于产品级的变更涉及到软件，硬件，工艺，结构，包装等多个方面的内容，因此对于产品级的变更三层模型往往是必须的。而对于纯粹软件层面的变更，我们可以将模型简化为两层结构，即变更申请直接转到具体的变更活动上面，一个变更申请可以对应到多个变更活动。举个例来做，一个接口的变更可能涉及到A,B两个业务系统代码层面的修改，则在需求分析评估后可以生成两个变更活动，分片指派给两个业务系统来处理。

在多层的变更模型和变更对象下面，每一层都有其独自的对象生命周期状态，同时各层对象之间又相互影响状态。整个基本操作思路可简化描述如下，在变更申请派发多个变更活动后，必须是底层所有的变更活动的状态关闭后，变更申请的最终状态才能够验证关闭，以形成一个完整的变更闭环过程。

基本上所有的变更都涉及到配置管理项的修改，因此将具体配置项和变更单，变更活动关联起来是必须的。这样我们才能够清楚每一次配置项的版本变化究竟和那个变更申请单有关系，形成完整的追溯关系。在变更的过程中，我们需要对配置项进行检出，则一般操作可以是在check out配置项的时候选择具体的变更活动以实现关联。同时对于选择到的配置项列表将自动带入到变更工单中，以实现完整的追溯。

我们来思考一下一个比较大的软件项目中所涉及到的变更管理流程和变更和部署测试的配置情况。具体场景我们可以简化为有20个bug，开发人员已经修改为10个bug，同时将缺陷的状态切换到了待部署状态。还有10个bug还在处理中。这个时候测试需要对已经修改好的10个bug提前进行验证。整个过程可以简化描述如下：

1.开发修改完的bug为待部署状态，未修改完的bug为修改中状态。
2.开发申请进行一次版本构建，独立的工单，该版本构建工单关联上已经修改的10个bug
3.配置管理员对版本构建单进行审核出来，根据bug追溯到配置项，然后进行单独按缺陷的deliver操作，将配置项的变更从开发分支deliver到配置管理的测试分支。
4.配置管理员根据自动化构建脚本进行编译和版本部署，根据版本管理规范生成本次部署包的版本号。
5.部署成功后完成后，10个已经修改完成的bug的状态转换到待测试状态。
6.测试负责人提交测试申请，某次测试申请可以关联所有已经在待测试状态的缺陷，然后走工单流程。
7.测试人员对待测试的缺陷进行测试和验证，如果通过该缺陷本身关闭，如果不通过缺陷重新打开。
8.如果所有缺陷都验证通过，则进行版本评审或评估，同时最后一次的版本为一个稳定的可用版本。
9.工程现场人员通过版本提取流程，对测试稳定可用的版本进行提前。

在这里要注意变更申请，变更活动，版本构建，测试申请，版本提取等都是独立的流程，同时这些对象之间又发生关联依赖和约束，以形成完整的闭环和追溯关系。变更的核心一定是可闭环+可追溯。

以上只是最简单的一个涉及到一个系统的bug修复和测试发布的流程。而较为复杂的则是跨多个业务系统的需求方案层面的变更。因为在原有单业务系统的基础上增加了更多的协同和相互约束。那再举个例子来说，一个需求方案，涉及到两个业务系统去变更修改，然后同时发布和部署，那我们的流程和工具上应该如何更好的支撑。

1.提交变更申请，变更申请在进行评审分析后拆分为单独的两个变更活动单分配给两个业务系统。
2.两个业务系统各自去处理自己的变更活动。流程同上面。
3.提交构建申请，两个业务系统可以各自提交自己的构建申请，将变更活动转到待测试状态。
4.测试负责人注意，只有两个变更活动都待测试的时候变更申请会转到待测试，这时候提交测试申请。
5.进行方案的测试和评估，形成测试结果和评估报告，后面流程同。

这已经是一个简化以后的跨系统的方案类变更例子，重点是通过两层或多层变更对象结构实现了全流程的追溯关系。而产品级的工程变更则往往需要启用标准的三层变更对象模型，以实现追溯和映射。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密