以下是我们在实际工作中遇到个例子这个例子充分介绍说明了正确工作流程对于保证软件Software产品质量重要意义

1问题描述

某开发团队(Team)为其客户开发业务软件Software系统上线的后存在着很多业务需求变更同时也有很多业务部门在使用过程中所发现软件Software缺陷我们把需求变更和软件Software缺陷统称为变更开发团队(Team)需要迅速响应客户所提出变更请求把相应软件Software版本修复及时地安装到生产系统上去

为了保证产品质量该开发团队(Team)建立了以下软件Software发布流程:

er\" height=45 alt=q src=\"/Files/BeyondPic/2007-12/20/SCM01-01.JPG\" width=530>

这 4个环节分别对应以下 4种环境:

开发环境:开发实现客户变更请求

测试平台:开发团队(Team)把软件Software发布给客户的前做内部系统测试

准生产环境:客户把软件Software发布到生产系统的前做验收测试

生产系统:最终生产系统

当开发团队(Team)将变更实现提交用户验收测试时凡是没有通过验收测试变更将被拒绝只有通过验收测试变更才会被部署到生产系统上去整个流程如下图所示假设开发团队(Team)总共实现了3个变更其中变更1和变更2通过了系统测试被提交用户验收测试但只有变更1通过了用户验收测试最终只有变更1被部署到生产系统上



er\" height=388 alt=qqq src=\"/Files/BeyondPic/2007-12/20/SCM01-02.JPG\" width=636 align=middle>

为了支持这种工作流程该团队(Team)分别在配置管理系统中管理了 4种源代码版本:

er\" height=44 alt=qq src=\"/Files/BeyondPic/2007-12/20/SCM01-03.JPG\" width=528 align=middle>

凡是通过每个环节变更所对应源代码版本将被复制到下个环节版本基线中去看上去这流程非常合理不是吗？

2质量陷阱

让我们来看这种流程两个应用案例

场景I:未经测试版本组合

在下面例子中文件f1、f2在修改的前版本都是1在实现了变更1、变更2后它们版本都变为了版本2表示为f1(v2)、f2(v2)在整个测试过程中前面 3个环境上测试代码版本始终是文件f1和f2版本2但是最后变更1没有通过验收测试而变更2通过了那么最终被部署到生产系统上去版本将是:

f1(v1这是f1原来在生产系统上版本)

f2(v2其中已包含了变更2所对应版本2)



er\" height=370 alt=d src=\"/Files/BeyondPic/2007-12/20/SCM01-04.JPG\" width=682 align=middle>

但f1(v1)应该是跟f1(v1变更1修改以前版本)相匹配版本组合跟f2(v2)相匹配版本组合应该是f1(v2)由此可能发生结果是:

在生产系统上运行是未经测试版本组合!

场景II:未经测试版本

在下面例子中在前面 3个测试环节中文件f2被测试版本都是版本4当变更2未通过用户验收测试时文件f2最终被复制到生产系统上版本为3这个版本是未经测试[Page]

er\" height=388 alt=qqqq src=\"/Files/BeyondPic/2007-12/20/SCM01-05.JPG\" width=683 align=middle>

结果令人难以置信:

在生产系统上运行是未经测试版本?!

任何个软件Software系统它所有代码应该被作为个整体来进行交付而不是象上述例子中那样只交付部分代码(变更相关代码),这是造成质量陷阱根本原因个看上去合理流程存在本质缺陷

3 改进建议

为了避免以上所述这些质量陷阱我们应该改进现有配置管理流程

3.1 建立闭环质量保证流程

选成以上质量隐患根本原因是系统代码没有被作为个整体来处理并且在发布过程中我们发布是源代码正确流程(也是业界较为通行做法)应该发布构建后目标码而非源代码我们可以建立个闭环质量保证流程(如下图所示)来批量地进行软件Software发布

er\" height=226 alt=dd src=\"/Files/BeyondPic/2007-12/20/SCM01-06.JPG\" width=525 align=middle>

其中系统测试过程中发现缺陷应该被开发人员及时改正然后再做构建再测试直到达到个比较稳定版本才会发布到验收测试环节同样验收测试中发现问题也会回到开发环节进行修复这应该是个多次循环过程不断地发现然后改正再测试这个循环到什么时候结束呢？这个取决于各个软件Software项目实际情况:

• 最理想情况当然是到所有缺陷都被改正为止但是所花时间比较长可能赶不上项目进度要求现实工作不大可能做到这点
• 折衷情况是所有严重缺陷(即那些影响系统使用缺陷)都必须被改正但允许有些已发现缺陷遗留到后面再去解决,前提是所遗留缺陷不会影响
  
  其他变更实现大家平时在些商用软件Software新版本中经常可以见到发布介绍说明(Release Notes)中所列已知缺陷(Known Defects)就是属于这种情况

我们向开发团队(Team)提出这个建议后马上遭到项目经理(project manager)反对:“客户有些紧急变更需要马上实现并交付生产运营几乎没有时间来走这样完整闭环流程”

3.2 区别对待缺陷和新增功能

通过进步了解我们发现紧急变更般是指影响系统正常使用软件Software缺陷这些缺陷需要及时修复；而新增功能请求般不是那么紧急允许开发团队(Team)有段时间来开发实现但开发人员目前是把所有紧急和非紧急变更请求混杂在起实现往往是个紧急缺陷已经修复但另外个正在开发中新增功能也修改了同组文件版本造成两者的间版本依赖从而导致紧急缺陷修复不能按时提交

我们建议把缺陷修复工作和新增功能开发工作区分开来这就涉及到多个版本并行开发开发团队(Team)主要面临以下 3个版本开发:

• v1.0中缺陷修复
• v1.0新增功能版本v1.1
• 下个版本v2.0

这样缺陷修复和新增功能开发相互独立保证紧急缺陷修复不会受到新增功能影响

3.3 发布版本构建(build)而不是源代码

[Page] 在这个案例中另外有个不附合配置管理惯例地方是在开发、测试、验收、生产 4个环节发布都是源代码分别需要构建(包括编译)过后才能部署到相应运行平台上由于软件Software构建结果很可能会受构建平台及相应编译器版本所影响最终在生产系统上运行代码(在生产系统上构建得到)和准生产环境上运行代码 (在准生产环境上构建得到)可能不完全致有可能造成质量隐患比较通行做法是所有平台上运行构建代码应该只在构建服务器上生成次次编译到处运行这样才能保证各个平台上所用到同版本运行代码是同次构建产物构建服务器通常就是由开发平台兼任但如果是发布多个区别运行平台版本话可以有多个构建服务器存在如:同个软件Software既有 AIX + DB2 平台运行版本也有 HPUX + Oracle 平台运行版本

除了某些特殊运行环境外如IBM主机系统(frame)上明确要求在运行平台上对源代码进行编译构建般软件Software系统开发都可以遵循这个工作原则

3.4 版本发布管理

对于所发布构建版本我们也需要进行有序管理可以用版本号来唯标识每个发布版本般可以把用于开发团队(Team)内部系统测试称的为内部发布版本把提交给客户称的为外部发布版本这两种软件Software发布版本都要统编号管理在我们例子中内部发布版本可以简单地用构建号来表示如:

v1.0_build_008 表示版本v1.0开发过程中生成第8次构建外部发布版本可以由版本号和发布号组合而成如:

v1.0_rel01 表示版本v1.0第个外部发布版本