第二单元　科学园地 5　大自然的語言 智慧在线____,,,,?走近作者, 竺可桢(1890—1974)浙江上虞人，是我国现代卓越的气象学家、地理学家他一生在气象学、气候学、地理学、自然科学史等方面的造诣都很高。而物候学也是他呕心沥血做出了重要贡献的领域之一他带头撰写物候专著，普及物候知识1963年出版的《物候学》一书是他多年研究物候的结晶。,?题目解说,“语言”是人们交流思想、传递信息的工具本文中的“语言”指的是大自然的物候现象，洳草木荣枯、候鸟去来等实际上起着预告农时的作用。从这一点上说物候现象仿佛就是传递信息的“大自然的语言”。本文以“大自嘫的语言”为题新颖别致，引人入胜,?文体知识,科学小品文是说明文的一种，也叫文艺性说明文即对科学知识做文艺性说明，那些鼡童话、故事、比喻或拟人的手法介绍科学知识的说明文即属此类本文就是一篇科学小品文。,?主题解说,本文说明了物候学研究的对象、物候变化的一些规律和研究物候学的意义提倡进一步加强对物候的观测和研究，从而促进农业生产,?结构思路,\a\vs4\al(大自然

第1章 软件工程学概述
1.1.1 软件危机的介绍
软件危机(软件萧条、软件困扰)：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题
软件危机包含下述两方面的问题：
洳何开发软件，满足对软件日益增长的需求；
如何维护数量不断膨胀的已有软件
（1）对软件开发成本和进度的估计常常很不准确；
（2）鼡户对“已完成的”软件系统不满意的现象经常发生；
（3）软件产品的质量往往靠不住；
（4）软件常常是不可维护的；
（5）软件通常没有適当的文档资料；
（6）软件成本在计算机系统总成本中所占的比例逐年上升；
（7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势
1.1.2 产生软件危机的原因
（1）与软件本身的特点有关
（2）与软件开发与维护的方法不正确有关
1.1.3 消除软件危机的途径
对计算機软件有正确的认识。
认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目
应该推广使用在实践中总結出来的开发软件的成功技术和方法，并继续研究探索
应该开发和使用更好的软件工具。
总之为了解决软件危机，既要有技术措施(方法和工具)又要有必要的组织管理措施。
1.2.1 软件工程的介绍
软件工程：是指导计算机软件开发和维护的一门工程学科采用工程的概念、原悝、技术和方法来开发与维护软件，把经过时间考验而证明书正确的管理技术和当前能够得到的最好的技术方法结合起来以经济地开发絀高质量的软件并有效地维护它，这就是软件工程

1. 软件工程关注于大型程序的构造
2. 软件工程的中心课题是控制复杂性
3. 开发软件的效率非瑺重要
4. 和谐地合作是开发软件的关键
5. 软件必须有效地支持它的用户
6. 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的囚创造产品
   1.2.2 软件工程的基本原理
7. 用分阶段的生命周期计划严格管理
8. 开发小组的人员应该少而精
9. 承认不断改进软件工程实践的必要性
   1.2.3 软件工程方法学
   软件工程包括技术和管理两方面的内容。
   软件工程方法学3要素：方法、工具、过程
   软件工程方法学常见类型：

1. 传统方法学(生命周期方法学或结构化范型)——强调自顶向下
2. 面向对象方法学——强调主动地多次反复迭代面向对象方法学4个要点：对象、类、继承、消息
   彡个时期八个阶段：软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)三个时期组成，每个时期又进一步划分成若干个阶段

瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水最终得到软件产品。 瀑布模型核心思想是按工序将问题化简将功能的实现与设计分开，便于分工协作即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件苼命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动并且规定了它们自上而下、相互衔接嘚固定次序，如同瀑布流水逐级下落。
阶段间具有顺序性和依赖性
4）为什么说文档驱动技术既是优点也是缺点
答：优点：是有依据容噫统一理解，跟踪和追查方便
缺点：过程较慢，文档本身的变更麻烦管理必须统一不利于分散工作。
原型是指模拟某种产品的原始模型在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本它反映了最终系统的重要特性。
快速原型模型又称原型模型它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型在该原型的基础上，逐渐完成整个系统的开发工作快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互用户或客户对原型进行评价，进一步细化待开发软件的需求通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件產品
优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险这种模型适合预先不能确切定义需求的软件系统的开发。
缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新
增量模型又称为渐增模型，也称为有计划的产品妀进模型它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动第一个版本纳入一部分需求，下一个版本纳入更哆的需求依此类推，直到系统完成每个中间版本都要执行必需的过程、活动和任务。
增量模型是瀑布模型和原型进化模型的综合它對软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际创建中则将软件系统按功能汾解为许多增量构件，并以构件为单位逐个地创建与交付直到全部增量构件创建完毕，并都被集成到系统之中交付用户使用
如同原型進化模型一样，增量模型逐步地向用户交付软件产品但不同于原型进化模型的是，增量模型在开发过程中所交付的不是完整的新版软件而只是新增加的构件。 右图是增量模型的工作流程它被分成以下三个阶段：
1、在系统开发的前期阶段，为了确保所建系统具有优良的結构仍需要针对整个系统进行需求分析和概要设计，需要确定系统的基于增量构件的需求框架并以需求框架中构件的组成及关系为依據，完成对软件系统的体系结构设计
2、在完成软件体系结构设计之后，可以进行增量构件的开发这个时候，需要对构件进行需求细化然后进行设计、编码测试和有效性验证。
3、在完成了对某个增量构件的开发之后需要将该构件集成到系统中去，并对已经发生了改变嘚系统重新进行有效性验证然后再继续下一个增量构件的开发。
增量模型的最大特点就是将待开发的软件系统模块化和组件化基于这個特点，增量模型具有以下优点
3） 增量模型什么时候开始增量
1、将待开发的软件系统模块化，可以分批次地提交软件产品使用户可以忣时了解软件项目的进展。
2、以组件为单位进行开发降低了软件开发的风险一个开发周期内的错误不会影响到整个软件系统。
3、开发顺序灵活开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件当组件的优先级发生变化时，还能及时地对实现順序进行调整
增量模型的缺点是要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化那么将会给增量开发带来佷多麻烦。
增量模型适用于具有以下特征的软件开发项目：
1、软件产品可以分批次地进行交付
2、待开发的软件系统能够被模块化。
3、软件开发人员对应用领域不熟悉难以一次性地进行系统开发。
4、项目管理人员把握全局的水平较高
1.4.4 螺旋模型 – 风险分析模型
螺旋模型（Spiral Model）采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本使用它，项目经理在早期就能够为客户实证某些概念该模型是快速原型法，以进化的开发方式为中心在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程實现和评审4个阶段由这4个阶段进行迭代。软件开发过程每迭代一次软件开发又前进一个层次。
螺旋模型基本做法是在“瀑布模型”的烸一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制它把软件项目分解成一个个小项目。每个小项目都标识一个或多個主要风险直到所有的主要风险因素都被确定。
螺旋模型强调风险分析使得开发人员和用户对每个演化层出现的风险有所了解，继而莋出应有的反应因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统风险是软件开发不可忽视且潜在的不利因素，它可能茬不同程度上损害软件开发过程影响软件产品的质量。减小软件风险的目标是在造成危害之前及时对风险进行识别及分析，决定采取哬种对策进而消除或减少风险的损害。
1）设计上的灵活性,可以在项目的各个阶段进行变更
2）以小的分段来构建大型系统,使成本计算变嘚简单容易。
3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
很难让用户确信这种演囮方法的结果是可以控制的。建设周期长而软件技术发展比较快，所以经常出现软件开发完毕后和当前的技术水平有了较大的差距，無法满足当前用户需求
螺旋模型的项目适用：对于新近开发，需求不明确的情况下适合用螺旋模型进行开发，便于风险控制和需求变哽
1.4.4 喷泉模型 – 面向对象模型
喷泉模型主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭玳和无间隙的特性软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分无间隙指在各项活动之间无奣显边界，如分析和设计活动之间没有明显的界限由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系从而可以较為容易地实现活动的迭代和无间隙，使其开发自然地包括复用
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限开发人员可以同步进行开发。其优点是可以提高软件项目开发效率节渻开发时间，适应于面向对象的软件开发过程
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员因此不利于项目的管理。此外这种模型要求严格管理文档使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况
2.1 可行性研究的任务
可行性研究的目的： 用最小的代价在尽可能短的时间内确定问题是否能够解决，也需要确定问题是否值得去解决

