软件工程导论课程总结

1 软件过程概述

1.1软件危机

软件危机

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

软件危机典型表现

•对软件开发成本和进度的估计常常不准 确。开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。

• 用户对“已完成”系统不满意的现象经常发生。

• 软件产品的质量往往靠不住。Bug一大堆， Patch一个接一个。

• 软件的可维护程度非常之低。

• 软件通常没有适当的文档资料。

• 软件的成本不断提高。

• 软件开发生产率的提高赶不上硬件的发展和人们需求的增长。

软件危机的原因

● 一方面是与软件本身的特点有关 — 如何开发软件，以满足不断增长，日趋复杂的需求。

● 另一方面是由软件开发和维护的方法不正确有关 —如何维护数量不断膨胀的软件产品。

消除软件危机的途径

• 对计算机软件有一个正确的认识，软件=程序+数据+文档资料

• 必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人 员协同配合、共同完成的工程项目。

• 推广使用在实践中总结出来的开发软件的成功技术和方法。

• 开发和使用更好的软件工具。

• 解决途径 — 软件工程 1）管理措施2） 技术措施

1.2软件工程

软件工程概念

软件工程:建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

软件工程:(1)把系统的、规范的、 可度量的方法应用于软件开发、运行和维护过程，即:将工程化应用于软件;(2)研究(1)中提到的方法。

软件工程:是应用计算机科学、数学(用于构造模型和算法)及管理科学(用于计划、资源、质量和成本等的管理)等原理开发软件的工程。它借鉴传统工程(用于制定规范、设计范型、评估成本、权衡结果)的原则、方法，以提高软件开发质量，降低成本为目的。

软件工程方法学

概念

把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学

软件工程方法学包含3个要素

• 过程 — 为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

• 方法 — 完成软件开发的各项任务的技术方法，回答“怎样做”的问 题。

• 工具 — 为运用方法而提供的自动的或半自动的软件工程支撑环境。

软件工程方法学分类

• 面向过程的方法学 –- 传统

• 面向对象的方法学 –- 现代

• 面向方面的方法学 –- 逐步

1.3软件生命周期

1.4软件过程

软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

瀑布模型

• 瀑布模型有许多优点:可强迫开发人员采用规范的方法(例如，结构化技术); 严格地规定了每个阶段必须提交的文档;要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。瀑布模型的成功在很大程度 上是由于它基本上是一种文档驱动的模型。

• “瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行;用户常常难以清楚地给出所有需求;用户必须有耐心，等到系统开发完成;开发者常常被不必要地耽搁。

快速原型模型

• 适用于用户驱动的系统(即需求模糊或随时间变化的系统)。

• 优点:

–从实践中学习(Learning by doing)

–改善通信

–改善用户参与

–使部分已知需求清晰化

–展示描述的一致性和完整性

–提高系统的实用性、可维护性

–节省开发的投入、缩短整个软件的开发周期

• 原型模型的缺点

–用户有时误解了原型的角色，例如他们可能误解原型应该和真实系统一样可靠。

–缺少项目标准，进化原型方法有点像编码修正。

–缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制。

–额外的花费:研究结果表明构造一个原型可能需要10%额外花费。

–为了尽快实现原型，采用了不合适的技术，运行效率可能会受影响。

–原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。

增量模型

先完成一个系统子集的开发，再按同样的开发步骤增加功能 (系统子集),如此递增下去直至满足全部系统需求。

特点

• 融合了线性顺序模型的基本成分和原型实现的迭代特征;

• 以功能递增的方式进行软件开发;

• 在每一步递增中，均发布一个新的增量，把用户/开发者的经验结合到不断求精的产品中;

• 每个增量的开发没有必要使用相同的过程;

• 可改善测试效果和降低软件开发总成本。

• 增量过程模型与原型实现模型，本质上都是迭代的。

• 两者区别在:增量模型强调每一个增量发布一个可操作的产品。早期的增量提供了为用户服务的功能和给用户评价的平台。

