一个神奇的大学科目《软件工程》，知识点总结+测试题，包你不挂科

逃离我推掉我的手 2022-11-18 13:39 236阅读 0赞

> 谁能告诉我这科的理论在哪可以实用呀？搞不懂，只能收藏一下包不挂科

# 知识点总结 #

第一章：

**软件工程定义**：

1968年10月，Fritz Bauer 首次提出了“软件工程”的概念，并将“软件工程”定义为：为了经济地获得能够在实际机器上有效运行的可靠软件，而建立并使用的一系列工程化原则。

1993年IEEE对软件工程的定义：软件工程是将系统化的、规范化的、可度量的途径应用于软件的开发、运行和维护的过程，即将工程化应用于软件的方法的研究。

**软件工程原则：**

抽象与自顶向下，逐层细化 信息隐蔽和数据封装 模块化 局部化 确定性 一致性和标准化 完备性和可验证性

瀑布模型：

开发活动的特征：（1）以上一项活动方产生的工作对象为输入(2)利用这一输入,实施本项活动应完成的内容(3)给出该项活动的工作结果,作为输出传给下一项活动(4)对实施该项活动的工作结果进行评审,若其工作得到确认,则继续进行下一项活动,否则返回前项,甚至更前项的活动进行返工

**瀑布模型的优点:**

(1)可强迫开发人员采用规范化的方法

(2)严格地规定了每个阶段必须提交的文档

**瀑布模型的缺点**

(1)由于瀑布模型几乎完全依赖于书面的规格说明,很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异,就会发生这种情况(2)瀑布模型只适用于项目开始时需求已确定的情况。总地来说,瀑布模型是一种应付需求变化能力较弱的开发模型,因此,很多在该模型基础上开发出来的软件产品不能够真正满足用户需求

第二章：

**可行性研究的过程：**

1.  复查系统规模和目标

复查系统定义，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束

1.  研究目前正在使用的系统

现有的系统是信息的重要来源。若一个软件是对旧系统的改造，那开发新系统时，要充分了解老系统存在的问题，需要增加的功能，新系统实际上是老系统的部分功能加上一些新增功能形成的系统

1.  导出新系统的高层逻辑模型
2.  重新定义问题

新系统的逻辑模型实质上表达了分析员对系统必须做什么的看法，得到新系统的高层逻辑模型之后，可能会发现前面问题定义的范畴过大，分析员还要和用户一起再复查问题定义，对问题进行重新定义和修正。

1.  导出和评价供选择的解法

分析员应该从系统逻辑模型出发，研究问题的几个组成部分，细化各功能点，导出若干个较高层次的物理解法供比较和选择

1.  推荐行动方针
2.  草拟开发计划

任务分解 进度规划 财务预算 风险分析及对策

1.  书写文档提交复查

第三章：

一.**软件需求的定义：**

以清晰、简单、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对软件系统的约束。

二.**需求分析的任务**：

1.  业务需求：是客户对于软件系统的高层次目标要求，定义了项目的远景和范围
2.  用户需求：从用户角度描述软件系统的功能需求与非功能需求，通常只涉及系统的外部行为。
3.  功能需求：功能需求描述软件系统应该提供的功能或务,通常涉及用户或其他外部系统与目标系统之间的交互,不考虑目标系统内部的实现细节
4.  非功能需求：非功能需求即性能需求，反映了客户对软件系统质量和性能的额外要求
5.  约束条件： 约束条件是软件系统设计和实现时必须满足的限制条件
6.  业务规则： 业务规则是对某些功能的可执行性成内部执行速制的一些限定条件
7.  外部接口需求: 外部接口需求是描述目标系统与外部环境之间的交互接口
8.  数据定义:当用户描达一个数据项或一个复杂的业务数据结构的格式或缺省值时,正在进行数据定义

第四章：

**启发规则**：