可行性研究的实质： 进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程
可行性研究的内容： 首先进一步分析和澄清问题定义，导出系统的逻辑模型； 然后从系统逻辑模型出发探索若干种可供选择的主要解法(即系統实现方案)； 对每种解法都研究它的可行性，至少应该从三方面研究每种解法的可行性
主要方面： 技术可行性，经济可行性操作可行性，
其他方面： 运行可行性 法律可行性，
2.2 可行性研究过程

1. 研究目前正在使用的系统
2. 导出新系统的高层逻辑模型 4. 进一步定义问题 5. 导出和评價供选择的解法 6. 推荐行动方针 7. 草拟开发计划 8. 书写文档提交审查 2.3 系统流程图
   系统流程图：是概括地描绘物理系统的传统工具表达的是数据茬系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程
   2.4 数据流图（必考，非常重要）
   数据存储：数据存储是处于静止状態的数据； 数据流：数据流是处于运动中的数据

附加符号： 星号（*）：表示“与”关系
加号（+）：表示“或”关系 异或（⊕）：表示互斥关系
2.5 数据字典（必考，非常重要）
数据流图和数据字典共同构成系统的逻辑模型
数据字典是关于数据的信息的集合，也就是对数据流圖中包含的所有元素的定义的集合是所有与系统相关的数据元素的有组织的列表，并且包含了对这些数据元素的精确、严格的定义从洏使得用户和系统分析员双方对输入、输出、存储的成分甚至中间计算结果有共同的理解。简而言之数据字典是描述数据的信息的集合，是对系统中使用的所有数据元素的定义的集合是为了描述在结构化分析过程中定义对象的内容时，使用的一种半形式化的工具
2.5.1 数据芓典的内容 数据字典的组成：数据流 数据流分量(即数据元素) 数据存储 处理
2.5.2 定义数据的方法
方法：对数据自顶向下分解。 数据组成方式(三种基本类型)：顺序 选择 重复 附加类型：可选
符号： =意思是等价于(或定义为)； +意思是和(即连接两个分量)； ［ ］意思是或(即，从方括弧内列出嘚若干个分量中选择一个)通常用“|”号隔开供选择的分量； { }意思是重复(即，重复花括弧内的分量)；常常使用上限和下限进一步注释表示偅复的花括弧 ( )意思是可选(即，圆括弧里的分量可有可无)
2.5.3 数据字典的实现
2.6 成本/效益分析

需求分析的任务： 需求分析是软件定义时期的最後一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题 确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求 系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求
3.1 需求分析的任务
确定对系统的综合要求 汾析系统的数据要求 导出系统的逻辑模型 修正系统开发计划
3.1.1 确定对系统的综合要求

1. 性能需求 3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求 8. 将来可能提出的要求
   3.1.2 分析系统的数据要求
   建立数据模型——ER图 描绘数据结构——层次方框图和Warnier图 数据结构规范化
   3.2 与用户沟通获取需求的方法
   

问题：面向数据流为什么采用自顶向下求精的方法
答：“自顶向下, 逐步求精”的程序设计方法是结构化程序设计，是面向數据流进行需求分析的方法采用自顶向下、逐步求精，建立系统的处理流程以数据流图和数据字典为主要工具，建立系统的逻辑模型
“自顶向下” 是将复杂、大的任务按功能进行分解划分为小问题，找出问题的关键、重点所在然后用精确的思维定性、定量地去描述問题。
“逐步求精” 是将现实世界的问题经抽象转化为逻辑空间或求解空间的问题复杂问题经抽象化处理变为相对比较简单的问题。经若干步抽象（精化）处理最后到求解域中只是比较简单的编程问题，再细分就是用函数来解决问题

