现代软件工程复习

2021现代软件工程考试复习指南

根据课件中的以下基本内容，适当的扩展阅读一些材料来复习。
可以说是相当的多了
干货满满，准备好吐吧~~

---

---

第一章：软件工程概述

1.理解什么是软件工程，软件工程包含那些领域，以及为何要搞软件工程？

软件工程
是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。

软件工程包括下列领域
软件需求分析、软件设计、软件构建、软件测试和软件维护。

软件工程和下列的学科相关
计算机科学、计算机工程、管理学、数学、项目管理学、质量管理、软件人体工学、系统工程、工业设计和用户界面设计。

因为需求复杂
要满足不同类型用户的多种需求，并且能长时间提供服务

因为系统太复杂
The effort is necessitated by the potential complexity of those systems, which may contain millions of lines of code.这些努力是必要的，因为这些系统可能包含数百万行代码。

因为人们的生命，财产依赖于软件
Millions of dollars, people’s life, business depends on it. 几百万美元，人命，生意都取决于它。

2.理解软件的特性

复杂性
软件的各个模块之间有各种显性或隐性的依赖关系，随着系统的成长和模块的增多，这些关系的数量往往以几何级数的速度增长。
不可见性
但是几乎无法完整重现到底程序出现了什么问题。
易变性
a) 让软件做新的事情；b) 让软件适应新的硬件。但是与此同时，正确地修改软件是一件很困难的事情
服从性
软件不能独立存在，它总是要运行在硬件上面，它要服从系统中其他组成部分的要求，它还要服从用户的要求、行业系统的要求
非连续性

新特性：
有许多不同的程序设计语言、
软件工具和软件开发平台
存在许多不同的软件开发流程
软件团队中存在许多不同的角色
软件通常既可以存储在磁带上，也可以存储在CD/DVD上
AI 可以写程序， GitHub 社区

软件开发会越来越容易么?
No Silver Bullet / 没有银弹 没有一种大规模提高软件开发效率的快速办法，将来也没有

这里的Silver Bullet让我想起了赤井，一个能够打穿黑衣组织的男人，赤井假死后干妈就将此称号颁发给了工藤新一

---

第二章：软件工程概述

1.掌握基本的单元测试技术，能够根据给定的程序写出相应的测试案例

对软件基本组成单元进行的测试，其测试对象是软件设计的最小单位（模块或者类）。
A.行覆盖（又叫语句覆盖）就是通过设计一定量的测试用例，保证被测试的方法每一行代码都会被执行一遍。

B.判定覆盖的含义就是代码里每一个判定都要走一次全true，一次全false。

C.条件覆盖和判定覆盖类似，不过判定覆盖着眼于整个判定语句，而条件覆盖则着眼于某个判断条件。

D.路径覆盖 覆盖所有可能执行的路径。

2.了解什么是回归测试

回归测试是一种软件测试，用于 确认最近的程序 或 代码更改未对现有功能产生不利影响。
Regress 的英语定义是：return to a worse or less developed state，是倒退、退化、退步、回归的意思。
如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这 个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化（回归）到不正常工作的状态。
针对一个Bug Fix，我们也要做Regression Test。目的是：
1. 验证新的代码的确改正了缺陷
2. 同时要验证新的代码有没有破坏模块的现有功能，有没有Regression

Right－结果是否正确？
Border Condition－是否所有的边界条件都是正确的?
Inverse Relation: 能查一下反向关联吗？
Cross check: 能用其他手段交叉检查一下结果吗？
Error－你是否可以强制错误条件发生？
Performance－是否满足性能要求？

---

第三章：个人软件流程

Personal Software Process

1.PSP2.1里的各项指标的含义

2.PSP优缺点

优点：
不局限某一种软件技术（如编程语言），而是着眼于开发流程，便于比较。
不依赖于考试，而主要依赖于工程师自己收集数据，然后分析，提高。
缺点：
在小型的创业团队，很难找到高质量的需求分析文档
导致后续的活动非常随机，开发活动可能随时变化
依赖于数据
要求开发人员手动记录所有活动，如何处理丢失数据或者不准确？
记录 “工作大小”
代码行数是唯一的衡量?
重用代码，用别人的类库 vs. 自己从头写
开发者删除了2000行有问题的代码，他的绩效如何？
衡量最终的结果么?
目前衡量了工程师如何有效地实现了软件需求
但是没有衡量用户是否对产品满意.
Windows 8 把 “开始” 按钮取消了， 工程师完美地执行了任务， 用户满意么？

