题型
10个名词解释 2*10 = 20 （例如：什么是设计模式啊？ 软件体系结构 ？…）
选择题 20个应该
简答题/论述题 5个 一个6分 5*6=20 （成本估算xxx 什么什么模型 那些阶段）
综合应用题（UML图的综合应用填空、软件测试）
第一章 软件工程简介
1. 定义、目的、方法
定义：理解问题的本质，并给出解决方案，即：用系统科学的方法解决问题
目的：设计和开发高质量的软件
方法：面向过程、面向对象（面向对象模式，结构化模式，基于过程的模式等。）
软件开发与程序设计有什么不同
软件开发将软件的开发过程分为若干阶段，包括需求分析、系统设计、程序设计、编码、测试等等，而程序设计仅是软件开发的一个组成部分，并且软件开发所指的软件不同于一般程序，而是指大型程序及文档
软件危机
软件危机：落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
典型表现：
- 对软件开发成本和进度的估计常常很不准确。
- 用户对“已完成”软件系统不满意的现象经常发生。
- 软件产品的质量往往靠不住。
- 软件常常是不可维护的。
- 软件通常没有适当的文档资料。
- 软件成本在计算机系统总成本中所占的比例逐年上升。
- 软件开发生产率提高的速度，远跟不上计算机应用迅速普及深入的趋势。
出现的原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。
- 软件缺乏“可见性”，管理和控制软件开发过程相当困难。
- 软件规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
- 开发时期引入错误，导致软件维护通常意味着改正或修改原来的设计，客观上使得软件较难维护。
- 软件专业人员对软件开发和维护中或多或少地采用了错误的方法和技术。
2. 错误、缺陷、失效
错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。
故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。
失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。
联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。
- error：理解的错误
- fault：理解的错误体现到了软件制品当中（不一定会触发failure）
- failure：系统的行为跟预期不符
例：直径是半径的3倍→写入文档是error，运行后结果错误：failure
会考如何区分↑
3. 软件质量
产品的质量
用户：从功能正确性、failure的数目、类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。
过程的质量
有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了 解）
商业环境背景下的质量
一种常见的方法：投资回报ROI（return on investment）
(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。
4. SE大致包含的阶段：
（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。
（2）系统设计：包括用户界面的设计【《SAD》即《软件系统结构图》：如何制作软件】与复审（开发者与客户）。
（3）程序设计：包括模块功能算法与数据描述设计【相关文档】与复审（开发者）。
（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。
（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）
（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。
（7）系统测试：按《SRS》对系统总体功能进行测试与复审（开发者与客户）
（8）系统交付：交付产品【用户手册和操作手册】与复审。
（9）系统维护：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。
注：圆括号中的为测试人员，方括号为生成的文档。
5. 现代SE 七个关键因素
（1）商用产品投入市场时间的紧迫性（时间紧迫）
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本（计算成本降低）
（3）桌面计算机功能增强
（4）广泛的局域网和广域网（网络技术的发展）
（5）面向对象技术的采用及其有效性（面向对象技术的发展）
（6）使用窗口、图标、菜单和指示器的图形用户界面（图形化界面实现的发展）
（7）软件开发瀑布模型的不可预测性（瀑布模型的问题）
6. Wasserman 规范
① 抽象(abstraction)：
基于某种层次归纳水平的问题描述。它使我们将注意力集中在问题的关键方面而非细节。
② 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
③ 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
④ 软件体系结构：
定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法（以下了解）：
（1）基于功能的模块化分解: 基于指派到模块的功能。
（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。
（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
⑤软件过程：
软件开发活动中的各种组织及规范方法。（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。
⑥ 重用或复用(reuse)：
重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
⑦ 测度或度量(measurement)：
量化的指标
通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
⑧ 工具和集成环境：
通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
第二章 项目过程建模与生命周期
1-1. 什么是软件过程
软件过程：一组有序的开发任务，它涉及活动、约束和资源使用的一系列步骤，用于产生某种想要的输出。
过程不仅仅是步骤，过程是步骤的集合，它将步骤组织起来使人们能够生产满足一系列目标和标准的产品。
1-2 软件过程为什么重要
强制软件开发活动具有一致性和一定的结构，帮助开发人员理解、控制、检查、改善开发过程，使我们获取经验并把经验传授给他人。
- 它强制活动具有一致性和一定的结构。
- 过程结构允许我们分析、理解、控制和改进组成过程的活动，并以此来指导我们的活动。
- 它使我们获取经验并把经验传授给他人。
1-3 软件生命周期
软件生命周期：产品从概念到实现、交付、使用和维护的整个过程。
2-1. 瀑布模型
需求分析→系统设计→程序设计→编码→单元测试→集成测试→系统测试→验收测试→运行与维护
线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。
2-2. 瀑布模型优点
优点：过程可见、方便监控
它的简单性使得开发人员很容易向不熟悉软件开发的客户作出解释。
每一个过程活动都有与其相关联的里程碑和可交付产品，以便于项目经理评估项目进度。
瀑布模型是最基础的模型，很多其他更复杂的模型实际上是在瀑布模型的基础上的润色，如加入反馈循环以及额外的活动。
2-3. 瀑布模型缺点
缺点：用户很难从一开始确定所有的需求，没有迭代，很难改变需求；没有把软件开发看成问题求解的过程
除了一些理解非常充分的问题之外，实际上软件是通过大量的迭代进行开发的。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。
没有涉及到迭代，用户可能会频繁修改需求
3. 分阶段开发模型 分类特点
含义：将软件产品分阶段、分功能，一部分一部分的交付
特点：大幅缩短循环周期，有两个运行版本
分类：增量式开发、迭代式开发
- 增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。（小的子系统→不断增加功能）
- 迭代开发：系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强。（全系统→不断完善功能）
4. 螺旋模型
含义：类似于迭代模型，将风险控制（risk control）结合起来，以控制最小化风险。
四个象限的任务：计划；确定目标、可选方案及约束；评估风险；开发与测试
四次迭代（四重循环）：操作概念、软件需求、软件设计、开发与测试。
5. 敏捷开发 代表性方法
定义：重量级开发的对立面，具有下面4个原则的方法：
强调个人价值
时间花在写软件，而不是文档上
将精力集中在与客户合作而不是谈判
专注于对变化的反应而不是自定义计划后严格遵循
敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。
这四条原则反映了敏捷方法的软件过程倾向性。它强调人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。
敏捷开发的总体目标：尽可能早的，持续的对有价值的软件的交付活动，以客户满意。
四个特性（准则）：
交流、简单性、勇气、反馈
①沟通: 客户与开发者之间持续的交流意见。
②简单性: 鼓励开发者选择最简单的设计或实现来应对客户的需求。
③反馈: 指在软件开发过程中的各个活动中,包含各种反馈循环工作。
④勇气: 指尽早的和经常性的交付软件功能的承诺。
敏捷开发过程的几种方法
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶法）：每一个不同的项目都需要一套不同的策略、约定和方法论
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)
⑤Feature Driven Development(FDD) (特征驱动软件开发)
这几种方法知道名字即可
6. 什么是UP、RUP
RUP（Rational Unified Process）：迭代开发的一种具体模型，是Rational软件公司创建的SE方法，是一种重量级的开发方法（适合大软件、大团队的开发）
UP是一种大的类型，RUP是这个公司开发的一种方法
什么是UP、 RUP、进化式迭代等市场流行的过程模型
UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。该模型的四个阶段：开始阶段、确立阶段、构建阶段和移交阶段。每个阶段可以进一步划分为多次迭代。该模型的六道核心工序：业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。
补充:统一过程（UP）可以用三句话来表达：它是用例驱动的、以基本架构为中心的、迭代式和增量性的软件开发过程框架，它使用对象管理组织（OMG(Object Management Group)）的UML 并与对象管理组织（OMG）的软件过程工程原模型（SPEM（Software Process Engineering Meta-Model ）软件过程工程元模型）等相兼容。
RUP（Rational Unified Process），是IBM提出的提供支持和包装的UP模型。统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。
进化式迭代开发（Iterative development）是统一开发过程(RUP)的关键实践。开发被组织成一系列固定的短期小项目。每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试。随着时间和一次次迭代，系统增量式完善。
什么是原型？用途？
原型是一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。
用途：
1、原型化设计可以使开发者更容易地提高软件质量。
2、原型化设计可以提供多种解决方案供用户选择。
第三章 计划与实施项目
1. 项目进度 活动 milestone里程碑 项目成本
项目进度定义：通过列举项目的各个阶段，把每个阶段分解成离散的任务或活动，来描述特定的软件开发周期
项目活动（Project Activity）：项目的一部分，一般占用项目进度计划中的一段时间
里程碑（Milestone）：指特定的时间点，标志着活动的结束，通常伴随着提交物。（如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档）
项目成本定义：为项目开发而购买软件、硬件的成本，用于支持需求分析、设计、编码、测试、处理需求变更等活动，涉及到工作量开支
(1) 项目进度（Project Schedule）
项目进度是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。
(2) 项目活动（Project Activity）
项目的一部分，一般占用项目进度计划中的一段时间
(3) 里程碑（Milestone）
指特定的时间点，标志着活动的结束，通常伴随着提交物。（如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档）
(4)前驱（Precursor）
活动进行前必须完成的事件
(5)工期（Duration）
完成活动的时间
(6)截止日期（Due date）
活动必须完成的时间
2-1 什么是活动图
描述了不同活动之间的依赖性、表明了执行的顺序，节点表示项目里程碑，线条表示活动
2-2 如何计算项目关键路径、冗余时间 最早最晚开始时间
关键路径：从起点到终点总花费时间最长的路径
关键路径（Critical Paths）
从起点到终点总花费时间最长的路径，即这个项目的最短完成时间，因为如果这条路径无法完成那么整个项目都不能算完成。所以这条路径上的任务耽误一点都会影响最后项目完成时间。
如上图，其关键路径为 A->B->D->I->J->L = 20，其他路径都比它短。
冗余时间（Slack Time）
最早开始时间（Earliest start time ES）
最晚开始时间（Latest start time LS）
- 若起始为1：
EF = ES + 工期 -1
LS = LF - 工期 +1
- 若起始为0：
EF = ES + 工期
LS = LF - 工期
设关键路径的长度为LL
ES 最早开始时间（能到达该开始点的最长的路径所花费的时间） | 工期（参照上面的计算公式） | EF（ES+工期） |
LS（使用LL-能到达该开始点的最长的路径所花费的时间） | slack time | LF（LS+工期） |
3. 软件项目团队基本组织架构
(1) 主程序员负责制
(2) 忘我方法（Egoless Approach）：每个成员平等的承担责任
依赖团队成员的背景、工作风格，团队成员数，客户和开发者的管理方式
(1) 主程序员负责制
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。
优势：使交流最小化；迅速做出决定
缺点：创造性低；对主程序员要求高，个人主观性强
(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。
4. COCOMO模型的三个阶段
constuction cost model
(1) 应用组合 application composition：利用原型化来解决高风险问题，用应用点来估算成本
(2) 早期设计 early design：用功能点（已经决定将项目开发向前推进，但是设计人员必须研究几种可选的体系结构和操作的概念；在这一步，使用需求文档中的功能点FP来进行规模测量。）
(3) 后架构阶段 Postarchitecture：开发已经开始，用代码行数来评估KLOC
COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。
- 计划阶段：项目通过构建原型来解决用户界面、软件、交互、性能、技术成熟度等方面的高风险问题；在这一步，使用应用点AP来进行规模测量，比如估算屏幕数、报表数、组件数等。
- 早期设计阶段：已经决定将项目开发向前推进，但是设计人员必须研究几种可选的体系结构和操作的概念；在这一步，使用需求文档中的功能点FP来进行规模测量。
- 后体系结构阶段：开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素（开发已经开始，软件已经被部分构造出来）。
5-1. 什么是软件风险
概念：风险是带有负面结果的，开发过程中不希望出现的事件
方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）
5-2. 风险管理活动
评估、分析、优先级分配、控制
风险评价：风险识别，风险分析，风险优先级分配
风险控制：风险降低，风险管理计划，风险化解
5-3. 降低风险的策略
三种降低风险的策略
- 避免风险（Avoiding the risk）：改变功能和性能需求，使风险没机会发生。比如用 C 语言的程序有内存泄漏的风险改用 Java，避免风险。
- 转移风险（Transferring the risk）：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。
- 假设风险（Assuming the risk）：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。
软件人员应该具备的能力是什么？
（1）完成工作的能力（2）对工作的兴趣（3）开发类似应用的经验（4）使用类似工具或语言的经验（5）使用类似开发环境的经验（6）使用类似技术的经验（7）培训（8）与其他人交流的能力（9）与其他人共同承担责任的能力（10）管理技能
第四章 软件需求
0. 用例图等都需要会填空！！！
例：借书还书的用例图、取钱还钱的作业题（or ppt上的）
UML图经常考综合题
框：表示系统边界
任务线条（系统边界之外）：参与者（用户/系统）
椭圆形（系统边界之内）：用例，表示重要功能或变体
线：（在actor和use case之间）：表示参与者参与用例
用例图包含的关系：
关联：表示参与者与用例之间的通信，任何一方都可发送或接受消息。（无箭头，参与者与用例相连接即可）
泛化（inheritance）：就是通常理解的继承关系
包含（include）：包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。（指向分解出来的功能用例）
扩展（extend）：扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。（指向基础用例）
1. 需求的定义
定义：对来自用户的关于软件系统的期望行为的描述、处理的是类、类的状态、改变这些状态或对象的函数。
2. 确定需求的过程
最终产出outcome：Software Requirements Specification（SRS）软件规格说明文档
①原始需求获取 Elicitation：客户给出的需求
②问题分析 Analysis：理解需求并通过建模或模型化方式进行描述
③规格说明草稿 Specification：利用符号描述系统将定义规范化表示
④需求核准 Validation：开发人员与客户进行核准
⑤软件规格说明（SRS）
3. 举例说明获取需求时，若有冲突发生，如何考虑根据优先级进行需求分类？
请求客户对需求进行优先级划分通常是有用的，这可以迫使客户思考提议的服务或特征中哪些是最重要的。
一种大致的优先级划分方案可能将需求分为3类：
- essiential基本的：必须要满足的需求
- desirable期望的：非常值得做但是不是必须的需求
- optional可选的：可选的需求（可做可不做）
举例：信用卡记账系统必须能够列出最近的费用，将他们加起来并要求在某个日期前支付，这是必须的需求。但是，该记账系统也可能按照购买类型区分费用，以帮助消费者理解购买的模式，这是值得要的需求。最后，记账系统可能要求用黑色来打印贷方账目，用红颜色打印借方账目，这用需求是有用的，但它是可选的需求。
按照类型对需求进行优先级的分类，能够帮助所有相关人员理解自己到底需要什么。
当软件开发项目受到时间或资源的限制时，如果系统的成本太高或者开发的时间太长，就可以去掉可选需求，并对值得要的需求进行分析，考虑是去掉还是延期。还可解决与质量需求之间的矛盾。
4. 需求文档分为两类：需求定义 需求规格说明
需求定义：完整罗列客户需求清单
需求规范(SRS)：将需求重述为关于要构建的系统如何运转的规格说明
需求定义
包含一般用途；系统的背景和目标；描述客户建议的方法；详细特征；运营环境等
需求规格说明（SRS）
包含文件系统接口；对功能、性能要求进行正式化的重述等
5. 功能性需求 非功能性需求 质量需求 设计性约束 过程约束
学会区分
① 功能需求 Functional requirement：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。（例：系统必须完成自动计算工资功能，系统必须存储每次的用户操作记录）
② 设计约束 Design constraint：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。（例：系统要采用ARM 64架构设计）
③ 过程约束 Process constraint：对用于构建系统的技术和资源的限制，涵盖资源、文档，标准等方面。
④ 非功能需求/质量 Quality requirement or non-functional requirement：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。（例：用户工资查询的响应式时间小于5秒）
6. 数据流图 DFD
便于用户理解和分析系统数据、流程的图形工具，摆脱了系统和具体内容，在逻辑上描述了系统的功能、输入、输出、数据流DS，是系统逻辑模型的重要组成部分
具体绘图也许要会吧（没说）
对数据流图的描述中出现控制流则判错
7. UML活动图
用于系统功能的建模，强调对象之间的控制流
UML类图 class diagram（以类和对象为基础，对简单的协作进行建模，以及对逻辑数据库模式进行建模）
系统结构的图形化工具
UML状态图 state diagram
对特定对象所有可能的状态、以及各种事件的发生而引起的状态转移，对于类/写作的行为建模非常重要
8. 依赖关系
依赖关系是类之间存在的短暂的非结构化的使用关系
聚合（has-a）：部分类对象是多个整体类对象的组合，例：一名学生同时参与多个兴趣小组；一个大雁群有多只大雁（大雁死去大雁群不会消失，两个对象生命周期不同；箭头指向大雁，空心菱形在大雁群那边）
组合：物理上由xxx组成，用实心黑色菱形；例如鸟有翅膀（两个类之间的关系，表示整体与部分，不能单独存在）
泛化/实现（is-a）：在一端有一个三角形来表示，用来表示类与类之间的继承关系，或者类对接口的实现关系（例如，鸟类继承抽象类动物，空心三角指向动物）
依赖：对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。（指向被依赖的对象，例如动物依赖氧气和水，箭头指向氧气和水）
关联：对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。
如何使需求变得可测试？
（1）指定每个副词和形容词的定量描述，这样限定词的含义就清楚、明确了
（2）用特定实体的名称替换代名词
（3）要确保在需求文档的某个地方，正确地定义每个名词。
在原型化需求方面，什么是抛弃式原型，什么是进化式原型？
原型化需求的目的：A: 有的需求难以用文字和符号说明,而原型化的过程可帮助我们找到“好的视觉和感觉”B：对非功能性需求，可以评价性能和效率
抛弃式原型：仅用于了解问题、探索可行性，并不打算用来作为将来实际提交系统的一部分，而是用完扔掉
进化式原型：用于了解问题，并作为将来准备提交的系统的一部分
这两种技术有时都称为快速原型化，因为它们都是为了回答需求的问题而构建软件。
利用自然语言进行描述的缺点 使用符号描述系统的优点
(1) 利用自然语言进行描述的缺点：所有使用者必须用同样的方式解释含义，很难做到；不易识别系统的各种元素
(2) 使用符号描述系统的优点：以严格可控的方式定义需求，使其易追踪和管理分类
用DFD图简单描述ATM机的工作原理（主要功能和数据流）（习题7）
第五章 软件系统设计
1-1. 什么是软件体系结构设计
软件体系结构定义：
- 【IEEE610. 12—1990】体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即软件体系结构={构件，连接件，环境，原理}
- 【Bass的定义】系统的一个或多个结构，包括软件构件、构件的外部可视属性和构件之间的关系
- 【国内】可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)
1-2. 设计模式 设计公约…
设计模式 design pattern：一种针对单个软件模块或少量模块而给出的一般性解决方案，它提供较低层次的设计决策。它是一个共同的设计结构的关键方面，包括对象和实例，角色和协作，责任分配，第六章详细讨论
设计公约 Design Convention：一系列设计决策和建议的集合，采取这些建议可以提高系统某方面的设计质量。当一种设计公约发展成熟时，将会被封装成设计模式或体系结构风格，最后可能被内嵌为一种程序语言结构
创新设计 innovation design：由脑海中闪现的灵感驱动，这种无规律的突发式进展正是创新性设计的特征
设计原则 design principle：是把系统功能和行为分解成模块的指导方针，描述一些良好设计的特征（优秀设计的可描述的特点）【好的设计所具有的可以描述的特征】
2. 软件体系设计过程
建模 分析 文档化 预审 SAD
软件设计过程模型的五个阶段：
- 初始建模：尝试对系统进行分解，根据需求描述的系统关键特性确定软件体系结构风格。
- 分析：分析软件系统的功能和质量属性、各种约束等。
- 文档化：确定各个不同的模型视图，进行文档化。
- 复审：检查文档是否满足所有功能及质量需求。
- 最终输出：软件体系结构图SAD。
3. 设计用户界面需要考虑的问题：
① prototype
② 文化差异的问题/用户爱好的问题
(1)设计界面要注意解决的要素：
①隐喻：可识别和学习的基本术语、图像和概念等
②思维模型：数据、功能、任务的组织与表示
③模型的导航规则：怎样在数据、功能、活动和角色中移动及切换
④外观：系统向用户传输信息的外观特征
⑤感觉：向用户提供有吸引力的体验的交互技术
(2) 文化问题：需要考虑使用系统的用户的信仰、价值观、道德规范、传统、风俗和传说。两种解决方法：①使用国际设计/无偏见设计，排除特定的文化参考或偏见②采用定制界面，使不同用户看到差异界面
(3) 用户偏爱：为具有不同偏好的人选择备选界面
4. 复审的概念 重要性
复审定义：检查文档是否满足所有功能及质量需求。
SAD的质量以以下两种方法评估：
(1) 验证verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确
(2)确认validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。
验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。
重要性：
(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流。
(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。
复审可以分为两类：
- 概念设计复审：与客户和用户一起检查概念设计。
- 技术/程序设计复审：让程序员可以参与复审，在程序实现之前获得本阶段的反馈。
什么是概念设计？什么是技术设计？
概念设计：确切地告诉客户系统要做什么
技术设计：一旦客户认可概念设计，系统构建人员就将概念设计转换为更为详细的文档，即技术设计，技术设计确切的告诉开发人员系统将如何运转。
概念设计强调的是系统功能，而技术设计描述的是系统将要采取的方式。
三种设计层及其关系
设计分三层：体系结构、代码设计和可执行设计
（1）体系结构将需求格式说明中确定的系统能力与实现这些能力的系统构件关联起来。
（2）代码设计包含算法和数据结构
（3）可执行设计在比代码设计的层次还要低的静态层次处理代码设计，讨论内存分配、数据格式、位模式等
关系：自顶向下设计有益的：首先设计体系结构，然后进行代码设计，最后是可执行设计
什么是模块化？什么是抽象？
模块化：把系统中各不相关的部分进行分离的原则，以便于各部分能够独立研究，也被称为关注点分离
抽象：对细节的隐藏称为抽象，是基于某种归纳水平的问题描述，使我们集中于问题的关健。
分解：把大的系统分解成为更小的部分使问题变得更易于处理，是一种自顶向下的方法；另一种自底向上的方法是将小的模块以及小的构件打包成一个更大的整体，被认为其设计出来的系统更加易于维护。
第六章 Designing the Modules
1. 设计模式
定义：设计模式（design paterns）代表了最佳的实践，通常被有经验的面向对象开发人员所用，是软件开发过程中面临的一般问题的解决方案。
2. OO设计的基本原则
1.模块化 modularity
把系统中各不相关的部分进行分离的原则，以便于各部分能够独立研究，也被称为关注点分离
很好的利用该原则的优点：
- 易理解和开发
- 易定位缺陷
- 易更改/维护
2.接口 interface
软件系统有一个外部边界和一个对应的接口，通过这个接口软件系统可以感知和控制它的环境
定义了该软件单元提供的服务以及如何获取这些服务
一个对象的接口是该对象所有公共操作以及这些操作的签名的集合，指定了操作名称、参数和可能的返回值
接口描述了它向环境提供哪些服务以及对环境的需求
3.数据隐藏 information hiding
将一个设计决策封装在软件单元中，对外不可见
实现深度模块最重要的技术是信息隐藏。
4.增量开发 incremental development
利用单元之间的依赖关系设计一个增量式设计开发进度表
为每个软件单元和它依赖的单元之间建立联系
…
5.抽象 abstraction
抽象是一种忽略一些细节来关注其他细节的模型或者表示
关于模型中哪部分细节被忽略是很模糊的，因为不同的目标会对应不同的抽象，会忽略不同的细节
6.通用性 generality
使得软件单元尽可能的成为通用软件，来提高他在未来的系统中可能有用的机会
使unit变得通用的方法：
- 将特定的上下文环境信息参数化，比如将读入数据的路径参数化，来区分是读本地路径还是服务器路径
- 去除前置条件，前置（限制）条件越少，越通用
- 简化后置条件，比如返回值封装成对象
高内聚与低耦合是每个软件开发者追求的目标
3. 耦合
耦合：两个软件之间的相互关联程度，耦合程度取决于模块之间的依赖关系的多少
会考解释（记住概念），也要学会举例子（下方的图也要记忆）
- content coupling 内容耦合
当一个模块修改了另一个模块的内部数据项/代码，或一个模块的分支转移到了另外一个模块时，就会产生内容耦合
- Common coupling 公共耦合
对公共数据的改变意味着需要反向追踪所有访问过该数据的模块来评估该改变的影响
- Control coupling 控制耦合
当某个模块通过传递参数或者返回代码来控制另一个模块的行为
受控制的模块如果没有收到来自控制模块的指示，是不能完成其功能的
- Stamp coupling 标记/特征耦合
在两个模块间传递的时复杂的数据结构，代表了在模块间的复杂的接口
- Data coupling 数据耦合
模块间传递的是数据值，这是最受欢迎的一种耦合。如一个数值被当做参数传递给另一个模块，这个数值在另一个模块中只会参与计算而非控制。
非直接耦合了解即可（不做要求）
4. 内聚（下图要会，还需要弄清楚概念）
内聚：模块内部各组成成分(如数据、功能、内部模块)的关联程度，内聚度越高，模块间各成分相互关系越密切。
- 偶然内聚 coincidental
模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法
- 逻辑内聚 logical
模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。比如因为有相同的某一个计算步骤而放在一起的两个没有关系的计算。
- 时间内聚 temporal
部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。
- 过程内聚 procedurally
要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程
- 通讯内聚 communicational
各部分访问和操作同一数据集，如将来自于同一传感器的所有不相干数据取出这一模块
- 顺序内聚 sequential
各部分有输入输出关系，操作统一数据集，并且操作有顺序
顺序内聚是指在一个模块内的多个组件之间存在“一个组件的输出是下一个组件的输入”这种“流水线”的关系
- 功能内聚 functional
理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序
功能内聚堪称最强内聚。在这种内聚中，每个组件单拿出来都不构成一个独立的业务功能；只有组合成一个整体，才能形成完整的功能。
- 信息内聚 information
将功能内聚调整为数据抽象化和基于对象的设计就是信息内聚
5. UML cases画法
了解UML其他图示的基本用途 那些图能表示同构啊…
静态图：
- UML类图：描述对象类型及静态关系
- UML对象图：可以看作类图的特殊用例（实例和类可以在其中显示）
- UML包图：类进行打包，使设计更加层次化，易于理解，包图就是这个层次的图
- UML构件图：说明运行时的构件以及它们之间的交互
- UML部署图：描述如何为构件分配计算资源
动态图：
- 用例图：描述系统必须执行的一般过程（是从用户使用系统的角度描述系统功能的图形表达方法）
可以用类图来描述
- UML活动图（程序框图）：描述业务活动的工作流模型，显示对象的值更改时系统中可能发生的所有活动
- UML状态图：展现一个对象所具有的所有可能的状态，并且它们在接收到什么信息时会进行怎样的转化
- 交互图 Interaction Diagram【顺序图和协作图是同构的】
- UML顺序图（时序图）：展示活动或行为发生的顺序（描述了一组交互对象间的动态协作关系，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序）
- UML通信图/UML 协作图：使用对象与对象之间的连接来描述对象间的消息顺序（与时序图相似，但顺序图强调时间顺序，通信图强调空间顺序）
6. 画UML图如何发现类？
一些能够为确定类而提供建议的条目：Actors（参与者）、physical objects（物理对象）、places（场景）、organizations（组织）, records（记录）, transactions（交易）, collections of things（事物的集合）, operations procedures（操作过程）, things manipulated by the system to be built（系统会操纵的事物）
根据系统的第一个需求，暂定类
以下面的问题为指导，判断候选类中应该包括哪些类：
①哪些数据需要以某种方式被处理
②哪些项目有多种属性
③什么时候一个类有多种对象
④什么是基于需求本身的，而不是对需求的理解中导出的
⑤什么属性或操作总是适用于一个类或对象
第七章 编写程序
1. 一般性的编程原则
- 控制结构：要让程序设计反映出在体系结构和设计中的各种控制结构。
- 算法：程序设计通常会制定一类算法，用于编写组件。
- 数据结构：编写程序时，应该安排数据的格式并进行存储，让数据结构决定项目结构，并尽可能以此简化程序。
2. 在编写程序内容文档时，除了HCB（头注释块），还应该包含什么
HCB、有意义的语句标识、其他程序注释、排版格式、文档化数据
3. 敏捷方法的大致思想、极限（XP）编程， 结对编程
①秉承敏捷宣言，体现如下思想：拥抱变化、自我组织、简单至上、有效沟通、精益求精（ppt有一页）
②XP是一种轻量级的软件开发方法论，属于敏捷编程，其主要的特征是：适应环境变化和需求变化，充分发挥开发人员的主动精神
③结对编程也属于主要的敏捷开发方法，其方式为两个程序员共同开发，且分工明确，一个负责编写程序，另一个负责复审与测试，最重要的是两人定期交换角色。
为什么说编码工作纷繁复杂甚至令人气馁？
（1）设计人员可能没有处理平台和编程环境的所有特性。易于用图表描述的结构和关系并不是总能够直截了当的编写成代码
（2）我们必须以这样一种方式编写代码：不仅要在再次使用代码进行测试的时候便于自己理解，而且当系统随着时间演化时，也便于他人理解
（3）在创建易于复用的代码的同时，还必须利用这些特征：设计的组织结构、数据结构、编程语言的概念。
论述编码阶段实现某种算法时所涉及的问题。
（1）编写更快代码的代价。可能会是代码更加复杂，从而要花费更多的时间编写代码
（2）测试代码的时间代价。代码的复杂度要求有更多的测试用例或测试数据
（3）用户理解代码的时间代价。
（4）需要修改代码时，修改代码的时间代价。
第八章 测试程序
1. 软件产生缺陷的原因
①需求错误（不是客户想要的）、需求缺失、需求不可实现
②错误的设计、错误的代码
③设计正确但是设计实现不正确
…
编码啊测试啊都会出现… # 待补充
2. 主要的缺陷类型
①算法缺陷(algorithmic fault)：由于处理步骤的某些错误，使得对于给定的输入构件的算法或逻辑没有产生适当的输出
②计算(computation fault)和精度缺陷(precision fault)：公式的实现是错误的，或者计算的结果没有达到要求的精度
③文档缺陷(documentation fault)：文档与实际做的事情不一致
④压力(stress fault)或过载缺陷(overload fault)：填充数据结构时超出规定的能力
⑤能力(capacity fault)或边界缺陷(boundary fault)：系统活动达到指定的极限时，系统性能变得不可接受
⑥计时(timing fault)或协调故障(coordination fault)：多线程执行，进程间的协调问题
⑦性能故障(performance fault)：系统不能以规定的速度执行
⑧硬件和系统软件缺陷(hardware and system software fault)：提供的硬件和软件并没有按照文档中的操作条件和步骤运作
⑨标准和过程缺陷(standards and procesure fault)：代码不符合标准
⑩恢复性缺陷(recovery fault)：系统失效时，程序无法再恢复也是一种缺陷；
主要的缺陷类型（10种）：
- 算法缺陷：算法某些处理步骤或逻辑有问题，导致软件的部件对于输入数据不能给出正确的输出；
- 计算和精度缺陷：算法或公式在编程实现时逻辑没错，但是计算过程出现了错误或者精度达不到要求，从而无法获取正确输出；
- 过载缺陷（压力缺陷）：程序运行时，数据填充量会超过数据结构的规定容量**引起的缺陷；
- 能力缺陷（边界缺陷）：系统活动量达到系统极限时，系统性能变的不可接受，称为能力缺陷；
- 性能缺陷（吞吐量缺陷）：系统在常规状态下就不能以需求规定的速度执行；
- 时序性缺陷（协调缺陷）：几个同时或有严格执行顺序的进程协调出现问题；
- 文档缺陷：文档描述与程序实际行为不符；
- 恢复性缺陷：系统失效时，程序无法再恢复也是一种缺陷；
- 硬件和系统软件缺陷：作为底层支持的硬件和系统软件没有按照文档中的操作条件和步骤运作时，也可引起软件的问题；
- 标准和规格缺陷：代码没有遵守组织机构的标准和过程。这个缺陷最大的影响在于：不按照标准的代码可能在测试和修改时让人不好理解，引起问题。
正交缺陷分类：使任意一个缺陷只属于一个类别的缺陷分类方案称为正交缺陷分类。
如果故障属于不止一个类，则失去了度量的意义。
3. 测试的各个阶段和任务
测试的各个阶段如上图所示，具体包括：
- 单元测试：验证组件的功能。依据文档：程序代码与配套文档。
- 集成测试：验证系统组件是否能正确的协同工作。依据文档：系统体系结构文档SAD、程序设计规格说明。
- 功能测试：验证系统是否能执行需求规格说明中描述的功能。依据文档：软件需求规格说明书SRS。
- 性能测试：验证系统的软硬件表现和性能是否符合需求规格说明文档。这一步之后，软件系统应当能在客户的实际工作环境中成功执行，这时我们说产生了一个被确认的系统。依据文档：软件需求规格说明书SRS。
- 验收测试：验证系统是否满足了客户的需求定义（需求定义和需求规格说明是有区别的）。依据文档：客户需求定义。
- 安装测试：验证系统能否在用户使用的真实环境中安装并正常运行。依据文档：用户环境的说明。
系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。
4. 测试的态度
为什么需要独立的测试团队？
新程序员不习惯将测试看做是一个发现的过程，可能仅仅将程序视作问题的解决方案，为没有考虑问题本身。但是客户对系统的在某些条件下能够运行并不感兴趣，相反，他们感兴趣的是确保系统在所有条件下都能适当运行。所以，作为一个开发人员，无论故障出现在系统的何处，也无论是谁引起这些故障，你的目标应该是尽可能多地去除故障。
将测试看做是一个发现的过程，而不是仅仅将程序视作问题的解决方案，应该考虑问题本身。当发现故障时，应该关注修改故障，而不是谴责开发人员。
为了从测试过程中排除个人情感，通常是用一个独立的测试小组来测试系统，这样就避免了故障的个人责任与可能多地发现故障的需要之间的冲突。
5.【必考！】 测试方法：黑盒测试和白盒测试
黑盒测试：从外部观察测试对象，将其看作是一个不了解其内容的黑盒，向黑盒提供输入数据并记录产生的输出，基于程序功能和性能
- 优点：不受测试对象内部结构和逻辑的约束
- 缺点：测试是非完备的
白盒测试：根据测试对象的内部结构，用不同的方式来测试 ，或者说是基于程序的内部结构来设计测试用例
- 优点：覆盖面广、完备
- 缺点：工作量大，无法测试遗漏路径
以下步骤也要学会
步骤一：根据程序逻辑画出流程图
步骤二：将流程图转换为流图
流图：刻画程序控制结构但不涉及程序过程性细节
步骤三：确定基本路径集合
步骤四：针对测试路径设计测试用例
步骤五：运行程序检验测试用例
运行待测试的程序代码
逐个输入测试用例
分析程序的运行路径
如果运行路径与期望路径不一样，则存在缺陷
黑盒测试——等价分类法
输入条件为一范围
划分出三个等价类：
(1) 有效等价类(在范围内)，(2) 大于输入最大值，(3)小于输入最少值
输入条件为一值
划分为三个等价类
(1) 有效，(2) 大于，(3) 小于
输入条件为集合
划分二个等价类
(1) 有效(在集合内)，(2) 无效(在集合外)
输入条件为一个布尔量
划分二个等价类
(1) 有效(此布尔量)，(2)无效(布尔量的非
黑盒测试——边界值分析法
输入条件是一范围(a,b)
a,b以及紧挨a,b左右的值应作为测试用例
输入条件为一组数
选择这组数最大者和最小者，次大和次小者作为测试用例
如果程序的内部数据结构是有界的
应设计测试用例使它能够检查该数据结构的边界
要会设计测试用例 啥多少个输出
6.单元测试
发现构件中的故障
①通过程序对代码审查
②编译代码、排除语法错误
③开发测试用例
测试用例的概念：以测试程序为目的而挑选的输入数据，包含对应的期望结果 测试用例是一个四元偶（包含输入条件、前置条件、测试步骤、预期数据）
7.集成测试及主要方法的分类
①将构件组合在一起进行测试，使得发生失效时，能够对导致引起失效的原因有所了解
②方法分类：自底向上、自顶向下、一次性集成、三明治集成 # 有图
分类：
1、自底向上集成
含义：使用这种测试方法的时候，每一个处于系统层次中最底层的构件先被单独测试，接着测试的是那些调用了前面已测试构件的构件。反复采用这种方法，直到所有的构件测试完毕。
先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。
2、自顶向下集成
含义：顶层构件通常是一个控制构件，是独立进行测试的。然后将被测构件调用的所有构件组合起来，作为一个更大的单元进行测试。重复这样的操作直到所有的构件都被测试。
先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。
3、一次性集成
先测试每一个模块，之后将所有模块一并集成。
先测试每一个构件，然后将所有的构件一次性的集成。只适用于小型系统。
4、三明治集成
将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。
8.传统测试方法跟OO测试的区别
在需求分析和验证阶段：：需求文档缺乏工具支持，很多时候需要人工
测试用例生成：对过程语言而言，系统改变时，我们可以针对改变测试是否正确，并使用原有测试用例验证剩余功能是否同原来一致。但是面向对象测试中，我们可能需要编写不同的测试用例（测试工具生成的测试用例，处理面对对象模型中的对象和方法时针对性不强）
源代码分析：传统的测试方法在评价OO系统的规模和复杂性时，还不是很有效，没有太强针对性
覆盖分析：对象的交互是面向对象系统复杂性的根源，传统的测试方法和根据/依据的作用有限
面向对象测试与传统测试的区别：
(1) 测试用例的充分性：对过程语言而言，系统改变时，我们可以针对改变测试是否正确，并使用原有测试用例验证剩余功能是否同原来一致。但是面向对象测试中，我们可能需要编写不同的测试用例
(2) 面向对象趋于小粒度，并且平常存在于构建内的复杂性常常转移到构件之间的接口上，这意味着，其单元测试比较容易，但是集成测试涉及面更加广泛
(3) 传统测试和面向对象测试主要集中在：需求分析和验证、测试用例生产、源码分析和覆盖分析
面向对象测试的难度
(4) 需求文档缺乏工具支持，很多时候需要人工
(5) 测试工具生成的测试用例，处理面对对象模型中的对象和方法时针对性不强
(6) 源代码分析：传统的测试方法在评价OO系统的规模和复杂性时，还不是很有效，没有太强针对性
(7) 覆盖分析：对象的交互时面向对象系统复杂性的根源，传统的测试方法和根据/依据的作用有限
9.构件驱动component driver
a runtine that calls a particalar component and passes a test case to it.
一种特殊类型的软件组件，用于调用正在被测试的组件，并为其提供假设的输入数据，以检查其正确性
集成测试及其主要方法的分类？（驱动模块、桩模块的概念）
构件驱动程序：在测试最底层的构件时，因为没有现成的已测试的构件调用底层的待测试构件，所以我们需要编写特定的代码来辅助集成。构件驱动程序就是调用特定构件并向其传递测试用例的程序，即代替上级模块传递测试用例的程序。
桩(stub)：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。
将软件缺陷进行分类的理由：
在编码完程序构件之后，我们通常对代码进行检查，以找出故障并立刻去除它们。当不存在明显的故障时，我们测试程序，通过创造一些条件，使代码不能像计划的那样做出反应，看一看能否发现更多的故障。因此，知道我们正在
查找什么类型的故障是很重要的。
什么是走查和检查？
走查：不正式的的代码评审。
检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。
第九章 测试项目
0. 测试的各个阶段和任务
1. 回归测试
当现行系统被纠正/更改/更新时，识别出可能引入的新的缺陷，验证新版本/新发布跟老版本的功能一样
2. 几种测试分类
〇 benchmark test（基准测试）
由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。
①pilot test（引导/先导测试）
在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。
②α测试：软件开发公司组织内部成员模拟各类用户行为，对即将面世的产品（又称为α版本，或内部测试版本）进行测试，发现错误并纠正
③β测试：软件开发公司组织各方面的典型用户在日常工作中实际使用β版本或对外宣传将β版本免费赠送给典型用户，并要求用户报告异常情况、提出批评意见。
安装测试
定义：在用户环境中配置系统，以测试可能因为开发环境与用户环境的不同而导致的问题
目的：安装系统的完备性，验证任何可能受场所条件影响的功能和非功能特性。
适应性、正确性、完善性、预防性（测试分类）
补充：一个软件上线之后，为其增加了一个摄像头，是完善性（加了一种途径去查看软件运行…）
依赖于银行，银行发生改变，我们的软件必须发生改变，属于什么维护？ 适应性
正式技术评审 formal technical review
不可能避免软件存在问题，只能尽可能少的去减少bug
功能测试
(1) 功能测试含义：测试需求设计的功能性需求
(2) 作用：有很高的故障检测概率
(3) 功能测试指导原则
- 有较高的查错概率
- 独立的测试团队
- 了解预期的输出结果
- 对合法与非法的输入都予以测试
- 不能仅仅为了测试方便修改系统
- 停止测试应该有前提条件
性能测试的含义与作用？
性能测试与需求的质量有密切的关系，需求文档需要足够完备才能确保性能测试的成功进行。因此需求的质量通常可以反映在性能测试的容易度上。
含义：测试非功能性需求。
作用：确保系统的可靠性、可用性和可维护性。
性能测试由测试小组进行设计和执行并将结果提供给客户。
性能测试的主要分类？
压力测试/强度测试(短时间内加载极限负荷，验证系统能力)
容量测试/巨量数据测试(验证系统处理巨量数据的能力)
配置测试(构建测试用例对系统软硬件的各种配置(最小到最大)进行测试)
兼容性测试(测试接口等。如果它与其他系统交互时)
回归测试(如果这个系统要替代一个现有系统时需要进行此测试)
安全性测试：确保安全性需求得到满足。
计时测试：评估涉及对用户的响应时间和一个功能的执行时间的相关需求。
环境测试：考察系统在安装场所的执行能力。
质量测试：评估系统的可靠性、可维护性和可用性。
恢复测试：强调的是系统对出现故障或丢失数据、电源、设备或服务时的反应。
维护测试：为了帮助人们发现问题的根源提供诊断工具和过程的需要。
文档测试：确保已经编写了必需的文档。
人为因素测试：检查设计系统用户界面的需求。
什么是可靠性、可用性和可维护性？
可靠性：指一个系统对于给定的时间间隔内、在给定的条件下无失效运作的概率。
可用性：指在给定的时间点上，一个系统能够按照规格说明正确运作的概率。
可维护性：在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。