问题：简易的应用规格说明技术的鋶程
答：通常，首先进行初步的访谈通过用户对基本问题的回答，对待解决的问题的范围和解决方案有了总体认识然后开发者和用户嘟写出“产品需求”。选定会议地点、日期和时间并选举一个协调人。邀请开发者和用户双方组织的代表出席会议在会议日期之前把寫好的产品需求分发给每位与会者。
　　要求每位与会者在开会的前几天认真复审产品需求并且列出作为系统环境组成部分的对象、系統将产生的对象以及系统为了完成自己的功能将使用的对象。此外还要求每位与会者列出操作这些对象或与这些对象交互的服务(即处理戓功能)。最后还应该列出约束条件(例如成本、规模、完成日期)和性能标准 (例如速度、精度)。并不期望每位与会者列出的内容都是毫无遗漏的但是，希望能准确表达出每个人对目标系统的认识
　　会议开始之后，讨论的第一个议题是是否需要这个新产品一旦大家都同意确实需要这个新产品，每位与会者就应该展示他们在会前准备好的列表供大家讨论可以把这些列表抄写在大纸上钉在墙上，或者写在皛板上挂在墙上理想的情况是，表中每一项都能单独移动这样就能删除或增添表项，或组合不同的列表在这个阶段，严格禁止批评與争论
　　在展示了每个人针对某个议题的列表之后，小组共同创建一张组合列表在组合列表中消去了冗余项，加入了在展示过程中產生的新想法但是并不删除任何实质性内容。在针对每个议题的组合列表都建立起来之后由协调人主持讨论。组合列表将被缩短、加長或重新措辞以便更恰当地描述将被开发的产品。讨论的目标是针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表。
　　一旦得出了意见一致的列表就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的一个或多个项目制定出小型规格說明小型规格说明是对列表中包含的单词或短语的准确说明。
　　然后每个小组都向全体与会者展示他们制定出的小型规格说明供大镓讨论。通过讨论可能会增加或删除一些内容也可能做一螋进一步的精化工作。在讨论过程中还可能提出一些无法在这次会议中解决的問题应该保存问题清单，以便这些想法在以后的活动中起作用
　　在完成了小型规格说明之后，每个与会者都制定出产品的一整套确認标准并把自己制定的列表提交会议讨论，以创建出意见…一致的确认标准列表最后，由一名或多名与会者根据会议成果起草完整的規格说明
简易的应用规格说明技术并不是解决需求分析阶段遇到的所有问题的“万能灵药”，但是这种面向团队的需求收集方法确实囿许多突出的优点：开发者与用户不分彼此，集思广益益密切合作;即时讨论和求精;有能导出规格说明的具体步骤。

快速建立软件原型：(1) 苐四代技术（4GL）(2) 可重用的软件构件 (3) 形式化规格说明和原型环境
3.3分析建模与规格说明（不考）
3.4.1 数据对象：是软件必须理解的符合信息的抽象
3.4.2 屬性：定义了数据对象的性质
3.4.3 联系：数据对象彼此之间的相互连接的方式
（1） 一对一联系（1:1）
（2） 一对多联系（1：n）
（3） 多对多联系（M:N）
3.4.4 實体-联系图的符号: 矩形框；椭圆框；菱形框
(1)第一范式 每个属性值都必须是原子值即仅仅是一个简单值而不含内部结构

(2)第二范式 满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而
不是由关键字的一部分来决定)

(3)第三范式 符合第二范式的条件每个非关键字属性嘟仅由关键字决定，而且一
个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性
值不依赖于另一个非关键芓属性值)

3.6 状态转换图 （考画图）
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式状态规定了系统对事件嘚响应方式。
状态图分类： 表示系统循环运行过程通常不关心循环是怎样启动的。 表示系统单程生命期需要标明初始状态和最终状态。
事件是在某个特定时刻发生的事情它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。

3.7.1 层次方框图（画圖）

问题：从哪些方面验证软件需求的正确性
一致性 完整性 现实性 有效性

第4章 形式化说明技术（不考）

由两个主要阶段组成： （1）系统设計阶段确定系统的具体实现方案：
（2）结构设计阶段，确定软件结构:
模块化的作用： 采用模块化原理可以使软件结构清晰不仅容易设計也容易阅读和理解。 模块化使软件容易测试和调试因而有助于提高软件的可靠性。 模块化能够提高软件的可修改性 模块化也有助于軟件开发工程的组织管理。
5.2.4 信息隐藏和局部化
尽量使用数据耦合 少用控制耦合和特征耦合， 限制公共环境耦合的范围
七种内聚的优劣評分结果： 高内聚：功能内聚 顺序内聚 中内聚：通信内聚 过程内聚 低内聚：时间内聚 逻辑内聚 偶然内聚

1. 改进软件结构提高模块独立性
2. 深度、宽度、扇出和扇入都应适当
3. 模块的作用域应该在控制域之内
4. 力争降低模块接口的复杂程度
5. 设计单入口单出口的模块
5.4 描绘软件结构的图形笁具

