学习体会：高教自考软件工程课程概说总结

学习体会：高教自考软件工程课程概说总结

1.学习体会：高教自考软件工程课程概说总结 篇一

一.什么是软件

1.满足功能要求和性能的指令或计算机程序集合;2.处理信息的数据结构;3.描述程序功能以及程序如何操作和使用所要求的文档;

二.软件危机以及产生软件危机的原因

1.软件开发生产率提高的速度,远远跟不上计算机迅速普及的趋势.软件产品“供不应求”.2.软件成本在计算机系统总成本中所占的比例逐年上升.3.软件开发人员和用户之间的信息交流往往很不充分,用户对“已完成的”的软件系统不满足的现象经常发生.4.软件产品的质量不容易保证.5.软件产品常常是不可维护的.6.软件产品的重用性差,同样的软件多次重复开发.7.软件通常没有适当的文档资料.产生软件危机的原因可归结为两个重要的方面: 软件生产本身存在的复杂性;软件开发所使用的方法和技术.三.有哪些软件工程方法学及其要素

1.使用最广泛的软件工程方法学是结构化方法学和面向对象的方法学.2.要素:方法,工具和过程.四.什么是软件生存周期 有哪些活动

4.1软件生存周期

一个软件从提出开发要求开始到软件废弃不用的整个过程.4.2 开发活动

可行性分析和项目开发计划,需求分析和定义,软件设计(先后细分为:概要设计和详细设计),编码,测试和运行维护 4.3 各活动阶段主要文档

4.3.1可行行分析和项目开发计划 可性行研究报告 项目开发计划

4.3.2需求分析中的文档 需求规格说明书 初步用户使用手册 确认测试计划

修改完善的软件开发计划 4.3.3 概要设计阶段文档 概要设计说明书 数据库说明书 用户手册

修订的测试计划(测试的策略,方法,步骤)4.4.4 详细设计阶段 详细设计说明书 4.4.5 系统测试阶段 系统测试计划文档

五.有哪些主要生命周期模型

瀑布模型,原型开发模型(快速原型模型,演化模型,增量模型),螺旋模型,喷泉模型,基于知识的模型和变化模型.5.1 瀑布模型

瀑布模型(传统的软件周期模型)严格遵循软件生命周期各阶段的固定顺序:计划,分析,设计,编程,测试和维护,上一阶段完成后才能进入到下一阶段,整个模型就像一个飞流直下的瀑布 优点:可强迫开发人员采用规范的方法,严格规定了各阶段必须提交的文档;要求每一阶段结束后,都要进行严格的评审.与它最相适应的开发方法是结构化方法.缺点:不适应用户需求的改动.5.2 原型模型

5.2.1 快速原型模型

快速原型的用途是获知用户的真正需求,一旦需求确定了,原型即被抛弃.主要用于需求分析阶段.不追求也不可能要求对需求的严格定义,而是采用了动态定义需求的方法,所以不能定义完善的文档.特征:简化项目管理,尽快建立初步需求,加强用户参与和决策.具有广泛技能水平的原型化人员是原型实施的重要保证.原型化人员应该是具有经验与才干,训练有素的专业人员.衡量原型化人员能力的重要标准是他是否能够从用户的模糊描述中快速获取需求.5.2.2 演化模型

在快速原型模型中,原型的用途是获知用户的真正需求,一旦需求确定了,原型即被抛弃.而演化模型应用于整个软件开发过程,是从初始模型逐步演化为最终软件产品的渐进过程.也就是说,快速原型模型是一种“抛弃式”的原型化方法,而演化模型则是一种“渐进式”的原型化方法.5.2.3增量模型

增量模型主要用于设计阶段,把软件产品划分为一系列的增量构件,分别进行设计,编程,集成和测试.新的增量构件不得破坏已经开发出来的产品 5.2.4 原型模型小结

