软件设计师学习-第五章 软件工程基础知识

wiki

本章的知识点会涉及单选题型，约占 2～5 分，偏重于概念知识

1. 软件工程概述

1. 计算机软件

计算机软件指的是计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述。任何以计算机为处理工具的任务都是计算任务。

按照软件的应用领域，将计算机软件分为以下十类，包括：①系统软件；②应用软件；③工程/科学软件；④嵌入式软件；⑤产品线软件；⑥Web 应用软件（Web APP）；⑦人工智能软件；⑧开放计算；⑨网络资源；⑩开源软件

2. 基本原理

美国著名的软件工程专家 B.W.Boehm 于 1983 年提出了软件工程的七条基本原理：

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

3. 生存周期

一个软件产品或软件系统要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期。软件生存周期包括以下七个方面：

1. 可行性分析与项目开发计划

这个阶段主要确定软件的开发目标及其可行性。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档有可行性分析报告、项目开发计划。

2. 需求分析

该阶段的任务不是具体的解决问题，而是要确定软件系统要做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。

参与人员：用户、项目负责人、系统分析师。

产生文档：软件需求说明书。

3.概要设计

该阶段开发人员把确定的各项功能需求转换成需要的体系结构。概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块层次结构是怎样的，调用关系是怎样的，每个模块的功能是什么。

参与人员：系统分析师、软件设计师。

产生的文档：概要设计说明书。

4. 详细设计

该阶段的主要任务是对每个模块的功能进一步详细、具体的描述。

参与人员：软件设计师、程序员。

产生文档：详细设计文档。

5. 编码

把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单。

6. 测试

测试是保证软件质量的重要手段。

参与人员：通常是另一部门（或单位）的软件设计师或系统分析师。

产生文档：软件测试计划、测试用例、测试报告。

7. 维护

软件维护是软件生存周期中时间最长的阶段。软件已交付且正式投入使用后，便进入维护阶段。对软件进行修改的原因包括：①运行中发现隐含的错误而需要修改；②为了适应变化的（或变化后的）工作环境而修改；③需要对软件功能进行扩充、增强而进行的修改；④为将来软件维护活动做预先准备

4. 软件工程

软件开发中遵循一系列可预测的步骤（即路线图），该路线图称为软件过程。

过程是活动的集合，活动是任务的集合。

软件过程有三层含义：

• 个体含义：指某产品、系统在生存周期中的某一类活动的集合，如开发过程、管理过程等。
• 整体含义：指软件产品、系统在所有上述含义下的软件过程的总体。
• 工程含义：指解决软件过程的工程

5. 软件工程概念模型

1. 能力成熟度模型（CMM）

CMM 是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。

CMM 将软件过程的改进分为五个成熟度级别：初始级、可重复级、已定义级、已管理级、优化级。

2. 能力成熟度模型集成（CMMI）

CMMI 提供了两种表示方法：阶段式模型和连续式模型。

1. 阶段式模型

结构类似于 CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1 版本中有五个成熟度等级：

• 初始级：过程不可预测且缺乏控制
• 已管理级：过程为项目服务
• 已定义级：过程为组织服务
• 定量管理级：过程已度量和控制
• 优化级：集中过程改进

2. 连续式模型

关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（简称 CL）。CMMI 中包括六个过程域能力等级：

• CL0：未完成级，表明过程域一个或多个特定目标未满足
• CL1：已执行级，过程通过转化可识别的输入工作产品，产生可识别的输出工作产品
• CL2：已管理级，
• CL3：已定义级
• CL4：定量管理级
• CL5：优化级

2. 软件过程模型

习惯上称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。

1. 瀑布模型

瀑布模型将软件生命周期中的各个活动规定为依据线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行、维护，如同瀑布流水逐级下落。瀑布模型的一个变体是 V 模型。

在瀑布模型中，需求或设计的错误往往只有到了项目后期才能被发现，对项目风险的控制能力较弱，导致项目通常会延期，开发费用超出预算。

• 优点：简单、强调早期
  • 容易理解、成本低
  • 强调开发的阶段性早期计划、需求调查、产品测试
• 缺点：抗风险差、后期测试集中
  • 客户必须要准确地表达他们的需要
  • 在早期阶段，很难评估真正的进度状态
  • 项目快结束时，出现大量的集成与测试工作
  • 项目结束之前，不能演示系统的能力

