2023年山东大学软件工程复习

英文版《软件工程》教学内容回顾2023下

(下述问题仅是课件中的主要部分回顾，问题答案以课件为主要参考)

Chapter01  软件工程概述

SE的定义、目的、方法及作用

定义：SE= nature (making the problem clearly) + solution (implement by developing tools)

理解问题的本质，并给出解决方案。即用系统科学的方法解决问题

目的：设计和开发高质量的软件

方法：面向对象模式，结构化模式，基于过程的模式等。

作用：付出较低的开发成本，达到要求的软件功能，取得较好的软件性能，开发的软件易于移植，需要较低的维护费用，能按时完成工作，及时交付使用

// 开发模式（paradiam）

开发软件时特定的方法、途径或哲学

说明错误、缺陷、失败的含义与联系。（请举例说明）

错误error：软件开发过程中人为产生的错误。例如：需求说明中的错误、代码中的错误

缺陷fault：软件功能实现过程中产生的问题，是错误导致的结果，属于功能实现层面。例如：需求说明中的错误导致与意图不符的设计、代码中的错误导致错误的功能实现（一个错误可能产生多个缺陷，故障静态存在于系统之中）

失败failure：系统违背了它应有的行为，在运行时产生的故障，是缺陷导致的结果。例如：需求文档中的缺陷会导致软件运行结果不符合实际需求、代码中的故障导致用户运行时软件坏了（在交付前或之后被发现，动态存在的、面向用户的）

联系：人为原因导致错误；错误编译到系统中导致缺陷（故障）；用户使用系统时由于缺陷导致失败。

缺陷是系统内部视图，从开发者角度看待问题；失败是系统外部视图，从用户角度看待问题。

不是所以故障都会导致失败，只要不执行故障代码活不进入某个特定状态，故障就不会使代码失败。

软件质量应从哪几个方面来衡量？论述之。

产品（product）的质量

用户：从失败的数目和类型等外部特性进行评价。软件具有足够的功能，易于学习和使用

开发者：从缺陷的数目和类型等内部特征进行评价

过程（process）的质量

很多过程都会影响到最终产品的质量，开发和维护过程的质量与产品的质量是同等重要的

量化模型：CMM、ISO 9000、SPTCE

商业（business）环境背景下的质量

1. 技术价值与商业价值的联系与区别
   技术价值：技术指标（速度、正确的运行时间、维护成本等）
   商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。商业价值一般需要在需求阶段预判
   误区：技术质量不会自动转化为商业价值
2. 目标
   将技术价值与商业价值统一起来，改进过程所带来的商业价值

// 软件系统的系统组成。

对象（实体）+ 活动 + 关系 + 系统边界

1. 活动和对象
   activity：活动是发生在系统中的某些事情，通常描述为由某个触发器引起的事件，活动通过改变某一特性把一个事物转变为另一个事物
   object/entity：活动中涉及的元素成为对象或实体
2. 关系和系统边界
   relationship：对实体和活动间数据项及动作相互关系的描述
   system boundary：用于描述系统中包含什么，不包含什么。对于相互关联影响的系统，刻画边界很重要

现代软件工程大致包含的几个阶段及各个阶段文档。
（1）需求分析：问题定义、可行性研究、系统分析【《SRS》软件需求规格说明书】和复审（所有人）

（2）系统设计：用户界面的设计【《SAD》软件系统结构图】和复审（开发者与用户）

1. 程序设计：模块功能算法与数据描述设计【相关文档】与复审（开发者）
2. 程序实现：编程与debug【源代码和注释】与复审（开发者于coder）
3. 单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）
4. 集成测试：按照结构图进行测试【测试报告】与复审（测试团队）
5. 系统测试：按《SRS》对系统总体功能进行测试和复审（开发者与客户）
6. 系统提交：交付产品【用户手册和操作手册】与复审
7. 系统维修：修改软件的过程，为了改错或满足新需求【维修报告】与复审（维修团队）

//使现代SE实践发生变化的（七个）关键因素是什么？

1. 商用产品投入市场时间的紧迫性
2. 计算技术在经济中的转变：更低的硬件成本，更高的开发成本、维护成本
3. 功能强大的桌面计算的可用性
4. 广泛的局域网和广域网
5. 面向对象技术的采用及其有效性
6. 使用窗口、图标、菜单和指示器的图形用户界面
7. 软件开发瀑布模型的不可预测性

什么是软件过程？软件过程的重要性是什么？包含几个阶段？

软件过程是软件开发活动中的各种组织及规范方法

包含九个阶段（见上两题）

重要性（第二章第一题）

什么是重用、抽象等现代软件工程Wasserman所述的主要概念？

1. 抽象：基于某种层次归纳水平的问题描述。它使我们将注意力集中在问题的关键方面而非细节
2. 分析、设计方法和符号描述系统：采用标准的符号表示系统来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用
3. 用户界面原型化：构建系统的小型版本，选取关键的功能进行展示。有利于用户对系统进行评价与选择，帮助我们确认关键需求，证明设计与方法的可行性
4. 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统系统。一个系统可由不同的体系结构来组成
5. 软件过程：软件开发活动中的各种组织及规范方法
6. 重用/复用：重复采用以前开发的软件系统中具有共性的部件，用到新的开发项目中去
7. 测度和度量：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统
8. 工具和集成环境：通过框架比较软件工程提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计

补充：什么是软件危机？表现？原因？

软件危机：落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护中出现一系列严重问题的现象

表现：

1. 对软件开发成本和进度的估计不准确
2. 用户对已完成的软件系统不满意
3. 软件产品的质量不可靠
4. 软件不可维护
5. 软件没有适当的文档资料
6. 软件成本在计算机系统总成本中的比例逐年上升
7. 软件开发生产率提高的速度跟不上计算机应用普及深入的趋势

原因：一方面与软件本身有关，一方面与软件开发和维护的方法有关

1. 软件缺乏可见性，管理和控制软件开发过程有困难
2. 软件规模庞大，程序复杂性随软件规模呈指数上升
3. 开发时期引入错误
4. 软件开发和维护中采用了错误的方法和技术

软件工程的出现是由于软件危机的出现

Chapter02  过程和生命周期建模

什么是软件过程？软件过程的重要性是什么？软件生命周期？

定义：软件开发活动中产生某种期望结果的一系列有序任务，涉及活动、约束和资源。过程不仅仅是步骤，而是步骤的集合

重要性：

1. 通用性：保证开发活动具有一致性和一定的结构，让我们明确地知道自己是否完成了工作，并且能让其他人以相同的方式工作，因而具有相对通用性，有助于保持大量不同人员开发的产品和服务之间的一致性和质量
2. 自我指导性：软件过程可以让我们不断分析、检查、理解、掌控、改进软件开发活动
3. 软件过程有利于我们把经验传授给他人
4. 软件过程会要求我们留下文档、记录，这有助于我们从过往的开发经验中获得最佳实践

