软件工程必背知识点_软件工程知识点总结

🎊软件工程期末知识点
✨博客首页：才下眉头n.
🎉已完结
💖如果觉得本篇文章还不错的话，欢迎大家点赞👍+收藏❤️+评论🤞

软件工程

第一章 软件工程学概述

1.软件危机

1.概念

• 计算机软件的开发和维护过程中所遇到的一系列严重的问题。
• 采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好技术方法结合起来，以经济地开发出高质量的软件并有效的维护它。

*2.软件危机的表现

1）对软件开发成本和进度的估计常常很不准确；

2）用户对完成的软件系统不满意的现象经常发生；

3）软件产品的质量往往靠不住；

4）软件常常是不可维护的；

5）软件通常没有适当的文档资料；

6）软件成本在计算机系统总成本中所占的比例逐年上升；

7）软件开发生产率提高的速度跟不上计算机应用的发展趋势。

3.解决途径

1）使用在实践中总结出来的开发软件的成功技术和方法

2）开发和使用更好的软件工具；

3）良好的组织管理措施。

2.软件工程

1.概念

指导计算机软件开发和维护的一门工程学科。是一门交叉学科

*2.基本原理

• 用分阶段的生命周期计划严格管理

• 坚持进行阶段评审

• 实行严格的产品控制

• 采用现代程序设计技术

• 结果应能清楚地审查

• 开发小组的人员应该少而精

• 承认不断改进软件工程实践的必要性

3.软件生命周期

软件定义、软件开发、运行维护

第二章 可行性分析

1.可行性研究

1.目的

用最小的代价在尽可能短的时间内确定问题是否有解，以及是否值得去解。

2.任务

1）技术可行性

对要开发项目的功能、性能和限制条件进行分析，确定在现有的资源条件下，技术风险有多大，项目能否实现。

2）经济可行性

经济可行性研究的内容是进行开发成本的估算以及进行效益的评估确定要开发的项目是否值得投资开发。

3）操作可行性

在这个应用范围内，系统的操作方式（批处理/联机处理）是否行得通。

4）社会可行性

社会可行性主要研究开发的项目是否存在任何侵犯、妨碍等责任问题，要开发项目的运行方式在用户组织内是否行得通，现有管理制度、人员素质和操作方式是否可行。

*3.步骤

复查问题定义阶段提出的系统的规模和目标

研究目前正在使用的系统

导出新系统的高层逻辑模型（数据流图、数据字典）

重新进一步定义问题

导出和评价供选择的解法（技术，操作和经济三方面）