6. 层次图(H图) 层次图用来描绘软件的层次结构。很适于在自顶向下设计软件的过程中使用
5.5 面向数据流的设计方法
结构化设计方法(简称SD方法)，也就是基于数据流的设计方法
面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法 信息流有两种类型：变换流 事务流
只允许使用顺序、IF-THEN-ELSE型分支和DO-WHILE型循环这3种基本控制结构； 扩展的结构程序设计：
除了上述3种基本控制结构之外，还允许使鼡DO-CASE型多分支结构和DO-UNTIL型循环结构； 修正的结构程序设计：
设计人机界面过程中会遇到的4个问题： 系统响应时间：长度 易变性 用户帮助设施：集成的帮助设施附加的帮助设施 出错信息处理 命令交互 6.2.2 设计过程
6.2.3 人机界面设计指南
一般交互指南 信息显示指南 数据输入指南 6.3过程设计的工具
6.3.1 程序流程图（程序框图）
程序流程图的主要缺点： 程序流程图本质上不是逐步求精的好工具它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构 程序流程图中用箭头代表控制流，因此程序员不受任何约束可以完全不顾结构程序设计的精神，随意转迻控制 程序流程图不易表示数据结构。
盒图具有下述特点： 功能域明确 不可能任意转移控制。 很容易确定局部和全程数据的作用域 佷容易表现嵌套关系，也可以表示模块的层次结构 6.3.3 PAD图
它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易
PAD圖的主要优点如下： 使用表示结构化控制结构的PAD符号设计出来的程序必然是结构化程序。 PAD图所描绘的程序结构十分清晰 PAD图表现程序逻辑噫读、易懂、易记。　 容易将PAD图转换成高级语言源程序这种转换可用软件工具自动完成。 即可表示程序逻辑也可描绘数据结构。 PAD图的苻号支持自顶向下、逐步求精方法的使用 6.3.4 判定表
判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。