软件生命周期是软件开发过程的别称，描述了软件产品从概念到实现、交付、使用和维护的整个过程，包括九个阶段

瀑布模型及各阶段文档，优缺点？

优点：

1. 简单性，易于向用户解释
2. 每个过程活动都有与其相关联的里程碑和可交付产品，以便于项目经理评估项目进度
3. 瀑布模型是最基础的模型，是其他复杂模型的基础，可以在此基础上加入反馈循环以及额外的活动

缺点：

1. 它没有反映实际的软件开发过程，软件是一个创造的过程，不是一个制造的过程。软件变动时，该模型无法处理实际过程中的重复开发问题
2. 文档转换有困难。它只说明了每一个活动的产品（例如需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如从需求文档转化为设计文档）

//原型的概念与用途。

概念：一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型

用途：

1. 将需求或设计进行原型化，让我们可以对其进行改进
2. 将各种可替代的方案原型化，允许我们进行选择

论述分阶段开发模型的含义, 其基本分类及特点是什么？

含义：系统被设计成部分提交，每次用户只能得到部分功能，而其他功能处于开发过程中。

最大优势：使每个软件版本的周期变短

分类：

1. 增量式开发
   系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集
2. 迭代式开发
   系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强性能
3. 增量-迭代融合
   两者结合使用，一个新发布的版本可能包含新功能，并对已有功能做了改进

螺旋模型四个象限的任务及四重循环的含义？

四个象限的任务依次是计划、目标/可选方案、风险评估、开发与测试

共有四次迭代，依次是操作概念、软件需求、软件设计、开发与测试

每一圈是一次迭代，每一个象限代表一次迭代中的某一部分任务

什么是敏捷方法？以及其代表性方法？

敏捷方法强调灵活性在快速有效的软件生产中所发挥的作用，是重量级方法的叛逆者

总体目标：尽可能早的，持续的交付有价值的软件，使客户满意

原则：

1. 个体和交互的价值胜过过程和工具。强调个人价值
2. 可以工作的软件胜过面面俱到的文档。把时间花在软件上而不是文档
3. 客户合作胜过合同谈判。精力集中在与客户协商
4. 相应变化胜过遵循计划。专注于对变化的反应，而不是制定计划

代表方法：

1. Extreme Programming (XP) (极限编程)
   激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派
   四个变量：成本、时间、质量和范围。通过研究变量之间的相互作用，将项目开发分析的更加透彻
   四个准则：
   ①沟通：客户与开发者之间持续的交流意见
   ②简单性：鼓励开发者选择最简单的设计或实现来应对客户的需求
   ③反馈：在软件开发过程中的各个活动中，包含各种反馈循环工作
   ④勇气：尽早的和经常性的交付软件功能的承诺
2. Crystal （水晶法）
3. SCRUM（并列争球法）
4. Adaptive Software Development(ASD) (自适应软件开发)
5. Feature Driven Development(FDD) (特征驱动软件开发)

//------ 习题2， 3

// 针对每一种过程模型，讨论他的优缺点，以及该模型如何处理开发后期重要的需求变化

1. 瀑布模型
   优缺点见上文
   如果严格执行原瀑布模型，那就难以处理后期的需求变化。即使是原型化瀑布，也需要在原型化阶段进行修改
2. V模型
   V模型允许在过程的后半段对前半段进行验证与确认，如果出现问题，应当立刻重新进行对应过程。这允许我们进行补救，后期出现重大需求时可以返回修改
3. 原型化模型
   每阶段都要进行原型化，基于原型的建立确认、评审并构建系统
   优点：各阶段的确认降低了开发的风险和不确定性
   缺点：在软件规模较大时，原型会很复杂
   后期出现需求变更可以进入修订过程，返回调整
4. 阶段化开发模型
5. 螺旋模型
6. 敏捷开发

// 在所有的软件开发过程模型中，你认为哪些过程给予你最大的灵活性以应对需求的变更？

阶段化开发模型和螺旋模型

什么是UP， RUP，进化式迭代等市场流行的过程模型?

统一过程（UP/RUP）

用例驱动的、以基本架构为中心的、迭代式和增量性的软件开发过程框架。是迭代开发的一种具体模型。描述了如何有效利用商业可靠的方法开发和部署，是一种重量级的过程。

进化式迭代

是统一开发过程的关键实践。开发被组织策划那个一系列固定的短期小项目。每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试。随着时间和一次次迭代，系统增量式完善。

Chapter03  计划和管理项目

什么是项目进度？活动？里程碑？项目成本？

项目进度是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间以及整个项目完成时间的初步估算。

项目活动是项目的一部分，一般占用项目进度计划中的一段时间。

里程碑指特定的时间点，标志着活动的结束，通常伴随着提交物（如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档）。

项目成本是为支持软件开发而购买软件和工具的开支,用于支持需求分析,设计,编码,测试,处理需求变更等等,另外加上工作量开支。

如何计算软件项目活动图的关键路径？（习题2，3）冗余时间？最早和最迟开始时间（课堂习题讲解） 见智库P24－25

关键路径

从起点到终点总花费时间最长的路径，即这个项目的最短完成时间，因为如果这条路径无法完成那么整个项目都不能算完成。所以这条路径上的任务耽误一点都会影响最后项目完成时间。

关键路径法（CPM）

时差=可用时间-真实时间=最晚开始时间-最早开始时间
冗余时间

在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值

如何计算：（活动是边，点是里程碑）
Step1：确定每个活动的最早开始时间
一个活动开始的前提是完成它的前置里程碑的所有活动，即一个活动的最早开始时间是到达它的开始节点的所有路径中最长的一个

Step2：确定每个活动的最晚开始时间

一个活动的最晚开始时间，取决于以它到达的里程碑为起点的所有活动中最小的最晚开始时间。

例如：活动ABC都指向结束，到达结束的时间分别为20、18、16，那么项目的结束时间就是20，ABC都只需要在20时刻到达结束就可以，用20减去他们的耗时就是他们的最晚开始时间

// 软件团队人员应该具备的能力是什么？

1. 完成工作的能力
2. 工作兴趣
3. 进行相关工作经验
4. 经过培训
5. 与他人交流的能力
6. 共同承担责任的能力
7. 管理能力

软件项目团队组织的基本结构？

（1）主程序员负责制

主程序员：负责系统的设计和开发，其他成员向其汇报，主程序员对每一个决定有绝对决策权。主程序员监督所有其他小组成员、设计所有程序、把代码开发分配给其他小组成员。