从下面的有关原型化方法的叙述中,选择出正确的叙述:(1)快速原型方法是一种企图克服传统软件周期模型缺点的开发方法.(2)在用户的数据资源没有得到很好地组织和管理的时候,应该使用原型化方法.(3)在用户没有明确地肯定其需求的时候,应该使用原型化方法.(4)在用户不希望把自己的时间花在软件开发过程中的时候,应该使用原型化方法.(5)使用原型化方法时应该使用第三代编程语言.(6)原型化加强了开发过程中用户的参与和决策.(7)原型化方法大致可分为三类:抛弃式,演化式和递增式.(8)原型化方法大致可分为演化式和递增式.(9)采用原型化方法时,软件的开发成本较高.(10)采用原型化方法时,关键的因素是建立原形的速度,而不是原形运行的效率.5.3 螺旋模型

螺旋模型综合了瀑布模型和原型模型中的演化模型的优点,还增加了风险分析.螺旋线第一圈的开始点可能是一个概念项目.从第二圈开始,一个新产品开发项目开始了,新产品的演化沿着螺旋线进行若干次迭代,一直转到软件生命期结束.5.4 喷泉模型

喷泉模型主要用于描述面向对象的开发过程.喷泉一词体现了面向对象开发过程的迭代和无间隙特征.六.软件过程基础知识 6.1 软件过程

软件过程是指人们用于开发和维护软件及相关产品的一系列活动,包括软件工程过程和软件管理过程.6.2 评估工具

软件过程的评估,通常采用软件能力成熟度 模型(Capability Maturity Model,CMM).CMM1.1的5个等级(由低级到高级): 初始级

软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力,管理是反应式(消防式)的.可重复级

建立了基本的项目管理过程来跟踪费用,进度和功能特性.制定了必要的过程纪律,能重复早先类似应用项目取得的成功.已定义级

已将软件管理和工程两方面的过程文档化,标准化,并综合成该组织的标准化软件过程.所有项目均使用经标准,裁减的标准软件过程来开发和维护软件.已管理级

收集对软件过程和产品质量的详细度量,对软件过程和产品都有定量的理解与控制.优化级

加强了定量分析,通过来自过程质量反馈和来自新观念,新技术的反馈使过程能持续不断地改进.七.软件工程项目管理基本知识

软件项目管理开始于任何技术活动之前,并且贯穿于整个的软件生命周期.软件工程项目管理一般分为时间管理,成本管理,人力资源管理,风险管理.7.1时间管理 7.1.1 Gantt图

是一种简单的水平条形图,它以水平线段表示子任务的工作阶段,线段的起点和终点分别对应着子任务的起始时间,线段长度指示完成该任务所需要的时间.甘特图的优点:直观简明,易学易绘,可从图上清楚地标出子任务间的时间对比,但它也有 缺点:

(a)不能显示地描绘各项彼此间的依赖关系;(b)进度计划的关键部分不明显,难以判断哪些部分应当是主攻和主控的对象;(c)计划中有潜力的部分以及潜力的大小不明确,往往造成潜力的浪费.7.1.2 PERT网图与关键路径

PERT网图是一个由箭头(标识任务)和结点(标识事件)组成的有向图.将网络方法用于工作计划安排的评审和检查.开发模块A,B,C模块的任务网络图 PERT图不仅给出了每个任务的开始时间,结束时间和完成该任务所需的时间,还给出了任务之间的依赖关系,即哪些任务完成后才能开始另一些任务,以及如期完成整个工程的“关键路径”.关键路径(Critical Path)是由一连串的任务所组成的链,距离最大的一条路径.软件项目的管理人员应该密切注视关键任务的进展情况.如果希望缩短工期,只有往关键任务中增加资源才会有效果.7.2成本管理

一种常用的成本估算方法是先估计完成软件项目所需的工作量(人月数),然后根据每个人月的代价(金额)计算机软件的开发费用: 开发费用 = 人月数×每个人月的代价

另一种方法是估计软件的规模(通常指源代码行数),然后根据每行源代码的平均开发费用(包括分析,设计,编码,测试所花的费用),计算机软件的开发费用: 开发费用=源代码行数×每行平均费用

估算源代码行数时,可以请n为有经验的专家,每位专家对软件给出3各估计值: ai---最少源代码行数(该软件可能的最小规模)bi---最大源代码行数(该软件可能的最大规模)mi---最可能的代码行数(该软件最可能的规模)然后计算出每位专家的估算期,n位专家的估算期望值的平均值就是代码行数的估算值.7.3 其他管理 人力资源管理 风险管理