3.理解软件工程师的四个误区

分析麻痹 100%才出手
依赖链条过长 不分主次，想解决所有问题
过早优化 没有着眼当前，思考离自己最近的问题。
过早泛化 没有从简单的项目开始，好高骛远

---

第四章：两人合作

1.了解代码复审的三种形式

2.掌握“代码复审核查表”的“概要部分”

1）代码符合需求和规格说明么？
2） 代码设计是否考虑周全？
3） 代码可读性如何？
4） 代码容易维护么？
5） 代码的每一行都执行并检查过了吗？

3.理解好的复审者的“更高要求”

“这么修改之后，有没有别的功能会受影响?”避免“回归”

“项目中还有别的地方需要类似的修改么?”不要改了一处忘记了其他相同之处（统一修改）

“有没有留下足够的说明，让将来维护代码时不会出现问题？对于这样的修改，有没有别的成员需要告知?”注释要写好，告知相关人员

“导致问题的根本原因是什么？我们以后如何能自动避免这样的情况再次出现?”前车之鉴，后车之师

4.理解结对编程，其优缺点，以及合适和不合适的场景

优点：
提高设计质量
更好的设计，避免愚蠢的bug，
降低成本
分享知识，更少的debug 时间
提高解决问题的信心
结对经常能解决 “不可能的任务（1987 ，Intuit）
“很多有经验的工程师觉得结对编程效率不高”
他们单独编程了 10 年，结对了1 小时，就觉得效率不高，很正常。 结对100 小时之后再评价。
提高士气
觉得自己的工作有另一人认可.
减轻风险
在团队中有一些 “知识的冗余”，降低了成员离开的负面影响
提高效率
两人在一起不好意思偷懒或开小差上网

缺点：
工作方式的不同，大多数人觉得喜欢一个人工作
让人感觉到威胁 ，新手 vs. 老手
时间可能花在培训上面 （也有价值），老手 vs. 新手
对个人情绪，自尊的影响，“my code” vs. “your code”

合适的场景：
降低容易犯的错误，新手 + 新手， 或者双方各有明显弱点
探索一个新的领域
传播知识和技能，老手 + 新手 也可以

不适合的场景
1、需要深入地研究的项目，需要一个人长时间的独立钻研；
2、在做后期维护的时候，如果维护的技术含量不高，只需要做有效的复审即可；
3、如果验证测试需要运行很长时间，那么两个人在那里等待结果是有点浪费时间；
4、如果团队的人员要在多个项目中工作，不能充分保证足够的结对编程时间，那么成员要经常处于等待的状态，反而影响效率；
5、关键是如何最大限度地发挥“领航员”的作用，如果用处不大，也就无需结对。

---

第五章：团体软件流程

1.了解瀑布模型及其变体的优缺点

Waterfall Model 瀑布模型
它反映了软件开发的串行的，连贯的步骤

优点：
每一步的结果都是可验证的
减少风险
给团队提供稳定的流程支持
缺点：
直到周期结束才会生产软件
适用于：
产品定义非常稳定，正确性重要，每一步都要被验证
使用的技术非常成熟，团队成员对这些技术也非常熟悉
子团队在不同的地理位置，不可能做到频繁的交流

变体：
Sashimi Model 生鱼片模型

优点
解决了各个步骤分离的缺点（重叠）
有助于降低完全分离阶段的成本
缺点
什么时候上一个步骤结束呢？结束时间？

Waterfall with Subprojects 瀑布模型和子项目

分而治之
风险
Unforeseen interdependencies不可预见互相依赖
Cost of integration 集合的成本

Spiral Model 螺旋模型

优点
在每一个版本都要衡量并控制风险
随着投入的增加和产品的运行，产品失败的风险在降低
缺点
需要高水平的管理团队
很难明确定义目标和稳定的里程碑
适用于
未知复杂的项目和knowledgeable, skillful牛逼的团队

2.了解RUP的大致内涵