**推荐行动方针(**是否继续，找出最好的）

草拟开发计划

书写文档提交审查

2.数据流图

一种图形化技术

1.基本构成符号

• *：表示数据流之间的“与关系”，实际使用时*常可省略

• +：表示数据流之间的“或关系”

• ○+：表示数据流之间的“异或关系”

  

2.步骤

自顶向下，逐层细化

1）先找外部实体（可以是人、物或其他软件系统），找到了外部实体，则系统与外部世界的界面就得以确定，系统的源点和终点也就确定了；

2）找出外部实体的输入和输出数据流；

3）在图的边上画出系统的外部实体；

3.例题

分析：

源点/终点：采购员（终点），仓库管理员（源点）。

处理：

处理事务(零件入库或出库后数量会变化，任何改变数据的操作都是处理）

产生订货报表

数据流：

（1）出入库事务（零件编号，事务类型，数量）

（2）定货报表（零件编号，零件名称，定货数量等）

数据存储：

（1）库存清单（零件编号，库存量，库存量临界值）

（2）定货信息（用来产生报表的数据，零件编号，零件名称，定货数量等）

2.数据词典

对数据流图中包含的所有元素的定义的集合；

1.基本内容

• 数据元素编号、名称及其含义；
• 数据类型和长度；
• 合理取值；
• 其他内容，如它与其它数据的逻辑关系等。

2.用途

1）作为分析阶段的重要工具；

2）数据元素的控制信息非常有用；

3）有助于开发数据库。

第三章 需求分析

1.需求分析是软件定义的最后一个阶段，它的基本任务是准确的回答“系统必须做什么”这个问题。

2.需求分析的结果是可行性研究报告

1.需求分析的意义

软件需求分析是软件开发获得成功的前提条件，必须了解用户需求，才能开发出符合用户要求的软件。

2.需求分析的基本任务

确定对系统的综合需求

分析系统的数据要求

导出系统的逻辑模型

修正系统开发计划

3.需求分析图形工具

1）实体-联系图（ER 图）

数据模型中包含3种相互关联的信息 —- 数据对象（实体）、数据对象的属性，及数据对象彼此间相互连接的关系。

a. 一对一联系(1∶1) 如：一个部门有一个经理，每个经理只在一个部门任职

b. 一对多联系(1∶N) 如：某校教师与课程之间存在一对多的联系“教”

c. 多对多联系(M∶N) 如：学生与课程间的联系(“学”)是多对多的

2）状态转换图

通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)

3）层次方框图

4）Warnier图

5）IPO图

4.系统分析的过程

1、解释说明环节：对研究的对象和需要解决的问题进行系统的说明，目的在于确定目标和说明该问题的重点和范围;

2、收集资料环节：在系统分析基础上，通过资料分析各种因素之间的相互关系，寻求解决问题的可行方案;

3、建模环节：依系统的性质和要求，建立各种数学模型;。实体数学模型是确定系统包含的实体以及它们之间的关联的过程。

4、运用数学模型对比并权衡各种方案的利弊得失; 有时候还会涉及到数据处理的流程。例如，一张图片提交后可能需要进行预处理，然后有运营人员进行审核和标记，最后进行发布。过程中数据的保存形式或者状态标记可能是不一样的。

5、确定最优方案。通过分析，若不满意所选方案，则可按原步骤重新分析。一项成功的系统分析需要对各方案进行多次反复循环与比较，方可找到最优方案。

第五章 总体设计

1、总体设计又被称为概要设计或初步设计，它的基本目的就是回答“概括的说，系统应该如何实现？”这个问题。

2、总体设计由两个阶段组成:系统设计阶段，确定系统的具体实现方案；结构设计阶段:确定软件结构。

3、衡量模块独立的两个标准:高内聚低耦合。耦合的分类(由低到高)，内聚的分类(由低到高)。

1.总体设计的过程

1）设想供选择的方案

2）选择合理的方案

3）推荐最佳方案

4）功能分解

5）设计软件结构

6）设计数据库

7）制定测试计划

8）书写文档

9）审查和复审

2.设计原理

模块化、抽象、逐步求精、信息隐藏和局部化、模块独立

3.描绘软件结构的图形工具

层次图、HIPO图、结构图

1）层次图

层次图作用：描述软件的层次结构

层次图：一个方框代表一个模块，方框间的连线表示调用关系。（不是组成关系）

2）HIPO图

HIPO 图： HIPO 图=层次图＋ IPO 图

在HIPO图里，除了最顶层的方框之外，每个方框都加了编号，方便追踪该模块在软件结构中的作用。

3）结构图

结构图是进行软件结构设计的另一个有力工具。

4.面向数据流的设计方法

面向数据流的设计方法:变换流、事务流。

1.变换流

变换流特点：具有明确的传入、变换（或称主加工）和传出界面

2.事务流

当数据流图的数据流是“以事务为中心的”，数据沿输入通路到达一个处理T，这个处理根据输入数据的类型在若干个动作序列中选出一个来执行。

事务中心的任务：

• 接受输入数据（事务）
• 分析每个事务以确定它的类型。
• 根据事务类型选取一条活动通路

第六章 详细设计

详细设计是要对系统的程序，界面，数据库进行设计，并不是进行具体的代码编写。

1.结构程序设计

结构化程序设计的本质： 代码容易阅读和理解

1.概念

如果一个程序的代码块仅仅通过顺序、选择和循环这 3 种基本控制结构进行连接，而且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。

2.目的

来保证程序的代码的是易读性

2.人机界面设计

掌握系统响应时间，响应长度，响应易变形的概念

1.人机界面应具有的特性

1、可使用性
1）使用简单
2） 用户界面中所用术语的标准化和一致性
3） 具有HELP功能
4） 快速的系统响应和低的系统成本
5）具有容错能力
2、灵活性
1）考虑用户的特点、能力、知识水平。
2） 提供不同的系统响应信息。
3）提供根据用户需求制定和修改界面。
3、界面的复杂性与可靠性
1）复杂性—界面规模及组织的复杂程度，应该愈简单愈好。
2）可靠性—指无故障使用的时间间隔，用户界面应该能够保证用户正确、可靠地
3）使用系统，及程序、数据的安全。

2.设计问题

1.系统响应时间

• 系统响应时间是指从用户完成某个控制动作到软件给出预期的响应之间的这段时间。
• 两个重要属性：
  • 长度：响应时间的长短；
  • 易变性：响应时间相对于平均响应时间的偏差。（更重要）

2.用户帮助设施

3.出错信息处理

4.命令交互

3.过程设计的工具

过程设计的工具是进行程序设计是使用的工具。

过程设计的工具包括三类：图形工具，表格工具，语言工具。其中，图形工具有三只：程序流程图、盒图（NS图）、问题分析图（PAD图）；

表格工具有判定树和判定表；

语言工具是过程设计的语言PDL。

此部分大家要重点学习（见幻灯片当中的34页-53页）。由于此部分内容较多，本次课大家只需要看懂，程序流程图和盒图。

1.程序流程图

1.程序流程图基本符号

2.程序流程图基本结构

顺序型：几个连续的处理步骤依次排列构成

选择型：由某个逻辑判断式的取值决定选择两个处理中的一个

先判定（while）型循环：在循环控制条件成立时，重复执行特定的处理

后判定（until）型循环：重复执行某些特定的处理，直至控制条件成立

多情况（case）型选择：列举多种处理情况，根据控制变量的取值，选择执行其一

3.示例

2.盒图（N-S图）

1.盒图的特点：
1）功能域明确，可以从盒图上一眼就看出来；
2）不可能任意转移控制；
3）很容易确定局部和全程数据的作用域； 4）很容易表现嵌套关系，也可以表示模块的层次结构。

2.盒图基本符号：

3.问题分析图（PAD图）

用二维树形结构的图来表示程序的控制流，控制流程自上而下，从左往右地执行

1.问题分析图基本符号

2.优点

1）使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构化程序；
2）PAD图所描绘的程序结构十分清晰。

• 图中最左面的竖线是程序的主线，即第一层结构。
• 随着程序层次的增加，PAD图逐渐向右延伸，每增加一个层次，图形向右扩展一条竖线。
• PAD图中竖线的总条数就是程序的层次数；

4.判定表

1.能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。

2.如果数据流处理时需要依赖多个逻辑条件的取值，用判定表来描述比较合适

1.组成

• 左上部列出所有条件
• 左下部是所有可能做的动作
• 右上部表示各种条件组合
• 右下部是和每种条件组合相对应的动作

5.判定树

判定树是判定表的变种，能清晰表示复杂的条件组合与操作之间的关系，形式简单，不需要做任何说明，是常见的系统分析工具。

6.过程设计语言(PDL)

也称伪码（ pseudo code ) ，是一种介于自然语言和程序设计语言之间的语言
用于描述功能模块的算法设计和处理细节的语言。