启发规则是软件结构设计优化准则，软件概要设计的任务就是软件结构的设计，为了提高设计的质量，必须根据软件设计原理设计软件，利用启发规则优化软件结构。

1.改进软件结构提高模块独立性2.模块规模适中3.适当控制深度、宽度、扇出、扇入

4.模块的作用域应该在控制域之内5.力争降低模块接口的复杂程度

6.设计单入口单出口的模块7.模块功能可预测

第五章：

**详细设计的过程**

软作详细设计是软件工程的重要阶段,在详细设计过程中,细化了高层的体系结构设计，将软件结构中的主要部件划分为能独立编码、编译和测试的软件单元,并进行软件单元的设计,同时确定了软件单元和单元之间的外部接口。

一.**详细设计的基本任务**：

1.  算法设计:用某种图形、表格、语言等工具将每个模块处理过程的详细算法描述出来
2.  数据结构设计:对于需求分析,概要设计确定的概念性的数据类型进行确切的定义
3.  物理设计： 对数据库进行物理设计,即确定数据库的物理结构
4.  其他设计

a.代码设计：为了提高数据的输入、分类、存储及检索等操作的效率,对数据库中的某些数据项的值要进行代码设计b.输入/输出格式设计c.人机对话设计

1.  编写详细设计说明书 6 . 评审：对处理过程的算法和数据库的物理结构要进行评审

二**.详细设计方法：**

1.  自顶向下，逐步求精 2.具有单入、单出的控制结构 3. 五种控制结构：顺序结构，选择，先判断型循环结构，后断型循环结构，多选择分支结构

第七章：

一．**测试用例设计：**

白盒测试是对软件的过程细节做细致的检查。这一方法把测试对象看作 个打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态,确定实际的状态是否与期望的状态一致。

**覆盖标准**：

1.  语句覆盖

含义：就是选择足够多的测试用例，运行被测程序，使得程序中每条语句至少执行一次。

1.  判定覆盖

含义：又称为分支覆盖，在设计测试用例，针对程序中具有分支结构的部分，为了测试所有的可能结果，需要将每个分支都至少执行一次，查看相应的语句执行情况和结果

(1)a=2,b=0,x=4,覆盖RACBDE

(2)a=3,b=1,x=1覆盖 RABE

1.  条件覆盖

条件覆盖是指设计测试用例时,除了保证每条语句执行一次,还要使判定表达式的每个条件的各种可能取值都至少执行一次,为了实现条件覆盖,保证各种可能的条件都取值,即保证

第一个判断有以下取值:a>1,a<=1,b=0,b≠0

第二个判断有以下取值:a=2,a≠2,x>1,x<=1

选择两组测试用例:

(1)a=2,b=2,x=2(满足a>1,b≠0,a=2,x>1的条件),执行路径为 RABDE

(2)a=1,b=0,x=0(满足a<=1,b=0,a≠2,x<=1的条件),执行路径为RABE

1.  判定/条件覆盖

单独使用判定覆盖和条件覆盖测试结果都不够全面, 若将两种覆盖结合，就会相互补充,判定/条件覆盖就是设计足够多的测试用例，使得每个判定表达式中的每个条件都取到各种可能的值,并且使每个判断语句的所有判断结果至少出现一次。

(1)a=2,b=0,x=2(满足a>1,b=0,a=2,x>1的条件)，执行路径RACBDE

(2)a=1,b=1,x=1(满足a<=1,b≠0,a≠2,x<=1的条件)，执行路径RABE

1.  条件组合覆盖

条件组合覆盖就是设计足够多的测试用例,使得每个判定表达式中条件取值的各种组合都至少出现一次。根据每个判定表达式情况,列出如下条件组合

(1)a>1,b=0,A表达式为真;(2)a>1,b≠0,A表达式为假;(3)a<=1,b=0,A表达式为假

(4)a<=1,b≠0,A表达式为假;(5)a=2,x>1,B表达式为真(6)a=2,x<=1,B表达式为真;