从瀑布模型开始的各种模型都有一个共同点：
重计划，
重事先设计，
重文档表达。
这一类的方法中集大成者要算Rational统一流程（Rational Unified Process，RUP），它把软件开发的各个阶段整合在一个统一的框架里。
RUP 的具体流程：
页需分设实测步

RUP 工具，里程碑
一个项目分为几个里程碑 （milestone）
每个里程碑内部有几个迭代（iteration）
环境
向开发团队提供开发环境，过程和工具
配置和变更管理
项目管理

---

第六章：敏捷流程

1.了解敏捷流程产生的背景

最初的软件：这些项目对功能的要求非常严格，对计算的准确度要求相当高
桌面软件：开发周期明显缩短，各种新的方法开始进入实用阶段 做好一个发布需要较大的经济投入，不能频繁更新版本
互联网时代：网络的传播速度和广度，使得知识的获取变得更加容易，很多软件服务可以由一个小团队来实现 技术更新的速度在加快，用户需求的变化也在加快，开发流程必须跟上这些快速变化的节奏。于是敏捷就产生了

2.理解敏捷流程和传统做法的区别

3.理解敏捷流程的原则

A.尽早并持续地交付有价值的软件以满足顾客需求。
B.敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。
C.经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。
D.业务人员和开发人员在项目开发过程中应该每天共同工作。
E.以有进取心的人为项目核心，充分支持信任他们。
F.无论团队内外，面对面的交流始终是最有效的沟通方式。
G.可用的软件是衡量项目进展的主要指标。
H.敏捷流程应能保持可持续的发展。 领导、团队和用户应该能按照目前步调持续合作下去。
I.只有不断关注技术和设计才能越来越敏捷。
J.保持简明 - 尽可能简化工作量的技艺 - 极为重要。
K.只有能自我管理的团队才能创造优秀的架构, 需求和设计。
L.时时总结如何提高团队效率, 并付诸行动。

4.理解SCRUM的角色以及流程

SCRUM是一种迭代的、增量的项目管理方法，经常出现在敏捷软件开发中。

角色：

A.敏捷教练，维持着流程（项目经理）
B.产品拥有者，代表利益相关者和企业
C.团队，一个跨职能小组，负责实际的分析、设计、实现、测试等工作

流程：

第一步：

找出完成产品需要做的事情 — Product Backlog.
产品负责人领导大家对于这个 Backlog中的条目进行分析，细化，理清相互关系，估计工作量，等工作。每一项工作的时间估计单位为“天”。

第二步：

决定当前的冲刺（Sprint）需要解决的事情 — Sprint Backlog。 整个产品的实现被划分为几个互相联系的冲刺（Sprint）。产品订单上的任务被进 一步细化了，被分解为以小时为单位（参见 WBS 工作划分的办法）。如果一个任务的估计时间太长（如超过 16 个小时），那么它就应该被进一步分解。
订单上的任务是团队成员根据自己的情况来认领。
团队成员能主导任务的估计和分配，他们的能动性得到较大的发挥。

第三步：

冲刺（Sprint）,团队按照backlog 任务执行
在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum 大师（Scrum Master）来完成。

第四步：

得到软件的一个增量版本，发布给用户。
然后在此基础上又进一步计划增量的新功能和改进。

5.敏捷和计划驱动的适用范围

---

第七章：软件需求

1.知道需求的分类

对产品功能性的需求： （略）
对产品开发过程的需求：要求软件的开发流程必须满足某些约束条件，例如，开发过程必须产生某种类型的文档，必须在某个时间点达到某个状态，必须对源代码施以某种约束（安全性核查、代码版权核查、代码规范和支持文档的核查）。
非功能性需求：这也叫“服务质量需求”（Quality of Service Requirement），例如，股票交易系统必须在一定时间内返回用户查询结果（它对时间的要求比“科技文献检索”网站 要高），火车票购票系统、大学选课软件必须能支持一定数量的用户同时访问，等等。
综合需求：有些需求并不是单单一个软件模块就能满足，例如，“购物网站必须在24小时内把货物发送到用户手中”，这个需求牵涉到软件系统、货物派送系统、送货部门、监控系统等不同部门的功能和执行能力。

2.能够知道利益相关者分别有哪些对应的需求

