软件工程复习

软件工程

期末复习本复习提纲仅供复习参考,如果在复习过程中有不够透彻的地方,请参见完整的授课PPT题型分布题型题数分值总计单项选择题20题1分/题20分判断题10题1分/题10分简答题8题5分/题40分应用题3题10分/题30分第一章概述

主要内容：软件？软件的特点？软件的分类？计算机软件的发展软件危机？表现？原因？克服的方法？软件工程？七条基本原理？软件过程？软件的生命周期？软件过程模型？软件开发方法软件工具与软件开发环境1.1软件定义:软件==程序+数据+文档

1.数据：程序加工处理的对象。包括数据的表示、组织与存储。数据==初始化数据+测试数据2.文档（document）：开发、使用和维护程序所需的图文资料。文档==开发文档+管理文档。3.程序（program）

：能完成预定功能和性能的指令集合。4.软件和程序的区别程序只是完整软件产品的一部分。编写程序只是软件开发过程数据中的一个阶段，一般来说，其工作量仅仅是软件开发全部工作量的10％－20％1.1软件软件的特点抽象性：逻辑实体。可记录。但看不到（Intangible），开发过程可视化程度低，开发结果难以直观表示。可复制性：与开发成本相比，复制成本很低无折旧受硬件制约未完全摆脱手工工艺开发费用高1.1软件软件分类1、按适用范围分：定制软件（CustomSoftware）项目软件通用软件（GenericSoftware）产品软件。2、按软件功能分：系统软件;应用软件;支撑软件3、按软件体系结构分桌面软件;布式软件;并行软件4、按规模分：(1)小型软件(1--5人年)；(2)中型软件(5--50人年)(3)大型软件(50人年以上)。5、按工作方式分：

(1)实时软件；(2)分时软件；(3)交互式软件；

(4)批处理软件；(5)嵌入式软件（EmbeddedSoftware）。1.1软件计算机软件发展的三个时期1.早期时代（60年代中期之前）程序设计阶段硬件通用，软件专用；程序规模小，编写者和使用者为同一人（同组人）。2.第二代（60年代中期-70年代中期）程序系统阶段出现“软件作坊”、产品软件；“个体化”开发方法。3.第三代（70年代中期之后）软件工程阶段软件开发成为一门新兴的工程学科——软件工程。一、软件危机的产生20世纪60年代中期以后，一些开发大型软件系统的要求提了出来。然而软件技术的进步一直未能满足形势发展的需要，在大型软件的开发过程中出现了复杂程度高、研制周期长、正确性难以保证的三大难题。遇到的问题找不到解决办法，致使问题堆积起来，形成了人们难以控制的局面，出现了所谓的“软件危机”。1.2软件危机（Softwarecrisis）1.2软件危机二、软件危机的定义软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。主要是两个问题:1.如何开发软件，怎样满足对软件的日益增长的需求。2.如何维护数量不断膨胀的已有软件1.2软件危机三、软件危机的主要表现1.对软件开发成本和进度的估计不准确,甚至开发过程就夭折2.不满足需求,用户不满意的现象经常发生3.软件质量不高、可靠性差4.缺乏适当的文档资料,软件常常不可维护、错误难以改正。5.软件成本占系统总成本的比例逐年上升6.软件开发速度跟不上计算机发展速度，软件生产率低，不能满足需要。1.2软件危机四、产生软件危机的原因与软件本身的特点有关,软件是逻辑产品，开发进度、成本难以估计缺乏或不完整、不一致的文档给维护带来困难用户对软件需求的描述往往不够精确，有遗漏，有二义软件开发人员对需求的理解与用户的本来愿望有差异,在软件开发过程中，或多或少地采用了错误的方法和技术。对用户需求没有完整准确的认识，就匆忙着手编写程序。大型软件项目需多人协同完成，缺乏管理经验缺乏有力的方法学和工具的支持软件项目的特殊性和人类智力的局限性1.2软件危机五、解决软件危机的途径1.技术措施消除错误的概念和做法使用更好的软件开发方法和开发工具2.组织管理措施软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。1.3软件工程

一、什么是软件工程软件工程（SoftwareEngineering)是在克服60年代末所出现的“软件危机”的过程中逐渐形成与发展的。软件工程是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。二、软件工程的目标1.3软件工程

软件工程的目标是在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并满足用户需求的软件产品。15软件工程的发展已经历了四个重要阶段：4.第四代软件工程

—

构件工程3.第三代软件工程

—

过程工程2.第二代软件工程

—

对象工程1.第一代软件工程

—

传统的软件工程三、软件工程的发展1.3软件工程四、软件工程研究的范畴软件开发技术：软件开发方法、软件开发过程、工具及环境。软件管理技术：包括计划、组织、控制、领导和激励等。1.3软件工程软件工程三要素：方法、工具和过程1.3软件工程关注大型程序的构造中心课题是控制软件固有的复杂性应对需求变更提高软件开发和维护的效率提倡有纪律的过程最终目的是使客户满意难点是对问题域的认识和描述五、软件工程的本质特性六、软件工程的7条基本原理用分阶段的生命周期计划严格管理2.坚持进行阶段评审3.实行严格的产品控制4.采用现代程序设计技术5.结果应能清楚地审查6.开发小组的人员应该少而精7.承认不断改进软件工程实践的必要性一、软件生存周期1.4软件过程与软件生存期软件的生存周期(SoftwareLifeCycle):软件产品或软件系统从设计、投入使用到被淘汰的全过程。软件生存周期一般分为：软件定义（问题定义、可行性研究、需求分析）、软件开发（总体设计、详细设计、编码和单元测试、综合测试）、软件维护等三个时期。软件生存周期(各阶段的工作小结)1.4软件过程与软件生存期阶段关键问题结束标准问题定义问题是什么？关于规模和目标的报告书可行性研究有可行的解吗？系统的高层逻辑模型：系统流程图、数据流图、成本／效益分析需求分析系统必须做什么？系统的逻辑模型：数据流图、数据字典、算法描述总体设计概括地说，应该如何解决这个问题？推荐的系统结构：层次图或结构图详细设计怎样具体地实现这个系统？编码规格说明：HIPO图或PDL编码/单元测试正确的程序模块源程序清单；单元测试方案和结果综合测试符合要求的软件综合测试方案和结果；完整一致的软件配置维护持久地满足用户需要的软件完整准确的维护记录二、软件过程（Softwareprocess）软件过程：是软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合。它规定了完成各项任务的步骤。软件过程有三层含义：个体含义，即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程，软件管理过程等；整体含义，即指软件产品或系统在所有上述含义下的软件过程的总体；工程含义，即指解决软件过程的工程，它应用软件工程的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及在用户环境下的运作，以此进一步提高软件生产率，降低成本。1.4软件过程与软件生存期ISO/IEC12207软件生存周期过程ISO/IEC12207标准把软件生存周期中可以开展的活动分为5个基本过程，8个支持过程和4个组织过程。每一个过程划分为一组活动，每项活动进一步划分为一组任务。能力成熟度模型CMMCMM（CapabilityMaturityModel）即能力成熟度模型，用于评价软件机构的软件过程能力成熟度的模型。CMM提供了一个成熟度等级框架：1级-初始级、2级-可重复级、3级-已定义级、4级-已管理级和5级-优化级。CMMI能力成熟度模型集成模型为每个学科的组合都提供两种表示法： 阶段式模型和连续式模型5.优化级4.已管理级3.已定义级2.可重复级1.初始级标准、一致的过程有纪律的过程可预测的过程持续改进的过程CMM软件过程成熟度的5个等级1.5软件开发模型

