软件工程课程复习

整理目的：

1. 我还是认为基础知识不能丢，也是对以前知识的回顾。
2. 考研软件工程方向考软件工程这门学科的并不多，我选择了两所学校来进行整理。

以中南大学944软件工程考试大纲和复旦961软件工程专业基础综合考试大纲为基础。

零、前言

0.1 考试性质

《软件工程》考试是为高等院校和科研院所招收硕士研究生而设置的具有选拔性质的全国统一入学考试科目，其目的是科学、公平、有效地测试学生掌握大学本科阶段软件工程课程的基本概念、原理、方法与技术，以及分析和解决问题的能力，评价的标准是高等学校本科毕业生能达到的及格以上水平，以保证被录取者具有基本的软件工程专业素质，并有利于各高等院校和科研院所在专业上择优选拔。

0.2 考察目标

掌握：软件工程的产生、软件工程学的研究对象与原则、软件开发方法、软件工程的生存周期模型以及软件工程发展的新方向；软件需求分析的任务和要求、可行性研究的任务以及系统建模方法；软件开发阶段的仼务、过程、方法和技术。
理解：软件质量的概念、分析技术；软件维护阶段的活动、提高软件可维护性的策略；软件工程的相关管理技术。

一、软件工程与软件过程

边际成本，1968年NATO首次提出。

软件工程是用工程，科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法，它由方法、工具和过程三部分组成。

1.1 软件工程的产生

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

产生软件危机的原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。

要缓解软件危机，既要有先进的技术和方法，又需要高水平的组织管理措施。而软件工程正是综合了管理和技术两方面，研究如何更好地开发软件的一门新兴学科。所以，就目前而言，软件工程是缓解软件危机的最好途径。

软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

1.2 软件工程的研究对象与基本原理

1.3 软件开发方法

1.4 软件工程工具和环境

• 软件工程环境

  方法与工具的结合，加上配套的软、硬件支持称为软件工程环境。它能支持开发者按照软件工程的方法,全面完成生存周期中的各项任务。

• 软件工具是什么？按照软件生存周期可将其分为几类？

  软件工具是指为支持计算机软件及其文档的开发、维护、模拟、移植或管理而研制的程序系统。按照软件生存周期可将其分为如下几类：

  • 需求分析：如数据流图绘制与分析工具、状态转换图绘制与分析工具、面向对象的模型和分析工具、快速原型构造工具、数据字典与数据库工具等。
  • 软件设计：如HIPO图、PDL(程序设计语言)或PAD(问题分析图)支持工具等。
  • 编码：集成化的程序员工作平台。如各种正文编辑器和常规的编译程序、汇编程序、连结程序及符号调试器等。
  • 软件测试：如静态分析器、动态覆盖率测试器、测试用例生成器、测试报告生成器及环境模拟器等。
  • 软件维护：如反汇编程序、反编译程序、程序结构分析器、源程序格式化工具、文档生成工具、源程序至PAD(问题分析图)或流程图的自动转换工具等。

• 软件工程的基本原理

  • 用分阶段的生命周期计划严格管理
  • 坚持进行阶段评审
  • 实行严格的产品控制
  • 采用现代程序设计技术
  • 结果应能清楚地审查
  • 开发小组应该少而精
  • 承认不断改进软件工程实践的必要性

1.5 软件生存期过程

三个时期八个阶段

软件生命期瀑布模型分为六个阶段：

• 可行性研究与计划（确定系统的目标和规模，分析项目的可行性）；

• 需求分析与规格说明（明确系统的规格和要求）

• 设计（包括概要设计和详细设计，将系统分解为模块）
• 编程（用程序语言实现每个模块，简单容易）；
• 测试（发现并改正错误，分为模块测试、集成测试和系统联调三级）；
• 运行维护（扩充功能、纠错等）。

WBS work breakdown structure 工作分解结构

软件生命周期由软件定义、软件开发和运行维护（也成软件维护）3个时期组成。

1.6 软件工程常用生存周期模型

软件生存周期模型是描述软件开发过程中各种活动如何执行的模型。

八种经典软件过程模型的特点（瀑布模型、增量和迭代模型、演化模型、统一过程模型、V模型、原型模型、操作规范、转换模型、螺旋模型、敏捷模型）

