软件工程复习提要2011.doc

第一讲 软件工程概念自从1968年首次提出“软件工程”一词以来，软件工程已经成为计算机软件的一个重要分支和研究方向。软件工程是指应用计算科学，数学及管理科学等原理以及工程化的原则和方法来解决软件问题的工程。其目的是：提高软件生产率，提高软件质量，降低软件成本。软件工程的概念可归结如下几个方面：一、软件的特点及其分类1.什么是软件或软件定义软件是程序、数据以及相关文档的完整集合。Boehm认为软件 程序 文档 。进一步，对于一个计算机而言，有： 硬件系统 计算机系统 程序：按事先设计的功能和性能要求执行的指令序列 软件系统 数据：程序能够正常操纵信息的数据结构 文档：与程序开发、维护、使用有关的图文资料为了能全面、正确地理解计算机和软件，必要了解软件的特点。2、软件的特点.软件是一种逻辑实体，它具有抽象性。.软件的开发过程没有明显的制作过程。.软件在使用期内没有磨损、老化问题。.软件的开发与运行常常受计算机系统的限制，对计算机系统有着不同程度的依赖性。.软件的开发至今尚未完全摆脱手工艺的开发方式，虽然近年来软件复用技术、自动生成技术开发工具等有了新的进展。.软件本身是复杂的，而且随着应用规模的扩大，软件变得越来越复杂。.软件的成本相当昂贵。.相当多的软件工作涉及到社会因素。3、软件的分类.按功能可分为：系统软件，支撑软件，应用软件。.按软件规模可分为： 微型软件，小型软件，中型软件，大型软件，甚大型软件，极大型软件。.按软件工作方式分： a.实时处理软件： 监控软件等； b.分时处理软件：多个用户联机使用计算机； c.交互式软件： 实现人机交互； d.批处理软件： 把一组作业以成批方式一次运行，按顺序逐个处理。.按软件服务对象的范围划分：项目软件(定制软件)，产品软件(商品软件)。除此以外，还要按使用频度划分，按软件失效的影响进行划分等方法。4、软件危机1)什么是软件危机软件危机是指在计算机软件开发和维护过程中所遇到的一系列严重问题。这些问题不仅仅是“不能正常运行的”软件才具有的，实际上几乎所有软件都不同程度的存在这些问题。软件危机包含两个方面：A.如何开发软件以满足对软件的日益增长的需求；B.如何维护数量不断膨胀的已有软件。2)软件危机的表现A. 对软件开发成本和进度的估计常常很不准确。B. 用户对“已完成的”软件系统不满意的现象经常发生。C. 软件产品的质量往往靠不住。D. 软件常常是不可维护的。E. 软件通常没有适当的文档资料。F. 软件成本在计算机系统总成本中所占的比例逐年上升。G. 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。3)产生软件危机的原因.由于缺乏软件开发的经验和有关软件数据的积累，使得开发工作的计划很难制定，在进度、费用上估计不准确，引起用户不满。.软件需求很难确定或不确定，这一点是非常关键，尤其在国内开发软件更为突出。.开发过程没有统一的、公认的方法论和规范指导，缺乏规范文档，使软件很难维护。.测试工作不充分，导致软件错误很多，使软件可靠性降低。有很多的软件测试方法已经被广泛采纳，如黑盒测试、白盒测试、逻辑覆盖、等价类划分、边界值划分、错误猜测、Alpha测试、Beta测试等技术等。二、软件工程过程与软件生存期1.软件工程过程为获得软件产品，在软件工具支持下，由软件工程师完成的一系列软件工程活动，称为软件工程过程。每一个软件开发结构都可以规定自己的软件工程过程。针对不同类型的软件产品，同一软件开发机构也可使用多个不同的软件工程过程。软件工程过程通常包含4种基本的过程活动。 P(plan)： 软件规格说明，规定软件的功能及其运行限制 D(do)： 软件开发，产生满足规格说明的软件 C(check)： 软件确认，确认软件能够完成客户提出的要求 A(action)：软件演进，为满足客户的变更要求，软件必须在使用的过程中演进。事实上，软件工程过程是一个软件开发机构针对某类软件产品为自己规定的工作步骤。2.软件生存期(软件生命周期)软件生命周期包括制定计划、需求分析、基本设计与详细设计、编码、测试、维护等阶段。项目计划软件功能软件项目计划评审需求分析或原型需求规格说明书原型评审A定义阶段源程序代码概要设计规格说明数据与结构设计评审评审评审过程设计程序编码原型详细设计规格说明B. 开发阶段修改过的源代码测试计划测试过程测试结果单元测试组装测试确认测试调试评审(QA)评审交付与销售维护操作过程用户文档修改的文档C测试、交付与维护阶段3.软件工程的目标低开发成本易于维护按时交付高可靠性高性能软件工程包括三个基本要素，即方法、工具和过程。方法主要研究如何做的问题；工具则是为了软件开发提供一个支撑环境；过程则是将软件工程的方法和工具结合起来以达到合理、及时地进行计算机软件开发地目的。这些目标是：低开发成本；高可靠性；高性能；按时交付；易于维护等。这些目标之间是具有一定的联系的，可用下图来描述这种联系： 其中，有些目标是互补的，而又有一些目标又是相互冲突的。5、软件工程的基本原理1)什么是软件工程软件工程是指采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的软件开发思想和方法。它是指导计算机软件开发和维护的工程学科。2)七条基本原理A. 用分阶段的生命周期计划严格管理B. 坚持进行阶段评审C. 实行严格的产品控制D. 采用现代程序设计技术E. 结果应能清楚地审查F. 开发小组的人员应该少而精G. 承认不断改进软件工程实践的必要性6、软件错误的积累与扩大效应分阶段的技术复查与管理复审的必要性。第二讲 系统分析与可行性研究在这一章中，主要介绍如下几个内容：(1) 问题的识别(2) 可行性分析与研究(3) 系统开发原则(4) 系统开发前的准备(5) 系统开发策略与开发计划(6) 系统分析(7) 系统分析方法论下面逐一加以说明一. 问题的识别系统开发的前提条件是，开发人员必须首先弄清楚5个W。即What，Why，Who，Where，When。也就是说，开发人员必须知道做什么，为什么要做，由谁来做，在哪里做以及何时做的问题。如果在没有搞清楚以上问题就匆忙着手开发，往往是导致系统失败的主要原因。但是，实际工作中，搞清楚以上几个问题并非易事。问题识别的主要是通过了解企业目标、现行企业系统的问题、企业的信息战略等内容，决定如何使用信息技术帮助企业解决这些问题。要识别的问题首先是管理问题。例如，企业战略优势下滑、产品滞销、效率低下等，然后了解信息技术的利用程度。例如有无数据混乱、处理速度慢，设备老化等问题。在了解企业需求的同时，系统分析人员应该通过科学的启发来激发企业的需求，因为企业对管理人员有时是无法了解当前信息技术发展的状况的，有些需求根本提不出来。所以说，现代信息系统的系统分析已经由“满足用户需求”转变为“使用户满意”。这里离不开系统分析员的主动性。问题识别的越清楚，开发成功的概率就越大。二. 可行性分析与研究1.可行性研究的任务可行性研究是指在当前组织内外的具体条件下，系统开发工作必须具备的资源和条件是否能够满足系统目标的需求，希望通过用最小的代价、在尽可能短的时间内确定所识别的问题是否有解。因此，可行性研究实际上是一个大大简化了的系统分析和设计过程，也就是说，是在较高层次上以较抽象的方式进行的系统分析和设计过程。可行性研究包括如下几个方面：l 技术可行性 现有技术能否实现用户的需求；l 经济可行性 从人力、财力、物力上考虑开发系统的经济效益是否高于开发成本；l 操作可行性 系统的操作方式在用户组织内是否可行？目标、方案是否有可操作性，是否满足企业的进一步发展的需求；l 法律可行性 是否满足法律上的要求，有没有社会的因素会对系统开发产生消极影响。2.可行性研究的步骤通过以下几个步骤进行可行性研究与分析。l 复查系统规模与目标；l 研究当前正在使用的系统；l 导出新系统的高层逻辑模型；l 重新定义问题(用户需求)；l 导出和评价可供选择的方法；l 推荐行动方针；l 草拟开发计划；l 书写文档并提交审查。这个阶段，参加的主要人员有：系统分析员、用户、软件工程师(提前进入状态)3.系统流程图系统流程图是描绘物理系统的传统工具。它表达的思想是信息在各个部件之间流动的情况，而不是对信息进行加工处理的控制过程，因此尽管系统流程图所使用的符号与程序流程图中所用的符号一致，但是它却表示的是系统流程图而不是程序流程图。例子：库存清单系统的系统流程图库存清单主文件库存清单程序事务报告生成程序定货报表定货信息画复杂系统的系统流程图时，常用的方法是采用分层地描述系统的方法。首先画高层的系统流程图描述系统的概貌，表明系统的关键功能。然后分别包每个关键功能扩展到适当的详细程度，并画在另外一页纸上。这种分层描述的方法结构清晰、便于阅读。订货单收据付款发货单付款收据发货票订单顾客供应商事务处理销售历史帐 目A商店业务处理系统的顶层数据流图4.数据流程图顾客付款收据付款发货票/收据修改查询修改查询供应商销售历史商品库存采购订单应收款明细账总 帐1销售2采购暂存订单3会计付款单收款单收据应付款明细账修改B商店业务处理系统功能级数据流图订货通知订货单到货通知发货单5.数据字典(DD)数据字典是关于数据信息的集合，即对DFD中所包含的所有元素的定义的集合。5.1 DD的内容 一般而言，DD有以下四个元素的定义组成：l 数据流l 数据流分量，即数据元素l 数据存储l 处理对数据处理而言，可能用IPO图或PDL语言描述更为方便。5.2 DD的用途DD的用途是作为分析阶段的工具。DD中给出了每个数据元素的控制信息，它对分析数据对程序的影响很有帮助。DD是开发数据库的第一步，而且是很有价值的一步。5.3 数据字典的实现(例子)名字：定货报表别名：定货信息描述：每天一次送给采购员的需要定货的零件表定义：定货报表=零件编号+零件名称+定货数量+目前价格+主要供应商+次要供应商位置：输出到打印机系统中每一个数据或数据元素都有一个类似的定义，也有用其它方式描述数据字典。6.成本/效益分析分析成本与效益，其目的是为了帮助用户预见到系统带来的好处，激励用户全力支持系统的开发。6.1 成本估算l 代码行价格技术l 任务分解技术l 自动估算成本技术6.2 成本/效益分析方法l 货币的时间价值l 投资回收期l 纯收入l 投资回收率以上概念不一一赘述。三. 系统开发原则系统开发应遵循的一般原则包括：l 领导参与原则l 优化与创新的原则l 充分利用信息资源的原则l 实用和时效的原则l 规范化原则l 发展变化原则四. 系统开发前的准备系统开发前的准备工作包括两个方面：(1) 基础准备工作l 管理工作要严格科学化，具体方法要程序化、规范化；l 做好基础数据管理工作；l 数据、文件、报表的统一化。(2) 人员准备工作l 领导参与；l 建立一支由系统分析员、管理岗位业务人员和信息技术人员参与的开发小组；l 明确各类人员的职责。五. 系统开发策略与开发计划系统的开发策略目前主要由四种：(1) 接收式开发策略 认为用户的需求是正确的，当系统规模不是很大且结构化时采用。(2) 直接式开发策略 认为用户需求变化不是很大，当对用户的业务有很好的了解时采用。(3) 迭代式开发策略 当用户需求不是一下子就能确定，需要重复时采用。(4) 实验式开发策略 当用户需求的不确定性很高时采用。六. 系统分析系统分析的主要任务时将系统调查中收集到的文档资料集中到一起，对组织内部整体管理状况和信息处理过程进行分析。它侧重于从业务全过程的角度进行分析。其目的是确定用户的需求，回答“做什么”的问题。虽然在可行性分析中已经做了讨论，但由于只是在较短的时间内做出的近乎合理的结论，很多细节都被忽略了，所以需要进一步做细致的分析，以确保用户需求。可行性分析阶段所产生的文档、DFD、DD是系统分析的基础，而需求分析的结果是系统开发的基础，它关系整个工程能否开发成功以及软件的质量。1.需求分析系统分析中关键的部分，有的书上直接讲需求分析。1.1 需求分析的具体任务l 确定对系统的综合要求1) 系统功能要求 列出系统所必须的功能2) 系统界面要求 描述系统的外部特性3) 系统性能要求 响应时间、存储容量、吞吐量、安全因素、可靠性4) 运行要求 软硬件环境5) 异常处理要求 运行历史记录、出错处理等6) 将来可能提出的要求 系统功能扩充和维护的要求l 分析系统的数据要求任何一个软件系统本质上是一个信息处理系统。系统必须处理的信息和系统应该产生的信息在很大程度上决定系统的面貌。对软件设计有深远的影响。采用ER模型分析数据。复杂的数据由数据元素组成，可用层次方框图或Warnier图来描述数据的结构。用范式理论来消除数据中的冗余。l 导出系统的逻辑模型通常用数据流程图和数据字典来描述系统的逻辑模型。l 修正系统开发计划准确地了解系统功能和模型之后，可以比较精确地估计系统的成本和进度。l 开发原型系统如果有必要的话，开发原型系统以帮助用户了解新系统。理由：u 由于认得认识的局限，很难预先确定需求；u 在用户和系统分析员之间存在着通信鸿沟；u 用户需要一个“活”的系统模型以获得实践经验；u 开发过程中的适当的重复或反复是不可避免的u 有比较好的工具可以利用。1.2 需求分析的分析过程l 沿着DFD回溯；l 用户复查；l 细化DFD；l 修正开发计划；l 书写文档；l 审查与复审；1.3 概念模型和规范化l ER模型；l 范式；1.4 图形工具l 层次方框图；l Warnier图；l IPO图；1.5 验证软件需求l 一致性；l 完整性；l 现实性；l 有效性；2 组织机构与功能分析l 组织结构分析与组织结构图；l 业务过程与组织结构之间的联系；l 业务功能一览表3 业务流程分析在业务功能的基础上将业务流程细化，建立业务流程图。业务流程图并不等于数据流程图。业务流程图反映业务处理的过程，与组织结构等有关；数据流程图反映的信息的流变、传递、处理和存储的情况(不涉及到信息的载体、具体处理工作、物资、材料等)。4 数据与数据流成分析数据调查汇总；数据分析以确定数据流程是否畅通、前后数据是否匹配、数据处理过程是否合理等；业务流程图是数据流程的基础。(上面的例子是关于数据流程)5 功能/数据分析系统功能规划与数据资源的合理分布6 新系统逻辑方案的建立低成本的解决方案；中等成本的解决方案；相对成本较高的饿解决方案；七. 系统分析方法论1. 结构化系统开发方法 SA，SD，SP 自顶向下，最为成熟1)基本思想用系统工程的思想和工程化的方法，按用户至上的原则，结构化，模块化，自顶向下地对系统进行分析与设计。2)特点l 自顶向下整体性的分析与设计和自底向上逐步实施的系统开发过程；l 用户至上；l 深入调查研究；l 严格区分工作阶段；l 充分预料可能发生的变化；l 开发过程工程化。3)生命周期l 系统规划阶段；l 系统分析阶段；l 系统设计阶段；l 系统实施阶段；l 系统运行阶段。4)优缺点l 强调系统开发过程的整体性和全局性；l 自顶向下；l 严格区分阶段和按阶段的管理；l 起点较低，工具落后，导致开发过程太长；l 不能适应不断变化的用户需求。2. 原型法(试验型原型法瀑布型模型的辅助、演进型原型法)1)工作流程 户提出要求； 开发人员识别和归纳用户要求； 根据归纳的要求构造原型系统； 用户分析评价原型系统； 用户评价不通过，则转第步； 用户已满意所实现的原型系统，则转第步； 修改原型，然后转第步； 系统交付。2)特点l 原型法更多地遵循了人们认识事物的规律，因而更容易被接受；l 原型法将模拟手段引入系统分析的初期阶段，缩短了用户与系统分析人员之间的距离，解决了结构化方法中最难于解决的一环；l 充分利用了最新的工具软件，提高开发效率。3)软件支持工具原型法的优点的发挥，必须有一个软件环境加以支持。一般认为，其支持环境如下：l 一个方便灵活的关系数据库系统(RDBS)；l 一个与RDBS相对应，方便灵活的DD，存储所有的实体；l 一套与RDBS相对应的快速查询系统，能够支持任意非过程(即交互定义方式)化的组合条件查询；l 一套高级的软件工具用以支持结构化程序，并且允许采用交互的方式迅速地编写和维护，产生任意程序语言的模块(原型)；l 一个非过程化的报告或屏幕生成器，允许设计人员详细定义报告或屏幕输出样本。4)适用范围l 对于一个大型的系统，如果不经过系统分析来进行整体性划分，想要直接通过屏幕来逐个模拟是很困难的；l 对于大量运算和逻辑性较强的程序模块，原型法很难出模型供人们评价；l 对于原管理不善，信息处理过程混乱的问题，使用有一定的困难；l 对于批处理系统，由于大量的处理是内部处理，所以用原型法有一定的困难。5)结论原型法是对结构化开发方法的发展和补充，所以两者的结合将是今后若干年信息系统或软件工程中所使用的主要方法之一。3. Jackson方法掌握Jackson方法的基本原理及其实现过程。4. 面向对象的开发方法1)OO方法的基本思想把组成系统对象从客观世界中抽象出来并设计成构成系统的最小集合。对象是OO法的主体，对象至少要有以下特征：l 模块性；l 继承和类比性；l 动态连接性；2)开发过程l 系统调查和需求分析；l 分析问题的性质和求解问题；l 整理问题；l 程序实现。3)OOA方法OOA所说的分析与SA中的分析不同，OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。5. 计算机辅助开发方法 CASE1)CASE方法的基本思路借助与专门研制的软件工具来实现上述软件开发方法的各个过程。每一种开发方法都有相应的CASE产品2)CASE的特点l 解决了从客观世界对象到软件结构的直接映射问题，强有力地支持软件/信息系统开发的全过程；l 使结构化方法更加实用；l 自动检测的方法大大提高了软件的质量；l 使原型化方法和OO方法付诸实施；l 简化了软件的管理和维护；l 加速了系统的开发过程；l 使开发者从繁杂的分析设计图表和程序编写中解放出来；l 使软件的各部分能够重复使用；l 产生统一的标准化的系统文档；l 使软件开发的速度加快而且功能进一步完善。第三讲 软件设计软件设计阶段要解决的问题是“How to do”的问题。就是说，需将整个系统划分出系统的物理组成元素(程序、文件、DB、人工过程、文档)。软件设计分为基本设计和详细设计两个部分。基本设计的主要工作是确定系统的结构、进行模块化划分、确定每一个模块的功能、规定每一个模块的接口及调用关系、确定全局数据结构等；详细设计的主要工作是为每一个模块设计其实现细节并确定各个局部数据结构。一、基本设计1.软件设计过程1） 依据需求分析的基础设想可供选择的方案；2） 选取合理的方案；3） 推荐最佳方案；4） 功能分解；5） 设计软件结构；6） 设计数据库结构；7） 制定测试计划；8） 书写文档；9） 审查与复审。2.软件设计的概念和原理1） 模块化概念2） 抽象的概念3） 信息隐蔽和局部化4） 模块独立及其度量耦合：衡量不同模块彼此相互依赖的紧密程度的一种度量内聚：衡量模块内部各个元素彼此结合的紧密程度的一种度量耦合方式(7种)：自上而下，其耦合程度越来越强。l 非直接耦合：两个模块没有直接的联系，互相都不依赖于对方而能独立地工作；l 数据耦合：两个模块借助于参数表传递简单数据；l 标记耦合：两个模块借助于参数表传递数据结构的一部分；l 控制耦合：两个模块间传递的信息中包含有用于控制模块内部逻辑的控制信息；l 外部耦合：模块与软件以外的环境有关；l 公共耦合：多个模块引用同一全局数据区的模式；l 内容耦合：两个模块间出现了下列情况之一：a) 一个模块访问另一个模块的内部数据；b) 一个模块不通过正常的入口转到另一个模块的内部；c) 两个模块有一部分程序代码重叠(汇编语言程序)；d) 一个模块有多个入口。内聚方式(7种)：自上而下，其内聚程度越来越强。l 偶然内聚：一个模块完成一组任务，这些任务间即使有关系，其关系也是松散的；l 逻辑内聚：一个模块完成逻辑上相关的一组任务；l 瞬时内聚：一个模块所包含的任务必须在同一时间间隔内执行(如初始化模块)；l 过程内聚：一个模块的处理元素是相关的，而且必须按特定的次序执行；l 通信内聚：一个模块的所处理元素集中在一个数据结构的区域上(如所有处理元素使用同一输入数据)；l 顺序内聚：一个模块的处理元素是相关的且必须顺序执行；l 功能内聚：一个模块完成一个单一的功能，模块中的各部分在此目标下协同工作且都是完成这一功能不可缺少的；3.软件设计的原则1） 满足信息隐蔽原则；2） 尽量做到高内聚、低耦合；3） 模块的大小适中，通常以完成一个相对独立的功能为宜；4） 模块的调用深度不宜过大；5） 模块的扇入应尽量大，而扇出不宜过大；原则：高层的扇出应较高；中间层的扇出应较少；低层的扇入应较高。6） 设计单入口和单出口的模块；7） 模块的作用域应在控制域之内；8） 模块的功能应该是可以预测的。4.图形工具1） 层次图和HIPO图； 2） 结构图。5.面向数据流的设计方法(结构化程序设计方法)结构化设计方法SD是一种面向数据流的设计方法。它与结构化分析SA相衔接。SD采用结构图(Structure Chart-SC)来描述程序结构。1)步骤l 复查并精化DFD；l 确定DFD的信息流类型(变换流或事务流)；l 根据数据流类型分别实施变换分析或事务分析；l 根据软件设计原则对程序结构图作优化。精化DFD区分输入流和输出流 区分事务中心和数据接受通路映射成事务结构映射成变换结构用软件设计原则精化软件结构详细设计导出接口描述和全局数据结构数据流类型 复查事务分析变换分析事务合格不合格变换下图说明了面向数据流设计方法的过程。2)例子变换分析 l 确定输入流和输出流，孤立出变换中心；l 第一级分解；l 第二级分解。事务分析l 确定事务中心和每条活动流信息；l 将事务流型DFD映射成高层的程序结构；l 进一步分解。二、详细设计1.结构化程序设计1） 顺序结构；2） 分支结构；3） 循环结构；4） GOTO语句的讨论2.详细设计工具1） 程序流程图；2） 盒图(N-S图)；3） PAD图；4） 判定表；5） 判定树；6） 过程设计语言；7） 程序开发文件夹。3.详细设计说明书1） 概要功能说明；2） 画面格式设计与说明；3） 数据关联图；4） 输入/输出数据项的详细描述；5） 处理功能逻辑说明(程序流程图等)；6） 画面迁移(功能逻辑关系的反映)。4.面向数据结构的程序设计方法1） Jackson程序设计方法的思想与实现过程；2） Warnier程序设计方法的思想；第四讲 编码与编程规范编码阶段的任务是根据详细设计说明书编写程序。一、编码1.选择合适的程序设计语言实现系统功能分析程序设计语言的特点，选择一种合适的语言实现所设计的软件。2.编码风格1） 程序内部的文档 l 选择标识符的名字，要含义明确且易于区分；l 注解(序言性注解和功能性注解)，要尽可能准确全面；l 程序的视觉组织，要便于阅读。2） 数据说明l 显式说明一切变量；l 数据说明的次序要规范化；l 当多个变量出现在同一个说明语句中时要有确定的次序，便于阅读；l 当定义一个复杂数据结构时，应说明其结构特征。3） 语句构造l 不要在同一行中写多个语句；l 避免使用测试条件“非”；l 避免使用复杂的条件测试；l 使用括号清晰地表达出各个表达式的运算次序；l 适当增加空格等使程序清晰；l 尽量少使用GOTO语句；l 尽量利用标准语句以便提高可移植性；l 尽量采用三种基本的控制结构语句编写程序。4） 输入/输出l 对所有的输入数据都要做合法性检查；l 检查输入项的重要组合的合理性；l 保持输入格式的简单和操作简单；l 使用数据结束标记；l 明确提出交互式输入的请求，详细说明可用的选择或边界值；l 保持输入格式与输出语句要求的一致性；l 设计良好的输出报表5） 效率l 程序运行时间；l 存储空间l 输入/输出二、编程规范每一个软件开发机构都应该有自己软件工程过程。有固定的软件开发模式，即要规定一种大家都遵守的规则三、运行记录文件对软件运行的记录，在批处理软件的制作中尤其需要。第五讲 测试与维护测试的目的是为了发现程序中潜在的错误，而不是为了证明程序的正确性。一、基本概念1.目的软件测试的目的是尽可能多地发现软件产品(主要是指程序)中的错误和缺陷，而不是为了证明程序的正确性。2.测试用例测试用例是测试数据和测试结果的总称。一个好的测试用例是极有可能发现迄今为止尚未发现的错误的测试用例。一个成功的测试是发现了迄今为止尚未发现的错误的测试。3.测试原则基于测试的目的，有以下的测试原则：1） 确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无测试结果，那么就不容易判断测试的结果是否正确；2） 程序员应尽量避免测试自己的程序，程序设计机构不应测试自己的程序；3） 彻底检查每一个测试结果，以免遗漏已经测出的错误；4） 对非法的和非预期的输入数据也要像合法的和预期的输入数据一样编写测试用例；5） 检查程序是否作了应该作的事情仅是成功的一半，另一半是检查程序是否做了不应该做的事；6） 除了真正没有用的程序外，一定不要将测试用例扔掉。因为改正错误或程序维护后还要进行重新测试；7） 在规划测试时不要设想程序中不会检查出错误；8） 程序模块经测试后，遗留的错误数目往往与已经发现的错误数目成比例。4.白盒测试与黑盒测试白盒测试：根据程序的内部逻辑设计测试用例并进行测试(也称内部逻辑测试)。黑盒测试：根据规格说明书规定的功能设计测试用例并进行测试(也称功能测试)。二、测试步骤与测试要点软件测试的主要步骤有单元测试、集成测试和确认测试等步骤。1.单元测试单元测试也称模块测试，通常可在编码阶段完成。单元测试主要发现编码和详细设计说明书中的错误，通常采用白盒测试方法。单独测试一个模块时，编制相应的测试软件是必要的。测试软件主要包括两种。一是向被测模块传送测试数据的驱动程序；二是用于接受测试结果的由被测模块调用的存根程序。最高层的模块不需要驱动程序；最底层的模块不需要存根程序。单元测试通常要考虑以下五个特性：l 模块接口参数；l 局部数据结构；l 重要的执行通路；l 出错处理；l 影响以上各方面特性的边界条件。单元测试过程：l 代码审查l 测试软件的利用2.集成测试(含结合测试、综合测试)集成测试也称组装测试，它对由各个模块组装成的程序进行测试。集成测试主要发现设计阶段产生的错误，通常采用黑盒测试方法有两种集成的方式。一是渐增式集成；二是非渐增式集成。所谓渐增式集成是指将单元测试和集成测试合并在一起，它根据模块结构图，按某种次序选择一个尚未测试的模块，把它已经测试好的模块组合在一起进行测试，每次增加一个模块，直至所有的模块都集成在程序中。所谓非渐增式集成是指首先测试所有的模块，然后把这些模块集成在一起对整个程序进行测试。渐增式集成又可分成自顶向下集成和自底向上集成。自顶向下集成先测试顶层模块，然后测试下层模块(需要存根程序，不需要驱动程序)；自底向上集成先测试低层模块，然后测试上层模块(不需要存根程序，但需要驱动程序)。3.确认测试确认测试的任务是检查软件的功能、性能及其它特征是否与用户的需求一致。它以需求规格说明书为依据进行测试。通常采用黑盒测试。确认测试首先测试程序是否满足需求规格说明所列的各项要求，然后要进行软件配置复查，特别是文档是否齐全，各方面的质量是否符合要求等。确认测试必须有用户参加。当开发的软件为商用软件产品时，尚需要进行Alpha测试和Beta测试。Alpha测试：在开发者现场由开发人员按照用户的要求设置测试环境并由用户进行测试。Beta测试：在用户现场由用户设置测试环境并由用户进行测试。4.并行运行为安全起见，新系统试运行阶段应与旧系统并行运行。三、测试阶段的信息流测试调试评价可靠性模型软件配置测试配置预期结果测试结果错误错误率数据可靠性预测正确测试阶段的信息流如下图5-1所示：图5-1 测试阶段的信息流四、测试用例1.白盒测试的测试用例设计白盒测试是根据程序的内部逻辑来设计测试用例，常用的技术是逻辑覆盖。主要的覆盖标准有如下六种：l 语句覆盖：选择足够多的测试用例，使得运行这些测试用例时，被测程序的每一个语句至少被执行一次。语句覆盖是一个最基本的覆盖，也是一种很弱的覆盖标准。l 判定覆盖：选择足够多的测试用例，使得运行这些测试用例时，被测程序的每一个判定的所有可能结果至少出现一次(判定的每个分支至少经过一次)。判定覆盖也称为分支覆盖，满足判定覆盖的测试用例也一定满足语句覆盖。l 条件覆盖：选择足够多的测试用例，使得运行这些测试用例时，被测程序的每一个条件的所有可能结果至少出现一次。条件覆盖比判定覆盖强，但未必能够覆盖判定覆盖。l 判定/条件覆盖：选择足够多的测试用例，使得运行这些测试用例时，被测程序的每一个条件的所有可能结果至少出现一次，并且每一个判定本身的所有可能结果至少出现一次。显然，满足判定/条件覆盖标准的测试用例也一定满足判定覆盖、条件覆盖和语句覆盖标准。值得注意的是，并非所有的程序都能对判定覆盖、条件覆盖和判定/条件覆盖找到相同的最少的测试用例(在满足条件的情况下，测试用例还是应该尽可能的少)。l 条件组合覆盖：选择足够多的测试用例，使得运行这些测试用例时，被测程序的每一个判定中条件结果的所有可能的组合至少出现一次。条件组合覆盖是对每个判定分别考虑它们的条件组合，而不是对整个程序中所有判断的所有条件的组合。由于条件组合覆盖使每个判定中条件结果的所有可能的组合都至少出现一次，因此判定本身的所有可能结果也一定至少出现一次，同时也使每一个条件的所有可能的结果至少出现一次，因此，条件组合覆盖是上述五种覆盖标准中最强的一种。然而，条件组合覆盖不能保证程序中所有可能的路径都被覆盖。l 路径覆盖：选择足够多的测试用例，使得运行这些测试用例时，被测程序的每一条可能执行的路径都至少经过一次(如果程序中有环路，则要求每一条环路至少要经过一次)。路径覆盖实际上考虑了程序中各种判定结果的所有可能的组合，但它没有考虑判定中条件结果的组合，因此，虽说是一种较强的覆盖标准，但并不能代替条件覆盖和条件组合覆盖。基本路径测试的原理基本路径测试的步骤为：(1) 以详细设计或源程序为基础，导出程序流程图的拓扑结构程序图。程序图是退化了的程序流程图，它是反映控制流程的有向图，其中小圆圈称为结点，代表了流程图中每个处理符号(矩形、菱形框)，有箭头的连线表示控制流向，称为程序图中的边或路径。图5.2(a)是一个程序流程图，可以将它转换成图5.2(b)的程序图(假设菱形框表示的判断内设有复合的条件)。在转换时注意：一条边必须终止于一个结点，在选择结构中的分支汇聚处，即使无语句也应有汇聚结点；若判断中的逻辑表达式是复合条件，应分解为一系列只有单个条件的嵌套判断，如对于图5.3(a)的复合条件的判定，应画成图5.3(b)所示的程序图。(a)程序流程图 (b)程序图图5-2 程序流程图和程序图(2) 计算程序图G的环路复杂性V(G)。McCabe定义程序图的环路复杂性为此平面图中区域的个数。区域个数为边和结点圈定的封闭区域数加上图形外的区域数1。例如图5.2(b)的V(G)=4，也可按另一种方法计算，即V(G)=判定结点数+l。(a)程序；b)程序图图5.3 复合条件下的程序图 (3) 确定只包含独立路径的基本路径集。环路复杂性可导出程序基本路径集合中的独立路径条数，这是确保程序中每个执行语句至少执行一次所必需的测试用例数目的上界。独立路径是指包括一组以前没有处理的语句或条件的一条路径。从程序图来看，一条独立路径是至少包含有一条在其他独立路径中未有过的边的路径，例如，在图5.2(b)所示的图中，一组独立的路径是：path1：1-11path2：1-2-3-4-5-10-1-11path3：1-2-3-6-8-9-10-l-11path4：1-2-3-6-7-9-10-1-11从例子可知，一条新的路径必须包含有一条新边。这4条路径组成了图5.2(b)所示的程序图的一个基本路径集，4是构成这个基本路径集的独立路径数的上界，这也是设计测试用例的数目。只要测试用例确保这些基本路径的执行，就可以使程序中每个可执行语句至少执行一次，每个条件的取“真”和取“假”分支也能得到测试。基本路径集不是唯一的，对于给定的程序图，可以得到不同的基本路径集。(4) 设计测试用例，确保基本路径集合中每条路径的执行。对于路径测试，能够根据给定的程序段，画出程序流程图、程序图（控制流图），并给出基本路径集。根据基本路径集，设计测试用例。2.黑盒测试的测试用例设计黑盒测试是根据规格说明书所规定的功能设计测试用例，它不考虑程序的内部结构和处理过程。常用的黑盒测试技术有等价类划分、边界值分析、错误猜测、因果图等1)等价类划分我们不能穷举所有可能的输入数据来进行测试，因此，一个有效的方法是选取少量具有代表性的输入数据来暴露尽可能多的程序错误。有效数据：符合规格说明书要求的合理的输入数据，主要用来检验程序是否实现了规格说明书中规定的功能；无效数据：不符合规格说明书要求的不合理或非法的输入数据，主要用来检验程序是否做了规格说明书中规定功能以外的事情；如果将所有的有效的、无效的输入数据划分成若干个等价类，那么，有理由假定：如果等价类中的一个输入数据能够检验出程序的一个错误的话，那么等价类中的其它输入数据也能检测出同一个错误；反之，如果等价类中的一个输入数据不能检验出程序的某个错误的话，那么等价类中的其它输入数据也不能检测出这一错误(除非这个等价类的某个子集还属于另一个等价类)。在确定输入数据的等价类时，常常还要分析输出数据等价类，以便根据输出数据等价类导出相应的输入数据的等价类。l 确定等价类在确定等价类时应考虑下列原则：(1) 如果某个输入条件规定了取值范围或值的个数，则可确定一个合理的等价类(输入值或数在此范围内)和两个不合理等价类(输入值或个数小于这个范围的最小值或大于这个范围的最大值)。例如输入值是学生的成绩，范围为0100，确定一个合理的等价类为“0成绩100”，两个不合理的等价类为“成绩0”和“成绩100”。(2) 如果规定了输入数据的一组值，而且程序对不同的输入值作不同的处理，则每个允许的输入值是一个合理等价类，此外还有一个不合理等价类(任何一个不允许的输入值)。例如，输人条件上说明教师的职称可为助教、讲师、副教授及教授4种职称之一，则分别取这四个值作为4个合理等价类，另外把4个职称之外的任何职称作为不合理等价类。(3) 如果规定了输入数据必须遵循的规则，可确定一个合理等价类(符合规则)和若干个不合理等价类(从各种不同角度违反规则)。(4) 如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。以上这些划分输入数据等价类的经验也同样适用于输出数据，这些数据也只是测试时可能遇到的情况的很小部分。为了能正确划分等价类，一定要正确分析被测程序的功能。确定等价类需要积累经验。l 设计测试用例利用等价类设计测试用例的步骤如下： 为每个有效等价类和无效等价类编号； 设计一个新的测试用例以尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，直至所有的有效等价类都被覆盖为止。 为每一个无效的等价类设计一个新的测试用例。每一个无效等价类极有可能发现程序中的错误，而且测试时，当发现一个错误时应该立即排除，所以，每一个无效等价类应该设计成一个测试用例。要求能够对于给定的程序，为该程序设计等价类。2)边界值分析实践证明，大量的错误出现在输入数据和输出数据的边界上。所以，通常将边界值分析方法和其它设计测试用例的方法结合起来使用。采用边界值分析设计测试用例的原则： 如果输入条件规定了值的范围，那么取边界值的左右数据设计测试用例； 如果输入条件规定了值的个数，那么对值的最大个数、最小个数以及相应的左右个数设计测试用例； 对每一个输出条件使用第条 对每一个输出条件使用第条 如果程序的输入或输出是某个有序集(例如顺序文件、线性表、表格)，应注意用该有序集的第一个和最后一个元素设计测试用例。以上几种情况只是列举的例子，实际应用中应尽可能多的考虑所有的边界值。3)错误猜测错误猜测是一种凭直觉和经验推测错误的方法。这种方法没有固定的步骤。4)因果图边界值分析和等价类划分等方法都没有考虑输入条件的组合，但是输入条件的组合通常是数目很大的，因此应该用某种方法来选择输入条件的某个子集，再考虑他们的组合。因果图是一种帮助人们系统地选择一组高效测试用例的方法，其特点是：l 考虑输入条件间的组合关系；l 考虑输出条件对输入条件的依赖关系，即因果关系；l 测试用例发现错误的效率高；l 能检查出功能设计中的某些不一致或遗漏。步骤：l 分割功能说明书；l 识别出原因和结果，并加以编号；l 根据功能说明书中规定的原因和结果之间的关系画出因果图；l 根据功能说明书在因果图中加约束条件l 根据因果图画出判定表l 为判定表的每一列设计一个测试用例。五、测试报告记录测试结果及测试方法等。六、软件维护维护的过程贯穿于软件的整个运行阶段。维护的费用在不断增加。1.软件维护的分类l 改正性维护：在使用过程中发现了隐藏的错误后，为了诊断和改正这些隐藏错误而修改软件的活动；20%l 适应性维护：为了适应软件运行环境的变化而修改软件的活动；25%l 完善性维护：为了扩充或完善软件的功能或性能而修改软件的活动；50%l 预防性维护：为了提高软件的可维护性和可靠性，为将来的进一步改进奠定基础而修改软件的活动；4%2.与维护有关的问题l 要维护一个软件，首先要整理之；l 需要维护的软件往往缺少合格的文档，或者文档资料不全，甚至没有文档。文档对于软件维护是及其重要的；l 软件维护时，不要指望开发人员对你有帮助；l 多数软件在设计时没有考虑今后的维护问题，因此在修改软件时容易引起错误；l 软件维护工作枯燥无味，毫无成就感。设计软件时应该考虑到维护过程中的这些问题，尽可能提高软件的可维护性。3.可维护性影响软件可维护性的三个要素：l 可理解性：非程序编制人员理解软件结构、接口、功能和内部过程的难易程度；l 可测试性：测试和诊断软件(主要指程序)中的错误的难易程度；l 可修改性：修改软件(主要指程序)的难易程度。4.软件维护流程维护过程是一个规模较小的开发过程。同样需要经过需求分析、设计、编码、测试等阶段。第六讲 软件项目管理(没有讲)一、软件管理软件管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预算的范围内，有效地利用人力、财力、资源、技术和工具，使软件系统或产品按原定计划和质量要求如期完成。成本估算：人月费用 进度安排：Gantt图，Pert图风险分析：充分考虑风险，尽量避免风险人员组织：主程序员组；无主程序员组；层次式程序员组。二、软件质量保证软件质量是贯穿软件生存期的一个极为重要的问题，是软件开发过程中所使用的各种开发技术和验证方法的最终体现。因此，在软件生存期中，要特别重视质量的保证，以生成高质量的软件产品。1. 软件质量的定义有各种各样的软件质量定义。下面说明两个定义：ANSI/IEEE std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”；M.J.Fisher定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。软件质量反映了以下三个方面的问题： 软件需求是度量软件质量的基础。不符合需求的软件就没有质量； 在各种标准中定义了一些开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证； 往往会有一些隐含的需求没有明确地提出来。如果软件只满足那些精确定义了的需求而没有满足这些隐含需求，软件质量也不能保证。软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。2. 典型的软件质量的模型 McCall质量模型 互联性(Interoperability)可移植性(Portability)复用性(Reusability)可维护性(Maintainability)可测试性(Testability)灵活性(Flexibility)PRODUCTREVITION产品修正 PRODUCT REVITION产品转移 产品运行PRODUCT OPERATIONS正确性(Correctness)可使用性(Usability)完整性(Integrity)可靠性(Reliability)效率(Efficiency)图1. McCall 软件质量模型1979年McCall等人提出的软件质量模型，其软件质量概念基于11个特性之上，而这11个特性分别面向软件产品的运行、修正、转移。它们与特性的关系如图1所示。进一步，McCall等给出了一个三层次式模型的框架。如图2所示。特性评价准则面向管理观点的产品质量决定产品质量的软件属性定量化地度量软件属性评价准则评价准则图2. McCall质量模型框架度量度量度量McCall等人认为，特性是软件质量的反映，软件属性可用做评价准则，定量化地度量软件属性可知软件质量的优劣。下表给出了McCall等人定义的软件质量特性与评价准则之间的关系。表1.1 McCall定义的软件质量模型 软件质软件 量因质量的 素评价准则 正确性可靠性效率完整性可使用性可维护性灵活性可测试性可移植性复用性互联性可跟踪性完备性一致性安全性容错性准确性简单性执行效率存储效率存取控制存取审查操作性易训练性简明性模块独立性自描述性结构性文档完备性通用性可扩充性可修改性自检性机器独立性软件系统独立性