副主程序员（后备程序员）：在必要时替代主程序员。

资料员：负责维护所有的项目文档，编译和链接代码，并对提交的所有模块进行初步测试。

优点：使交流最小化；迅速作出决定
缺点：创造性低；对主程序员要求高，个人主观性强

（2）忘我方法
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人

1. 项目组织的结构化和创造性
   队伍的结构性越强，越能按时完成复杂任务，但创造性就越弱，能给出普通但功能完备的成品，适合规模大的团队解决稳定的任务。
   队伍的结构性越弱，创造性越强，越能对问题给出创造性的解决方案，但是不稳定，容易无法按时完成任务，适合解决有大量不确定因素的问题。

//专家估算法的大致含义？算式估算法的大致含义？

专家估算法：很多工作量估算方法依赖于专家的判断。使用专家的知识和经验，对软件项目的工作量进行评估，预测的精确性基于估算者的能力、经验、客观性和洞察力。是对构建整个系统或其子系统所需的工作量做出的经验性猜测。依赖经验

算式估算法：研究人员创建出了表示工作量和影响工作量的因素之间关系的模型。这些模型通常用方程式描述，其中工作量是因变量，而其他因素是自变量。大部分模型认为项目规模是方程式中影响最大的因素，不直接依赖于经验，而是依赖于算法模型

试述COCOMO模型的三个阶段基本工作原理或含义。

COCOMO模型针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确

阶段一：

项目通过构建原型来解决用户界面、软件、交互、性能、技术成熟度等方面的高风险问题。在这一步中，使用应用点AP来进行规模测量

阶段二：

早期设计阶段，设计者要研究几种可选的体系结构和操作概念。在这一步中，使用需求文档中的功能点FP来进行规模测量

阶段三：

后体系结构阶段，开发已经开始，软件已经被部分构造出来。在这一步中，使用功能点FP或代码量作为衡量标准

什么是软件风险？了解主要风险管理活动？有几种降低风险的策略？

软件风险：软件生产过程中不希望看到的，有负面结果的事件。有两方面：风险损失，风险概率（相乘为风险暴露）

风险管理活动：

风险评价：风险识别、风险分析、风险优先级分配

风险控制：风险降低、风险管理计划、风险化解

策略：

1. 避免风险
   改变功能和性能需求，使风险没机会发生
2. 转移风险
   通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失
3. 假设风险
   假设风险会发生，接受它，并使用资源来控制风险的后果。比如在开发时主动有意识的进行测试

弄懂活动图基本原理（参考课本），找出课后练习题--图3.23和3.24的关键路径。

Chapter04  获取需求

需求的含义是什么?

定义：对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

需求阶段作为一个工程，其确定需求的过程是什么？

1. 原始需求获取：客户给出的需求
2. 问题分析：理解需求并通过建模或模型化方式进行描述
3. 规格说明草稿：利用符号描述系统将定义规范化表示
4. 需求核准：开发人员与客户进行核准
5. 软件规格说明《SRS》

举例说明获取需求时，若有冲突发生时，如何考虑根据优先级进行需求分类。

1. 必须要满足的需求。例如，信用卡转账记录必须被持久保存，并且可以列出，信用卡账单不保存是不可能的
2. 非常值得但非必要的需求。例如，信用卡转账时要能实时发送给用户，这能极大的方便用户，但是这个功能不是必须的
3. 可选的需求。例如，账单根据金额不同用不同的颜色显示

// 如何使需求变得可测试？（sidebar4.4）

1. 针对需求确定一种量化的描述方法，避免模糊的表达方式
2. 将各种指代用词替代为实体的正式名字
3. 每个名词或事项应在需求文档中给出唯一定义

需求文档分为哪两类？

1. 需求定义
   完整罗列了客户期望的需求
2. 需求规格说明（SRS）
   将需求重述为关于要构建的系统将如何运转的规格说明

什么是功能性需求和非功能性需求/质量需求？ 设计约束？过程约束？如何区分？

1. 功能需求
   描述系统内部功能或系统与外部环境的交互作用，涉及系统输入应对，实体状态变化，输出结果，设计约束与过程约束等

它针对的是解决问题的方案和可选方案的边界

1. 设计约束
   已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面

技术层面的

1. 过程约束
   对用于构建系统的技术和资源的限制，涵盖资源、文档等方面

外部要求层面的

1. 非功能需求/质量需求
   描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等

非功能性需求不是用户想让系统完成的事，而是用户希望“完成的有多好”

// 需求的特性？（正确性、一致性、完整性）。

正确性：开发者和客户都应该评审需求文档，确保其正确表达了用户需求

一致性：需求之间不能有冲突，如果两个需求不可能同时满足则破坏了一致性

无二义性：如果需求描述的多个读者都能够一致、有效地解释需求，那么需求就是无二义性的

完备性：指定了所有状态、所有约束下的可能输入对应的输出和必要行为，那么这组需求就是完备的

可行性：需求的解决方案应当切实存在

相关性：不应该有与解决问题本身毫不相关的需求

可测试性：需求应当能被测试证明被满足了

可跟踪性：需求应当被组织好并被唯一标识，以达到易于引用的目的，在需求规格说明中容易找到

了解DFD图的正确性：构成及画法。

数据流图：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

加工：代表会对数据进行操作的行为

数据集合：同类的数据的集合，数据贮存的地方

外部项：数据源或接收者（可理解为实体）

数据流向：线上标注被传递的数据

// 在需求原型化方面，什么是抛弃型原型？什么是演化型原型？

原型化需求原因：用户有时不能确定自己的详细、完整需求；开发者有时无法确定自己的方案是否真实可行；帮助获取需求的更多细节

抛弃型原型：仅用于了解问题，探索可行性，用完扔掉

进化型原型：用于了解问题，并作为将来提交的系统的一部分

// 用DFD图简单描述ATM机的工作原理（主要功能和数据流）（习题7）

补充：UML系列模型

1. 用例图
   用例图着重于从外部执行者角度描述系统需要提供哪些功能，并指明了这些功能的执行者是谁，UML是一种用例驱动的开发方法
   
2. 类图
   描述了系统中的类及其相互之间的各种关系，其本质反映了系统中包含的各种对象的类型及对象间的静态关系
3. 其他图
   （1）包图：包图也存在类图里面的继承、引用等依赖关系，也包含接口，接口与包之间用带小圆圈的实线相连
   （2）序列图：序列图中的对象可以是并发执行的，每一个对象有自己运行的线程控制着。这时，需要通过激活、异步消息、同步控制和活动对象来表示
   （3）部署图：描述了系统在运行时的物理结构、配置和关系，涉及处理器、设备、通讯等硬件单元和软件部件。部署图的描述是基于代表硬件单元的节点之上的
   （4）活动图