V-V原则：validation（核实）：确保系统实现了所有的需求。 verification（验收）：确保每个功能正确运行。

1.6.1 瀑布模型

• 传统瀑布模型特点

  • 阶段间具有顺序性与依赖性
  • 推迟实现的观点
  • 质量保证的观点

• 瀑布模型

  • 优点
    • 可强迫开发人员使用规范的方法（例如：结构化技术）；
    • 严格规定每个阶段必须提交的文档；
    • 要求每个阶段交出的所有产品都必须通过验证。
  • ·缺点
    • “瀑布模型是由文档驱动的”成为主要缺点
  • 适用范围
    • 适合于用户需求明确、完整、无重大变化的软件项目开发。

1.6.2 增量和迭代模型

• 特点

  • 反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个“增量”的发布或提交，该增量均是一个可运行的产品。
  • 早期的版本实现用户的基本需求，并提供给用户评估的平台。

• 优点

  • 在较短时间内向用户提交可完成部分工作的产品；
  • 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击；

• 缺点

  • 软件体系结构必须是开放的；
  • 开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾；
  • 多个构件并行开发，具有无法集成的风险。

1.6.3 演化模型

1.6.4 （Rational）统一过程模型

RUP重复一系列周期，每个周期由一个交付给用户的产品结束。每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个核心工作流（需求、分析、设计、实现、测试）分别迭代。

1.6.5 V模型

1.6.6 （快速）原型模型

• 适用范围
  • 用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等情况。

1.6.7 操作规范

1.6.8 转换模型

1.6.9 螺旋模型

• 基本思想

  • 使用原型或其他方法来降低风险。

• 适用范围

  • 适用于内部开发大规模软件项目。

• 优点

  • 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件发的一个重要目标
  • 减少了过多测试或测试不足
  • 维护和开发之间并没有本质区别

• 缺点

  • 风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大
  • 随着迭代次数的增加，工作量加大，软件开发成本增加

1.6.10 敏捷模型

1.6.11 喷泉模型

• 特点
  • 喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性

1.7 软件过程的概念

1.8 过程评估与CMM/CMMI的基本概念

1.9 敏捷宣言与敏捷过程的特点

二、需求分析

需求分析中应该建立哪三种模型：数据模型、功能模型、行为模型

2.1 软件需求的概念

四种类型的需求（用两种文档表示）：1：功能需求 2：质量（性能需求） 3：设计约束 4：过程约束

• 两种描述需求的文档

  • 需求定义：客户想要实现的所有内容的完整列表。

  • 需求规格说明书 设计建模UML：要求重新表述为所提出的系统应如何表现的规范

• RTM 需求跟踪矩阵

  • 系统怎么做什么的订需求定义
  • 根据需求生成的设计模块
  • 实现设计的程序代码
  • 验证系统功能的测试
  • 描述系统的文档

• 从哪些方面验证软件需求的正确性

  • 一致性，即所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
  • 完整性，需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
  • 现实性，指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
  • 有效性，必须证明需求是正确有效的，确实能解决用户面对的问题。

2.2 需求工程的基本过程

需求工程过程包括如下主要活动：获取需求、需求分析与建模、需求规格说明、确认需求、需求管理。

2.3 需求分析的目标

需求分析阶段的基本任务是要准确的定义新系统的目标，为了满足用户需要，回答系统必须“做什么”的问题。

本阶段要进行以下几方面的工作：问题识别、分析与综合，导出软件的逻辑模型、编写文档

• 基本任务
  • 问题识别：双方确定对问题的综合需求，这些需求包括功能需求，性能需求，环境需求，用户界面需求。
  • 分析与综合，导出软件的逻辑模型
  • 编写文档：包括编写”需求规格说明书”,”初步用户使用手册”,”确认测试计划”,”修改完善软件开发计划”

2.4 可行性分析

了解可行性研究中的任务和过程

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

• 过程

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

• 可行性研究目的

  • 确定在问题定义中所提出的问题是否值得去解，在限制条件下，问题能否解决。

• 可行性研究的任务

  • 进一步分析和澄清问题的定义，在澄清问题的基础上，导出系统的逻辑模型；
  • 从系统逻辑模型中，选择问题的若干种主要解法，研究每一种解法的可行性，为以后的行动提出建议；
  • 如果问题没有可行的解，建议停止系统开发；如果问题有可行的解，应该推荐一个较好的解决方案，并为工程制定一个初步的计划。