(7)a≠2,x>1,B表达式为真;(8)a≠2,x<=1,B表达式为假。

选择以下四组测试用例

选择条件a=2,b=0,x=2,(1)、(5)组合,执行路径 RACBDE

选择条件a=2,b=1,x=1,(2)、(6)组合,执行路径 RABDE

选择条件a=1,b=0,x=2,(3)、(7)组合,执行路径 RABDE

选择条件a=1,b=1,x=1,(4)、(8)组合,执行路径 RABE

1.  路径覆盖

就是选取足够多的用例，保证程序的所有路径都至少执行一次，如果存在环形结构，也要保证此环的所有路径都至少执行一次。

(1)a=1,b=1,x=1(满足a<=1,b≠0,a≠2,x<=1的条件),执行路径为RABE

(2)a=2,b=0,x=2(满足a>1,b=0,a=2,x>1的条件),执行路径为 RACBDE

(3)a=2,b=1,x=2(满足a>1,b≠0,a=2,x>1的条件),执行路径为 RABDE;

(4)a=3,b=0,x=1(满足a>1,b=0,a≠2,x<=1的条件),执行路径为 RACBE

二．**测试的步骤：**

1.  单元测试

a.单元测试的主要任务

单元测试针对每个模块,主要解决五个方面的问题：(1)模块接口(2)局部数据结构（3）路径测试 (4)过界条件 (5)出错处理

b.单元测试的执行过程

1.  集成测试

a.非增式集成测试方法 b. 增式集成测试方法

1.  确认测试

确认测试的标准 配置审查的内容 Alpha Beta 测试

1.  系统测试

方法：恢复测试方法 安全测试方法 强度 性能

第八章：

一．软件维护的概念

软件维护是指在软件运行或维护阶段对软件产品所进行的修改,这些修改可能是改

正软件中的错误,也可能是增加新的功能以适应新的需求,但是一般不包括软件系统结

构上的重大改变。根据软件维护的不同原因,软件维护可以分成四种类型

(1)改正性维护

在软件交付使用后,由于开发时测试得不彻底或不完全,在运行阶段会暴露一些开

发时未能测试出来的错误,为了识别和纠正软件错误,改正软件性能上的缺陷,避免实

施中的错误使用,应当进行的诊断和改正错误的过程,这就是改正性维护

(2)适应性维护

随着计算机技术的飞速发展和更新换代,软件系统所需的外部环境或数据环境可能

会更新和升级,如操作系统或数据库系统的更换等。为了使软件系统适应这种变化,需

要对软件进行相应的修改,这种维护活动称为适应性维护

(3)完善性维护

在软件的使用过程中,用户往往会对软件提出新的功能与性能要求,为了满足这些

要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件

的可维护性,这种情况下进行的维护活动叫作完善性维护,完善性维护不一定是救火

式的紧急维修,而可以是有计划的一种再开发活动

4)预防性地护

这类维护是为了提高软件的可维护性,可靠性等,为以后进一步改进软件打下良好

的基础的维护活动,具体来讲,就是采用先进的软件工程方法对需要维护的软件或软件中的某一部分重新设计、编码和测试的活动。

二．软件维护的特点

1.软件维护受开发过程影响大

2.软件维护困难多

3.软件维护成本高

三．软件维护的步骤

软件维护工作包括建立维护组织、报告与评估维护申请、实施维护流程等步骤。

在影响分析和版本规划的过程中,不同的维护类型需要采用不同的维护策略

（1）改正性维护:首先应该评价软件错误的严重程度,对于十分严重的错误,维护

员应该立即实施维护对于一般性的错误,维护人员可以将有关的维护工作与其他开发

任务一起进行现划。在有些情况下,有的错误非常严重,以致不得不临时放弃正常的维

护控制工作程序,既不对修改可能带来的副作用作出评价,也不对文档作相应的更新,而

