软件工程教材知识点整理.doc

第一章 可行性研究
1、 软件工程项目可行性研究实质是一次大大压缩和简化了的分析和设计过程，主要在较高层次上以较抽象的方式进行，其目的是在尽可能短的时间内以最小的代价确定该项目是否能够开发，是否值得开发。
2、 可行性研究不是去开发一个软件项目，而是研究该项目能否在给定的资源和给定的时间开发，是否能够开发，是否值得开发。
3、 可行性研究的内容：技术可行性 （相关技术分析、资源有效性分析、风险分析）；经济可行性 （成本估计、效益分析 ）；操作可行性 ，又称社会可行性和运行可行性（就政治意识形态、法律法规、社会道德、民族意识以及系统运行的组织机构或人员等，分析系统能否运行及运行好坏程度）。
4、 可行性研究的步骤：对系统目标和范围的定义→对现行系统进行分析研究→导出新系统的逻辑模型→设计新系统的物理方案→推荐可行的方案。
5、 可行性研究阶段，成本估计的方法：
①基于已完成的类似项目进行估算；（自顶向下估计）
缺点:对开发中某些局部问题难以预估，导致考虑不周
②使用简单的“分解技术”来进行成本及工作量的估算；（自底向上估计）
③使用经验模型进行成本及工作量的估算。（经验算法估计）
主要经验模型：静态单变量模型；动态多变量模型；COCOMO模型。
COCOMO模型：Boehm将软件成本估算分成3个由粗到细的层次：基本层、中间层和详细层。每个层次又按软件项目的应用领域和复杂程序分成3种类型：组织型、半独立型和嵌入型。
6、 效益分析：系统的效益有两部分：经济效益和社会效益。 经济效益是指用使用新系统而增加的收入，包括使用新系统节省的运行费用，是一种有形的效益。
（经济效益度量指标：货币的时间价值 、纯收入、投资回收期 、投资回收率）；社会效益是一种无形的效益，主要从性质上、心理上进行衡量，很难直接量化，但在某些情况下，无效的效益能转化成有形的效益。

7、 系统流程图是描绘物理系统的传统工具，可以采用系统流程图来描述项目的大概业务处理流程，其基本思想是用图形符号以黑盒子形式描绘系统各部件（如程序、数据库、文档、人工过程等）。系统流程图表达的是信息在系统中各部件之间流动的情况，而不是对信息进行加工处理的控制过程。（信息有流动无处理）
8、 数据流图描述的是系统的逻辑模型，图中没有具体的物理元素，只是描绘信息在系统中的流动和处理情况。（数据流图是逻辑系统的图形表示）

第二章 软件项目计划
1、 软件项目计划的目标就是提供一个框架，使管理者有能够对资源、成本、风险及进度进行合理的估算分析和调度，为软件工程过程提供管理依据。 项目计划一般由软件项目的管理员、系统分析员与用户经过“可行性研究后”共同制订，并在“需求分析”阶段确定软件系统的详细需求后定稿，随着项目的进展定期更新。
2、软件项目计划的主要内容:风险分析、进度安排和项目组织。
3、风险分析活动：风险标识（项目风险、技术风险和商业风险）、风险估计、风险评价和风险管理与监控。
4、进度安排方法：PERT技术和Gantt图方法（看看书上的过程）。
5、小结：由于经过风险分析，能够做到“知已知彼”（彼即风险），从而“百战不殆”，使得开发者能够战胜风险带来的损失，使项目成功。 进度安排的落空不仅会造成项目开发成本的提高，造成有形的经济损失，而且会使客户的不满意度、不信任度增加，造成无形的经济损失。 在软件开发过程中，人是最活跃的部分。