• 可行性研究包括哪几方面的内容

  • 技术可行性：现有技术能否实现本系统，现有技术人员能否胜任，开发系统的资源能否满足；
  • 经济可行性：经济效益是否超出开发成本；
  • 操作可行性：系统操作在用户内部行得通吗？
  • 法律可行性：新系统开发是否会侵犯他人、集体或国家利益，是否违反国家法律。

• 可行性研究的步骤

  • 复查系统的规模和目标；
  • 研究目前正在使用的系统，总结现有系统的优劣，提出新系统的雏形；
  • 导出新系统的高层逻辑模型；
  • 推荐建议方案；
  • 推荐行动方针；
  • 书写计划任务书(可行性报告)；
  • 提交审查。

• 可行性研究报告的主要内容

  可行性分析的结果是可行性研究报告，内容包括

  • 系统概述：说明开发的系统名称,提出单位和开发单位。
  • 可行性研究的前提:系统目标；要求；约束和限制；可行性研究的基本准则等。
  • 对现有系统的分析:处理流程，图示说明现有系统的处理流程和数据流程；现有系统存在的问题。
  • 系统需求:主要功能；主要性能及其要求；操作要求；信息要求；限制性要求。
  • 建议系统:系统目标；处理流程；系统结构,功能,性能；系统技术可行性；投资和效益分析；操作可行性；法律可行性。
  • 其它可选方案:与国内外同类型方案的比较；提出一两个可行性方案供论证和探讨。
  • 制定下一阶段的预算。
  • 结论性意见：由用户方、设计方和投资方共同签署意见。

2.5 需求收集

2.6 需求规格说明

• 简述软件需求说明书（软件规格说明书）中包含的内容

  • 软件系统的开发背景资料（主要相关人、财、物或设备）；
  • 所开发软件的功能、性能、用户界面及运行环境等作出详细的说明；
  • 软件系统详细的逻辑模型：数据流图(DFD)+数据词典（DD）或面向对象的三大模型（对象模型、动态模型和功能模型）等
  • 系统开发计划表
  • 所有附加文档：调查问卷信息、BPFD等

• 软件需求规格说明书由哪些部分组成，组成包括

  • 引言：编写目的、背景说明、术语定义及参考资料等。
  • 概述主要功能、约束条件或特殊需求。
  • 数据流图与数据字典。
  • 用户接口、硬件接口及软件接口。
  • 性能需求、属性等。
  • 其它需求，如数据库、操作及故障处理等。

2.7 数据流建模

（分层数据流模型）

2.8 实体一关系建模

用例和场景建模及其UML表达（用例图、活动图、泳道图、顺序图）

2.9 系统行为建模

（数据模型建模及其UML表达（类图））（行为模型建模及其UML表达（状态机图））

2.10 IDEF0功能建模

2.11 IDEF1x数据建模

三、软件设计

3.1 软件体系结构及体系结构风格的概念

软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、元素间的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。良好的体系结构是普遍适用的，它可以高效地处理各种各样的个体需求。

软件架构也有通用的解决方案，叫做体系结构风格

体系结构风格提供有关如何将问题分解为软件单元以及这些单元应如何相互交互的建议

使用体系结构风格的六种方法：

• 去理解系统：他能做什么和怎么做
• 去判断多少系统可以去复用先前就建立好的系统，多少系统在以后将不能复用。
• 提供构建系统的蓝图，提供构建系统的蓝图，包括系统的“承载”部分可能在哪里
• 推断系统如何发展，包括表现，成本，原型设计
• 去分析依赖，选择最合适的设计，实现，和测试技术
• 支持管理厥词，理解实施和维护中固有的风险

3.2 设计模式的概念

3.3 模块化设计的基本思想及概念

（抽象、分解、模块化、封装、信息隐藏、功能独立）

• 什么是模块？模块具有哪几个特征？总体设计主要考虑什么特征？

  • 模块是数据说明、可执行语句等程序对象的集合，可以单独命名且可通过名字来访问。
  • 模块具有输入和输出(参数传递)、功能、内部数据结构(局部变量)和程序代码四个特性。
  • 概要设计主要考虑输入、输出(参数传递)和功能两个特性。