(SoftwareDevelopmentModel)软件开发模型是描述软件开发过程中各种活动如何执行的模型。因此又称为软件过程模型或软件生存周期模型。典型的软件过程模型有：瀑布模型（waterfallmodel）演化模型（evolutionarymodel）增量模型（incrementalmodel）原型模型（prototypingmodel)螺旋模型（spiralmodel）喷泉模型（waterfountainmodel）基于构件的开发模型（component-baseddevelopmentmodel）形式方法模型（formalmethodsmodel）问题定义编程需求分析设计可行性研究运行与维护测试开发时期运行时期计划时期(目标与范围说明书)(可行性论证论告)(维护报告)(测试报告)(程序)(设计文档)(需求说明书)瀑布模型螺旋模型图原型化模型快速分析或修改评价构造运行常见软件开发模型分析系统设计软件设计实现喷泉模型1.5软件开发方法

软件开发的目标是要在规定的投资和时间内，开发出符合用户的需求，高质量的软件，为此需要有成功的开发方法。软件开发方法可分为两大类：面向过程的开发方法

结构化开发方法 面向数据结构的开发方法 原型化开发方法面向对象的开发方法

1.6软件开发工具与环境

在软件工程活动中，软件工程师和管理员按照软件工程的方法和原则，借助于计算机及其软件工具的帮助，开发、维护、管理软件产品的过程，称为计算机辅助软件工程（CASE,ComputerAidedSoftwareEngineering）。

为支持软件开发、维护、管理而研制的计算机程序系统称为软件工具。

软件工具种类繁多，涉及面广，如编辑、编译、正文格式处理,静态分析、动态跟踪、需求分析、设计分析、测试、模拟和图形交互等。主要内容1.基于计算机的系统2.系统工程的任务3.可行性分析4.成本/效益分析第二章系统工程

所谓基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程（Procedure）1.基于计算机的系统2.系统工程的任务(1)识别用户的要求(2)系统建模和模拟(3)成本估算及进度安排(4)可行性分析(5)生成系统规格说明开发一个基于计算机的系统通常都受到资源（人力、财力、设备等）和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。3.1可行性研究的含义3.2可行性研究的目的3.3可行性研究的任务3.4可行性研究的步骤3.可行性分析(研究)一、可行性研究-含义可行性研究又称为可行性分析，可行性分析的对象是系统目标。评价总体方案（系统目标）的可能性、必要性。可行性研究的含义，就是按照各种有效的方法和工作程序，对拟建工程项目在技术上的先进性、适用性，经济上的合理性、盈利性，以及项目的实施等方面进行深入的系统分析。注：不要花过多精力，占总成本的510%。二、可行性研究-目的可行性研究的目的:要用最小的代价在最短的时间内确定该项目是否值得去解决，是否存在可行的解决方案。可行性研究的主要内容有：技术上可行经济上可行社会上可行可行性报告可行性报告可行性报告可行性报告可行性分析的结果报告操作上可行三、可行性研究--任务可行性研究的任务:1）技术可行性研究2）经济可行性研究3）操作可行性研究4)社会、政策允许的可行性5)开发方案的选择四、可行性研究-步骤(一)、系统流程图(SFD)进行可行性分析时，通常用系统流程图来描述所要开发的系统。系统流程图实质上是物理数据流图，它描绘组成系统的主要物理元素以及信息在这些元素间流动和处理的情况。(二)、数据流图(DFD)也可以用数据流图(DFD)

来对系统进行描述。通常数据字典和数据流图共同构成系统的逻辑模型。五、可行性分析的描述手段(一)影响成本估算的因素1、软件人员的业务水平

软件人员的素质、经验、掌握知识的不同，在工作中表现出很大的差异。2、开发所需时间显然，开发时间越长成本越高。3、软件开发技术水平指开发方法、工具、语言等，技术水平越高，效率越高。4、软件可靠性要求一般可靠性要求愈高，成本愈高。5、软件产品的规模及复杂度规模：按YOURDON分类法将软件产品的规模分为微型，小型，中型，大型，超大型，极大型。复杂性：应用程序，实用程序，系统程序分别由低到高排列。4.成本/效益分析（二）软件成本估计技术常用的估算方法：基于已经完成的类似项目进行估算，这是一种常用的也是有效的估算方法基于分解技术进行估算问题分解是将一个复杂问题分解成若干个小问题，通过对小问题的估算得到复杂问题的估算过程分解指先根据软件开发过程中的活动(分析、设计、编码、测试等)进行估算，然后得到整个项目的估算值。基于经验估算模型的估算。典型的经验估算模型有IBM估算模型、CoCoMo模型和Putnam模型。1．货币的时间价值2．投资回收期3．纯收入4．投资回收率（三）效益度量的方法内容摘要1.什么是需求工程2.什么是软件需求工程？3.软件需求的重要性4.软件需求的困难5.软件需求内容6.需求工程的活动第三章

软件需求工程需求工程(RE)的概念是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。需求工程RE可分为:系统需求工程（如果是针对由软硬件共同组成的整个系统）软件需求工程（如果仅是专门针对纯软件部分）。1.什么是需求工程2.什么是软件需求工程软件需求——是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。软件需求工程——是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。

