配置项测试的理解，我觉得得先清楚两个概念：
①软件配置项：我认为软件配置项就是一个开发完成的,已经进入配置管理的,准备提供给客户的产品。可以是可执行代码，也可以是产品文档。
②软件需求规格说明书：软件需求规格说明书是在项目前期进行需求分析的时候得到的一份文档，这份文档中描述了用户的需求，是初始阶段甲乙双方对项目的共同理解，比如一些界面设计，流程描述，这个是整个开发工作的基础。
那么配置项测试，就可以理解成是对软件配置项的一种检查，检查它与软件需求规格说明书是否一致。比如对可执行代码进行功能测试，关注它的功能是否与软件需求规格说明书中要求的一致。或者对一份产品文档进行文档审查，关注是否已经按照软件需求规格说明书中要求，描述了安装步骤，或者文档中描述的接口是否与软件需求规格说明书中的相同。
所以配置项测试，需要在单元测试和集成测试之后进行。
我理解的测试顺序应该是：单元测试->集成测试->配置项测试->系统测试->确认测试，如果项目存在变更，还需要进行回归测试。当然，这个只是帮助理解，实际中肯定不会是按顺序做的。
个人观点：
这里的配置项测试，可以简单看做单元测试的下一个级别，即对单独配置项进行的测试，这里如果你对测试理解不上去，就换个词，检查~
在一些体系中，对测试角色所赋予的工作范围是包括文档检查、代码静态检查的，也就是所谓的配置项测试。这部分工作完成后再进行单元测试、集成测试、系统测试等等一系列后续工作。
个人观点：这里的配置项测试，可以简单看做单元测试的下一个级别，即对单独配置项进行的测试，这里如果你对测试理解不上去，就换个词，检查~在一些体系中，对测试角色所赋予的工作范围是包括文档检查、代码静态检查的，也就是所谓的配置项测试。这部分工作完成后再进行单元测试、集成测试、系统测试等等一系列后续工作。
摘要：现在，软件配置管理的环境及其工具越来越得到人们的重视。本文尝试就现存的CM体系中的以用户为主体的一些概念作详细说明。就如一个光谱，某些概念可能是另一些概念的延伸或总结。由于在整个软件工程家族中对于CM的功能性没有共通的术语,且许多CM系统在概念的应用上也是千差万别，因此要从CM系统中抽象出一些概念是难乎其难的事了。正因为这样，本文陈述的每一概念是其在某一具体的CM系统中的概念。有一部分的概念陈述是针对CM体系的用户极为重要的问题。没有哪一个CM系统能提供CM体系不同用户要求的所有功能。而且，每一CM系统解决的问题只是所有概念的一部分。为了完成本报告，对CM体系的功能以举例的形式作了简短的说明。
1 简介
现在，软件配置管理的环境及其工具越来越得到人们的重视，这一点从CM体系中提供的概念谱中就显而易见。本文对这些概念进行了阐明。首先，在一典型的CM情形中，我们 对CM和CM体系做了更为广泛的定义。
1.1 配置管理的定义
软件配置管理是一控制软件系统演变的学科。关于CM的经典讨论在条文[3]、[4]中进行了阐述。IEEE标准729-1983就CM以下的内容进行了规范的定义。
在IEEE标准729-1983中，软件配置管理的定义包括：
标识——识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
控制——通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。例如，它将解决哪些修改会在该产品的最新版本中实现的问题。
状态统计——记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。例如，它将解决修改这个错误会影响多少个文件的问题。
审计和审查——确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。例如，它将解决目前发布的产品所用的文件的版本是否正确的问题。
生产——对产品的生产进行优化管理。它将解决最新发布的产品应由哪些版本的文件和工具来生成的问题。
过程管理——确保软件组织的规程、方针和软件周期得以正确贯彻执行。它将解决要交付给用户的产品是否经过测试和质量检查的问题。
小组协作——控制开发统一产品的多个开发人员之间的协作。例如，它将解决是否所有本地程序员所做的修改都已被加入到新版本的产品中的问题。
软件配置管理的解决方案涉及面很广，将影响软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。
配置管理解决方案将影响过程模型和模型的使用者，是因为它强行推行组织的方针政策和工作规程，并对工作过程进行跟踪。它从开发和维护的及时性方面影响产品的质量。例如，配置管理机制可以保证为每一个发布的版本提供内容清单，通过一致性维护提高产品的质量。配置管理解决方案通常在组织范围内推行，实际上配置管理系统是组织内部信息交换的中心，它影响组织内的每一个成员及组织的业务流程。
总之，一个配置管理解决方案的制定包括配置管理计划、过程的定义、与使用者的交流、自动化支持和做出管理决定等活动。
软件组织应该提出不同层次的配置管理视角，这些层次包括：公司级、项目级、程序员级和应用级。公司级视角提供组织的全貌图和配置管理过程的描述；项目级视角是与项目相关的各项目组可以使用不同的配置管理方案；程序员级视角是专门为程序员提供的且具有某些特定的配置管理功能；应用级视角关心的是配置管理如何应用到具体的问题中去。
1.2 CM系统的定义
至于怎样才算是构成CM系统的，对此还没有普遍接受的定义。例如：假如系统有版本控制功能，它是否就是一个CM系统呢？理想的CM系统是基于以上定义提供所有功能的系统。但是， 实际中的系统只能提供某种程度上实现的版本控制功能、配置识别功能、系统构建功能、系统建模功能，或某种程度上提供CM的意识就被软件工程大家族认为是CM系统了。应注意的是， 现有的CM体系提供只是一种功能的综和而不是一标准的体系。本报告提及15个CM系统，目前至少有40个系统可以为今所用。
这里，有必要将CM系统和CM工具两概念区分一下。CM系统可看作是其支持环境的一部分且以这种形式被售出。譬如，在RATIONAL[14]环境下CM功能成为该环境必不可少的一部分。CM工具可看作是一独立的工具。譬如，版本控制系统（RCS）只是一个工具，因为它可被安装在一个现有环境中。由于这种区分在本文不是那么重要，术语CM系统就被用来表示这两概念。
1.3 CM以用户为导向的典型情形
在讨论CM体系之前，我们描述了一个简单、典型的、以用户为导向的CM系统来作参考。在此情形下，包含了具有不同职责的人员：负责软件小组的项目经理、负责CM规程和方针的配置经理、负责软件产品开发与维护的软件工程人员、负责验证产品正确性的测试人员、负责确保产品高质量的质量保证经理、使用产品的用户。
每一角色都有他们的目标和任务。对项目经理来讲，其目标是确保产品在一定的时间框架里得以开发。因此，经理监控开发过程并发现问题，解决出现的问题。这些又必须通过对软件系统的现状形成报告并予以分析以及对系统进行审核才能完成。
配置经理的目标是确保用来建立、更改及编码测试的规程和方针得以贯彻执行，同时使有关项目的信息容易获得。为了对编码更改形成控制，经理引入对正规请求更改的机制，评估更改的机制[通过更改控制机构（CCB），由它负责批准对软件系统的更改]，和批准更改的机制。经理负责为工程人员创建并宣导任务单，基本上创建项目的框架。同时，经理还收集软件系统中构件的相关数据，比如说用以判断系统中出现问题的构件的信息。
对于软件工程人员，他们的目标是有效地创造出产品。这就意味着工程人员在创建产品、编码测试及支持文档的产生中不必相互间干涉。与此同时，他们能有效地进行沟通与协作。他们利用工具以帮助创建性能一致的软件产品，通过相互通知要求的任务和完成的任务来进行沟通与协调。做出的更改通过将它们进行融合、分散和冲击而得知。产品中的所有元素的演变连同其更改的原因及实际更改的记录都予以保留。工程人员在创建、变更、测试及编码的汇合上有自己的工作范围。在某一点上，编码会形成一个基线，它使得进一步开发得以延续，为其它平行开发得以进行。
测试的目标是确保产品经过测试达到要求。这里包括产品某一特定版本的测试和对某个产品的某种测试及其结果予以记录。将错误报告给相关人员并通过回归测试进行修补。
质量保证经理的目标是确保产品的高质量。这意味着特定的规程和方针应当完成并得到相关的批准。错误应得到纠正并应对变化的部分进行充分测试。客户投诉应予以跟踪。
不同的客户使用的产品版本也是不同的。客户总是遵循规则来做变更要求、错误显示及产品改进。
理想的CM系统在这种情形下应能够支持所有这些目标、角色和任务。这也意味着这些角色、任务和目标决定了一CM系统要求的功能。本文提出的一些概念就是为了解决这些问题。
1.4 本文的结构
在简介中就CM和CM系统进行了定义，列出一典型的CM情形，这样一来也就暗示了CM体系的要求。第二节描述了CM系统中以用户为导向的一些问题。这些问题影响用户对CM系统的期望。第三节描述了CM概念谱。第四对CM体系的未来做了探讨，第五节是结论。附录是本文CM体系索引的概览。
2 CM体系用户的有关问题
许多与CM有关的问题直接影响到CM系统的用户。现有的CM体系从不同的角度解决这些问题。尽管本文是为了就现有CM体系的特色进行探讨，但对这些问题的阐述仍然有必要因为它们影响到用户对一CM系统的期望。这些问题包括：
用户的角色问题：
不同CM体系用户对CM体系的功能的要求也就不同。
集成问题：
不同的集成问题影响到CM系统的功效。
启用CM的时机问题：
一项目组何时启用CM系统取决于该CM系统的能力。
控制水平问题；
一CM系统对产品及产品的管理的控制水平可以是不同的。
过程与产品问题：
一理想的CM系统提供CM的过程、产品及其附件。
自动化水平问题：
CM功能的实现总是手工与自动程序的统一。
功能问题：
CM体系具备实现CM众多功能的许多特点。
以下将对此做进一步说明。
2.1 用户的角色问题
正如1。3节中的情形表示的一样，CM体系的用户是多种多样的。每一个用户都有特定的角色，对CM也有不同的观点，因此，对CM系统的要求也就不同。这种要求是很分明的同时又是互补的。图1是一功能组描述了项目经理、配置经理、软件工程人员、质量保证经理及客户对CM系统的期望。图1中的每一个方框代表的是一主要的功能区域。图1显示在方框外（审核、统计、构件、结构与创建）在任何CM系统中都可独立存在的功能区域，但当与团队和过程功能合并时，就得到一个完整的（或综合的）CM系统了。
北京顶测教育为您解答
内容全部来源于网络收集，如有侵权，请联系网站删除：QQ：24596024