增量模型存在的问题

• 增量应该相对较小，每个增量应该包含一 定的系统功能。所以，很难把用户的需求映射到适当规模的增量上。

• 大多数系统需要一组在系统许多部分都会用到的基本服务。但由于增量实现前需求不能被详细定义，所以，明确所有增量都会用到的基本服务就比较困难。

增量模型的优点

1. 在较短时间内向用户提交可完成部分工作的产 品，并分批、逐步地向用户提交产品。从第一个部件交付之日起，用户就能做一些有用的工 作。
2. 整个软件产品被分解成许多个增量部件，开发 人员可以一个部件一个部件地逐步开发。
3. 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
4. 采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报

使用增量模型的困难

1. 在把每个新的增量部件集成到现有软件体系结构中时，必须不破坏原来已 经开发出的产品。此外，必须把软件 的体系结构设计得便于按这种方式进 行扩充，向现有产品中加入新构件的 过程必须简单、方便，也就是说，软 件体系结构必须是开放的。
2. 开发人员既要把软件系统看作整体。 又要看成可独立的部件，相互矛盾。
3. 多个部件并行开发，具有无法集成的 风险。

螺旋模型

可看作在每个快速原型阶段之前都增加了风险分析过程的快速原型模型。

• 对于大型软件系统的开发，螺旋模型是一 个很现实的方法，主要适用于内部开发的大规模软件项目。

• 优势:随着迭代的增加(成本的增加)， 风险程度随之降低

• 缺陷:比较复杂，需要相当的风险评估技术，且成功依赖于这种技术。要有具有丰富风险评估专门知识的开发人员，否则风 险更大。

敏捷过程与极限编程

极限编程 (extreme Programming,简称XP)

特点

以极限编程为杰出代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特征，而且在快速的同时仍然能够保持可持续的开发速度。

2可行性研究

2.1可行性研究的任务

可行性研究的内容

(1) 技术可行性

(2) 经济可行性

(3) 操作可行性：用户使用可能性、 时间进度可行性、组织和文化上的可行性

(4) 社会可行性(法律可行性)

2.2系统流程图

2.3数据流图

DFD-Date Flow Diagram

分层 DFD 图的优点

. 便于实现— 采用逐步细化的扩展方法，可避免一次引入过多的细节，有利于控制问题的复杂度;

. 便于使用— 用一组图代替一张总图，方便用户及软件开发人员阅读。

2.3数据字典

DD(Data Dictionary)

数据字典的任务是: 对于数据流图中出现的所 有被命名的图形元素在字典中作为一个词条加 以定义，使得每一个图形元素的名字都有一个 确切的解释。

数据流词条的描述

数据流名

说明:简要介绍作用，即它产生的原因和结果。

数据流来源:即该数据流来自何方。

数据流去向:去向何处。

数据流组成:数据结构。

每个数据量流通量:数据量、流通量。

例子

数据流名:发票

说明:用作学生已付书款的依据

数据流来源:来自加工“审查并开发票”

数据流去向:流向加工“开领书单”。

数据流组成:学号+姓名+书号+单价总价+书费合计

加工逻辑词条的描述

格式

加工名

加工编号:反映该加工的层次

简要描述:加工逻辑及功能简述

输入数据流:

取值范围: 相关的数据元素及数据结构

加工逻辑说明

2.5成本效益分析

成本估计技术

1. 代码行技术
2. 任务分解技术
3. 自动估计成本技术

3需求分析

3.1 需求分析的任务

1 确定对系统的综合要求

–-功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、 逆向需求、将来可能提出的要求。

2 分析系统的数据要求

3 导出系统的逻辑模型

4 修正系统开发计划

3.2 与用户沟通获取需求的方法

访谈

• 正式的访谈

— 系统分析员将提出一些事先准备好的具体问题。

• 非正式的访谈

