软件工程期末复习笔记

仅用作个人期末复习总结

1.1.3 消除软件危机的途径

1. 软件：程序、数据、文档的完整集合。
2. 软件开发：一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
3. 推广使用在实践中总结出来的开发软件的成功的技术和方法，并研究探索更好更有效的技术和方法。
4. 开发和使用更好的软件工具。

1.2.1 软件工程的介绍

1. 软件工程：指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量地软件并有效地维护他。
2. 软件工程的本质特性：
   • 软件工程关注于大型程序的构造
   • 软件工程的中心课题是控制复杂性
   • 软件经常变化
   • 开发软件的效率十分重要
   • 和谐的合作是开发软件的关键
   • 软件必须有效地支持他的用户
   • 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人开发产品

1.2.3 软件工程方法学

1. 软件工程方法学三要素：方法、工具和过程

   • 方法：完成软件开发的各项任务的技术方法，是“怎样做”
   • 工具：运用方法而提供的自动或半自动的软件工程的支撑环境
   • 过程：为了获得高质量软件所需要完成的一系列人物的框架，她规定了完成各项任务的基本步骤

2. 最广泛的软件工程方法学：传统方法学和面向对象方法学

3. 传统方法学（生命周期方法学、结构化范型）：

   • 定义：采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。
   • 特点：把软件生命周期划分为若干个阶段，每个阶段相互独立。在软件生命周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作。

4. 面向对象方法学：

   • 把数据和行为看成是同等重要的，他是一种以数据为主线，把数据和对数据的操作紧密结合起来的方法
   • 4个要点：
     • 把对象作为融合了数据及在数据上的操作行为的统一的软件构件
     • 把对象都划分为类
     • 按照父类（或基类）与子类（或派生类）的关系，把若干个相关类组成一个层次结构的系统（也称类等级）
     • 对象彼此间仅能通过发送消息互相联系。
   • 出发点和基本原则：尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程，从而使描述问题的问题空间（问题域）与实现解法的解空间（求解域）在结构上尽可能一致。
   • 优点：降低软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作。面向对象方法特有的继承性和多态性，进一步提高了面向对象软件的可重用性。

1.3 软件的生命周期

1. 软件生命周期：软件定义、软件开发、软件维护（运行维护）

2. 软件定义时期的任务：

   1. 确定软件开发工程必须完成的总目标
   2. 确定工程的可行性
   3. 导出实现工程目标应该采用的策略及系统必须完成的功能
   4. 估计完成该工程所需的资源和成本，并且指定工程进度表

3. 软件定义时期又称系统分析时期，由系统分析员完成。有3个阶段：问题定义、可行性研究、需求分析。

4. 开发时具体设计和实现在前一个时期定义的软件通常由4个阶段组成：

   1. 总体设计
   2. 详细设计
   3. 编码
   4. 单元测试

   前两个阶段又称系统设计，后两个阶段成为系统现。

5. 维护时期的主要任务是使软件持久地满足用户的需要

6. 软件生命周期的基本任务：

   1. 问题定义

      通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标、和工程规模地书面报告，经过讨论和必要地修改后这份报告应该得到客户的确认

   2. 可行性研究

      关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程，可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探究这个问题是否值得去解，是否有可行的解决办法

   3. 需求分析

      为了准确地确定“为了解决这个问题，目标系统必须做什么”，主要使确定目标系统具备什么功能。系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认地系统逻辑模型。通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。

   4. 总体设计

      关键问题：“概括地说，应该怎样实现目标系统？”设计出实现目标系统的几种可能的方案。通过至少应该设计出低成本、中等成本和高成本3种方案，推荐一个最佳方案。总体设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成及模块间的关系。

   5. 详细设计

      关键问题：“应该怎样具体地实现这个系统呢？”设计出程序的详细规格说明。详细设计也称模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。

   6. 编码和单元测试

      关键任务：写出正确的容易理解、容易维护的程序模块。应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

   7. 综合测试

      关键任务：通过各种类型的测试使软件达到预定的要求。最基本的测试是集成测试和验收测试。

   8. 软件维护

      关键任务：通过各种必要的维护活动使活动系统持久地满足用户的需要。