2. 增量模型

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征。

• 优点：初版交付快、增量小风险小
  • 具有瀑布模型所有的优点
  • 第一个交付版本的成本和时间较少，并因此可减少用户需求的变更
  • 增量开发小系统，所承担的风险较小
• 缺点：变更规划影响大、管理成本高
  • 若未规划用户变更，可能造成后来增量不稳定
  • 若需求不稳定完整，可能需要重新开发或发布
  • 管理成本、进度、配置复杂性，可能会超出组织的能力

3. 演化模型

演化模型是应对不断演化、迭代的过程模型，适用于对需求缺乏准确认识的情况。

典型的演化模型：原型模型、螺旋模型。

1. 原型模型

首先定义总体目标、制定原型开发计划，迅速开发一个系统，再收集客户反馈意见，进入下一轮原型的迭代开发。

• 适用：需求不清或变动频繁，并且系统规模不大、不复杂时
• 分类：探索型原型、实验型原型、演化型原型

2. 螺旋模型

螺旋模型将瀑布模型和原型模型结合起来，加入两种模型均忽略的风险分析，弥补了这两种模型的不足。需要开发人员具体相当丰富的风险评估经验和专门知识。

• 适用：于庞大、复杂、高风险的系统

螺旋模型中的每个螺旋周期大致与瀑布模型一致，可分为以下四个步骤：

• 制订计划：确定软件目标，选定实施方案，明确项目开发的限制条件
• 风险分析：对所选方案进行分析，识别风险，消除风险
• 实施工程：实施软件开发，验证阶段性产品
• 用户评估：评价开发工作，提出修正建议，建立下一个周期的开发计划

4. 喷泉模型

喷泉模型克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。

• 适用：以对象为驱动，面向对象的模型
• 优点：各阶段无明显边界，开发效率高
• 缺点：过程中需要大量开发人员，且需要严格管理文档

5. 基于构件的开发模型

基于构件的开发模型是指利用预先包装的构件来构造应用系统。

构件可以是组织内部开发的构件，也可以是商品化成品（COTS）软件构件。

• 分类：领域工程、应用系统工程

6. 形式化方法模型

形式化方法是建立在严格数学基础上的一种软件开发方法。

• 适用：生成计算机软件形式化的数学规格说明

7. 统一过程模型

统一过程（UP）模型是一种 “用例和风险驱动，以架构为中心，迭代并增量” 的开发过程，由 UML 方法和工具支持。

统一过程定义了四个技术阶段及其主要工作产品：

• 起始阶段：专注于项目初创活动
  • 里程碑：生命周期目标
  • 工作产品：构想文档、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划、业务模型及多个原型（需要时）
• 精化阶段：在理解了最初的领域范围之后进行需求分析和架构演进
  • 里程碑：生命周期架构
  • 工作产品：用例模型、补充需求、分析模型、整体体系结构描述、可执行的软件体系结构原型、初步设计模型、修订的风险列表、项目计划及初始用户手册
• 构建阶段：关注系统的构建，产生实现模型
  • 里程碑：初始运作功能
  • 工作产品：设计模型、软件构件、集成软件增量、测试计划及步骤、测试用例及支持文档（用户手册、安装手册等）
• 移交阶段：关注软件提交方面的工作，产生软件增量
  • 里程碑：产品发布
  • 工作产品：提交的软件增量、β 测试报告和综合用户反馈

统一过程的典型代表是 RUP，RUP 是 UP 的商业扩展，完全兼容 UP，比 UP 更完整、更详细。

8. 敏捷方法

敏捷方法的总体目标是通过 “尽可能早地、持续地对有价值的软件进行交付” 使客户满意。

典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念，即敏捷宣言：

• 极限编程（XP）：把整个开发过程分解为比较小而简单的周期，结对编程
• 水晶法（Crystal）：强调软件开发流程的纪律性
• 并列争球法（Scrum）：增量、迭代，由若干个短的迭代周期组成，一个短的迭代周期称为一个 Sprint，长度是 2 到 4 周
• 自适应软件开发（ASD）：强调开发方法的适应性
• 敏捷统一过程（AUP）：在大型上联系，在小型上迭代

3. 软件项目需求分析

1. 软件需求