风险管理的主要活动有风险识别,风险估算,风险评价和风险控制.八.模块化基本知识

模块是指执行某一特定任务的数据和可执行语句程序元素的集合,通常是指可通过名字来访问的过程,函数,子程序或宏调用等.模块化就是将一个待开发的软件划分成若干个可完成某一子功能的模块,每个模块可独立地开发,测试,最后组装成完整的程序.8.1模块特性 8.1.1 可分解性

如果一种设计方法提供了将问题分解成子问题的系统化机制,它就能降低整个系统的复杂性,从而实现一种有效的模块化解决方案.8.1.2 可组装性

如果一种设计方法使现存的(可复用的)设计构件能被组装成新系统,它就能提供一种不需要一切从头开始的模块化解决方案.8.1.3 可理解性

如果一个模块可以作为一个独立的单位(不用参考其他模块)被理解,那么它就易于构造和修改.8.1.4 连续性

如果对系统需求的微小修改只导致对单个模块,而不是整个系统的修改,则修改引起副作用就会被最小化.8.1.5 保护性

如果模块内部出现异常情况,并且它的影响限制在模块内部,不会影响其他模块,则错误引起的副作用就会被最小化.8.2 模块与模块的耦合性

耦合是对一个软件结构内不同模块之间互连程序的度量.耦合可以分成下列几种,它们之间的耦合度由高到低排列.8.2.1 内容耦合

直接操作或修改另一模块的数据,或不通过正常入口转入另一个模块.软件设计时应坚决禁止内容耦合,应设计成单入口,单出口的模块,避免病态连接.8.2.2 公共耦合

多个模块引用同一全局数据区.例如,C语言中的external数据类型,磁盘文件等都是全局数据区.8.2.3 外部耦合

模块与软件以外的环境有关联.例如,输入输出把一个模块与特定的设备,格式,通信协议耦合在一起.8.2.4 控制耦合

一模块明显把开关量,名字等信息送入另一模块,控制另一模块的功能.8.2.5 标记耦合

两个模块之间通过传递公共指针或地址相互作用的耦合.8.2.6 数据耦合

模块间通过传递数据交换信息.8.2.7 非直接耦合(无耦合)模块间无任何关系,独立工作

原则上讲,模块化设计总是希望模块之间的耦合表现为非直接耦合方式.在以上耦合中,耦合度从高到低,内容耦合度最高,非直接耦合度最低.8.3 模块的内聚性

内聚是指一个模块内各个元素彼此结合的紧密程序,它是信息隐蔽和局部的概念的自然扩展.设计时应该力求高内聚,理想内聚的模块应当恰好做一件事情.1).偶然内聚:一个模块的各成分之间毫无关系.比如:一组语句在程序的多处出现,为了节省内存空间,这些语句放在一个模块中,该模块的内聚是偶然内聚的.2)逻辑内聚:把几种逻辑上相关的功能组放在同一模块中.3)瞬时内聚(时间内聚):一个模块所包含的任务必须在同一时间间隔内执行,例如初始化模块.4)过程内聚:一个模块的处理元素是相关的,而且必须按特定的次序执行.5)通信内聚:一个模块的所有成分都结合再同一个数据结构上.6)顺序内聚:模块的成分同一个功能密切相关,且输出,作为另外一个成分的输入.7)功能内聚:模块内的所有成分属于一个整体,完成单一的功能.在以上的内聚中,内聚度从低到高,偶然内聚度最低,功能内聚度最高.模块的高内聚,低耦合的原则称为模块独立原则,也称为模块设计的原则.8.4 模块的深度,宽度,扇出与扇入 深度:表示软件结构中控制的层数.宽度是软件结构中同一个层次上的模块总数的最大值 一个模块的扇入是指直接调用该模块的上级模块的个数.一个模块的扇出是指该模块直接调用的下级模块的个数.设计原则:低扇出 高扇入 8.5 模块作用域和控制域

软件设计时,模块的作用域应在控制域之内.8.6 模块化基础知识小结

通过模块的合并和分解,降低模块的耦合度.模块的扇入应尽量大,扇出应尽量小.一个模