是立即进行代码的修改。这是一种救火式的改正性维护,只有在非常紧急的情况下才使

用,这种维护在全部维护中只占很小的比例。应当说明的是,救火式不是取消,只是推迟

了维护所需要的控制和评价。一旦危机取消,这些控制和评价活动必须进行,以确保当

前的修改不会增加更为重要的问题

(2)适应性维护:首先确定软件维护的优先顺序,再与其他开发任务一起进行规划

(3)定善性维护,根据商业的需求和软件的发展，有些完善性维护可能不会被接受。对于被接受的维护中请,应该确定其优先次序井现划其开发工作

第九章

**质量保证**

产品的生命，不论生产何种产品，质量都是极端重要的。软件产品开发周期长，耗费巨大的人力和物力，更必须特别注意保证质量。

**软件质量：**概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

**软件质量因素的定义：**

正确性：系统满足规格说明和用户目标的程度,即,在预定环境下能正确地完成预期功能的程度

建壮性：在硬件发生故障、输人的数据无效或操作错误等意外环境下,系统能做出适当响应的程度

完整性(安全性)：对未经授权的人使用软件或数据的企图,系统能够控制(禁止)的程度

效率：为了完成预定的功能,系统需要的计算资源的多少

可用性：系统在完成预定应该完成的功能时令人满意的程度

风险：按预定的成本和进度把系统开发出来,并且为用户所满意的概率

可理解性：理解和使用该系统的容易程度

可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小

灵活性(适应性)：修改或改进正在运行的系统需要的工作量的多少

可测试性：软件容易测试的程度

可移植性：把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时,需要的工作量多少,有一种定量度量的方法是:用原来程序设计和调试的成本除移植时需用的费用

可再用性：在其他应用中该程序可以被再次使用的程度(或范围)

互运行性：把该系统和另一个系统结合起来需要的工作量的多少

软件质量保证的措施主要有：基于非执行的测试（也称为复审或评审），基于执行的测试（即以前讲过的软件测试）和程序正确性证明。

复审主要用来保证在编码之前各阶段产生的文档的质量；基于执行的测试需要在程序编写出来之后进行，它是保证软件质量的最后一道防线；程序正确性证明使用数学方法严格验证程序是否与对它的说明完全一致

**技术复审的必要性：**

正式技术复审的显著优点是，能够较早发现软件错误，从而可防止错误被传播到软件过程的后续阶段。

正式技术复审是软件质量保证措施的一种，包括走查和审查等具体方法。走查的步骤比审查少，而且没有审查正规。

**走查主要有下述两种方式。**

（1） 参与者驱动法。参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。

（2） 文档驱动法。文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更有效，往往能检测出更多错误。经验表明，使用文档驱动法时许多错误是由文档讲解者自己发现的。

**审查步骤：**

（1） 综述。由负责编写文档的一名成员向审查组综述该文档。在综述会结束时把文档分发给每位与会者。

（2） 准备。评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以辅助审查工作。这些列表有助于评审员们把注意力集中到最常发生错误的区域。

（3） 审查。评审组仔细走查整个文档。和走查一样，这一步的目的也是发现文档中的错误，而不是改正它们。通常每次审查会不超过90分钟。审查组组长应该在一天之内写出一份关于审查的报告。

（4） 返工。文档的作者负责解决在审查报告中列出的所有错误及问题。

（5） 跟踪。组长必须确保所提出的每个问题都得到了圆满的解决（要么修正了文档，要么澄清了被误认为是错误的条目）。必须仔细检查对文档所做的每个修正，以确保没有引入新的错误。如果在审查过程中返工量超过5%，则应该由审查组再对文档全面地审查一遍。

**程序正确性证明：**

测试可以暴露程序中的错误，因此是保证软件可靠性的重要手段；但是，测试只能证明程序中有错误，并不能证明程序中没有错误。因此，对于保证软件可靠性来说，测试是一种不完善的技术，人们自然希望研究出完善的正确性证明技术。