1.特点

易编写，易理解，容易转换成源程序。

2.PDL的优点

1）可以作为注释直接插在源程序中间； 2）可以使用普通的正文编辑程序或文字处理系统来完成PDL的书
写和编辑工作；
3）现在已经有一些自动处理程序可以自动地把PDL生成程序代码。
3.PDL的缺点

不如图形工具形象直观。

4.面向数据结构的设计方法

• 数据结构既影响程序的结构又影响程序的处理过程

• 面向数据结构的设计方法根据数据结构设计程序处理过程

  程序中实际使用的数据结构种类很多，但数据元素彼此间的逻辑关系却只有顺序 选择和重复3类，因此，数据结构也只有这三类数据结构。数据元素彼此间的逻辑关系：

  • 重复出现的数据通常由具有循环控制结构的程序来处理
  • 选择数据要用带有分支控制结构的程序来处理
  • 层次的数据组织通常和使用这些数据的程序的层次结构十分相似。

• 面向数据结构的设计方法的最终目标是得出对程序处理过程的描述。

1.Jackson图

使用面向数据结构的设计方法，首先需要分析确定数据结构，并用适当的工具清晰地描绘数据结构

数据元素彼此间的逻辑关系却只有顺序 选择和重复3类

• 顺序结构：顺序结构的数据由一个或多个数据元素组成，每个元素按确定次序出现一次。
• 选择结构：选择结构的数据包含两个或多个数据元素，每次使用这个数据时按一定条件从这些数据元素中选择一个。
• 重复结构：重复结构的数据，根据使用时的条件由一个数据元素出现零次或多次构成。

1.Jackson图的优点

• 便于表示层次结构，而且是对结构进行自顶向下分解的有力工具；
• 形象直观可读性好；
• 既能表示数据结构也能表示程序结构。

2.Jackson图的缺点

• 表示选择或重复结构时，选择条件或循环结束条件不能直接在图上表示
  出来，影响了图的表达能力，也不易直接把图翻译成程序；
• 框间连线为斜线，不易在行式打印机上输出

	Jackson图	层次图
作用	1.描绘数据结构 2.描绘程序结构	描绘软件结构
矩形框	1.数据元素 2.几个语句	模块
连线	组成关系	调用关系

2.Jackson方法

• JACKSON系统开发方法则是面向数据结构的开发方法。
• 基本思想实现建立输入输出的数据结构，再将其转换为程序结构。

Jackson结构程序设计方法由五个步骤组成：
1）分析并确定输入数据和输出数据的逻辑结构，并用Jackson图描绘这些数据结构；
2）找出输入数据结构和输出数据结构中有对应关系的数据单元；

3）用以下三条规则从描绘数据结构的Jackson图导出描绘程序结构
的Jackson图：
A.为每对有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构图的相应层次画一个处理框；

​ B.根据输入数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框；
​ C.根据输出数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框；

4）列出所有操作和条件（包括分支条件和循环结束条件），并且把
它们分配到程序结构图的适当位置；
5）用伪码表示程序。

5.程序复杂度的定量度量

1.软件复杂性主要表现在程序的复杂性上，程序复杂性主要指模块内程序的复杂性。

2.常见的定量度量软件复杂性的方法有：
McCabe度量法(环路度量法)
Halstead 的软件科学

1.定量度量程序复杂度的作用

（1）可估算软件中错误的数量及软件开发工作量；
（2）度量的结果可用来比较不同设计或不同算法的优劣；
（3）程序的复杂度可作为模块规模的限度。

2.McCabe方法

McCabe 方法根据程序控制流的复杂程度定量的度量程序复杂程度，这样度量出的结果称为程序的环形复杂度，为了突出程序控制流，使用程序图(流图)

1.程序图(流图)

“退化”的程序流程图；

程序图(流图)仅描绘程序的控制流程，不表现对数据 的具体操作以及分支或循环的具体条件。

2.程序图的基本元素

1. 符号“ O ”为程序图的结点，一个圆代表一条或多条语句；
   流程图中的各种处理框（如加工框，判断框，顺序处理框序列，菱形判断框等），
   都被简化成用圆圈表示的结点；