需求的重要性FrederickBrooks在他1987年经典文章“NoSilverBullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

3.软件需求的重要性4.软件需求的困难软件需求是软件工程中最复杂的过程之一：应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。非功能性需求建模技术的缺乏及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。沟通上的困难，由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。软件需求用户需求系统需求功能需求非功能需求领域需求由客户管理员、用户等提出软件需求的内容5.软件需求内容

需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。6.需求工程的活动481．必须能够表示和理解问题的信息域2．必须能够定义软件将完成的功能3．必须能够表示软件的行为(作为外部事件的结果)4．必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节5．分析过程应该从要素信息移向细节信息需求分析操作性原则常用的需求分析方法：功能分解方法面向数据流的结构化分析方法(SA)面向数据结构的分析方法信息建模法面向对象的分析方法(OOA)需求工程小结软件需求工程,是软件开发人员与用户密切配合，充分交换意见，获得对需求一致意见的过程。在开发者一方，参与工作的主要角色是系统分析员和系统工程师等，负责沟通用户和开发人员的认识和见解，起着桥梁作用。需求工程阶段的最终任务是要完成目标系统的需求规格说明，确定系统的功能、非功能需求和性能，为后阶段的开发打下基础。本阶段常用的有SA法，原型法，OOA法等。第4章

设计工程主要内容软件设计工程概述软件设计原则软件体系结构设计部件级设计技术设计规约与设计评审要求：（1）识记：设计阶段划分,设计的任务、目标,过程及准则,设计描述方法。（2）领会：有关指标,常见的软件体系结构,在部件级设计阶段，部件的执行过程常用的描述方式软件设计分为总体设计和详细设计两个阶段。其工作流程可用下图表示：总体设计需求说明书复审软件结构修改详细设计可接受模块描述复审修改设计说明书1、设计阶段结束要交付的文档是设计说明书，根据设计方法的不同，有不同的设计文档。2、每个设计步骤完成后，都应进行复审。

常用的设计方法有：SD法、Jackson法、OOD法、HIPO法、Parnas法、Warnier法等。软件设计阶段1.软件设计阶段的任务：将分析阶段获得的需求说明转换为计算机中可实现的系统,完成系统的结构设计，包括数据结构和程序结构，最后得到软件设计说明书。软件设计阶段要解决“如何做”的问题。过程设计）软件结构数据结构界面设计软件设计4.1软件设计工程概述2.软件设计的目标就是构造一个高内聚低耦合的软件模型。提高可靠性；提高可维护性；提高可理解性；提高效率。软件设计高可靠性高可维护性高可理解性高效率软件设计的目标3.软件设计的过程选取合理的系统体系结构推荐最佳方案、技术选型划分模块，确定软件结构数据结构和算法设计设计用户界面编写文档审查和复查1、抽象化与逐步求精2、模块化准则3、信息隐蔽准则4、模块独立性准则4.2软件设计准则①深度：表示软件结构中从顶层模块到最底层模块的层数；②宽度：表示控制的总分布；③扇出数：指一个模块直接控制下属的模块个数；④扇入数：指一个模块的直接上属模块个数。

一个好的软件结构的形态准则是：顶部宽度小，中部宽度最大，底部宽度次之；在结构顶部有较高的扇出数，在底部有较高的扇入数。有关指标

耦合性

用于描述模块之间联系的紧密程度。内聚性

用于描述模块内部联系的紧密程度。软件独立性的度量标准是两个定性指标：耦合性的几种类型内容耦合公共耦合外部耦合控制耦合标记耦合高耦合性低偶然型逻辑型时间型过程型通信型低内聚性高信息型内聚性的几种类型数据耦合无直接耦合独立性强弱独立性强弱功能型耦合、内聚与模块独立性关系内聚与耦合密切相关，强耦合的模块意味者弱内聚，强内聚模块意味着与其它模块间松散耦合.耦合与内聚都是模块独立性的定性标准，都反映模块独立性的良好程度。但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。4.3软件体系结构设计常见的软件体系结构单主机结构C/S（Client/Server）结构B/S（Browser/Server）结构4.4部件级设计技术在部件级设计阶段，主要完成如下工作：为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程性描述；确定每一部件内部使用的数据结构；在部件级设计结束时，应该把上述结果写入部件级设计说明书，并且通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据。4.4部件级设计技术

在部件级设计阶段，对部件的执行过程,常用的描述方式一般有3种:图形描述程序流程图结构化流程图（N-S图）PAD图—问题分析图语言描述(PDL（ProgramDesignLanguage）)表格描述(判定表)小结一般认为，软件开发阶段由设计、编码和测试三个基本活动组成，其中“设计”活动是获取高质量、低耗费、易维护软件的一个最重要环节。设计过程示意图

第5章结构化分析与设计