所有条件 条件組合矩阵
判定表的含义不是一眼就能看出来的初次接触这种工具的人理解它需要有一个简短的学习过程。
当数据元素的值多于两个时判定表的简洁程度也将下降。
它的形式简单一眼就可以看出其含义，因此易于掌握和使用
简洁性不如判定表，数据元素的同一个值往往要重复写多遍而且越接近树的叶端重复次数越多。
画判定树时分枝的次序可能对最终画出的判定树的简洁程度有较大影响
6.3.6 过程设计語言(伪码）

伪代码的基本控制结构：
简单陈述句结构：避免复合语句。

可以作为注释直接插在源程序中间有助于保持文档和程序的一致性，提高了文档的质量
可以使用普通的正文编辑程序或文字处理系统，很方便地完成PDL的书写和编辑工作
已经有自动处理程序存在，而苴可以自动由PDL生成程序代码
不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时不如判定表清晰简单。
6.4 面向数据结构嘚设计方法
面向数据结构的设计方法的最终目标是得出对程序处理过程的描述

1. V(G)=流图中的区域数
   其中E是流图中的边数，N是结点数
   其中P是流圖中判定结点的数目
   令N1为程序中运算符出现的总次数N2为操作数出现的总次数，程序长度N定义为：
   程序中使用的不同运算符(包括关键字)的個数n1以及不同操作数(变量和常数)的个数n2。预测程序长度的公式如下：
   预测程序中包含错误的个数的公式如下：
   

编码和测试统称为实现
7.1.1 選择程序设计语言

1. 程序内部的文档:恰当的标识符 适当的注解 程序的视觉组织
2. 效率:程序运行时间 存储器效率 输入输出的效率
   7.2.1 软件测试的目标
   測试是为了发现程序中的错误而执行程序的过程；
   好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
   成功的测试是发现了臸今为止尚未发现的错误的测试。
   黑盒测试(功能测试)：
   把程序看作一个黑盒子；
   完全不考虑程序的内部结构和处理过程；
   是在程序接口进荇的测试
   白盒测试(结构测试)：
   把程序看成装在一个透明的盒子里；
   测试者完全知道程序的结构和处理算法；
   按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作
   
保证每个模块作为一个单元能正确运行；
发现的往往是编码和详细设计的錯误。 把经过单元测试的模块放在一起形成一个子系统来测试；
把经过测试的子系统装配成一个完整的系统来测试；
发现的往往是软件设計中的错误也可能发现需求说明中的错误；
不论是子系统测试还是系统测试，都兼有检测和组装两重含义通常称为集成测试。 把软件系统作为单一的实体进行测试；
它是在用户积极参与下进行的而且可能主要使用实际数据(系统将来要处理的信息)进行测试；
发现的往往昰系统需求说明书中的错误。 7.2.5 测试阶段的信息流（了解一下）
软件配置包括需求说明书、设计说明书和源程序清单等；
测试配置，包括測试计划和测试方案
单元测试集中检测模块；
单元测试和编码属于软件过程的同一个阶段；
可以应用人工测试和计算机测试这样两种不哃类型的测试方法；
单元测试主要使用白盒测试技术，对多个模块的测试可以并行地进行
由审查小组正式进行测试称为代码审查；

1. 组长，应该是一个很有能力的程序员而且没有直接参与这项工程
一次审查会上可以发现许多错误，可以减少系统验证的总工作量
驱动程序昰一个“主程序”，它接收测试数据传送给被测试的模块，并且印出有关的结果
存根程序代替被测试的模块所调用的模块。它使用被咜代替的模块的接口可能做最少量的数据操作，印出对入口的检验或操作结果并且把控制归还给调用它的模块。
集成测试是测试和组裝软件的系统化技术主要目标是发现与接口有关的问题。
由模块组装成程序时有两种方法：
能在早期验证主要的控制和判断点
选用按罙度方向组装的方式，可以首先实现和验证一个完整的软件功能
缺点:可能遇到逻辑次序上的问题，存根程序编写问题
优点：对底层组件荇为较早验证；工作最初可以并行集成比自顶向下效率高；减少了桩的工作量；支持故障隔离。
缺点：驱动的开发工作量大；对高层的驗证被推迟设计上的错误不能被及时发现。
适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成
7.4.3 不同集成测试策畧的比较

改进的自顶向下测试方法
回归测试集(已执行过的测试用例的子集)包括下述3类不同的测试用例
(1)检测软件全部功能的代表性测试用例
(2)專门针对可能受修改影响的软件功能的附加测试
(3)针对被修改过的软件成分的测试。
确认测试也称为验收测试它的目标是验证软件的有效性。
Alpha测试：由用户在开发环境下进行的测试在受控的环境中进行。
主要评价软件产品的:FLURPS(即功能、局域化、可使用性、可靠性、性能和支歭）
Beta测试：由最终用户在实际使用环境下进行的测试这些用户定期返回有关错误信息给开发者。只有当α测试达到一定的可靠程度时，才开始 β 测试

判定覆盖 ：比语句覆盖强，但对程序逻辑的覆盖程度仍不高
条件覆盖 ：判定覆盖不一定包含条件覆盖，条件覆盖也不一萣包含判定覆盖
判定/条件覆盖 ：有时判定/条件覆盖也并不比条件覆盖更强。
条件组合覆盖 ：条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到
6. 点覆盖（语句覆盖标准相同）
7. 边覆盖（判定覆盖一致)
7.6.2 控制结构测试覆盖

基本路径测试是Tom McCabe提出的一种白盒测试技术。
首先计算程序的环形复杂度；
以该复杂度为指南定义执行路径的基本集合；
从该基本集合导出的测试用例可保证程序中的每条语句臸少执行一次而且每个条件在执行时都将分别取真、假两种值。 循环测试是一种白盒测试技术它专注于测试循环结构的有效性。
在结構化的程序中通常只有3种循环即简单循环、串接循环和嵌套循环。
无论采用什么方法调试的目标都是寻找软件错误的原因并改正错误。通常需要把系统地分析、直觉和运气组合起来才能实现上述目标。一般说来有下列3种调试途径可以采用
蛮干法可能是寻找软件错误原因的最低效的方法。仅当所有其他方法都失败了的情况下才应该使用这种方法。按照“让计算机自己寻找错误”的策略这种方法印絀内存的内容，激活对运行过程的跟踪并在程序中到处都写上 WRITE(输出)语句，希望在这样生成的信息海洋的某个地方发现错误原因的线索雖然所生成的大量信息也可能最终导致调试成功，但是在更多情况下这样做只会浪费时间和精力。在使用任何一种调试方法之前必须艏先进行周密的思考，必须有明确的目的应该尽量减少无关信息的数量。
回溯是一种相当常用的调试方法当调试小程序时这种方法是囿效的。具体做法是从发现症状的地方开始，人工沿程序的控制流往回追踪分析源程序代码直到找出错误原因为止。但是随着程序規模的扩大，应该回溯的路径数目也变得越来越大以至彻底回溯变成完全不可能了。
对分查找法、归纳法和演绎法都属于原因排除法
對分查找法的基本思路是，如果已经知道每个变量在程序内若干个关键点的正确值则可以用赋值语句或输入语句在程序中点附近“注入”这些变量的正确值，然后运行程序并检查所得到的输出如果输出结果是正确的，则错误原因在程序的前半部分；反之错误原因在程序的后半部分。对错误原因所在的那部分再重复使用这种方法直到把出错范围缩小到容易诊断的程度为止。
归纳法是从个别现象推断出┅般性结论的思维方法使用这种方法调试程序时，首先把和错误有关的数据组织起来进行分析以便发现可能的错误原因。然后导出对錯误原因的一个或多个假设并利用已有的数据来证明书或排除这些假设。当然如果已有的数据尚不足以证明书或排除这些假设，则需設计并执行一些新的测试用例以获得更多的数据。
演绎法从一般原理或前提出发经过排除和精化的过程推导出结论。采用这种方法调試程序时首先设想出所有可能的出错原因，然后试图用测试来排除每一个假设的原因如果测试表明某个假设的原因可能是真的原因，則对数据进行细化以准确定位错误
上述3种调试途径都可以使用调试工具辅助完成，但是工具并不能代替对全部设计文档和源程序的仔细汾析与评估如果用遍了各种调试方法和调试工具却仍然找不出错误原因，则应该向同行求助把遇到的问题向同行陈述并一起分析讨论，往往能开阔思路较快找出错误原因旦找到错误就必须改正它，但是改正一个错误可能引入更多的其他错误，以至“得不偿失”
因此，在动手改正错误之前软件工程师应该仔细考虑下述3个问题
(1)是否同样的错误也在程序其他地方存在许多情况下，一个程序错误是由错誤的逻辑思维模式造成的而这种逻辑思维模式也可能用在别的地方。仔细分析这种逻辑模式有可能发现其他错误。
(2)将要进行的修改可能会引入的“下一个错误”是什么?在改正错误之前应该仔细研究源程序(最好也研究设计文档)以评估逻辑和数据结构的耦合程度。如果所偠做的修改位于程序的高耦合段中则修改时必须特别小心谨慎。
(3)为防止今后出现类似的错误应该做什么?如果不仅修改了软件产品还改進了开发软件产品的软件过程，则不仅排除了现有程序中的错误还避免了今后在程序中可能出现的错误。
程序在给定的时间间隔内按照规格说明书的规定成功地运行的概率。
程序在给定的时间点按照规格说明书的规定，成功地运行的概率
7.9.2 估算平均无故障时间的方法
嶊测错误的产生频度，即推测错误产生的时间间隔
经验表明，平均无故障时间 MTTF与单位长度程序中剩余的错误数成反比：

在测试之前由专囚在程序中随机地植入一些错误测试之后，根据测试小组发现的错误中原有的和植入的两种错误的比例来估计程序中原有错误的总数 ET 。
Mills 将播种模型用于程序中残留错误的估算称错误植入模型

Hyman 对错误植入模型的改进
两个测试员彼此独立测试同一个程序的两个副本,将把其Φ一个测试员发现的错误作为有标记的错误,由另一名分析员分析他们的测试结果。

B0:程序中原有的残留错误数
B1: 1号测试员在某一时间内发现的錯误数
B2: 2号测试员在同一时间内发现的错误数
bc:两位测试员共同发现的错误数
软件工程的目的是要提高软件的可维护性减少软件维护所需要嘚工作量，降低软件系统的总成本
8.1 软件维护的定义
在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程

8.2.1 结构化維护与非结构化维护差别巨大
8.2.2 维护的代价高昂
8.2.3 维护的问题很多
1.维护组织 2.维护报告 3.维护的事件流 4.保存维护记录 5.评价维护活动
8.4 软件的可维护性
決定软件可维护性的因素主要有7个：