2. 箭头为边，表示控制流的方向;

3. 边和结点圈定的封闭范围叫做区域，计算区域数时应该包括图外
   部未被围起来的区域。

3.映射方法

• 任何方法表示的过程设计结果，都可以翻译成流图。

• 对于顺序结构，一个顺序处理序列和下一个选择或循环的开始语句，
  可以映射成流图中的一个结点。

• 对于选择结构，开始语句映射成一个结点；两条分支至少各映射成一
  个结点；结束映射成一个结点。

• 对于循环结构，开始和结束语句各映射成一个结点。

4.环路复杂性 V ( G ）的3种计算方法
1）环形复杂度 V（G）等于流图中的区域数；
2）环形复杂度 V（G）＝E－N+2，其中E是流图中边的条数，N是结点数；
3）环形复杂度 V（G）＝P＋1，其中P为流图中判定结点的数目。

5.环形复杂度的用途

可用于对测试难度的定量度量，也可对软件最终的可靠性给出某种预测。

3.Halstead方法

• Halstead方法根据程序中运算符和操作数的总数来度量程序的复杂程度。
• 令N1为程序中运算符出现的总次数，N2为操作数出现的总次数，程序长度N定义为：N=N1+N2

• 多次验证都表明，程序的预测长度H和实际程序长度N非常接近。
• Halstead还给出了预测程序中包含错误的个数的公式：
  

第七章 实现 (编码与测试)

• 编码和测试统称为实现。

• 编码：把软件设计结果翻译成程序代码。

• 测试和调试：检测程序并改正错误的过程。

• 程序的质量主要取决于软件设计的质量。

• 所选用的程序设计语言的特点及编码风格也将对程序的可靠性、可读性、可测试性和可维护
  性产生深远的影响。

• 测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。

• 目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。

• 软件测试

• 单元测试：通常在编写出每个模块之后就对它做必要的测试

• 综合测试：在单元测试结束之后，对软件系统进行的各种综合测试 通过测试发现错误之后还必须诊断并改正错误，这就是调试的目的。调试是测试阶段最困难的工作。

1.编码

编码就是把软件设计结果翻译成用某种程序设计语言书写的程序。

1.选择程序设计语言

程序设计语言是人和计算机通信的最基本的工具， 它的特点必然会影响人和计算机通信的方式和质量，也会影响其他人阅读和理解程序的难易程度。因此，编码之前的一项重要工作就是选择一种适当的程序设计语言

1.主要实用标准
(1) 系统用户的要求。
(2) 可以使用的编译程序。
(3) 可以得到的软件工具。
(4) 工程规模。
(5) 程序员的知识。
(6) 软件可移植性要求。
(7) 软件的应用领域

2.编码风格

程序实际上也是一种供人阅读的文章，有一个文章的风格问题。应该使程序具有良好的风格，应遵守以下规则：
– 源程序文档化
– 数据说明
– 语句构造
– 输入/输出方法
– 效率

1.源程序文档化—-符号名的命名

• 符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。

• 这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。

• 名字不是越长越好，应当选择精炼的意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。

1.源程序文档化—-程序的注释

• 夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。

• 注释绝不是可有可无的。

• 一些正规的程序文本中，注释行的数量占到整个源程序的1/3到1/2，甚至更多。

• 注释分为序言性注释和功能性注释。

• 序言性注释：通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。

• 序言性注释包括：
  – 程序标题：有关本模块功能和目的的说明； – 主要算法： – 接口说明：包括调用形式，参数描述，子程序清单；
  – 有关数据描述：重要的变量及其用途，以及其它有关信息；
  – 模块位置：在哪一个源文件中，或隶属于哪一个软件包；
  – 开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。

1.源程序文档化—-程序的视觉组织

• 恰当地利用空格，可以突出运算的优先性，避免发生运算的错误。例如 ，将表达式(A＜－17)ANDNOT(B＜＝49)ORC写成 (A＜－17) AND NOT (B＜＝49) ORC
• 自然的程序段之间可用空行隔开；
• 移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列。这样做使程序完全分不清层次关系。
• 对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行。使程序的逻辑结构更加清晰

2.数据说明

• 在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。

• 为了使程序中数据说明更易于理解和维护，必须注意以下几点:

  • 数据说明的次序应该标准化。有次序易查阅，能加速测试、调试和维护的过程。
  • 当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量。
  • 如果设计时使用了一个复杂的数据结构，则应该用注解说明用程序设计语言实现这个数据结
    构的方法和特点

3.语句构造
构造语句时应该遵循的原则是，每个语句都应该简单而直接，不能为了提高效率而使程序变得过分复杂；
也不要刻意追求技巧性，使程序编写得过于紧凑。

4.输入输出
在设计和编写程序时应该考虑下述有关输入输出风格的规则：

• 对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；

• 检查输入项的各种重要组合的合法性，必要时报告输入状态信息；

• 使得输入的步骤和操作尽可能简单，并保持简单的输入格式；

• 输入数据时，应允许使用自由格式输入；

• 应允许缺省值；

5.程序效率

程序的效率是指程序的执行速度及程 序所需占用的内存的存储空间。程序编码是最后提高运行速度和节省存储的机会，因此在此阶段不能不考虑程序的效率。

（1）程序运行时间

• 源程序的效率直接由详细设计阶段确定的算法的效率决定，但是，写程序的风格也能对程序的执行速度和存储
  器要求产生影响。

• 在把详细设计结果翻译成程序时，总可以应用下述规则：

  • 写程序之前先简化算术的和逻辑的表达式；

  • 仔细研究嵌套的循环，以确定是否有语句可以从内层往外移；

  • 尽量避免使用多维数组；

  • 尽量避免使用指针和复杂的表；

  • 使用执行时间短的算术运算；

  • 不要混合使用不同的数据类型；

  • 尽量使用整数运算和布尔表达式。

    在效率是决定性因素的应用领域，尽量使用有良好优化特性的编译程序，以自动生成高效目标代码。

（2）存储器效率

• 在大中型计算机系统中，存储限制不再是主要问题。在这种环境下，对内存采取基于操作系统的分页功能的虚拟存储管理。存储效率与操作系统的分页功能直接有关。
• 采用结构化程序设计，将程序功能合理分块，使每个模块或一组密切相关模块的程序体积大小与每页的容量相匹配，可减少页面调度，减少内外存交换，提高存储效率。
• 在微型计算机系统中，存储器的容量对软件设计和编码的制约很大。因此要选择可生成较短目标代码且存储压缩性能优良的编译程序，有时需采用汇编程序。
• 提高存储器效率的关键是程序的简单性。

(3) 输入输出的效率

• 输入／输出可分为两种类型：

  • 面向人(操作员)的输入／输出

  • 面向设备的输入／输出

• 如果操作员能够十分方便、简单地录入输入数据，或者能够十分直观、一目了然地了解输出信息，则可以说面向人的输入／输出是高效的。

(4)设备输入/输出效率

• 关于提高设备输入/输出效率的指导原则：
  • 输入/输出的请求应当最小化；
  • 对于所有的输入/输出操作，安排适当的缓冲区，以减少频繁的信息交换。
  • 对辅助存储(例如磁盘)，选择尽可能简单的，可接受的存取方法；
  • 对辅助存储的输入/输出，应当成块传送； – 对终端或打印机的输入/输出，应考虑设备特性，尽可能改善输入/输出的质量和速度；
  • 任何不易理解的，对改善输入/输出效果关系不大的措施都是不可取的；
  • 任何不易理解的所谓“超高效”的输入/输出是毫无价值的；

2.软件测试基础

› 什么是软件测试？
› 是为了发现错误而执行程序的过程。
› 发现错误是为了更正错误，最终得到一个高质量的软件系统。
› 软件测试的对象：整个软件定义、开发周期的产品
› 暴露问题并不是软件测试的最终目的，发现问题是为了解决问
题，测试阶段的根本目标是尽可能多地发现并排除软件中潜藏
的错误，最终把一个高质量的软件系统交给用户使用。
› 测试工作量约占开发总工作量的40%以上

1.软件测试的目标

G.Myers给出了关于测试的一些规则，这些规则也可以看作是测试的
目标或定义。
(1) 测试是为了发现程序中的错误而执行程序的过程；
(2) 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
(3) 成功的测试是发现了至今为止尚未发现的错误的测试。

2.软件测试准则

1 ）所有测试都能追溯到用户需求
2 ）应该远在测试开始之前就制定出测试计划
3 ）应该把 Pareto原理应用到软件测试中
群集现象： 80 ％的错误可能是由 20 ％的模块造成的
4 ）从“小规模”测试开始，逐步过渡到“大规模”测试
5 ）穷举测试是不可能的
测试只能证明程序有错，不能证明程序没有错误
6 ）应由独立的第三方从事测试工作（专业的测试技术及方法）

3.测试方法

• 黑盒测试

  又称功能测试、数据驱动测试或基于规格说明的测试。它是一种从用户观点出发的测试。用这种方法进行测试时，把被测程序当作一个黑盒，不考虑程序内部结构和特性，测试者只考虑程序输入输出和程序功能，根据需求规格说明书来设计测试用例，推断测试结果的正确性。

  已知产品应该具有的功能，可以通过测试来检验每个功能是否符合设计要求。（不考虑内部结构和处理过程）

• 白盒测试:

  又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序内部细节的严密检验，针对特定条件设计测试用例，对软件的逻辑路径进行测试。因此采用白盒测试技术时，必须有设计规约及程序清单。

  已知产品的内部工作过程，可以通过白盒测试来检验每种内部操作是否按要求的规定正常进行。(测试者需知道程序的逻辑和处理算法，检验程序中的执行通路)
  

4.测试步骤

› 大型软件系统的测试过程基本上由下述几个步骤组成。
– 1. 模块测试 — 单元测试
– 2. 子系统测试 — 局部测试（集成测试）
– 3. 系统测试 — 集成测试
– 4. 验收测试 — 用户参与，确认测试
– 5. 平行运行 — 新旧系统对比

模块测试
软件系统中每个模块完成相对独立的功能，可以单独进行测试，模块测试又称单元测试，它把每个模块作为单独的实体来测试。（发现编码和详细设计的错误）

子系统测试
子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。（解决模块间协调和通信，着重测试模块接口）

系统测试（集成测试）
系统测试是把经过测试的子系统装配成一个完整的系统来测试。

验收测试
验收测试把软件系统作为单一的实体进行测试（利用用户的实际数据测试，验证系统确实能够满足用户需求，确认测试）

平行运行
平行运行是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果，看新系统能否满足要求。

5.测试阶段的信息流

---

3.单元测试

单元测试的一般方法：
1.首先通过编译系统检查并改正程序中所有的语法错误；

2.然后用详细设计说明为指南，对重要的控制路径进行测试，以便发现模块内部的错误。

3.通常，单元测试使用白盒测试方法

› 在单元测试期间着重从下述5个方面对模块进行测试
– 1. 模块接口
– 2. 局部数据结构
– 3. 重要的执行通路
– 4. 出错处理通路
– 5. 边界条件

1.模块接口测试

• 在单元测试的开始，应对通过被测模块的数据流进行测试。
• 测试项目：
  • 调用本模块的输入参数是否正确（参数个数，次序，属
    性等）；
  • 本模块调用子模块时，输入给子模块的参数是否正确；
  • 输出给标准函数的参数是否正确；
  • 全局量的定义和用法在各摸块中是否一致；
  • 与外部设备的输入输出是否正确

2.局部数据结构测试

• 测试项目：
  • 不正确或不一致的数据类型说明
  • 使用尚未赋值或尚未初始化的变量
  • 错误的初始值或错误的缺省值
  • 变量名拼写错或书写错
  • 不一致的数据类型

3.重要的执行通路测试

• 测试用例要适当 : 关键
• 通常不可能进行穷尽测试，在单元测试期间应该选取最具代表性，最可能发现错误的执行通路进行测试。

4.错误处理测试

• 着重测试以下可能发生的错误：
  • 出错的措述是否难以理解
  • 出错的描述是否能够对错误定位
  • 显示的错误与实际的错误是否相符
  • 对错误条件的处理正确与否
  • 在对错误进行处理之前，错误条件是否已经引起系统的干预等

5.边界测试

• 重点检查刚好等于、大于或小于边界值的数据;

6.代码审查

由审查小组,人工测试源程序称为代码审查。它是一种非常有效的程序验证技术，对于典型的程序来说，可以查出30%～70%的逻辑设计错误和编码错误。审查小组最好由下述4人组成：
(1) 组长，应该是一个很有能力的程序员，而且没有直接参与这项工程；
(2) 程序的设计者；
(3) 程序的编写者；
(4) 程序的测试者。

7.计算机测试

• 机器测试：通过运行模块发现问题。
  两个重要概念：
  • 驱动程序（ driver ) ：相当于被测试模块的“主程序”，接收测
    试数据，把这些数据传送给被测试的模块，并且输出相关结果。
  • 存根程序（stub）：代替被测试模块所调用的模块。因此存根程
    序也可以称为“虚拟子程序”。