内容摘要结构化分析方法概述数据流图分层数据流图的审查数据字典描述基本加工的小说明结构化设计概述数据流图到软件体系结构的映射初始结构图的改进小结结构化分析方法概述结构化分析过程理解当前的现实环境，获得当前系统的具体模型(物理模型)从当前系统的具体模型抽象出当前系统的逻辑模型分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型为目标系统的逻辑模型作补充当前系统具体模型建立当前系统逻辑模型抽象目标系统逻辑模型建立完善的系统逻辑模型改进深入调查研究分析用户需求,用DFD图描述分析系统需求,用DFD图描述修改完善DFD图,增添功能结构化分析模型的描述数据字典是模型的核心，它包含了软件使用和产生所有数据的描述数据流图：用于功能建模，描述系统的输入数据流如何经过一系列的加工变换逐步变换成系统的输出数据流实体—关系图：用于数据建模，描述数据字典中数据之间的关系状态转换图：用于行为建模，描述系统接收哪些外部事件，以及在外部事件的作用下的状态迁移情况实体-关系图数据流图状态转换图控制规约数据字典加工规约数据对象描述数据流图DataFlowDiagram(简称DFD)：描述输入数据流到输出数据流的变换(即加工)过程，用于对系统的功能建模，基本元素包括：数据流(dataflow)加工(process)：文件(file)：源或宿(sourceorsink)数据流名图a1.2.1加工名图b实体名图d文件名图c数据流数据流的流向从一个加工流向另一个加工从加工流向文件(写文件)从文件流向加工(读文件)从源流向加工从加工流向宿数据流名图a加工每个加工用一个定义明确的名字标识至少有一个输入数据流和一个输出流可以有多个输入数据流和多个输出数据流加工（图b）：描述输入数据流到输出数据流的变换,也称为数据处理，它对数据流进行某些操作或变换。每个加工也要有名字，通常是动词短语，简明地描述完成什么加工。在分层的数据流图中，加工还应有编号。1.2.1加工名图b文件文件(数据存储（图c）)：指保存数据信息的外部单元，它可以是数据库文件或任何形式的数据组织。流向数据存储的数据流可理解为写入文件，或查询文件，从数据存储流出的数据可理解为从文件读数据或得到查询结果。每个文件用一个定义明确的名字标识由加工进行读写DFD中称为文件，但在具体实现时可以用文件系统实现也可以用数据库系统等实现文件名图c图和加工的编号顶层图只有一个代表整个软件系统的加工，该加工不必编号。0层图中的加工编号分别为1，2，3，…子图号：若父图中的加工号x分解成某一子图，则该子图号记为“图x”子图中加工的编号：若父图中的加工号为x的加工分解成某一子图，则该子图中的加工编号分别为x.1、x.2、x.3…X1321.11.21.41.32.12.21.1.11.1.22.1.32.1.22.1.12.2.22.2.32.2.1顶层中间层底层0图1图2图1.1图2.1图2.2图分层DFD图画分层数据流图的步骤1．画系统的输入和输出2．画系统内部3．画加工内部4．重复第3步，直至每个尚未分解的加工都足够简单(即不必再分解)内容摘要结构化分析方法概述数据流图分层数据流图的审查数据字典描述基本加工的小说明结构化设计概述数据流图到软件体系结构的映射初始结构图的改进小结分层数据流图的审查检查图中是否存在错误或不合理(不理想)的部分一致性：分层DFD中不存在矛盾和冲突完整性：分层DFD本身的完整性，即是否有遗漏的数据流、加工等元素分层数据流图的一致性父图与子图平衡任何一张DFD子图边界上的输入/输出数据流必须与其父图中对应的加工的输入/输出数据流保持一致数据守恒一个加工所有输出数据流中的数据，必须能从该加工的输入数据流中直接获得，或者能通过该加工的处理而产生多余的数据流：加工未使用其输入数据流中的某些数据项局部文件一个加工的输出数据流不能与该加工的输入数据流同名分层数据流图的完整性每个加工至少有一个输入数据流和一个输出数据流在整套分层数据流中，每个文件应至少有一个加工读该文件，有另一个加工写该文件分层数据流图中的每个数据流和文件都必须命名(除了流入或流出文件的数据流)，并保持与数据字典的一致分层DFD中的每个基本加工(即不再分解子图的加工)都应有一个加工规约其它需注意的问题适当命名画数据流而不是画控制流避免一个加工有过多的数据流分解尽可能均匀先考虑稳定状态，忽略琐碎的枝节随时准备重画分解的程度可参照以下几条与分解有关的原则：