• 功能需求：考虑系统要做什么、什么时候做、如何修改或升级。
• 性能需求：考虑软件开发的技术性指标，如存储容量限制、执行速度、响应时间、吞吐量等。
• 用户或人的因素：考虑用户的类型。
• 环境需求：考虑软件应用的环境。
• 界面需求：考虑来自其他系统的输入或到其他系统的输出等。
• 文档需求：考虑需要哪些文档、文档针对哪些读者。
• 数据需求：考虑输入、输出格式，接收、发送数据的频率，数据的精准度、数据流量、数据保持时间。
• 资源使用需求：考虑软件运行时所需要的资源。
• 安全保密需求：考虑是否需要对访问系统或系统信息加以控制。
• 可靠性需求：考虑系统的可靠性需求、系统是否必须检测和隔离错误、出错后重启系统所允许的时间等。
• 软件成本消耗或开发进度需求：考虑开发是否有规定的时间表。
• 其他非功能性需求：如采用某种开发模式、确定质量控制标准、里程碑和评审、验收标准等。

2. 需求分析原则

需求分析过程有不同的分析方法，它们要遵循的操作原则有：

• 必须能表示和理解问题的信息域
• 必须能定义软件将完成的任务
• 必须能表示软件的行为
• 必须划分描述数据、功能和行为的模型
• 分析过程应该从要素信息移向细节信息

3. 需求工程

需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。

需求工程细分为六个阶段：①需求获取；②需求分析与协商；③系统建模；④需求规约；⑤需求验证；⑥需求管理。

4. 软件项目系统设计

系统设计的主要内容包括新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。

常用的设计方法有：面向数据流的结构化设计方法（SD）、面向对象的分析方法（OOD）。

系统设计包括两个基本的步骤：概要设计、详细设计。

• 概要设计主要包括：
  • 软件系统总体结构设计：划分模块和功能，确定调用和接口
  • 数据结构及数据库设计
  • 编写概要设计文档（概要设计说明书、数据库设计说明书、用户手册及修订测试计划）
  • 评审
• 详细设计主要包括：
  • 对每个模块进行详细设计
  • 对模块内部的数据结构进行设计
  • 对数据库进行物理设计，即确定数据库的物理结构
  • 其他设计（代码设计、输入/输出设计、用户界面设计）
  • 编写详细设计说明书
  • 评审

5. 软件项目系统测试

1. 系统测试与调试

• 信息系统测试包括：软件测试、硬件测试、网络测试
• 测试的目的：以最少的人力和时间，发现潜在的错误和缺陷

测试应遵循的基本原则：

• 应尽早并不断地进行测试
• 测试工作应避免原先开发软件的人员或小组参与
• 设计测试方案时要确定输入数据，还要根据系统功能确定预期的输出结果
• 设计测试用例时要设计合理、有效的输入条件，还要包含不合理、失效的输入条件
• 在测试时要检查程序是否做了该做、不该做的事，多余的工作会影响程序的效率
• 严格按照测试计划进行测试
• 妥善保存测试计划、测试用例
• 要精心设计测试用例

测试的过程包括：

• 制定测试计划
• 编制测试大纲
• 根据测试大纲设计和生产测试用例
• 事实测试
• 生成测试报告

2. 传统软件的测试策略

1. 单元测试

单元测试也称模块测试，在模块编写完成且编译无误后进行，侧重于模块中的内部处理逻辑和数据结构。

测试时，需要开发两种模块：

• 驱动模块：相当于一个主程序，接收测试例子的数据，将这些数据送到测试模块，输出测试结果
• 桩模块：也称为存根模块，用来代替测试模块中所调用的子模块，其内部可进行少量的数据处理，目的是为了检验入口，输出调用和返回的信息

2. 集成测试

集成测试通常有以下两种方法：

• 非增量集成：分别测试各个模块，再将这些模块组合起来进行整理测试。
• 增量集成：以小增量的方式逐步进行构造和测试。

常用的增量集成策略包括：

• 自顶向下测试：从主程序开始，沿控制层向下，将从属于主控模块集成到结构中
• 自底向上测试：从最底层构件开始构造测试，无需桩模块
• 回归测试：每加入一个模块进行集成测试时，重新测试已测试过的某些子集
• 冒烟测试：对提交测试的软件在进行详细深入的测试之前而进行的预测试，目的是暴露导致软件需重新发布的基本功能失效等严重问题