7. 4类维护活动：

   1. 改正性维护：诊断和改正正在使用过程中发现的软件的错误
   2. 适应性维护：修改软件以适应环境的变化
   3. 完善性维护：根据用户的要求改进或扩充软件使他更加完善
   4. 预防性维护：修改软件，为将来的维护活动预先做准备。

1.4.1 瀑布模型

1. 一直是唯一被广泛采用的生命周期模型，现在仍是软件工程中应用得最广泛的过程模型。

2. 特点：

   1. 阶段时间具有顺序性和依赖性

      两重含义：

      ①必须等前一阶段的工作完成之后，才能开始后一阶段的工作

      ②前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才是正确的结果

   2. 推迟实现的观点

      瀑布模型在编码之前设置了系统分析与系统设计各个阶段，分析与设计阶段的基本任务规定，子啊这两个阶段主要考虑吧目标系统与逻辑模型，不涉及物理的实现

   3. 质量保证的观点

      软件工程的基本目标：优质、高产。瀑布模型每个阶段坚持的两个重要做法：

      ①每个阶段必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。

      ②每个阶段完成前都要对所完成的文档进行评审，以便尽早地发现问题，改正错误。

3. 传统的瀑布模型太理想化了，实际的瀑布模型带有“反馈环”。

4. 瀑布模型的优点：

   • 强迫开发人员采用规范的方法
   • 严格规定了每个阶段必须提交的文档
   • 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证

5. 主要缺点：瀑布模型是由文档驱动的

   用户不经过实践就提出完整准确的需求在许多情况下都是不切实际的。由于瀑布模型几乎完全依赖书面的规格说明，很可能导致最终开发出的软件产品不能正常满足用户的需求。

1.4.2 快速原型模型

1. 快速原型：快速建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终产品能完成的功能的一个子集。
2. 快速原型模型：快速建立一个能反馈用户需求的原型系统，让用户在计算机上试用它，通过时间来了解目标系统的概貌。用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，让用户再次试用。一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可以据此书写规格说明文档，根据这份文档开发出的软件便可以满足用户的真实需求。
3. 快速原型模型不带反馈环。
4. 主要优点：软件产品的开发基本上是线性顺序进行的。
5. 能做到线性顺序开发的原因：
   1. 原型系统已经通过与用户交互而得到验证
   2. 开发人员通过建立原型模型已经学到了许多东西
6. 根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同的阶段
7. 原型系统的内部结构不重要，重要的是，必须迅速的构建原型然后根据用户意见迅速修改模型。

1.4.3 增量模型

1. 又称渐增模型。把软件作为一系列的增量构建来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
2. 增量模型分批地逐步向用户提交产品。整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。
3. 优点：
   1. 能在较短时间内向用户提交可完成部分地产品
   2. 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新软件可能给客户组织带来的冲击
4. 困难：在把每个新的构件集成到现有的软件体系结构中时，必须不破坏原来已经开发出的新产品。向现有产品中加入新构建的过程必须简单、方便。即软件结构必须是开放的。
5. 用增量模型开发软件，不同的构件并行地构建，可能加快工程进度。但是使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程毁于一旦。

2.4 数据流图

1. 

2. 处理并不一定是一个程序。

3. 数据存储和数据流都是数据，仅仅是状态不同。前者是静止的，后者是运动的。

4. 命名问题：

   1. 数据流、数据存储：
      • 名字应带表整个数据流或数据存储的内容
      • 不要使用空洞的、缺乏具体含义的名字
      • 如果在为某个数据流或数据存储起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的
   2. 处理：
      • 先为数据流命名，再为与之相关联的处理命名。
      • 名字应该反映整个处理的功能
      • 最好由一个具体的及物动词及一个具体的宾语组成
      • 仅包括一个动词
      • 如果遇到命名困难，可能是分解不当
   3. 注意处理编号的方法

