第一章：课程概述

1.1 软件危机

1.1.1 计算机软件的四个发展阶段

程序设计阶段、程序系统阶段、软件工程阶段、面向对象阶段

1.1.2 什么是软件危机（考点）

软件危机是指在计算机软件的开发和维护过程种所遇到的一系列严重问题。

1.1.3 软件危机产生时间(考点)

20 世纪60年代

1.1.4 软件危机需要解决的两个问题

①如何快速地开发软件，满足对软件日益增长地需求

②如何维护数量不断膨胀地已有软件

1.1.5 软件危机的具体表现

• 对软件开发成本和进度的估计不准确；
• 质量不可靠；
• 不可维护；
• 没有适当的文档资料；
• 软件成本在计算机系统总成本中所占的比例逐年上升。

1.1.6 软件危机的产生原因： （考点）

（1）与软件本身的特点有关。

（2）与软件开发和维护的方法不正确有关。

←

主要原因

1.2 软件工程

1.2.1 什么是软件工程(考点)

软件工程是指采用工程地概念、原理、技术和方法来开发与维护软件

，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量地软件并有效地维护它。

1.2.2 软件工程目的

实现按预期的进度和经费完成软件生产计划，提高软件的生产率和可靠性

1.2.3 软件工程方法学三要素（考点）

方法：

是指完成软件开发的各项任务的技术方法，既回答”怎么做“的问题

工具：

是指为运用方法而提供的自动或者半自动的软件工程支撑环境

过程：

需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤

1.2.4 软件工程方法学之传统方法学（考点）

采用结构化技术，将任务划分为多个阶段，然后顺序地完成每个阶段地任务，每个阶段地任务相互独立，且前一个阶段是后一个阶段的前提和基础。


缺点：


使用传统方法学开发的软件，维护起来仍然困难

数据与操作分离

传统方法学的三大模型

：功能模型（数据流图）、数据模型（E-R图）、行为模型（状态转换图）

1.2.5 软件工程方法学之面向对象方法学（考点）

把数据和行为看成同等重要，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法

面向对象方法学的三大模型：

（简答）

1.2.6 形式化方法学

是一种基于形式化数学变换的软件开发方法，将系统的规格说明转换为可执行的程序

1.3 软件生命周期

1.3.1 三个时期，八个阶段（考点）

制定计划

——解决什么问题，目标及其可行性（技术、人员、财力、社会）


需求分析

——做什么、验收标准


总体设计

——怎么做


详细设计

——具体怎么做


程序编写

——实现


软件测试

——保证软件质量


运行/维护

——保证正常而可靠地运用

1.3.2 为什么要进行阶段划分（考点）

把整个软件生存周期划分为若干阶段，

使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理

1.3.3 软件维护在软件生命周期中占比60%（重点）

1.4 软件过程

1.4.1 瀑布模型

特点：

• 阶段间具有顺序性和依赖性
• 推迟实现的观点：清楚区分逻辑设计和物理设计，尽可能推迟程序的物理实现
• 质量保证的观点：瀑布模型
  
  每个阶段必须先完成规定文档
  
  ，每个阶段结束前都要对完成的文档进行评审

缺点：（考点）

• 由文档驱动（缺点也是特点）
• 不能适用于用户需求变动
  
  

1.4.4 快速原型模型

以某个软件原型为参照模型的开发方法，叫做原型法。在初步需求分析之后，马上向客户展示一个软件产品原型，对客户进行培训，让客户试用，在试用中收集客户意见，修改原型，再让客户试用，反复循环几次，直到客户确认为止。

1.4.5 螺旋模型（考点）

螺旋模型就是在

每个阶段开始之前都增加了风险分析的快速原型模型

。

第二章：可行性研究

2.1 可行性研究的任务（考点）

2.1.1 可行性研究的目的

用最小的代价在尽可能短的时间内确定问题是否能够解决，

不是解决问题，而是确定问题是否值得去解决。(即找出最优解)

2.1.2 可行性研究的实质

进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。

2.1.3 可行性研究的内容

1、首先进一步分析和澄清问题定义，导出系统的逻辑模型；

2、然后从系统逻辑模型出发，探索若干种可供选择的主要解法(即系统实现方案)；

3、对每种解法都研究它的可行性，至少应该从三方面研究每种解法的可行性 。

2.1.4 可行性研究的主要方面：

1、技术可行性，使用现有的技术能实现这个系统吗?

2、经济可行性，这个系统的经济效益能超过它的开发成本吗?