Chapter05  设计体系结构

什么是软件体系结构？设计模式？设计公约？设计？ //概念设计？技术设计？

1. 软件体系结构：一种软件解决方案，用于解释如何将系统分解为单元，以及单元如何相互关联，还包括这些单元的所有外部特性
2. 设计：将需求中的问题描述转变为软件解决方案的创造性过程
3. 设计模式：一种针对单个软件模块或少量模块而给出的一般性解决方案，它提供较低层次的设计决策。它是一个共同的设计结构的关键方面，包括对象和实例，角色和协作，责任分配
4. 设计公约：一系列设计决策和建议的集合，用于提高系统某方面的设计质量。当一种设计公约发展成熟时，将会被封装成设计模式或体系结构风格，最后可能被内嵌为一种程序语言结构
5. 概念设计和技术设计是两个迭代的过程

概念设计相当于系统设计，确切地告诉客户系统要做什么，即软件架构和功能

技术设计相当于程序设计，一旦客户认可概念设计，系统构建人员就将概念设计转换为更为详细的文档，即技术设计，技术设计确切地告诉开发人员系统将如何运转，包括：主要的硬件组件及其功能；软件组件的层次和功能；数据结构和数据流

概念设计强调的是系统功能，技术设计描述的是系统将要采取的方式

软件设计过程模型的几个阶段？

1. Modeling 初始建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构风格，进行系统级别的决策。
2. Analysis 分析：分析初步的体系结构，主要关注软件系统的质量属性性能、安全性、可靠性等、各种约束等等。关注系统级别决策
3. Documentation 文档化：确定各个不同的模型视图
4. Review 复审：检查文档是否满足了所有需求
5. Final output 最终输出：SAD 软件体系结构文档，用来和开发团队中其他人员交流系统级别设计决策的有力工具

// 三种设计层次极其关系？

1. 体系结构设计：相当于系统设计，由软件需求中的系统能力与系统部件关联起来而得到软件整体结构的过程
2. 代码设计：各个构件/模块的算法和数据结构设计
3. 可执行设计：最底层的设计，包括内存分配，数据格式、位模式等

这是一种自上向下的设计，首先设计体系结构，然后进行代码设计，最后是可执行设计，具有可重复性，可以多次修改。在设计师的理解和创造力允许的情况下，可以对体系结构、代码设计、可执行设计进行多次修改。

//什么是模块化？什么是抽象？

1. 模块化：模块化设计也称为关注点分离，是一种把系统中各不相关的部分进行分离的原则。在模块化设计中，构件清晰地定义了输入和输出，设计目标明确，功能独立，可以做独立测试
2. 抽象：对细节的隐藏称为抽象，是基于某种归纳水平的问题描述，使我们集中于问题的关系，当探讨或分析两个模块共享数据时，模块各自的私有细节应隐藏
3. 模块/部件都以某种不同层次结构的抽象的形式出现, 越上层、越早期的模块层次或框架是越抽象的设计。将模块化部件和抽象层次结合，顶层模块通过隐藏细节可以给出解决方案，其他层次模块显示主要职能和实施细节，就可以用不同的方式设计不同构件的能力

论述设计用户界面应考虑的问题。

1. 设计界面要注意解决的要素：
   ①隐喻：可识别和学习的基本术语、图像和概念等
   ②思维模型：数据、功能、任务的组织与表示
   ③模型的导航规则：怎样在数据、功能、活动和角色中移动及切换
   ④外观：系统向用户传输信息的外观特征
   ⑤感觉：向用户提供有吸引力的体验的交互技术
2. 文化问题：需要考虑使用系统的用户的信仰、价值观、道德规范、传统、风俗和传说。
   两种解决方法：
   ①使用国际设计/无偏见设计，排除特定的文化参考或偏见
   ②采用定制界面，使不同用户看到不同界面
3. 用户偏爱：为具有不同偏好的人选择备选界面

5.5节----模块独立性----耦合与内聚的概念及各个层次划分？

举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

1、模块独立性
模块之间彼此独立的程度

取决于内聚和耦合的程度，我们追求的是高内聚、低耦合

1. 耦合
   （1）耦合度是指两个软件之间的相互关联程度，耦合程度取决于模块之间的依赖关系的多少，可以划分为紧密耦合、松散耦合和非耦合
   （2）级别划分（从高到低）：
   ①内容耦合：一个模块实际上修改了另一个模块，被修改的模块完全依赖于修改它的模块。例如，直接调用另一个模块的私有数据；一个模块在另一个模块中；一个模块修改另一个模块内部的数据项或代码；分支转移到另一个模块
   ②公共耦合：不同模块可以从公共数据存储区来访问和修改数据。例如，大家一起访问全局变量
   ③控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。例如，一个模块传出一个flag给别的模块，别的模块根据flag执行不同操作
   ④标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。例如，将一个数组传递给另一个模块，数组仅用于计算而非控制
   ⑤数据耦合：模块间传递的是数据值，但不限定数据结构，这是最受欢迎的一种耦合。例如，一个数值被当做参数传递给另一个模块，这个数值在另一个模块中只会参与计算而非控制
   ⑥非耦合：模块相互之间没有信息传递。例如，两个毫无关系的方法，但是一般完全没有耦合是不现实的
2. 内聚
   （1）内聚是指模块内部各组成成分（如数据、功能、内部模块）的关联程度，内聚度越高，模块各成分间相互联系越密切，与总目标相关性越高。内聚分为低内聚和高内聚
   （2）级别划分（从低到高）
   ①偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法
   ②逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。比如因为有相同的某一个计算步骤而放在一起的两个没有关系的计算
   ③时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作
   ④过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间内聚相比优点在于其功能总是涉及相关活动和针对相关目标，比如，写数据→检查数据→操作数据这一过程
   ⑤通讯内聚：各部分访问和操作统一数据集，比如将来自于同一传感器的所有不相关数据取出这一模块
   ⑥顺序内聚：各部分有输入输出关系，操作统一数据集，并且操作有顺序
   ⑦功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，比如一个简单的输出程序
   ⑧信息内聚：功能内聚的基础上调整为数据抽象化和基于对象的设计
3. 面向对象设计的目的是高内聚

软件过程中复审的概念，设计复审的重要性。

复审：检查文档（软件设计、软件体系结构图）是否满足所有功能及质量需求

设计检验方法：
（1）验证：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已经定好的标准，就是要用数据证明我们是不是在正确的制造产品。注重过程正确性，强调做得正确

（2）确认：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否能达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确