— 分析员将提出一些用户可以自由回答的开放性问 题，以鼓励被访问人员说出自己的想法。

• 当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。

• 在访问用户的过程中使用情景分析技术往往非常有效。

情景分析

所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。

情景分析技术的用处主要体现在下述两个方面:

(1) 它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员 目前还不知道的需求。

(2) 由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求， 而这一信息的惟一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要 的。

快速建立软件原型

• 快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。

• 快速建立软件原型是最准确、最有效、 最强大的需求分析技术。

• 快速原型应具备的特性是“快速”、 “容易修改”。

3.3 分析建模与规格说明

分析建模

需求分析过程应该建立3种模型:

数据模型 ---- 实体-联系图

功能模型 ---- 数据流图

行为模型 ----状态转换图

软件需求规格说明

软件需求规格说明(SRS)

Software Requirement Specification

通常用自然语言+模型，完整、准确、具体地描述系统的数据要求、功能需求、 性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求 以及将来可能提出的要求。

软件需求说明书的编写提示

1 引言

1.1 编写目的

1.2 背景

1.3 定义

1.4 参考资料

2 任务概述

2.1 目标

2.2 用户的特点

2.3 假定和约束

3 需求规定

3.1 对功能的规定

3.2 对性能的规定

3.2.1 精度

3.2.2 时间特性要求

3.2.3 灵活性

3.3 输人输出要求

3.4 数据管理能力要求

3.5 故障处理要求

3.6 其他专门要求

4 运行环境规定

4.1 设备

4.2 支持软件

4.3 接口

4.4 控制

3.4 实体-联系图(ER)

Entity Relationship Diagram

• ER图 ---- 是用来建立数据模型的工具。

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

• 数据模型中包含3种相互关联的信息:数据对象 (实体)、数据对象的属性及数据对象彼此间相互连接的关系。

3.5 数据规范化

规范化的目的

• 消除数据冗余，即消除表格中数据的重复;

• 消除多义性，使关系中的属性含义清楚、单一;

• 使关系的“概念”单一化，让每个数据项只是一个简单的数或字符串，而不是一个组项或重复组;

• 方便操作。使数据的插入、删除与修改操作可行并方便;

• 使关系模式更灵活，易于实现接近自然语言的查询

范式

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

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

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

3、范式级别提高则需要访问的表增多，因此性能(速度) 将下降。从实用角度看来，在大多数场合选用第三范式都比较恰当。

3.6 状态转换图

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

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

事件就是引起系统做动作或 (和)转换状态的控制信息。

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

符号

• 初态用实心圆表示，终态用一对同心圆(内圆为 实心圆)表示。

• 中间状态用圆角矩形表示，可以用两条水平横 线把它分成上、中、下3个部分。上面部分为状 态的名称，这部分是必须有的;中间部分为状态变量的名字和值，这部分是可选的;下面部分是活动表，这部分也是可选的。

3.7 其他图形工具

• IPO图

input processing output

4总体设计

4.1 设计过程

• 总体设计过程通常由两个主要阶段组成:

– 系统设计阶段，确定系统的具体实现方案;

– 结构设计阶段，确定软件结构。

4.2 设计原理

4.2.1 模块化

模块是由边界元素限定的相邻程序元素(例如， 数据说明，可执行的语句)的序列，而且有一个总体标识符代表它。

– 如:过程、函数、子程序、宏、对象等，都可作为模块。

模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。

4.2.2 抽象

人类在认识复杂现象的过程中使用的最强有力的思维工具是 抽象 – 就是抽出事物的本质特性(共性)，而暂时不考虑它们的细节。

软件工程过程的每一步都是对软件解法的抽象层次的一次精化。

4.2.3 逐步求精

逐步求精定义为:“为了能集中精力解决主要问题而尽量推迟对 问题细节的考虑。”

• 抽象与求精是一对互补的概念。

• 抽象使得设计者能够说明过程和数据，同时却忽略低层细节。事实上，可以把抽象看作是一种通过忽略多余的细节同时强调有关的细节，而实现逐步求精的方法。

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