• 什么是模块化

  • 模块化是按规定的原则将一个大型软件划分为一个个较小的、相对独立但又相关的模块。

• 模块设计的准则

  • 改进软件结构, 提高模块独立性:在对初步模块进行合并、分解和移动的分析、精化过程中力求提高模块的内聚，降低藕合。
  • 模块大小要适中:大约50行语句的代码，过大的模块应分解以提高理解性和可维护性;过小的模块,合并到上级模块中。
  • 软件结构图的深度、宽度、扇入和扇出要适当。一般模块的调用个数不要超过5个。
  • 尽量降低模块接口的复杂程度；
  • 设计单入口、单出口的模块。
  • 模块的作用域应在控制域之内。

3.4 软件重构的概念

3.5 软件体系结构的UML建模

软件开发的过程犹如雕琢一件工艺品，由无形到有形，由粗到细。鉴于软件系统的复杂性和规模的不断增大，项目失败的可能性也相应增加。需要建立不同的模型对系统的各个层次进行描述。在长期的研究与实践中，人们越来越深刻地认识到，建立简明准确的表示模型是把握复杂系统的关键。模型是对事物的一种抽象，在软件开发过程中，建立各种模型，以便更透彻地了解系统的本质。由于UML以图形模型为主，模型的直观性及丰富的信息描述便于开发人员与用户的交流。建立的模型也为以后的系统维护和升级提供了文档。总的来说，使用模型可以使人们从全局上把握系统的全貌及其相关部件之间的关系，可以防止过早地陷入各个模块的细节。因此，面向对象的分析与设计应该从建模开始。UML 是一种标准的图形化、可视化的建模型语言，UML的核心是建立系统的各类模型。

3.5.1 包图

3.5.2 类图

3.5.3 构件图

3.5.4 活动图（Activity Diagram）

是由状态图变化而来的，从系统任务的观点来看，系统的执行过程是由一系列有序活动组成的。活动图可以有效地描述整个系统的流程，描述了系统的全局的动态行为，且只有活动图是唯一能够描述并发活动的UML图

3.5.4 顺序图（Sequence Diagram）

清晰地描述一组对象之间动态的交互关系、时间的约束关系，着重描述对象间消息传递的时间顺序，所以顺序图在实时系统中被大量使用。当参与交互的对象数目增加，交互关系复杂时用顺序图描述会显得杂乱。

3.5.5 协作图（Collaboration Diagram）

从另一个角度来更好地描述相互协作的对象间的交互关系和链接（Link）关系。着重体现交互对象间的静态链接关系和协作关系。协作图也可以从顺序图生成

3.5.6 部署图

3.5.7 状态图（State Diagram）

用来描述一个特定对象在其生存周期或在某段时间内的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的改变。例如订单的状态变化等，在实时系统中用得较多，还可以用于辅助设计用户界面。

3.6 接口的概念

3.7 面向对象设计原则

（开闭原则、Liskov替换原则、依赖转置原则、接口隔离原则）

3.8 内聚与耦合的概念、常见的内聚和耦合类型

耦合包含了哪些类型？每个类型的具体内容是什么？要求能通过程序代码识别出耦合类型。

• 非直接耦合：就是没有耦合。
• 数据耦合：就是参数传递耦合，它属于低级别耦合。
• 标记耦合：标记耦合指两个模块之间传递的是数据结构。
• 控制耦合：它属于中级别耦合，比如调度程序与进程之间的耦合，就是控制耦合。
• 外部耦合：属于高级别耦合
• 公共耦合：指通过一个公共数据环境相互作用的那些模块间的耦合。
• 内容耦合：属于最高级别耦合，例如，一个模块利用分支或跳转技术，转入到另一个模块中去执行，就是内容耦合。

3.9 软件设计的任务和过程

• 系统设计包括哪两个阶段

  • 系统设计包括总体设计与详细设计两个阶段

• 总体设计的主要任务是什么

  • 总体设计的主要任务是完成软件结构的设计，确定系统的模块及其模块之间的关系。

• 详细设计的目的

  • 为软件结构图（SC图或HC图）中的每一个模块确定采用的算法和块内数据结构，用某种选定的表达工具给出清晰的描述。