块的扇入是指直接调用该模块的上级模块的个数.一个模块的扇出是指该模块直接调用的下级模块的个数.扇入大表示模块的重用性高,利用率高.扇出大表示模块的复杂度高.所以要高扇入低扇出.要将模块的作用范围限制在模块的控制范围之内.降低模块之间的复杂性,避免“病态连接”.九.什么是软件开发方法 有哪些主要方法

软件开发方法:使用已定义好的技术集及符号表示习惯组织软件生产的过程.结构化方法,面向对象方法,JACKSON方法,维也纳开发方法(VDM).9.1 结构化方法学

结构化方法学也称为生命周期方法学(瀑布模型方法),是一种面向数据流的需求分析方法.它的基本思想是自顶向下逐层分解.为了在需求改变时对软件的影响较小,结构化分析时应该使程序结构与问题结构相对应.常用工具: 数据流图(DFD),数据字典(DD),实例—关系图(E—R图)及描述加工处理的结构化语言,判定表,判定树.9.1.1数据流图(DFD图)DFD的基本成分

数据流图主要由4种成分组成

数据流(data flow):由一组固定成分的数据组成,表示数据的流向.它可以从源,文件流向加工,也可以从加工流向文件和宿,还可以从一个加工流向另一个加工.通常每个数据流必须有一个合适的名字,一方面是为了区别,另一方面也给人一个直观的印象,使人容易理解这个数据流的含义.但流向文件或从文件流出的数据流不必命名,因为这种数据流的组成部分就是相应文件的组成部分.加工(process):描述了输入数据流到输出数据流之间的变换,也就是输入数据流做了什么处理后变成了输出数据流.每个加工有一个名字和一个编号.编号反映了该加工位于分层DFD的哪个层次和哪张图中以及它是哪个加工分解出来的子加工.文件(file):可以表示数据文件,也可以表示一个数据记录.流向文件的数据流表示写文件,流出文件的数据流表示读文件,双向箭头表示对文件既读又写.每个文件都有一个文件名.源/宿(source/sink):源是指系统所需数据的发源地,宿(也称数据池)是指系统所产生的数据的归宿地.无论源或宿,均对应于外部实体,在框内应加注实体的名字,在一个软件各级软件系统中,有些源和宿可以是一个外部实体,外部实体是指存在于软件系统之外的人员或组织,它指出系统所需数据的发源地和系统所产生数据的归宿地.分层数据流图

一套分层的的数据流图由顶层,底层,和中间层组成.画分层数据流图基本原则与注意事项 a.自外向内,自顶向下,逐层细化,完善 求精.b.保持父图与子图的平衡.也就是说,父

图中某加工的输入数据流中的数据必须与它的子图的输入数据流在数量和名字上相同.c.保持数据守恒.也就是说,一个加工所 有输出数据流中的数据必须能从该加工的输入数据流中直接获得,或者是通过该加工能产生的数据.c.加工细节隐藏.根据抽象原则,在画父

图时,只需画出加工和加工之间的关系,而不必画出各个加工内部的细节.d.简化加工间关系.在数据流图中,加工

间的数据流越少,各加工就越相对独立,所以应尽量减少加工间输入输出数据流的数目.e.均匀分解.应该使一个数据流中的各个 加工分解层次大致相同.f.适当地为数据流,加工,文件,源/宿命

名,名字应反映该成分的实际意义,避免空洞的名字.g.忽略枝节.应集中精力于主要的数据流, 而暂不考虑一些例外情况,出错处理等枝节性问题.h.表现的是数据流而不是控制流.i.每个加工必须既有输入数据流,又有输

出数据流.在整套数据流图中,每个文件必须既有读文件的数据流又有写文件的数据流,但在某一张子图中可能只有读没有写或者只有写没有读.小结:一个软件系统,其数据流图往往有多层.如果父图有N个加工(Process),则父图允许有0～N张子图,但是每张子图只能对应一张父图.在一张DFD图中,任意两个加工之间可以有0条或多条名字互不相同的数据流;在画数据流图时,应该注意父图和子图的平衡,即父图中某加工的输入输出数据流必须与其输入输出流在数量和名字上相同.DFD信息流大致可分为两类:交换流和事务流.9.1.2 数据字典

