【IT168 技术文章】
以下是我们在实际工作中遇到的一个例子，这个例子充分说明了正确的工作流程对于保证软件产品质量的重要意义。
1. 问题描述
某一开发团队为其客户开发业务软件，系统上线之后存在着很多的业务需求变更，同时也有很多业务部门在使用过程中所发现的软件缺陷，我们把需求变更和软件缺陷统称为变更。开发团队需要迅速响应客户所提出变更请求，把相应的软件版本修复及时地安装到生产系统上去。
为了保证产品质量，该开发团队建立了以下的软件发布流程：
图1
这四个环节分别对应以下四种环境：
开发环境：开发实现客户的变更请求
测试平台：开发团队把软件发布给客户之前做内部系统测试
准生产环境：客户把软件发布到生产系统之前做验收测试
生产系统：最终的生产系统
当开发团队将变更实现提交用户验收测试时，凡是没有通过验收测试的变更将被拒绝，只有通过验收测试的变更才会被部署到生产系统上去。整个流程如下图所示，假设开发团队总共实现了3个变更，其中变更1和变更2通过了系统测试被提交用户验收测试，但只有变更1通过了用户验收测试，最终只有变更1被部署到生产系统上。
图2
为了支持这种工作流程，该团队分别在配置管理系统中管理了四种源代码版本：
图3
凡是通过每一个环节的变更所对应的源代码版本将被复制到下一个环节的版本基线中去。看上去这一流程非常合理，不是吗？
2. 质量陷阱
让我们来看这种流程的两个应用案例。
场景I：未经测试的版本组合
在下面的例子中，文件f1、f2在修改之前的版本都是1，在实现了变更1、变更2后，它们的版本都变为了版本2，表示为f1(v2)、f2(v2)。在整个的测试过程中，前面三个环境上测试的代码版本始终是文件f1和f2的版本2，但是最后变更1没有通过验收测试而变更2通过了，那么最终被部署到生产系统上去的版本将是：
f1(v1，这是f1原来在生产系统上的版本)
f2(v2，其中已包含了变更2所对应的版本2)
图4
但f1(v1)应该是跟f1(v1，变更1修改以前的版本)相匹配的版本组合，跟f2(v2)相匹配的版本组合应该是f1(v2)，由此可能发生的结果是：在生产系统上运行的是未经测试的版本组合!
场景II：未经测试的版本
在下面的例子中，在前面三个测试环节中，文件f2被测试的版本都是版本4。当变更2未通过用户验收测试时，文件f2最终被复制到生产系统上的版本为3，这个版本是未经测试的。
图5
结果令人难以置信：在生产系统上运行的是未经测试的版本?!
任何一个软件系统，它的所有代码应该被作为一个整体来进行交付，而不是象上述例子中那样只交付部分的代码（变更相关的代码），这是造成质量陷阱的根本原因。一个看上去合理的流程存在本质的缺陷。