2.5.2 定义数据的方法

1. 数据元素组成数据的方式有下述三种基本类型和一种增加的关系算符：

   1. 顺序：以确定次序连接两个或多个分量
   2. 选择：从两个或多个可能的元素中选取一个
   3. 重复：把指定的分量重复次数的上下限同时使用
   4. 可选：即一个分量是可有可无的（重复零次或一次）

2. 符号：

   =：等价于（定义为）

   +：和（连接两个分量）

   []：或（从方括号内列出的若干分量中选择一个），使用“|”隔开

   {}：重复（重复花括号内的分量）

   ()：可选（可有可无）

   常常使用上限和下限进一步注释表示重复的花括号，花括号左侧标重复的下限，右侧标重复的上限，如1{A}5

2.6 成本/效益分析

1. 代码行技术：把开发每个软件功能的成本和实现这个功能需要用的源代码行数联系起来，根据经验和历史数据估计实现一个功能需要的源程序行数。成本 = 每行代码的平均成本 * 行数
2. 任务分解技术：把软件开发工程分解成若干个相对独立的任务，再分别估计每个单独开发任务的成本，最后累加起来就是软件开发工程的总成本。
3. 自动估计成本技术：使用相应的软件工具。
4. 货币的时间价值：用利率的形式表示货币的时间价值。
5. 投资回收期：使累计的经济效益等于最初同投资所需要的时间。
6. 纯收入：整个生命周期之内系统的累计经济效益与投资之差。
7. 投资回收率：衡量投资效益的大小，可以把它和年利率比较。

3.1 需求分析的任务

1. 软件系统的综合要求：

   • 功能需求：系统必须提供的服务
   • 性能需求：必须满足的定时约束和容量约束
   • 可靠性和可用性需求：可靠性需求定量的指定系统的可靠性。可用性量化了用户可以使用系统的程度。
   • 出错处理要求：说明系统对环境错误应该做出怎样的相应。
   • 接口需求：描述应用徐通与它环境通信的格式。
   • 约束：在设计或实现应用系统时应遵守的限制条件
   • 逆向需求：软件系统不应该做什么
   • 将来可能提出的要求：虽不属于当前系统的开发范畴，但是据分析将来可能会提出来的要求。

2. 分析系统的数据要求通常采用建立数据模型的方法。

3. 导出系统的详细的逻辑模型，通常用数据流图、实体联系图、状态转换图、数据字典和主要的处理算法描述逻辑模型

4. 修正系统的开发计划

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

1. 访谈

   • 两种形式：正式和非正式的访谈
   • 使用情景分析技术，情景分析技术指对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。
   • 情景分析技术的作用：
     • 在某种程度上演示目标系统的行为，可能进一步揭示出分析员目前还不知道的某些需求
     • 较易为用户所理解

2. 面向数据流自顶向下求精

   

3. 简易的应用规格说明技术

   优点：开发者与用户不分彼此，齐心协力，密切合作。即时讨论并求精。有能导出规格说明的具体步骤。

4. 快速建立软件原型

   • 特性：快速、容易修改
   • 3种方法和工具：
     • 第四代技术
     • 可重用的软件构件
     • 形式化规格说明和原型环境

3.6 状态转换图

1. 状态图中定义的状态：

   初态（初始状态）

   终态（最终状态）

   中间状态

   初态只能有一个，终态可以有0至多个

2. 状态图可以表示系统循环运行过程，也可以表示系统单程生命状态。前者不关心循环怎样启动，后者需要表明初始状态和最终状态。

3. 事件：在某个特定时刻发生的事。是引起系统做动作或（和）转换太转换的控制信息