7加减2分解应自然，概念上合理、清晰只要不影响DFD的易理解性，可适当多分解几个加工，以减少层数一般说来，上层分解得快些(即多分解几个加工)，下层分解得慢些(即少分解几个加工)数据字典数据流图与数据字典是密不可分的,数据字典由字典条目组成，每个条目描述DFD中的一个元素数据字典条目包括：数据流文件数据项(组成数据流和文件的数据)加工源或宿基本加工的小说明小说明是基本加工的规约说明，应精确地描述用户要求一个加工“做什么”包括加工的激发条件、加工逻辑、优先级、执行频率、出错处理等最基本的部分是加工逻辑，即该加工的输出数据流与输入数据流之间的逻辑关系加工逻辑不是对加工的设计，不涉及数据结构、算法实现、编程语言等与设计和实现有关的细节加工逻辑的描述方法结构化语言：介于自然语言和形式语言之间的一种半形式语言判定表：适用于加工逻辑包含多个条件，而不同的条件组合需做不同的动作判定树：判定表的变种，它本质上与判定表是相同的，只是表示形式不同内容摘要结构化分析方法概述数据流图分层数据流图的审查数据字典描述基本加工的小说明结构化设计概述数据流图到软件体系结构的映射初始结构图的改进小结结构化设计结构化设计(StructuredDesign，简称SD)是将结构化分析得到的数据流图映射成软件体系结构的一种设计方法强调模块化、自顶向下逐步求精、信息隐蔽、高内聚低耦合等设计准则分为概要设计和详细设计两大步骤概要设计是对软件系统的总体设计，采用结构化设计方法，其任务是：将系统分解成模块，确定每个模块的功能、接口(模块间传递的数据)及其调用关系，并用模块及其对模块的调用来构建软件的体系结构详细设计是对模块实现细节的设计，对模块图中每个模块的过程进行描述，常用的描述的方式有：伪代码，流程图，N-S图，PAD图等。将分析模型转换为软件设计数据字典数据流图E-R图状态变迁图加工规约控制规约数据对描述象数据设计体系结构设计接口设计过程设计分析模型设计模型结构化设计方法结构图用结构图(StructureChart)来描述软件系统的体系结构描述一个软件系统由哪些模块组成，以及模块之间的调用关系结构图的基本成分有：模块、调用和数据OQNRUVaa,cbccda,da,dMSffjPTSWghi启发式设计策略按照模块化设计原则，相应的启发式设计策略如下：改造程序结构图，降低耦合度，提高内聚度避免高扇出，并随着深度的增加，力求高扇入避免“平铺”形态，较好的结构图形态是“椭圆”型模块的影响范围应限制在该模块的控制范围内降低模块接口的复杂程度和冗余程度，提高一致性模块的功能应是可预测的，避免对模块施加过多的限制尽可能设计单入口和单出口的模块结构化设计的步骤建立初始结构图对结构图进行改进可根据设计准则和启发式设计策略对初始结构图进行改进书写设计文档设计评审内容摘要结构化分析方法概述数据流图分层数据流图的审查数据字典描述基本加工的小说明结构化设计概述数据流图到软件体系结构的映射初始结构图的改进小结将数据流图分为变换型数据流图和事务型数据流图，对应的映射分别称为变换分析和事务分析数据流图映射到结构图的步骤复审和精化数据流图确定数据流图的类型(变换型、事务型)将DFD映射成初始结构图：采用变换分析或事务分析技术，将DFD映射成初始结构图改进初始结构图数据流图到软件体系结构的映射变换分析步骤划定输入流和输出流的边界，确定变换中心进行第一级分解：将DFD映射成变换型的程序结构进行第二级分解：将DFD中的加工映射成结构图中的一个适当的模块标注输入输出信息：根据DFD，在初始结构图上标注模块之间传递的输入信息和输出信息事务分析的步骤确定事务中心：事务中心位于数条动作路径的起点，这些动作路径呈幅射状从该点流出。将DFD映射成事务型的结构图分解每条动作路径所对应的结构图接收模块的分解：从事务中心开始，沿着输入路径向外移动，把输入路径上的每个加工映射成结构图中受接收模块控制的一个低层模块动作路径控制模块的分解：首先确定每条动作路径的流类型(变换流或事务流)，然后，运用变换分析或事务分析，将每条动作路径映射成与其流特性相对应的以动作路径控制模块为根模块的结构图动作路径1控制模块发送模块动作路径n控制模块动作路径2控制模块┄接收模块主控模块分层DFD的映射0层图反映了系统由哪些子系统组成，此时可先将0层图映射成下图中的结构0层图每个加工的DFD子图可映射成以相应模块为根模块的结构子图如果DFD子图中的加工还可分解成一张子图，则再将其映射成以相应模块为根模块的结构子图依次一层一层分解下去得到最终的初始结构图如果初始结构图太大，我们也可以将它组织成分层的结构图子系统1系统子系统n子系统2┄内容摘要结构化分析方法概述数据流图分层数据流图的审查数据字典描述基本加工的小说明结构化设计概述数据流图到软件体系结构的映射初始结构图的改进小结初始结构图的改进对结构图改进的依据就是观察这种改进是否符合软件设计的准则和启发式设计策略因此结构图的改进没有明显的步骤，也很难定义终止条件,设计改进往往伴随着折衷结构图改进技巧减少模块间的耦合度消除重复功能消除“管道”模块模块的大小适中避免高扇出应尽可能研究整张结构图，而不是只考虑其中的一部分高扇出时重新分解(a)高扇出(b)重新分解小结结构化方法是一种传统的面向数据流开发方法,以数据流为中心构建软件的分析模型和设计模型在结构化分析方面，本章介绍结构化分析的基本思想和分析过程，详细介绍了分层数据流图的画法，分层数据流图的审查，数据字典各条目的描述内容以及基本加工小说明的描述方法在结构化设计方面，本章介绍如何将分析的结果(DFD)映射成初始的程序结构图，包括变换分析和事务分析，并介绍对初始结构图的优化软件工程第6章面向数据结构的分析与设计面向数据结构的需求分析与设计典型方法有Jackson方法和Warnier方法（1）Jackson方法1975年,M.A.Jackson-提出了一类软件开发方法。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。Jackson方法有时也称为面向数据结构的软件设计方法。（2）Warnier方法1974年，J.D.Warnier提出的软件开发方法与Jackson方法类似。差别有三点：一是它们使用的图形工具不同，分别使用Warnier图和Jackson图；另一个差别是使用的伪码不同；最主要的差别是在构造程序框架时，Warnier方法仅考虑输入数据结构，而Jackson方法不仅考虑输入数据结构，而且还考虑输出数据结构。面向数据结构的需求分析与设计主要特点：以信息对象及其操作为核心进行需求分析认为复合信息对象具有层次结构，并且可按顺序、选择、重复三种结构分解为成员信息对象提供由层次信息结构映射为程序结构的机制，从而为软件设计奠定良好的基础面向数据结构的需求分析与设计JACKSON方法的构成JSP（JacksonstructuredProgramming)Jackson结构程序设计方法JSD(JacksonSystemDevelopment)Jackson系统开发方法。JSP方法的特点简单、易学、形象直观、可读性好便于表示层次结构适用于小型数据处理系统第7章面向对象的分析和设计

内容摘要面向对象的基本概念面向对象的分析和设计过程UML概述用况建模静态建模动态建模物理体系结构建模PeterCoad和EdwardYourdon提出用下列等式识认面向对象方法：面向对象

=对象（object）

+分类（classification）

+继承（inheritance）

+通过消息的通信（communicationwithmessages）可以说，采用这四个概念开发的软件系统是面向对象的传统软件开发方法存在的问题1.传统软件开发方法无法实现从问题空间到解空间的直接映射。问题空间(现实世界)解空间(软件系统)复杂映射2.传统软件开发方法无法实现高效的软件复用。原因是：传统软件开发方法数据与代码（操作）分离。3.传统软件开发方法难以实现从分析到设计的直接过渡。复杂转换分析文档（DFD）设计文档(SC)面向对象方法的出现很快受到计算机软件界的青睐，并成为20世纪90年代的主流开发方法。我们可以从下列几个方面来分析其原因：从认知学的角度来看，面向对象方法符合人们对客观世界的认识规律。面向对象方法开发的软件系统易于维护，其体系结构易于理解、扩充和修改。面向对象方法中的继承机制有力支持软件的复用。内容摘要面向对象的基本概念面向对象的分析和设计过程UML概述用况建模静态建模动态建模物理体系结构建模面向对象分析

Object-OrientedAnalysis

面向对象分析的一般步骤如下：获取客户对系统的需求：包括标识场景（scenario）和用况（usecase，也称用例），以及建造需求模型用基本的需求为指南，来选择类和对象（包括属性和操作）。定义类的结构和层次。建造对象—关系模型。建造对象—行为模型。利用用况/场景来复审分析模型。面向对象设计面向对象设计的一般步骤如下：系统设计将子系统分配到处理器；选择实现数据管理、界面支持和任务管理的设计策略；为系统设计合适的控制机制；复审并考虑权衡（折衷）对象设计在过程级别（procedurallavel）设计每个操作，即设计每个操作的实现细节定义内部类为类属性设计内部数据结构消息设计使用对象间的协作和对象--关系模型，设计消息模型复审复审设计模型并在需要时迭代。典型的面向对象方法Coad&Yourdon方法OMT方法（JamesRumbaugh创立的ObjectModelTechnology）Booch方法OOSE方法(Jacobson创立的)内容摘要面向对象的基本概念面向对象的分析和设计过程UML概述用况建模静态建模动态建模物理体系结构建模UML概述为何研究UML统一建模语言（UnifiedModelingLanguage）—结束方法大战模型元素模型元素指模型中的实体以及实体间相互连接的关系部分模型元素注解类属性操作对象：类属性操作状态用况