• 这两个概念都有助于设计者在设计演化过程 中创造出完整的设计模型。

4.2.4 模块独立

模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他模块的接口是简单的。

模块的独立程度可以由两个定性标准度量

耦合

模块之间的相对独立性的度量

耦合性是程序结构中各个模块之间相互关联的度量它取决于各个模块之间接口的复杂程度、调用模块的方式以及哪些信息通过接口。

内聚

一个模块内部元素在功能上相互关联的强度

耦合、内聚与模块独立性关系

耦合与内聚都是模块独立性的定性标准，都反映模块独立性的良好程度。但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。

4.3 改进设计的启发规则

1. 改进软件结构提高模块独立性。
2. 模块规模应该适中(30-60行语句)。
3. 深度、宽度、扇出和扇入都应适当。
4. 模块的作用域应该在控制域之内。
5. 力争降低模块接口的复杂程度。
6. 设计单入口单出口的模块。
7. 模块功能应该可以预测。

4.4结构图

SC – Structure Chart

结构图反映程序中模块之间的层次调用关系和联系:它以特定的符号表示模块、模块间的调用关系和模块间信息的传递。

在模块A的箭头尾部标以一个菱形符号，表示模块A有条件地调用另一个模块B。当 一个在调用箭头尾部标以一个弧形符号， 表示模块A反复调用模块C和模块D

4.5 面向数据流的设计方法

— 结构化设计(SD - Structured Design)

• 面向数据流的设计方法的目标是给出设计软件结构的一个系统化的途径。

• 面向数据流的设计要解决的任务，就是在需求分析的基础上，将表示系统逻辑模型的DFD图映射 (Mapping)成软件系统结构的初始设计描述。

分类

变换分析DFD->SC

5详细设计

详细设计的目的: 为软件结构图 (SC) 中的每一个模块确定采用的算法和模块内数据结构，用某种选定的表达工具给出清晰的描述。

5.1 结构程序设计

结构程序设计的经典定义如下所述:“如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。”

3种基本的控制结构

顺序、选择、循环

5.2 人机界面设计

设计人机界面中的4个问题

1)系统响应时间

两个重要属性，分别是长度和易变性。

2)用户帮助设施

常见的帮助设施可分为集成的和附加的两类

3)出错信息处理

4)命令交互

人机界面设计指南

1)一般交互指南

一般交互指南涉及信息显示、数据输入和系统整体控制，因此，这类指南是全局性的，忽略它们将承担较大风险。

(1) 保持一致性。

应该为人机界面中的菜单选择、命令输入、数据显示以及众多的其他功能，使用一致的格式。

(2) 提供有意义的反馈。

应向用户提供视觉的和听觉的反馈，以保证在用户和系统之间建立双向通信

(3) 在执行有较大破坏性的动作之前要求用户确认。

如果用户删除一个文件，或覆盖一些重要信息，或终止一个程序的运行，应 该给出“您是否确实要…”的信息，以请求用户确认他的命令。

(4) 允许取消绝大多数操作。

UNDO或REVERSE功能曾经使众多终端用户避免了大量时间浪费。每个交互 式系统都应该能方便地取消已完成的操作。

(5) 减少在两次操作之间必须记忆的信息量。

不应该期望用户能记住在下一步操作中需使用的一大串数字或标识符。应该

尽量减少记忆量。

(6) 提高对话、移动和思考的效率。

应该尽量减少用户击键的次数，设计屏幕布局时应该考虑尽量减少鼠标移动 的距离，应该尽量避免出现用户问“这是什么意思?”的情况。

(7) 允许犯错误。系统应该能保护自己不受严重错误的破坏。

(8) 按功能对动作分类，并据此设计屏幕布局。

下拉菜单的一个主要优点就是能按动作类型组织命令。实际上，设计者应该尽力提高命令和动作组织的“内聚性”。

