《软件工程》复习要点

1、第一章 概论1. 计算机软件：计算机系统中的程序及文档，程序是计算任务的处理对象和处理规则描述。2. 软件的发展：第一台计算机高级语言软件工程。3. 软件的特点:逻辑实体、被开发、无磨损和老化、硬件依赖、未自动化、成本昂贵、涉及社会因素4. 现代软件 = 程序 + 软件工程现代软件企业 = 软件 + 商业模式（1）软件构建管理、源代码管理、软件设计、测试、项目管理等是软件工程的核心，用户体验与用户界面是优化（2）程序(算法，数据结构等)是基本功（3）软件工程决定了软件的质量（4）商业模式决定企业成败5. 现代计算机软件的特殊性(1) 非连续性：人类通常容易理解连续事件，但软件系统不具备该特性(

2、2) 易变性:a.修改软件代码相对容易，但代码的更改会带来意想不到的问题b.如何正确地修改软件是一件很困难的事情(3) 服从性:软件不独立存在，需服从系统中其它组成部分的要求6. 现代计算机软件的特殊性(对软件工程师而言) (1) 许多不同的程序设计语言，软件工具和开发平台。 (2) 许多不同的软件开发流程。 (3) 软件团队中存在许多不同的角色。7. 软件工程定义 1968年在NATO(北大西洋公约组织)会议上首次提出 (1) IEEE:软件工程是将系统化的，将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中；对上述方法的研究。 (2) 计算机科学技术

3、百科全书：应用计算机科学、数学及管理科学等原理，开发软件的工程。8. 软件工程框架：目标，过程和原则。（P6） 创造足够好的软件。 (1) 目标：正确、可用、开销合宜. (2) 过程：如何生产满足需求且达到目标的软件产品 (3) 原则：适宜的开发模型、合适的设计方法、工程支撑、软件工程管理9. 软件工程生命周期 (P7)系统工程、需求分析、设计、编码、测试、运行和维护。软件工程分层 10. 能力成熟度模型CMM/CMMI卡内基梅隆软件工程研究所(SEI)11. 软件过程模型（P16） (1) 瀑布模型:给出了软件生存周期活动的固定顺序，上一阶段的活动完成后向下一阶段活动过渡，最终得到产品。优点

4、：结构简单明了；历史较长（70年代W. Royce提出）、应用面广泛、为广大软件工作者所熟悉；已有与之配套的一组十分成熟的开发方法和丰富的支撑工具。缺点：a. 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发. b. 开发早期存在的问题往往要到交付使用时才发现，维护代价大.(2) 原型模型特点:a.原型系统的开发需要尽可能的采用快速开发的工具b.在原型阶段要进行严密的项目计划与管理往往比较困难c.用户紧密介入系统原型开发过程中优点：对于需求不确定或是技术风险较大的系统开发，可以大大降低风险。缺点：原型阶段的部分工作可能会被丢弃。(3) 增量模型特点:a. 基于完整的系统全局设计，以功能增

5、量的方式逐步进行局部功能开发b. 每个递增功能的开发过程仍然是以瀑布过程模型开展c. 功能是自顶向下生长的，过程采用的是自顶向下的软件开发方法 优点：a. 能较快的产生一个可操作的系统，从而减少开发过程中用户需求变动的可能性，又提高了开发者和用户的士气b. 在每一步递进中都可以把用户/开发者的经验结合到不断求精的产品中c. 功能是逐步递增的，软件测试更为容易，项目组织和人员安排可以按照功能生长进行组织安排缺点：a. 系统的功能递增有可能是缓慢的，持续时间较长，用户无法很快获得一个完整的系统b. 必须基于一个完整的系统总体设计来生长软件功能，每一次递增的功能开发必须都考虑与原有功能的集成以及符合

6、系统的总体设计要求c. 系统局部的优化与系统全局的优化问题，如重用性(4) 螺旋模型特点:a. 软件开发过程为一个逐步细化的螺旋周期过程。每经历一个周期，系统就得到进一步的细化和完善b. 强调风险分析与控制，基于风险分析逐层推动过程中的各项活动 优点：a. 强调风险驱动大大减小了软件开发的风险b. 能尽早识别那些导致80重复工作的开销来源于20的问题c. 结合了其它几种过程模型的优点缺点：a. 过程复杂，因此过程的组织与管理挑战性大b. 风险分析的方法较为复杂和依赖于经验c. 过程步骤的详细定义及里程碑划分不是很明确(5) 基于构件的开发模型支持软件复用 (Reuse)：利用预先包装好的软件构