# **软件工程一测** #

1.  软件工程三要素：\_\_\_\_\_\_\_\_\_\_\_\_\_\_、\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_、\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
2.  获取愿景的三部曲：
3.  愿景\_\_\_\_\_\_\_（是/否）功能。
4.  愿景必须指出\_\_\_\_\_\_\_\_\_\_
5.  迭代与增量的定义
6.  UML静态图包括（4个）
7.  UML动态图包括（5个）
8.  为什么使用UML语言
9.  \_\_\_\_\_\_\_\_\_\_\_\_\_\_是软件成功的基础。

答案：

1.  工具（系统）、方法（技能）、开发过程（框架）
2.  第一步：找到软件项目的“老大”；第二步：得到“老大”对项目的期望（愿景）；第三步：描述出愿景的度量指标。
3.  否
4.  度量指标
5.  迭代是反复求精，增量是逐块建造
6.  类图、对象图、组件图、部署图
7.  时序图、协作图、状态图、活动图、用例图
8.  主要用于交流，有利于清晰，有利于精确
9.  需求

# **软件工程二测** #

1.  在项目失败的因素中，与 相关的比例最高。
2.   是解决需求噩梦的手段。
3.  简要分析项目开发过程中，公司老板、中层经理、一线员工的需求分别有什么特点。
4.  ICONIX过程从把需求文档变成可运作的代码过程只需四步，需要使用哪四张UML图？
5.  若某公司设有公司老总、市场总监与财务总监，实现强化客户管理功能、提升财务效率功能、优化公司资源功能的三种软件，“老大”分别是谁？

答案：

1.需求

2.需求工程

3.公司老板：企业战略、开源节流（定于愿景）

中层经理：简化管理、优化流程（业务建模）

一线员工：工作简单（用例分析）

4.用例图、序列图、类图、健壮性图

5.强化客户管理：市场总监

提升财务效率：财务总监

优化公司资源：公司老总

# **软件过程三测** #

1.  业务建模序列图阶段要注意什么？
2.  业务序列图中，alt表示（ ），loop表示（ ），opt表示（ ）；
3.  Alt和opt在使用的时候有什么区别？
4.  业务序列图中，消息的名字表示什么？
5.  业务序列图中，消息的方向表示什么？
6.  把（ ）看作特殊的业务实体。
7.  业务建模结果复核目的有两点，分别是什么？

答案：

1.  本阶段不要考虑要实现什么系统
2.  分支，循环，可选分支
3.  Alt表示分支，是需要条件的；opt表示可选分支，没有条件，有选择性。
4.  代表责任和目的
5.  责任委托，不是数据流动
6.  时间
7.  一是完善业务建模成果，寻找是否有遗漏或错误的地方进行修正，如果问题明显，就需要迭代回去继续做业务建模工作；

二是关键干系人在信息和意见上达成一致，并共同签字确认，作为下一阶段启动的标志。

# **软件工程四测** #

1.  业务建模要求我们把视角从\_\_\_\_\_\_\_，以达到清晰准确地“诊断”，对症“开方”

答案：软件系统转向客户组织，站在客户角度看问题

2、业务建模三步骤：

1、\_\_\_\_\_\_\_\_\_\_\_2、\_\_\_\_\_\_\_\_\_\_\_\_3、\_\_\_\_\_\_\_\_\_\_\_\_

答案：

1.  明确我们为谁服务（选定愿景要改进的组织）。
2.  要改进的组织是什么现状（业务用例图、现状业务序列图）。
3.  我们如何改进（改进业务序列图）。

3、了解组织现状：

（1）从外部看：组织是\_\_\_\_的集合，用业务用例图来建模

（2）从内部看：组织是\_\_\_\_的集合

答案：价值、系统

4、业务用例图帮助我们从\_\_\_\_\_\_了解组织的\_\_\_\_\_\_。