（3）验证更多是从开发商角度来做评审，测试验证产品需求、架构设计等方面是否和用户要求一致；确认更多是从用户或模拟用户的角度来验证产品是否和自己期望的一致

重要性：

（1）复审中批评和讨论时“忘我”的，能将开发人员更好的团结在一起，提倡并增强了成员之间的交流

（2）在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益

概念设计复审：与客户和用户一起检查概念设计

技术/程序设计复审：让程序员可以参与复审，在程序实现之前获得本阶段的反馈

Chapter06  考虑对象

// 什么是面向对象？OO有几个基本特征？如何使用高级语言实现这些基本// 特征？

面向对象：是一种软件开发方法，它将问题及其解决方法组织成一系列独立的对象，数据结构和动作都被包括在其中

七个基本特征：

1. 标识：确认对象的身份。对象名称用来区分对象或对象自身的状态，使对象可辨别
2. 抽象：层次化的角度描述对象
3. 分类：将在属性和行为上有共同点的对象分成一个类（一个对象是某特定类的一个实例）
4. 封装：封装一个对象的属性和行为，隐藏其实现细节
5. 继承：根据对象间相同点和不同点分层次地组织对象
6. 多态：允许不同类的对象对同一函数调用做出相应，即同一函数调用可以根据调用对象的不同而采用多种不同的行为方式
   多态存在的三个必要条件：继承、重写、父类引用指向子类对象
7. 持久性：持久对象不随着创建它的进程结束而消亡（因为在外存中存贮）

// 掌握并使用高级语言的OO基本编程方法和技巧。

什么是设计模式？

是一套被反复使用的（多数人知晓并经过分类编目的）代码设计经验的总结，使用设计模式目的是为了可重用代码、让代码更容易被他人理解并且保证软件质量

（软件开发方法：一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策）

面向对象设计模式：简单工厂模式，工厂方法模式，抽象工厂模式，观察者模式，单例模式，桥梁模式，责任链模式，适配器模式，代理模式，策略模式

了解OO设计的基本原则？

1. 单一职责原则
2. 重用原则
3. 开闭原则
4. 替换原则
5. 依赖倒置原则
6. 接口隔离原则
7. 迪米特法则

了解OO开发有何优势？

语言的一致性：采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案

全开发过程的一致性：从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构

全开发过程的一致性是面向对象开发和传统过程式开发的关键区别

OO开发过程有几个步骤？

OO需求分析和定义 + OO高层设计 + OO底层设计 + OOP + OO测试

面向对象需求分析、面向对象高层设计、面向对象底层设计、面向对象编程、面向对象测试

掌握用例图的组成和画法，用例的几个要素的含义。

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系

①用例：描述特定系统提供的特定功能，用椭圆表示

②执行者：和系统交互的实体（用户、设备或其他），用小人表示

③包含：对已定义用例的复用，用于提取公共行为，用带箭头的实线表示

④扩展：对一个用例的扩展使用，箭头指向被扩展者

掌握用例图的实例解析方法，如何辨识和确定一个用例？

识别参与者：
①谁/什么使用系统？  

②谁/什么从系统中获取信息？

③谁/什么向系统提供信息？

④公司的哪个部门会使用系统？

⑤谁/什么负责系统的维护？

⑥还有哪些其他系统会使用系统？

识别用例：

①每个参与者的目标是什么？

②为什么参与者要使用这个系统？

③参与者是否需要对系统中数据进行创建，存储，更改，删除或者读取的操作？为什么？

④参与者是否需要将外部事件或发生的改变告知系统？

⑤参与者是否需要知道系统内部发生的事件或改变？

⑥系统是否能够应对业务中所有的正确行为与操作？

用例模型相关建模步骤是什么？

用例识别——用例图——用例提纲——用例详细规约

1. 找出系统外部的参与者和外部系统，确定系统的边界和范围
2. 确定每一个参与者所期望的系统行为
3. 把这些系统行为命名为Use Case
4. 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分
5. 编制每一个Use Case的脚本
6. 绘制Use Case图
7. 区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的Use Case处理

(8) 细化Use Case图，解决Use Case间的重复与冲突问题。

用例图、类图等针对面向对象的项目开发的意义是什么？
①阐明需求（需求本身是比较难以表述的）
②便于找到需求中存在的问题并完善系统的功能需求
③便于客户、设计人员、测试人员的沟通交流
④在系统分析中是更正式建模的基础

熟悉类图中各个类之间的基本关系分类及其含义。   

OO设计是从类图（描述对象类型和它们的静态关系）开始的

类图本身分为三部分，分别为名字、属性、方法

1. 继承
   “is-a”的关系，箭头指向父类
   
2. 关联
   通常是将一个类的对象作为另一个类的成员变量。箭头指向被依赖者，可以使用双箭头表示双向关联，还可以知名关联中双方的数量
   
3. 聚合
   箭头指向部分，菱形指向整体。表示一个事物的整体和部分，两者可以独立存在
   
4. 组合
   箭头指向部分，实心菱形指向整体。表示一个事物的整体和部分，不能独立存在，整体不存在时部分也就不存在了
   
5. 依赖
   箭头指向被依赖方。一个类的实现依赖于另一个类的关系，往往体现为一个类的方法的参数是另一个类
   
6. 接口与实现
   箭头指向被实现的接口，接口中通常没有属性，且所有操作都是抽象的
   

//状态图的含义及用途。

状态图用于展现一个对象所具有的所有可能的状态，并且它们在接收到什么信息时会进行怎样的转化。当一个对象会随着属性的改变而具有不同的行为时，使用状态图反映

状态（State）：表示对象在其生命周期中的某个特定状态，如"待处理"、"进行中"、"已完成"等

状态转换（Transition）：表示对象从一个状态转换到另一个状态的过程，通常用箭头表示。箭头上可以标注触发状态转换的事件或条件。

条件（Guard Condition）：表示触发状态转换的条件，通常用方括号内的逻辑表达式表示。

动作（Action）：表示状态转换发生时执行的动作或操作，通常用在状态转换的箭头上。

事件是触发状态转换的外部或内部事件，条件是触发状态转换的条件，动作是状态转换发生时执行的操作

绘制类图最常用的方法及步骤是什么？识别一个类的基本思路？

1. 确定类和属性
   ①从需求中寻找对象
   ②可以先定义一个系统中应有的部分，然后去需求中出现的名词中找到符合的
2. 确定行为
   ①去需求里找动词
   ②思考确定的类应该有什么行为
3. 绘制

熟悉用例图、类图、状态图的组成和画法。

活动图：描述活动和过程流，描述一个过程或操作的工作步骤，描述系统的动态行为

了解UML其他图示结构的基本用途。

用例图：描述系统必须执行的一般过程

UML类图：描述对象之间的静态关系