7、件（包括组织内部开发的构件和现存商品化构件COTS）来构造应用系统包括领域工程和应用系统工程两部分第二章 系统工程1. 基于计算机的系统：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列.计算机系统主要元素：软件、硬件，人员，数据库，文档和规程2. 系统工程的任务：（1） 识别用户要求：做什么，不做什么？（2） 系统建模和模拟：硬件、软件、人机接口、数据模型（3） 成本估算及进度安排（4） 可行性分析：经济、技术、法律等（5） 生成系统规格说明(或者可行性分析报告)3. 可行性分析(1) 经济可行性：从经济角度确定系统是否值得开发成本：硬件、软件、设备，开发费用，系统安装、运行和

8、维护费用，人员培训效益：经济效益、社会效益(2) 技术可行性：在现有资源和技术条件下能否实a.风险分析：是否应用最新技术？b.资源分析：是否具备人员、类似开发经验等各类资源？c.技术分析：当前技术能否支持?技术对成本的影响？(3) 法律可行性中华人民共和国著作权法,计算机软件保护条例第三章 需求工程1. 需求工程阶段与步骤（P34）（1）需求获取：确定系统的范围、人员、功能、限制、环境等（2）需求分析与协商：需求之间关系、一致性、重叠与遗漏情况（3）系统建模：建立分析人员与用户的桥梁、排除错误和不足（4）需求规约：用户和开发者之间的一个协议（5）需求验证：功能的正确性、完整性和清晰性（6）需求

9、管理：获取、组织并记录系统需求的系统化方案，使用户与项目团队对不断变更的系统需求达成并保持一致2. 需求工程是一个交叉的、递增的和反复的活动获取 分析与建模 编写规约 验证 重新评估 更正并减小误差 证实 重写 3. 软件需求 (P35)(1)功能需求 （2）性能需求 （3）用户或人的因素 （4）环境需求（5）界面需求 （6）文档需求 （7）数据需求 （8）资源使用需求（9）安全保密需求 （10）可靠性需求 （11）成本与进度需求 （12）其他非功能需求4. 需求分析原则:a） 能够表示和理解信息域b） 能够定义软件完整的功能c） 能够表示软件的行为d） 划分描述数据、功能和行为的模型e） 分

10、析过程应该从要素信息移向细节信息5. 信息域（P40）：包括信息内容、信息流、以及信息结构(1) 信息内容：数据对象一组数据体的组合，例如“毕业设计选题表”(2) 信息流：数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出，例如“选题信息汇总”(3)信息结构：表示了各种数据和控制项的内部组织6. 需求验证（1）涉众：开发团队、需求评审团队（2）检查内容一致性检查完整性检查数据检查功能性检查约束检查风险检查检验标准审核评审意见确认签字7. 需求管理 对需求进行唯一性标识 建立跟踪表：（1）特征跟踪表：需求与系统/产品特征的关联（2） 来源跟踪表

11、：需求来源（3） 依赖跟踪表：需求之间的关系 方式：（1）正向跟踪：以用户需求为切入点，检查需求规约中的每个需求是否都能在后继工作中找到对应点（2）逆向跟踪：检查设计文档，代码，测试用例等工作产品是否都能在需求规约中找到出处第四章 设计工程1. 软件设计把软件需求变换成软件表示模型，它主要包含两个阶段：概要设计和详细设计（1）概要设计：数据结构、软件体系结构及其接口（2） 详细设计：将体系结构中的结构性元素转换为软件部件，得到详细数据结构和算法2. 软件设计原则（P49）（1）抽象: 是从特殊到一般的过程，上层概念是下层概念的抽象，下层概念是上层概念的精化和细化a.过程抽象(功能抽象)：任何一