(9) 提供对用户工作内容敏感的帮助设施。

(10) 用简单动词或动词短语作为命令名。

过长的命令名难于识别和记忆，也会占用过多的菜单空间。

2) 信息显示指南

如果人机界面显示的信息是不完整的、含糊的或难于理解的，则该应用系统显然不能满足用户的需求。可以用多种不同方式“显示”信息:用文字、图形和声音;按位置、移动和大小;使用颜色、分辨率和省略。

(1) 只显示与当前工作内容有关的信息。

用户在获得有关系统的特定功能的信息时，不必看到与之无关的数据、菜单和图形。

(2) 不要用数据淹没用户，应该用便于用户迅速吸取信息的 方式来表示数据。 例如，可以用图形或图表来取代庞大的表格。

(3) 使用一致的标记、标准的缩写和可预知的颜色。

显示的含义应该非常明确，用户无须参照其他信息源就能理解。

(4) 允许用户保持可视化的语境。

如果对所显示的图形进行缩放，原始的图像应该一直显示着(以缩小的形式 放在显示屏的一角)，以使用户知道当前看到的图像部分在原图中所处的相 对位置。

(5) 产生有意义的出错信息。

(6) 使用大小写、缩进和文本分组以帮助理解。

人机界面显示的信息大部分是文字，文字的布局和形式对用户从中提取信息的难易程度有很大影响。

(7) 使用窗口分隔不同类型的信息。

利用窗口用户能够方便地“保存”多种不同类型的信息。

(8) 使用“模拟”显示方式表示信息，以使信息更容易被用户提取。

(9) 高效率地使用显示屏。当使用多窗口时，应该有足够的空间使 得每个窗口至少都能显示出一部分。此外，屏幕大小应该选得 和应用系统的类型相配套(这实际上是一个系统工程问题)。

3)数据输入指南

用户的大部分时间用在选择命令、键入数据和向系统提供输入。在许多应用系统中，键盘仍然是主要的输入介质，但是，鼠标、数字化仪和语音识别系统正迅速地成为重要的输入手段

(1) 尽量减少用户的输入动作。

最重要的是减少击键次数，这可以用下列方法实现:用鼠标从预定义的一组输入中选一个;用“滑动标尺”在给定的值域中指定输入值;利用宏把一次击键转变成更复杂的输入数据集合。

(2) 保持信息显示和数据输入之间的一致性。显示的视觉特征应该与输入域一致。

(3) 允许用户自定义输入。

专家级的用户可能希望定义自己专用的命令或略去某些类型的警告信息和动作确认，人机界面应该为用户提供这样做的机制。

(4) 交互应该是灵活的，并且可调整成用户最喜欢的输入方式。

用户类型与喜好的输入方式有关，例如，秘书可能非常喜欢键盘输入，而经理可能更喜欢使用鼠标之类的点击设备。

(5) 使在当前动作语境中不适用的命令不起作用。这可使得用户不去做那些肯定会导致错误的动作。

(6) 让用户控制交互流。

用户应该能够跳过不必要的动作，改变所需做的动作的顺序(在应用环境允 许的前提下)，以及在不退出程序的情况下从错误状态中恢复正常。

(7) 对所有输入动作都提供帮助。

(8) 消除冗余的输入。

除非可能发生误解，否则不要要求用户指定输入数据的单位;尽可能提供默认值;绝对不要要求用户提供程序可以自动获得或计算出来的信息。

5.3 详细设计的工具

程序流程图

主要优点

对控制流程的描绘很直观，便于初学者掌 握。由于程序流程图历史悠久，为最广泛的人所熟悉，尽 管它有种种缺点，许多人建议停止使用它，但至今仍在广 泛使用着。不过总的趋势是越来越多的人不再使用程序流 程图了。

主要缺点

(1) 程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。

(2) 程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制

(3) 程序流程图不易表示数据结构。

盒图(N-S图)

特点