数据字典是关于数据的信息的集合也就是对 数据流图中包含的所有元素的定义的集合.组成部分: a.数据项条目 b.数据流条目 c.文件条目 d.加工条目

加工条目是对数据流图中每一个不能再分 解的基本加工的精确说明.对于加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言,判定树和判定表.9.1.3 结构化语言

结构化语言实际上是一种半形式化语言, 它的结构通常可分为内外两层.外层接近于形式化语言,而内层近似于自然语言的描述.9.1.4 实体——关系图(E—R图)实体——关系图(Entity-Relabionship Diagram),简称E-R图,包含实体,关系和属性等3种基本成分.通常用矩形框代表实体,并用直线把实体(或关系)与其属性连接起来.E-R图通常用于数据库应用系统.9.2 结构化设计

结构化设计通常可分为概要设计和详细设计,但是主要用于概要设计阶段.概要设计的任务是确定软件系统的结构,进行模块划分,确定每个模块的功能,接口以及模块间的调用关系.详细设计的任务是为每个模块设计实现的细节.9.2.1 概要设计

经过需求分析阶段的工作,系统必须“做什么”已经清楚了,概要设计的基本目的就是回答“概括地说,系统应该如实现 ”这个问题.概要设计的重要任务:

将一个复杂的系统按功能化分为模块,确

定每个模块的功能,确定模块之间的调用关系,确定模块之间的接口(模块之间传递的信息),评价模块的结构质量.1.软件结构图形工具

结构化设计方法(SD)方法采用结构图(Structure Chart),层次图和HIPO图描述软件结构.结构图的主要成分有模块,调用和数据,结构图中的模块用矩形表示,在矩形框内可标上模块的名字.模块间如有箭头或直线相连,表明它们之间有调用关系.层次图用来描绘软件的层次结构.层次图中一个矩形框代表一个模块,方框间的连线表示模块间的调用关系.HIPO图实际上就是层次图加输入/处理/输出图.HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图”,是在层次图里出了最顶层的方框之外,每个方框都加了编号.编号规则和数据流图的编号规则一样.2.概要设计中的信息流

变换流:信息沿着输入通道进入系统,然后通过变换中心(也称主加工)处理,再沿着输出通道离开系统.具有这一特性的信息流称为变换流.具有变换流型的数据流图可明显地分成输入,变换(主加工),输出三大部分.事务流:信息流沿着输入通道到达一个事务中心,事务中心根据输入信息(即事务)的类型在若干个动作序列(称为活动流)中选择一个来执行,这种信息流称为事务流.事务流有明显的事务中心,各活动以事务中心为起点呈辐射状流出.9.2.2 详细设计

概要设计已经确定了每个模块的功能和接口,详细设计的任务就是为每个模块设计其实现的细节.详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统,得出对目标系统的精确描述.1.详细设计阶段的内容

为每个模块进行详细的算法设计.为模块内部的数据结构进行设计.对数据库进行物理设计.其他

详细设计工具主要包括程序流程图(系统流程图),盒图(N-S图),PAD图和伪码(PDL).2.人机界面设计

人机界面的设计质量,直接影响用户对软件产品的评价.界面的美观,灵活和风格都很重要,但人机界面设计中最重要的也是最基本的目标是软件的易操作性.人机界面设计主要包括系统响应时间,用户帮助设计,出错信息处理和命令交互设计等几个方面.9.3 Jackson方法

上面讲的结构化设计方法是面向数据流的,另外还有一种面向数据结构的设计方法, Jackson方法是最著名的面向数据结构的设计方法,而不是面向数据流的设计方法.Jackson方法的基本步骤是:建立系统的数据结构;以数据结构为基础,对应地建立程序结构;列出程序中要用到的各种基本操作,再将这些操作分配到程序结构适当的模块中.9.4 面向对象分析方法(00A)OTM方法的三个模型,分别从三个不同侧面描述了所要开发的系统:功能模型指明了系统应该“做什么”;动态模型明确了什么时候做;对象模型则定义了做事情的实体.对象模型描述了系统中对象的静态结构及对象间的联系,用对象模型图来表示.动态模型描述了与时间和操作次序有关的系统属性.动态模型由多张状态图组成.各个类的状态图通过共享事件组成系统的动态模型.功能模型描述系统内数据值的变化,它由数据流图组成.数据流图说明数据流是如何从外部输入,经过操作和内部存储而得到输出的.十.软件工具