12、个完成明确定义功能的操作都可被使用者当作单个实体看待b.数据抽象:定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据（2）逐步求精: 把问题的求解过程分解成若干步骤或阶段，每步都比上步更精化，更接近问题的解法注：抽象使得设计者能够描述过程和数据而忽略低层的细节求精有助于设计者在设计过程中揭示低层的细节（3）模块化模块独立的衡量标准：内聚度和耦合度内聚(Cohesion)：一个模块内部各个元素彼此结合的紧密程度的度量耦合(Coupling)：模块之间的相对独立性(互相连接的紧密程度)的度量（4）信息隐藏3. 部件级设计技术（1） 图形表示法程序流程图（2

13、）图形表示法PAD图 Problem Analysis Diagram的缩写 ，由程序流程图演化而来(3) 判定表当算法中包含多重嵌套的条件选择时，用程序流程图、N-S图或PAD都不易清楚地描述，然而，判定表却能清晰地表达复杂的条件组合与应做动作之间的对应关系优点:能够简洁，无二义性地描述所有的处理规则。缺点：判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构第五章 结构化分析与设计1. 结构化分析与设计是一种面向数据流的传统软件开发方法，以数据流为中心构建软件的分析模型和设计模型1. 结构化分析SA （2）结构化设计SD （3）结构化程序设

14、计SP自底向上的抽象与自顶向下的逐层分解2. 结构化分析过程（1）理解当前的现实环境，获得当前系统的具体模型( 物理模型)（2）从当前系统的具体模型抽象出当前系统的逻辑模型（3） 分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型（4）为目标系统的逻辑模型作补充3. 结构化分析的描述形式（P68）（1）数据字典是模型的核心，它包含了软件使用和产生所有数据的描述（2）数据流图：用于功能建模，描述系统的输入数据流如何经过一系列的加工变换逐步变换成系统的输出数据流（3）实体关系图：用于数据建模，描述数据字典中数据之间的关系（4）状态转换图：用于行为建模，描述系统接收哪些外部事件，以及在外部事

15、件的作用下的状态迁移情况4. 数据流图 (P69)描述输入数据流到输出数据流的变换(即加工)过程，用于对系统的功能建模（1）基本元素：a.数据流 由固定成分数据组成，代表数据流动方向b.加工 输入数据流到输出数据流的变换c.文件 使用文件、数据库等保数据结果d.源或宿 存在于软件系统之外的人员或组织(2)描述一个加工的多个数据流之间的关系a. 星号()：表示数据流之间存在“与”关系所有输入数据流同时存在时，才能进行加工处理,或加工处理的结果是同时产生所有输出数据流b. 加号()：表示数据流之间存在“或”关系至少存在一个输入数据流时才能进行加工处理,或加工处理的结果是至少产生一个输出数据流c.

16、异或()：表示数据流之间存在“异或”(互斥)关系必须存在且仅存在一个输入数据流时，才能进行加工处理,或加工处理的结果是产生且仅产生一个输出数据流(3)数据流图的层次结构（P71）顶层图只有代表整个软件系统的1个加工，描述了软件系统与外界(源或宿)之间的数据流顶层图中的加工经分解后的图称为0层图(只有1张)中间层图中至少有一个加工(也可以有多个)在下层图中分解成一张子图处于最底层的图称为底层图，其中所有的加工不再分解成新的子图，称为基本加工(4) 分层数据流图绘制步骤:a. 绘制系统输入和输出（顶层图）b. 绘制系统内部c. 绘制加工内部d. 重复第3步，直至每个尚未分解的加工都足够简单(即不必

17、再分解)5. 分层数据流图的审查(P77):检查DFD图是否存在错误或不合理的部分(1)一致性检查：分层DFD中是否存在矛盾和冲突(2)完整性检查：分层DFD本身的完整性，即是否有遗漏的数据流、加工等元素6. 数据字典(P83)（1）数据流图+数据字典=软件逻辑模型(分析模型)（2）数据字典由字典条目组成，每个条目描述DFD中的一个元素（3）数据字典条目包括：数据流、文件、数据项(组成数据流和文件的数据)、加工、源或宿（4）字典条目中的描述内容主要包括：a. DFD元素的基本信息(名称、别名、简述、注解)b. 定义(数据类型、数据组成)c. 使用特点(取值范围、使用频率、激发条件)d. 控制信