UML活动图：描述业务活动的工作流模型，显示对象的值更改时系统中可能发生的所有活动

UML状态图：展现一个对象所具有的所有可能的状态，并且它们在接收到什么信息时会进行怎样的转化

UML包图：类的集合形成一个包，使设计更加层次化，易于理解。展示包和类之间的依赖，在测试时发挥重要用途

UML顺序图：展示活动或行为发生的顺序

UML通信图/UML协作图：使用对象与对象之间的连接来描述对象间的消息顺序

UML构件图：说明运行时的构件以及它们之间的交互

UML部署图：描述如何为构件分配计算资源

OO的基本设计方法和技巧

OO设计是从类图开始的，在需求分析完成之后，我们通过正确分析各个类之间的关系设计类图，要遵循OO设计原则，采用适当的OO设计模式

Chapter07  编写程序

//为什么说编码工作是纷繁复杂甚至令人气馁？  

1. 设计人员可能没有处理平台和编程环境的所有特性，易于用图表示的结构或关系并不是总能直截了当的编写代码
2. 编写易于理解的代码
3. 编写的代码要易于重用
4. 需要比照着设计进行检查

一般性的编程原则应该从哪三个方面考虑？

1. 控制结构（程序如何传递数据）
   要让程序设计反映出在体系结构和设计中的各种控制结构。当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的
2. 算法（程序如何处理数据）
   设计师通常会指定一类算法，编程时遵循。选择算法要在执行时间，设计质量，标准和客户需求之间平衡考虑。
3. 数据结构（程序如何储存数据）
   编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂

//论述编码阶段实现某种算法时所涉及的问题。

①编写更快代码的代价。可能会使代码更加复杂，从而要花费更多时间编写代码
②测试代码的时间代价。代码的复杂度要求有更多的测试用例或测试数据

③用户理解代码的时间代价
④需要修改代码时，修改代码的时间代价

在编写程序内部文档时，除了HCB外，还应添加什么注释信息？注意什么？

内部文档包含的信息是面向阅读程序源码的那些人的因此它提供概要信息以识别程序，描述数据结构，算法和控制流。包含：

1. 头注释块（HCB）
   将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有构件，构件是如何使用数据结构、算法和控制的
2. 其他程序注释
   包含：
   ①解释性注释：可以对程序正在做什么提供逐行解释
   ②分解性注释：将代码分解成表示主要活动的段，每个活动再分解成更小的步骤
   ③版本注释：随着时间进行修改的记录
3. 有意义的变量名和语句标记
   命名时尽量用有意义的变量名进行命名
4. 安排格式以增强理解
   注意缩进和间隔来反映基本的控制结构
   编写内部文档要注意：
   ①分段注释
   ②修改代码的同时也要修改注释
   ③写代码同时就写注释，不延后
   ④注释要带来新的信息，通过变量名或者简单阅读代码就可以获得的信息是不用加入注释的
   ⑤使用有意义的变量名或标签
   ⑥使用统一易读的编码格式
   ⑦注释应当描述数据结构和它的用法，这一点在强调封装性的OO中尤为重要

敏捷方法的大致思想？什么是极限编程(XP)? 以及派对编程？

1. 敏捷开发
   敏捷开发理念认为：人与人之间的交互复杂、难以预期，但这是开发中最重要的方面
   敏捷开发强调人与人之间的交流，并且以“尽可能早的、持续的交付有价值的软件”为最高目标，而不是把时间精力都花在文档、谈判、计划上，随机应变，唯快不破
2. 极限编程
   极限编程是敏捷开发的一种具体形式，提供敏捷开发最一般原则的指导方针，是一种轻量级软件开发方法论，强调敏捷方法的四个特性：
   ①交流：客户和开发人员之间持续的交换看法
   ②简单性：鼓励开发人员选择最简单的设计或实现来满足客户的需求
   ③勇气：尽早地和经常地交付功能的承诺
   ④反馈：程序员和客户之间或程序员之间针对各种开发过程对彼此进行反馈
3. 派对编程/结对编程
   结对编程属于主要的敏捷开发方法，开发方式是两个程序员共同开发程序，且角色分工明确：
   一个负责编写程序
   一个负责复审和测试
   两个人员定期交换角色
   优点：提高生产率和质量，但证据不充分，模棱两可
   缺点：会抑制问题求解的基本步骤，扰乱对问题的关注

Chapter08  测试程序

了解产生软件缺陷的原因？

1. 软件本身，系统处理大量的状态，复杂的公式，活动，算法等
2. 客户不清晰的需求
3. 其他原因，如项目的规模，众多的参与者导致的复杂性

// 将软件缺陷进行分类的理由？

知道正在处理的是什么类别的故障对于我们具体测试，以及以后的故障改正都有很大帮助

有几种主要的缺陷类型？

1. 算法故障
   由于处理步骤中的某些错误，使得对于给定的输入，构件的算法或逻辑没有产生适当的输出
2. 计算故障/精度缺陷
   一个公式的实现是错误的，或者计算结果没有达到要求的精度
3. 文档故障
   文档与程序实际做的事情不一致
4. 压力故障/过载故障
   对队列长度、缓冲区大小、表的维度等的使用超出了规定的能力
5. 能力故障/边界故障
   系统活动到达指定的极限时，系统性能会变得不可接受
6. 计时故障/协调故障
   几个同时执行或仔细定义顺序执行的进程之间协调不当
7. 吞吐量故障/性能故障
   系统不能以需求规定的速度执行
8. 恢复故障
   当系统失效时，不能表现得像设计人员希望的或客户要求的那样
9. 硬件和系统软件故障
   当提供的硬件或者系统软件实际上并没有按照文档中的操作条件或步骤运作时
10. 标准和过程故障
    代码没有遵循组织机构的标准和过程

// 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果一个故障属于不止一个类，则失去了度量的意义

测试的各个阶段及其任务？涉及的文档？（图8.3）

1. 模块测试/构件测试/单元测试
   将每个程序构件与系统中的其他构件隔离，对其本身进行测试
   依据文档：程序代码与配套文档
2. 集成测试
   验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作
   依据文档：系统体系结构文档SAD、程序设计规格说明
3. 功能测试
   对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统
   依据文档：软件需求规格说明书SRS
4. 性能测试
   测试系统的软硬件性能是否符合需求规格说明文档，其结果是一个确认的系统
   依据文档：软件需求规格说明书SRS
5. 验收测试
   确定系统是按照用户的期望运转的
   依据文档：客户需求定义
6. 安装测试
   确保系统在实际环境中按照应有的方式运转
   依据文档：用户环境的说明
7. 系统测试
   功能测试 + 性能测试 + 验收测试 + 安装测试 = 系统测试