3. 确认测试

确认测试始于集成测试的结束，那时已测试完单个构件，软件已经组装成完整的软件包，而且接口错误已被发现和改正。

确认过程的一个重要成分是配置评审，主要检查软件、文档、数据是否齐全、分类有序。

4. 系统测试

系统测试是将已经确认的软件、硬件、外设、网络等其他因素结合在一起，进行各种集成测试和确认测试，主要包括恢复测试、安全性测试、压力测试、性能测试、部署测试。

3. 测试方法

软件测试分为静态测试和动态测试：

• 静态测试：被测程序不在机器上运行，采用人工检测和计算机辅助静态分析的手段对程序进行测试，包括人工检测、计算机辅助静态分析。
• 动态测试：通过运行程序发现错误，一般采用黑盒测试和白盒测试。
  • 黑盒测试：也称功能测试，在不考虑软件内部结构和特性的情况下，测试软件的外部特性。
  • 白盒测试：也称结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。

4. 调试

调试发生在测试之后，从期望表现和实际表现不一致时开始。

目前常用的调试方法有以下五种：

• 试探法：调试人员分析错误的症状，猜测问题所在的位置，一步步试探和分析问题所在。该方法效率低，适用于结构比较简单的程序。
• 回溯法：调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回追踪代码，直到找出问题根源为止。该方法适用于小型程序。
• 对分查找法：该方法主要用来缩小错误范围，直到把故障范围缩小到比较容易诊断为止。
• 归纳法：从测试所暴露的问题出发，收集所有正确、不正确的数据，并分析它们之间的关系，提出假想的错误原因，用这些数据证明或反驳，从而查出错误所在。
• 演绎法：根据测试结果，列出可能的错误原因，分析已有的数据，排除不可能和彼此矛盾的原因。若有多个错误同时存在，就要重新分析，提出新的假设，直到发现错误为止。

6. 软件项目管理

1. 项目管理涉及的范围

有效的软件项目管理集中在以下四点：人员（person）、产品（product）、过程（procedure）、项目（project）。

• 人员：参与项目的人员类型有项目管理人员、高级管理人员、开发人员、客户、最终用户。
• 产品：开展项目计划之前，应先进行项目定义，即定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术、管理约束等。
• 过程：对于软件项目来说，强调的是对其进行过程控制，通常将项目分解为任务、子任务等。
• 项目：常识的软件项目办法有明确目标及过程、保持动力、跟踪进展、作出明智的决策、进行事后分析

2. 项目估算

常用的估算方法有三类：基于已完成的类似项目、基于分解技术、基于经验估算模型。

成本估算常用方法：

• 自顶向下：参照之前的总成本推算，并按阶段、步骤分配
  • 优点：估算工作量小、速度快
  • 缺点：会忽视低级别上的引起成本增加的技术困难
• 自底向上：将待开发软件细分，估算子任务的工作量，再加起来
  • 优点：交给负责人估算，结果较准确
  • 缺点：会忽视子任务间交流和系统级工作量，造成结果偏低
• 差别估算方法：将待开发项目与已完成项目比较，估算不同之处成本，计算待开发项目成本
• 专家估算：依靠专家进行估算
  • 缺点：准确性依赖于专家经验
• 类推估算：类推相似项目或相似子模块成本，进行自顶向下或自底向上估算
• 算式估算：通过理论导出或经验导出：
  • COCOMO 估算模型：通过静动态变量公式，进行估算
  • COCOMOⅡ 估算模型
  • Putnam 估算模型：动态多变量模型

3. 进度管理

1. 进度管理的基本原则

• 划分：项目必须要被划分成若干个可以管理的活动和任务。
• 相互依赖性：划分后的各个活动之间的依赖关系必须是明确的，如有的任务必须按顺序完成，有的任务可以并发进行，有的任务只能在其他活动完成后才能开展，有的任务则可以独立进行。
• 时间分配：必须为每个任务规定开始和结束时间。
• 工作量确认：每个项目都有预定的人员参与，项目管理者在任何时间节点中所分配的人员数量不能超过项目团队的总人数。
• 确定责任：为每个任务指定特定的团队成员进行负责。
• 明确输出结果：每个任务都要有一个明确的输出结果，如一个可交付的工作产品。
• 确定里程碑：每个任务或任务组都应该与一个项目里程碑相关联，当一个或多个工作产品经过质量评审并得到认可时，标志着一个里程碑的完成。