18、息(来源、去向、访问权限)等7. 结构化设计方法概述（P91）结构化设计SD是将结构化分析得到的数据流图映射成软件体系结构的一种设计方法，强调模块化、自顶向下逐步求精、信息隐蔽、高内聚低耦合等设计准则，分为概要设计和详细设计两大步骤,SA、SD和SP构成完整的结构化方法体系.(1) 结构图（程序结构图）：描述软件系统的体系结构，由哪些模块组成，以及模块之间的调用关系模块：具有一定功能的可以用模块名调用的一组程序语句，如函数、子程序等。一个模块具有外部特征和内部特征。a. 外部特征包括：模块的接口(模块名、输入/输出参数、返回值等)和模块的功能b. 内部特征包括：模块内部数据和完成其功能的程序代

19、码（2）结构化设计步骤（P96）:a. 建立满足软件需求规约的初始结构图b. 对结构图进行改进c. 书写设计文档d. 设计评审8. 数据流图到软件体系结构的映射(P97)数据流图分为变换型数据流图和事务型数据流图，对应的映射分别称为变换分析和事务分析.信息流：变换流和事务流(1) 数据流图到结构图的映射步骤：a.复审和精化数据流图b.确定数据流图的类型(变换型、事务型)c.将DFD映射成初始结构图：采用变换分析或事务分析技术d.改进初始结构图（2）变换型分析步骤a) 划定输入流和输出流的边界，确定变换中心b) 进行第一级分解：将DFD映射成变换型的程序结构c) 进行第二级分解：将DFD中的加工

20、映射成结构图中的一个适当的模块d) 标注输入输出信息：根据DFD，在初始结构图上标注模块之间传递的输入信息和输出信息(3)事务型分析步骤a) 确定事务中心：事务中心位于数条动作路径的起点，这些动作路径呈幅射状从该点流出.b) 将DFD映射成事务型的结构图c) 分解每条动作路径所对应的结构图第七章 面向对象方法基础1. 面向对象的基本概念（P121）（1）对象：一组属性以及这组属性上的专用操作的封装体。属性（attribute）通常是一些数据，有时它也可以是另一个对象。每个对象都有它自己的属性值，表示该对象的状态。对象中的属性只能通过该对象所提供的操作来存取或修改。操作（operation）（也

21、称方法或服务）规定了对象的行为，表示对象所能提供的服务。封装（encapsulation）是一种信息隐蔽技术，用户只能看见对象封装界面上的信息，对象的内部实现对用户是隐蔽的。封装的目的是使对象的使用者和生产者分离，使对象的定义和实现分开。(2)类：一组具有相同属性和相同操作的对象的集合。一个类中的每个对象都是这个类的一个实例。类是创建对象的模板，从同一个类实例化的每个对象都具有相同的结构和行为。(3)继承类间的基本关系：父类与子类。基于层次关系的不同类共享数据和操作的一种机制。子类中除了定义自己特有的属性和操作外，可以继承其父类（或祖先类）的属性和操作，还可以对父类（或祖先类）中的操作重新定义

22、其实现方法。没有实例的类：抽象类。抽象类中可以定义抽象操作，抽象操作指：只定义这个类的操作接口，不定义它的实现，其实现部分由其子类定义。(4)多态性：同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。动态绑定：在程序运行时才将消息所请求的操作与实现该操作的方法连接起来，是一种在运行时确定被执行代码的技术，根据接收对象的具体情况将请求的操作与实现的方法进行连接。2. 面向对象分析的一般步骤（P124）(1) 获取客户对系统的需求: 标识场景和用况（Use Case），以及建造需求模型(2) 用基本的需求为指南，选择(标识)类和对象(3) 定义类的结构和层次(4) 建造对象关系模

23、型(5) 建造对象行为模型(6) 利用用况/场景来复审分析模型*思考：面向对象分析与结构化分析的异同3. 面向对象分析过程涉及的UML模型:UML用例图：用例建模UML类图：静态建模UML状态机图：动态建模4. 面向对象设计的一般步骤（P126）(1)系统设计 ：a. 将子系统分配到处理器b. 选择实现数据管理、界面支持和任务管理的设计策略，并为系统设计合适的控制机制c. 复审并考虑权衡（折衷）(2)对象设计a. 在过程级别设计每个操作，即设计每个操作的实现细节b. 定义内部类，为类属性设计内部数据结构(3)消息设计 使用对象间的协作和对象-关系模型，设计消息模型(4)复审 复审设计模型并在需