• 详细设计的主要任务

  编写软件的“详细设计说明书”。软件人员要完成的工作：

  • 为每一个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程描述
  • 确定每一模块使用的数据结构
  • 确定模块结构的细节，包括对系统外部的接口和用户界面，对系统内部其它模块的接口，以及关于模块输入数据、输出数据及局部数据的全部细节
  • 为每一个模块设计出一组测试用例，以便在编码阶段对模块代码（即程序）进行预定的测试。

• 概要设计（结构设计）

  • 把一个软件需求转换为软件表示时，首先设计出软件总的体系结构。
  • 基本任务
    • 设计软件系统结构
    • 进行数据结构及数据库的设计
    • 编写概要设计的文档
    • 评审

• 详细设计

  为SC图中的每个模块确定采用的算法和块内数据结构，用选定的表达工具（流程图、N-S图、PAD图、伪代码）给出清晰的描述。

  • 基本任务
    • 为每个模块进行详细的算法设计
    • 为模块内的数据结构进行设计
    • 对数据库进行物理设计
    • 其他设计
    • 编写详细设计说明书
    • 评审

3.10 软件设计基本原则

设计原则定义：将我们的系统需要的功能和行为分解为模块的指南（设计原理？）

六个主导原则：

• 模块化：耦合和类聚 我们说两个模块紧耦合，当他们彼此依赖很多。低耦合模块有一些依赖，但是他们的关联很微弱。解耦模块没有耦合
  • 内聚：cohesion ： 去测量多个模块的相互依赖程度，内聚指来自模块内部的依赖。最糟糕的情况，巧合：一个模块和另一个没有关系
  • 内聚种类：巧合内聚，逻辑类聚，时间类聚，过程类聚，通信类聚，功能类聚，信息类据。
  • 耦合是影响软件复杂程度的一个重要因素。设计时力争做到高内聚，并且能够辨认出低内聚的模块，有能力通过修改设计提高模块的内聚程度并且降低模块间的耦合程度，从而获得较高的模块独立性。
• 接口 定义了软件单元给剩余的系统提供什么服务，其他单元如何访问那些服务。
• 信息隐藏（和局部化？） 使得软件系统更易于维护 它以分解系统的指导来区分：每个软件单元都包含了一个可以在未来改变的分离设计决策
• 增量开发
• 抽象 是一种模型或者表示，忽略一些细节从而可以专注其他细节。
• 泛化 使技术通用 泛化是一个设计原则，使得软件单元尽可能普遍接受，增加在未来别的系统复用的可能性

3.11 面向数据流图的设计方法

掌握面向数据流的设计方法，了解其中涉及到的概念（变换流，事务流），结合例子理解变换分析的具体过程。

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

• 变换流

• 事务流

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

事务流：以事务为中心，事务型数据流图中存在一个事务中心（也就是数据处理、加工中心），它将输入分离成若干个发散的数据流，形成许多活动路径，并根据输入值选择其中一条路径，这类数据流就是事务流。

3.12 面向对象的设计方法

• 三种编程范型的特点

  • 过程式编程范型：把程序理解为一组被动的数据和一组能动的过程所构成；程序=数据结构+算法；着眼于程序的过程和基本控制结构，粒度最小
  • 面向对象编程范型：数据及其操作被封装在对象中；程序=对象+消息；着眼于程序中的对象，粒度比较大
  • 基于构件技术的编程范型：构件是通用的、可复用的对象类；程序=构件+架构；眼于适合整个领域的类对象，粒度最大

• 用面向对象方法开发软件时，通常需要建立哪三种形式的模型？

  • 描述系统数据结构的对象模型。
  • 描述系统控制结构的动态模型。
  • 描述系统功能的功能模型。

面向对象方法学的出发点和基本原则，是尽可能模拟人类思维方法，是开发软件尽可能接近人类认识世界解决问题的方法与过程。

对象模型表示静态的，结构化的系统的“数据”性质。它是对模拟客观世界实体的对象以及对象彼此之间的关系的映射，描述了系统的静态结构。

动态模型表示瞬时的、行为化的系统的”控制“性质，它规定了对象模型中的对象的合法序列。

功能模型表示变化的系统的”功能“性质，他指明了系统应该”做什么”，因此更直接反映了用户对目标系统的需求。

3.13 面向对象软件设计模式

3.14 模型-视图-控制器框架

四、软件验证技术（软件测试）