软件工具是指用于辅助软件开发,运行,维护,管理,支持等过程中的活动的软件.通常也称为CASE(Computer Aided Software Engineering,计算机辅助软件工程)工具.按软件过程的活动分为软件开发工具,软件维护工具和软件管理工具等.十一.软件开发环境

集成型开发环境通常可由工具集和环境集成机制两部分组成.这种环境应具有开放性和可裁减性.环境集成机制主要有数据集成机制,控制集成机制和界面集成机制.十二.软件质量管理基础知识 12.1 软件质量

ISO/IEC 9126软件质量模型可从软件功能性,可靠性,可用性,效率,可维护性,可移植性6个方面来衡量.(1).功能性

与功能及其指定的性质的一组软件属性.(2)可靠性

软件在规定的一段时间内和规定的条件下保持其性能水平有关的一组软件属性.也可以称为在规定的条件下和规定的时间间隔内,软件实现其规定功能的概率.(3)可用性

与使用的难易程序及规定或隐含用户对使用 方式所做的评价有关的软件属性.(4)效率

与在规定条件的性能水平与所用资源量之间的关系有关的一组软件属性.(5)可维护性

与软件维护的难易程序有关的一组软件属性.(6)可移植性

软件可从某一环境转移到另一环境的能力有关的一组属性.即软件从一个计算机系统转换到另一个计算机系统运行的难易程度是指软件的可移植性.为了提高可移植性,应注意提高软件的设备独立性.采用表格驱动程序有助于提高设备独立性.为了提高可移植性,还应有完备的文档资料.使用C语言开发的系统软件具有较好的可移植性.12.2 软件质量保证

软件质量保证的主要困难表现在以下几个方面: 1)软件开发的管理人员往往关心项目开发的成本与进度.因为成本和进度是显而易见的,而软件质量则难以度量.如果软件开发的管理人员对交付的软件含有多少隐患并不必负什么责任,他们必定没有太高的热情去控制开发的质量,更不必说保证质量并不容易且代价昂贵.开发人员的习惯一旦形成难以改变,他们的形为也难于控制,而高质量的软件产品,又主要取决于参与开发的人员.复杂的软件项目需要许多技术人员和管理人员参与,对问题的不同认识和误解如不能及时消除必然影响软件质量.软件开发人员的频繁流动,特别是骨干开发人员的流失,也会使软件质量受到一定的影响.软件质量的保证手段: 开发初期制定质量保证计划,并在开发中坚持实行.开发前选定或制定开发标准或开发规范,并遵照实施.从开始就选择分析设计方法和工具,形成高质量的分析模型和设计模型.严格执行阶段评审,以便及时发现问题.各个开发阶段的测试.对软件的每次“变动”都要经过申请,评估,批准,实施等步骤.软件质量特性的度量化.软件生存期的各阶段都要完整的文档.12.3 代码评审技术

常用方法有代码走查和代码审查技术.代码走查

程序员和测试员组成审查小组,通过逻辑运行程序.第一步:小组成员提前阅读设计规格书,程序文本等相关文档;第二步:利用测试用例,使程序逻辑运行,记录程序的踪迹,发现,讨论,解决问题 代码审查

程序员和测试员组成审查小组.第一步:小组成员提前阅读设计规格书,程 序文本等相关文档;第二步:召开程序审查会,开发人员读程序,审查小组讨论,发现,解决问题.两者的区别

代码审查是一种正式的评审活动,而代码走 查的讨论过程是非正式的.十三.成本-效益分析可用哪些指标进行度量

投资回收率:通常把建立系统若干年后所取得的收益折算成现在的价值和开发系统所需的费用进行比较得出投资回收率.投资回收期:就是使累计的经济效益等于最初的投资费用所需的时间.纯收入:整个软件生命周期之内的累计经济效益(折成现在值)与投资之差.十四.第四代语言(4GL)的主要特征

友好的用户界面

兼有过程性和非过程性两种特性 高校的程序代码 完备的数据库 应用程序生成器

十五.软件测试