24、要时迭代。5. 面向对象设计模式的分类（P129）（1）创建型模式：工厂方法，抽象工厂，构建器，原型，单件（2）结构型模式：适配器，桥接，组合，装饰器，外观，享元，代理（3）行为型模式：解释器，模板方法，职责链，命令，迭代器，中介者，备忘录，观察者，状态，策略，访问者。6. 统一建模语言UML（1）提出者（2）UML2.0的视图和图主题域视图（view）图（diagram）结构化静态视图类图（class）设计视图内部结构（internal structure）协作图（collaboration）构件图（component）用况视图用况图（use case）动态的状态机视图状态机图（state

25、machine）活动视图活动图（activity）交互视图顺序图（sequence）通信图（communication）物理的部署视图部署图（deployment）模型管理模型管理视图包图（package）a.用况图：展示了各类外部执行者与系统所提供的用况之间的连接。一个用况是系统所提供的一个功能的描述。执行者是指那些可能使用这些用况的人或外部系统。用况图给出了用户所感受到的系统行为，但不描述系统如何实现该功能。用况通常用普通正文描述，也可以用活动图来描述。b.类图：展示了系统中类的静态结构及其相互联系。类之间有多种联系方式:关联（相互连接）;依赖（一个类依赖或使用另一个类）;泛化（一个类是另

26、一个类的特殊情况）.可以把若干个相关的类包装在一起作为一个单元（包）,相当于一个子系统，一个系统可以有多张类图，一个类也可以出现在几张类图中。c.状态机图：通常是对类描述的补充，它说明该类的对象所有可能的状态以及哪些事件将导致状态的改变。状态的改变称为迁移（transition）。一个状态迁移还可以有与之相关的动作，该动作指出状态迁移时应做什么。并不是所有的类都要画状态机图，有些类有一些意义明确的状态，并且其行为受不同的状态所影响和改变，这些类才需要画状态机图。d.活动图：展示了连续的活动流。活动图通常用来描述完成一个操作所需要的活动。还能用于描述其它活动流，如描述用况。活动图由动作状态组成，

27、它包含完成一个动作的活动的规约(即规格说明)。第八章 面向对象建模1. 统一建模语言UML在各个软件开发阶段的应用: a.分析阶段：描述需求b.设计阶段：引入定义软件系统中的技术细节c.实现阶段：模型转换为代码d.测试阶段e.单元测试使用类和类规格说明f.集成测试使用构件图和协作图g.系统测试使用用例图2. 用例建模步骤（P138）a.定义系统并确定执行者b.确定用例c.描述用例：文本或活动图d.定义用例间关系e.确认模型毕业设计管理系统用例图3. 静态建模（P147）a.类-责任-协作者（CRC）技术CRC是一个标准索引卡集合，每张卡片描述一个类类名：协作者：责任：属性和操作描述履行责任所需

28、的其它协作信息（类） CRC建模步骤b.类之间的关系：关联，依赖，泛化，实现等关联的种类主要有二元关联，多元关联，受限关联，聚集（aggregation）和组合（composition） 泛化关系：类之间一般-特殊关系，面向对象继承机制的体系泛化约束集4. 动态建模(P163)a.状态机图:对类描述的补充，说明该类的对象所有可能的状态，以及哪些事件将导致状态的改变.描述了对象的动态行为，是对象生存周期的模型状态由状态名、状态变量和活动三部分组成.状态变量是状态机图所显示的类的属性，也可以是临时变量.活动部分列出了处于该状态时要执行的事件和动作三个标准事件：entry, exit和do.状态迁移

29、的两种原因： a) 当标在迁移箭头上的事件出现时会引起状态的迁移。b) 当状态机图中相应的迁移上未指明事件时，表示当位于迁移箭头源头的状态中的内部动作全部执行完后，该状态迁移被自动触发。 状态机图绘制步骤：1）列出对象具有的所有状态。2）标识导致状态转换的事件。3）为状态和迁移定义状态变量和动作。b.活动图示例泳道根据责任把活动组织到不同的泳道中，它能清楚地表明动作在哪里执行（在哪个对象中），或者表明一个组织的哪部分工作（一个动作）被执行。c.顺序图：描述对象间交互行为，关注于对象间消息的发送和接受。适用于描述实时系统中的时间特性和时间约束。顺序图中对象框下可画一垂直的虚线，称为该对象的生存线