4.集成测试

集成测试：在单元测试之后，将模块组装成系统，为发现并
排除模块在连接中可能出现的问题，而进行的测试。
› 需要考虑：
– 模块连接时穿越模块接口的数据是否会丢失；
– 各子功能组合起来，能否达到预期要求的功能
– 全局数据结构是否有问题；
– 单个模块的误差累积起来，是否会放大至不能接受的程度。

集成测试在组装程序时有两种组装方式：
› ① 非渐增式组装方式
› 对每个模块分别进行单元测试，再把所有模块组装成一个完整的系统进行的
测试，从而得到要求的软件系统。
› ② 渐增式组装方式
› 把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完
再把下一个应该测试的模块结合进来测试，这种每次增加一个模块的方法称
为渐增式测试。
目前在进行集成测试时普遍采用渐增式测试方法。

1.渐增式测试方式

使用渐增式测试方法把模块结合到软件系统中去时，有自顶向下和自底向上两种集成策略。

5.确认测试

确认测试也称为验收测试，它的目标是验证软件的有效性。
什么是软件有效性？
简单定义： 如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的。

1.确认测试的范围

主体：以用户为主或用户积极参与
方法：黑盒测试法
测试目的：

• 确定软件的特性是否与需求相符；

• 所有的文档都是正确且便于使用；