4. 符号：

   • 初态：●

   • 终态：◉

   • 中间状态用圆角矩形表示，两条水平横线分为上中下三部分。上部分是状态名称，必有。中间部分是状态变量的名字和值，可选。下部分是活动表，可选

   • 活动表语法：事件名（参数表）/动作表达式

     活动表中的3种标准事件：

     • entry：指定进入该状态的动作
     • exit：指定退出该状态的动作
     • do：指定在该状态下的动作

   • 事件表达式语法：事件说明[守卫表达式]/动作表达式

     • 事件说明：事件名（参数表）
     • 守卫表达式：布尔表达式
     • 动作表达式：过程表达式，状态转换开始时执行该表达式

   • 

   • 举个🌰：

5.2.5 模块独立

1. 耦合

   • 含义：是对一个软件结构内不同模块之间连接程度的度量。耦合的强弱取决于不同模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。
   • 数据耦合：两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据结构
   • 控制耦合：传递的信息有控制信息
   • 特征耦合：当把整个数据结构作为参数传递而调用的模块只需要使用其中一部分数据元素
   • 公共环境耦合：当两个或多个模块通过一个公共数据环境相互作用时
   • 内容耦合的情况：
     • 一个模块访问另一个模块的内部数据
     • 一个模块不通过正常入口而转到另一个模块的内部
     • 两个模块有一部分程序代码重叠（只有可能出现在汇编语言中）
     • 一个模块有多个入口（意味着这个模块有多个功能）
   • 数据耦合是低耦合，系统中必须存在。控制耦合是中程度的耦合，可以将模块适当分解解决。内容耦合是高程度的耦合，应当避免
   • 公共环境耦合的复杂程度随耦合模块的个数变化，数量增加复杂程度增加。
   • 如果两个模块有公共环境，那么这种耦合有两种可能
     • 一个模块往公共环境种送数据，另一个模块从公共环境种取数据。这是数据耦合的一种形式
     • 两个模块都既往公共环境中送数据又从中取数据，这种耦合程度介于数据耦合和控制耦合之间
   • 设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不使用内容耦合。

2. 内聚

   • 含义：内聚标志着一个模块内部各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然拓展。理想内聚的模块只做一件事情。
   • 设计时力求做到高内聚，中等程度的内聚也可以。
   • 耦合与内聚密切相关，模块的高内聚意味着模块间的低耦合。实践表明，内聚更重要。
   • 低内聚：
     • 偶然内聚：如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也很松散
     • 逻辑内聚：一个模块完成的任务在逻辑上属于相同或相似的一类
     • 时间内聚：一个模块包含的任务必须在同一段时间内执行
   • 中内聚：
     • 过程内聚：一个模块内处理的元素是相关的，而且必须以特定的次序执行
     • 通信内聚：模块中所有元素都使用同一个输入数据和（或）产生同一个输出数据
   • 高内聚：
     • 顺序内聚：一个模块内的处理元素和同一个功能密切相关，而且这些处理必须按顺序执行
     • 功能内聚：模块内所有处理元素属于一个整体，完成一个单一的功能
   • 功能内聚 > 顺序内聚 > 通信内聚 > 过程内聚 > 时间内聚 > 逻辑内聚 > 偶然内聚

6.1 结构程序设计

1. 3种能实现任何单入口单出口的程序的控制结构：

   1. 顺序
   2. 选择
   3. 控制

   用顺序结构和训话结构可以试下选择结构，理论上最基本的控制结构只有两种

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

3. LEAVE或BREAK实际上是受限制的前向GO TO语句，用于转移到循环结构后面的语句

4. 经典的结构程序设计：只允许使用顺序、IF-ELSE型分支、DO-WHILE型循环

5. 拓展的结构程序设计：在经典的基础上，还允许使用DO-CASE型多分支结构和DO-UNTIL型循环结构

6. 修正的结构程序设计：在拓展的基础上，允许使用LEAVE或BREAK结构

6.3.3 PAD图

1. PAD图即问题分析图，用二维树形结构的图来表示程序的控制流。
2. 基本符号：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3pmc9lCe-1654399465973)(C:\Users\Nakiri\Desktop\42EF9E8FE17E50847908F7863C4E8DA1.png)]
3. 优点：
   1. 设计出的程序必然是结构化的程序
   2. 描绘的结构十分清晰
   3. 表现程序逻辑，易读易懂易记
   4. 容易将PAD图转换成高级语言源程序
   5. 既可用于表示程序逻辑，也可用于描绘数据结构
   6. 支持自顶向下，逐步求精方法的使用