30、（lifeline），用来指出该对象执行期间的时序。消息种类：简单消息、同步与异步消息第十三章 软件测试1. 软件测试的目的:设计合适的测试用例，用尽可能少的测试用例，发现尽可能多的软件错误和缺陷，并加以纠正.a.测试用例由测试输入数据和预期结果组成。b.通过输入数据，运行被测程序，如果与预期不一致，则发现程序中的错误。2. 软件测试用例的设计是软件测试的关键所在3. 测试用例的设计方法：白盒测试和黑盒测试(1) 白盒测试:根据程序内部逻辑结构，检查逻辑路径是否正确工作(2) 黑盒测试:不考虑程序内部逻辑结构和特性;检查程序的功能是否符合需求规格说明书中功能需求4. 白盒测试(P249)主要用

31、于程序模块的测试主要测试方法:逻辑覆盖测试,基本路径测试,数据流测试,循环测试(1)逻辑覆盖测试测试标准:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖示例测试程序:输入x, y和z,返回结果x值 该程序有四条可执行路径 L1: sabcde ，条件a=true且c=true L2: sace ，条件a=false且c=false L3: sacde ，条件a=false且c=true L4: sabce ，条件a=true且c=falsea.语句覆盖选择足够测试用例，使得被测程序的每个可执行语句都至少执行一次只需执行路径L1（sabcde）即可测试数据预期结果x=4,y

32、=2,z=0x=3b. 判定覆盖选择足够测试用例，使得被测程序的每个判定的所有可能结果都至少执行一次，即判定的每个分支至少经过一次方案1：L3（sacde ）和L4（sabce ）方案2：L1（sabcde）和L2（sace ）测试用例测试数据预期结果路径acx=1,y=2,z=1x=2sacdeftx=3,y=3,z=0x=1sabcetf c. 条件覆盖选择足够的测试用例，使得被测程序的每个判定中的每个条件的所有可能结果都至少出现一次示例测试程序所有可能结果判定a：y>1， y 1 ，z=0， z 0。判定c：y=2， y 2 ，x>1（或x>y）， x 1 （或x y）

33、测试用例测试数据预期结果路径覆盖的条件x=1,y=2,z=0x=1.5sabcdey>1， z=0，y=2，x yx=2,y=1,z=1x=3sacdey 1，z 0， y 2 ，x>1d. 基本路径测试根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例流图中由结点和边组成的闭合部分称为一个区域（region）。在计算区域数时，图的外部部分也作为一个区域.c）图所示的流图的区域数为3。独立路径是指程序中至少引进一个新的处理语句序列或一个新条件的任一路径。在流图中，独立路径至少包含一条在定义该路径之前未曾

34、用到过的边。在基本路径测试时，独立路径的数目就是流图的区域数。5. 黑盒测试（P259）依据软件的需求规约，检查程序的功能是否符合需求规约的要求主要方法:等价类划分、边界值分析、比较测试、错误猜测、因果图(1) 等价类划分：将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个代表性的数据作为测试用例把输入数据分为有效输入数据和无效输入数据a. 有效：检验程序是否实现了规格说明中的功能b. 无效：检验程序是否做了规格说明以外的事等价类划分方法设计测试用例的步骤：a.确定等价类:根据软件的规格说明，对每一个输入条件（通常是规格说明中的一句话或一个短语）确定若干个有效等价类和若干个无效

35、等价类。b.利用等价类设计测试用例*设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。*为每个无效等价类设计一个新的测试用例。 （2）边界值分析 边界是指，相对于输入等价类和输出等价类而言，直接在其边界上、或稍高于其边界值、或稍低于其边界值的一些特定情况。专门挑选那些位于边界附近的值（即正好等于、或刚刚大于、或刚刚小于边界值）作为测试用例。6. 测试策略（P267）（1）一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试a.单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误b.集成测试针对集成的软件系统，主要揭

36、露设计阶段产生的错误c.确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的缺陷d.对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误 （2）软件测试的V型模型 （3）单元测试：又称模块测试，它着重对软件设计的最小单元（软件构件或模块）进行验证。单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误单元测试通常采用白盒测试，并且多个构件或模块可以并行进行测试。a. 单元测试内容1）接口：确保模块的输入/输出参数信息是正确的2）局部数据结构：确保临时存储的数据在算法执行的整个过程中都能维持其完