// 测试的态度问题？（为什么要独立设置测试团队？）

1. 新程序员不习惯将测试看作一个发现的过程，通常只想去展示正确之处、设计亮点、个人能力
2. 客户只是单纯的希望系统在任何情况下都能正常运行，即使有时候提出的要求并不现实
3. 我们应当以“忘我编程”的态度来测试，将组件看作系统的一部分而不是编写者的财产，尽可能地发现并修改缺陷，而不是谴责编写者
4. 独立设置测试团队的原因：
   ①避免试图掩盖错误、逃避责任的行为，避免了故障的个人责任，尽可能多的发现故障的需要之间的冲突
   ②各个阶段都可能引入故障，独立团队因为和代码不是太过紧密，所以能更客观，有更多机会发现细微的故障
   ③允许我们先着手测试完成的部分，测试与编码同时进行

掌握测试的方法----黑盒、白盒的概念？

1. 黑盒
   测试人员在完全不了解程序内部的逻辑结构和内部特性的情况下，只依据程序的需求规格设计说明，检查程序的功能是否符合它的功能说明。其原则是依据需求文档、系统设计文档、程序设计文档进行测试，正确的结果是系统完成了所有该做的，拒绝了一切不该做的
   优点：测试人员不受内部结构和逻辑的约束，测试更具客观性，更偏向于功能性的测试
   缺点：黑盒测试以SRS为依据，有一定的盲目性和不确定性，不可能揭示所有的错误，有时会无法进行完备的测试，不容易找到具有代表性的测试用例证明所有情况下功能都正确
2. 白盒
   测试人员拥有全套文档，以程序内部结构为基本依据，根据测试对象的结构用不同的方式进行测试
   优点：可以测试一个模块的细节
   缺点：白盒测试以模块内部逻辑为依据，当内部逻辑过于复杂时，则不能给出好的或合适的测试用例。有时候，对于大量递归、循环和分支的构件，想测试完所有的分支也是不现实的
3. 实际测试中，没有必要黑盒测试和白盒测试严格的区分开来。具体的测试方法选择受到很多因素的影响

什么是单元测试？

将每个程序构件与系统中其他构件隔离，对其单独进行测试
步骤：
（1）检查代码

（2）测试程序模块
①确定测试的目标和计划
②选择测试用例
③执行测试计划

测试点或测试用例：用于测试程序的输入数据的一个特定选择，测试是测试用例的集合

测试的完全性：以一种使人信服的方式来证明测试数据展现了所有可能的行为

1. 语句（覆盖）测试：在某次测试中，构件中的每条语句至少执行一次
2. 分支测试：对代码中的每个判断点，每个分支在某次测试中至少选择一次
3. 路径测试：通过代码的每一条不同路径在某个测试中至少执行一次

//什么是走查和检查？

两者都是代码检查的一部分
（1）代码走查：程序员向评审小组提交代码和相关文档，评审小组非正式的进行讨论，注意力集中在代码上，发现缺陷不必修改

（2）代码审查：更正式的代码评审，评审小组事先准备好问题清单，依据清单来检查代码和文档

黑盒、白盒方法各自的分类？测试用例的设计方法和给出方法。

黑盒、白盒方法的分类原则，各种覆盖方法等。（课件等）

1、黑盒：

1. 等价分类法：将输入域划分为若干等价类。每一个测试用例都代表了一类与它等价的其他例子。如果测试用例没有发现错误，那么对应的等价例子也不会发生错误。有效等价类的测试用例尽量公用，以此来减少测试次数，无效等价类必须每类一个用例，以防止漏掉可能发新鲜的错误
   有效等价类是正常输入，无效等价类是不应当输出正确结果的无效输入。
   划分等价类时要进行“密辅”式划分，并且尽可能不对测试的实体整体添加限制条件以提升可扩展性
   用例覆盖等价类的原则：
   对有效等价类的用例，尽量用一个用例覆盖尽可能多的等价类，这是因为任意一个有效等价类的处理出现问题都会产生故障，可以以此减少测试次数
   对无效等价类，必须为每一个无效等价类都设计一个专门验证该点的用例，这是因为所有无效等价类的表现都是不正常返回，不进行共用以避免多个错误一起发生导致漏过一些错误
2. 边界值分析法：在等价分类法中，代表一个类的测试数据可以在这个类的允许范围内任意选择。但如果把测试值选在等价类的边界上，往往有更好的效果，这就是边界值分析法的主要思想
3. 错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。更多依赖于测试人员的直觉和经验
4. 因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合情况。由布尔逻辑与约束条件产生因果图—>将因果图转化为判定表—>由判定表产生测试用例

2、白盒：

逻辑覆盖法：按对程序逻辑覆盖程度由低到高分为：
（1）语句覆盖：每条语句至少执行一次

（2）判定覆盖（分支覆盖）：每一分支至少执行一次

1. 条件覆盖：每个条件均按“真”和“假”两种结果至少执行一次
2. 条件组合覆盖：某个分支虽然只有一种结果，但可能由多个条件组合而成。条件覆盖只要求单个条件一次真一次假即可，条件组合覆盖要求覆盖所有组合，即使有些组合最终结果一样

如何面对一个命题，设计和给出测试用例的问题。（课件）

------课堂练习的测试题目和讲解内容

1. 在集成测试及以后的阶段，除去很小的程序，都应当使用黑盒。具体流程为：
   （1）使用边界值分析法或等价类分析法提出基本的测试用例
   （2）使用错误猜测法补充一些测试用例
   （3）如果在程序的功能说明中含有输入条件的组合，则在一开始就用因果图法，然后再按以上两步进行
2. 对于单元测试，我们可以直接参考模块的源代码，并且工作量可以承受，所以适合把黑盒白盒法结合运用
   （1）先使用黑盒法设计测试用例，然后用白盒法做验证，如果发现黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足他们覆盖的标准
   （2）先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能说明用黑盒法进行补充

集成测试及其主要方法的分类？（驱动模块、桩模块的概念）

验证系统组件是否能正确的协同工作，得到一个正常运作的系统

选择策略要兼顾系统特性和客户需求

驱动模块：代替上级模块传递测试用例的程序，即代替上层模块的调用程序（出现在自底向上集成测试中）

桩模块：代替下级模块的应答程序（出现在自顶向下）

分类：

1. 自底向上集成测试
   每一个处于系统层次中最底层的构件先被单独测试，接着测试那些调用了前面已测试构件的构件。反复采用这种方法，直到所有构件测试完毕
   典型特征：添加新模块调用的下层模块必须全部测试完毕
   使用驱动模块
   优点：容易生成测试用例；适合面向对象方法；编写驱动程序简单
   缺点：存在于高层模块中的关键错误无法被及时发现