2. 进度安排

为了监控项目的进度计划和实际的进展情况，也为了表示各项任务之间进度的相互依赖关系，需要采用图示的方法。

常用的方法有甘特图（Gantt Chart）和项目计划评审技术图（PERT）。

4. 软件项目组织

开发组织采用什么形式，不仅要考虑到项目的特点，还要考虑参与人员的素质。

软件项目组织的原则有：①尽早落实责任；②减少交流接口；③责权均衡。

组织结构的模式，根据项目的分解和过程的分解，软件项目有以下三种组织形式：

• 按项目划分的模式。将开发人员组织成项目组，项目组成员共同完成项目的所有任务，如项目的定义、需求分析、设计、编码、测试、评审等，甚至还包括项目的维护
• 按职能划分的模式。按软件过程中所反映的各种职能将项目参与者组织成相应的专业组，如开发组、测试组、质量保证组、维护组等
• 矩阵模式：该模式是上述两种模式的组合，它既按职能来组织相应的专业组，又按项目来组织项目组

5. 软件项目配置管理

软件配置管理（SCM）用于整个软件工程，主要目标是识别变更、控制变更、确保变更正确实现、报告有关变更。

1. 基线

基线即软件生存周期中各个开发阶段的一个特定点，作用是将各阶段的工作划分得更加正确。

2. 软件配置项

软件配置项（SCI）是配置管理的基本单位，对已经成为基线的 SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。

3. 版本控制

版本控制实际上是一个动态的概念，一方面随着软件生存周期向前推进，SCI 的数量在不断增加，一些文档经过转换生成另一些文档，并产生一些信息；另一方面又随时会有新的变更出现，形成新的版本。

4. 变更控制

软件工程中的变更都会引起软件配置的变更，必须要对变更进行严格的控制和管理。配置数据库有：开发库、受控库、产品库。

6. 软件项目风险管理

1. 软件风险

软件风险包括两个特性：不确定性和损失。

• 不确定性是指风险可能发生也可能不发生；
• 损失是指风险发生后会产生恶性后果。

常见的商业风险有：市场风险、策略风险、销售风险、管理风险、预算风险。

2. 风险识别

当识别出已知风险和可预测风险后，项目管理者首先要做的是尽可能回避这些风险，在必要时控制这些风险。

风险因素可以定义为：性能风险、成本风险、支持风险、进度风险。

3. 风险预测

风险预测又称为风险估计，它试图从两个方面评估一个风险：

• 风险发生的可能性或概率
• 风险发生后所产生的后果

4. 风险控制

应对风险最好的办法是主动地避免风险，即在风险发生前分析引起风险的原因，然后采取措施避免风险的发生。

7. 软件项目质量管理

1. 软件质量特性

1. ISO/IEC 9126 软件质量模型

在 ISO/IEC 9126 中，软件质量模型由三个层次组成，第一层为质量特性，第二层为质量子特性，第三层为度量指标。

2. McCall 软件质量模型

McCall 软件质量模型给出了一个三层模型框架，第一层为质量特性，第二层为评价准则，第三层为度量指标。

2. 软件质量保证

在软件质量方面强调三个要点：①软件必须满足用户规定的需求；②软件应遵循规定标准所定义的一系列开发准则；③软件还应满足某些隐含的需求。

软件质量保证包括七个主要活动相关的各种任务：①应用技术方法；②进行正式的技术评审；③测试软件；④标准的实施；⑤控制变更；⑥度量；⑦记录、保存和报告。

3. 软件评审

软件评审的内容包括以下三个方面：

• 设计质量的评审。包括评审软件的规格说明书是否符合用户的要求；评审可靠性；评审保密措施的实施情况；评审操作特性的实施情况；评审性能；评审软件是否具有可修改性、可扩充性、可互换性和可移植性；评审软件可测试性；评审软件可复用性。
• 程序质量的评审。从开发者的角度进行评审，与开发技术直接相关，着眼于软件本身的结构与运行环境的接口，以及变更带来的影响。
• 与运行环境的接口。运行环境包括硬件、其他软件和用户，主要检查项目与硬件的接口、与用户的接口。