结点供应接口包依赖关联泛化主动类属性操作请求接口构件实现视图与图主题域视图（view）图（diagram）结构化静态视图类图（class）设计视图内部结构（internalstructure）协作图（collaboration）构件图（component）用况视图用况图（usecase）动态的状态机视图状态机图（statemachine）活动视图活动图（activity）交互视图顺序图（sequence）通信图（communication）物理的部署视图部署图（deployment）模型管理模型管理视图包图（package）内容摘要面向对象的基本概念面向对象的分析和设计过程UML概述用况建模静态建模动态建模物理体系结构建模用况建模用况建模是功能建模，用用况图来描述。一个用况模型可由若干幅用况图组成。每个用况指明了一个完整的功能。一幅用况图包含的模型元素有系统、执行者、用况，以及表示它们间的不同关系，如关联、扩展、包含、泛化等。用况图展示了各类外部执行者与系统所提供的用况之间的连接。一个用况是系统所提供的一个功能（也可以说是系统提供的某一特定用法）的描述，执行者是指那些可能使用这些用况的人或外部系统，执行者与用况的连接表示该执行者使用了那个用况。用况图给出了用户所感受到的系统行为，但不描述系统如何实现该功能。用况通常用普通正文描述，也可以用活动图来描述。用况图电话订购系统用况图TelephoneCatalogCustomerSalespersonnShippingClerksupervisorestablishcreditFillorderArrangePaymentSupplyCustomerDataorderproductArrangeCreditPaycashplaceorderRequestCatalog《include》《include》《include》《extend》checkstatus用况建模步骤创建用况模型的步骤包括：1．定义系统2．确定执行者3．确定用况4．描述用况5．定义用况间的关系，6．确认模型内容摘要面向对象的基本概念面向对象的分析和设计过程UML概述用况建模静态建模动态建模物理体系结构建模静态建模（类和对象建模）

类和对象模型的基本模型元素有类、对象以及它们之间的关系。系统中的类和对象模型描述了系统的静态结构，在UML中用类图和对象图来表示。类图由系统中使用的类以及它们之间的关系组成。类之间的关系有关联、依赖、泛化、实现等。类图是一种静态模型，它是其它图的基础。一个系统可以有多张类图，一个类也可出现在几张类图中。对象图是类图的一个实例，它描述某一时刻类图中类的特定实例以及这些实例之间的特定链接。确定类1.标识类

（1）标识潜在的对象类 （2）筛选对象类，确定最终对象类2.标识责任

（1）标识属性 （2）定义操作3.标识协作者4.复审CRC卡类名：

协作者：

责任：

内容摘要面向对象的基本概念面向对象的分析和设计过程UML概述用况建模静态建模动态建模物理体系结构建模动态建模

动态建模用来描述系统的动态行为，显示对象在系统运行期间不同时刻的动态交互。UML中用状态机图、活动图、顺序图、通信图来建立动态模型。面向对象建模是软件工程中最重要的技术之一，UML已成为面向对象建模事实上的标准。标准建模语言UML定义良好、易于表达、功能强大,不仅支持面向对象的分析与设计,而且支持从需求分析开始的软件开发的全过程。小结第11章人机界面设计内容摘要人的因素人机界面风格人机界面分析与建模界面设计活动实现工具设计评估人的因素人的因素主要包括:人对感知过程的认识用户的技能和行为方式人体测量学对设计的影响语言界面图形用户界面直接操纵用户界面多媒体用户界面多通道用户界面人机界面风格人机界面分析与建模1.人机界面设计过程用户、任务和环境分析及建模界面设计界面构造界面确认2.人机界面设计中涉及的模型软件工程师创建的设计模型（designmodel）人机工程师创建的用户模型（usermodel）终端用户在脑海里对界面产生的映象，称为用户的模型（user´smodel）或系统感觉（systemperception）系统实现者创建的系统映象（systemimage）3.任务分析的途径与方法采用逐步精化的方法和面向对象的方法,剖析原有应用系统,分析系统需求规格说明界面设计活动1.定义界面对象和动作2.设计问题系统响应时间用户求助设施（userhelpfacilities）错误信息处理命令标记（commandlabeling）3.黄金原则让用户拥有控制权减少用户的记忆负担保持界面一致130小结人的因素主要包括:人对感知过程的认识用户的技能和行为方式人体测量学对设计的影响人机界面风格语言界面图形用户界面直接操纵用户界面多媒体用户界面多通道用户界面人机界面设计过程用户、任务和环境分析及建模界面设计界面构造界面确认界面设计活动定义界面对象和动作设计问题黄金原则有效的设计评估包括专家评审和可用性测试。第12章程序设计语言和编码

内容摘要程序设计语言程序设计风格基本概念程序设计语言是指用于书写计算机程序的语言，它是一种实现性的软件语言一般地，程序设计语言的定义都涉及到语法，语义，语用等三个方面因素：语法（syntax）用来表示构成语言的各个记号之间的组合规则，它是构成语言结构正确成分所需遵循的规则集合语义（semantic）用来表示按照各种表示方式所表示的各个记号的特定含义，但它不涉及到使用者。语用（pragmatic）用来表示构成语言的各个记号和使用者的关系。程序设计语言的基本成分程序设计语言基本成份可归纳为四种：数据成分、运算成分、控制成分、传输成分数据成分：它指明该语言能接受的数据，用来描述程序中的数据。运算成分：它指明该语言允许执行的运算，用来描述程序中所需进行的运算。如+、-、*、/等。控制成分：它指明该语言允许的控制结构，人们可利用这些控制成分来构造程序中的控制逻辑。基本的控制成分包括：顺序结构、条件选择结构和重复结构。传输成分：它指明该语言允许的数据传输方式，在程序中可用它进行数据传输。1.影响程序员心理的语言特性有：一致性：指语言采用的标记法（使用的符号）协调一致的程度。如，一符多用的标记法容易导致错误。二义性：对语句不同理解所产生的二义性将导致程序员对程序理解的混乱。如，

