1.1软件
1.软件的发展
软件的发展经历了如下几个阶段：
第一阶段从20世纪50年代初期至60年代中期，这一阶段又称为程序设计阶段。此时硬件已经通用化，而软件的生产却是个体化。软件产品为专用软件，规模较小，功能单一，开发者即为使用者，软件只有程序，无文档。软件设计在人们的头脑中完成，形成了“软件等于程序”的错误观念。
第二阶段从20世纪60年代中期至70年代末期，称为程序系统阶段。此时多道程序设计技术、多用户系统、人机交互技术、实时系统和第一代数据库管理系统的出现，催生了专门从事软件开发的“软件作坊”，软件广泛应用，但软件技术和管理水平相对落后，导致“软件危机”出现。软件危机主要表现在以下几个方面：
(1) 软件项目无法按期完成，超出经费预算，软件质量难以控制；
(2) 开发人员和开发过程之间管理不规范，约定不严密，文档书写不完整，使得软件维护费用高，某些系统甚至无法进行修改；
(3) 缺乏严密、有效的质量检测手段，交付给用户的软件质量差，在运行中出现许多问题，甚至产生严重的后果；
(4) 系统更新换代难度大。
第三阶段从20世纪70年代末期至80年代中期称为软件工程阶段。微处理器的出现及分布式系统的广泛应用，使得计算机真正成为大众化的东西。以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。1968年，北大西洋公约组织的计算机科学家在联邦德国召开国际会议，会议讨论了软件危机问题，正式提出并使用“软件工程”概念。这标志着软件工程的诞生。
第四阶段从20世纪80年代中期至今，客户端/服务器(C/S)体系结构，特别是Web技术和网络分布式对象技术的飞速发展，导致软件系统体系结构向更加灵活的多层分布式结构演变，CORBA、EJB、COM/DCOM等三大分布式的对象模型技术相继出现。
2006年提出的面向服务架构(Service-Oriented Architecture，简称SOA)作为下一代软件架构，是一种“抽象、松散耦合和粗粒度”的软件架构，根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用，主要用于解决传统对象模型中无法解决的异构和耦合问题。
2.软件的生命周期
软件生命周期具有如下六个阶段：
(1) 问题的定义及规划。此阶段由软件开发方与需求方共同讨论，确定软件的开发目标及其可行性。
(2) 需求分析。在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段作为一个很重要的阶段，在整个软件开发过程中是不断变化和深入的，因此必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
(3) 软件设计。此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计、数据库设计等。软件设计一般分为总体设计和详细设计。
(4) 程序编码。此阶段是将软件设计的结果转换成计算机可运行的程序代码。程序编码必须符合标准的编写规范，以保证程序的可读性、易维护性，提高程序的运行效率。
(5) 软件测试。在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分为单元测试、组装测试以及系统测试等阶段。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
(6) 运行维护。软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件有可能不适应用户的要求，要延续软件的使用寿命，此时就必须对软件进行维护。
1.2软件过程
一、RUP（Rational Unified Process），统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。
1. RUP特点：
1）.迭代模型
RUP强调软件开发是一个迭代模型(Iterative Model)，它定义了四个阶段(Phase)：初始(Inception)、细化(Elaboration)、构造(Construction)、交付(Transition)。其中每个阶段都有可能经历以上所提到的从商务需求分析开始的各个步骤，只是每个步骤的高峰期会发生在相应的阶段，例如开发实现的高峰期是发生在构造阶段。实际上这样的一个开发方法论是一个二维模型，这种迭代模型的实现在很大程度上提供了及早发现隐患和错误的机会，因此被现代大型信息技术项目所采用。
2）、用例驱动
RUP的另一大特征是用例驱动。用例是RUP方法论中一个非常重要的概念。简单地说，一个用例就是系统的一个功能。在系统分析和系统设计中，用例被用来将一个复杂的庞大系统分割、定义成一个个小的单元，这个小的单元就是用例。然后以每个小的单元为对象进行开发。按照RUP过程模型的描述，用例贯穿整个软件开发的生命周期。在需求分析中，客户或用户对用例进行描述，在系统分布和系统设计过程中，设计师对用例进行分析，在开发实现过程中，开发编程人员对用例进行实现，在测试过程中，测试人员对用例进行检验。
3）、以架构为中心
RUP的第三大特征是它强调软件开发是以构架为中心的。构架设计(ArchitecturalDesign)是系统设计的一个重要组成部分。在构架设计过程中，设计师(Architect)必须完成对技术和运行平台的选取，整个项目的基础框架( Framework)的设计，完成对公共组件的设计，如审计( Auditing)系统、日志(Iog)系统、错误处理(Exception Handling)系统、安全(Security)系统等。设计师必须对系统的可扩展性( Extensibility)、安全性(Security)、可维护性( Maintainability)、可延拓性(Scalability)、可重用性(Reusability)和运行速度(Performance)提出可行的解决方案。
2．RUP各个阶段
RUP中的软件生命周期在时间上被分解为4个顺序的阶段，分别是初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束于一个主要的里程碑；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足，如果评估结果满意，则允许项目进入下一个阶段。其中每个阶段又可以进一步分解迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，作为最终产品的一个子集，产品增量式地发展，从一个迭代过程到另一个迭代过程，直到成为最终的系统。
如图1.1所示，RUP可用二维坐标来描述。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期、阶段、迭代和里程碑；纵轴以内容来组织，体现开发过程的静态结构，用来描述它的术语主要包括活动、产物、工作者和工作流。
1) 初始阶段
初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目标必须识别所有与系统交互的外部实体，并在较高层次上定义交互的特性。这包括识别出所有用例并描述几个重要的用例。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在已有系统基础上的开发项目来讲，初始阶段可能很短。
在初始阶段应该取得如下成果：
(1) 蓝图文档，即关于项目的核心需求、关键特性、主约束的总体蓝图。
(2) 初始的用例模型(约占总体的10%～20%)。
(3) 初始的项目术语表。
(4) 初始的商业案例，包括商业环境、验收标准等。
(5) 初始的风险评估。
(6) 项目计划。
(7) 一个或多个原型。
2) 细化阶段
细化阶段的目标是分析问题领域，建立坚实的体系结构基础，制定项目计划，消除项目中风险最高的因素。为了达到该目标，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境，包括创建开发案例，创建模板、工作准则并准备工具。
细化阶段的成果包括：
(1) 用例模型。所有的用例和参与者都已被识别出，并完成大部分的用例描述。
(2) 补充非功能性要求以及与特定用例没有关联的需求。
(3) 软件体系结构的描述。
(4) 可执行的软件原型。
(5) 修订过的风险清单和商业案例。
(6) 整个项目的开发计划，该开发计划应体现迭代过程和每次迭代的评价标准。
(7) 更新的开发案例。
(8) 初步的用户手册。
3) 构建阶段
在构建阶段，组件和应用程序的其余功能被开发并集成为产品，所有的功能都被彻底地测试。从某种意义上说，构建阶段是一个制造过程，其重点为管理资源及控制运作，从而降低成本、加速进度和优化质量。
构建阶段的成果是可以交付给最终用户的产品，它至少包括：
(1) 集成于适当操作系统平台上的软件产品。
(2) 用户手册。
(3) 当前版本的描述。
4) 交付阶段
交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在这一阶段，用户反馈应主要集中在产品调整、设置、安装和可用性问题。
3. RUP核心工作流
1) 商业建模
商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程、角色和责任。
2) 需求
需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化，最重要的是理解系统所解决问题的定义和范围。
3) 分析设计
分析设计工作流是将需求转化成系统的设计，为系统开发一个健壮的结构，使其与实现环境相匹配。设计活动以体系结构设计为中心，其结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包和设计子系统，而描述则体现了类的对象如何协同工作实现用例的功能。
4) 实施
实施工作流的目的包括以层次化的子系统形式定义代码的组织结构，以组件的形式(源文件、二进制文件、可执行文件)实现类和对象，将开发出的组件作为单元进行测试，集成单元使其成为可执行的系统。
5) 测试
测试可通过可靠性、功能性和系统性的三维模型来进行。测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。RUP提出的迭代方法是在整个项目中进行测试的，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。
6) 部署
部署工作流的目的是成功地生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，它包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和生成beta测试版、移植现有的软件和数据以及正式验收。
7) 配置和变更管理
配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的软件产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发，如何自动化创建工程，同时也阐述了对产品修改的原因、时间、人员进行记录，依靠程序员主动、开放、高效的面对面交流来达成对需求、目标、设计实现的理解。
8) 项目管理
软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
9) 环境
环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
3. 用例驱动为核心
开发软件系统的目的是要为该软件系统的用户服务。因此，要创建一个成功的软件系统，必须明白此软件的用户需要什么。“用户”这个术语所指并不仅仅局限于人，还包括其它软件系统。一个用例就是系统向用户提供一个有价值的结果的某项功能。用例是软件的功能性需求。所有用例结合起来就构成了“用例模型”，该模型描述系统的全部功能。用例模型取代了系统的传统的功能规范说明。功能规范说明描述为 “需要该系统做什么？”，而用例驱动则是“需要该系统为每个用户做什么？”因此，用例模型是从用户的利益角度出发进行考虑，设计人员创建一系列用例模型，开发人员审查每个后续模型，以确保它们符合用例模型。测试人员将测试软件系统的实现，以确保实现模型中的组件正确实现了用例。这样，用例不仅启动了开发过程，而且与开发过程结合在一起。
二、敏捷过程
传统计划驱动的开发方法往往不能获得良好的效果，并且由于过分强调过程控制，因此在开发过程中产生大量的文档，给开发人员带来很多额外的工作量，因此被称为重量级方法。这种方法使程序员花费大量的开发时间在开发文档的撰写和维护上，而真正花在代码上的时间较少，并且由于依赖过程控制，而不是程序员自我管理，导致开发过程管理复杂且低效，极大地阻碍了软件开发效率。
1. 敏捷开发简介
2001年是全球软件行业具有历史意义的一年，就在这一年，“敏捷联盟”成立了，并发表了对传统软件开发过程具有颠覆意义的《敏捷宣言》:“通过开发软件和帮助别人开发软件，我们找到了一些更好的开发软件的方式。通过这一工作，我们得出了这些价值：
● 个体和交互 胜过 过程和工具；
● 可以工作的软件 胜过 面面俱到的文档；
● 客户合作 胜过 合同谈判；
● 响应变化 胜过 遵循计划。
2. 敏捷开发的特征
敏捷方法具有如下两个主要特征：
(1) 开发采用适应性方法，经过多次小型迭代开发过程逐步逼近实际需求，从而为客户提供实际需要的软件。
(2) 以人为本。传统计划驱动方法企图以文档、过程为核心，从而抹杀人的重要性。
3. 敏捷开发的价值与局限
敏捷方法抛弃了繁琐的文档管理，依靠程序员主动、开放、频繁的面对面的高效交流来达成对需求、目标、设计实现的理解。敏捷方法抛弃了机械、严格的过程控制，依赖程序员和开发团队的高标准自我要求：严格的自律，团队合作精神，个人高度自觉的主动性，责任感。
敏捷方法的高效和高质量实际上是以程序员的高素质和开发团队的高度合作的开发文化为基础的。因此敏捷方法的实施前提是必须找到愿意并有能力实施敏捷方法的团队。XP的创始人Beck也曾建议有些情况是不适合采用XP方法的。
1.3软件质量
一.概述
软件质量具有多种定义。
ANSI/IEEE Std 729—1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。
CMM对质量的定义是：
① 一个系统、组件或过程符合特定需求的程度；
② 一个系统、组件或过程符合客户或用户的要求或期望的程度。
M.J.Fisher定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。
因此，软件质量是一个复杂的多层面概念。
软件质量框架是由“质量特性—质量子特性—度量因子”构成的3层结构模型，如图1.2所示。
二、CMM/CMMI
1. CMM
CMM是卡耐基—梅隆大学软件工程研究院受美国国防部委托制定的软件过程改良和评估模型，也称为SEI SW-CMM。该模型于1991年发布，其核心是把软件开发视为一个过程，进行过程的监控和研究。CMM提供了一个软件过程改进的框架，这个框架与软件生命周期无关，与所采用的开发方法无关。
CMM为软件企业的过程能力提供了一个阶梯式的进化框架，该框架共有5级，分别是初始级、可重复级、已定义级、已管理级和优化级。第一级实际上是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过这个起点向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一个级别迈进，如表1.1所示。
1) 初始级
在这个阶段，软件开发过程表现得非常随意，偶尔会出现混乱的现象，只有很少的工作过程是经过严格定义的，开发成功往往依靠的是某个人的智慧和努力。此时的软件机构基本没有健全的软件工程管理制度，其软件过程完全取决于项目组的人员配备，具有不可预测性。人员变了过程也随之改变。如果一个项目碰巧由一个杰出的管理者和一支有经验、有能力的开发队伍承担，则这个项目可能是成功的。但是，更常见的情况是，由于缺乏健全的管理和周密的计划，延期交付和费用超支的情况经常发生，结果大多数行动只是应付危机，而不是完成事先计划好的任务。
2) 可重复级
这一阶段已经建立了基本的项目管理过程，只需按部就班地设计功能、跟踪费用，根据项目进度表进行开发。对于相似的项目，可以重用以前已经开发成功的部分。处于2级成熟度的软件机构，针对所承担的软件项目已建立了基本的软件管理控制制度。通过对以前项目的观察和分析，可以提出针对现行项目的约束条件。项目负责人跟踪软件产品开发的成本和进度以及产品的功能和质量，并且识别出为满足约束条件所应解决的问题。此时，软件的需求是条理化，而且其完整性是受控制的。软件机构已经制定了项目标准，并且能确保严格执行这些标准。项目组与客户及承包商已经建立起一个稳定的、可管理的工作环境。
3) 已定义级
在这一阶段，软件开发的工程活动和管理活动都是文档化、标准化的，是被集成为一个有组织的标准开发过程。所有项目的开发和维护都在这个标准基础上进行定制。处于3级成熟度的软件机构，有一个固定的过程小组从事软件过程工程活动。过程小组可以利用过程模型进行过程例化活动，从而获得一个针对某个特定的软件项目的过程实例，并投入过程运作而开展有效的软件项目工程实践。同时，过程小组还可以推进软件机构的过程改进活动。在该软件机构内实施了培训计划，能够保证全体项目负责人和项目开发人员具有完全承担任务所要求的知识和技能。
4) 已管理级
这一阶段已经对软件开发过程和产品质量的测试细节有了很好的归纳，产品和开发过程都可以定量地分解和控制。
处于4级成熟度的软件机构的过程能力可以概况为：软件过程是可度量的，软件过程在可度量的范围内运行。这一级的过程能力允许软件机构在定量的范围内预测过程和产品质量趋势，在发生偏离时可以及时采取措施予以纠正，并且可以预期软件产品是高质量的。
5) 优化级
这一阶段通过建立开发过程的定量反馈机制，不断产生新的思想，采用新的技术来优化开发过程。处于5级成熟度的软件机构，可以通过对过程实例性能的分析和确定产生某一缺陷的原因，来防止再次出现这种类型的缺陷。通过对任何一个过程实例的分析所获得的经验教训都可以成为该软件机构优化其过程模型的有效依据，从而使其它项目的过程实例得到优化。这样的软件机构可以通过从过程实施中获得的定量的反馈信息，在采用新思想和新技术的同时测试它们，从而不断地改进和优化软件过程。
处于5级成熟度的软件机构的过程能力可以概况为：软件过程是可优化的。这一级的软件机构能够持续不断地改进其过程能力，既对现行的过程实例不断地改进和优化，又借助于所采用的新技术和新方法来实现未来的过程改进。
2. CMMI
CMMI是SEI于2000年发布的CMM的新版本。CMMI (Capability Maturity Model Integration，能力成熟度模型集成)将各种能力成熟度模型，包括Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM等，整合到同一架构中去，由此建立包括软件工程、系统工程和软件采购等在内的模型集成，以解决除软件开发以外的软件系统工程和软件采购工作中的需求。
三、质量与测试
软件测试和软件质量是分不开的。测试是手段，质量是目的。软件测试作为一种辅助而且必需的手段，客观反映某个时间段内的软件质量。测试人员执行软件测试，发现软件BUG，反馈给开发人员进行修改，然后经过再次测试，以确认该BUG已被解决。测试人员重复此过程直至软件符合最终用户需求。在BU*生之前，BUG的具体数量、位置、出现时间等都是未知数，测试人员根本就不知道。
测试可以发现BUG，但不能避免BUG的产生。QA团队对项目进行近似完全的控制，通过建立标准和方法论，有条理地仔细监视和评价软件开发过程，对发现的软件缺陷提出解决建议，执行某些测试，从而从源头上防止BUG的出现。
实现软件质量保证主要有两种途径：一种是通过贯彻软件工程各种有效的技术方法和措施使得尽量在软件开发期间减少错误；另一种是通过分析和测试软件来发现和纠正错误。
软件测试属于软件控制，作为软件质量的重要保证，其和质量保证有如下4点区别，如表1.2所示。
通过实施CMM/CMMI，有助于改进软件产品的质量，改进项目满足预定目标能力，减少开发成本和周期，降低项目风险，提高组织过程能力，提高市场占有率。实施不同等级的CMM/CMMI，对于按照每功能点来计算的软件缺陷率的降低具有显著的作用，如表1.3所示。
CMM/CMMI基于过程的软件质量管理主要包括质量保证和质量控制两大方面。软件质量保证是由(相对)独立的质量管理人员在项目的整个开发周期中对项目所执行的过程和产生的工作产品进行监督和检查，确保其符合预定的要求。软件质量保证的目的是确保过程得到有效的执行及推进过程改进，并就项目过程的执行情况和所构造的产品向管理者提供适当的可视性。软件质量控制是指为评价和验证已开发的产品而执行的活动和技术，包括验证产品是否满足质量要素的要求，以及产品(包括生命周期的工作产品)是否具有接受的质量。
软件质量控制所采取的主要技术是软件测试。通过软件测试，来验证产品是否符合技术文档预期的特性、功能和性能等要求，并识别产品的缺陷。
虽然目前在CMM/CMMI中没有明确软件测试作为一个独立的过程域，但是在CMM/CMMI很多地方都涉及了软件测试内容。CMMI和软件测试最主要的区别在于：CMMI是对于软件过程的改进(包括软件测试过程)；而软件测试是针对项目结果的验证，在测试时是从侧面改进软件质量的。例如，在CMMI的“确认”和“验证”两个过程域中，CMMI列出了以下实践。
1.4测试和开发的关系
1．测试与开发各阶段的关系
图1.3给出了软件测试与软件开发各阶段的关系，软件测试在开发阶段具有如下作用。
(1) 项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。
(2) 需求分析阶段：确定测试需求分析、系统测试计划的制定，评审后成为管理项目。
(3) 详细设计和概要设计阶段：确保集成测试计划和单元测试计划完成。
(4) 编码阶段：由开发人员完成自己负责部分的测试代码。当编写工作项目较大时，由专人进行编码阶段的测试任务。
(5) 测试阶段(单元、集成、系统测试)：依据测试代码进行测试，并提交相应的测试状态报告和测试结束报告。
2．测试与开发的并行性
图1.4给出了软件测试与软件开发之间的并行关系。
3．完整的软件开发流程
从图1.5中可以看出，测试过程和开发过程贯穿软件过程的整个生命周期，二者相辅相成，相互依赖，具体概括为如下3个关键点：
(1) 测试过程和开发过程是同时开始、同时结束的，两者保持同步的关系。
(2) 测试过程是对开发过程中阶段性成果和最终产品进行验证的过程，所以两者相互依赖。前期，测试过程更多地依赖于开发过程；而后期，开发过程更多地依赖于测试过程。
(3) 测试工作的重点和开发工作的重点可能是不一样的，两者有各自的特点。
1.2软件测试的基本概念
1.软件测试的定义：
IEEE给出的测试定义：
在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价。（测评是评错）
分析某个软件项以发现和现存的和要求的条件之差别(即错误)并评价此软件项的特性。（测试是做度量）
2.软件测试的特征：
可以从需求开始，而不仅仅是代码
既是静态活动也是动态活动
用来预防失效
有助于在软件生命周期中尽早发现问题，以降低修复缺陷所需的成本
过程中应创建可重用的测试件
3.软件测试的目的：
Glenford J. Myers提出:
测试是程序的执行过程，目的在于发现错误。
测试是为了证明程序有错,而不是证明程序无错误。
个好的测试用例在于能发现至今未发现的错误。
个成功的测试是发现了至今未发现的错误的测试
Bill Hetzelt在《软件测试完全指南》中指出:
软件测试的目的不仅仅是为了发现软件缺陷与错误，同时
也对软件进行度量和评估，提高软件质量。
现对软件测试目的总结为以下三点：
①以最少的人力、物力、时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避潜在的软件错误和缺陷给软件造成的商业风险。
②通过分析测试过程中发现的问题可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进;同时通过对测试结果的分析整理,可修正软件开发则，并为软件可靠性分析提供相关的依据。
③评价程序或系统的属性,对软件质量进行度量和评估,以验证软件的质量满足用户的需求,为用户选择、接受软件提供有力的依据。
| |
\.| |/
.\/
软件测试的目的是工程性的,是以发现错误为目的
4.软件测试的关键问题（原则）
软件测试是证伪而非证真
尽早地和不断地进行软件测试
重视无效数据和非预期使用习惯的测试
程序员应该避免检查自己的程序
充分注意测试中的群集现象（二八原则）
用例要定期评审
应当每一个测试结果做全面检查
测试现场保护和资料归档
软件测试的经济型原则
5.软件质量保证
软件质量保证是贯穿软件项目整个生命周期的有计划和有系统的活动，经常针对整个项目质量计划执行情况进行评估，检查和改进，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一 致。
确保软件项目的过程遵循了对应的标准及规范要求且产生了合适的文档和精确反映项目情况的报告，其目的是通过评价项目质量建立项目达到质量要求的信心。软件质量保证活动主要包括评审项目过程、审计软件产品，就软件项目是否真正遵循已经制定的计划、标准和规程等，给管理者提供可视性项目和产品可视化的管理报告。
软件测试与软件质量：软件测试是获取度量值的一种重要手段。
1.5软件测试的分类
1.单元测试
单元测试又称模块测试，针对软件设计中的最小单位一程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
单元定义: C中指一个函数，Java中 指一个类，在图形化的软件中,
单元测试的六个问题？
①什么时候进行单元测试：编码后，编译通过后进行。
②由谁来做单元测试：白盒测试工程师或者开发工程师，最好不要白己做白己代码的测试
③单元测斌的依据：源程序(代码+注释) +《详细设计文档》
④单元测试的通过标准：程序通过所有单元测试用例、语句的覆盖率达到100%、分支的覆盖率达到85%
⑤国内单元测斌的现状：简单+没有单元测试计划、单元测试用例和代码覆盖率的统计。
⑥如何进行单元测试：单元格测试主要用白盒测试，先静态地检查代码是否符合规
范，然后动态运行代码，检查其实际运行结果，检查程序的运行结果是否正确是一个最基本的要求，还要关注容错处理，程序的边界值处理等
2.集成测试
集成测试又叫组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。
1.什么时候进行集成测试?
单元测试&集成测试同步进行，理论上先有单元测试。
2.由谁来做集成测试?
白金测试工程师或者开发工程师
3.集成测试的依据?
单元测试的模块+《概要设计》文档。
3.系统测试
指的是将整个软件系统看为一一个整体进行测试，包括对功能、性能、
以及软件所运行的软硬件环境进行测试。
目前系统测试主要由黑盒测试工程师在系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。
4.验收测试
验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。在系统测试的后期，以用户测试为主或有测试人员等质量保证人员共同参与的测试。
-
a测试:指的是指的是由用户，测试人员、开发人员等共同参与的内部测试。
-
β测试:指的是内测后的公测，印完全交给最终用户测试
-
正式的验收测试
验收测试的重要性：验收签字，收钱
5.静态测试(static testing)
静态测试是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误过程。
-
代码测试: 主要测试代码是否符合相应的标准和规范。
-
界面测试:主要测试软件的实际界面与需求中的说明是否相
符
-
文档测试:主要测试用户手册和需求说明是否真正符合用户
的实际需求。
-
工具， (Logiscope) Telelogic,可以用作Java/C++等规范
6.动态测试
动态测试(dynamic testing)、 是指实际运行被测程序，输入相应的测试数据，
检查实际输出结果和预期结果是否相符的过程。
-
动态测试方法为结构和正确性测试
-
动态测试工具Robot、 QTP等
7.黑盒测试
指的是把被测的软件看做一个黑金子，我们不关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出数据。
7.1功能测试：是黑盒测试的一方面。它检查软件的功能是否符合客户要求。
-
逻辑功能测试( logic function testing )
-
界面测试(UI testing)
-
易用性测试(usability testing)
-
安装测试(instal lation testing)
-
兼容性测试(compatibility testing)
7.2性能测试(performance testing) :是软件测试的高端领域，性能测试工程师的待遇和白盒测试工程师不相上下，通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师。
-
时间性能(事务响应时间等)
-
空间性能(系统資源消耗)
-
一般性能测试
-
可靠性测试
-
负载测试
-
压力测试
8.白盒测试
指的是把盒子打来，去研究里面的源代码和程序结构。
在软件公司中，往往采用黑盒测试&白盒测试相结合的方式。
-
软件的整体功能和性能进行黑盒测试
-
软件的源代码采用白盒测试
9.回归测试(regression testing)
是指软件被修改后重新进行的测试，如重复执行上一个版本测试时的用例，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。
10.冒烟测试(smoke testing)
是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。
11.随机测试(random testing)
是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
1.4软件缺陷管理
1.目标：确保每个被发现的缺陷都能够被有效的解决。(注意:这里的解决不一定是被修复，也可以是其它的处理方式，如在下一版本修正或者不修正，但是每个bug的处理方式必须能在开发组织中达成一致。)
2.定义：
-
软件未达到产品说明书中标明的功能。
-
软件出现了产品说明书中指明的不会出现的功能。
-
软件功能超出了产品说明书中指明的范围。
-
软件未达到产品说明书中指明应达到的目标。
-
软件测试人员认为软件难以理解和使用、运行速度慢，或最终用户认为不好。
3.软件缺陷属性：
发现缺陷后，需要提交缺陷单，通常情况下，，缺陷单需而要包含以下的内容:
|
ID
|
描述信息(Description)
|
|
标题(Title)
|
重现步骤(Reproduce)
|
|
测试环境(Environment)
|
附件(Attachment)
|
|
严重等级(Severity)
|
测试人员(Created by)
|
|
优先级(Priority)
|
处理人员(Assign to)
|
|
类别(Category)
|
.......
|
|
状态(Status)
|
|
4.软件缺陷的严重程度：
描述因缺陷引起的故障对软件产品影响的程度。通常划分为以下几个级别:
按照CMM5中定义的规范，软件缺陷分为多个等级，分别为致命、严重、一般和提示。
(1) 致命。致命性漏洞主要为：内存泄漏、用户数据丢失或被破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误和造成系统不稳定等情况。
(2) 严重。严重性漏洞主要为：功能未实现、功能严重错误、系统刷新错误、语音或数据通信错误、轻微的数值计算错误、系统所提供的功能或服务受明显的影响但不会影响到系统稳定性。
(3) 一般。一般性漏洞主要为：操作界面错误(包括数据窗口内列名定义、含义是否一致)、边界条件下错误、提示信息错误(包括未给出信息、信息提示错误等)、长时间操作无进度提示、系统未优化(性能问题)、光标跳转设置不好、鼠标(光标)定位错误等。
(4) 提示。提示性漏洞主要为：界面格式等不规范、辅助说明描述不清楚、操作时未给出用户提示、可输入区域和只读区域没有明显的区分标志、个别不影响产品理解的错别字、文字排列不整齐等一些小问题及建议。
三种纠错技术
纠错先要查错。查错的工作量通常占整个纠错的90%以上。下面介绍几种常用的查明程序错误时可能采用的工具和手段，这些方法能明显提高查错的效率。
1) 插入打印语句
在程序中插入暂时性的打印语句，是一种十分常见的查错技术。这类打印语句的作用主要是显示程序的中间结果或有关变量的内容。插入打印语句适用于任何高级语言编写的程序。
2) 设置断点
查错的基本技术之一，就是在程序的可疑区设置断点。每当程序执行到设置的断点时，就会暂停执行，以便纠错者观察变量内容和分析程序的运行状况。
3) 掩蔽部分程序
对可疑程序进行检查时，常常要让程序反复执行。如果整个程序较长，可疑区仅占其中的一小部分，则每次运行整个程序必将浪费许多时间和精力。在这种情况下，往往将不需要检查的程序掩蔽起来，只让可疑的部分程序反复运行。
掩蔽无关程序可使用下述方法：
(1) 在要掩蔽的语句行加上注释符。
(2) 把要掩蔽的程序段置入“常假”的选择结构中，使其无法执行。
5.软件缺陷优先级：
描述缺陷必须被修复的紧急程度。通常划分为以下几个级别:
6.软件缺陷的类别
类别描述缺陷所属的类型，以便查找对应开发人员，以及后期缺陷分析。类别通常可以分为以下几种情况:
7.软件缺陷状态
状态用于跟踪缺陷处理过程及当前所处阶段，常用状态有以下情况:
根据项目具体特征和管理需求，可以适当增加或者精简缺陷状态。
8.软件缺陷生命周期（重点）
-
一般的，测试人员识别缺陷，其初始状态是“新建”;
-
项目经理或技术领导分析缺陷，分配给合适的开发人员来解决，状态流转为“待解决”;
-
指定的工程师解决缺陷，将其状态跟踪到“已解决”;
-
测试人员回归该缺陷，如果回归通过，则关闭缺陷，如果回归不通过，则重新打开该缺陷( "Reopen"状态)。
9.常见的软件缺陷管理
10.缺陷管理常见的问题
-
缺陷无法重现怎么办?
-
缺陷太多怎么办?
-
找不到缺陷怎么办?
-
如何减少无效缺陷的提交?
-
如何防止重复缺陷重复提交?
-
测试和开发如何客观有效的进行缺陷沟通?
1.6软件质量与软件测试相关特性
1.软件质量特性：软件质量度量方法有多种，可以进一步分为静态质量特性和动态质量特性。
-
静态质量特性：静态质量特性包括结构化的、可维护的、可测试的代码以及正确而又完整的文档。
-
动态质量特性：软件动态质量特性包括正确性、可靠性、完整性、一致性、易用性、性能等。
-
动态质量特性—正确性
-
软件正确性:如果软件针对其输入域中的每个元素都能得到预期的结果,则称该软件是正确的。
-
输入域:对软件P的所有可能输入的集合被称作P的输入域，或者输入空间。
-
正确性是想说明软件是无错的，这是我们所追求的一个良好的愿望，但并不是软件测试的目标。
-
-
动态质量特性-可靠性
-
定义一:软件可靠性是指软件在给定时间间隔和给定条件下无故障运行的概率。 ( ANSI/IEEE729- 1983)
-
这里的概率依赖于程序输入的分布情况，这种输入分布经常被称作操作剖面( operational profile) ，是对软件使用方式的数值描述。
-
根据该定义，软件的可靠性会因操作剖面的不同而不同，这就意味着某些用户可能觉得“这个软件很糟糕”，而也有某些用户可能会觉得“软件很好用”。
-
-
定义二:可靠性是指软件在预期环境下无故障运行的概率，
-
这里的环境是指软件运行所需的硬件及软件要素，包括硬件设备、操作系统以及其它必需的应用程序。
-
这个定义与“谁使用这个软件以及如何使用软件”无关，而只与软件功能正确性相关。由于没有操作剖面的定义，整个输入域被认为是均匀分布的
-
-
对比
-
定义一需要了解用户操作剖面，如果能够准确建立某类用户的操作剖面，那么就能够准确计算出软件针对该类用户的可靠性。但是，用户操作剖面本身是很难准确评估的。
-
定义二只需要用单个数值来表示软件可靠性，非常具有吸引力，但是这个数值要适用于所有的用户，这本身是不现实的。
-
-
-
动态质量特性-易用性
-
定义：是指软件使用的难易程度。其本身是一个研究领域，有大量技术可用于易用性测试，心理学在易用性测试设计中也扮演着重要的角色。
-
-
完整性
-
定义：指得到软件需求规格说明书或者用户手册中所有功能的可能性
-
-
一致性
-
定义：指软件对常规惯例和假设的遵循程度。例如，用户界面中所有按钮遵从统一的颜色编码规定。
-
-
性能
-
定义：可以简单理解为软件完成规定任务所花费的时间。例如，--个编译系统的性能需求可能会用编译一组数值计算程序所需的最少平均时间来描述。
-
-
2.软件测试的复杂性
举例:测试三角形程序
输入3个整数a、b和c， 作为三角形的3条边，通过程序判断由这3条边构成的三角形类型是等边三角形、等腰三角形还是一般三角形，并打印出相应的信息。
需要测试用例:
(1) 3数相等 (9)含有零数据
(2) 3数中有2个数相等，比如AB相等 (10)含有负整数
(3) 3数中有2个数相等，比如BC相等 (11)少于3个整数
(4)3数中有2个数相等，比如AC相等 (12)含有非整数
(5) 3数均不相等 (13)含有非数字符
(6) 2数之和不大于第3数，比如最大数是A (14)2数之和等于第3数
(7)2数之和不大于第3数，比如最大数是B (15)输入3个零
(8)2数之和不大于第3数，比如最大数是C (16)输入3个负数
黑盒测试的复杂性：
①测试所需要的输入量太大
②测试的输出结果太多
③软件实现的途径太多
④软件规格说明没有一个客观标准
白盒测试的复杂性：
白盒测试方法将被测对象看做一一个打开的盒子，允许人们检查其的内部结构。测试人员根据程序内部的结构特性，设计和选择测试用例，检测程序的每条路径是否都按照预定的要求正确地执行。
那么从A点走到B点的所有路径数至少有5^20+5^19+...+5^1,这是一个天文数字。
穷举路径测试看起来它同穷举输入测试一样是不现实的。即使程序中每条路径都测试过了，仍不能保证程序没有故障。
-
穷举路径测试不能保证程序实现符合规格说明的要求。例如，如果要求编写升序排序程序，结果程序被错误地编写成按降序程序。这时，穷举路径测试是毫无用处的。
-
穷举路径测试不可能查出程序中因遗漏路径而出现的错误。
-
穷举路径测试可能发现不了有关数据的故障。
3.软件测试的经济性
E.W .Dijkstra的一句名言对测试的不彻底性作了很好的注释:“软件测试只能证明故障的存在，但不能证明故障不存在”
软件测试的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为
了降低测试成本，选择测试用例时应注意遵守测试的“经济性”原则:
第一，根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级;
第二，认真研究测试策略，以便能开发出尽可能少的测试用例，发现尽可能多的软件故障。
1.7软件测试充分性和和测试停止标注
1.软件测试的充分性
给定一个程序P,针对程序的需求R,我们设计了k个测试用例，形成测试用例集T，问:
T足够好吗?
T可以对程序P进行完全测试吗?
T是充分的吗?
等等。这些问题，都表达一个思想:人们总想完全测试程序P,以期望在测试结束进行交付的时候，P中所有的错误都被发现并修正了。
"充分性”就是用来度量一个给定的测试集T是否能验证软件P满足其需求R。充分性度量是相对于具体的测试充分性准则C的。当一个测试集T满足准则C时，即认为T相对于C是充分的。相反，如果T不能完全满足C，那么就认为用例集T对于C是不充分的。因此，确定程序P的测试集T是否满足充分性准则C，是依赖于准则自身的。
例1:
考虑编写程序sumProduct,其需求如下:
R1:从标准输入设备上输入两个正数x和y。
R2.1:当x<y时，求x与y之和，并在标准输出设备上输出x与y之和。
R2.2:如果x>=y,求x与y之积，并在标准输出设备上输出x与y之积。
假设测试充分性准则C1为:
如果针对需求R中的每一个需求r，测试集T中至少有一个测试用例测试证明了P满足r，则认为测试集T对于程序P的需求R是充分的。
给定测试集T={t: <x=2，y=3>}。显然，相对于准则C1来讲T是不充分的,因为T中的测试用例只测试了R1,和R2.1，没有测试R2.2。
覆盖域
测试集的充分性评估是由一个有限集来度量，根据所依赖的充分性准则，有限集中的元素由软件需求或者代码导出。对于每一个测试准则C，我们都可以得到一个有限集，称之为覆盖域Ce。如果覆盖域Ce仅依赖于被测软件的代码，则称准则C为一个白盒测试充分性准则;如语句覆盖、分支覆盖、路径覆盖等。如果覆盖域Ce仅依赖于被测软件的需求，则称准则C是一个黑盒测试充分性准则。其他的测试充分性准侧可能是白盒与黑盒之间。
测试覆盖率
给定测试集T,覆盖标准C，覆盖域Ce,假设Ce包含n个元素(n>=0),我们说T覆盖Ce,是指对于Ce中的每一个元素e,在T中都至少有一个测试用例测试了它。如果T覆盖了Ce中所有的元素，则称T相对于C是充分的;如果T只覆盖了Ce中的k(k<n)个元素，则称T相对于C是不充分的。分数k</n代表了T对C的充分度，也称为T对于C，P以及R的覆盖率
测试充分性准则C2
如果软件P中的每一条路径都被遍历至少一次，则认为测试集T针对(P,R)是充分的。对于例1中的需求，假设程序P有且只有两条路径，一条应对与条件x<y,一条对应与条件x>=y。这两条路径分别记作p1,p2。
针对准则C2,得到覆盖域Ce= {p1, p2}
使用准测C2来度量测试集T ={t: <x=2, y=3>}
对C2的覆盖率，对P执行T中的每一个测试用例，因为p1被执行了，因此T对于C2，P, R的覆盖率为1/2=0.5，T相对于测试准则C2是不充分的。
除了基于被测软件需求、控制流、数据流这样一些常规测试充分性评价准则外，还有其它一些测试充分性评价技术也得到广泛研究和应用，如符号执行、变异测试也是用于评价测试优良程度的有效技术，它为测试评价和测试增强提供了较为严格的准则。
2.软件测试终止准则
软件消亡之前，如果没有测试结束标准,那么软件测试就永无休止。软件测试终止条件需要依据项目具体情况来制定，般而言，其遵循以下终止准则:
1.基于测试阶段的原则
每个软件都经过单元测试、集成测试、系统测试这几个测试阶段，我们可以对单元测试、集成测试、系统测试制定各自具体的测试结束标准，当每个阶段的测试结束标准都符合时，我们认为该软件达到测试停止标准。
2.基于测试用例的原则
测试设计人员设计测试用例，并请项目组成员参与用例评审，一旦评审通过，就可以作为后面测试结束的一个参考标准。比如测试过程中如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在比如可以制定功能测试用例通过率100%，非功能性
测试用例通过率达到95%以上，即可允许正常测试结束。该准则的关键在于测试用例质量的把握。
3.基于缺陷收敛趋势及缺陷修复率原则
可以通过软件缺陷的趋势图的走向，来定测试是否可以结束;缺陷修复率也是常用的一个指标，如严重级别错误和主要级别错误要100%修复，较小缺陷修复率达850以上。
4.基于验收测试的原则
即项目通过验收测试，并得到验收测试通过结论，即可结束该项目的测试活动。
5.基于覆盖率的原则
如需求覆盖率达100%，测试用例执行覆盖率达100%，单 元测试中语句覆盖率不低于85%等这些准则在软件测试活动中都是比较常用的。
6.软件项目暂停或终止，则测试活动也应响应暂停或终止
如在开发生命周期内出现重大估算、进度偏差，需要暂停调整或者终止项目，那么测试活动也随之暂停或终止，并备份相应测试数据。
思 考 与 习 题
一、选择题
1．软件本身的特点和目前软件开发模式使隐藏在软件内部的质量缺陷不可能完全避免，在下列关于导致软件质量缺陷的原因的描述中，不正确的是 （ C ） 。
A. 软件需求模糊以及需求的变更，从根本上影响着软件产品的质量
B. 目前广为采用的手工开发方式难于避免出现差错
C. 程序员编码水平低下是导致软件缺陷的最主要原因
D. 软件测试技术具有缺陷
2．缺陷产生的原因是( D )。
A. 交流不充分及沟通不畅；软件需求的变更；软件开发工具的缺陷
B. 软件的复杂性；软件项目的时间压力
C. 程序开发人员的错误；软件项目文档的缺乏
D. 以上都是
二、判断题
1. 缺乏有力的方法学指导和有效的开发工具的支持，往往是产生软件危机的原因之一。( √ )
2. 目前的绝大多数软件都不适合于快速原型技术。( √ )
3. 在程序运行之前没法评估其质量。( × )
4.下列哪些活动是项目
探索火星生命迹象( √ )
向部门经理进行月工作汇报( × )
开发新版本的操作系统。( √ )
每天的卫生保洁。( × )
组织超级女声决赛。( √ )
一次集体婚礼。( √ )
三、简答题
1. 什么是软件？软件发展经过了哪几个阶段？
答:软件是一系列按照特定顺序组织的计算机数据和指令的集合。-般来，讲软件北划分为系统软件，应用软件和介于着两者之间的中间件。其中系统软件为计算机使用提供最基本的功能，但是并不是针对某一特定领域，而应用软件则恰好相反，不同的应用软件更根据用户和所服务的领域提供不同的功能。
20世纪50年代初期至60年代中期是软件发展的第一阶段(又称程序设计阶段);
第二阶段从20世纪60年代中期到70年代末期是程序系统阶段。
第三阶段称为软件工程阶段，从20世纪70年代中期到80年代中期，由于微处理器的出现，分布式系统广泛应用，以软件的产品化，系列化，工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计原则，方法和标准。
第四阶段是从20世纪80年代中期至今，客户端/度武器(C/S)体 系结构，特别是Web技术和网络分布式对象技术法飞速发展，导致软件体系结构向更加灵活的多层分布式结构演变，CORBA,EJB,COM/DCOM 等三大分布式的对象模型技术相继出现。
2. RUP是什么？具有什么特征？
答:RUP(Rational Unified Process)，统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。
1.迭代式开发——较之瀑布式开发，迭代开发更能规避风险，更好的获取用户需求。
2.管理需求——需求是动态变化的，对需求的管理应贯穿软件生命周期的所有环节。需求管理包括三个活动：获取、组织并记录需求；评估需求变化及其影响；跟踪、记录需求的变更相关的决策与权衡的理由。
3.应用基于构件的构架——软件系统很复杂，不同干系人（stakeholder，例如：用户、分析师、开发人员、集成人员、测试人员、项目经理等）对软件有不同的视角。建立并维护软件构件有利于管理不同的视角，从而在整个迭代周期内控制迭代的过程。 而基于构件的构架则由于其柔性的结构、对复用的支持被Rational认为是最佳的实践。
4.可视化的建模——复杂的软件通过UML这样的建模语言进行抽象和可视化不但能够简化沟通，而且也能简化开发人员对系统的理解。
5.持续不断的验证软件质量——缺陷越早被发现被解决就越节约成本，因此应该在整个软件生命周期内不断验证质量。
6.控制软件变更——多人、分布式的开发，如果不能控制版本和变更，开发必然陷入混乱，变更的控制是项目有序进行的必要条件。
RUP是可以剪裁的，他包含针对不同项目特征进行剪裁的指南。同时RUP也是不断演化的，Rational不断在发布RUP的新版本。
4. 软件质量框架是什么？包括什么内容？
答:第一部分是前提，说明了软件框架的适用范围，以及适合的环境，和方法学一样，没有泛之四海皆准的方法学,所以软件质量框架也需要一个上下文环境。
第二部分是价值观，价值观说明了软件质量框架中强调的价值，在软件框架的结构和实践中，都将充分的的表现出一开始我们定义的价值。
第三部分是结构。结构定义了软件质量框架的组成部分，以及软件质量框架和开发过程之间的关系。
第四部分是文章中着墨最多的部分，即优秀实践。优秀实践通过具体、实际的分析、举例，深入阐述了软件质量框架的价值观和结构。
5. CMM是什么？其具体内容是什么？CMMI与CMM的关系是什么？
答: CMM是由美国软件工程学会(Software Engineering Institute)制定的一套专门针对软件产品的质量管理和质量保证标准。该标准最初是为美国军方选择软件产品提供商时评价软件企业的软件开发质量保证能力而制定,所以称为软件企业能力成熟度模型(Capability Maturity Mode简称CMM)。该标准将软件企业的能力成熟度划分为5个等级,级别越高表明该企业在提供合格软件产品方面的能力越强。
软件过程包括管理过程(软件项目策划、软件项目管理)、组织过程(跨项目过程、培训、基础设施)、工程过程(需求分析、设计、编码、测试)。CMM分为五个等级:一级为初始级， 二级为可重复级，三级为已定义级，四级为己管理级，五级为优化级。成熟度反映了软件过程能力的大小，任何一个软件机构的软件过程必定属于其中某个级别。除了第一级以外,每级成熟度又由若干
关键过程域构成。CMM结构中关键实践描述了对关键过程域有效实施和制定化起重要的作用的基础设施和活动，有5个共同特征:执行约定、执行能力、进行的活动、测量和分析、验证实施。
CMM:软件能力成熟度模型，是对组织软件过程能力的描述。
CMMI:能力成熟度模型集成，目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。CMMI模型的前身是SW-CMM和SE-CMM，前者就是我们指的CMM。
CMMI与SW-CMM的主要区别就是:
一、覆盖了许多领域;到目前为止包括四个下面领域: ( 1)、软件工程( SW-CMM); (2)、 系统工程( SE-CMM); (3)、 集成的产品和过程开发(IPPD-CMM); (4)、 采购(SS-CMM)。
二、CMMI有两种表示方法,一种就是与CMM一样的阶段式表现方法(把CMMI中的若千个过程区域分成5个成熟度级别);另一种是连续式的表现方法(将CMMI中过程区域分为四大类:过程管理、项目管理、工程以及支持)。
三、CMM2级有6个关键过程区域,在CMMI中增加了一个:度量与分析;CMM4级有2个关键过程区域，在CMMI中也是2个，只是名称与内容有所改变;在CMM5级中有3个KPA,在CMMI中合并了，改为2个。最显著还是在CMM3级中，原来的7个KPA改为14个。
6. 软件测试与软件开发具有什么关系？
答: 1、没有软件开发就没有测试，软件开发提供软件测试的对象。
2、软件开发和软件测试都是软件生命周期中的重要组成部分
3、软件开发和软件测试都是软件过程中的重要活动。
4、软件测试是保证软件开发产物质量的重要手段。