软件工程知识梳理
第一章 软件工程概述
1.1软件工程（SE）的定义、目的、方法、作用
定义：在将有关软件开发与应用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件的理论和技术工程的方法学，以及一些开发和维护软件的方法、过程、原则。是一个系统工程，既有对技术问题的分析与综合，也有对开发过程和参与者的管理。
方法：面向对象模式，结构化模式，基于过程的模式等。
作用：付出较低的开发成本，达到要求的软件功能，取得较好的软件性能，开发的软件易于移植，需要较低的维护费用，能按时完成开发工作，及时交付使用。
1.2开发模式
软件开发的全部过程，活动和任务的结构框架，它能直观的表达软件开发全过程，明
确要完成的主要活动，任务和开发策略。
1.3说明错误、缺陷和失败的含义及联系
错误(error)：是在软件开发过程中人为产生的错误（如：需求说明中的错误，代码中的错误）
缺陷（故障fault）：是在软件功能实现过程中产生的问题；是错误导致的结果，是在软件中一个错误的表现（如：代码写错了导致系统无法启动，一个错误可能产生多个缺陷，静态存在的）
失败(failure)：系统违背了它应有的行为（如：使用者发现某个计算功能算不出结果，是动态存在的）
联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图， 从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。
1.4软件质量应从哪几个方面衡量
1、产品(product)的质量
用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。
2、过程(process)的质量
有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
3、商业(business)环境背景下的质量
(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。
误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。
1.5软件系统的系统组成（系统的要素有哪些）
对象（实体）+ 活动 + 关系 + 系统边界
活动：活动是发生在系统中的某些事情，通常描述为由某个触发器引发的事件，活动通过改变属性把一个事物变成另一个事物。
对象：活动中涉及的元素称为对象。
关系：是指活动与对象之间的关系。
系统边界：即系统包含的功能与系统不包含的功能之间的界限。
1.6现代软件工程大致包含几个阶段及各个阶段的文档
（1）需求分析：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格 说明书》】与复审（所有人）。
（2）系统设计：包括用户界面的设计【《SAD》即《软件系统结构图》：如何制作软 件】与复审（开发者与客户）。
（3）程序设计：包括模块功能算法与数据描述设计【相关文档】与复审（开发者）。
（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。
（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。
（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。
（7）系统测试：按《SRS》对系统总体功能进行测试与复审（开发者与客户）。
（8）系统提交：交付产品【用户手册和操作手册】与复审。
（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。
1.7使现代软件工程实践发生变化的关键因素是什么？
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
1.8什么是重用、抽象等现代软件工程主要概念？
抽象(abstraction)：基于某种层次归纳水平的问题描述。它使我们将注意力集中在问题的关键方面而非细节。
分析、设计方法和符号描述系统：使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
用户界面原型化(prototyping)：建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
软件过程：软件开发活动中的各种组织及规范方法。
重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
第二章 过程与生命周期的建模
2.1什么叫过程，过程的重要性
过程是一组有序的任务，它涉及活动、约束和资源使用的一系列步骤，用于产生某种想要的输出。
过程不仅仅是步骤，过程是步骤的集合，它将步骤组织起来使人们能够生产满足一系列目标和标准的产品。
（1）它强制活动具有一致性和一定的结构。
（2）过程结构允许我们分析、理解、控制和改进组成过程的活动，并以此来指导我们的活动。
（3）它使我们获取经验并把经验传授给他人。
2.2什么是软件生命周期？
软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。
2.3瀑布模型及各阶段文档，优缺点
瀑布模型：瀑布模型线性地安排每一个阶段，将开发阶段描述为从一个开发阶段瀑布般地转换到另外一个阶段，一个开发阶段必须在另一个开发阶段开始之前完成。瀑布模型从一种非常高层的角度描述了开发过程中进行的活动，并且提出了要求开发人员经过的时间序列。
瀑布模型的各阶段文档：
需求分析：《SRS》软件需求规格说明书
系统设计：《SAD》系统设计文档
程序设计：模块功能算法和数据描述文档
编码：源程序和注释
单元测试和集成测试：单元测试报告
系统测试：系统测试报告
验收测试：验收测试报告
运行与维护：维护报告
优点：
（1）它的简单性使得开发人员很容易向不熟悉软件开发的客户作出解释。
（2）每一个过程活动都有与其相关联的里程碑和可交付产品，以便于项目经理评估项目进度。
（3）瀑布模型是最基础的模型，很多其他更复杂的模型实际上是在瀑布模型的基础上的润色，如加入反馈循环以及额外的活动。
缺点：
（2）软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。
2.4什么是原型？
原型是一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。
2.5论述分阶段（阶段化）开发模型的含义、其基本分类和特点（运行系统和开发系统的概念）
含义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。
cycle time(循环时间): 软件开发时整理需求文档时间与系统提交时间之差(P55)
production system(产品系统): 用户正在使用的版本
development system(开发系统): 准备代替现有产品系统的下一个版本
分类：
（1）增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
（2）迭代开发：系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强。
（3）增量式+迭代式结合开发：一个新发布的版本可能包含新功能，并对已有功能做了改进。
特点：
（1）即使还缺少某些功能，但在早期的发布中就可以开始培训。
（2）可以及早为那些以前从未提供的功能开拓市场。
（3）当运行系统出现未预料到的问题时，经常性的发布可以使开发人员能全面、快速地修复这些问题
（4）针对不同的发布版本，开发团队将重点放在不同的专业领域技术上。
2.6螺旋模型的含义、目的、四个象限的任务及四重迭代（四重循环）的含义
//含义：螺旋模型将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
//目的：把开发活动和风险管理结合起来，以将风险减到最小并控制风险。
螺旋模型每次迭代有四个任务，依次是（四个象限）：计划、目标/可选方案、风险评估、开发与测试。
螺旋模型共有四次迭代，依次是（每个象限的四重循环），依次是操作概念、软件需求、软件设计、开发与测试。
每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。当风险确认之后，项目经理必须决定如何消除或最小化风险。
//——— 习题2， 3。
//在所有的软件开发模型中，你认为哪些过程给予你最大的灵活性以应对需求的变更？
①设计对于分析模型应该是可跟踪的：软件的模块可能被映射到多个需求上。
②设计结构应当尽可能的模拟实际问题。
③设计应当表现出一致性。
④不要把设计当成编写代码。
⑤在创建设计时就应该能够评估质量
2.7什么是UP、 RUP、进化式迭代等市场流行的过程模型
UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。
该模型的四个阶段：开始阶段、确立阶段、构建阶段和移交阶段。每个阶段可以进一步划分为多次迭代。该模型的六道核心工序：业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。
RUP（Rational Unified Process），是IBM提出的提供支持和包装的UP模型。统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。
进化式迭代开发（Iterative development）是统一开发过程(RUP)的关键实践。开发被组织成一系列固定的短期小项目。每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试。随着时间和一次次迭代，系统增量式完善。
第三章 计划和管理项目
3.1什么是项目进度？活动？里程碑？项目成本？
项目进度：是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。
活动：项目的一部分，一般占用项目进度计划中的一段时间
里程碑（Milestone）指特定的时间点，标志着活动的结束，通常伴随着提交物。（如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档）
项目成本(project costs)：为支持软件开发而购买软件和工具的开支,用于支持需求分析,设计,编码,测试,处理需求变更等等,另外加上工作量开支。
3.2软件人员应该具备的能力是什么？
（1）完成工作的能力（2）对工作的兴趣（3）开发类似应用的经验（4）使用类似工具或语言的经验（5）使用类似开发环境的经验（6）使用类似技术的经验（7）培训（8）与其他人交流的能力（9）与其他人共同承担责任的能力（10）管理技能
3.3软件项目团队组织的基本结构
(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。
优势：使交流最小化，迅速做出决定
缺点：创造性低；对主程序员要求高，个人主观性强
(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。
一般软件项目的团队组织结构是介于以上两个极端之间的。
(3) 项目组织的结构化
结构化较强的团队：按时完成任务，单工作比较循规蹈矩，项目普通但是功能完备。适合人员较多，项目稳 定性和一致性高，使用较正规的结构。
结构化较弱的团队：不能按时完成任务但是创造性强，涉及大量的不确定性因素时采用较为民主的方法和相关的团队结构
3.4试述COCOMO模型的三个阶段基本工作原理或含义
COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化， 逐渐准确。
在阶段一，项目通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。这时，人们对正在创建的最终产品可能的规模知之甚少，因此COCOMOⅡ用应用点来估算规模。
在阶段二，即早期设计阶段，已经决定将项目开发向前推进，但是设计人员必须研究几种可选的体系结构和操作的概念。同样，仍然没有足够的信息支持准确的工作量和工期估算，但是远比第一阶段知道的信息要多。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
在阶段三，即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。
3.5什么是软件风险？ 了解主要风险管理活动？有几种降低风险的策略？
概念：软件生产过程中不希望看到的，有负面结果的事件。
方面：风险损失，风险概率（相乘为风险暴露Risk Exposure)，即数学期望）
风险管理活动：
风险评价：风险识别，风险分析，风险优先级分配
风险控制：风险降低，风险管理计划，风险化解。
降低风险的策略：
避免风险（Avoiding the risk）：改变功能和性能需求，使风险没机会发生。比如用 C 语言的程序有内存泄漏的风险改用 Java，避免风险。
转移风险（Transferring the risk）：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。
假设风险（Assuming the risk）：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。
第四章 获取需求
4.1需求的含义是什么？
需求：对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、约束、功能等。
4.2确定需求的过程（获取需求的过程）是什么？
①原始需求获取：客户给出的需求
②问题分析：理解需求并通过建模或模型化方式进行描述
③规格说明草稿：利用符号描述系统将定义规范化表示
④需求核准：开发人员与客户进行核准
⑤软件规格说明（SRS）
4.3举例说明获取需求时，若有冲突发生，如何考虑根据优先级进行需求分类？
（1）必须要满足的需求
（2）非常值得做但是不是必须的需求
（3）可选的需求（可做可不做）
4.4如何使需求变得可测试？
①针对需求确定一种量化的描述方法，避免模糊的表达方式
②将各种指代用词替代为实体的正式名字
③每个名词或事项应在需求文档中给出唯一定义
4.5需求文档分为哪两类？
(1) 需求定义: 完整罗列了客户期望的需求
(2) 需求规格说明（SRS）: 将需求重述为关于要构建的系统将如何运转的规格说明。
4.6什么是功能需求和非功能需求（质量需求）
功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。根据要求的活动来描述需求的行为。（功能需求定义问题解决方案空间的边界）
非功能需求（质量需求）：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、快速的响应时间、易使用性、高可靠性或低维护代价等。
4.7列出类图中各个类间的基本关系
泛化：继承关系，用带三角的实线表示
实现：类和接口的关系，用带三角虚线表示
关联：拥有的关系，一个类知道另一个类的属性和方法，如老师和学生，用带普通箭头的实
线表示，双向拥有则为直线
聚合：整体和部分的关系，部分可以离开整体独立存在，用带空心菱形的实线表示。
组合：整体和部分的关系，部分不能离开整体独立存在，用带实心菱形的实线表示
4.8需求的特征
（1）正确性（2）一致性（3）无二义性（确定性）（4）完备性（5）可行性（6）相关性（7）可测试性（8）可跟踪性
4.9在原型化需求方面，什么是抛弃式原型，什么是进化式原型？
原型化需求的目的：
A: 有的需求难以用文字和符号说明,而原型化的过程可帮助我们找到“好的视觉和感觉”
B：对非功能性需求，可以评价性能和效率
抛弃式原型：仅用于了解问题、探索可行性，并不打算用来作为将来实际提交系统的一部分，而是用完扔掉
进化式原型：用于了解问题，并作为将来准备提交的系统的一部分
这两种技术有时都称为快速原型化，因为它们都是为了回答需求的问题而构建软件。
第五章 设计体系结构
5.1什么是软件体系结构？设计模式？设计公约？设计？
体系结构Architecture:一种软件解决方案，用于解释如何将系统分解为单元，以及单元如何相互关联，还包括这些单元的所有外部特性。
设计模式design pattern：一种针对单个软件模块或少量模块而给出的一般性解决方案，它提供较低层次的设计决策。它是一个共同的设计结构的关键方面，包括对象和实例，角色和协作，责任分配。
设计公约Design Convention:一系列设计决策和建议的集合，用于提高系统某方面的设计质量。当一种设计公约发展成熟时，将会被封装成设计模式或体系结构风格，最后可能被内嵌为一种程序语言结构。
设计Design:将需求中的问题描述转变成软件解决方案的创造性过程。
5.2软件过程中复审的概念，设计复审的重要性
复审定义：检查文档是否满足所有功能及质量需求。
两种设计检验的方法：
(1) 验证verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确
(2)确认validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确 性，强调做的东西正确。
(3)验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想 要的一致。
重要性：
(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流。
(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。
重要性：
1、可以和用户一起检查软件的概要设计。
2、可以向开发者呈现并明确软件的技术设计。
3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。
5.3软件设计过程模型的几个阶段
(1) Modeling 初始建模:尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构风格
(2) Analysis 分析:分析初步的体系结构，主要关注软件系统的质量属性性能、安全性、可靠性等、各种约束等等。关注系统级别决策
(3) Documentation 文档化:确定各个不同的模型视图。
(4) Review 复审:检查文档是否满足了所有需求。
(5) final output输出文档: SAD:Software Architecture Document 软件体系结构文档， 用来和开发团队中其他人员交流系统级别设计决策的有力工具。
5.4三种设计层及其关系
设计分三层：体系结构、代码设计和可执行设计
（1）体系结构将需求格式说明中确定的系统能力与实现这些能力的系统构件关联起来。
（2）代码设计包含算法和数据结构
（3）可执行设计在比代码设计的层次还要低的静态层次处理代码设计，讨论内存分配、数据格式、位模式等
自顶向下设计：首先设计体系结构，然后进行代码设计，最后是可执行设计
5.5什么是模块化？什么是抽象？
模块化：在模块化的设计中，构件清晰地定义了输入和输出，设计目标明确，功能独立，可以做独立测试。
抽象：对细节的隐藏称为抽象，是基于某种归纳水平的问题描述，是我们集中于问题的关系。
5.6论述设计用户界面应考虑的问题
(1)设计界面要注意解决的要素：
①隐喻：可识别和学习的基本术语、图像和概念等
②思维模型：数据、功能、任务的组织与表示
③模型的导航规则：怎样在数据、功能、活动和角色中移动及切换
④外观：系统向用户传输信息的外观特征
⑤感觉：向用户提供有吸引力的体验的交互技术
(2) 文化问题：需要考虑使用系统的用户的信仰、价值观、道德规范、传统、风俗和传说。两种解决方法：
①使用国际设计/无偏见设计，排除特定的文化参考或偏见
②采用定制界面，使不同用户看到额界面
(3) 用户偏爱：为具有不同偏好的人选择备选界面
5.7 耦合与内聚的概念及各个层次划分？
模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。
内聚是软件内部组成成分的关联程度。
耦合指的是两个软件间的关联程度。
耦合的概念，如何分类？
耦合度是指两个软件之间的相互关联程度，耦合程度取决于模块之间的依赖关系的多少，可以划分为紧密耦合、松散耦合和非耦合。模块之间的依赖关系有：一个模块引用另一个模块、模块间传递数据量、某个模块控制其他模块的数量。为了使模块可以独立设计和修改，应尽可能减少耦合度。模块耦合有六个级别，从高到底依次为：
(1) 内容耦合 content：一个模块实际上修改了另一个模块，被修改的模块完全依赖于修改他的模块。可能的情况有：一个模块修改另一个模块内部数据项或代码，或分支转移 到另一个模块。如 goto 语句
(2) 公共耦合 common：不同模块可以从公共数据存储区来访问和修改数据。
(3) 控制耦合 control：一个模块通过传递参数或返回代码来控制另一个模块的活动
(4) 标记/特征耦合 stamp：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制
(5) 数据耦合 data：模块间传递的是数据值，这是最受欢迎的一种耦合。如一个数值被当做参数传递给另一个模块，这个数值在另一个模块中只会参与计算而非控制。
(6) 非耦合 uncoupled：模块相互之间没有信息传递，如两个毫无关系的方法，但是一般完全没有耦合是不现实的。
内聚的概念，如何分类？
内聚度是指模块内部各组成成分（如数据、功能、内部模块）的关联程度，内聚度越高， 模块各成分间相互联系越密切，与总目标越相关。内聚分为低内聚和高内聚。
(1) 偶然内聚 coincidental：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法
(2) 逻辑内聚 logical：模块中各部分只通过代码的逻辑结构相关联， 会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。比如因为有相同的某一个计算步骤而放在 一起的两个没有关系的计算。
(3) 时间内聚 temporal：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。
(4) 过程内聚 procedurally：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关 活动和针对相关目标，如写数据->检查数据->操作数据这一过程
(5) 通讯内聚 communicational：各部分访问和操作同一数据集，如将来自于同一传感器的所有不相干数据取出这一模块
(6) 顺序内聚 sequential：各部分有输入输出关系，操作统一数据集，并且操作有顺序
(7) 功能内聚 functional：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序
(8) 信息内聚 information：功能内聚的基础上调整为数据抽象化和基于对象的设计
第六章 面向对象
6.1什么是面向对象？
是一种软件开发方法，它将问题及其解决方法组织成一系列独立的对象，数据结构和动
作都被包括在其中。
6.2了解OO 设计的基本原则
单一职责原则（SRP）、重用原则、开闭原则（OCP）、里氏替换原则（LSP）、
依赖倒置原则（DIP）、接口分隔原则（ISP）、迪米特法则
6.3了解OO开发有何优势？
（1）语言的一致性。采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案
（2）全开发过程的一致性：从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。
6.4OO开发过程有几个步骤？
面向对象需求分析、面向对象高层设计、面向对象底层设计、面向对象编程、面向对象测试。
6.5面向对象有什么特征？
（1）标识（2）抽象（3）分类（4）封装（5）继承（6）多态（7）持久性
6.6面向对象设计模式
简单工厂模式。工厂方法模式。抽象工程模式。观察者模式。单例模式。桥梁模式。责任链模式。适配器模式。代理模式。策略模式。
6.7接口的三种含义
①程序设计阶段，需要详细说明对象之间起交互作用的接口的特征（操
作签名）②多态意义上的接口，这允许我们利用多态的优点（我们可以只针对基类写出一段
程序，但它可以适应于这个类的家族，因为编译器会自动找出合适的对象来执行操作）实现
多态性的手段又叫做动态绑定③多继承意义上的接口（java 通过实现多接口的形式实现多
继承）
6.8OO 的基本设计方法和技巧
OO 设计是从类图开始的，在需求分析完成之后，我们通过正确分析各个类之间的关系设
计类图（可以通过改进之前制作的概念类图），要遵循 OO 设计原则，采用适当的 OO 设计模式
第七章 编写程序
7.1为什么说编码工作纷繁复杂甚至令人气馁？
（1） 设计人员可能没有处理平台和编程环境的所有特性，易于用图表示的结构和关系
并不是总能直截了当的编写代码。
（2） 编写易于理解的代码
（3） 编写的代码要易于重用
（4） 需要比照着设计进行检查
7.2一般性的编程原则应该从哪三个方面考虑？
（1）控制结构（程序如何传递数据）：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法（程序如何处理数据）：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构（程序如何储存数据）：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。
7.3论述编码阶段实现某种算法时说涉及的问题。
（1）编写更快代码的代价。可能会是代码更加复杂，从而要花费更多的时间编写代码
（2）测试代码的时间代价。代码的复杂度要求有更多的测试用例或测试数据
（3）用户理解代码的时间代价。
（4）需要修改代码时，修改代码的时间代价。
7.4在编程程序内部文档时，除了ＨＣＢ外，还应添加什么注释信息？注意什么？
（1）解释性注释：本段源代码是在做什么的注释。
（2）分解性注释：通过注释将代码分解成多个段。
（3）版本注释：随着时间进行修改的记录。
注意的问题：
1、分段注释
2、注释和代码要一并更改。
3、注释要有意义。
4、一边写代码一边写注释，不要写完代码回过头来添加注释。
内部文档：
（1）头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。
（2）其他程序注释包含：
a. 可以对程序正在做什么提供逐行的解释。
b. 将代码分解成表示主要活动的段，每个活动再分解成更小的步骤。
c. 随着时间进行修改的记录。
（3）有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名
（4）安排格式以增强理解
注意缩进和间隔来反映基本的控制结构。
7.5敏捷方法的大致思想？
含义：以人为核心、迭代、循序渐进。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
敏捷宣言四条原则：个体和交互的价值胜过过程和工具（个人的卓越创意），可以工作的软件胜过面面俱到的文档（文档非软件），客户合作胜过合同谈判，响应变化胜过遵循计划。
上述四条原则反映了敏捷方法的软件过程倾向性
目标：通过尽可能早地、持续地交付有价值的软件使客户满意。
7.6什么是极限编程（Extreme Programming，ＸＰ）？
极限编程是敏捷过程的一种具体形式，提供敏捷方法最一般原则的指导方针。
XP的支持者强调敏捷方法的4个特性（准则）：交流、简单性、勇气以及反馈。
交流是指客户与开发人员之间持续地交换看法；简单性激励开发人员选择最简单的设计或实现来处理客户的需要；勇气体现在今早地和经常交付功能的承诺；在软件开发过程中的各种活动中，都包含反馈循环。例如，程序员一起工作，针对实现设计的最佳方式，相互提供反馈；客户和程序员一起工作时，以完成计划的任务。
7.7什么是派对编程(Pair Programming)？
结对编程属于主要的敏捷开发方法，开发方式是两个程序员共同开发程序，且角色分工明确：一个负责编写程序，另一个负责复审和测试，两个人定期交换角色。
优点：提高生产率和质量，但证据不充分，模棱两可
缺点：会抑制问题求解的基本步骤，扰乱对问题的关注
第八章 测试程序
8.1.了解 产生软件缺陷的原因？
故障：由错误（error）引起的系统内在问题。
(1)软件本身，系统处理大量的状态，复杂的公式，活动，算法等；
(2)客户不清晰的需求；
(3)其他原因，如项目的规模，众多的参与者导致的复杂性。
8.2将软件缺陷进行分类的理由
在编码完程序构件之后，我们通常对代码进行检查，以找出故障并立刻去除它们。当不存在明显的故障时，我们测试程序，通过创造一些条件，是代码不能像计划的那样做出反应，看一看能否发现更多的故障。因此，知道我们正在查找什么类型的故障是很重要的。
8.3几种主要的故障类型
(1)算法故障(algorithmic fault)：由于处理步骤中的某些错误，使得对于给定的输入，构件的算法或逻辑没有产生适当的输出。
(2)计算故障(computation fault)或精度故障(precision fault)：一个公式的实现是错误的，或者计算结果没有达到要求的精度。
(3)文档故障(documentation fault)：文档与程序实际做的事情不一致。
(4)压力故障(stress fault)或过载故障(overload fault)：对队列长度、缓冲区大小、表的维度等的使用超出了规定的能力。
(5)能力故障(capacity fault)或边界故障(boundary fault)：系统活动到达指定的极限时，系统性能会变得不可接受。
(6)时序性故障(timing fault)或协调故障(coordination fault)：几个同时执行或仔细定义顺序执行的进程之间细条不适当。
(7)吞吐量故障(throughput fault)或性能故障(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掌握测试的方法——黑盒、白盒的概念？
黑盒 将测试的对象看作是一个不了解其内容的闭盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每一种输入，观察到的输出与预期的输出相匹配。
定义：测试人员在完全不了解程序内部的逻辑结构和内部特性的情况下，只依据程序的需求规格及设计说明，检查程序的功能是否符合它的功能说明。(备注：1、测试时应该考虑让被测模块完成一切应做的事情, 拒绝一切不应做的事情。2、黑盒测试的参考文档是系统需求、主要文档是系统设计和程序设计阶段文档。若是可重用部件，则是类似系统)
优点：黑盒测试免于受强加给测试对象内部结构和逻辑的约束。更偏向于功能性的测试。
缺点：黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。
没办法总是使用这种方式进行完备的测试。不容易找到具有代表性的测试用例证明所有情况 下功能都正确。
白盒：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。例如，可以设计执行构件内所有语句或所有控制路径的测试用例。
定义：以测试对象的内部结构为基本依据，手工或自动的展开各种测试。
优点：可以测试一个模块的细节。
缺点：该法以模块内部逻辑为依据，当内部逻辑过于复杂时，则不能给出好的或合适的测试用例。有时候，对于大量递归、循环和分支的构件，想要测试完所有的分支也是不现实的。
实际测试中，没有必要把黑盒测试和白盒测试严格的区分开来。具体的测试方法的选择收到很多因素的影响。
8.8什么是单元测试？
将每个程序构件与系统中的其他构件隔离，对其本身进行测试。
8.9什么是走查和检查？
走查：不正式的的代码评审。
检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。
8.10黑盒、白盒方法各自的分类？测试用例的设计和给出方法。
黑盒、白盒方法的分类，各种覆盖方法等。（课件等）
黑盒测试方法：
1、等价分类法：将输入域划分为若干等价类。每一个测试用例都代表了一类与它等价 的其他例子。如果测试用例没有发现错误，那么对应的等价例子也不会发生错误。有效等价 类的测试用例尽量公用，以此来减少测试次数，无效等价类必须每类一个用例，以防止漏掉 可能发现的错误。
2、边界值分析法：在等价分类法中，代表一个类的测试数据可以在这个类的允许范围 内任意选择。但如果把测试值选在等价类的边界上，往住有更好的效果，这就是边界值分析 法的主要思想。
3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。更多的依赖于 测试人员的直觉和经验。
4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种 组合的情况。
白盒测试方法：
逻辑覆盖法
1、语句覆盖：程序的每条语句都要执行一次。
2、判定(分支)覆盖：程序的每个分支都要执行一次。
3、条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
4、条件组合覆盖：要求所有条件结果的组合都至少出现一次。(比如 A&&B，两个条件，那么就有四种条件的组合)
路径测试法
8.12集成测试及其主要方法的分类？（驱动模块、桩模块的概念）
构件驱动程序就是调用特定构件并向其传递测试用例的程序，即代替上级模块传递测试用例的程序。
桩(stub)：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。
分类：
1、自底向上集成
含义：使用这种测试方法的时候，每一个处于系统层次中最底层的构件先被单独测试，接着测试的是那些调用了前面已测试构件的构件。反复采用这种方法，直到所有的构件测试完毕。
先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。
2、自顶向下集成
含义：顶层构件通常是一个控制构件，是独立进行测试的。然后将被测构件调用的所有构件组合起来，作为一个更大的单元进行测试。重复这样的操作直到所有的构件都被测试。
先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。
3、一次性集成
先测试每一个模块，之后将所有模块一并集成。
先测试每一个构件，然后将所有的构件一次性的集成。只适用于小型系统。
4、三明治集成
将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。
8.13传统测试和OO测试有何不同？OO测试有何困难？
(1)测试用例的充分性：对过程语言而言，当系统改变时，我们可以针对改变测试是否正确，并使用原有的测试用例来验证剩余的功能是否同原来一致。但是面向对象的测试中，我们可能需要编写不同的测试用例。
(2)面向对象趋向于小粒度，并且平常存在于构件内的复杂性常常转移到构件之间的接口上。这意味着，其单元测试较为容易，但是集成测试涉及面变得更加广泛。
(3)传统测试和面向对象的测试主要集中在：需求分析和验证、测试用例生成、源码分析和覆盖。
困难：
A: 需求验证缺乏工具支持。（很多时候依赖人工）
B: 测试工具生成的测试用例，处理OO模型中的对象和方法时，其针对性不强。（某些OO关系是测试工具本身搞不清楚其内在逻辑关系的）
C: 传统的测试方法（如环路复杂度等）在评价OO系统的规模和复杂性时，还不是很有效。
D: 对象的交互是OO系统复杂性的根源，传统的测试方法和根据作用有限。
8.14测试计划涉及的几个步骤？
(1)制定测试目标
(2)设计测试计划
(3)编写测试用例
(4)测试测试用例
(5)执行测试
(6)评估测试结果
第九章 测试系统
9.1系统测试的主要步骤及各自含义
(1)功能测试——系统功能需求。根据SRS测试系统功能。
(2)性能测试——其他软件需求。根据SRS测试系统性能。
(3)验收测试——客户需求规格说明书。根据客户的需求定义，由客户和用户一起测试。
(4)安装测试——用户环境。在用户环境下进行测试。
9.2什么是回归测试？
回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。
9.3功能测试的含义极其作用？
含义：测试需求设计（SRS）中提出的功能性需求。
作用：有很高的故障检测概率（因为一项功能测试只面向一小组组件）。
9.4功能测试的基本指导原则？
(1)高故障检测概率；
(2)使用独立于设计人员和程序员的测试小组；
(3)了解期望的动作和输出；
(4)既要测试合法输入，也要测试不合法输入；
(5)制定停止测试的标准；
(6)不能修改系统。
9.5性能测试的含义与作用？
性能测试与需求的质量有密切的关系，需求文档需要足够完备才能确保性能测试的成功进行。因此需求的质量通常可以反映在性能测试的容易度上。
含义：测试非功能性需求。
作用：确保系统的可靠性、可用性和可维护性。
性能测试由测试小组进行设计和执行并将结果提供给客户。
9.6性能测试的主要分类？
压力测试/强度测试(短时间内加载极限负荷，验证系统能力)
容量测试/巨量数据测试(验证系统处理巨量数据的能力)
配置测试(构建测试用例对系统软硬件的各种配置(最小到最大)进行测试)
兼容性测试(测试接口等。如果它与其他系统交互时)
回归测试(如果这个系统要替代一个现有系统时需要进行此测试)
安全性测试：确保安全性需求得到满足。
计时测试：评估涉及对用户的响应时间和一个功能的执行时间的相关需求。
环境测试：考察系统在安装场所的执行能力。
质量测试：评估系统的可靠性、可维护性和可用性。
恢复测试：强调的是系统对出现故障或丢失数据、电源、设备或服务时的反应。
维护测试：为了帮助人们发现问题的根源提供诊断工具和过程的需要。
文档测试：确保已经编写了必需的文档。
人为因素测试：检查设计系统用户界面的需求。
9.7.确认测试概念，确认测试分类？（基准测试和引导测试）
由用户检查软件系统是否满足了他们的需求的测试。
(1)基准测试
由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。
(2)引导测试(课件译)/试验性测试(课本译)
在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。
9.8.什么是alpha测试？β测试？
α测试：在向客户发布一个系统之前，先让来自自己组织机构或公司的用户来测试这个系统。在客户进行实际的试验性测试前，先自己组织团队（或者委托其他团队）测试这个系统。
β测试：客户实际进行测试。
9.9.什么是安装测试？
在用户的系统环境中安装软件并进行测试。以测试可能因为开发环境与用户环境的不同而导致的问题。
9.10什么是系统配置？软件配置管理？ 基线？
系统配置：向特定客户交付的一组系统构件
软件配置管理：开发和测试不同的配置需要配置管理。配置管理控制不同系统配置之间的差别，将风险和错误减少到最低程度。
基线：是指软件文档和其他资料的集合，它们代表了产品在某一时间点的情况(以及其他参考点)。
9.11 什么是可靠性、可用性和可维护性？
可靠性：指一个系统对于给定的时间间隔内、在给定的条件下无失效运作的概率。
可用性：指在给定的时间点上，一个系统能够按照规格说明正确运作的概率。
可维护性：在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。