ifthenifthenelsex:=a**b**c紧致性（compactness）：指程序员必须记忆的与编码有关的信息总量。刻画紧致性的指标有：对结构化部件的支持程度，可用关键字和缩写的种类，算术及逻辑操作符的数目，预定义函数的个数等。局部性：程序由模块组成，应采用高内聚低耦合、模块独立、局部化等原则。线性：人们习惯于按逻辑上线性的次序理解程序，程序中大量的分支和循环、随意的GOTO语句会破坏程序的线性，提倡结构化程序设计。传统性：传统性容易影响人们学习新语种的积极性程序设计语言的特性2.工程特性程序设计语言的特性影响人们思考程序的方式，从而也限制了人们与计算机进行通信的方式。为满足软件工程的需要，程序设计语言还应该考虑：程序设计语言的特性将设计翻译代码的便利程度、编译器的效率、源代码的可移植性、配套的开发工具、软件的可复用性软件的可维护性。3.应用特性不同的程序设计语言满足不同的技术特性，可以对应于不同的应用。例如Prolog语言适用于人工智能领域、SQL语言适用于关系数据库。语言的技术特性对软件工程各阶段有一定的影响，特别是确定了软件需求之后，程序设计语言的特性就很重要了，要根据不同项目的特性选择相应特性的语言。

程序设计语言的选择为一个特定的开发项目选择编程语言时，通常要考虑如下因素：应用领域算法和计算复杂性软件运行环境用户需求，特别是性能需求数据结构的复杂性软件开发人员的知识水平可用的编译器与交叉编译器项目所属的应用领域常常是首要的标准COBOL适用于商业领域FORTRAN适用于工程和科学计算领域Prolog、Lisp适用于人工智能领域Smalltalk、C++适用于OO系统的开发有些语言适用于多个应用领域，如C若有多种语言都适合于某项目的开发时，也可考虑选择开发人员比较熟悉的语言程序设计语言的选择选择高级语言还是低级语言优先选择高级语言开发和维护高级语言程序比开发和维护低级语言程序容易得多必要时使用低级语言高级语言程序经编译后所产生的目标程序的功效要比完成相同功能的低级语言程序低得多，所以在有些情况下会部分或全部使用低级语言程序设计语言的选择内容摘要程序设计语言程序设计风格程序设计风格编程的依据是详细设计的结果，因此程序的质量主要取决于设计，但编程的质量也在很大程度上影响着程序的质量编程风格主要包括：源程序中的内部文档数据说明语句构造输入／输出第13章软件测试

内容摘要软件测试基础白盒测试黑盒测试测试策略面向对象测试测试完成标准调试软件测试基础软件测试的目的软件测试的基本原则软件测试方法

因为开发工作的前期不可避免地会引入错误，测试的目的是为了发现和改正错误，这对于某些涉及人的生命安全或重要的军事、经济目标的项目显得尤其重要。软件测试的目的软件测试的原则1、尽量不由程序设计者进行测试。因为由程序设计者进行测试，他会有意无意地在测试过程中去证明自己的程序是正确的，因而会影响测试的效果。2、关键是注重测试用例的选择。输入数据的组成（输入数据、预期的输出结果）既有合理输入数据，也有不合理的输入数据。(1.2.3三边)用例既能检查应完成的任务，也能够检查不应该完成的任务。(用户权限)长期保存测试用例。3、充分注意测试中的群集现象。群集现象是指—

在测试过程中，发现错误比较集中的程序段，往往可能残留的错误数较多。因此必须注意这种群集现象，对错误群集的程序段进行重点测试，以提高测试的效率。软件测试方法分为两类：静态分析、动态测试，在进行软件测试时，通常两种方法都应同时使用。一、静态分析方法指以人工的、非形式化的方法对程序进行分析和测试。常用的静态测试方法有：步行检查是最常用的静态分析方法，进行步行检查时，还常使用以下分析方法： ①

调用图

从语义的角度考察程序的控制路线。 ②数据流分析图检查分析变量的定义和引用情况。桌前检查（DeskChecking)由程序员检查自己的程序，对源代码进行分析、检验。代码会审（CodeReadingReview)由程序员和测试员组成评审小组，按照“常见的错误清单”，进行会议讨论检查。步行检查

(Walkthroughs)与代码会审类似，也要进行代码评审，但评审过程主要采取人工执行程序的方式，故也称为“走查”。软件测试方法二、动态测试方法动态测试方法与静态分析方法的区别是：需要通过选择适当的测试用例，上机执行程序进行测试。2、黑盒法不考虑程序的内部结构与特性，只根据程序功能或程序的外部特性设计测试用例。因此将其比喻为一个不透明的盒子，称为黑盒法。分析程序的内部逻辑结构，注意选择适当的覆盖标准，设计测试用例，对主要路径进行尽可能多的测试。逻辑结构常用的方法有：

1、白盒法由于需要分析了解程序的内部结构，好象一个透明的盒子，因此称为白盒法。内容摘要软件测试基础白盒测试黑盒测试测试策略面向对象测试测试完成标准调试白盒测试常用的白盒测试方法有：逻辑覆盖测试基本路径覆盖测试数据流测试循环测试逻辑覆盖测试

语句覆盖判定覆盖条件覆盖

判定－条件覆盖条件组合覆盖路径覆盖逻辑覆盖主要考察使用测试数据运行被测程序时对程序逻辑的覆盖程度。通常希望选择最少的测试用例来满足所需的覆盖标准。

主要的覆盖标准有：基本路径测试在实际问题中，一个不太复杂的程序，特别是包含循环的程序，其路径数可能非常大。因此测试常常难以做到覆盖程序中的所有路径，为此，我们希望把测试的程序路径数压缩到一定的范围内。基本路径测试是TomMcCabe提出的一种白盒测试技术，这种方法首先根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例。内容摘要软件测试基础白盒测试黑盒测试测试策略面向对象测试测试完成标准调试黑盒测试黑盒测试是依据软件的需求规约，检查程序的功能是否符合需求规约的要求。主要的黑盒测试方法有：等价类划分边界值分析比较测试错误猜测因果图内容摘要软件测试基础白盒测试黑盒测试测试策略面向对象测试测试完成标准调试测试策略一种测试策略就是将测试分为单元测试集成测试确认测试系统测试V模型：描述软件开发各阶段与测试策略之间的对应关系。系统工程需求分析设计编码系统测试确认测试集成测试单元测试单元测试(UnitTesting)单元测试又称模块测试，它着重对软件设计的最小单元（软件构件或模块）进行验证单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误单元测试通常采用白盒测试，并且多个构件或模块可以并行进行测试这里将构件或模块统一称为模块单元测试通常与编码工作结合起来进行。模块本身不是一个独立的程序，在测试模块时，必须为每个被测模块开发一个驱动(driver)程序和若干个桩(stub)模块。集成测试（IntegratedTesting）集成测试也称组装测试、联合测试经单元测试后，每个模块都能独立工作，但把它们放在一起往往不能正常工作。主要问题在于：数据可能在通过接口时丢失；一个模块可能对另一个模块产生产生非故意的、有害的影响（即副作用）；当子功能被组合起来时，可能不能达到期望的主功能；单个模块可以接受的不精确性（如误差），连接起来后可能会扩大到无法接受的程度；全局数据结构可能会存在问题。