软件失败：软件不能做我们描述的需求。

4.1 软件测试基础（软件测试及测试用例的概念）

测试的目的是判断和发现软件是否有错误 , 调试的目的是定位软件错误并纠正错误。

软件测试是按照特定的规则，发现软件错误的过程；好的测试方案是尽可能发现迄今尚未发现错误的测试；成功的测试方案是发现迄今尚未发现错误的测试

• 软件测试的一般步骤

  ​ 单元测试、子系统测试、系统测试、验收测试、平行测试。

4.2 代码复审

4.3 白盒测试

根据程序内部逻辑结构进行测试，来检验程序内部动作是否按照规格说明书的规定正常进行

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

8个覆盖点：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、点覆盖、边覆盖、路径覆盖

白盒测试主要采用的技术有：路径测试技术和事务处理流程技术，对包含有大量逻辑判断或条件组合的程序采用基于逻辑的测试技术。

4.4 黑盒测试

根据程序外部特征来进行测试，着重测试软件功能，它并不能取代白盒测试，它是与白盒测试互补的测试方法

黑盒测试着重测试软件功能。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。

黑盒测试主要采用的技术有:等价分类法、边沿值分析法、错误推测法和因果图等技术。

黑盒测试力图发现下述类型的错误

• 功能不正确或遗漏了功能
• 界面错误
• 数据结构错误或外部访问数据库错误
• 性能错误
• 初始化和终止错误

4.5 单元测试

单元测试集中监测软件设计的最小单元—模块。

从这些方面对模块进行测试

• 模块接口
• 局部数据结构
• 重要的执行通路
• 出错处理通路
• 边界条件

4.6 集成测试

是测试和组装软件的系统化技术。

• 测试方法
  • 非渐增式测试
  • 渐增式测试

当使用渐增方式把模块结合到程序中去时，有自顶向下和自底向上的两种集成策略

• 比较集成试的两种方式的优劣
  • 非渐增式测试方式：分别测试模块,再把所有模块按设计要求放在一起组成所要的程序。该方法编写测试软件工作量大，模块间的接口错误发现得晚，错误定位较难诊断，总体测试有的错误容易漏掉，测试时间相对较少，可以并行测试所有模块，能充分利用人力，加快工程进度。。
  • 渐增式测试方式：把下一个要测试的模块,同已经测试好的那些模块结合起来进行测试。该方法利用已测试过的模块作测试软件,开销小，较早发现模块间的接口错误，错误定位往往和最近入的模块相关，对已测试好的模块可在新加入模块的条件下受到新的检验，测试更彻底，需要较多的测试时间，不能并行测试。
  • 总的来说，渐增式测试方法比较好。

4.7 确认测试

• 什么是确认测试？该阶段有哪些工作？

  • 确认测试又称有效性测试。它的任务是检查软件的功能与性能是否与需求规格说明书中确定的指标相符合 。

• 确认测试阶段有两项工作，进行确认测试与软件配置审查

  • 确认测试一般是在模拟环境中运用黑盒测试方法，由专门测试人员和用户参加的测试。
  • 软件配置审查的任务是检查软件的所有文档资料的完整性、正确性。如果发现遗漏和错误，应补充和改正，同时要编排好目录，为以后的软件维护工作奠定基础。

4.8 系统测试

4.9 回归测试的概念

4.10 程序正确性证明

4.11调试

（调试的概念、调试与测试的关系）

测试与调试的主要区别？

• 测试从一个侧面证明程序员的失败；调试证明程序员的正确；
• 测试从已知条件开始，使用预先定义的程序，且有预知的结果，不可预见的仅是程序是否通过测试；调试从不可知内部条件开始，除统计性调试外，结果是不可预见的；
• 测试有计划并且要进行测试设计；调试不受时间约束；
• 测试是发现错误、改正错误、重新测试的过程；调试是一个推理的过程；
• 测试执行是有规程的；调试执行要求程序员进行必要的推理；
• 测试由独立的测试组在不了解软件设计的件下完成；调试由了解详细设计的程序员完成；
• 大多数测试的执行和设计可由工具支持；调试用的工具主要是调试器。

4.12 测试覆盖度的概念

4.13 代码圈复杂度的计算方法

4.14 白盒测试中的基本路径测试方法