6.3.4 判定表

1. 4部分
   1. 左上部分：列出所有条件
   2. 左下部分：所有可能的动作
   3. 右上部分：各种条件组合的一个矩阵
   4. 右下部分：和每种条件组合相对应的动作
2. 举个🌰

7.2.4 测试步骤

1. 软件测试步骤

   1. 模块测试

      又称单元测试，发现的是编码和详细设计的错误

   2. 子系统测试

      把经过单元测试的模块放在一起形成一个子系统来测试。着重测试接口间的通信

   3. 系统测试

      把经过测试的子系统装配成一个完整的系统测试。发现的是软件设计中的错误，也可能发现需求说明中的错误

      子系统测试和系统测试通常称为集成测试

   4. 验收测试

      又称确认测试，把软件系统作为单一的实体进行测试。发现系统需求说明书中的错误

   5. 平行运行

      • 含义：同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果
      • 目的：
        • 可以在准生产环境种运行新系统又不冒风险
        • 用户能有一段熟悉新系统的时间
        • 可以验证用户指南和使用手册之类的文档
        • 能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标

7.4 集成测试

1. 集成测试：测试和组装软件的系统化技术

2. 主要目标：发现与接口有关的问题

3. 模块组装成程序的两种方法：

   1. 非渐增式测试方法：先分别测试每个模块，再把所有模块按照设计要求放在一起组合成程序
   2. 渐增式测试方法：把下一个应该测试的模块结合进来测试，测试完以后再把下一个要测试的模块结合进来测试

4. 普遍采用渐进式测试方法。有自顶向下和自底向上两种策略

5. 自顶向下的策略：

   1. 含义：从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来。在把附属于主控制模块的哪些模块组装到程序结构中去时使用深度优先策略，或者宽度优先策略
   2. 步骤
      1. 对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块
      2. 根据选定的结合策略，每次用一个实际模块代换一个存根程序
      3. 在结合进一个模块的同时进行测试
      4. 保证加入的模块没有引进新的错误，可能进行回归测试
   3. 优点：不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误
   4. 缺点：需要存根程序，可能遇到与此联系的测试困难，低层关键模块中的错误发现较晚，而且早期不能充分展开人力
   5. 解决在软件结构中没有重要的数据自下往上流的问题：
      1. 把许多测试推迟到用真实模块代替了存根程序后进行
      2. 从层次系统的底部向上组装软件（自底向上的策略）

6. 自底向上的策略：

   1. 含义：自底向上测试从“原子”模块开始组装和测试
   2. 步骤
      1. 把低层模块组合成实现某个特定的软件子功能的族
      2. 写一个驱动程序，协调测试数据的输入和输出
      3. 对由模块组成的子功能族进行测试
      4. 去掉驱动程序，沿软件结构自下向上移动，把子功能族组合成形成更大的子功能族
   3. 优缺点和自顶向下策略相反

7. 纯粹的自顶向下和自底向上都不适用，人们在实践中创造了许多混合策略

   1. 改进的自顶向下测试法，在早期是固体部分自底向上的方法测试软件中的少数关键模块
   2. 混合法，在软件结构较上层使用的自顶向下方法与对软件结构中较下层使用自底向上方法结合

7.6.1 逻辑覆盖

1. 逻辑覆盖：对一系列测试过程的总称

2. 语句覆盖

   1. 含义：选择足够多的测试数据，使被测试程序中每个语句至少执行一次。
   2. 语句覆盖是很弱的逻辑覆盖标准

3. 判定覆盖（分支覆盖）

   1. 含义：不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次

4. 条件覆盖

   1. 含义：不仅每个语句要被执行一次，而且使判定表达式中的每个条件都取到各种可能的结果