• 其它软件需求。

测试结果：

• 与预期的结果相符；

• 与预期的结果不符：

• 要提交一份问题报告。

2.软件配置复查

目的：

• 各方面的质量都符合要求；
• 具有维护阶段所必需的细节；
• 而且已经编排好分类的目录。
• 应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。

3.Alpha和Beta测试

• Alpha测试：由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。
  Alpha测试是在受控的环境中进行的。
• Beta测试：是软件在开发者不能控制的环境中的“真实”应用。
• 注意：只有当Alpha测试达到一定的可靠程度时，才开始 Beta 测试。

6.白盒测试技术

1.逻辑覆盖

• 所谓逻辑覆盖是对一系列测试过程的总称，以程序内部的逻辑结构为基础设计测试用例的技术
• 这组测试过程可以逐渐进行越来越完整的通路测试

› 从覆盖源程序的详尽程度，逻辑覆盖程度分为以下不同等级:

– 语句覆盖
– 判定覆盖
– 条件覆盖
– 判定一条件覆盖
– 条件组合覆盖
– 点覆盖
– 边覆盖
– 路径覆盖

语句覆盖：设计的测试用例能使程序中每条语句至少执行一次。

判定覆盖（分支覆盖）：不仅每个语句至少执行一次，而且每个判定的每个分支至少执行一次