软件测试的费用已经超过软件开发费用的30%左右.“高产”测试是指用少量的测试用例,发现被测试程序尽可能多的错误.15.1 软件测试经过的步骤

单元测试->集成测试->确认测试->系统测试 15.2 测试与软件开发各阶段的关系

单元测试对程序中每一个程序单元进行测试,检查各个模块是否争取实现规定的功能,从而发现模块在编码中或算法中的错误,该阶段涉及编码和详细设计文档.集成测试是为了检查与设计相关的软件体系结构的有关问题,也就是检查概要设计是否合理有效.确认测试主要是检查已实现的软件是否满足需求规格说明书中已确定了的各种需求.系统测试是把已确认的软件与其他系统元素(如硬件,其他支持软件,数据,人工等)结合在一起进行测试,以确定软件是否可以支付使用.15.3 白盒测试

白盒测试又称为结构测试.可以把程序看成装在一个透明盒子里,测试者(一般为编程者)完全知道程序的结构和处理算法.按照程序内部逻辑设计测试用例,检测程序中的主要执行通路是否能按预定要求正常工作.白盒测试多用于单元测试阶段.逻辑覆盖是主要的白盒测试技术.白盒测试时,确定测试数据应根据程序的内部逻辑和指定的覆盖方式.采用一下几种逻辑覆盖标准: 语句覆盖 判定覆盖 条件覆盖

判定/条件覆盖 条件组合覆盖 路径覆盖

满足条件组合覆盖测试用例,也一定满足判定条件覆盖.因此,条件组合覆盖是上述五种覆盖标准中最强的一种.15.4 黑盒测试

黑盒测试,又称为功能测试.把软件看做是一个不透明的黑盒子,完全不考虑(或不了解)软件内部结构和处理算法,它只检测软件功能是否能按照软件需求说明书的要求正常使用,软件是否能适当的接受输入数据并产生正确的输出信息,软件运行过程中能否保持外部信息(例如文件和数据库)的完整性等.常用的黑盒测试技术包括等价类划分,边值分析,错误推测和因果图等.其中等价类划分和边界值分析法方法最常用.如果两者结合使用,更有可能发现软件中的错误.15.4灰盒测试

灰盒测试介于白盒测试和黑盒测试之间,它把软件看做是一个半透明的灰盒子,结合考虑软件的内部结构和外部功能设计测试用例 15.5 回归测试

纠正了程序中的错误之后,选择部分或全部原先已测试过的测试用例,对修改后程序重新测试以验证对软件修改后有没有引出新的错误,称为回归测试.15.6 单元测试

单元测试(Unit testing)也称为模块测试或结构测试,通常可放在编程阶段(实现阶段),主要采用逻辑覆盖技术,由程序员对自己编写的模块自行测试,检查模块是否能实现了详细设计说明书中规定的功能和算法.单元测试主要发现编程和详细设计中产生的错误.测试一个模块时需要为该模块编写一个驱动模块和若干个桩(stub)模块.顶层模块测试时不需要驱动模块,底层模块测试时不需要桩模块.在进行单元测试时,常用的方法是白盒测试(采用逻辑覆盖的测试技术),辅之以黑盒测试.15.7集成测试

集成测试(integration testing)也称为组装测试,在单元测试的基础之上,把所有的模块组装成一个系统进行测试.主要测试设计阶段产生的错误,集成测试计划应该在概要设计阶段制定.非渐增式集成测试

首先将每个模块分别进行单元测试,再把所有的模块组装成一个完整的系统进行测试.目前在进行集成测试时已普遍采用渐增式集成.渐增式集成测试

又可以分为自顶向下集成和自底向上集成.自顶向下集成先测试上层模块,再测试下层模块,由于测试下层模块时上层模块已经测试过,所以不必要另外编写驱动模块.自底向上集成,先测试下层模块,再测试上层模块.顶层模块测试时不需要驱动模块,底层模块测试时不需要桩模块.软件的集成测试最好由不属于该软件开发组的软件设计人员承担,以提高集成测试的效果.三明治测试

从系统的三个角往中间包围测试的方法.15.8 确认测试

在系统验收测试中,验证测试是在模拟的环境中进行强度测试的基础上进行,主要依据软件需求说明书检测软件的功能,性能及其他特征是否与用户的要求一致,而确认测试是在一个实际环境中使用真实数据运行系统.确认测试计划应该在需求分析阶段制定.α测试