3、操作可行性，系统的操作方式在这个用户组织内行得通吗?

2.2 可行性研究过程

• 复查系统规模和目标
• 研究目前正在使用的系统
• 导出新系统的高层逻辑模型
• 进一步定义问题
  
  
  可行性研究的前4个步骤实质上构成一个循环。
  
• 导出和评价供选择的解法
• 推荐行动方针
• 草拟开发计划
• 书写文档提交审查
  
  

2.3 系统流程图

2.3.1 系统流程图概念

系统流程图

表达的是数据在系统各部件之间流动的情况

，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不是程序流图。

2.3.2 系统流程图符号

基本符号：

2.3.3 举例

某校办工厂有一个库房，存放该厂生产需要的各种零件器材，库房中的各种零件器材的数量及其库存量临界值等数据记录在库存主文件上，当库房中零件器材数量发生变化时，应更改库存文件。若某种零件器材的库存量少于库存临界值，则立即报告采购部门以便订货，规定每天向采购部门送一份采购报告。

2.4 数据流图（考点）

2.4.1 数据流图概念

数据流图是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。

2.4.2 数据流图符号（重点）

数据源点/终点：

通常是人或部门，可重复表示；


处理：

一个处理框可以代表一系列程序、单个程序或程序的一个模块；


数据存储：

可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等，数据存储是处于静止状态的数据；


数据流：

描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件 ，数据流是处于运动中的数据。

2.4.3 步骤

①画出最概括的系统模型



②细化，描绘系统的主要功能



③对系统的主要功能进一步细化

2.4.4 细化时的注意事项

（1）当进一步分解涉及如何具体的实现一个功能时就不应该再分解了。

（2）当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入输出数据流必须相同。

（3）注意对处理进行编号的方法。

2.5 数据字典

2.5.1 数据字典概念

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。

是数据流图和数据字典共同构成系统的逻辑模型。

2.5.2 数据字典的用途

1、数据字典最重要的用途是作为分析阶段的工具；

2、数据字典中包含的每个数据元素的控制信息是很有价值的。很容易估计改变一个数据将产生的影响；

3、数据字典是开发数据库的第一步，而且是很有价值的一步。

2.6 成本/效益分析的方法（考点）

2.6.1 货币的时间价值

通常利用利率的形式表示货币的时间价值。假设年利率为i，如果现存入P元，则n年后可以得到的钱为：

F = P(1 + i)^n
P = F/(1 + i)^n 

2.6.2 投资回收期

通常用投资回收期衡量一项开发工程的价值。所谓投资回收期就是使累计的经济效益等于最初投资所需要的时间。显然投资回收期越短，就能越快获得利润，因此这项工程也就越值得投资。

第三章：需求分析

3.1 分析建模与规格说明

3.1.1 需求分析的任务

需求分析的任务不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

3.1.2 需求分析过程应该建立3种模型（考点）

数据模型、功能模型、行为模型

数据字典：

是分析模型的核心，它描述软件使用或产生的所有数据对象。

(详见上一章)

实体-联系图：

描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。

数据流图：

描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，因此，数据流图是建立功能模型的基础。

(详见上一章)

状态转换图(简称为状态图)：

指明了作为外部事件结果的系统行为。为此，状态转换图描绘了系统的各种行为模式(称为“状态”)和在不同状态间转换的方式。状态转换图是行为建模的基础。

3.1.3 软件需求规格说明

通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。

3.2 实体联系图（E-R图)（考点）

3.2.1 概念

是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，且与在软件系统中的实现方法无关。

数据模型中包含3种相互关联的信息：

1、数据对象

2、数据对象的属性：定义了数据对象的性质

3、数据对象彼此间相互连接的关系

3.2.2 实体-联系图的符号（重点）

实体

(即数据对象)，用矩形框表示；


关系

，用连接相关实体的菱形框表示；


属性

，用椭圆形或圆角矩形表示，并用直线把实体(或关系)与其属性连接起来。

3.2.3 ER图的优点

1、比较接近人的习惯思维方式；

2、用简单的图形符号表达系统分析员对问题域的理解，用户也容易理解，可以作为用户与分析员之间有效的交流工具。

3.2.4 例子

银行储蓄系统的ER图

银行计算机储蓄系统的工作过程大致如下：

储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息，并印出存单给储户；

3.3 数据规范化

3.3.1 数据结构规范化

软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。

3.3.2 范式