37、整性3）边界条件：确保程序单元在极限或严格的情况下仍能正确地执行4）独立路径：确保模块中的所有语句都至少执行一次5）错误路径处理：单元测试应该对所有的错误处理路径进行测试b. 单元测试过程通常与编码结合，并开发相应的驱动程序和桩程序（4） 集成测试a集成的方法1）非增量式集成：“一步到位”2）增量式集成：自顶向下、自底向上b.策略的优缺点1）自底向上不需要桩模块，容易组织测试，提高效率，但只能测试一部分，对整体性错误发现较晚2 自顶向下能较早地对某些完整功能进行验证，但低层模块用桩模块代替，不能反映真实情况（5） 确认测试:主要采用黑盒测试的方法，以软件需求规约为依据a.软件配置评审 源代码和

38、可执行程序，各类文档，程序内外部的数据b. 测试和测试测试在开发者场所进行，在开发者“指导下”进行测试在一个或多个用户场所进行（6） 系统测试:当软件属于某一更大计算机系统时进行a.恢复测试：强制错误，验证是否正常恢复b.安全保密性测试：保护机制是否能实际保护系统c.压力测试：对非正常情况的承受程度 d.性能测试：在集成系统中的运行性能测试策略1) 把类作为面向对象软件的单元，传统的单元测试等价于面向对象中的类测试，也称类内测试。它包括类内的方法测试和类的行为测试。2) 面向对象中的类间测试（interclass testing）相当于面向对象的集成测试3) 面向对象的确认测试和系统测试策略与

39、传统的确认测试和系统测试策略相同，在面向对象确认测试时，应该利用用况模型，通过用况提供的场景来发现与用户需求不一致的错误7. 面向对象测试用例的设计(1) 类内测试a.测试类中的每个操作（相当于传统软件中的函数或子程序），通常采用白盒测试方法，如逻辑覆盖、基本路径覆盖、数据流测试、循环测试等b.测试类的行为（通常用状态机图来描述），利用状态机图进行类测试时，可考虑覆盖所有状态、所有状态迁移等覆盖标准，也可考虑从初始状态到终止状态的所有迁移路径的覆盖(2)类间测试类间测试主要测试类之间的交互和协作。在UML中通常用顺序图和通信图来描述对象之间的交互和协作。可以根据顺序图或通信图，设计作为测试用例

40、的消息序列，来检查对象之间的协作是否正常。(3)基于场景的测试场景是用况的实例，它反映了用户对系统功能的一种使用过程，基于场景的测试主要用于确认测试，在类间测试时也可根据描述对象间的交互场景来设计测试用例8. 调试主要方法a.蛮力法：程序中设置断点b.回溯法:从错误的征兆出发，人工沿着控制流程往回跟踪，直至发现错误的根源c.原因排除法:分为归纳法和演绎法第十五章 软件维护1. 覆盖了从软件交付使用到软件被淘汰为止的整个时期2. 为了改正错误或满足新的需要而修改软件的过程3. 必须在现有系统的限定和约束条件下实施4. 根据起因不同，软件维护可以分为纠错性维护、适应性维护、改善性维护和预防性维护四

41、类1. 软件可维护性:指理解、改正、调整和改进软件的难易程度(P302)主要影响因素:a.可理解性（understandability）b.可测试性（testability）c.可修改性（modifiability）d.可移植性（portability）2. 提高可维护性方法(P304):a.确定质量管理目标和优先级b.规范化程序设计风格c.选择可维护性高的程序设计语言改进程序文档d.改进程序文档e.保证软件质量审查方法第十六章 软件项目管理1. 软件项目管理概述a. 项目成功的标志1) 在规定的时间内完成项目,成本控制在预算之内2) 功能特性达到客户所要求的水平（质量过关）3) 项目通过客户或用户的验收4) 项目范围变化是最小的或可控的5) 没有干扰或严重影响整个组织的其它工作流程b. 软件项目管理的特点6) 软件项目是设计型项目7) 存在各种软件开发过程模型8) 需求变化频繁难以估算工作量9) 主要的成本是人力成本，以人为本的管理c. (软件)项目管理的基本内