(1) 功能域(即，一个特定控制结构的作用域)明确，可以从盒图上一眼就看出来。

(2) 不可能任意转移控制。

(3) 很容易确定局部和全程数据的作用域。

(4) 很容易表现嵌套关系，也可以表示模块的层次结构。

5.4 程序复杂程度的定量度量

定量度量程序复杂程度的价值

— 把程序的复杂程度乘以适当常数即可估算出软件中错误的数量以及软件开发需要用的工作量;

— 定量度量的结果可以用来比较两个不同的设计或两个不同算法的优劣;

— 程序的定量的复杂程度可以作为模块规模的精确限度。

MrcCabe度量法

McCabe度量法，又称环路复杂性度量，是一种基于程序控制流的复杂性度量方法

计算环形复杂度V(G)的方法

(1) 流图中的区域数等于环形复杂度

(2) 流图G的环形复杂度 V(G)=E – N+2其中，E是流图中边的条数，N是结点数

(3) 流图G的环形复杂度 V(G)=P+1其中，P是流图中判定结点的数目。

6编码与测试----实现

6.1软件测试基础

6.1.1软件测试的目标

(1) 预防错误: 为下次项目

(2) 发现错误:为本次项目

G.Myers 给出了关于测试的一些规则，这些规则也可以看作是测试的目标或定义。

(1) 测试是为了发现程序中的错误而执行程序的过程;

(2) 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案;

(3) 成功的测试是发现了至今为止尚未发现的错误的测试。

6.1.2测试方法

6.1.3测试步骤

1. 模块测试 — 单元
2. 子系统测试 — 局部
3. 系统测试 — 集成
4. 验收测试 — 用户参与
5. 平行运行 — 新旧共存

6.1.4测试阶段的信息流

测试阶段的信息流

软件测试的对象

软件测试并不等于程序测试。软件测试应贯 穿于软件定义与开发的整个期间。因此，需求分析、概要设计、详细设计以及程序编码 等所得到的文档资料，包括需求规格说明、 概要设计说明、详细设计规格说明以及源程 序，都应成为软件测试的对象。

6.2单元(模块)测试

6.2.1 测试重点 — 5个方面

1. 模块接口

主要检查下述几个方面:参数的数目、次序、属性或单位系统与变元是否一致;是否修改了只作输入用的变元;全局变量的定义和用法在各个模块中是否一致。

2. 局部数据结构

局部数据说明、初始化、默认值等方面的错误。

3. 重要的执行通路

选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的。应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误。

4. 出错处理通路

5. 边界条件

6.2.2代码审查

由审查小组,人工测试源程序称为代码审查。

6.3 集成测试

集成测试 是测试和组装软件的系统化 技术，其主要目标是发现与接口有关的问题。

集成测试有两种方法

1、非渐增式测试方法，即:先分别测试每个模块， 再把所有模块按设计要求放在一起结合成所要的程序 进行测试。

2、渐增式测试，即:先把下一个要测试的模块同已 经测试好的那些模块结合起来进行测试，测试完以后 再把下一个应该测试的模块结合进来测试。这种每次增加一个模块的方法实际上同时完成单元测试和集成测试，目前在进行集成测试时普遍采用渐增式测试方法。

渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略。但在实践中常采用混合的策略。

回归测试

• 任何成功的测试都会发现错误，而且错误必须被改正。每当 改正软件错误的时候，软件配置的某些成分(程序、文档或 数据)也被修改了。回归测试就是用于保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。

• 即:回归测试是指重新执行已经做过的测试的某个子集，以 保证修改变化没有带来非预期的副作用。

• 回归测试集(已执行过的测试用例的子集)包括下述3类不同的测试用例:

(1) 检测软件全部功能的代表性测试用例;

(2) 专门针对可能受修改影响的软件功能的附加测试;

(3) 针对被修改过的软件成分的测试。

6.4确认测试

6.4.1 确认测试的范围