第三章 需求分析
1、 需求分析是指开发人员通过细致的调查分析，详细、准确和完整地理解用户需要什么样的软件，将用户非形式的需求陈述转化为完整的需求定义，再将需求定义转换到相应的需求规格说明的过程。
2、 通常，把一整套的需求分析方法、技术和工具等的集合称为建模方法。
3、 需求收集的方式：访谈（程式化的访谈和非程式化的访谈 ）；问卷调查；使用用例；用户资料收集；建立快速原型。
4、 需求分析主要任务：问题分析、需求描述、需求评审。
5、 需求分析主要目的：确定用户需要系统做什么。
6、需求规格说明：需求分析的主要成果是得到需求规格说明（SRS）。需求规格说明为用户、分析人员、设计人员和测试人员之间的理解和交流提供了方便，是系统设计、测试和验收的依据。
大量统计数字表明，软件系统中15%的错误起源于需求的错误。一个有效的需求规格说明应具有如下特征：正确性、无歧义性、完整性、一致性、可验证性、可理解性、可修改性、可追踪性和注释等。
需求分析说明书的作用：① 用户与开发人员之间的合同 ② 概要设计的依据
③ 软件验收测试的依据。
数据流建模（功能建模）
7、数据流建模：数据流建模方法是一种结构化分析方法（SA）；自顶向下、逐层分解地定义系统需求；主要是利用数据流图（DFD）来对用户需求进行分析。
8、数据流图：数据流图描述的是系统的逻辑模型，图中没有具体的物理元素，只是描绘信息在系统中的流动和处理情况。（数据流图是逻辑系统的图形表示）
9、数据流图的四种基本符号：数据流(用箭头表示）；加工（加工一般用一个圆圈或圆角方框来表示 ）；数据存储(一般用开口的矩形框或双划线来表示)；数据的源点和终点（一般用正方形或立方体来表示 ）。
10、分层数据流图：将数据流图分为顶层数据流图，中间层数据流图以及底层数据流图，可以避免一次引入过多的细节，有利于控制问题的复杂度，从而便于对大型系统描述的实现。
①顶层数据流图:主要描述整个系统的作用范围，说明系统的边界，反映系统和外部环境之间的关系，即系统的输入和输出数据流。 顶层数据流图只有一张。
②中间层数据流图：通过分解高层加工得到的，其中有些加工还需进一步分解。
③底层数据流图：底层数据流图由一些不必再进行分解的加工组成。
11、数据流建模步骤:原则上是由外向里、自顶向下去模拟问题的处理过程.
画顶层数据流图； 画分层数据流图； 用数据词典定义数据流图中的所有数据；用加工说明描述数据流图中的基本加工。
12、数据词典：又称数据字典，是关于数据信息的集合，是对数据流图中的每个数据，包括数据流和数据存储，进行严格定义的场所，以保持数据在系统中的一致性。
数据字典的作用：①为用户与开发人员之间统一认识 ② 作为概要设计的依据 ③ 便于需求分析阶段定义各类条目
13、加工说明：数据流图中的“基本加工”由于没有进一步分解得到子图，因而需要加工说明来对其进行描述。 加工说明是描述基本加工如何把输入数据流变换成输出数据流的加工规则，是描述实现加工的策略而不是实现加工的细节。
IPO图、结构化语言（PDL，伪代码，是一种介于自然语言和形式语言之间的一种半形式语言）、判定表、判定树等均可作为加工说明的工具。
IDEF0图（功能建模）
14、IDEF0功能建模:IDEF方法是一套用来对复杂系统进行建模分析和设计的系统方法：IDEF0进行功能建模，IDEF1X用来建立数据模型，IDEF4方法则用于面向对象设计，等等。
15、IDEF0方法用严格的自顶向下、逐层分解的方式来构造系统的功能模型，用IDEF0图来描述。
IDEF0图：只能反映系统做什么，系统功能由谁做，但不能反映系统如何做，因为盒子内部的结构如何无从得知。

16、IDEF0图:也称为活动图形。主要元素是简单的盒子及箭头。盒子代表系统的功能（活动）。箭头表示系统处理的数据约束，可以是具体的事物，也可以是抽象的信息。 IDEF0功能建模方法要求一张IDEF0图中的盒子最多只能有6个（子图形还要求不少于3个）。
17、IDEF0建模步骤：IDEF0方法在详细的功能需求调研基础上，用严格的自顶向下、逐层分解的方式来进行；确定建模的范围、观点及目的；建立系统的内外关系图，即A-0图；建立A0图的一系列子图；书写文字说明。（P49）
IDEF1X（数据建模）
18、IDEF1X数据建模：IDEF1X方法是IDEF1方法的扩展版本。 IDEF1用来表示系统的信息结构和语义。 IDEF1X方法增强了图形的表达能力，丰富了语义和简化了开发过程。
19、IDEF1X图：实体是具有相同属性或特征的现实或抽象事物的集合，这个集合中的一个元素便称为实体的一个实例。 在一张IDEF1X图中 ，一个实体只能在图中出现一次。 属性：表示现实或抽象的事物一种特性或性质。
IDEF1X建模步骤：0阶段——确定建模目标和计划；1阶段——定义实体；2阶段——定义联系；3阶段——定义键；4阶段——定义属性。
需求分析(2)面向对象方法
1、UML建模语言：是一种可以应用于任面向对象软件开发方法的标记法和语义语言。
2、UML各种图：动态模型图(反映系统行为)：用例图、顺序图、协作图、状态图、活动图。 静态模型图（反映系统结构）：类图、包图、组件图、部署图、对象图。
3、UML特点 ：统一了面向对象方法的基本概念 （UML融合了Booch方法、OMT方法和OOSE方法中的有关概念 ）；具有更强的建模能力（正如G. Booch在他的一本书中所说：“如果你有好的思想，那它也是我们的。” ）；独立于特定的开发语言和开发过程。
4、UML应用：需求分析（用例图---功能的需求；类图---静态结构 ；状态图、顺序图和协作图等---类之间所需的协作，实现用例。）；设计（定义软件系统中的技术细节用到的类，如引入处理用户交互的类、处理数据的类、处理通信和并行性的类等。）；实现（组件图---代码组件的物理结构以及组件之间的关系；部署图---硬件的拓扑结构和组件的分布。）；测试（类图---单元测试；组件图、协作图---集成测试；用例图 ---确认测试）

第四章 概要设计
1、 软件设计：需求分析：软件系统必须“做什么” ；软件设计：“如何做”才可以满足需求规格说明中规定的各项需求。
2、 从工程管理的角度来看，软件设计通常分为两步，即概要设计和详细设计。
3、 概要设计的基本目的是回答“概括地说，软件系统应如实现”这一问题。因此，概要设计有时称为初步设计或总体设计。概要设计的主要任务是确定软件的总体结构，即确定软件系统的组成成份（子系统或模块）以及各组成成份之间的相互关系。方法：结构化方法、面向对象方法 。详细设计是对概要设计结果的进一步细化，其主要任务是确定软件系统各组成成份内部的数据结构和算法过程。
4、 抽象与求精：抽象，即过程抽象、数据抽象和控制抽象。抽象使得设计人员能够避开过早地陷入细节之中刻画过程和数据。求精能够帮助设计人员随着设计过程的深入而不断呈现更低层次的信息。
5、 模块化和信息隐藏：软件应该分解成可单独命名的且可访问的部件，这些部件称为模块。由Parnas倡导的“信息隐藏”是指模块中所包含的信息（包括数据和过程）对不需要这些信息的其它模块是不可访问的。抽象有助于定义组成软件的过程（或信息）实体；隐藏定义并加强了对模块内部访问的约束，有助于分离模块的实现者和使用者。
6、 模块独立性：模块独立性是模块化、抽象和信息隐藏的直接产物。模块的功能独立性可以使得模块既容易开发又容易维护。模块独立性有两个定性的度量标准：内聚度和耦合度。
7、 内聚度：模块内部各成分联系紧密的程度。内聚度越高，模块的独立性就越强。内聚程度从高到低的顺序是：功能内聚、信息内聚、通信内聚（数据相关—数据或标记耦合）、过程内聚（程序流程图；过程相关---控制耦合）、时间内聚（初始化模块）、逻辑内聚和偶然内聚。 设计模块时，应该尽可能避免使用偶然内聚等低级内聚的模块，争取高级内聚的模块，以提高模块的独立性。
8、 耦合度：模块之间相互关联紧密的程度。模块的耦合度越低，模块的独立性越强。 耦合程度从低到高也可分为七种：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。 在设计模块时，应该尽量使用数据耦合，必要时使用标记耦合，少用控制耦合，限制使用公共耦合，最好不要使用内容耦合。
结构化设计方法
面向数据流图的软件结构设计
面向数据流图的设计方法是一种结构化设计方法。过程：首先，研究、分析和审查数据流图，确保数据流图符合实际，必要时还要进一步精化数据流图；然后，确定数据流图的类型，即变换型数据流或事务型数据流；再依据数据流图的类型采用变换分析法或事务分析法导出系统初始的软件结构；最后，依据软件设计原理和一些优化策略改进系统初始的软件结构，形成最终的软件结构。

1、 在结构化设计方法中，软件结构是软件系统模块层次结构，反映了整个系统功能及其之间的关系。 软件结构图的主要内容有：模块、模块间的调用关系和模块之间传递的信息。
2、 模块：在软件系统的软件结构图中，有6种类型的模块：传入模块、传出模块、变换模块、协调模块、源模块和漏模块。 在软件结构图中，模块用方框来表示，并用名字标识该方框。
3、 调用关系：在软件结构图中，模块间的调用关系主要有三种：顺序调用、选择调用和循环调用。方框之间的箭头表示模块之间的调用与被调用关系。模块间调用的次序，习惯上是从左至右。
4、 数据或控制信息：在软件结构中，模块传递的信息用带名称的短线箭头来表示。箭头方向代表信息传递的方向。若箭头线尾是带空心圆圈，则表示该箭头线代表的是数据；若箭头线尾是带实心圆圈，则表示该箭头线代表的是控制。
5、 数据流变换分析法：一种将变换型数据流图映射为变换型软件结构图的软件系统设计方法。（P101）
6、 数据流事务分析法：是将事务型数据流图映射为事务型软件结构图的软件系统设计方法。（P103）
7、 软件结构图的改进：模块大小适中、模块扇入扇出合理、模块的作用域应在控制域内 。 模块的扇出是指模块直接调用多少其它模块。 模块的扇入是指共有多个模块直接调用本模块。良好的软件结构图，上层模快（主要是控制模块）往往具有较高的扇出，底层的模块（主要是功能型模块）具有较高的扇入，呈两头小、中间大的清真寺状。 模块的作用域是指模块中判定的作用范围，它是指所有受这个判定影响的模块。 模块的控制域是指模块本身及其直接或间接调用的模块。 如果模块的作用域不在控制域之内，则会增加模块间数据的传递量，使模块之间出现控制耦合。

面向IDEF0图的软件结构设计
8、 面向IDEF0图的软件结构设计是一种结构化设计方法，它以系统的功能模型和信息结构（数据）为基础设计系统的软件结构。
9、 概要设计时，一般可按照IDEF0图的分解层次，逐层将其转换成软件结构。

面向对象设计模式
1、对象建模：主要任务是了解某个特定应用问题域内所涉及的对象，以及各种各样的结构和通信关系。 介绍Coad/Yourdon 面向对象分析方法来进行对象建模，在表示符号上采用UML建模语言提供的标记法。
2、确定对象&类的方法 ：三视图模型法（实体一关系模型、数据流模型、状态—迁移模型）。
3、面向对象设计是在对象建模的基础进行逐渐扩充的过程。在对象建模中，是以问题域为中心，而面向对象设计要在软件系统环境，即解空间，解决对象建模中要完成的事情。对象建模是以问题域为中心确定“做什么”，面向对象设计则以软件系统实现环境为中心确定“如何做”。
4、面向对象设计主要设计内容：问题域部分设计、人机交互部分设计 、任务管理部分设计 、数据管理部分设计、系统交互部件的设计。（P110）
5、面向对象设计模式是普通面向对象设计问题的解决方案，这类问题以一组交互类的形式出现，用户根据需要定制这些交互类以形成专门的设计。
作用：设计模式不仅使人们可以更加方便地复用成功设计方案，提高软件的灵活性和可复用性，也能提高已有系统的文档管理和系统维护的有效性。
6、创建型模式：创建型模式帮助系统独立于对象的产生、组合和表示。
作用：一方面均将关于系统使用哪些具体的类的信息封装起来；另一方面隐蔽了这些具体类的实例是如何被创建和放在一起的。因此，创建型模式在“什么”被创建、“怎样”被创建、“谁”创建它以及“何时”创建等方面带来了很大的灵活性，有利于设计可复用的软件成分。 主要有两种：工厂方法模式、抽象工厂模式。 结构型模式：结构型模式涉及如何组合类和对象构成更大的结构。一种方法是采用继承机制来组合接口或实现来形成更大的结构；另一种方法通过对象组合方式对一些对象进行组合来形成。由于对象组合可以在运行时刻改变，而继承机制为静态类组合，因而对象组合方式具有更大的灵活性。 主要有两种：适配器模式、组合模式。 行为型模式：行为型模式不仅描述对象或类的模式，还描述它们之间的通信模式。这些模式刻划了在运行时难以跟踪的复杂的控制流。行为型模式使设计者的注意力从控制流转移到对象间的联系方式上。 主要有两种：迭代器模式、观察者模式。
7、MVC框架中类的交互：当用户进行一些输入动作后，控制器接收用户事件，并根据事件的类型来改变模型；视图事先会在模型中登记，当模型数据发生改变时，马上通知已向此模型登记的每个视图，视图从模型中取得最新的数据并刷新自己。

概要设计文档
1、概要设计说明包括软件系统的基本处理流程、软件结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等。概要设计说明为软件的详细设计提供了基础，也是系统集成测试的主要依据。
2、概要设计文档复审：目的：较早期地发现设计中存在的错误和缺陷。参与者：除开发人员外，必须要有用户代表参加，必要时还应邀请有关领域的专家参加。
内容：重点在软件系统的总体结构、模块划分、内外接口以及人机界面上。方式：正式复审和非正式复审。

小结:①概要设计是由软件结构设计、内外接口设计、数据逻辑结构设计和用户界面设计等活动组成，是将用户需求转化为计算机可实现的系统的一个重要步骤。②面向数据流图的设计方法和面向IDEF0图的设计方法是两种常用的结构化设计方法，其特点是自顶向下，逐层细化。③Coad/Yourdon方法在面向对象设计方法中比较系统的一种方法，其四个部分的设计实际是对面向对象分析模型在五个层次上扩充，扩充的内容实质也就是用户界面设计、内外接口设计、数据逻辑结构设计等方面的内容。

第五章 详细设计
1、 详细设计的目标与任务：概要设计确定了软件系统的总体结构，详细设计则对概要设计结果进一步细化，给出目标系统的精确描述，以便在编码阶段直接翻译成计算机上能够运行的程序代码。详细设计的任务：算法过程的设计；数据结构的设计；数据库物理设计；信息编码设计；测试用例的设计；编写“详细设计说明书”。（主要任务：确定软件系统各组成成份内部数据结构和算法过程）
2、 详细设计图形描述工具：详细设计中用于过程设计的图形工具，包括程序流程图、盒图、问题分析图和协作图。
3、 Jackson程序设计方法是一种面向数据结构的结构化程序设计方法。通过分析问题的输入、输出数据结构（用Jackson图表示）的对应关系，按一定的映射规则将其映射成软件的过程描述，用Jackson伪代码表示。（P134）
4、 Warnier程序设计方法：LCP（逻辑构造程序）程序设计方法。
5、 程序规格说明文档及复审：又称详细设计说明，与概要设计说明相比，程序规格说明着重描述模块的细节，包括算法过程和数据结构。如果软件系统比较简单，则可将程序规格说明并入概要设计说明中。 程序规格说明的复审类似于概要设计说明的复审，但重点在于各个模块的具体设计上。

小结：详细设计是进行逻辑系统开发的最后一个阶段，其质量的好坏将直接影响到系统的编码实现。 合理选择和正确使用有关工具、深入理解和掌握有关设计思想和方法，对搞好详细设计是非常重要的。 结构化程序的详细设计与面向对象程序的详细设计有许多共性。
第六章 软件测试
1、软件验证：是通过检查和提供客观证据表明软件已经满足规定的需求，是确保软件质量和降低软件成本的重要手段，涉及软件的整个生存周期。
进行软件验证的方式大体有两种：测试和证明。
测试又分静态测试和动态测试两种。（静态测试，又称评审，是对软件进行的一种分析和检查活动。动态测试是通过运行软件来检验其动态行为和运行结果的正确性。） 证明是一种通过形式化的数学方法来确保软件正确性的活动。
2、软件测试：是在软件投入运行前，对软件需求分析、设计规格说明和编码的复审，是为了发现错误，通过检查和提供客观证据表明软件已经满足规定的需求。
软件测试是确保软件质量和降低软件成本的重要手段，涉及软件的整个生存周期。
软件测试就是试图以最少的代价发现软件分析、设计和编码中存在的各种不同类型的错误，从而提高软件质量，降低软件成本。
一般的软件开发组织要将30%~40%的项目精力投入到测试之中，一些人命悠关的软件（如航空器的飞行控制软件）其测试费用往往更高。
3、 软件测试对象：软件生存周期各阶段文档和代码。
4、测试与调试：测试是查找错误症状的过程，调试则是查找错误症状原因并改正错误的过程。 针对测试中发现的错误进行改正，这便是调试的工作。测试和调试往往交替进行。
5、软件测试的根本任务就是发现软件中存在的错误。
由于软件错误往往出现在软件的分析和设计中，而且错误发现越晚，改正错误的工作量也越大，因而在开发前期利用静态测试非常重要，而且发现错误的效率也往往比较高。
6、测试只能说明软件中存在错误，不能表明程序没有错误，因而任何软件经过测试后不能保证软件中不再存在错误。
白盒测试
白盒测试是一种以程序的内部逻辑结构为依据设计测试用例的方法，因而又称结构测试或玻璃盒测试。
合理的白盒测试就是要选取足够的测试用例，对源代码实行比较充分的覆盖，以便尽可能多地发现程序中的错误。（原因：穷举测试不合理）。
主要有两种方法：一种称为逻辑覆盖法，另一种称为路径覆盖法。除此外，对循环的测试，可采用循环覆盖法。
①逻辑覆盖： 语句覆盖，测试用例能使被测程序的每条执行语句至少执行一次； 判定覆盖：测试用例能使被测程序中的每个判定至少取得一次“真”和一次“假”。又称分支覆盖；条件覆盖：测试用例能使被测程序中每个判定的每个条件至少取得一次“真”和一次“假”。如果判定中只有一个条件，则条件覆盖便满足判定覆盖，否则，不一定；判定/条件覆盖：测试用例既满足判定覆盖，又满足条件覆盖；条件组合覆盖：测试用例使每个判定中所有可能的条件取值组合至少执行一次。 其中语句覆盖最弱。
②基本路径覆盖法：是在程序图的基础上，通过分析环形复杂性，导出基本路径集，然后设计测试用例使基本路径集中的每条路径至少经过一次。
独立路径：包含一组以前从未被处理的语句或条件的一条路径。
③循环覆盖法： 逻辑覆盖法和基本路径覆盖法对于循环只进行了循环一次的测试，显然是不充分的。而循环是大多数软件实现算法的关键部分，因此对循环的测试是十分重要的。对于结构化程序而言，循环主要有三种：简单循环、嵌套循环和串接循环。
黑盒测试
黑盒测试 ：又称功能测试、数据驱动测试等，它将待测试对象看成是一个黑盒子，不考虑程序内部的逻辑结构和特性，只依据规格说明书检查程序的功能是否能正常使用。通常，白盒测试用于测试的早期，而黑盒测试由于不需了解程序内部情况，因而被许多后期测试（如确认测试、系统测试）采用。
测试用例设计方法：用黑盒测试发现程序中的错误，主要根据输入条件和输出条件确定测试数据，来检查程序是否能产生正确的输出。
进行黑盒测试，主要有下述几种方法：等价分类法、边界值分析法、猜错法、因果图法。
等价分类法和边界值分析法通过选择有代表性的测试数据来暴露程序错误。但不同类型不同特点的程序通常又有一些特殊的容易出错的情况。并且，有时分别使用某些测试用例测试时程序工作正常，但其组合可能会使程序出错； 猜错法是根据经验和直觉设计测试用例，尽管能考虑到输入组合的情况，但显得不充分；因果图法借助图形来设计测试用例，特别适用于被测程序具有多种输入条件，程序的输出又依赖于输入条件的各种组合的情况。
黑盒法综合策略：首先用边界值分析法设计测试用例；必要时用等价分类法补充测试用例；必要时再用猜错法补充测试用例；如果在程序的说明中含有输入条件的组合，宜在一开始末就采用因果法，然后再按上述步骤进行。
动态测试
动态测试：通过运行软件来检验其动态行为与运行结果的正确性。
（1）单元测试：又称模块测试或分调，是动态测试中的第一步，通常在编码阶段进行。单元测试集中检查软件设计的最小单元——模块，即程序中最小的独立编译单位。
单元测试一般总是把白盒法和黑盒法结合运用。先用黑盒法设计出一组基本的测试用例，然后用白盒法，根据覆盖标准要求补充新的测试用例满足覆盖标准。在一般情况下，单元测试应以白盒法为主。
单元测试在于考察模块的接口和内部结构，检查是否符合程序规格说明（即详细设计说明书）的要求。测试的重点在以下几个方面：模块的接口；局部数据结构；重要的执行通路；出错处理路径；影响以上各项的边界条件。
测试软件：一般地，驱动模块应完成接收测试数据，并把数据传给被测模块，然后打印有关结果等任务；桩模块应该模拟实际模块完成少量数据处理，并检验和打印入口处的信息，然后将控制返回给被测模块。
面向对象单元测试：最小的可测试单元是类，包含一组不同操作。对面向对象软件的类测试等价于结构化软件的单元测试。类测试方法：基于故障的测试、随机测试和划分测试。

（2）集成测试：集成测试，又称组装测试、综合测试或联调，是在单元测试完成之后，将所有模块按概要设计要求组装成系统的时候进行的测试。
主要目标是发现与接口有关的问题。主要检查模块接口和全局数据。
集成测试有组装和检验两重意义，一方面将各经过单元测试的模块拼装起来形成完整可运行的系统；另一方面要检验每一步拼装过程是否正确。
测试策略：集成测试一般应由独立的测试小组进行，由测试小组提出测试用例，记录测试结果，并编制测试报告。
测试用例的设计通常采用黑盒法，其实施策略又分为非渐增式和渐增式两种。
非渐增式测试：采用非渐增式测试，一般应先经过单元测试，然后再把所有模块一次性组装在一起进行测试，最终得到要求的软件系统。
将模块一次性组装在一起运行成功的可能性并不大。其结果往往是发现有错误，但由于程序中模块一次性引入过多，难于进行错误定位。同时，一旦修正错误之后，新的错误很可能马上会出现。 除规模很小的程序，一般很少采用此种测试策略。

渐增式测试：渐增式测试采用逐步加入模块或功能簇的方式进行，在加入过程中边连接边测试，比较容易定位和修正错误，且接口也可以更容易进行彻底地测试。
按照添加模块的方式，又可分为自顶向下的渐增测试和自底向上渐增测试。
自顶向下的渐增式测试：首先集成主控模块，然后按照软件结构的控制层次自上而下进行集成，把主控模块的直接（或间接）调用模块按深度优先或广度优先的方式集成到整个软件结构中。 特点：①能较早地显示整个程序的轮廓，对增强开发人员的信心，取得用户的支持，有重要的作用；②只需编写桩模块供测试用，驱动模块可以利用实际模块；③能尽早发现主要控制中的问题，减少以后的返工；④可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误，为其后对主加工分支的组装和测试提供了保证；⑤由于每添加一个新模块，就进行一次测试，这样虽然耗费一些时间，但却使被测程序测试更彻底，尤其是上层模块。
自底向上的渐增式测试：(1)把低层模块组合成实现某个特定的子功能的模块簇，并用编写的驱动模块控制它进行测试；可以对若干功能簇并行进行测试；
(2) 用实际模块换掉驱动模块，沿软件结构自下而上移动，把子功能簇组合起来形成更大的子功能簇，并进行测试；(3)重复(2)直到所有模块组装完毕。
特点：①不能在测试的早期显示出程序的轮廓。程序的总体结构，要等到加入最后一个模块时才能最终形成；②测试软件只需要驱动模块，不需要桩模块，而且随着组装层次的上移，驱动模块将大为减少（在多数情况下，编写驱动模块要比桩模块容易）；③由于从低层模块开始组合，所以较易产生测试用例。
在模块组装起来后，新的数据流路径建立起来了，新的控制逻辑可能激活了等等。这些改变可能会使原本工作正常的功能产生错误，因此，应对某些已经进行过的测试的测试用例再重新执行一遍，以保证上述改变不会传播意外的副作用，称之为回归测试。

（3）确认测试：就是验证所开发软件的功能和性能及其他特性是否符合软件需求规格说明书的要求。所以，确认测试又称之为有效性测试。 内容：功能测试；性能测试；强度测试；配置复审。
确认测试是由软件开发单位组织进行的最后一次测试，也是把软件交给用户，进行正式的安装和验收之前所作的一次重要的准备。为了确保测试质量，一方面应组织独立的测试小组进行测试，另一方面吸收任务委托单位及用户代表参加测试，以提高测试的可信度。同时，应将测试中发现的错误填入问题清单，交开发者处理。
（4）系统测试：是在更大范围内进行的测试，它将经过确认测试的软件作为整个基于计算机的系统的一个元素，与计算机硬件、外设、支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对系统进行的一系列集成和确认测试。
系统测试通常由任务委托单位或用户组织的验收小组负责，一般应根据需求分析说明书来设计测试用例，在实际使用环境中运行。系统测试的内容对不同的系统各不相同。

第七章 软件维护
1、所谓软件维护是指软件交付使用之后，为了改正错误或满足新的需求等而修改软件以达到延长软件寿命为目的的过程。软件维护阶段的长短决定了软件寿命的长短；软件维护阶段的费用占软件总成本的大部分。
2、软件维护不同于硬件维护，主要原因是软件维护不是因为使用时软件磨损或老化引起，而是由于软件设计不正确、不完善或使用环境的变化等引起。
3、软件维护类型：改正性维护，识别和纠正软件错误，改正性能上的缺陷，排除实施中的误使用而进行的诊断和改正错误的活动。约占整个维护的20%；适应性维护，使软件适应处理环境或数据要求的变化而修改软件的活动。约占整个维护的25%；完善性维护，修改或再开发软件，以扩充软件功能，增强软件性能等。约占整个维护的50%；预防性维护或再工程，采用先进的软件工程方法对需要维护的软件或软件的某一部分（重新）进行设计、编码和测试。连同其它维护约占整个维护的5%。
4、软件维护成本：软件维护活动所花费的工作量占软件整个生存期工作量的70%以上。影响软件维护工作量的因素有很多，就软件系本身而言，有以下几个主要方面： 系统的大小；程序设计语言；系统年龄；数据库技术的应用；软件开发新技术的运用。
5、软件维护相关的模型：Boehm模型；Belady与Lehman模型。
6、软件维护过程本质上是修改和压缩了的软件定义和软件开发过程。
7、软件可维护性是指纠正软件系统中出现的错误或缺陷，以及为满足新的要求进行修改、扩充和压缩软件的容易程度。
软件可维护性的7个度量指标：可理解性，可测试性，可修改性，可靠性，可移植性，可使用性及效率。
8、影响软件可维护性的软件属性：可理解性，表现为人们通过阅读源代码和相关文档，理解软件的结构、接口、功能和内部过程的容易程度；可测试性，一个软件容易被测试的程度；可修改性，程序容易修改的程度。
9、软件再工程技术：是一类软件工程活动，通过对旧软件(遗留系统)实施处理，以增进对软件的理解，同时又提高了软件自身的可维护性、可复用性等。
逆向工程：软件逆向工程，通过对程序的分析，导出更高抽象层次的表示，如从现存的程序中抽取数据、体系结构、过程的设计信息等，是一个设计恢复过程。
软件重构是对源代码和/或数据进行修改，使其易于理解或维护，以适应将来的变更。 软件重构要求关注模块细节。
正向工程也称为改造，用从现存软件恢复设计中得到的信息去重构现存系统，以改善其整体质量。
10、软件维护的副作用：因修改软件而造成的错误（编码副作用、数据副作用、文档副作用）

小结：软件工程学的一个主要目的便是提高软件的可维护性，降低软件维护的代价； 软件维护是软件生存周期的最后一个阶段，也是成本最高的阶段； 软件维护大多要涉及到软件设计内容的修改，从而要重视软件维护的副作用，对软件维护要有正式的组织，制定规范化的过程，实行严格的维护评价。

第八章 软件质量
1、 软件质量度量的两个方面：软件复杂性分析、软件可靠性分析。
2、 软件质量控制：ISO9000认证、软件配置管理SCM、CMM。
3、 评价软件质量可从三个方面进行，即产品或中间产品、过程（即软件生产所需的资源和活动）和项目。
4、 复杂性度量方法：McCabe环形计数法
程序环形复杂度V（G）=程序流程图中的“判定数”+1
=程序图中的“环形数”。
=m-n+2
其中m对应于程序图中的弧数，n对应于程序图中的节点数
5、 软件可靠性：软件在给定的时间间隔及规定的使用环境条件下，按分析和设计规定的要求成功地运行程序的概率；是与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性。
软件可靠性三要素：失效，是指最后执行结果与有关规格不相符或用户在软件系统边界觉察到不期望的软件出错行为；时间，即软件失效的时间；环境，软件运行时所需要的支持系统及有关的因素。软件可靠性、硬件可靠性和操作可靠性三者综合起来反映整个计算机系统的可靠性。
软件可靠性测试：
①Gilb植错模型
假设：N表示软件中原有残留的错误数；S表示植入软件中的错误数；
n表示测试中发现的原有错误数；s表示测试中发现的植入错误数。
则： N=(n/s)*S
②Hyman分别测试模型
假定：B0表示软件中原有的残留错误数；B1表示甲测试员在某一时间内发现的错误数；B2表示乙测试员在同一时间内发现的错误数；Bc表示甲乙两人发现的相同错误数。 则：B0=(B1*B2)/Bc
6、软件配置管理是一组用于计算机软件的整个生命周期内管理变化的活动。
主要目标：使变化更易适应，并减少变化发生时所需的工作量。
7、CMM：1987年，美国卡内基-梅隆大学软件工程研究所（Software Engineering Institute, SEI）在美国国防部的支持下，提出了“软件过程能力成熟度模型CMM (Capability Maturity Model）”。
CMM作用：一方面，可以用来评价软件组织的质量保证能力；另一方面，也为软件组织改进软件过程，提高软件过程能力提供了依据。
8、软件过程能力成熟度等级：初始级，混沌的软件过程。焦点：英雄人物；可重复级，经过训练的软件过程。焦点：项目管理；已定义级，标准一致的软件过程。焦点：工程过程；定量管理级，可预测的软件过程 。焦点：产品和过程质量；优化级，能持续改善的软件过程 。焦点：持续的改进。
9、CMM与ISO9001的主要区别：CMM明确强调持续的过程改进，而ISO9001则确定可接受的质量体系的最低要求；CMM严格适用于软件；而ISO 9001范围很广，涵盖了硬件、软件、加工材料和服务。

小结：提高软件质量，一方面要在软件开发过程中对开发成果进行验证，另一方面要注重软件开发过程的规范化和可视化。前者注重的是产品本身的质量，后者注重的是产品管理的质量。 软件复杂性和可靠性分析技术为软件质量的分析提供了量化的方法。

第九章 软件复用
1、 所谓软件复用是指利用已有的、对建立新系统有用的软件制品来形成新系统的活动。目前，人们对软件复用寄予厚望，认为其有可能成为突