答案：高层次 、业务构成

5、业务执行者是在业务组织之外，与其交互，享受其价值的\_\_\_\_\_\_\_

答案：人或组织

6、业务用例是业务组织为业务执行者提供的\_\_\_\_\_\_.

答案：价值

7、业务序列图帮助我们从\_\_\_\_\_\_了解组织的\_\_\_\_\_\_。

答案：细节上、 业务流程

8、业务序列图详细描述\_\_\_\_\_\_\_\_、\_\_\_\_\_\_\_、\_\_\_\_\_\_\_\_之间如何交互，以完成某个业务用例的实现流程

答案：业务执行者、业务工人、业务实体

9、举个简单的例子并识别其中的业务对象：业务执行者、业务工人、业务实体

答案：自由发挥

10、我们如何改进（改进业务序列图）

答案：了解业务组织现状的目的——发现流程中的改进点：

*  信息自动流转
 *  封装复杂业务逻辑
 *  职责转移
 *  访问和操作业务对象

其他……

# 软件过程五测 #

1.  域建模\_\_\_\_\_不等于\_\_\_\_\_（等于或不等于）数据模型
2.  \_\_\_用例分析\_\_\_\_\_\_\_\_前做域建模
3.  需求分析的主流分析方法有\_\_\_原型法\_\_\_\_、\_\_\_\_\_\_用例法\_\_\_\_\_\_\_
4.  绘制系统用例图的步骤

1. 确定系统边界

2. 识别系统执行者

3. 识别系统用例

4. 确定用例间的关系

1.  怎样区别主执行者和辅执行者

主执行者：

1.用例发起者；

2.用例为其实现有价值的目标；

辅执行者：

1.用例支持者；

2.用例的完成需要与其交互，得到其支持

1.  如何找到执行者

谁使用该系统？

• 谁改变系统的数据？

• 谁从系统获取信息？

• 谁负责维护、管理并保持系统正常运行？

• 系统需要应付哪些硬件设备？

• 系统需要和那些外部系统交互？

• 谁对系统运行产生的结果感兴趣？

• 有没有自动发生的事件？

1.  系统用例是执行者通过系统\_\_\_\_达到某个目标\_\_\_\_\_\_
2.  用例的关系\_\_\_\_泛化\_\_\_\_、\_\_\_\_\_包含\_\_\_\_\_\_\_、\_\_\_\_\_\_扩展\_\_\_\_\_\_\_\_\_\_
3.  先发现执行者还是先发现用例？为什么？

执行者比用例明显。

• 执行者的个数远比用例的个数少。

• 找到一个执行者，就可以找到一堆用例。

• 执行者是系统外部人物的代表，所以当然是要先找到执行者，才能够从执行者的角度去寻找用例。

1.  用例命名的三个条件是什么？

用例名称必须是动宾短语。

• 采用域建模中的名词术语。

• 慎用弱动词弱名词——会掩盖真正的业务

1.  用例\_\_\_\_\_不等于\_\_\_\_\_\_功能，用例\_\_\_\_不等于\_\_\_\_\_\_步骤

# 软件过程六测 #

1.  每个用例必须对应有\_\_\_愿景目标\_\_\_\_\_\_
2.  用例描述的基本组成\_\_干系人利益\_\_\_\_\_\_\_\_\_\_\_\_\_、\_\_\_\_\_基本路径\_\_\_\_\_\_\_\_\_\_\_\_、\_\_\_\_\_\_\_\_扩展路径\_\_\_\_\_\_\_、\_\_\_\_\_\_\_业务规则\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
3.  \_\_\_\_\_\_\_\_\_用例\_\_\_\_\_\_\_是干系人利益的平衡点。
4.  基本路径的书写要求。

以主动语态、“名词-动词-名词”格式来书写。

主语只能是执行者或系统。

1.  基本路径与扩展路径是否要分开。

要