-
配置管理--百度百科
2009-06-05 11:05:17
配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。
早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为SoftTool的公司，开发了自己的配置管理工具：CCC，这也是最早的配置管理工具之一。之后，随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了软件配置管理的重要性，而相应的软件配置管理工具也如雨后春笋一般，纷纷涌现，比较有代表性的有：Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System)，这两种工具对日后的配置管理工具的发展做出了重大的贡献，目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。
一、配置管理在软件开发过程和项目管理过程中的作用
随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置管理逐渐成为软件生命周期中的重要控制过程，在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开过程的宏观管理，即项目管理，也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性，使软件系统具有可重复性，使用户和主管部门用软件质量和开发小组有更强的信心。
软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化，为了保证对产品有效地进行控制和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必须对动态的、成长的产品进行管理。由此可见，配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期。通过配置管理过程的控制，用户对软件产品的需求如同普通产品的订单一样，遵循一个严格的流程，经过一条受控的生产流水线，最后形成产品，发售给相应用户。从另一个角度看，在产品开发的不同阶段通常有不同的任务，由不同的角色担当，各个角色职责明确，泾渭分明，但同时又前后衔接，相互协调。
好的配置管理过程有助于规范各个角色的行为，同时又为角色之间的任务传递提供无缝的接合，使整个开发团队象一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品，这些都是项目主管人员所关注的重点，因此配置管理系统在软件项目管理中也起着重要。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境，使新的成员可以快速实现任务交接，尽量减少因人员流动而造成的损失。
二、配置管理的功能
配置管理系统应该具备以下主要功能：
并行开发支持：因开发和维护的原因，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制；
修订版管理：跟踪每一个变更的创造者、时间和原因，从而加快问题和缺陷的确定 ；
版本控制：能够简单、明确地重现软件系统的任何一个历史版本 ；
产品发布管理：管理、计划软件的变更，与软件的发布计划、预先定制好的生命周期或相关的质量过程保持一致；项目经理能够随时清晰地了解项目的状态 ；
建立管理：基于软件存储库的版本控制功能，实现建立（build）过程自动化 ；
过程控制：贯彻实施开发规范，包括访问权限控制、开发规则的实施等 ；
变更请求管理：跟踪、管理开发过程中出现的缺陷（Defect）、功能增强请求（RFE）或任务（Task），加强沟通和协作，能够随时了解变更的状态 ；
代码共享：提供良好的存储和访问机制，开发人员可以共享各自的开发资源 ；
三、配置管理的流程
1、制定配置管理计划
配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。
2、配置库管理
配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。
3、版本控制
在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。
4、变更控制
在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。
修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。
当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请－审批－执行变更－再评审－结束”的规则执行。
5、配置审计
为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。
四、配置管理的实施
实施配置管理系统，一般的步骤和需要考虑的问题如下：
规划、调整网络开发环境
一个规划良好的开发环境，是实施配置管理系统的前提。在此阶段我们要对配置管理系统做出规划，主要考虑以下问题：
* 网络的带宽、拓扑结构
*服务器的选择、命名规范
*存储区的定位
*开发人员及组的命名规约等
设计配置管理库
根据项目开发的要求，设计开发资源的存储模式，良好的存储模式有利于减轻管理上的负担，增强配置管理库的访问性能，同时便于控制访问权限，保护软件资产。
定义配置管理系统的角色
在此阶段，我们需要确定与配置管理相关的所有角色，包括他们的相应的活动。在开发过程中，一个开发人员可能兼任多种角色，但一项任务在同一时刻只能由一个角色来执行。
一般配置管理中的角色主要包括：
项目经理：项目经理在配置管理方面的职责是依靠配置管理员、系统管理员和系统体系结构设计人员的帮助，制定项目的组织结构和配置管理策略。这些工作包括：定制开发子系统，定制访问控制，制定常用策略，制定集成里程碑，以及进行系统集成；
配置管理员：配置管理员的职责是根据项目经理制定的开发组织结构和策略，实施、维护配置管理的环境。其主要职责如下：创建配置管理库，对存储库进行日常备份和恢复，维护配置管理环境，及管理配置管理相关的用户；
软件开发人员：软件开发人员依据项目的开发和配置管理策略，创建、修改和测试开发工件；
集成人员：对软件进行归并，形成相应的基线或发布版本 ；
QA人员：需要对软件配置管理有较深的认识，其主要工作是跟踪当前项目的状态，测试，报告错误，并验证其修复结果；
制定配置管理流程
这是配置管理实施的一个重要阶段，其主要目的是根据项目开发的需要，制定相应的配置管理流程，以更好地支持开发，主要活动包括：
定制并行开发策略：合理的并行开发策略应该具有以下特点：协调项目的复杂性和需求，统一创建分支类型和元数据，为开发过程中的变更集成制定有效的规范，适时反映开发过程中方法和需求的变化
发布版本管理：软件开发过程中的一个关键活动是提取工件的相关版本，以形成软件系统的阶段版本或发布版本，我们一般将其称为稳定基线。一个稳定基线代表新开发活动的开始，而一系列定制良好的活动之后又会产生一个新的稳定基线。有效地利用此项功能，在项目开发过程中可以自始至终管理、跟踪工件版本间的关联。
烽火猎聘分类来培训相关人员
一般来讲，实施配置管理系统，相关人员需要接受以下培训：
管理员培训：针对配置管理员，主要学习配置管理工具管理相关内容
开发人员培训：针对开发人员，主要学习配置管理工具与开发相关的常用操作
管理流程培训：针对全体人员，目的是了解配置管理策略和流程，以及如何与开发管理、项目管理相结合
五、配置管理经验谈
围绕配置管理,世界一些致力于软件工程研究的公司在深入理解ISO 9000的基础上, 推出了各种符合ISO 9000配置管理标准的工具软件,如INTERSOLV公司的PVCS,Rational公司的Clear Case等。这些配置管理工具面向软件规范化、工程化、自动化的需要,帮助开发团队提高科学管理水平,从而提高工程效率,降低工程成本。现以PVCS为例,结合我们的实际经验,谈谈我们实施配置管理的益处:
1. 节约费用
(1) 缩短开发周期
利用PVCS的Version Manager对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。同时项目管理人员可以通过Version Manager查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从Version Manager上得到不同的运行版本,并且Version Manager 可以安装在Web Server供外地施工人员存取最新版本,无需开发人员亲临现场。
利用Tracker组建开发团体之间的问题跟踪及消息通迅,通过其Notify模块与电子邮件结合起来大大加强了开发团体之间的沟通,Reporter模块可对发现的问题进行整理、以报表方式分类报出,作为开发的指导。
以上为PVCS的两个主要模块,科学地应用可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。
(2) 减少施工费用
利用PVCS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,内部直接通过Netscape访问Version Manager,工程人员通过远程进入内部网,获取所需的最新版本。开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是否修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。
2. 有利于知识库的建立
(1) 代码对象库
软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是:一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及。Version Manager为对象管理提供了一个平台和仓库,有利于建立公司级的代码对象库。
(2) 业务及经验库
通过PVCS Version Manager的注释及Tracker,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作用。
3. 规范管理
(1) 量化工作量考核
传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自己把握,随意性相当大;靠管理人员把握,主观性又太强。采用PVCS管理后,开发人员每天下班前对修改的文件 Check In,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。
(2) 规范测试
采用PVCS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。
(3) 加强协调与沟通
采用PVCS后,通过Version Manager文档共享及其特定锁机制、Tracker与电子邮件的集成,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。
六、配置管理的精髓
具体来讲，配置管理包含如下内容：
标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
控制：通过一定的机制控制对配置项的修改
状态报告：记录并报告配置项以及元数据的状态。
配置审计：确认产品的完整性并维护配置项间的一致性。
从上面的描述，我们知道，配置管理的基本单位是配置项。
从“哲学”意义上讲，它记录配置项的三个方面：
从哪里来？此项可归结为WWW的问题，（Who）谁创建的？（When）什么时间创建的？（Why）为什么创建此配置项？
当前在哪里？此项纪录配置项当前的存储位置以及状态。
将到哪里去？通过配置控制来把配置项“组装”到正确的版本中去。
配置项可以是大粒度的，也可以是小粒度的。如果跟踪个别需求，那么不必要把整个需求规格说明文档定义为一个配置项，可以把每个需求定义为配置项；如果把软件开发工具也放入配置管理系统，那么把配置项定义为文件级就不合适了，只需要跟踪开发工具的版本，即把整个配置工具定义为一个配置项就足够了。
简而言之，配置项可以是文件级粒度的，也可以使文件版本级粒度的。当然，粒度越小管理的成本越高，但是配置的精度也就越高。
一个完整的SCM系统要具有三个核心功能：版本控制、变更控制、配置控制以及两个支持功能：状态统计和配置审计。
版本控制
版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。这里的某一特定对象是指版本维护工具管理的软件组成单元，一般是指源文件；具体实例则是指软件开发人员从软件库中恢复出来的某软件组成单元的具有一定内容和属性的一个真实拷贝。例如，对源文件的每一次修改都生成一个新版本。
版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。
当前，这方面典型的工具有如VSS和CVS。
变更控制
变更控制是通过对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。
变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修补。
对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。
下面是一个典型的变更机制：
我们可以随着变更过程的推进，提升配置项的状态。 这方面的工具有Bugzilla。
配置控制
配置控制使用户能够通过对适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策略使得配置管理系统象搭积木似的使用已有的积木（版本）组装成各种各样、不同功能的模型。
软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。配置控制就是要保证每个配置的完整性和精确性。
举个例子来说，我们要发布软件的32.6版本，那么我们就要把源代码、文档、数据中所有这个应该包含到这个版本中的正确配置项检出。
在开发过程中，我们在不同阶段要建立各种基线。基线的建立是配置控制功能的典型应用。所以说，基线是具有里程碑意义的一个配置。
一般的商业软件配置管理工具都具有配置控制的功能，只是灵活性和精确性有差别。
状态报告
状态报告要回答所谓4W的问题：
What：发生了什么事？
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
状态报告还要能够报告所有配置项以及变更请求的状态。
配置审计
配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否具有一致性等等。
由于现在软件行业越来越重视质量，许多项目专门成立质量保证部门专门来进行配置审计。所以现在也可以说，配置审计是一个SQA（软件质量保证）活动。
配置管理的商业模型
配置管理的实施包括两部分：工具和规范。
在软件开发过程自动化的今天，没有工具的支持而实施配置完整的配置管理是不能想象的。因此选择一个符合公司或项目的工具至关重要。在配置管理系统中，我们可归纳出四种模型。当前商业工具一般采用其中一种或几种模型。
我们通过对商业模型的理解可以帮助我们了解某种工具是否适合我们公司或项目。
CICO模型
CICO模型主要关注的是单个文件的版本控制。图显示了一个支持CICO模型的CM系统的工作过程。用户利用库和文件系统来进行工作。文件被版本化并存储到库中，新版本的产生是由库工具控制的。然而， 文件在库中不是可以直接存取的，用户必须去检出（即Check Out）一个文件的版本到工作空间中以便读取它的内容。更改后的文件可以被检入库中（即Check in）,产生文件的一个新版本。
此模型的代表工具是SCCS和CVS。
组织模型
组织模型由CICO模型自然导出，建立于构件版本图的基础之上，同时依赖于存储库和工作空间的概念，可以通过对构件加锁进行并发控制。组织模型的重点是在CM系统支撑下加强了对创建配置、对有关的历史信息的管理和使用他们作为工作环境的支持。
组织模型中的配置由系统模型和版本选择规则组成。系统模型列出了组成系统的所有的构件。版本选择规则指出了组成配置的每一个构件选择版本。选择规则用于系统模型，选择构件版本，即绑定一构件到某一版本。这个模型的操作方式是：开发员根据模型的构件定义整个系统，并在每一步骤中给每个构件选择合适的版本。版本操作的工作方式如图所示。
CM支持主要关心的是维护系统和其构件的版本历史，并选择符合一致性配置的构件版本。只有在所选构件的版本与所选其它构件版本一致时才认为一个配置版本。
此模型的代表工具是CCC。
长事务模型
长事务模型主要支持包括一系列原子变更的全系统演变和由团队开发员对系统变更的协调。开发员主要操作配置而非单独的构件。事务提交的结果是新配置版本，一系列连续的变更结果生成一系列的配置版本，称为开发路径。
在长事务模型中，开发员主要的工作对象时配置，开发员首先选择系统配置版本，接下来把关注重点放在系统结构上。构件的版本由配置隐式决定。长事务由两个概念组成：工作空间和并发控制方案。工作空间来源于存储库或一个封闭工作空间中的一个固定配置。工作空间由工作配置和一系列已保存的配置组成。工作配置代表构件和系统结构能够被动态更改的配置。提供通过工作空间进行的透明库访问、将高效的库存储技术应用于工作空间和管理派生构件的版本。
此模型的代表系统是NSE。
变更集模型
主要集中于对系统配置的逻辑变更的支持。在这个模型中引入的变更集表示组成逻辑变更的对不同构件修改的集合，它是创建变更的活动完成后对逻辑变更的记录。支持这个模型的CM系统用户可以直接操作变更集。在变更集模型中，配置可描述为由基线和一组变更集组成。
变更传播给其它配置可通过包含各自变更集来进行。开发员使用不同的集成策略将逻辑变更集包含到一个新的系统发行中。这样的好处非常明显，例如，我们现在维护10个不同版本的产品，现在要对所有的版本修改一个缺陷（Bug）。如果相同的工具简单的重复10次显然是不可接受的。而通过变更集把这个逻辑变更从一个版本自由的传到另外一个版本。
开发员可跟踪逻辑变更和确定这些变更是否属于特定配置。这种配置管理的方法，因为其将重点放于逻辑变更上，所以被称作面向变更的配置管理。它不同于现在的其他3种CM模型，因为其它3种CM模型使用的面向版本的方法把重点放在构件和配置版本上。
在单一构件的情况下，变更集是两个文件版本之间区别的集合，通常指的是增量内容。对配置来说，变更集就是两个配置版本之间区别的集合。这组区别就是两个配置版本间的修改构件增量集合，即变更构件集的增量。
面向变更的观点不同于面向版本的观点。这有两点不同，一是逻辑变更的显式表示允许对与单个构件和配置有关的变更集进行跟踪。二是引用单个变更集并有选择地将它们纳入配置管理中的这种能力提供了对系统演化管理的支持，这种演化是基于将逻辑变更传播到维护的系统配置进行的。
此模型的代表工具是UCM和SABLIME。
结束语
配置管理本身无论从理论和实践都在不断丰富和发展。例如，配置管理应用于“知识库”的管理就产生了“内容管理”这一新的领域。配置管理提供的状态报告和数据统计也为软件度量提供了决策依据。配置管理为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，在此平台上，大家能够更有效率的交流和协作。可以说，配置管理是软件开发的基石！
配置管理近年来在中国得到了极大的认可，可以毫不夸张的说，没有配置管理，就谈不上软件开发，就谈不上软件质量，就谈不上软件业的发展。随着软件业规模的扩大，配置管理的实施不是要不要的问题，而是什么时间、如何实施的问题了。 -
配置管理--百度百科
2009-06-05 11:05:17
配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。
早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为SoftTool的公司，开发了自己的配置管理工具：CCC，这也是最早的配置管理工具之一。之后，随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了软件配置管理的重要性，而相应的软件配置管理工具也如雨后春笋一般，纷纷涌现，比较有代表性的有：Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System)，这两种工具对日后的配置管理工具的发展做出了重大的贡献，目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。
一、配置管理在软件开发过程和项目管理过程中的作用
随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置管理逐渐成为软件生命周期中的重要控制过程，在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开过程的宏观管理，即项目管理，也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性，使软件系统具有可重复性，使用户和主管部门用软件质量和开发小组有更强的信心。
软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化，为了保证对产品有效地进行控制和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必须对动态的、成长的产品进行管理。由此可见，配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期。通过配置管理过程的控制，用户对软件产品的需求如同普通产品的订单一样，遵循一个严格的流程，经过一条受控的生产流水线，最后形成产品，发售给相应用户。从另一个角度看，在产品开发的不同阶段通常有不同的任务，由不同的角色担当，各个角色职责明确，泾渭分明，但同时又前后衔接，相互协调。
好的配置管理过程有助于规范各个角色的行为，同时又为角色之间的任务传递提供无缝的接合，使整个开发团队象一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品，这些都是项目主管人员所关注的重点，因此配置管理系统在软件项目管理中也起着重要。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境，使新的成员可以快速实现任务交接，尽量减少因人员流动而造成的损失。
二、配置管理的功能
配置管理系统应该具备以下主要功能：
并行开发支持：因开发和维护的原因，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制；
修订版管理：跟踪每一个变更的创造者、时间和原因，从而加快问题和缺陷的确定 ；
版本控制：能够简单、明确地重现软件系统的任何一个历史版本 ；
产品发布管理：管理、计划软件的变更，与软件的发布计划、预先定制好的生命周期或相关的质量过程保持一致；项目经理能够随时清晰地了解项目的状态 ；
建立管理：基于软件存储库的版本控制功能，实现建立（build）过程自动化 ；
过程控制：贯彻实施开发规范，包括访问权限控制、开发规则的实施等 ；
变更请求管理：跟踪、管理开发过程中出现的缺陷（Defect）、功能增强请求（RFE）或任务（Task），加强沟通和协作，能够随时了解变更的状态 ；
代码共享：提供良好的存储和访问机制，开发人员可以共享各自的开发资源 ；
三、配置管理的流程
1、制定配置管理计划
配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。
2、配置库管理
配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。
3、版本控制
在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。
4、变更控制
在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。
修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。
当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请－审批－执行变更－再评审－结束”的规则执行。
5、配置审计
为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。
四、配置管理的实施
实施配置管理系统，一般的步骤和需要考虑的问题如下：
规划、调整网络开发环境
一个规划良好的开发环境，是实施配置管理系统的前提。在此阶段我们要对配置管理系统做出规划，主要考虑以下问题：
* 网络的带宽、拓扑结构
*服务器的选择、命名规范
*存储区的定位
*开发人员及组的命名规约等
设计配置管理库
根据项目开发的要求，设计开发资源的存储模式，良好的存储模式有利于减轻管理上的负担，增强配置管理库的访问性能，同时便于控制访问权限，保护软件资产。
定义配置管理系统的角色
在此阶段，我们需要确定与配置管理相关的所有角色，包括他们的相应的活动。在开发过程中，一个开发人员可能兼任多种角色，但一项任务在同一时刻只能由一个角色来执行。
一般配置管理中的角色主要包括：
项目经理：项目经理在配置管理方面的职责是依靠配置管理员、系统管理员和系统体系结构设计人员的帮助，制定项目的组织结构和配置管理策略。这些工作包括：定制开发子系统，定制访问控制，制定常用策略，制定集成里程碑，以及进行系统集成；
配置管理员：配置管理员的职责是根据项目经理制定的开发组织结构和策略，实施、维护配置管理的环境。其主要职责如下：创建配置管理库，对存储库进行日常备份和恢复，维护配置管理环境，及管理配置管理相关的用户；
软件开发人员：软件开发人员依据项目的开发和配置管理策略，创建、修改和测试开发工件；
集成人员：对软件进行归并，形成相应的基线或发布版本 ；
QA人员：需要对软件配置管理有较深的认识，其主要工作是跟踪当前项目的状态，测试，报告错误，并验证其修复结果；
制定配置管理流程
这是配置管理实施的一个重要阶段，其主要目的是根据项目开发的需要，制定相应的配置管理流程，以更好地支持开发，主要活动包括：
定制并行开发策略：合理的并行开发策略应该具有以下特点：协调项目的复杂性和需求，统一创建分支类型和元数据，为开发过程中的变更集成制定有效的规范，适时反映开发过程中方法和需求的变化
发布版本管理：软件开发过程中的一个关键活动是提取工件的相关版本，以形成软件系统的阶段版本或发布版本，我们一般将其称为稳定基线。一个稳定基线代表新开发活动的开始，而一系列定制良好的活动之后又会产生一个新的稳定基线。有效地利用此项功能，在项目开发过程中可以自始至终管理、跟踪工件版本间的关联。
烽火猎聘分类来培训相关人员
一般来讲，实施配置管理系统，相关人员需要接受以下培训：
管理员培训：针对配置管理员，主要学习配置管理工具管理相关内容
开发人员培训：针对开发人员，主要学习配置管理工具与开发相关的常用操作
管理流程培训：针对全体人员，目的是了解配置管理策略和流程，以及如何与开发管理、项目管理相结合
五、配置管理经验谈
围绕配置管理,世界一些致力于软件工程研究的公司在深入理解ISO 9000的基础上, 推出了各种符合ISO 9000配置管理标准的工具软件,如INTERSOLV公司的PVCS,Rational公司的Clear Case等。这些配置管理工具面向软件规范化、工程化、自动化的需要,帮助开发团队提高科学管理水平,从而提高工程效率,降低工程成本。现以PVCS为例,结合我们的实际经验,谈谈我们实施配置管理的益处:
1. 节约费用
(1) 缩短开发周期
利用PVCS的Version Manager对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。同时项目管理人员可以通过Version Manager查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从Version Manager上得到不同的运行版本,并且Version Manager 可以安装在Web Server供外地施工人员存取最新版本,无需开发人员亲临现场。
利用Tracker组建开发团体之间的问题跟踪及消息通迅,通过其Notify模块与电子邮件结合起来大大加强了开发团体之间的沟通,Reporter模块可对发现的问题进行整理、以报表方式分类报出,作为开发的指导。
以上为PVCS的两个主要模块,科学地应用可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。
(2) 减少施工费用
利用PVCS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,内部直接通过Netscape访问Version Manager,工程人员通过远程进入内部网,获取所需的最新版本。开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是否修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。
2. 有利于知识库的建立
(1) 代码对象库
软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是:一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及。Version Manager为对象管理提供了一个平台和仓库,有利于建立公司级的代码对象库。
(2) 业务及经验库
通过PVCS Version Manager的注释及Tracker,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作用。
3. 规范管理
(1) 量化工作量考核
传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自己把握,随意性相当大;靠管理人员把握,主观性又太强。采用PVCS管理后,开发人员每天下班前对修改的文件 Check In,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。
(2) 规范测试
采用PVCS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。
(3) 加强协调与沟通
采用PVCS后,通过Version Manager文档共享及其特定锁机制、Tracker与电子邮件的集成,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。
六、配置管理的精髓
具体来讲，配置管理包含如下内容：
标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
控制：通过一定的机制控制对配置项的修改
状态报告：记录并报告配置项以及元数据的状态。
配置审计：确认产品的完整性并维护配置项间的一致性。
从上面的描述，我们知道，配置管理的基本单位是配置项。
从“哲学”意义上讲，它记录配置项的三个方面：
从哪里来？此项可归结为WWW的问题，（Who）谁创建的？（When）什么时间创建的？（Why）为什么创建此配置项？
当前在哪里？此项纪录配置项当前的存储位置以及状态。
将到哪里去？通过配置控制来把配置项“组装”到正确的版本中去。
配置项可以是大粒度的，也可以是小粒度的。如果跟踪个别需求，那么不必要把整个需求规格说明文档定义为一个配置项，可以把每个需求定义为配置项；如果把软件开发工具也放入配置管理系统，那么把配置项定义为文件级就不合适了，只需要跟踪开发工具的版本，即把整个配置工具定义为一个配置项就足够了。
简而言之，配置项可以是文件级粒度的，也可以使文件版本级粒度的。当然，粒度越小管理的成本越高，但是配置的精度也就越高。
一个完整的SCM系统要具有三个核心功能：版本控制、变更控制、配置控制以及两个支持功能：状态统计和配置审计。
版本控制
版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。这里的某一特定对象是指版本维护工具管理的软件组成单元，一般是指源文件；具体实例则是指软件开发人员从软件库中恢复出来的某软件组成单元的具有一定内容和属性的一个真实拷贝。例如，对源文件的每一次修改都生成一个新版本。
版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。
当前，这方面典型的工具有如VSS和CVS。
变更控制
变更控制是通过对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。
变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修补。
对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。
下面是一个典型的变更机制：
我们可以随着变更过程的推进，提升配置项的状态。 这方面的工具有Bugzilla。
配置控制
配置控制使用户能够通过对适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策略使得配置管理系统象搭积木似的使用已有的积木（版本）组装成各种各样、不同功能的模型。
软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。配置控制就是要保证每个配置的完整性和精确性。
举个例子来说，我们要发布软件的32.6版本，那么我们就要把源代码、文档、数据中所有这个应该包含到这个版本中的正确配置项检出。
在开发过程中，我们在不同阶段要建立各种基线。基线的建立是配置控制功能的典型应用。所以说，基线是具有里程碑意义的一个配置。
一般的商业软件配置管理工具都具有配置控制的功能，只是灵活性和精确性有差别。
状态报告
状态报告要回答所谓4W的问题：
What：发生了什么事？
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
状态报告还要能够报告所有配置项以及变更请求的状态。
配置审计
配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否具有一致性等等。
由于现在软件行业越来越重视质量，许多项目专门成立质量保证部门专门来进行配置审计。所以现在也可以说，配置审计是一个SQA（软件质量保证）活动。
配置管理的商业模型
配置管理的实施包括两部分：工具和规范。
在软件开发过程自动化的今天，没有工具的支持而实施配置完整的配置管理是不能想象的。因此选择一个符合公司或项目的工具至关重要。在配置管理系统中，我们可归纳出四种模型。当前商业工具一般采用其中一种或几种模型。
我们通过对商业模型的理解可以帮助我们了解某种工具是否适合我们公司或项目。
CICO模型
CICO模型主要关注的是单个文件的版本控制。图显示了一个支持CICO模型的CM系统的工作过程。用户利用库和文件系统来进行工作。文件被版本化并存储到库中，新版本的产生是由库工具控制的。然而， 文件在库中不是可以直接存取的，用户必须去检出（即Check Out）一个文件的版本到工作空间中以便读取它的内容。更改后的文件可以被检入库中（即Check in）,产生文件的一个新版本。
此模型的代表工具是SCCS和CVS。
组织模型
组织模型由CICO模型自然导出，建立于构件版本图的基础之上，同时依赖于存储库和工作空间的概念，可以通过对构件加锁进行并发控制。组织模型的重点是在CM系统支撑下加强了对创建配置、对有关的历史信息的管理和使用他们作为工作环境的支持。
组织模型中的配置由系统模型和版本选择规则组成。系统模型列出了组成系统的所有的构件。版本选择规则指出了组成配置的每一个构件选择版本。选择规则用于系统模型，选择构件版本，即绑定一构件到某一版本。这个模型的操作方式是：开发员根据模型的构件定义整个系统，并在每一步骤中给每个构件选择合适的版本。版本操作的工作方式如图所示。
CM支持主要关心的是维护系统和其构件的版本历史，并选择符合一致性配置的构件版本。只有在所选构件的版本与所选其它构件版本一致时才认为一个配置版本。
此模型的代表工具是CCC。
长事务模型
长事务模型主要支持包括一系列原子变更的全系统演变和由团队开发员对系统变更的协调。开发员主要操作配置而非单独的构件。事务提交的结果是新配置版本，一系列连续的变更结果生成一系列的配置版本，称为开发路径。
在长事务模型中，开发员主要的工作对象时配置，开发员首先选择系统配置版本，接下来把关注重点放在系统结构上。构件的版本由配置隐式决定。长事务由两个概念组成：工作空间和并发控制方案。工作空间来源于存储库或一个封闭工作空间中的一个固定配置。工作空间由工作配置和一系列已保存的配置组成。工作配置代表构件和系统结构能够被动态更改的配置。提供通过工作空间进行的透明库访问、将高效的库存储技术应用于工作空间和管理派生构件的版本。
此模型的代表系统是NSE。
变更集模型
主要集中于对系统配置的逻辑变更的支持。在这个模型中引入的变更集表示组成逻辑变更的对不同构件修改的集合，它是创建变更的活动完成后对逻辑变更的记录。支持这个模型的CM系统用户可以直接操作变更集。在变更集模型中，配置可描述为由基线和一组变更集组成。
变更传播给其它配置可通过包含各自变更集来进行。开发员使用不同的集成策略将逻辑变更集包含到一个新的系统发行中。这样的好处非常明显，例如，我们现在维护10个不同版本的产品，现在要对所有的版本修改一个缺陷（Bug）。如果相同的工具简单的重复10次显然是不可接受的。而通过变更集把这个逻辑变更从一个版本自由的传到另外一个版本。
开发员可跟踪逻辑变更和确定这些变更是否属于特定配置。这种配置管理的方法，因为其将重点放于逻辑变更上，所以被称作面向变更的配置管理。它不同于现在的其他3种CM模型，因为其它3种CM模型使用的面向版本的方法把重点放在构件和配置版本上。
在单一构件的情况下，变更集是两个文件版本之间区别的集合，通常指的是增量内容。对配置来说，变更集就是两个配置版本之间区别的集合。这组区别就是两个配置版本间的修改构件增量集合，即变更构件集的增量。
面向变更的观点不同于面向版本的观点。这有两点不同，一是逻辑变更的显式表示允许对与单个构件和配置有关的变更集进行跟踪。二是引用单个变更集并有选择地将它们纳入配置管理中的这种能力提供了对系统演化管理的支持，这种演化是基于将逻辑变更传播到维护的系统配置进行的。
此模型的代表工具是UCM和SABLIME。
结束语
配置管理本身无论从理论和实践都在不断丰富和发展。例如，配置管理应用于“知识库”的管理就产生了“内容管理”这一新的领域。配置管理提供的状态报告和数据统计也为软件度量提供了决策依据。配置管理为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，在此平台上，大家能够更有效率的交流和协作。可以说，配置管理是软件开发的基石！
配置管理近年来在中国得到了极大的认可，可以毫不夸张的说，没有配置管理，就谈不上软件开发，就谈不上软件质量，就谈不上软件业的发展。随着软件业规模的扩大，配置管理的实施不是要不要的问题，而是什么时间、如何实施的问题了。 -
[转帖]软件可测试性的启发--陈能技
2009-06-05 10:56:28
软件可测试性的启发
陈能技
2007-8-10
原文：Heuristics of Software Testability James Bach, Satisfice, Inc.
The better we can control it, the more the testing can be automated and optimized.
我们越是能控制它，测试越能被自动化和优化
• A scriptable interface or test harness is available.
存在可编程的接口或测试桩
• Software and hardware states and variables can be controlled directly by the test engineer.
软件和硬件的状态、变量能被测试工程师直接控制
• Software modules, objects, or functional layers can be tested independently.
软件模块、对象或功能层能被独立地测试
What you see is what can be tested.
你能看到的都是能被测试的
• Past system states and variables are visible or queriable (e.g., transaction logs).
系统的过去状态和变量是可见的或可查询的（例如：事务日志）
• Distinct output is generated for each input.
为每个输入产生独立的输出
• System states and variables are visible or queriable during execution.
在执行过程中系统的状态和变量是可见的或可查询的
• All factors affecting the output are visible.
所有影响输出的因素都是可见的
• Incorrect output is easily identified.
不正确的输出能轻易被识别
• Internal errors are automatically detected and reported through self-testing mechanisms.
内部错误通过自测机制被自动发现和报告
To test it, we have to get at it.
为了测试它，我们需要了解它
• The system has few bugs (bugs add analysis and reporting overhead to the test process).
系统有很少bug（bug给测试过程增加分析和报告的成本）
• No bugs block the execution of tests.
没有bug阻止测试的执行
• Product evolves in functional stages (allows simultaneous development and testing).
产品在功能阶段进化（允许开发和测试同时进行）
• Source code is accessible.
源代码可被访问
The simpler it is, the less there is to test.
越简单，需要的测试越少
• The design is self-consistent.
设计是有条理的
• Functional simplicity (e.g., the feature set is the minimum necessary to meet requirements)
功能简单（例如：功能特性集合是满足需求的最小集）
• Structural simplicity (e.g., modules are cohesive and loosely coupled)
结构简单（例如：模块是松耦合的）
• Code simplicity (e.g. the code is not so convoluded that an outside inspector can’t effectively review it)
代码简单（例如：代码不会费解到外部检查者不能有效地进行审查）
The fewer the changes, the fewer the disruptions to testing.
越少改变，对测试的影响越少
• Changes to the software are infrequent.
对软件的更改很少发生
• Changes to the software are controlled and communicated.
对软件的更改是被控制的和充分沟通的
• Changes to the software do not invalidate automated tests.
对软件的更改不会造成自动测试的无效
The more information we have, the smarter we will test.
了解越多的信息，我们将测得更巧妙
• The design is similar to other products we already know.
设计类似于其他我们已经知道的产品
• The technology on which the product is based is well understood.
充分了解产品基于什么技术构造
• Dependencies between internal, external and shared components are well understood.
充分了解内、外部和公共组件之间的依赖关系
• The purpose of the software is well understood.
充分了解软件的用途
• The users of the software are well understood.
充分了解软件的用户
• The environment in which the software will be used is well understood.
充分了解软件的使用环境
• Technical documentation is accessible, accurate, well organized, specific and detailed.
技术文档是可访问、准确、组织良好、明确和详细的
• Software requirements are well understood.
充分了解软件需求
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Testing_is_believing/archive/2007/08/10/1736187.aspx -
[转帖]武装你的测试--陈能技
2009-06-05 10:51:03
原文：Boost Your Testing Super Powers - Secret Tools to Add to Your Utility Belt （James Bach）
当我还是3岁的时候，我最喜欢的卡通片是《The Fantastic Four》。当我的妈妈发现的时候，她老是转台并禁止我看。太暴力了，我想。我想她是为了纠正我，就逼着我看《Mr. Rogers》。但是我已经中毒太深了。
几天前，我意识到当我在测试时我会感觉像一个超级英雄。我在做探索性测试时感觉就像驾驶着飞机飞过一个产品，使用我的X光视力去寻找bug。我能像Clark Kent一样，假装成一个普通人，但是当我需要的时候我能跳过很高的楼。拥有仿生耳，超强的力量，能扭曲时间和控制自然力量等。
是什么给了我这些神奇的力量，超越那些平庸的测试者呢？一组特殊的工具。什么工具？不是http://www.testingfaqs.org/tools.htm上列的测试工具。我所说的工具甚至不是能买到的测试工具。但是他们给你的力量是很强的。
X-Ray Vision, Super Strength, and Time Control
X光视力、超能力、时间控制能力
有些工具能让你看到看不见的东西。
把一个晶体管收音机放到处理器的6英寸附近，调到AM975左右的频道，你就能听到处理芯片的工作声音。如果你想知道一个看起来好像挂起的程序究竟是在运算过程中还是真的停止响应了，这是个好办法。
Restorator是一个能把软件的所有资源都抽取出来的工具，包括所有对话框，菜单文本，储存在资源的所有错误信息。这个工具不仅方便你了解软件的所有功能，而且能识别出软件的不同build的版本之间在资源上的差异。
InCtrl5能让你知道两个时间点之间哪些文件和注册表内容改变了。把它用在安装测试，或用于发现程序如何修改文件。
有些工具能让你做普通用户不能做的东西。例如，EZ Macros能让你做轻量级的录制和回放。它能部分地替代昂贵的GUI测试工具。Kleptomania可以从通常不能拷贝的对话框、图像和错误信息拷贝文本出来。Print Key Pro给你精确的屏幕截图。
Spector是我最爱的工具之一，它在我测试的过程中每秒取一次屏幕截屏。这个工具不怎么打扰你的工作，但是对于回答你的“我刚才做什么了？”这一问题会有很大帮助。
我的绝对最爱是Perl，如果你想学编程，考虑一下Perl。它的显著强项是对数据的处理（例如在你想分析或创建数据文件时），有很多现成的module可以让你轻而易举地完成很多事情，像控制软件程序或监视系统资源，或是模拟web broser等，最重要的是，Perl是免费的。
Look for a Tool's Secret Identity
寻找工具的秘密特性
这些工具都有共同的特征：价格便宜，甚至免费。并且都不是设计给测试用的。例如Spector,它是为了监视越轨的夫妇或迷途的少年而设计的。
为了找到这些有用的工具，你要注意收集，而不是简单地在Yahoo上输入“测试工具”。时不时去Download.com看看。除了到下载网站找，还可以看看开发包附带的工具，操作系统资源包，MSDN，技术书籍附带的CD，或者问问开发人员他们最喜欢的工具。有些工具是操作系统的一部分，但是你要有意识地找才知道有这样的工具。
好吧！带上你的秘密武器出发吧，消灭bug的时候到了！
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Testing_is_believing/archive/2007/08/23/1756597.aspx -
很难的面试题，大家来试试
2008-06-12 01:14:15
有道面试题，据说是google的，大家做下试试:
1到1000的倒数，有最大循环节的是哪个？循环节为多少位？ -
XML简单教程
2008-06-08 17:49:40
XML是一种标识语言。一个XML元素是由开始标签、结束标签以及标签之间的数据构成的。开始和结束标签用来描述标签之间的数据。标签之间的数据被认为是元素的值。例如，在下面一个XML元素的例子中，元素“director”的值是“Éd Wood”。
<director>Ed Wood</director>
元素名（“director”）允许你把“Ed Wood”这个值标出来，这样你就能把这些数据同另外类似的数据区分开来。例如，有可能另一个元素的值也是“Ed Wood”。
<actor>Ed Wood</actor>
由于每个元素都有不同的标签名，所以你能很容易把上面两个元素的值区别开来。如果没有办法把数据标出来，两鲇型档脑鼗峄煜鹄础?lt;/FONT>
处理XML文档
一个基本的XML文档就是一个XML元素，它可以嵌套XML元素。例如，下面的XML元素“books”就是一个有效的XML文档。
<books> <book isbn="0345374827"> <title>The Great Shark Hunt</title> <author>Hunter S. Thompson</author> </book> </books>构建一个基本的XML文档需要记住关键的三点：所有元素必须有结束标签；所有元素必须正确的嵌套（不允许交迭元素）；所有特征值必须加引号。
处理XML数据岛
什么是XML数据岛?
数据岛是指存在于HTML页面中的XML代码。数据岛允许你在HTML页面中集成XML，对XML编写脚本，不需要通过脚本或<OBJECT>标签读取XML。几乎所有能够存在于一个结构完整的XML文档中的东西都能存在于一个数据岛中。包括处理指示、DOCTYPE声明和内部子集。（注意，编码串不能放在数据岛中。）
数据岛的XML可以是内嵌的：
<XML ID="XMLID"> <customer> <name>Herbert Hanley</name> <custID>81422</custID> </customer> </XML>或者在XML标签中通过SRC属性引用：
<XML ID="XMLID" SRC="customer.xml"></XML>
处理指导
简单处理XML。把XML放到一个XML元素中，并且给这个XML元素一个ID。
类似于文档对象访问一个XML数据岛
什么是XML文档对象?
XML文档对象是指一个拥有属性和方法的对象，你可以利用这些属性和方法访问和处理XML文档。当一个XML数据岛被读取和解析时，就会创建一个XML文档对象。
怎样访问XML数据岛?
下面是一个带有数据岛的HTML页面。数据岛在<XML>元素中。
<HTML> <HEAD> <TITLE>HTML with XML Data Island</TITLE> </HEAD> <BODY> <P>Within this document is an XML data island.</P> <XML ID="resortXML"> <resorts> <resort>Calinda Cabo Baja</resort> <resort>Na Balam Resort</resort> </resorts> </XML> </BODY> </HTML>你能通过ID属性访问数据岛，“resortXML”成为文档对象的名称。你能利用这个对象的方法和属性访问它的根节点和孩子节点。在上面的例子中，根节点是<resorts>，孩子节点是<resort>。下面列出了一些属性和方法，可用来访问XML文档的节点。
-
XMLDocument：返回对XML文档对象模式的引用。
-
documentElement：返回XML文档的根节点。
-
childNodes：返回节点的孩子节点目录。
-
item：通过索引访问目录中的个别节点。索引值是从0开始的，所以item(0)返回第一个节点。
-
text：返回节点的内容。
下面的代码访问第二个孩子节点<resort>并返回它的内容“Na Balam Resort”。
resortXML.XMLDocument.documentElement.childNodes.item(1).text
访问XML对象模式
什么是XML对象模式?
微软IE5中的XML解析器揭示了XML对象模式，允许你访问和处理XML文档中的节点。当解析器读取并且解析一个XML文档时，它将建立一棵节点树，每个节点都能通过脚本来访问。
例如，如果解析器读取并且解析下面的XML文档，它将创建一个能通过文档ID值(xmlDocument)被引用的文档对象，一个表现根节点的对象和一个表现树中其余节点的对象。
怎样访问树中的节点?
请试着在下面的数据岛中找出访问每个节点所需要的代码。
<XML ID="xmlDocument"> <class> <student studentID="13429"> <name>Jane Smith</name> <GPA>3.8</GPA> </student> </class> </XML>在XML文档中使用数据类型
什么是XML文档中的数据类型?
微软提供的XML Schema版本支持数据类型。作为一项预先展示的技术，它对于那些想要用schema和丰富的数据类型构造原型和增长经验的开发者来说是很有用的。微软积极参与制定逐步形成的W3C的XML Schema标准。开发者需要注意这个版本的XML Schema是要变化的。在微软IE5当中，元素值能被指定数据类型。数据类型能够通过XML Schema或根据实际情况被指定。以前，XML元素值只有一种类型（字符串），所以开发者要处理XML文档必须花时间转换元素值。键入你的XML数据，解析器会进行数据类型转换。另外，由于元素值有特定的数据类型，所以元素值的改变也要符合数据类型。这给你提供了一种确认使用者输入的方法。
如何指定XML元素值的类型？
通过XML Schema指定元素值的类型，你必须在XML Schema的开头声明数据类型的名域和schema的名域。
<Schema xmlns="urn:schemas-microsoft-com:xml-data" xmlns:dt="urn:schemas-microsoft-com:datatypes">
dt前缀用来在schema中表示指定数据类型的类型属性。
<ElementType name="NUMBER" content="textOnly" dt:type="number"/>
通过dt属性指定元素类型，你必须在XML文档的开头声明数据类型的名域。
<NUMBERS xmlns:dt="urn:schemas-microsoft-com:datatypes">
dt前缀用来给一个元素的例子指定数据类型。
<NUMBERS xmlns:dt="urn:schemas-microsoft-com:datatypes"> <NUMBER dt:dt="number">44533</NUMBER> </NUMBERS>访问经过类型定义的XML值
什么是经过类型定义的XML值？
经过类型定义的XML值是指在XML Schema中被指定数据类型的元素值。XML解析器使用schema来确认文档。
微软提供的XML Schema版本支持数据类型。作为一项预先展示的技术，它对于那些想要用schema和丰富的数据类型构造原型和增长经验的开发者来说是很有用的。微软积极参与制定逐步形成的W3C的XML schema标准。开发者需要注意这个版本的XML Schema是要变化的。
除了拥有字符串值以外，每个XML元素也可以有经过类型定义的值。例如下面的XML元素：
<date>1970-09-30</date>
值可以是“1970-09-30”，也可以是经过类型定义的“Web Sep 30 00:00:00 PDT 1970.”
如何访问经过类型定义的XML值？
可以通过XML对象模式访问经过类型定义的数据。就好象你能根据元素节点的节点值性质找到元素值一样，你能根据元素本身的节点类型值找到经过类型定义的元素值。
例如，考虑一下下面的XML文档：
<?xml version="1.0"?> <weather xmlns="x-schema:weatherSchema.xml"> <date>1970-09-30</date> <degrees>67.5</degrees> </weather>“weatherSchema.xml”是下面这个文件：
<Schema xmlns="urn:schemas-microsoft-com:xml-data"xmlns:dt="urn:schemas-microsoft-com:datatypes"> <ElementType name="date" content="textOnly" dt:type="date"/> <ElementType name="degrees" content="textOnly" dt:type="float"/> <ElementType name="weather" content="eltOnly"/> <element type="date"/> <element type="degrees"/> </ElementType> </Schema>如果你要处理“degrees”这个元素（xmlDocument.documentElement.childNodes.item(1)），你可以根据节点类型值来访问它的值（xmlDocument.documentElement.childNodes.item(1).nodeTypedValue）。
XML Schema
什么是XML Schema？
W3C XML Activity Page 声明：“尽管XML1.0提供了一种机制，文档类型定义（DTD）给标记的使用加了限制，但是对XML文档的自动处理需要更严格更全面的工具。需要主要体现在对应用软件各部分的结合、文档结构、属性和数据类型等等的约束。W3C XML Schema工作组正忙于定义XML文档的结构、内容和语义。”
微软IE5支持XML Schema，这项预先展示的技术是建立在递交给W3C的XML-Data草案的基础上的。XML Schema可被认为是XML-Data草案的子集，它符合文档内容描述（DCD）提议的特点。
IE5中的XML解析器能够根据文档类型定义(DTD)或XML Schema解析XML文档。XML Schema是用来声明内容模式的基于XML的语法。它有DTD所有的功能，并且还有其他的功能如数据类型定义。
如何建立XML Schema？
请在下面的XML文档中找一找每个节点的schema声明。
<class xmlns="x-schema:classSchema.xml"> <student studentID="13429"> <name>Jane Smith</name> <GPA>3.8</GPA> </student> </class>你会注意到在上面文档中默认的名域是“x-schema:classSchema.xml”。这告诉解析器根据URL(“classSchema.xml”)上的schema(x-schema)来解析整个文档。
下面是上面那个文档的完整的schema。注意schema的根元素中的名域声明。第一个(xmlns=”urn:schemas-microsoft-com:xml-data”)表明这个XML文档是一个XML Schema。第二个(xmlns:dt=”urn:schemas-microsoft-com:datatypes”)允许schema处理者在“ElementType”和“AttributeType”声明中的“type”属性前加“dt”前缀来说明元素的类型和内容的特征。
<Schema xmlns="urn:schemas-microsoft-com:xml-data" xmlns:dt="urn:schemas-microsoft-com:datatypes"> <AttributeType name='studentID' dt:type='string' required='yes'/> <ElementType name='name' content='textOnly'> <ElementType name='GPA' content='textOnly' dt:type='float'/> <ElementType name='student' content='mixed'> <attribute type='studentID'/> <element type='name'/> <element type='GPA'/> </ElementType> <ElementType name='class' content='eltOnly'> <element type='student'/> </ElementType> </Schema>schema用“Schema”元素开头，“Schema”元素包括schema名域的声明，在本例中还包括数据类型名域的声明。Schema的内容以“AttributeType”和“ElementType”的声明开头。
<AttributeType name='studentID' dt:type='string' required='yes'/> <ElementType name='name' content='textOnly'> <ElementType name='GPA' content='textOnly' dt:type='float'/>
这些声明接下来的是刚声明过元素的父亲元素的“ElementType”声明。
<ElementType name='student' content='mixed'> <attribute type='studentID'/> <element type='name'/> <element type='GPA'/> </ElementType>这个过程继续下去，直到所有元素都已经声明了。
不同于DTDs，XML Schema允许有一个开放的内容模式，你可以进行定义数据类型、使用默认值等等操作而不必限定内容。
在下面的schema中，“GPA”元素的类型被定义并有一个默认值，但在“student”元素中没有其他节点被声明。
<Schema xmlns="urn:schemas-microsoft-com:xml-data" xmlns:dt="urn:schemas-microsoft-com:datatypes"> <AttributeType name="scale" default="4.0"/> <ElementType name="GPA" content="textOnly" dt:type="float"> <attribute type="scale"/> </ElementType> <AttributeType name="studentID"/> <ElementType name="student" content="eltOnly" model="open" ōrder="many"> <attribute type="studentID"/> <element type="GPA"/> </ElementType> </Schema>上面的schema允许你只确认你所关心的区域。这使你对文档有更多的控制，并允许你使用schema提供的一些特性而不必严格确认。
一些说明：
- “ElementType”和“AttributeType”声明必须放在“attribute”和“element”内容声明之前。例如，在上面的schema中，“GPA”元素的“ElementType”声明必须放在“student”元素的“ElementType”声明之前。
- “order”属性的默认值是建立在“content”属性的值上的。当content值为“eltOnly”时，order默认值是“seq”。当content值为“mixed”时，order默认值是“many”。
-
-
using namespace std详解
2008-06-08 14:13:46
using namespace std详解
一 ：
<iostream>和<iostream.h>是不一样，前者没有后缀，实际上，在你的编译器include文件夹里面可以看到，二者是两个文件，打开文件就会发现，里面的代码是不一样的。
后缀为.h的头文件c++标准已经明确提出不支持了，早些的实现将标准库功能定义在全局空间里，声明在带.h后缀的头文件里，c++标准为了和C区别开，也为了正确使用命名空间，规定头文件不使用后缀.h。
因此，当使用<iostream.h>时，相当于在c中调用库函数，使用的是全局命名空间，也就是早期的c++实现；当使用<iostream>的时候，该头文件没有定义全局命名空间，必须使用namespace std；这样才能正确使用cout。
二：
所谓namespace，是指标识符的各种可见范围。
C＋＋标准程序库中的所有标识符都被定义于一个名为std的namespace中。
由于namespace的概念，使用C＋＋标准程序库的任何标识符时，可以有三种选择：
1、直接指定标识符。例如std::ostream而不是ostream。完整语句如下：
std::cout << std::hex << 3.4 << std::endl;
2、使用using关键字。
using std::cout;
using std::endl;
以上程序可以写成
cout << std::hex << 3.4 << endl;
3、最方便的就是使用using namespace std;
例如：
#include <iostream>
#include <sstream>
#include <string>
using namespace std;
这样命名空间std内定义的所有标识符都有效（曝光）。就好像它们被声明为全局变量一样。那么以上语句可以如下写:
cout << hex << 3.4 << endl;
因为标准库非常的庞大，所程序员在选择的类的名称或函数名时就很有可能和标准库中的某个名字相同。所以为了避免这种情况所造成的名字冲突，就把标准库中的一切都被放在名字空间std中。但这又会带来了一个新问题。无数原有的C++代码都依赖于使用了多年的伪标准库中的功能，他们都是在全局空间下的。
所以就有了<iostream.h>和<iostream>等等这样的头文件，一个是为了兼容以前的C++代码，一个是为了支持新的标准。
命名空间std封装的是标准程序库的名称，标准程序库为了和以前的头文件区别，一般不加".h"