路径测试技术中几种主要覆盖的含义？举例说明？

• 语句覆盖：至少执行程序中所有语句一次。
• 判定覆盖：使被测程序中的每一个分支至少执行一次。故也称为分支覆盖。
• 条件覆盖：执行所有可能的穿过程序的控制路流程。
• 条件组合测试：设计足够的测试用例，使每个判定中的所有可能条件取值组合至少执行一次

4.15 黑盒测试中的等价类划分方法

等价分类法的测试技术采用的一般方法?举例说明?

• 为每个等价类编号；
• 设计一个新的测试方案,以尽可能多的覆盖尚未被覆盖的有效等价类,重复这一步骤,直到所有有效等价类被覆盖为止。
• 设计一个新的测试方案,使它覆盖一个尚未被覆盖的无效等价类, 重复这一步骤,直到所有无效等价类被覆盖为止。

4.16 Alpha和Beta测试

Alpha测试：由用户在开发者的场所进行，并且在开发者对用户的”指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题.

Beta测试：由软件的最终用户在一个或多个客户场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因此，Bate测试时软件在开发者不能控制的环境中的”真实”应用。

五、软件维护技术

5.1 软件维护的基本概念

软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程一个中等规模的软件，如果其开发过程需要一两年时间，则它投入使用以后，其运行时间可能持续5~10年之久。在这个维护阶段中，人们需要着手解决开发阶段尚未解决的问题，同时，还解决维护工作本身所产生的问题。做好软件的维护工作不仅能够排除软件中存在的错误，使它能够正常工作，而且还可以使它扩充功能，提高性能，为用户带来新的效益。维护阶段的花费约占整个软件生存周期花费的67%。 因此，应充分认识到维护现有软件的重要意义。

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

软件的维护一般分为哪几类？

• 改正性维护：满足用户对已开发产品的性能与运行环境不断提高的要求，进而达到延长软件寿命的目的。
• 适应性维护：对程序使用期间发现的程序错误进行诊断和改正的过程，配合变化了的环境进行修改软件的活动；
• 完善性维护：满足用户在使用过程中提出增加新的功能或修改已有功能的建议而进行的工作；
• 预防性维护：为了改善未来的可维护性或可靠性而修改软件的工作。

软件维护的最终目的，是满足用户对已开发产品的性能与运行环境的不断提高的需求，进而延长软件的寿命。

5.2 软件维护过程

• 维护过程

  • 维护组织
  • 维护报告
  • 维护的事件流
  • 保存维护记录
  • 评价维护活动。

• 为什么说软件的维护是不可避免的？

  • 因为软件的开发过程中，一般很难检测到所有的错误，其次软件在应用过程中需要随用户新的要求或运行环境的变化而进行软件的修改或完成功能的增删等，为了提高软件的应用水平和使用寿命，软件的维护是不可避免的。

5.3 软件可维护性

软件的可维护性是指维护人员为纠正软件系统出现的错误或缺陷，以及为满足新的要求而理解、修改和完善软件系统的难易程度。可维护性是所有软件系统都应具备的特点。在软件工程的每一-阶段都应该努力提高系统的可维护性，在每个阶段结束前的审查和复审中，应着重对可维护性进行复审。

决定软件可维护性的因素

• 软件的可理解性、可测试性、可修改性；
• 文档描述符合要求、用户文档简洁明确、系统文档完整并且标准。

5.3.1 可维护性度量的特性

主要有可理解性、可测试性和可修改性可理解性被定义为人们通过阅读源代码和文档了解软件系统的结构、接口、功能、内部过程以及如何运行的难易程度；可测试性被定义为诊断和测试系统的难易程度；可修改性被定义为修改软件系统的难易程度；它们是密切相关的。

5.3.2 提高可维护性的方法有哪些

在软件工程的每一阶段都应该努力提高系统的可维护性，在每个阶段结束前的审查和复审中，应着重对可维护性进行复审。在需求分析阶段的复审中，应对将来要扩充和修改的部分加以注明。在讨论软件可移植性问题时，要考虑可能要影响软件维护的系统界面。在软件设计的复审中，应从便于修改、模块化和功能独立的目标出发，评价软件的结构和过程，还应对将来可能修改的部分预先做准备。在软件代码复审中，应强调编码风格和内部说明这两个影响可维护性的因素。在软件系统交付使用前的每一测试步骤中都应给出需要进行预防性维护部分的提示。在完成每项维护工作后，都应对软件维护本身进行仔细认真的复审。为了从根本上提高软件系统的可维护性，人们正试图通过直接维护软件规格说明来维护软件，同时也在大力发展软件重用技术。