集成的方式有两种：非增量式集成：使用“一步到位”的方法来构造程序。先将所有经过单元测试的模块组合在一起，然后对整个程序（作为一个整体）进行测试。这种测试在发现错误时，很难为错误定位。改正错误时容易引入新的错误，新旧错误混在一起，更难定位。

增量式集成：根据程序结构图，按某种次序挑选一个（或一组）尚未测试过的模块，把它集成到已测试好的模块中一起进行测试，每次增加一个（或一组）模块，直至所有模块全部集成到程序中。在增量集成测试过程中发现的错误，往往与新加入的模块有关。

增量式集成又可分为自顶向下集成和自底向上集成。自顶向下集成：从主控模块（主程序）开始，然后按照程序结构图的控制层次，将直接或间接从属于主控模块的模块按深度优先或广度优先的方式逐个集成到整个结构中，并对其进行测试。自顶向下集成在测试一个模块时，它的上层模块（已测试过）可用作它的驱动模块。自顶向下集成的优点：不需要驱动模块；能尽早对程序的主要控制和决策机制进行检验，能较早发现整体性的错误；深度优先的自顶向下集成能较早对某些完整的程序功能进行验证。自顶向下集成的缺点：

测试时低层模块用桩模块替代，不能反映真实情况；重要数据不能及时回送到上层模块。

自底向上集成：从程序结构的最底层模块（即原子模块）开始，然后按照程序结构图的控制层次将上层模块集成到整个结构中，并对其进行测试。自底向上集成在测试一个模块时，它的下层模块（已测试过）可用作它的桩模块。自底向上集成的优点：不需要桩模块，所以容易组织测试；将整个程序结构分解成若干个簇，对同一层次的簇可并行进行测试，可提高效率。自底向上集成的缺点：整体性的错误发现得较晚。

策略的选择自顶向下集成测试与自底向上集成测试各有优缺点，其中一种策略的优点差不多就是另一种策略的缺点。将这两种策略组合起来可能是一种最好的折衷，这种折衷的策略是：在程序结构的高层使用自顶下向策略，而在低层则使用自底向上策略，这种测试策略也称为三明治测试（sandwichtesting）。集成测试时应特别关注关键模块（criticalmodule）的测试。关键模块是指具有下列一个或多个特征的模块：1）与多个软件需求有关；2）含有高层控制（位于程序结构的高层）；3）本身是复杂的或是容易出错的；4）含有确定的性能需求。关键模块应尽早测试，回归测试时也应集中在关键模块的功能上。回归测试（RegressionTesting）在集成测试过程中，每当增加一个（或一组）新模块时，原先已集成的软件就发生了改变。新的数据流路径被建立，新的I/O操作可能出现，还可能激活新的控制逻辑，这些改变可能使原本正常的功能产生错误。当测试时发现错误后，需修改程序；或者在软件维护时也需修改程序。这些对程序的修改也可能使原本正常的功能产生错误。回归测试就是对已经进行过的测试的子集的重新执行，以确保对程序的改变和修改，没有传播非故意的副作用。确认测试（ValidationTesting）确认测试标准

确认测试以软件需求规约为依据，以发现软件与需求不一致的错误。主要检查软件是否实现了规约规定的全部功能要求，文档资料是否完整、正确、合理，其他的需求，如可移植性、可维护性、兼容性、错误恢复能力等是否满足。确认测试的结果可分为两类：满足需求规约要求的功能或性能特性，用户可以接受。发现与需求规约有偏差，此时需列出问题清单。

α测试和β测试α测试是由一个用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经α测试后的软件称为β版软件。β测试是由软件的最终用户在一个或多个用户场所进行的，与α测试不同，开发者通常不在测试现场，因此，β测试是软件在一个开发者不能控制的环境中的“活的”应用，用户记录所有在β测试中遇到的（真正的或想象的）问题，并定期把这些问题报告给开发者，在接到β测试的问题报告后，开发者对软件进行最后的修改，然后着手准备向所有的用户发布最终的软件产品。系统测试（SystemTesting）系统测试是对整个基于计算机的系统进行的一系列测试。系统测试的种类很多，每种测试都有不同的目的，它们从不同的角度测试计算机系统是否被正常地集成，并完成相应的功能。常用的系统测试包括：恢复测试（recoverytesting）安全测试（securitytesting）压力测试（stresstesting）性能测试（performancetesting）内容摘要软件测试基础白盒测试黑盒测试测试策略面向对象测试测试完成标准调试面向对象语境对测试的影响单元:类是面向对象软件中的单元封装:由于属性和操作被封装在类中，因此测试时很难获得对象的某些具体信息（除非提供内置操作来报告这些信息），从而给测试带来困难。继承:测试了父类的操作后，并不表示其子类就不必对继承的操作进行测试。多态性:在测试时，应覆盖反映多态的所有实现方法。基于消息的通信:面向对象软件是通过消息通信来实现类之间的协作，它们没有明显的层次控制结构，因此，传统的自顶向下和自底向上集成策略不适用于面向对象软件测试。面向对象的测试策略把类作为面向对象软件的单元，传统的单元测试等价于面向对象中的类测试，也称类内测试。它包括类内的方法测试和类的行为测试。面向对象中的类间测试（interclasstesting）相当于面向对象的集成测试。它有两种集成策略：基于线程的测试（thread－basedtesting）基于使用的测试（use－basedtesting）面向对象的确认测试和系统测试策略与传统的确认测试和系统测试策略相同，在面向对象确认测试时，应该利用用况模型，通过用况提供的场景来发现与用户需求不一致的错误。内容摘要软件测试基础白盒测试黑盒测试测试策略面向对象测试测试完成标准调试测试完成的标准几种实用的测试完成标准：Musa和Ackerman提出了一个基于统计标准的答复：“不，我们不能绝对地认定软件永远也不会再出错，但是相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错运行的概率大于0．995的话，那么我们就有95%的信心说，我们已经进行了足够