4. 软件容错技术

提高软件质量和可靠性的技术大致分为两类：避开错误和容错技术。

实现容错的主要手段是冗余，常见的冗余技术有：

• 结构冗余：又分为静态冗余、动态冗余和混合冗余。
• 信息冗余：为检测或纠正正在运算或传输中的信息错误需外加的一部分信息。
• 时间冗余：以重复执行指令或程序来消除瞬时错误带来的影响。
• 冗余附加技术：为实现上述冗余技术所需要的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等

8. 软件度量

软件度量用于对产品及开发产品的过程进行度量。软件产品、软件过程、资源都具有外部属性和内部属性。

1. 软件度量分类

可分为面向规模的度量、面向功能的度量，或者分为生产率度量、质量度量、技术度量。

1. 面向规模的度量

面向规模的度量主要是通过对质量和生产率的测量进行规范化得到的，而这些量都是根据开发过的软件的规模得到的。

2. 面向功能的度量

面向功能的度量以功能测量数据为规范化值。应用最广泛的面向功能的度量是功能点（FP）。功能点是根据软件信息域的特性及复杂性来计算的。

2. 软件复杂性度量

软件复杂性度量是指理解和处理软件的难易程度。

软件复杂性度量的参数有很多，主要包括：①规模；②难度；③结构；④智能度。

软件复杂性包括程序复杂性和文档复杂性，软件复杂性主要提现在程序复杂性中。

1. 程序复杂性度量

程序复杂性度量的原则包括：

• 程序理解的难度
• 纠错、维护程序的难度
• 向他人解释程的难度
• 根据设计文件编写程序的工作量
• 执行程序时需要资源的程度

典型的程序复杂性度量有 McCabe 环路复杂度量、Halstead 复杂性度量。

1. McCabe 环路复杂度量

以图论为工具，先画程序图，然后用该图环路数作为程序复杂性度量值。

在一个强连通的有向图 G 中，环路数 V(G) 由公式给出：V(G)=m-n+2p。m 是图中弧的个数，n 是节点数，p 是强连通分量。

9. 其他

1. 逻辑覆盖

逻辑覆盖率：语句覆盖<条件覆盖<判定覆盖<条件-判定覆盖<组合覆盖<路径覆盖

• 语句覆盖：使每个可执行语句至少执行一次
• 条件覆盖：使每个判断中的每个条件的可能取值至少满足一次
• 判定覆盖：使每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足
• 条件判定覆盖：使判定条件中的所有可能（条件成立、不成立）至少执行一次取值，同时，所有判断的可能结果（取真，取假），至少执行一次
• 组合覆盖：使所有可能的条件取值组合至少执行一次
• 路径覆盖：覆盖程序中的所有可能执行的路径

2. 项目活动图

• 任务：用图中的箭头表示
• 关键路径：又称最少时间，从开始到结束得所有路径中，所花时间最长的一条为关键路径
• 最早开始时间：指某项活动能够开始的最早时间，即在关键路径上，从开始到该任务的最早执行的时间，加上节点入度任务中最长的
• 最晚开始时间：关键路径的总时间减去反向得出该任务的时间，倒退方式，减去节点出度任务中最短的
• 松弛时间：又称最多延迟执行的时间，关键路径的总时间减去包含该任务的关键路径花的时间

3. 决策表

决策表有四个部分组成：

• 条件桩（Condition Stub）：列出了测试对象的所有条件。一般情况下，列出的条件的次序不会影响测试对象的动作。
• 动作桩（Action Stub）：列出了测试对象所有可能执行的操作。一般情况下，这些执行的操作没有先后顺序的约束。
• 条件项（Condition Entry）：列出针对特定条件的取值，即条件的真假值。
• 动作项（Action Entry）：列出在不同条件项的各种取值组合情况下，测试对象应该执行的动作。

桩	规则/动作	规则1	规则2	规则3	规则4
条件桩	条件1	Y	Y	N	N
条件桩	条件2	Y	N	Y	N
动作桩	动作1		Y	Y	Y
动作桩	动作2		Y	Y	Y
动作桩	动作3			Y

规则数为 n 时，条件数量为 2ⁿ，根据规则来判断动作是否满足，并合并相同动作结果的项目，可得条件组合数。