最终用户
顾客 (决定购买的客户)
市场分析者
监管机构
软件工程师
产品创始人

软件开发不可能一次满足所有利益相关者的需求，但是我们一定要让相关角色在这个阶段有机会提出他们的需求和意见，同时，要弄清楚“他们想从软件中得到什么”。

3.了解焦点小组和问卷调查方法的优缺点

焦点小组：

找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等等。
优点：
求同存异：一群人在一起，往往大家会出于讨好其他人的心理来发表意见，避免不一致的意见或冲突。

弱点：
1、参与讨论的人士表达能力也会有差异，有可能会出现一些善于表达的人士控制讨论议程的倾向。
2、讨论者对于他们不熟悉的事物（例如全新的市场、颠覆式的创新）不能表达有价值的想法
3、讨论者容易受到主持人有意或无意的影响。
4、研究者往往从不同意见中挑选最符合自己利益的那些条目，然后对外号称这就是大家的共识。

以上这些特点要求会议的组织者要有很强的组织能力，能让不同角色都充分表达意见，并如实地总结这些意见。这种形式也叫做推进会议（Facilitated Meetings）。

问卷调查方法：

优点：
范围广，基数大
不同人群看法
弱点：
定义不明确， 使用含混的形容词
让用户花额外的努力来回答问题
问题问题
带有引导性的问题
过于开放式的问题
选择过于狭窄的问题

4.能够把功能合理的分在四像限中

维持：以最低的成本维持此功能

抵消：快速地达到“最够好”、“和竞争对手差不多”

优化：花大力气做到并保持行业最好

差异化：产生同类产品比不了的功能或优势

不做：砍掉一个功能

---

第八章：典型用户和场景

1.能够对一个产品选取合理的典型用户并能描述典型场景

Persona（典型用户/角色）
有了典型用户之后，我们还得决定每一个典型用户的目标
他/她使用系统想要达到什么目的（如：购物者，产品提供商，滥发广告者……）对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事/Story。

---

第九章：项目管理

Pm：program manager微软的职位名称

1.知道风险的分类

2.能够合理的列出项目的风险

3.能够知道如何合理的处理风险

Risk 1: 任务比我们想象的要困难许多，原来制定的日程太乐观。

Explanation: 软件固有的特性，人员缺乏估算能力和经验，项目日程没有充分讨论。

补救办法: 让团队多做估算练习 （wide-band delphi 等练习），老员工给新员工传授经验；分析类似项目的日程；让团队充分参与项目估算流程。 尽早和项目的利益相关者沟通，尽早提出项目延期的问题。把长期项目规划为短期里程碑，能很快看到项目延期的问题。

Risk2: 需求爆炸，我们要做越来愈多的功能。

Explanation:

随着项目的进展，我们发现在项目初期没有发现的问题必须要解决，从而影响了原定的日程。

Solution:

承认这是软件项目经常出现的事实

确保意外出现的需求不影响当前的里程碑

制定长度合适的里程碑，确保问题能尽快浮现

经常和客户+开发人员交流，确认项目的需求。

Risk3: 人员流失 (或请假)

Explanation:

关键人物离开团队，项目的关键信息丢失，人力资源减少，导致项目困难.

Solution:

在团队持续鼓励合作和分享，所有代码必须在源代码服务器上，源代码的每一次修改都有记录，所有任务必须在项目管理工具中

鼓励结对编程，代码复审，共同拥有代码，经常报告各种进展和问题。

让多人参与关键模块的工作.

短期的里程碑保证某功能在较短时间得到改进，不让功能处于 “半完成” 状态

Risk4: 低质量的规格说明书 spec

Explanation: 当开始具体实现和集成的时候，发现spec 包含了相互冲突的需求，或者说明不完备.

Solution:

让客户或者客户的代表，代理来参加需求分析和spec 复审.

运用场景驱动的方法尽早模拟几个模块集成后能给用户带来什么好处.

尽早用 desig by contract* 的方法来保证模块之间能相互支持

Risk5: 团队效率低下

Explanation:

在长期项目中，团队成员失去了紧迫感，缺乏真实世界的反馈，大部分时间浪费在不紧急的事情上.

解决方案:

短期的里程碑和冲刺阶段 – 人们 （学生）通常等到deadline 临近的时候才开始行动.