简述提高软件可维护性的方法

• 建立明确的软件质量标准；
• 使用先进软件开发技术和工具；
• 建立明确的软件质量保证工作；
• 选择可维护的程序设计语言；
• 改进程序文档。

5.4 软件再工程技术

简述软件再工程的过程

• 库存目录分析：包含每个应用系统的信息，如：名称、构建日期、修改次数、过去18个月报告的错误、用户数量、文档质量、预期寿命，等。从中选出再工程的候选者。

• 文档重构

  • 如果一个程序走向生命终点，不再经历变化，则保持现状；
  • 重构只针对当前正在修改的软件部分。

• 逆向工程：逆向工程是一个恢复设计结果的过程，从程序代码中抽取数据结构、体系结构和处理过程的设计信息。

• 代码重构： 分析源代码，标注出与结构化程序设计概念不符的部分，重构它的代码，测试重构代码并更新代码。

• 数据重构：当数据结构较差时，进行再工程。如以文件方式保存数据变为以数据库方式存储。

• 正向工程：也称革新或改造，即应用软件工程的原理、概念、技术和方法来重新开发现有系统。

六、软件项目管理

6.1 成本估计

软件开发成本估算方法有哪几种

• 自顶向下估算方法。估算人员参照以前完成的项目所耗费的总成本（或总工作量），来推算将要开发的软件的总成本（或总工作量），然后把它们按阶段、步骤和工作单元进行分配，这样方法称为自顶向下的估算方法。
• 自底向上估算方法。自底向上估算方法是将待开发的软件细分，分别估算每一个子任务所需要的开发工作量，然后将它们加起来，得到软件的总开发量。
• 差别估算方法。差别估算是将开发项目与一个或多个已完成的类似项目进行比较，找出与某个相类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。
• 专家估算法。依靠一个或多个专家对要求的项目做出估算。
• 类推估算法。
• 经验公式估算法。

为什么在软件开发中，不能用简单增加人员的方法来缩短开发时间？ 大量软件开发实践说明：向一个已经延迟的项目追加开发人员，可能使它完成得更晚。因为当开发人员以算术级数增长时，而人员之间的通信将以几何级数增长，往往”得不偿失”。

6.2 效益分析

6.3 风险分析

6.4 进度安排

6.5 项目组织与计划

6.6 软件质量保证与分析

• 影响软件质量的主要因素有哪些？

  • 产品运行：正确性、风险性、效率、完整性、健壮性和可用性；
  • 产品修改：可理解性、可维护性、灵活性、可测试性；
  • 产品转移：可移植性、可重用性和互运行性。

• 如何做好软件质量保证工作？

  软件质量保证工作是软件工程管理的重要内容，软件质量保证应做好以下几个方面的工作

  • 采用技术手段和工具。质量保证活动要贯彻开发过程始终，必须从采用技术手段和工具，尤其是使用软件开发环境来进行软件开发。
  • 组织正式技术评审，在软件开发的第一个阶段结束时，都要组织正式的技术评审。国家标准要求单位必须采用审查、文档评审、设计评审、审计和测试等具体手段来保证质量。
  • 加强软件测试。软件测试是质量保证的重要手段，因为测试可发现软件可发现软件中大多数潜在错误。
  • 推选软件工程规范（标准）。用户可以自己指定软件工程规范（标准），但标准一旦确认就应贯彻执行。
  • 对软件的变更进行控制。软件的修改和变更常常会引起潜伏的错误，因此必须严格控制软件的修改和变更。
  • 对软件质量进行度量。即对软件质量进行跟踪，及时记录和报告软件质量情况。

基线是一个软件配置管理概念，它有助于人们在不严重合理变化的前提下来控制变化，简而言之，基线就是通过了正式复审的软件配置项。。在软件配置项变成基线之前，可以迅速而非正式地修改它。

七、参考书目

• 《软件工程：实践者的研究方法》（英文版，第7版），Roger Pressman，机械工业出版社，2010年10月