条件覆盖：不仅每个语句至少执行一次，而且使判定表达式中每个条件都取到各种可能的结果

判定-条件覆盖：设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，每个判断中的每个分支至少执行一次。

条件组合覆盖：选择足够多的测试数据，使每个判定表达式中条件的各种可能组合都至少出现一次。

点覆盖: 要求选取足够多的测试数据，使得程序执行路径至少经过流图的每个结点一次，由于流图的每个结点与一条或多条语句相对应，显然，点覆盖标准和语句覆盖标准是相同的。

边覆盖：使得程序执行路径至少经过程序图中每条边一次。 通常边覆盖和判定覆盖式一致的

路径覆盖：选取足够多的测试用例，使得程序的每条可能路径都至少执行一次。

7.黑盒测试技术

黑盒测试（功能测试）主要是为了发现以下错误：
› 是否有不正确或遗漏了的功能？
› 能否正确地接受输入？能否正确的输出结果？
› 是否有数据结构错误或外部数据库访问错误？
› 性能上是否能够满足要求？
› 是否有初始化或终止性错误？

几种黑盒测试技术：
› 等价类划分、边界值分析、错误推测法、因果图

1.等价划分（等价类划分）

基本思想
把所有可能的输入数据（包括有效或无效的），划分成若干数据类（ 区域），然后从每个数据类（区域）中选取少数有代表性的数据做为测试用例。

• 划分原则：同一区域中各个输入数据对于揭露程序中
  的错误是等价的，（称为等价类）。
• 等价类测试的关键：选择并确定类的等价关系

根据等价类设计测试方案的步骤

• 设计一新测试方案，尽可能多覆盖尚未被覆盖的有效等价类，重复此步，直至所有有效等价类被覆盖；
• 设计一新测试方案，覆盖且仅覆盖一个无效等价类，重复此步，直到所有无效等价类被覆盖。（为了逐个
  排除错误）

2.边界值分析

边界值分析方法思想：确定边界之后，选取正好等于、刚刚大于或刚刚小于边界的值做为测试数据，而不是选取等价类中典型值或任意值做为测试数据。

在实际设计测试方案时，常常结合使用等价划分和边界值分析两种技术，把一些等价类的边界值作为测试用例进行测试

8.调试

软件调试是在成功完成测试之后，进一步诊断和改正程序中潜在的错误。
调试活动的组成部分：
确定程序中可疑错误的确切性质和位置。对程序（设计，编码）进行修改，排除这个错误

1.调试过程

调试在技术上的难度

• 错误现象与原因所处的位置可能相距甚远。当其它错误得到纠正时，这一错误所表现出的现象可能会暂时消失，但并未实际排除。
• 非错误原因（例如，舍入误差）
• 不容易发现的人为错误。 – 现象是由于难于精确再现的输人状态（例如，实时应用中输入顺序
  不确定）引起。
• 现象可能是周期出现的。在软、硬件结合的嵌入式系统中常常遇到。

2.调试途径

强行排错(蛮干法)
效率最低的方法，常见形式：
打印出所有存储内容、代码
在程序特定部位设置打印语句

是效率最低的程序调试方法！

回溯法（跟踪法）

• 根据错误症状位置，人工沿程序控制流程向回追踪
  源代码。
• 适用于小程序，路径数目很大时无法进行

归纳法调试
一种从特殊现象推断一般原理的思考方法。
包括：对分查找法、归纳法、演绎法

9.软件可靠性

1.基本概念

1.什么是软件可靠性?
是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
2.什么是软件可用性?
是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。

3.可靠性和可用性的主要差别：
可靠性意味着在 0 到 t 这段时间间隔内系统没有失效；
可用性只意味着在时刻 t ，系统是正常运行的

第八章 维护

1.软件维护的定义

​ 软件维护是软件生存周期的最后一个阶段，它是在软件交付使用之后，为了改正错误或满足新的要求而修改软件的过程。因此不属于系统开发过程。
​ 据统计一个大、中型软件的开发周期一般为1-3年，有效运行周期可达5-10年。在这段时间里，我们除了要改正软件中残留的错误外，更多的是要随着计算机技术的发展，不断更新软件版本，适应改善了的软、硬件运行环境，增加软件产品的新需求，这些都属于维护范畴的工作。

1.改正性维护

​ 通常，在软件开发过程中所进行的测试都是不完全、不彻底的，软件中必然会有一些潜伏的错误被带到运行阶段来。用户常常将把他们遇到的问题报告给软件维护人员，要求解决。我们把诊断和改正软件错误的过程称为改正性维护。

2.适应性维护

计算机科学技术领域的各个方面都在迅速进步，大约每过一段时间就有新一代的硬件宣告出现。适应性维护就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。
例如，适应性维护可以是修改原在xp操作系统中运行的程序，使之能在vista操作系统中运行。

3.完善性维护