Parkinson‘s Law: “Work expands to fil* the time available”

不断发布/收集反馈，让团队感受真实的需求

---

第十章：软件设计（只参考UML附件和UML相关书籍）

1.根据系统的基本描述，能够画出合适的用例图、类图、活动图和顺序图。

用例图

1.需求与用例
2. 参与者(Actor) ：
指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
3. 用例(Use Case)：
用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
通讯关联(Communication Association) ：
用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。
4. 关系
继承




参与者:外部参与者(用户/其他系统)
用例:功能
关系
包含关系:一个用例包含另一个用例(不可或缺)
拓展关系:一个用例存在是为了拓展另一个用例(锦上添花)
继承关系:一个用例继承自一个用例
依赖关系:一个用例依赖另一个用例

用例图可参考： UML用例图详解

类图

关系：

实现: 类实现接口 , [表现] implements
泛化: 类继承类 , [表现] extends
组合: 特殊的关联关系, 是整体与部分的关系, 部分与整体同生命周期, [表现] 成员变量
聚合: 特殊的关联关系, 是整体与部分的关系, 部分与整体不同生命周期, [表现] 成员变量关联: 一个类知道另一个类的行为(方法), [表现] 成员变量
依赖: 一个类的实现需要另一个类的协助, [表现] 局部变量、方法的参数或者对静态方法的调用

关系强弱:
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

示例说明:

汽车和飞机实现交通工具接口
引擎组合成汽车,车载收音机聚合成汽车
出租车继承自汽车
出租车与司机是多对多的双向关联关系,司机单向关联驾照(一个司机持有一个驾照)
司机依赖车载WIFI

类图可参考：UML:类图关系总结

活动图：

泳道

顺序图：

高级

---

第十一章：软件测试

1.能够理解测试和质量保障的定义

Testing (测试) – provide input, measure output against expectation.
The planning happens around the same time as design
The action happens post-implementation.
Unit Testing
Black Box Testing
White Box Testing
Quality Assurance (质量保障) – all activities that increase confidence in quality
Testing is only one activity of Quality Assurance （测试只是质量保障的一部分）
Quality Assurance encompasses all phases, including planning, and support
测试(测试): 提供输入,测量输出与期望。
规划与设计几乎同时进行
动作发生在执行之后。
单元测试
黑盒测试
白箱测试
质量保证(质量保障)——所有活动,增加对质量的信心

测试是只有一个活动的质量保证(测试只是质量保障的一部分)
质量保证包括所有阶段，包括计划和支持

2.能够知道客观质量和主观质量分别是什么

Some aspects of Quality are objective (客观)
Stability / bug-free
Complies with the specification

Some aspects of Quality is subjective (主观)
Overall value to the customer / satisfies the customer’s needs
Enjoyable end-user experience, emotional value
Makes the customer want more

So Bug-free != High Quality
Why is BMW better than Hyundai? （宝马车和QQ车都通过质量标准，都能在路上跑，谁的质量高?)
质量目标的某些方面(客观)：
稳定性/没有错误
符合规格要求

质量是主观的某些方面(主观)：
对客户的整体价值/满足客户的需求
愉快的终端用户体验，情感价值
让客户想要更多

所以没有bug <> 高质量
为什么宝马比现代好?(宝马车和QQ车都通过质量标准,都能在路上跑,谁的质量高吗?)

3.知道白箱测试和黑箱测试的定义

黑箱：

在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”，从软件的行为，而不是内部结构出发来设计测试。

白箱：

在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。

4.掌握三种测试用例设计方法

等价类划分:

等价类的概念：指定某个输入域的子集，子集中每个输入对发现软件错误都是等效的。
有效等价类
对于软件规格说明来说，是合理的、有意义的输入数据构成的集合。
无效等价类
对于软件规格说明而言，没有意义的、不合理的输入数据集合
基本思路
从每个子集中选取少数具有代表性的数据作为测试用例。

边界值分析

对等价类分析方法的一种补充,由长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。

编写测试用例的步骤：
(1) 根据被测对象的输入（或输出）要求确定边界值。

