软件工程软件工程期末知识点总结一篇带你过软工
【软件工程】软件工程期末知识点总结！（一篇带你过软工）
🌈 个人主页：
🔥 系列专栏： 🏀
💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
1. 前言
在进入本篇文章前，大家可以按需求看看另几篇文章：
这几篇文章将让你对软件工程有一个整体的脉络，并在细节上有一定的把控🐮🐮
本文参考书籍： 软件工程 第4版（ ）
本系列为【软件工程】知识讲解部分的延续，重点在于【软件工程】的习题考点的总结归纳。因为是习题考点，因此不同学校存在侧重点不同的情况，本系列仅仅针对山东大学考生，大家可以选择性学习。
【软件工程】系列合集：
1. Chapter01
1.1 SE的定义、目的、方法及作用
- 定义： 软件工程是用系统化、工程化的方法解决软件开发问题，提高软件开发质量的一门技术。系统化、工程化方法结果就是“软件开发规范”，规范里面体现软件开发的固有规律。
- 目的： 提高软件开发质量
- 方法： 面向对象模式、面向过程模式、结构化模式等
- 作用： 帮助开发出较低开发成本，较低维护成本且开发周期较短，但达到软件功能要求，并且充分利用集成环境工具、可以广泛移植到各个工作系统的软件。
1.2 开发模式（ paradigm ）是什么
开发： 开发软件时
模式： 方法、途径或哲学
- 开发模式是开发软件时特定的方法、途径或哲学。
- 例如面向对象开发有各种模式（MVC模式等）。
- 结构化开发的模式，基于过程的模式，订制的模式（分布式开发模式Hadoop）
1.3 说明错误、缺陷、失败的含义与联系。（请举例说明）
错误：error
缺陷：falut
失败：failure
- 错误： 是软件开发中开发人员所犯的错误，例如需求理解错误，代码编写错误等。
- 缺陷： 是软件功能实现过程中出现的缺陷，是错误导致的结果。例如程序运行报错等。
- 失败： 是系统在运行中违背了应有的行为，例如系统并不能按照需求完成工资计算，工资计算错误。
- 联系： 1、人为原因导致错误，一个错误可能产生多个缺陷，由于缺陷的存在，系统的运行可能失败。2、缺陷是从开发者角度看问题，是系统内部视图；失败是从用户角度看问题，是系统外部视图。3、不是所有故障都会导致失败，故障是静态存在的，但是失败是动态存在的，只要不执行到故障代码，就永远不会失败。
1.4 软件质量应从哪几个方面来衡量？论述之
- 产品质量： 1、用户衡量产品质量是从产品的外部特性出发，如果软件有足够多的功能并且易于使用，则产品质量高，或者虽然难以使用，但是功能强大值得付出，则产品质量高。2、开发者衡量产品质量是从产品的内部特性出发，判断产品内部的缺陷数量和类型来判断产品质量。
- 过程质量： 1、过程质量和产品质量一样重要；2、过程质量直接影响最终产品质量。
- 商业背景下的质量： 1、技术质量和商业质量存在区别。技术质量高，技术价值高不代表商业价值（质量）就高。2、技术质量不会自动转化为商业质量。3、产品目标要将技术价值和商业价值统一起来。
1.5 现代软件工程大致包含的几个阶段及各个阶段文档。
核心思想：
1、对工程化软件开发的考察。
2、九大阶段
- 需求分析：对问题定义和可行性进行分析，得到 需求规格说明书（SRS）
- 系统设计：包括系统体系结构设计等，得到 软件体系结构图（SAD）
- 程序设计：设计程序中的每一个模块的算法和数据结构，得到 算法与数据描述相关文档
- 程序实现：完成编码与文档编写，得到 源代码和注释
- 单元测试：测试模块功能和性能，得到 模块功能/性能测试报告
- 集成测试：测试模块间的交互功能，得到 集成测试报告
- 系统测试：进行系统的功能测试、性能测试、验收测试、安装测试，得到 总测试报告
- 系统验收：将系统交付给用户，提交 用户操作手册
- 系统维护：维护软件原功能或满足新需求，得到 维修报告
1.6 使现代SE实践发生变化的（七个）关键因素是什么？
五个角度： 时间、预算、开发环境、程序运行环境、瀑布模型的不可预测性
- 产品从研发到投入商用的时间越来越短。
- 计算经济学发生变化，硬件越来越便宜，但是开发服务成本越来越高。
- 互联网和物联网的普及。
- 面向对象技术的出现和采用。
- 强大的桌面计算平台的可用性。
- 丰富的图形化用户界面。
- 瀑布模型的不可预测性（沿用大规模工业制造的思想，不再满足灵活性和适应性要求）
1.7 什么是软件过程？软件过程的重要性是什么？包含几个阶段？
过程： 一系列有序任务的集合，涉及活动、资源和约束。
软件过程： 软件开发中的过程
定义： 软件过程就是 软件开发活动中的各种组织和规范方法 。
重要性： 1、强制软件开发活动具有一致性和结构性；2、过程具有结构性允许我们分析、理解并改进过程，来指导活动；3、软件开发活动有一致性和结构性更有利于获取经验并传授他人。
几个阶段： 软件过程也叫做软件开发过程，也就是软件生存周期。它描述了软件从概念到实现、交付使用和维护的整个过程
1.8 什么是重用、抽象等现代软件工程主要概念？
测度和度量： 衡量产品过程的特性
- 抽象： 基于某种层次看待问题，使我们将注意力集中在问题的关键方面。
- 分析设计方法和符号描述系统： 程序设计中选用合适的设计方法，同时利用符号描述系统（UML）对需求分析、程序设计等过程进行描述。
- 软件过程： 软件开发活动中的各种组织方式以及规范方法。
- 软件体系结构： 系统设计就是设计软件体系结构，定义一系列模块结构及其相互关系来描述软件系统。
- 重用和复用： 重复采用以前开发的软件系统中具有共性的部件。
- 用户界面原型化： 建立用户界面的小型版，用于用户和开发员共同研究、探索可行性与改进方案。
- 测度和度量： 通过评价方法和体系，让过程和产品的特性更加可见，包括量化描述系统等。
- 工具和集成环境： 通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于 工具的比较集中于小的活动集，例如测试或设计 。（有测试工具和设计工具）
2. Chaoter02
2.1 瀑布模型各阶段及各阶段文档的关系，优缺点？
各阶段及各阶段文档的关系：
- 瀑布模型线性安排各个阶段，想要开始下一个阶段就必须要完成上一个阶段的任务，进入下一个阶段任务就不能返回上一个阶段。
- 瀑布模型各阶段的文档之间需要相互转化，并且瀑布模型是文档驱动的。
优点：
- 瀑布模型作为软件过程相对简单，容易向用户解释。
- 瀑布模型是最基础的模型，很多其他模型都是在其基础上改进得到的。例如V模型、原型瀑布模型等。
- 瀑布模型每一个阶段都有一个 可交付产品 ，作为里程碑 便于项目经理评估项目进度 。
缺点：
- 瀑布模型像瀑布一样的过程开发，不能从下阶段返回上一阶段，要求开发人员和用户对问题需要理解的非常充分。但是实际上在项目开发早期，这是不现实的，项目开发需要迭代式进行。
- 软件开发是一个创造过程，不是一个制造过程，因此需要不停迭代修改。瀑布模型无法处理实际软件开发中的重复开发问题。
- 瀑布模型会产生可交付产品，这些产品很多是文档。不同文档之间的转化比较复杂，例如需求文档向设计文档的转化。
2.2 原型的概念与用途
- 概念：一种 部分开发 的产品。
- 用途：用来 让用户和开发者共同研究，提出意见，为最终产品定型 。
原型化： 制作原型的子过程
2.3 V 模型与瀑布模型的区别
- V模型更关注活动以及其正确性，瀑布模型更关注文档和可交付产品。
- V模型允许软件过程中存在迭代和重复动作，瀑布模型并没有。
2.4 论述分阶段开发模型的含义, 其基本分类及特点是什么？
定义： 系统被设计成部分提交，用户每次只能得到系统的一部分，其他的正处于开发过程中。分阶段开发模型中衡量模型的一个因素就是 循环时间 。循环时间是指 软件开发时整理需求文档时间与系统提交时间之差。
基本分类及其特点：
- 增量开发： 系统按照功能被分成不同的部分，每次开发其中的一部分。再在后续的开发中为原本的系统添加新的功能，最后得到的是一个拥有全部功能的子系统集。
- 迭代开发： 系统开始提供完整功能的一个基本框架，每一个功能都有涉及。在后续版本中陆续加强各个子系统，最后得到的是一个各个功能都得到加强至最强的子系统集。
- 迭代增量式开发： 将增量开发和迭代开发相结合：一个新发布的版本可能包含新功能，并对已有功能做了改进
2.5 四个象限的任务及四重循环的含义？
四个象限任务：
- 计划
- 目标/可选方案
- 风险评估
- 开发与测试
四重循环，四重循环意味着四轮迭代：
- 操作概念
- 软件需求
- 软件设计
- 开发与测试
每一次迭代都给出计划以及可选方案，并根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。
2.6 什么是敏捷方法？以及其代表性方法？
定义： 是一种较新型软件开发方法。不要求遵循传统的软件开发流程，强调快速开发和有效适应需求变化，典型代表如极限编程、测试驱动开发等。
新型软件开发方法、快速开发、适应需求变化
2.7 在所有的软件开发过程模型中，你认为哪些过程给予你最大的灵活性以应对需求的变更？
- 敏捷开发
（和史清华老师沟通后，待更新~~~）
2.8 什么是UP， RUP，进化式迭代等市场流行的过程模型?
统一过程（up）： 用例驱动、以基本架构为中心、迭代式和增量性的软件开发过程框架。它使用对象管理组织的 UML 并与对象管理组织的 软件过程工程原模型 等相兼容。统一过程将重复一系列生命期，每个生命期都以向客户提供一个产品版本而结束，每个周期包括：开始阶段、确立阶段、构建阶段和移交阶段。
RUP ： 是 Rational 公司开发和维护的过程产品。它完全兼容UP，但比UP更加完整、详细。它提供了 在开发组织中分派任务和责任的纪律化方法 。
进化式迭代开发： 是统一开发过程(RUP)的关键实践。开发按照RUP的规则被组织成一系列固定的短期小项目。同时每次迭代都产生经过测试、集成并可执行的 局部系统 。每次迭代都具有各自的需求分析、设计、实现和测试。随着时间和一次次迭代，系统增量式完善。
3. Chapter03
3.1 什么是项目进度？活动？里程碑？项目成本？
项目进度： 项目进度是对特定项目的软件开发周期的刻画。包括对项目阶段、活动、步骤的分解，对离散活动之间相互关系的描述，以及对各个活动完成时间及整体项目完成时间的初步估算。
活动： 项目的一部分，一般占用项目进度中的一部分时间。
里程碑： 特定时间点，标志活动的结束，通常伴随着交付产品。
项目成本：
为支持软件开发而购买软件和工具的开支
,
用于支持需求分
析
,
设计
,
编码
,
测试
,
处理需求变更等等
,
另外加上工作量开支。
3.2 如何计算软件项目活动图的关键路径？冗余时间？最早和最迟开始时间？
关键路径（Critical Paths）： 从起点到终点总花费时间最长的路径，即这个项目的最短完成时间，因为如果这条路径无法完成那么整个项目都不能算完成。所以这条路径上的任务耽误一点都会影响最后项目完 成时间。
具体看我的文章：
3.3 软件团队人员应该具备的能力是什么？
工作舒适度（工作合适度）、交流能力、承担责任能力、管理能力
3.4 软件项目团队组织的基本结构？
(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。
优势：
使交流最小化
迅速做出决定
缺点：
创造性低
对主程序员要求高，个人主观性强
(2) 忘我方法制（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。
结构化较强的团队：
按时完成任务，单工作比较循规蹈矩，项目普通但是功能完备。适合人员较多，项目稳定性和一致性高，使用较正规的结构。
结构化较弱的团队：
不能按时完成任务但是创造性强，涉及大量的不确定性因素时采用较为民主的方法和相
关的团队结构。
3.5 试述COCOMO模型的三个阶段基本工作原理或含义
COCOMO 模型的关键在于 针对项目开发的不同阶段 来 设置工作量的衡量标准 ，逐步细化， 逐渐准确。具体公式如下：E = bS^c m(X)
- 原型阶段： 这个阶段仅仅有项目的原型，原型大多也是针对高风险部分（例如用户界面等），整体对项目规模了解较少，因此使用 应用点 来估算项目规模。
- 早期设计阶段： 项目已经开始推进，设计人员已经开始考虑设计方法和体系结构问题，对项目的了解变多了，但是仍然不足以准确估算工作量和工期，因此使用 功能点 来测量项目规模。
- 后期体系结构阶段： 项目推进有一段时间，且已经获得足够多的信息。因此，在这个阶段可以使用 功能点或代码行 来估算规模。
3.6 什么是软件风险？ 了解主要风险管理活动？有几种降低风险的策略？
- 软件风险： 软件开发过程中，不希望看到可能会对软件造成负面结果的事件。
- 风险管理活动： 风险评价+风险控制
- 风险评价： 风险识别、风险分析、风险优先级排序
- 风险控制： 风险降低、风险管理计划、风险化解
降低风险策略： 风险降低（避免风险、转移风险、假设风险）、风险化解（具体风险及其应对策略，例如产品过大用增量式开发，功能过复杂用迭代式开发，合作问题协调好人员分配，系统兼容问题用原型测试系统等）。
3.7 专家估算法的大致含义？算式估算法的大致含义？
E 为工作量，a,b,c 都为常数，S 是估算的系统规模，X 是一个 x1…xn 维度成本因素的向量，m 是基于该因素的调整因子。
4. Chapter04
4.1 需求的含义是什么?
定义： 对来自用户的关于软件系统的 期望行为的综合描述 ，涉及系统的 对象、状态、约束、功能 等。
4.2 需求阶段作为一个工程，其确定需求的过程是什么？
工程化思想：确定的工程步骤
- 原始需求获取：理解客户的需求。
- 问题分析：理解客户需求后，通过建模等方式描述并进一步分析需求。
- 规格说明草稿：利用符号描述系统，将原始需求转化为系统将如何运转的规格说明。
- 需求核准：开发人员和客户进行核准。
- 软件规格说明：将原始需求转化为系统将如何运转的规格说明。
4.3 举例说明获取需求时，若有冲突发生时，如何考虑根据优先级进行需求分类
- 必须要满足的需求
- 非常值得做但是不是必须满足的需求
- 可选的需求（可做可不做的需求）
4.4 需求文档分为哪两类？
- 需求定义：完整罗列了客户期望的需求（原始需求）
- 需求规格说明（SRS）：将客户的原始需求重述为系统将如何运转的规格说明
4.5 什么是功能性需求和非功能性需求/质量需求？ 设计约束？过程约束？如何区分？
- 功能性需求： 描述系统内部功能或系统与外部功能的交互作用，设计系统输入应对、输出结果、设计约束和过程约束等。
- 非功能性需求： 描述系统必须具备的质量特征，例如系统响应时间、安全性、性能等。
- 设计约束： 已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口等。
- 过程约束： 构建系统的技术和资源限制，涵盖资源、文档等方面。
4.6 了解DFD图（数据流图）的构成及画法。
想要更深入了解DFD图，建议看我的这篇文章：
4.7 如何使需求变得可测试？
只有需求更准确，测试起来才越方便： 正式名称、唯一定义、量化描述
需求可测试——>需求更准确
- 将各种指示代词替换为实体的正式名称。（重名、化名不可以，这些那些不可以）。
- 需求中的每个名词或事项都要在需求文档中给出唯一的定义。
- 针对需求要确定一种量化的描述方法，避免模糊表达。
4.8 在需求原型化方面，什么是抛弃型原型？什么是演化型原型？
5. Chapter05
5.1 什么是软件体系结构？设计模式？设计公约？设计？概念设计？技术设计？
- 软件体系结构： 是系统设计层面上的软件设计，用于设计如何将软件系统分解为单元（模块），以及单元间如何相互联系。
- 设计模式： 一种针对单个模块或少量模块的特定问题的一般性解决方案，包括模块内部以及模块之间的对象实例、协作关系等的设计方式。
- 设计公约： 一系列设计决策和建议的集合，用于提高软件设计质量。当其成熟时会被封装成设计模式或体系结构风格，甚至内嵌为一种程序语言结构。
- 设计： 将需求中的问题转化为软件解决方案的创造性过程。
- 概念设计： 告诉用户系统将做什么（宏观层面的软件结构和功能）（系统设计）。
- 技术设计： 告诉开发人员系统将怎么做（微观层面软件接口和功能如何实现）（程序设计）。
5.2 软件设计过程模型的几个阶段？
- 软件设计过程 不是 软件过程
- 软件设计过程 是 软件设计的过程
- 软件设计 分为 系统设计 + 程序设计
- 程序设计没有固定过程，因此软件设计就是指系统设计
- 建模：尝试可能的分解，根据需求将系统分解为不同的模块，确定软件体系结构风格。
- 分析：分析软件体系结构，主要关注它的性能、安全性、可靠性等。
- 文档化：根据软件体系结构模型，确定各个不同的模型视图
- 复审：检查文档是否满足所有需求。
- 体系结构说明书（SAD）：软件体系结构文档，用来指导开发团队人员的开发。
5.3 论述设计用户界面应考虑的问题。
分为 针对性问题 以及 一般问题 。
- 文化问题： 考虑宗教、价值观、文化等影响。解决方案有：1、采用通用设计（无偏见设计）；2、采用定制界面，为不同用户设计不同界面。
- 用户偏好： 为不同偏好的人准备备选界面
- 一般性影响因素： 思维模型、模型导航、隐喻、外观、感觉
5.4 三种设计层次及其关系
三种设计层次：
(1) 体系结构设计，相当于系统设计，将 SAS 中确定的系统能力和实现这些能力的系统构件关联起来。
(2) 代码设计 code：各个构件/模块的算法和数据结构设计。
(3) 可执行设计 executable：最底层的设计，包括内存分配，数据格式、位模式等。
关系：
- 这是一种自顶向下的设计，首先设计体系结构，然后进行代码设计，最后是可执行设计
- 三者之间具有可重复性，可以多次修改。
5.5 耦合与内聚的概念及各个层次划分？
耦合度 是指两个模块之间的相互关联程度，模块间相互依赖关系越多则模块的耦合度也就越高。
内聚度 是指模块内部各个部分之间的相互关联程度，模块内各部分的关系越密切则内聚度越高。
耦合度分为六个层次：
- 内容耦合：修改一个模块实际上修改了另一个模块，被修改的模块完全依赖于修改他的模块。如 goto 语句
- 公共耦合：不同模块可以从公共数据存储区来访问和修改数据。
- 控制耦合：一个模块通过传递参数控制另一个模块的活动（重点在于控制而不仅仅是数据参与计算）
- 特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。
- 数据耦合：模块间传递的是数据值，这是最受欢迎的一种耦合。如一个数值被当做参数传递给另一个模块，这个数值在另一个模块中只会参与计算而非控制。
- 非耦合：模块相互之间没有信息传递，如两个毫无关系的方法，但是一般完全没有耦合是不现实的。
内聚度分为八个层次：
- 偶然内聚：模块各部分并不相关，仅仅因为偶然性放在一起。
- 逻辑内聚：模块中各部分存在逻辑关联，共享代码结构等。例如因为两个模块有相同计算部分，就把相同部分整合在一起。
- 时间内聚：模块中各部分要求同一时间完成或被同一任务使用。比如打开某文件的各个操作。
- 过程内聚：模块中的各部分要求按照某种特定的顺序去执行一系列的功能，各部分放在一起仅仅是为了保证过程的先后顺序。例如写模块需要打开文件夹——写数据——检查数据。
- 通讯内聚：模块中各部分访问同一个数据集。
- 顺序内聚：模块中各个部分之间存在输入输出的先后关系，同时操作同一个数据集。
- 功能内聚：理想情况，模块中各个部分组成一个单一的功能，且在功能实现过程中，每一个部分都是必须的。
- 信息内聚：在功能内聚的基础上加上面向对象和数据抽象化。
5.6 软件过程中复审的概念，设计复审的重要性。
复审针对的是软件体系结构设计中产生的体系结构文档
复审： 检查体系结构文档是否满足所有需求
复审包括：
- 验证（verification）：针对开发者，检查设计是否遵循良好的设计原则和设计模式，重点在于对软件开发过程的检查。
- 确认（validation）：针对用户，检查设计后得到的软件产品在最终的运行环境上是否达到目标要求，重点在于软件结果的正确，不太在乎软件开发过程的正确性。
- 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和 用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想 要的一致。
复审的重要性：
- 复审中的讨论是忘我的，能够促进开发人员之间的交流，提高团队内部的凝聚力。
- 复审中发现故障改正比交付后更容易。
6. Chapter06
6.1 什么是面向对象？OO有几个基本特征？
定义： 面向对象是一种软件开发方法，它将问题及其解决方法组织成一系列的独立对象，数据结构和动作都包含在其中
基本特征：
- 标识：确定对象身份，将对象和对象之间区分开。
- 抽象：用层次化的思想描述对象。
- 分类：将在属性和行为上有共同点的对象分为一类。
- 封装：把对象的行为和属性隐藏起来。
- 继承：根据对象的相同点和不同点有层次地组织对象。
- 多态：允许不同类的对象对同一个函数做出不同响应。
- 持久性：持久对象不会随着创建它的进程结束而消亡（因为在外存中存贮）。
6.2 什么是设计模式？
设计模式是针对单一模块或少数模块解决特定问题的一般性方法，用来提高软件设计质量，设计对模块内部的对象、动作和相互关系等的设计。
6.3 了解OO设计的基本原则？
- 单一职责原则
- 重用原则
- 接口隔离原则
- 迪米特法则
- 依赖倒置原则
- 替换原则
- 开闭原则
6.4 了解OO开发有何优势？
- 语言一致性： 采用相同语义结构（类、对象、接口、属性和行为）来描述事物和解决方案。
- 全开发过程一致性： 从需求分析到设计到编码和测试，所有过程都采用相同的语义结构。
6.5 OO开发过程有几个步骤？
总共有五大步骤！！
- OO需求分析和定义
- OO高层设计
- OO底层设计
- OOP
- OO测试
6.6 掌握 用例图的组成和画法，用例的几个要素的含义。
用例图： 表示一个用户、外部系统或其他实体和开发系统的关系
用例图的几个要素：
- 执行者：和开发系统交互的实体，例如用户、外部系统或其他实体，用小人表示。
- 用例：开发系统提供的特定功能，用椭圆表示。
- 包含：对已定义用例的复用，用来提取公共行为，表示一个用例无论如何都会包含另一个用例的行为，是强依赖的。
- 拓展：表示一个用例的行为可以在某些条件下被扩展，通常用于增加可选的、附加的功能或行为。
具体见下面文章：
6.7 熟悉 类图中各个类之间的基本关系分类及其含义.
- 继承
- 实现
- 依赖
- 关联
- 聚合
- 组合
具体见下面文章：
6.8 掌握 顺序图的含义及画法。
具体见下面文章：
7. Chapter07
7.1 为什么说编码工作是纷繁复杂甚至令人气馁？
- 设计人员需要适应工具和集成环境的使用
- 从图表到代码的转化并不是很容易，例如SRS、SAD到代码有时候需要花费比较大的代价。
- 代码从设计方法、设计模式上要求高。
- 代码需要和需求等进行比对检查。
- 代码要求易于理解。
7.2 一般性的编程原则应该从哪三个方面考虑？
- 数据结构： 编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操 作才能简明易懂。
- 算法： 在编写代码时，程序设计通常会制定一类算法，用于编写组件。
- 控制结构： 当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的 面向对象设计中，控制是基于系统状态和变量而变化的。
7.3 在编写程序内部文档时，除了HCB外，还应添加什么注释信息？注意什么？
程序内部文档需要有的注释信息：
- HCB头注释块： 将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。
- 其他程序注释： a. 可以对程序正在做什么提供逐行的解释。b. 将代码分解成表示主要活动的段，每个活动再分解成更小的步骤。
需要注意的有：
- 有意义的变量名和语句标记： 命名时尽量用有意义的变量名进行命名
- 安排格式增强理解： 注意缩进和间隔来反映基本的控制结构。
7.4 敏捷方法的大致思想？什么是极限编程(XP)? 以及派对编程？
敏捷方法：
是一种较新型软件开发方法。不要求遵循传统的软件开发流程，强调快速开发和有效适应需求变化，典型代表如极限编程、测试驱动开发等。
- 个体和交互胜过过程和工具
- 响应变化胜过遵循规则
- 客户合作胜过合作谈判
- 可运行的软件胜过面面俱到的文档
极限编程(XP)：
极限编程是敏捷开发的一种具体方法，深受大家喜爱。其核心思想有：
- 交流：是指客户与开发人员之间持续地交换看法；
- 简单性：激励开发人员选择最简单的设计或实现来处理客户的需要；
- 勇气：体现在尽早地和经常交付功能的承诺；
- 反馈：在软件开发过程中的各种活动中，都包含反馈循环。
派对编程：
派对编程是敏捷开发的一种具体方法，开发方式是两个程序员共同开发程序，且角色分工明确：一个负责编写程序，另一个负责复审和测试，两个人定期交换角色。
- 优点：提高生产率和质量，但证据不充分，模棱两可
- 缺点：会抑制问题求解的基本步骤，扰乱对问题的关注
8. Chapter08
8.1 了解产生软件缺陷的原因？
- 客户不清晰的需求。
- 软件本身复杂，状态、活动等很多。
- 其他原因，如项目规模、众多参与者参加。
8.2 将软件缺陷进行分类的理由？
知道正在处理的是什么类别的故障对于我们具体的测试，以及之后的故障改正都是有很大帮助的。
8.3 有几种主要的缺陷类型？
(1) 算法故障(algorithmic fault)： 由于处理步骤中的某些错误，使得对于给定的输入，构件的算法或逻辑没有产生适当的输出。
(2) 计算故障(computation fault)或精读故障(precision fault)： 一个公式的实现是错误的，或者计算结果没有达到要求的精度。
(3) 文档故障 (documentation fault)： 文档与程序实际做的事情不一致。（倾向于相信文档）
(4) 过载故障(overload fault)： 对队列长度、缓冲区大小、表的维度等的使用超出了规定的能力。（数据上不可接受）
(5) 能力故障(capacity fault)： 系统活动到达指定的极限时，系统性能会变得不可接受。（用户数量、活动数量不可接受）
(6) 时序故障(timing fault)： 几个同时执行或仔细定义顺序执行的进程之间细条不适当。
(7) 性能故障(performance fault)： 系统不能以需求规定的速度执行。
(8) 恢复故障(recovery fault)： 当系统失效时，不能表现得像设计人员希望的或客户要求的那样。
(9) 硬件和系统软件故障(hardware and system software fault)： 当提供的硬件或者系统软件实际上并没有按照文档中的操作条件或步骤运作时。
(10) 标准和过程故障(standards and procesure fault)： 代码没有遵循组织机构的标准和过程。
8.4 什么是正交缺陷分类？
定于： 正交缺陷分类是对缺陷分类方法的一个基本要求。如果缺陷都只属于一种分类，则该分类方案是正交的，如果一个缺陷属于多个分类，则分类就失去了意义
8.5 测试的各个阶段及其任务？涉及的文档？
文档：
- 单元测试：模块代码
- 集成测试：设计文档（系统设计文档和程序设计文档）
- 功能测试：系统功能需求文档
- 性能测试：其他软件需求文档
- 验收测试：用户需求定义
- 安装测试：用户环境
- 系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。
任务：
(1)模块测试(module testing)、构件测试(component testing)或单元测试(unit testing)：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。
(2)集成测试(integration testing)：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。
(3)功能测试(function test)：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。
(4)性能测试(performance test)：测试系统的软硬件性能是否符合需求规格说明文档。其结果是一个确认的系统。
(5)验收测试(acceptance test)：确定系统是按照用户的期望运转的。
(6)安装测试(installation test)：确保系统在实际环境中按照应有的方式运转。
(7)系统测试(system test)：功能测试、性能测试、验收测试和安装测试统称为系统测试。
8.6 测试的态度
- 将测试看作一个发现的过程。
- 测试不仅仅要关注程序作为问题解决方案，也要关注问题本身。
- 出现问题不要责怪某个开发人员，而是专注于修复故障。
8.7 掌握 测试的方法—-黑盒、白盒的概念？
黑盒：
- 等价分类法：将输入域划分为若干等价类。每一个测试用例都代表了一类与它等价 的其他例子。如果测试用例没有发现错误，那么对应的等价例子也不会发生错误。有效等价 类的测试用例尽量公用，以此来减少测试次数，无效等价类必须每类一个用例，以防止漏掉 可能发现的错误。
- 边界值分析法：在等价分类法中，代表一个类的测试数据可以在这个类的允许范围 内任意选择。但如果把测试值选在等价类的边界上，往住有更好的效果，这就是边界值分析 法的主要思想。
- 错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。更多的依赖于 测试人员的直觉和经验。
- 因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种 组合的情况。
白盒：
- 语句(覆盖)测试：在某次测试中，构件中的每条语句至少执行一次。
- 分支测试：对代码中的每个判断点，每个分支在某次测试中至少选择一次。（ 每个分支都有一次就可以，不两两都组合过 ）。
- 路径测试：通过代码的每一条不同路径在某个测试中至少执行一次。（ 不仅每个分支都要走过一次，而且两两都要组合过 ）
- 条件测试：不仅要把判断中的每一个分支都走一次，并且判断内部的条件的真假组合也要都覆盖。
对于这个图：
语句覆盖：选择 X 大于 K 使其产生正的 RESULT，就可以顺序执行 1-2-3-4-5-6-7 语句。
分支覆盖：图中有两个判断点，因此使用两个测试用例分别执行 1-2-3-4-5-6-7 和1-2-4-5-6-1 即可。
路径覆盖：图中可能路径包括：1-2-3-4-5-6-7、1-2-3-4-5-6-1、1-2-4-5-6-7、1-2-4-5-6-1 四条路径。
具体可以看我的文章：
8.8 集成测试及其主要方法的分类？（驱动模块、桩模块的概念）
自底向上的集成：
含义： 使用这种测试方法的时候，每一个处于系统层次中最底层的构件先被单独测试，接着测试的是那些调用了前面已测试构件的构件。反复采用这种方法，知道所有的构件测试完毕。
构件驱动程序：
代替上级模块传递测试用例的程序。
优点： 测试用例比较容易生成；符合面向对象的开发思路。
缺点： 顶层构件通常是最重要的，但是却是最后测试的。主要故障的测试将会推迟到测试的后期。（ 越到后期的故障越难处理 ）。
自顶向下的集成：
含义： 顶层构件通常是一个控制构件，是独立进行测试的。然后将被测构件调用的所有构件组合起来，作为一个更大的单元进行测试。重复这样的操作直到所有的构件都被测试。
桩(stub)：
代替下级模块的仿真程序
优点： 一些功能性的设计故障或主要问题可以在测试的早期进行处理。
缺点：桩不容易编写，桩的正确性可能影响测试的有效性；另一个缺点是可能需要大量的桩。
这个模式下，桩需要能够完美代替下级模块的输出，这要求我们需要知道系统中每一个模块的正确输出，从而完成对上级模块的测试。这就导致测试用例的编写很有难度。
一次性集成：
1.先测试每一个构件，然后将所有的构件一次性的集成。只适用于小型系统
2.缺点：
1、有些构件同时需要桩和驱动程序；
2、一次性集成，很难发现失效原因；
3、很难将接口故障和其他故障区分开。
三明治集成：
含义：将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成。测试集中于目标层。
8.9 传统测试和OO测试有何不同？OO测试有何困难？
- 测试用例的充分性：对过程语言而言，当系统改变时，我们可以针对改变测试是否正确，并使用原有的测试用例来验证剩余的功能是否同原来一致。但是面向对象的测试中，我们可能需要编写不同的测试用例。
- 趋向于小粒度：面向对象趋向于小粒度，并且平常存在于构件内的复杂性常常转移到构件之间的接口上。这意味着，其 单元测试较为容易，但是集成测试涉及面变得更加广泛 。
- 传统测试和面向对象的测试主要集中在： 需求分析和验证、测试用例生成、源码分析和覆盖分析 。
9. Chapter09
9.1 系统测试的主要步骤及各自含义？（图9.2）
- 功能测试——系统功能需求
- 性能测试——其他软件需求
- 验收测试——客户需求规格说明书
- 安装测试——用户环境
9.2 功能测试的含义极其作用？
测试系统在需求设计中的功能性需求。
有很高的故障检测概率（因为一项功能测试只面向一小组组件）。
9.3 功能测试的基本指导原则？
高独预法停不改： 高独想要干预法律，让他停止，他也不改。
- 高故障检测概率。
- 使用独立于设计人员和开发人员的测试人员。
- 了解期望的动作和输出。
- 既要测试合法输入，也要测试不合法输入。
- 指定停止测试标准
- 不能修改系统
9.4 性能测试的含义与作用？
含义： 根据需求设计文档去测试系统的性能，例如响应时间、安全性、可靠性等。
作用：
- 性能测试针对的是非功能需求，它在确保系统的可靠性、安全性等。
- 性能测试与需求质量密切相关，只有需求文档足够完备才能确保性能测试成功。需求质量直接反映在性能测试的容易度上。
9.5 性能测试的主要分类？
- 压力测试(短时间内加载极限负荷，验证系统能力)
- 容量测试(验证系统处理巨量数据的能力)
- 配置测试(测试各种软硬件配置(最小到最大))
- 兼容性测试(如果它与其他系统交互时)
- 回归测试(如果这个系统要替代一个现有系统时)
- 安全性测试
- 计 时 测 试
- 环 境 测 试
- 质 量 测 试
- 恢 复 测 试
- 维 护 测 试
- 文档测试
- 人为因素测试/可使用性测试
9.6 确认测试概念，确认测试分类？（基准测试和引导测试）
确认测试就是验收测试
概念： 用户检查系统是否符合需求定义中的需求
确认测试的分类：
- 基准测试： 由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。
- 引导测试： 在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。
9.7 什么是alpha测试？β测试？
这两个测试是引导测试的方法
α测试： 在向客户发布一个系统之前，开发者自己组织公司成员（或安排测试组织机构）来测试这个系统。在客户进行实际的试验性测试前先试验这个系统。
β测试： 客户的试验称为β测试。
9.8 β测试名词解释：客户的试验成为β测试。
在用户环境中配置系统，以测试可能因为开发环境与用户环境的不同而导致的问题。
10. 总结
本文到这里就结束啦~~，本文是【软件工程】系列的练习题部分。
目前【软件工程】系列的知识讲解部分已经完成：
【软件工程】系列的知识讲解已经更新完毕 🎢🎢🎢
本文算是最后的一个总结~~~
如果觉得对你有帮助，友友们可以点个赞，收个藏呀~