由用户在开发者的场所进行,并且在开发者的指导下进行测试.开发者负责纪录发现的错误和使用中遇到的问题,也就是说α测试是在受控的环境中进行的.β测试是在一个或多个用户的现场由该软件的最终用户实施的,开发者通常不在现场,用户负责记录发现的错误和使用中遇到的问题并把这些问题报告给开发者.也就是说,β测试是在受控的环境中进行的.经过确认测试之后的软件通常就可以交付使用了.15.9 系统测试

系统测试是将已经确认的软件,计算机硬件,外设和网络等其他因素结合在一起,进行信息系统的各种组装测试和确认测试,其目的是通过与系统的需求相比较,发现所开发的系统与用户需求不符或矛盾的地方.包括以下的测试: 恢复测试:监测系统的容错能力

安全性测试:监测系统的安全机制,保密措施是否完善等防范能力.强度测试:测试软件的异常情况的处理能力.性能测试:监测系统是否满足系统设计方案说明书对性能的要求.可靠性测试:从平均失效间隔是否超过了规定的时限,因故障而停机的时间在一年中不应超过的时间来进行检测.安装测试:监测软件在安装过程中是否有错误,是否容易操作等.系统测试计划在系统测试阶段初期制定.十六.软件工程标准和软件文档

GB/T8566-2001,GB/T12504-1990,GB/T12505-1990是我国现阶段最重要的三个软件开发规范标准.国家标准局1988年1月批准并发布的《GB/T8567-1988计算机软件产品开发文件编制指南》规定在一项软件开发过程中应该产生14中文件 可行性研究报告 项目开发计划 软件需求说明书 数据要求说明书 概要设计说明书 详细设计说明书 数据库设计说明书 用户手册 操作手册 模块开发卷宗 测试计划 测试分析报告 开发进度月报 项目开发总结报告

软件运行和维护基础知识

管理人员主要使用:项目开发计划,可行性研究报告,模块开发卷宗,开发进度月报,项目开发总结报告.开发人员:项目开发计划,可行性研究报告,软件需求说明书,数据要求说明书,数据库设计说明书,概要设计说明书,详细设计说明书,测试计划,测试分析报告.维护人员:概要设计说明书,详细设计说明书,数据库设计说明书,模块开发卷宗,测试分析报告,维护报告.用户:用户手册,操作手册.十七.软件维护

用于软件维护的花费约为整个软件生命周期花费的75%(或60%～80%之间)而且还在逐年上升.17.1 软件维护类型

根据引起软件维护的原因,软件维护可分为以下四种类型(1)改正性维护

使用过程中发现了隐蔽的错误后,为了诊断和改正这些隐蔽错误而修改软件的活动(2)适应性维护

为了适应环境的变化而修改软件的活动(3)完善性维护

为了扩充或完善原有软件的功能或性能而修改软件的活动.(4)预防性维护

预防性维护是指为了提高软件的可维护性和可靠性,为未来的进一步改进打下基础而修改软件的活动.17.2 软件的可维护性 通常影响软件可维护性的因素有可理解性,可测试性和可修改性.(1)可理解性

可理解性是指维护人员理解软件的结构,接口,功能和内部过程的难易程度.采用良好的编程风格有助于提高软件的易理解性.(2)可测试性

可测试性是指测试和诊断软件错误的难易程度.(3)可修改性

可修改性是指修改软件的难易程度.怎样提高软件的可维护性

在软件生命周期的各个阶段都必须充分考虑维护问题.结构化设计的几条主要原则,如模块化,信息隐藏,高内聚,低耦合等,对于提高软件的可理解性,可测试性和可修改性也都有重要的作用.书写详细正确的文档,书写源文件的内部注解,使用良好的编程语言,具有良好的程序设计风格,也有助于提高软件的可理解性.使用先进的测试工具,保存以前的测试过程和测试用例,则有助于提高软件的可测试性.十八.软件的可靠性

在给定的时间内,在给定的环境条件下系统完成所指定工作的概率.衡量的标准是:平均失效等待时间MTTF 和平均失效间隔时间MTBF.