5. 判定/条件覆盖

   1. 含义：选取足够多的数据，使判定表达式中的每个条件都取得各种可能的值，而且每个判定表达式也都取得各种可能的结果

6. 条件组合覆盖

   1. 含义：选取足够多的测试数据，使得每个判定表达式中的条件各种可能的组合都至少出现一次

7.7 黑盒测试技术

1. 黑盒测试技术着重测试软件功能

2. 黑盒测试发现的错误类型

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

3. 设计黑盒测试方案时，应该考虑的问题

   1. 怎样测试功能的有效性
   2. 哪些类型的输入可构成好的测试用例
   3. 系统是否对特定的输入值特别敏感
   4. 怎样划分数据类的边界
   5. 系统能够承受怎样的数据率和数据量
   6. 数据的特定组合将对系统造成怎样的影响

4. 应用黑盒测试技术，可以导出符合下属标准的测试用例

   1. 测试用例能够减少为达到合理测试所需的设计的测试用例的总数
   2. 测试用例能够告诉人们，是否存在某种类型的错误

5. 黑盒测试技术：

   1. 等价划分

      1. 含义：把程序的输入域划分为若干个数据类，据此导出测试用例
      2. 划分等价类的启发式规则
         1. 如果规定了输入值的范围，就可以划分出一个有效的等价类和两个无效的等价类
         2. 规定了输入数据的个数，就可以划分出一个有效等价类和两个无效等价类
         3. 如果规定了输入数据的一组值，而程序对不同输入值做不同的处理，则允许每个输入值是一个有效的等价类，此外还有一个无效的等价类
         4. 如果规定了输入数据必须遵守的规则，则可以划分出一个有效的等价类和无数个无效的等价类
         5. 如果规定了输入数据为整型，则可以划分出正整数、零和负整数3个有效类
         6. 如果程序的处理对象是表格，则应该使用空表、含一项或多项的表
      3. 根据等价类设计测试方案的步骤
         1. 设计一个新的测试方案以尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步骤知道所有有效等价类都被覆盖为止
         2. 设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止

   2. 边界值分析

      着重测试程序边界情况，选取的测试数据应该刚好等于、刚刚小于、刚刚大于边界值。

   3. 错误推测

8.1 软件维护的定义

1. 软件维护的定义：在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程

2. 软件交付使用后可能进行的4项活动

   1. 改正性维护：在任何大型程序的使用期间，用户必然会发现程序的错误，并且把他们遇到的问题报告给维护人员
   2. 适应性维护：为了和变化了的环境适当地进行配合而进行的修改软件的活动，必要且经常
   3. 完善性维护：满足用户提出的新增功能或修改已有功能的需求，或者一般性的改进意见，占维护工作的大部分
   4. 预防性维护：为了改进未来的可维护性或可靠性，或为了给未来的改进奠定基础而修改软件，相对较少
   5. 如果程序的处理对象是表格，则应该使用空表、含一项或多项的表

   3. 根据等价类设计测试方案的步骤
      1. 设计一个新的测试方案以尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步骤知道所有有效等价类都被覆盖为止
      2. 设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止

   2. 边界值分析

      着重测试程序边界情况，选取的测试数据应该刚好等于、刚刚小于、刚刚大于边界值。

   3. 错误推测

8.1 软件维护的定义

1. 软件维护的定义：在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程
2. 软件交付使用后可能进行的4项活动
   1. 改正性维护：在任何大型程序的使用期间，用户必然会发现程序的错误，并且把他们遇到的问题报告给维护人员
   2. 适应性维护：为了和变化了的环境适当地进行配合而进行的修改软件的活动，必要且经常
   3. 完善性维护：满足用户提出的新增功能或修改已有功能的需求，或者一般性的改进意见，占维护工作的大部分
   4. 预防性维护：为了改进未来的可维护性或可靠性，或为了给未来的改进奠定基础而修改软件，相对较少
3. 维护软件文档和维护软件的可执行代码同样重要。