通常用“范式(normal forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。

范式级别越高，存储同样数据需要分解成更多张表，因此，“存储自身”过程越复杂。

随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。

范式级别提高则需要访问的表增多，因此性能(速度)将下降。

3.3.3 第一、第二和第三范式的定义

第一范式，每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。

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

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

3.4 状态转换图

3.4.1 状态转换图概念

状态转换图：通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。

3.4.2 状态

状态：

是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。

状态主要有：


1、初态(即初始状态)，只能有1个

2、终态(即最终状态)，可以有多个

3、中间状态

3.4.3 事件

是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。

3.4.4 符号

初态：

用实心圆表示；

终态：

用一对同心圆(内圆为实心圆)表示；

中间状态：

用圆角矩形表示，分成上、中、下3部分。

1、上面部分—–为状态的名称；

2、中间部分—–为状态变量的名字和值；

3、下面部分—–是活动表。

带箭头的连线：

称为状态转换，箭头指明了转换方向。

3.4.5 例子

电话系统

第五章：总体设计

5.1 总体设计的任务

5.1.1 总体设计过程

首先寻找实现目标系统的各种不同的方案；然后分析员从这些供选择的方案中选取若干个合理的方案，从中选出一个最佳方案向用户和使用部门负责人推荐；分析员应该进一步为这个最佳方案设计软件结构，进行必要的数据库设计，确定测试要求并且制定测试计划。

5.2.2 总体设计的主要阶段

• 
  系统设计阶段
  
  
  从数据流图出发构想完成系统功能的若干种合理的物理方案，并从中选出一个最佳方案

• 
  结构设计阶段
  
  
  确定程序由哪些模块组成以及这些模块之间的关系

5.2.3 典型的总体设步骤

• 
  1. 设想供选择的方案
  
  ：考虑各种可能的实现方案，力求从中选出最佳方案。

• 
  2. 选取合理的方案
  
  ：为每个合理方案准备：系统流程图、组成系统的物理元素清单、成本/效益分析、实现这个系统的进度计划

• 
  3. 推荐最佳方案
  
  ：综合分析对比各种合理方案的利弊，推荐一个最佳的方案。

• 
  4. 功能分解
  
  ：首先进行结构设计，然后进行过程设计。结构设计确定程序由哪些模块组成，以及这些模块之间的关系；过程设计确定每个模块的处理过程。

• 
  5. 设计软件结构
  

• 
  6. 设计数据库
  

• 
  7. 制定测试计划
  

• 
  8. 书写文档
  

• 
  9. 审查和复审
  

5.2 设计原理

5.2.1 模块化

模块化就是把程序划分成独立命名且

可独立访问

的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。

模块化的作用

• 采用模块化原理可以使软件结构清晰，不仅容易设计也容易阅读和理解。
• 模块化使软件容易测试和调试，因而有助于提高软件的可靠性。
• 模块化能够提高软件的可修改性。
• 模块化也有助于软件开发工程的组织管理。

5.2.2 抽象

用自顶向下、由抽象到具体的方式分配控制

软件结构顶层的模块，控制了系统的主要功能并且影响全局；

在软件结构底层的模块，完成对数据的一个具体处理。

5.2.3 逐步求精

逐步求精与抽象是互补的概念

，由抽象到具体地构造出软件的的层次结构。

抽象使得设计者能够说明过程和数据,同时却忽略了底层细节。

求精则帮助设计者在设计过程中逐步揭示出底层的细节。

5.2.4 信息隐藏和局部化

信息隐藏：

应该这样设计和确定模块，使得一个

模块内包含的信息

（过程和数据）对于

不需要这些信息的模块

来说，是

不能访问的

。

局部化：

把一些关系密切的软件元素

物理地

彼此靠近。（局部化有助于信息隐藏）

5.2.5 模块独立

模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。这样设计软件结构，使得每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系很简单。

模块独立的重要性：

• 有效的模块化(即具有独立的模块)的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化，当许多人分工合作开发同一个软件时，这个优点尤其重要。

• 独立的模块比较容易测试和维护。这是因为相对说来，修改设计和程序需要的工作量比较小，错误传播范围小，需要扩充功能时能够“插入”模块。

5.2.6 模块独立的衡量标准（考点）

1、耦合：

耦合衡量不同模块彼此间互相依赖(连接)的紧密程度。耦合要低，即每个模块和其他模块之间的关系要简单；

2、内聚：

内聚衡量一个模块内部各个元素彼此结合的紧密程度。内聚要高，每个模块完成一个相对独立的特定子功能。

5.3 面向数据流的设计方法（考点）

5.3.1 总述

面向数据流的设计方法定义了一些不同的“映射”，利用这些映射可以把数据流图变换成软件结构。

因为任何软件系统都可以用数据流图表示，所以面向数据流的设计方法理论上可以设计任何软件的结构。通常所说的结构化设计方法(简称SD方法)，也就是基于数据流的设计方法。

5.3.2 概念（重点）

面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。

信息流有两种类型：

1、变换流

信息沿输入通路进入系统，同时由外部形式变换成内部形式，进入系统的信息通过变换中心，经加工处理以后再沿输出通路变换成外部形式离开软件系统。




2、事务流

数据沿输入通路到达一个处理T，T根据输入数据的类型在若干个动作序列中选出一个来执行。处理T称为事务中心，它完成下述任务：

■接收输入数据；

■分析每个事务以确定它的类型；

■根据事务类型选取一条活动通路。

3、设计过程

第六章：详细设计

6.1 详细设计的任务

详细设计阶段的根本目标是经过这个阶段的设计工作得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。详细设计阶段的任务还不是具体地编写程序，而是要设计出程序的“蓝图”，以后程序员将根据这个蓝图写出实际的程序代码。

结构程序设计技术是实现上述目标的关键技术，因此是详细设计的逻辑基础。

6.2 结构程序设计

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

尽可能少用GO TO语句的程序设计方法，最好仅在检测出错误时才使用GO TO语句，而且应该总是使用前向GO TO语句

6.3 过程设计的工具

6.3.1 图形工具（重点）

将过程细节用图形来表示，在图中，逻辑结构用具体的图形表示。

• 程序流程图（Program Flow Chart）
• 盒图（Box Diagram）
• PAD图（Problem Analysis Diagram）

6.3.2 列表工具

利用表来表示过程细节，表列出了各种操作和相应的条件。

• 判定表&判定树（Decision Table & Tree）表示复杂的条件（input）组合与应做动作（output）之间的对应关系。

6.3.3 语言工具

用类语言（伪码）表示过程的细节，很接近编程语言。

• PDL（Program Design Language）：又称Pseudo code

6.3.4 程序流程图

优点：直观、容易掌握，且历史悠久，使用广泛。

缺点：对于提高大型系统的可理解性作用甚微；不易表示数据结构；转移控制太方便。

趋势：使用越来越少。

6.6.5 盒图（考点）

特点：

• 没有箭头，不允许随意转移控制。
• 每个矩形框（Case中条件取值例外）都是一个功能域，结构表示明确。
• 局部及全程数据的作用域易见。
• 易表现嵌套关系以及模块的层次结构。

根据代码画盒图

6.6.6 PAD图

用二维树形结构的图来表示程序的控制流

6.4 程序复杂度的定量度量（考点，大题）

6.4.1 流图的定义

McCabe方法根据程序控制流的复杂程度定量度量程序的复杂程度，这样度量出的结果称为程序的环形复杂度。

所谓流图实质上是“退化了的”程序流程图，它仅仅描绘程序的控制流程，完全不表现对数据的具体操作以及分支或循环的具体条件。

6.4.2 流图的表示：

结点：

用圆表示，一个圆代表一条或多条语句。

边：

箭头线称为边，代表控制流。在流图中一条边必须终止于一个结点，即使这个结点并不代表任何语句。

区域：

由边和结点围成的面积称为区域，包括图外部未被围起来的区域。

6.4.3 映射方法(如何绘制流图)：（重点）

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

对于顺序结构，

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




对于选择结构，

开始语句映射成一个结点；两条分支至少各映射成一个结点；结束映射成一个结点。

对于循环结构，

开始和结束语句各映射成一个结点。




例：


程序：

void func(int x,int y){ //画图时，不需要考虑此行
    while(x>0){ //1
    	int sum = x+y; //2
        if(sum>1){ //3
            x--; //4
            y--; //5
        }else{
            if(sum<-1){ //6
                a-=2; //7
            }else{
                a-=4; //8
            } //9
        } // end of if(sum>1) //10
    }    // end of while
    x = x+y; //11
} // end of func //画图时，不需要考虑此行

程序对应的程序流程图：



程序对应的流图：

6.4.4 环形复杂度的计算方法（重点）

以下三种方法任选一种（建议第三种）：

1. 流图中线性无关的区域数等于环形复杂度。
2. 流图G的环形复杂度 V(G)=E-N+2，其中，E是流图中边的条数，N是结点数。
3. 流图G的环形复杂度V(G)=P+1，其中，P是流图中判定结点（选择结构）的数目。

6.4.5 线性独立路径的基本集合（重点，难点，本来在第七章的）

所谓独立路径是指至少引入程序中的一个新的处理语句集合或一个新条件的路径，用流图的术语描述就是：

独立路径至少包含之前定义的路径没有使用过的边。

对于上面的例子，求出环形复杂度为4，即有4条独立路径

路径1：1->11

路径2：1->2->3->4->5->10->1->…

路径3：1->2->3->6->7->9->10->1->…

路径4：1->2->3->6->8->9->10->1->…

注：(…)表示可以后接通过该控制结构的其余部分的任意路径，如路径2可以后接路径1也可以后接路径2。

第七章：实现

7.1 确认测试

7.1.1 测试方法（考点）

• 
  黑盒测试
  
  
  把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程,是在程序接口进行的测试即黑盒是根据程序外部特征进行测试。
• 
  白盒测试
  
  
  按照程序内部的逻辑来测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。

7.1.2 测试阶段工作步骤（考点）

• 模块测试: 检验每个模块能否单独工作.

• 子系统测试：把经过模块测试的模块放在一起形成一个子系统来测试，主要测试模块间接口

• 系统测试: 把经过测试的子系统装配成一个完整的系统来测试

• 验收测试：让用户对软件进行测试，并重新执行已经做过的测试的某个子集

7.2 白盒测试

7.2.1 逻辑覆盖（考点）

有选择地执行程序中某些最有代表性的通路是对穷尽测试的惟一可行的替代办法。

从覆盖源程序语句的详尽程度分析，大致有以下一些不同的覆盖标准：

7.2.2 控制结构测试

1. 基本路径测试

首先计算程序的环形复杂度，以该复杂度为指南定义执行路径的基本集合；

从该基本集合导出的测试用例可保证程序中的每条语句至少执行一次，而且每个条件在执行时都将分别取真、假两种值。

2. 循环测试

循环测试是一种白盒测试技术，它专注于测试循环结构的有效性。

在结构化的程序中通常只有3种循环，即简单循环、串接循环和嵌套循环。

7.3 黑盒测试

7.3.1 等价划分

等价划分是一种黑盒测试技术，把程序的输入域划分成若干个数据类，据此导出测试用例。 每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。

等价类划分的启发式规则

• 如果规定了输入值的范围，则可划分出一个有效的等价类(输入值在此范围内)，两个无效的等价类(输入值小于最小值或大于最大值)；

• 如果规定了输入数据的个数，则类似地也可划分出一个有效的等价类和两个无效的等价类；

• 如果规定了输入数据的一组值，而且程序对不同输入值做不同处理，则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类(任一个不允许的输入值)；

• 如果规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类(符合规则)和若干个无效的等价类(从各种不同角度违反规则)；

• 如果规定了输入数据为整型，则可以划分出正整数、零和负整数等3个有效类；

• 如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。

7.3.2 边界值分析

经验表明，处理边界情况时程序最容易发生错误。例如，许多程序错误出现在下标、纯量、数据结构和循环等等的边界附近。

使用边界值分析方法设计测试方案首先应该确定边界情况。选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值。

通常设计测试方案时总是联合使用等价划分和边界值分析两种技术。

7.3.3 错误推测

不同类型不同特点的程序通常又有一些特殊的容易出错的情况。因此必须依靠测试人员的经验和直觉，从各种可能的测试方案中选出一些最可能引起程序出错的方案。

错误推测法在很大程度上靠直觉和经验进行。它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试方案。

第八章 软件维护

8.1 什么是软件维护

8.1.1 软件维护的定义（考点）

所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。

8.1.2 软件维护的特点

软件维护的成本是开发成本的4倍左右

8.2 软件维护过程

8.2.1 软件维护的活动（考点）

• 改正性维护：诊断和改正错误的过程，占比约为17%-21%
• 适应性维护：适应环境变换而进行的修改软件的活动，占比约18%-25%
• 完善性维护：新增功能或者修改已有功能所进行的维护，占比约50%-66%
• 预防性维护：主动地对软件进行重新设计、编码和测试，占比约4%

只有预防性维护是主动地

8.2.2 维护的类别（考点）

结构化维护和非结构化维护

区别：有无良好的方法学开发软件

8.2.3 软件维护的因素与维护活动的侧重点