(2) 选取等于、刚刚大于、刚刚小于边界的值作为测试数据。
注：基本思想是在最小值（min）、略高于最小值（min+）、正常值（nom）、略低于最大值（max-）和最大值（max）等处取值。

正交实验设计方法（Pair-wise）

---

第十二章：软件质量

1.软件工程的质量体现在哪些方面

软件工程的质量体现在：
开发过程的可见性
开发过程的风险控制
开发成本的控制
内部模块的交付质量
内部质量指标的完成情况

2.根据燃尽图（或类似的图）能够说明软件过程中出现的问题

正常的 未解决/解决/关闭 的比例

在制品(即检测)中出现的凸起表明资源不足或来料质量不合格
Bulge in work in process (i.e. in testing) indicates inadequate resources or inadequate incoming quality

进展缓慢导致削减计划工作，但削减不够
Slow progress leading to cuts in planned work,but not enough cuts
进步速度稳定，但坡度太浅
Steady rates of progress, but slope too shallow

在迭代开始时没有计划的新工作
New work not planned at iteration start

**“暗物质”**在迭代中出现
“Dark matter” emerging during iteration
有计划的工作被挤出去了
Planned work is squeezed out

A real example

3.了解用户代替测试的问题

1） 没有测试，就没有人给第一时间的反馈，特别是各种非主流配置下的非主流使用场景。例如， 我们想测试各个模块如何处理闰年的2月 29号（或者闰年的最后一天），我们要等到实际闰年的时候， 才能让用户帮我们测试么？
2） 严格的时间标准听起来很好，但是这个时间是某个版本在某个目标用户手上的时间，这些目标 用户都有自己的日常工作要求**，不会像测试人员那样去全面和深入测试，更没有任何动力去整天 测试。**
3）如果有专职测试，他们就可以在较短时间内完整测试，给出有信心的 “go/no go" 判断。而不是 要等一帮dogfood 用户N 天的使用。这个规定比较僵化，不能处理一些比较紧急的情况，例如， 需要3 周就上线，但是规定要求必须走两个环，每个环要强制4 周的使用时间。
4）用户报告的Bug 很多， 很多开发人员在自己的机器上试了一试，发现无法重现，于是就标上 “无法重现”(not reproducible)，就把这个Bug 关闭了。岂不知这个在用户的环境中是的确发生了 的！但是没有专业测试团队试图重现这个环境，开发人员只有有限的配置（而且从处理器，内存， 网速，都是高端，干净的配置），也没有精力和动力去找到如何能重现这个Bug的环境。 “快速重现用户报过的Bug”这是专业测试人员的价值所在。没有测试人员之后，开发人员并没有 负责这个新的任务，他们的主要目标还是“快速开发功能”。
5） 针对这些 Bug的修复也要一级一级地发出去，增加很多成本。
6） 质量控制的核心是：尽早，高效地找到Bug，一个专职的测试团队就能做到这些。全部依赖于 社区，会出现很多副作用。还是那句话，没有责任，就没有质量。

---

第十三章：软件发布

1.了解软件发布的那些名词

Alpha： 指集成了主要功能的第一个试用版本。在这个版本中有些小功能并未实现。
Beta： 功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用，可以有 Beta1、Beta2、Beta3 ……
ZBB（Zero Bug Build）：某天的版本要把在之前（例如48小时前）记录的Bug都解决掉。
RC（Release Candidate）：发布候选版本，RC1、RC2……直到RTM为止，版本间隔时间较短。
RTM（Release To Manufacturer）：最终发布版本。如果某一个RC版本没有很大的问题， 那么这一RC就会成为最终的版本，通常情况下，软件公司会把最终的版本和相关的文件及其他资料交给另一个团队（Manufacturer）去包装、刻制光盘。在App Store/ Marketplace的年代，我们有相应的RTM（Release To Market）。
RTW（Release To Web）：要依赖“Web”来发布我们 的最终版本。
RTO（Release To Operation）如果软件产品是一个网站服务，则一般会交给网站运营团队（Operation Team）去管理，
RTS （Release To Store）运营团队和 研发团队一起决定什么时候系统上线（Go Live）。把软件提交到各个应用商店则可以 称为 。

2.了解从代码完成到软件发布之间的步骤

---

总结

概念性内容比较多
重点在于对画图的掌握程度
祝我考出好成绩！！！