关键字：软件测试知识帖
正规检视介绍会议： 介绍会议阶段是评审流程可选择的阶段。如果检视小组成员不熟悉检视对象以及相关的背景，那么这个会议就应当安排举行。在介绍会议上，作者介绍产品的理论基础，产品同被开发的系统其余部分的关系，产品的功能和产品的主要应用，以及在产品开发过程中采用的开发方式。所有的检视者必须参加介绍会议。
召开介绍会议的主要原因如下：
1、正规检视小组不熟悉检视对象
2、检视对象是新开发的或者是首次进行正规检视
3、正规检视工作在检视对象的项目中被首次采用
第58贴【2004－7－15】：软件配置管理介绍
1、软件配置管理概念：
软件配置管理是通过在软件生命周期的不同时间点上对软件配置进行标识并对这些标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。
配置：软件系统的功能属性。
配置项：软件系统的逻辑组成，即与某功能属性相对应的文档或代码等。
2、软件配置管理的四个基本过程：
配置标识： 标识组成软件产品的各组成部分并定义其属性，制定基线计划。
配置控制： 控制对配置项的修改。
配置状态发布： 向受影响的组织和个人报告变更申请的处理过程，通过的变更及他们的实现情况等。
配置评审： 确认受控软件配置项满足需求并就绪。
3、配置库：对各基线内容的存储和管理的数据库
开发库：程序员工作空间，始于某一基线，为某一目的开发服务，开发完成后，经过评审回归到基线库。
基线库：包括通过评审的各类基线，各类变更申请的记录和统计数据。
产品库：是某一基线的静态拷贝，基线库进入发布阶段形成产品库。
4、检视对象中应用了最新的技术
第59贴【2004－7－16】：利用PC－LINT进行代码排错
PC-LINT是GIMPEL SOFTWARE公司的产品，是一种软件质量保证工具，用于程序排错，可对windows、unix平台下的C、C++代码进行最仔细的语法检查，可检查一些在普通编译器不易发现的句法、一般逻辑错误等，是程序员不可多得的排错工具。
如果给 PC-LINT工具下一个形象点的定义，那就是：一种更加严格的编译器。它不仅可以象普通编译器那样检查出一般的语法错误，还可以检查出那些虽然完全合乎语法要求，但很可能是潜在的、不易发现的错误。
许多国外的大型专业软件公司，如微软公司，都把它作为程序检查工具，在程序合入正试版本或交付测试之前一定要保证通过了LINT检查，他们要求软件工程师在使用LINT时要打开所有的编译开关，如果一定要关闭某些开关，那么要给出关闭这些开关的正当理由。
在开发、测试过程中，除了正规检视、代码走读、代码审查等活动可以有效的帮助获得正确的代码，运用PC-LINT、LOGISCOPE等工具也是很好的排错手段，尤其是PC-LINT，以其方便、准确、严格的特点在排除程序一般性错误方面有着明显的优势，其付出的工作量比正规检视、代码走读的要少很多。
可想而知，如果从编码后第一次编译程序时就使用LINT来检查程序，并且保证消除所有的LINT告警，程序质量的提高是不言而喻的。
第60贴【2004－7－17】：LOGISCOPE介绍
LOGISCOPE是为软件的全面质量控制而开发的强大工具，可以用在编程、测试和维护阶段。LOGISCOPE五个模块的功能：
(1) 阅读器(Viewer)：以文件调用图(各部件文件之间的关系)及组件调用图(函数和程序间的调用关系)的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序，在不同级别上的引导有助于整个应用程序的理解。
(2) 效果检查器(ImpactChecker)：允许用户检查使用的资源(文件、函数、用户定义类型、全局变量、结构成员常量)。它有助于我们理解函数间的信息流(参数传递)，以及数据和其它应用程序资源间的关系。
(3)规则检查器(RuleChecker)：所有关心无质量风险地开发软件的公司(比如航天公司)定义了编程规则和质量目标。这样做的好处是公司编程行为的一致性、确保易于维护、提高可靠性、易于移植到其它机器上，等等。我们可以用规则检查器(RuleChecker)确立编程标准，保证质量控制。
(4) 测试检查器(TestChecker)：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器(TestChecker)和动态分析器 (Dynamic Analyzer)通过阅读器产生用于应用程序分析的数据。
(5) 代码检查器(CodeChecker)：验证应用程序与质量模型的一致性。代码检查器和静态分析器(Static Analyzer)通过阅读器(Viewer)产生用于应用程序分析的数据。代码检查器(CodeChecker)可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。
第61贴【2004－7－19】：软件估计
软件估计、测量、度量过程是软件开发过程的重要组成部分，是开发过程不断改进的原因所在。软件组织如果没有什么有效手段评估和测量开发过程，即使是依赖优秀的个人和开发团体成功的开发了多个产品或项目，也不能将经验和教训记录下来供以后的开发工作参考并用于改进开发过程。产品或项目的成功总是过多的依赖个人的努力而不是丰富的历史经验数据。
软件组织需要制订开发过程相关的软件估计、测量、度量活动规范、模板，并且把软件估计、测量等活动列入了日常的开发工作的一部分。并以阶段性数据形式进行数据估计和测量工作，这些将成为以后开发过程重要的参考资源。
软件估计过程主要包括规模、工作量、进度的估计。规模估计有许多已成为标准的估计方法，常见的有Wideband Delphi Technique、Pert Sizing、功能点、 类比法以及一些估计工具。
第62贴【2004－7－20】：CMM2级之需求管理
任何一个产品都应满足用户相应的需求。但是满足用户需求的同时会存在两个问题：一是需求在开发过程中会发生变化，如何控制与管理这些变化？二是从需求到产品要经过许多步骤，如系统设计、详细设计、具体实现等，如何保证这些步骤没有背离产品的需求？
需求管理关键过程域就是针对这两个问题提出相应的目标。软件需求可能是系统需求的一部分或是全部（纯粹的软件产品），无论是哪种情况，需求管理的第一个目标就是软件需求应能被控制，并可产生一个可用于软件工程过程和管理过程的基线。需求管理的第二个目标是确保软件项目计划、开发活动、产品与需求一致。需求管理的最终目的是在用户与实现用户需求的项目之间达成共识，需求管理活动就是为了建立并维护这种共识。
第63贴【2004－7－21】：CMM2级之软件项目计划
软件项目计划（SPP）常常不能按期完成，主要原因有两个方面：一是由于计划执行和管理的能力不足；二是计划本身是否合理和有效，计划的不合理性和无效性造成了大多数项目拖延，甚至失败。项目的跟踪与监督则是如何保证计划的执行和调整。
建立合理的开发计划的基础是对项目规模、资源要求和风险等要有一个合理的估算。这个估算过程应是规范的，而不是任意的。例如，如果提出一个项目计划需要40个软件工程师工作三个月的计划，那么就要问这些数据是如何得出的。用户提出的时间和费用的要求仅能作为项目计划的约束条件，而不能作为项目计划的基础。开发计划要包括所有项目活动和所有参加方面的责任，这些活动和责任需要文档化，以保证有效地将计划传达给项目的各个参加方。在项目开发计划执行前，各个项目参加方要认同所承担的项目责任，这种认同是项目计划有效性的一个基本保证。
第64贴【2004－7－22】：CMM2级之软件项目跟踪与监控
软件工程项目是否成功的主要因素在于项目管理，而项目是否能有效地进行管理的关键在于项目过程的可见性。由于软件项目过程是一个逻辑活动过程的组合，因此，它不具备一个物理过程那样的可见性。软件项目跟踪与监控的目的就是为项目实际过程提供充分的可见性，以保证当项目执行偏离项目计划时能采取有效的解决措施。
项目跟踪是基于计划的，对一个项目要设定适当的检查点。在检查点上要将执行结果、执行状态和项目开发计划进行比较。若发现较大的差异，则采取适当的步骤进行调整。在必要的情况下，也需要对项目计划本身进行修改和调整。若在修改计划时，改变了某些项目责任，那么这些改变必须得到有关责任方面的重新认同。
第65贴【2004－7－23】：CMM2级之子合同管理
由于CMM是美国国防部投资研究的项目，而美国军方有大量的子合同转包，因此子合同管理也成为了一个基本的KPA。子合同管理的目的就是选择合格的软件承包商，并可进行有效地管理。子承包商选择应由项目责任者负责，子承包商的选择是基于能力的，项目的责任者与子承包商对所承包的项目责任要有一致的认同，并保持不断地交流。项目责任者负责根据合同的责任跟踪子承包商的实际工作结果。
第66贴【2004－7－25】：CMM2级之软件质量保证
软件质量保证是项目管理提供的过程可见性的一个工具。由于用于开发软件系统或软件产品的过程是决定项目成功与否的关键因素，因此软件质量保证的工作是评审和审计软件活动与软件产品。评审和审计的依据是规定用于项目的步骤和相关标准。软件质量保证活动不能是随意的，必须经过充分的讨论和协商。相关的组织和个人要了解质量保证的活动和质量保证活动的结果。为了解决质量保证组织与开发组织对某些项目开发活动或开发出的产品的评价发生的争议和分歧，企业要定义更高层次的管理组织，负责解决这些争议和分歧。
第67贴【2004－7－26】：CMM2级之软件配置管理
产品从需求分析开始到最后提交产品要经历多个阶段，每个阶段的工作产品又会产生出不同的版本，如何在整个生存期内建立和维护产品的完整性是配置管理的目的。配置管理关键过程域的基本工作内容是：标识配置项、建立产品基线库、系统地控制对配置项的更改、产品配置状态报告和审核。同软件质量保证活动一样，配置管理活动必须制定计划，而不是随意的行为。相关的组织和个人要了解配置管理的活动及其结果，并且要认同在配置管理活动中所承担的责任。
第68贴【2004－7－27】：软件过程和项目的度量
测度对于任何工程学科而言都是基本的，软件工程也不例外。在过去十年中，软件工程界终于开始认可测度对于软件开发过程的重要性，但付出的代价也是昂贵的。
软件度量是指计算机软件中范围广泛的测度。测度可以应用于软件过程中，目的是在一个连续的基础上改进它。测度也可以用于整个软件项目中，辅助估算、质量控制、生产率评估及项目控制。最后，软件工程师使用测度帮助评估技术工作产品的质量，且在项目进行中辅助决策。
在软件项目管理中，我们主要关心生产率和质量的度量--根据投入的工作量和时间对软件开发“输出”的测度，对产生的工作产品的“适用性”的测度。为了达到计划及估算的目的，我们的主要兴趣是放在历史数据上：在过去的项目中软件开发生产率是怎样的呢？产生的软件的质量是怎样的？如何从过去的生产率及质量数据推断出现在的状况？过去的信息如何帮助我们更加准确地计划和估算呢？
第69贴【2004－7－28】：软件度量规则
软件过程度量对于一个组织提高其总体的过程成熟度能够提供很大的帮助。不过，就像其他所有度量一样，它们也可能被误用，产生比它们解决的问题更多的问题。基于此，需要建立软件度量规则，该规则可以用于管理者建立过程度量计划：
1、解释度量数据时使用通用的观念，并考虑组织的感受性
2、对收集测量和度量的个人及小组提供定期的反馈
3、不要使用度量去评价个人
4、与开发者和小组一起设定清晰的目标及达到这些目标的度量
5、不要用度量去威胁个人或组织
6、提出某个问题的度量数据不应该被看成是“否定的”含义，这些数据仅仅是过程改进的指标
7、不要被某个与其他重要度量不符合的度量迷惑
第70贴【2004－7－29】：软件故障分析
通过软件故障分析方法可以收集软件开发及使用中所遇到的错误及缺陷的信息。故障分析采用如下方式：
1.根据来源分类所有的错误和缺陷（如规格说明中的错误，逻辑错误，与标准不符合的错误等）
2.记录修改每个错误和缺陷的成本
3.统计每一类错误和缺陷的数目，并按降序排列
4.计算每一类错误和缺陷的总成本
5.分析结果数据，找出造成组织最高成本的错误和缺陷类型
6.产生修正过程的计划，目的是消除（或降低其出现的频率）成本最高的错误和缺陷类型
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