2. 自顶向下集成测试
   顶层构件通常是一个控制构件，是独立进行测试的。然后将被测构件调用的所有构件组合起来，作为一个更大的单元进行测试。重复这样的操作直到所有构件都被测试
   典型特征：添加的新模块，调用它的上层模块必须被测试过
   使用桩模块
   优点：一些功能性的设计故障或主要问题可以在测试的早期进行处理
   缺点：桩不容易编写，桩模块的正确性可能影响测试的有效性；可能需要大量的桩模块
3. 一次性集成
   先测试每一个构件，然后将所有的构件一次性集成。只适用于小型系统
   缺点：有些构件同时需要桩模块和驱动程序；一次性集成很难发现失效原因；很难将接口故障和其他故障区分开
4. 三明治集成
   将系统分为三层，目标层处于中间、上面一层、下面一层。在顶层采用自顶向下的方式，在较低层采用自底向上的方式，测试集中于目标层

传统测试和OO测试有何不同？OO测试有何困难？

1. 区别
   （1）测试用例的充分性：对过程语言而言，当系统改变时，我们可以针对改变测试是否正确，并使用原有的测试用例来验证剩余的功能是否同原来一致。但是面向对象的测试中，我们可能需要编写不同的测试用例
   （2）面向对象趋向于小粒度，并且平常存在于构件内的复杂性常常转移到构件之间的接口上。这意味着，其单元测试较为容易，但是集成测试涉及面变得更广泛
   （3）传统测试和面向对象的测试主要集中在：需求分析和验证、测试用例生成、源码分析和覆盖分析
2. 困难
   （1）需求文档的验证缺乏支持
   （2）测试工具生成的测试用例往往不能很好的处理OO模型中的对象和方法
   （3）传统的测试方法在评价OO系统的规模和复杂度时不是很有效
   （4）对象的交互是OO系统复杂性的根源，传统的测试方法和经验的作用有限

// 测试计划涉及的几个步骤？  （了解）

1. 制定测试目标
2. 设计测试计划
3. 编写测试用例
4. 测试测试用例
5. 执行测试
6. 评估测试结果

Chapter09  测试系统

系统测试的主要步骤及各自含义？（图9.2）

1. 功能测试
   验证系统是否能执行需求规格说明中描述的功能
   依据文档：软件需求规格说明书SRS
2. 性能测试
   验证系统的软硬件表现和性能是否符合需求规格说明文档
   依据文档：软件需求规格说明书SRS
3. 验收测试
   验证系统是否满足了客户的需求定义
   依据文档：客户需求定义
4. 安装测试
   验证系统能否在真实环境中安装并运行
   依据文档：用户环境的说明

// 什么是系统配置？软件配置管理？  // 基线？（或见课件）

系统配置：向特定客户交付的系统构件的集合

软件配置管理：对系统不同软件配置的管理及控制方法（其中既有开发，也有测试）。通过控制系统差别以降低风险，减少错误。它的重要性在于它协调测试人员与开发人员之间的工作，从而获取有效配置

基线：软件文档和其他资料的集合，代表了产品在某一时间点的情况

什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本或改进版本相比，他是否仍然以同样的方式执行同样的功能

功能测试的含义极其作用？

含义：测试SRS（软件需求规格说明书）中的功能性需求

作用：有很高的故障检测概率（因为一项功能测试只面向一小组组件）

软件功能测试的基本指导原则？

1. 高故障检测概率
2. 使用独立于设计人员和程序员的测试小组
3. 了解期望的动作和输出
4. 既要测试合法输入，也要测试不合法输入
5. 制定停止测试的标准

性能测试的含义与作用？

性能测试比功能测试更难

需求定义要足够完备才能保证性能测试成功进行，需求质量通常可以反映在性能测试的容易度上

含义：测试SRS中的非功能需求，如性能、准确度等

作用：确保系统的可靠性、可用性和可维护性

性能测试的主要分类？

1. 压力测试/强度测试：短时间内加载极限负荷，验证系统能力，对经常产生负荷高峰的系统很有意义
2. 容量测试/巨额数据测试：验证系统处理巨量数据的能力
3. 计时测试：评估涉及对用户的响应时间以及功能执行耗时的相关需求
4. 配置测试：对系统软硬件的各种配置进行测试
5. 兼容性测试：测试其接口在与其他系统互动时能否正常运作
6. 环境测试：测试系统在安装场所的执行能力，这里指的是外部的物理条件，比如高温、潮湿
7. 回归测试：验证软件的新版本与旧版本相比，是否仍能以相同的方式执行着相同的功能
8. 安全性测试：确保安全性需求得到满足
9. 质量测试：评估系统的可靠性、可维护性和可用性
10. 恢复测试：检验系统是否能在故障或丢失电源、数据、设备时自我修复
11. 维护测试：核验一些诊断工具和过程是否能正常运行，如：诊断程序、实物跟踪、辅助工具
12. 文档测试：确保编写了必要的文档
13. 人为因素测试/可用性测试：检查涉及系统用户界面的需求

// 什么是可靠性、可用性和可维护性？

可靠性：软件系统在给定的时间范围和条件下运行成功的概率

可用性：软件系统在给定的时间点成功运行的概率。可用性强调某一时刻系统正常，系统可能在相当长一段时间内都可用，保持了可靠性，但在不能使用的那一刻，它失去了可用性

可维护性：指在给定的使用条件（预定的时间间隔、可用的维护程序、可用的维护资源之下进行维护）下，维护活动能被执行的概率

确认（验收）测试概念，确认测试分类？（基准测试和引导测试）

概念：由客户检查软件系统是否满足了他们的需求定义，主导者是客户，开发者只负责解答一些必要问题

分类：

1. 基准测试
   先由客户准备测试用例，然后在实验环境中安装系统，最后由用户进行评估
2. 引导测试
   先将系统安装在实验环境中，然后再假设系统正式安装的前提下，由测试者在测试系统上进行日常工作，而不是依赖于测试用例
   α测试和β测试都属于引导测试
3. 并行测试
   当软件的一个旧版本正在使用，并且要测试一个新版本时使用并行测试
   新旧版本并行运转，来自用户的操作会同时在新旧系统上执行，旧系统实际工作，新系统进行测试，使用户逐渐习惯新系统

什么是alpha测试？β测试？

α测试：在发布系统之前，由开发者自己组织人员或委托专业团队来进行小规模测试

β测试：有客户实际进行小规模测试

什么是安装测试？

定义：在用户环境中配置系统，以测试可能因为开发环境与用户环境的不同而导致的问题

目的：安装系统的完备性，验证任何可能受场所条件影响的功能和非功能特性