• 确认测试必须有用户积极参与，或者以用户为主进行。

• 确认测试通常使用黑盒测试法。

• 通过测试和调试要保证软件能满足所有功能要求，能 达到每个性能要求，文档资料是准确而完整的，此外， 还应该保证软件能满足其他预定的要求。

6.4.2 软件配置复查

软件配置:软件需求规格说明、软件设计规格说明、源代码等

复查的目的是保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节，而且已经编好目录。

除了按合同规定的内容和要求，由人工审查软件配置 之外，在确认测试过程中还应该严格遵循用户指南及 其他操作程序，以便检验这些使用手册的完整性和正 确性。必须仔细记录发现的遗漏或错误，并且适当地 补充和改正。

6.4.3 Alpha和Beta测试

• Alpha测试由用户在开发者的场所进行，并且在开发 者对用户的“指导”下进行测试。开发者负责记录发 现的错误和使用中遇到的问题。该测试是在受控的环 境中进行的。

• Beta测试由软件的最终用户们在一个或多个客户场所 进行。Beta测试是软件在开发者不能控制的环境中的 “真实”应用。用户记录在Beta测试过程中遇到的一 切问题(真实的或想像的)，并且定期把这些问题报 告给开发者。接收到在Beta测试期间报告的问题之后， 开发者对软件产品进行必要的修改，并准备向全体客 户发布最终的软件产品。

6.5白盒测试技术

6.5.1 逻辑覆盖

逻辑覆盖 ---- 是以程序内部的逻辑结构为基 础的设计测试用例的技术。

(1) 语句覆盖

(2)判定覆盖

(3)条件覆盖

(4)判定/条件覆盖

(5)条件组合覆盖

(6)点覆盖:如果连通图G 的子图G′是连通的，而且包含G的所有结点， 则称G′是G的点覆盖。

(7)边覆盖:如果连通图G的子图 G′′是连通的，而且包含G的所有边，则称G′′是 G的边覆盖。

(8)路径覆盖:选取足够多测试数据，使程序的每条可能路径都至少执行一次(如果程序图中

有环，则要求每个环至少经过一次)。

6.5.2 控制结构测试

1. 基本路径测试
2. 条件测试
3. 循环测试

6.6黑盒测试技术

• 黑盒测试着重测试软件功能。黑盒测试并不能取代 白盒测试，它是与白盒测试互补的测试方法，它很 可能发现白盒测试不易发现的其他类型的错误。

• 黑盒测试力图发现下述类型的错误: 1功能不正确或遗漏了功能; 2界面错误; 3数据结构错误或外 部数据库访问错误; 4性能错误; 5初始化和终止 错误。

• 黑盒测试技术:等价划分法、边界值分析法、错误推测法、因果图法等。

6.6.1 等价类划分法(等价分配)

把所有可能的输入数据(有效的和无效 的)划分成若干个等价的子集(称为等价类别或等价区间)， 使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同.

划分等价类的规则

(1)如果输入条件规定了取值范围，可定义一个有 效等价类和两个无效等价类。

(2)如果输入条件代表集合的某个元素，则可定义 一个有效等价类和一个无效等价类。

(3)如规定了输入数据的一组值，且程序对不同输 入值做不同处理，则每个允许的输入值是一个 有效等价类，并有一个无效等价类(所有不允许的输入值的集合)。

(4)如果规定了输入数据必须遵循的规则，可确定 一个有效等价类(符合规则)和若干个无效等 价类(从不同角度违反规则)。

(5)如已划分的等价类各元素在程序中的处理方式 不同，则应将此等价类进一步划分成更小的等 价类。

用等价类划分法设计测试用例步骤

(1)形成等价类表，每一等价类规定一个唯一的编号;

(2)设计一测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一 步骤，直到所有有效等价类均被测试 用例所覆盖;

(3)设计一新测试用例，使其只覆盖一个 无效等价类，重复这一步骤直到所有 无效等价类均被覆盖;