在使用软件的过程中，用户往往提出增加新功能或改善某些已有功能的要求，还可能提出提高程序性能的要求。为了满足这类要求而修改软件的活动，称为完善性维护。
例如，在储蓄系统交付银行使用之后，增加扣除利息税的功能；

4.预防性维护

​ 当为了提高未来的可维护性或可靠性，或为了给未来的改进工作奠定更好的基础而修改软件时，就出现了第四类维护活动，这类维护活动称为预防性维护。
​ 把预防性维护定义为：“把今天的方法学应用于昨天的系统以满足明天的需要”。也就是说，预防性维护就是采用先进的软件工程方法对需要维护的软件或软件中的某一部分，主动地进行重新设计、编码和测试，以满足明天的需要” 。

2.软件维护的特点

1.结构化维护与非结构化维护差别悬殊

非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从阅读程序代码开始，而且常常由于程序内部文档不足而使维护更困难（诸如软件结构、数据结构、系统接口、性能或设计约束等微妙的特点是难于搞清的，而且常常误解了这一类特点）。最终对程序代码所做的改动的后果是难于估量的。
因为没有测试方面的文档，难以进行回归测试。这就是非结构化维护，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
结构化维护
如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。
上面描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法学的结果。（它确实能减少精力的浪费并且能提高维护的总体质量。）

2.维护的代价高昂

​ 在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的35%～40%，1980年上升为40%～60%，1990年上升为70%～80%。

​ 软件的维护代价包括有形代价、无形代价和生产率代价三部分 (了解)

3. 维护的问题很多

（1） 理解他人写的程序往往是非常困难的，软件配置越少，困难越大。如果程序只有代码而没有文档，则会出现严重的问题。

（2） 没有合适的文档资料或文档资料太少。首先要认识到软件必须有文档资料，其次文档资料必须是可以理解的并与源程序一致。否则软件修改将很困难，还容易引入新的问题。
（3） 对软件进行维护时，经常得不到开发人员的帮助。因为维护时间较长，需要解释软件时，原来写程序的人往往不在现场。

（4） 大多数软件在设计时没有考虑将来的修改。除非采用强调模块独立原理的设计方法，否则软件的修改将是困难的，并且容易出错。

（5） 软件维护不是一项吸引人的工作。这是因为维护工作困难大，常使人受到挫折。

3.软件维护过程

1.维护组织

虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。维护机构成员一般包括：配置管理员、维护控制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理员去评价

2. 维护报告

​ 应该用标准化的格式表达所有软件维护要求。软件维护人员通常给用户提供空白的维护要求表——有时称为软件问题报告表，这个表格由要求维护活动的用户填写。
对于每一个错误 必须完整描述导致出现错误的环境（包括输入数据，全部输出数据，以及其他有关信息)。对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。

维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息：
（1）满足维护要求表中提出的要求所需要的工作量；
（2）维护要求的性质；
（3）这项要求的优先次序；
（4）与修改有关的事后数据。
在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。

3. 维护的事件流

4. 保存维护记录

在处理每项维护要求的过程中，应该收集和保存与维护工作有关的数据

5. 评价维护活动

—————————————————————————————————

4.软件的可维护性

指软件能够被维护人员理解、改正、适应和完善以适应新的环境的难易程度

1.决定软件可维护性的因素

1. 可理解性
   可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。
2. 可测试性
   在设计开发阶段应该注意尽量把软件设计成容易测试和容易诊断的，可用的测试工具和调试工具对测试和诊断非常重要。程序的环形复杂度越高，测试难度越大。
3. 可修改性
   软件的可修改程度与软件设计阶段采用的原则和策略是直接相关的。如：模块的耦合、内聚、控制范围和作用范围、局部化程度都直接影响软件的可修改性。
4. 可移植性
   把程序从一种环境转移到另一种环境的难易程度
5. 可重用性
   同一事物不做修改或稍加改动就可在不同环境中多次重复用

2.文档

影响软件可维护性的决定因素

​ 1. 用户文档：描述系统功能和使用方法，并不关心系统实现手段（用户角度）

2. 系统文档：描述系统设计、实现和测试各方面的内容。

总的说来，软件文档应该满足下述要求：
从用户角度出发
（1）必须说明系统能做什么（功能描述）；
（2）必须描述如何使用（使用手册）这个系统，没有这种描述即使是最简单的系统也无法使用；
（3）必须描述怎样安装（安装文档）和管理（参考手册、操作用指南）这个系统；

从开发者角度出发
（1）必须描述系统需求和设计；
（2）必须描述系统的实现和测试，以便使系统成为可维护的。

5.预防性维护

定义：为了提高未来的可维护性和可靠性，而主动的修改软件。

进行预防性维护的主要理由：
（1）对于旧系统而言，维护一行原代码的代价可能是最初开该行源代码代价的14－40倍；
（2）使用最新的设计理念，重新设计软件体系结构（程序和数据结构）对将来的维护有较大帮助；
（3）原有旧系统可作为软件原型使用，能提高开发效率。
（4）利用软件再工程工具（自学）可以自动完成部分工作。

今天的文章软件工程必背知识点_软件工程知识点总结分享到此就结束了，感谢您的阅读。