软件工程期末复盘：一张知识地图串起需求、设计、测试与维护

简介：这份资源是合肥工业大学计算机与信息学院2019～2020学年第二学期软件工程课程A卷的试卷原件，面向备考软件工程的学生及需要梳理知识体系的读者，可用于自测、对照复习与查漏补缺。试卷由吴克伟老师命题，题型覆盖判断题、选择题、填空题、名词解释与简答题，考点涉及需求分析、模块独立性与耦合、结构化程序设计、单元测试与验收测试、判定覆盖与条件覆盖、软件维护费用、迭代模型与瀑布模型、PDL伪码、包图建模、边界值分析法及软件重用等核心内容，并附有标准答案页。资源包共1个docx文件，约25KB，为可直接查阅的文档格式。目前已有1800人学习下载，适合希望借助真题把握命题重点、检验理论掌握程度的读者参考使用。

1. 软件工程期末复盘：一张知识地图串起需求、设计、测试与维护

软件工程这门课最坑的地方在于，它看起来全是概念，考起来全是细节。很多人复习时把教材翻了三遍，合上书还是分不清「总体设计」和「详细设计」的产出物，说不准「判定覆盖」和「条件覆盖」到底谁包含谁。这份 2020 年的 A 卷恰好是一面镜子：判断、选择、填空、名词解释、简答、应用题六种题型，把软件生命周期的每个阶段都扫了一遍，而且专挑那些「你以为你懂了」的地方下手。梳理下来会发现，整张卷子的骨架其实就一条主线——需求怎么来、结构怎么划、代码怎么测、上线怎么养。这篇笔记按这条主线把知识点重新排了一遍，适合正在系统学这门课、或者考前想快速查漏补缺的人。先给地图，再拆模块，最后落到一份能直接照着走的复习清单。

2. 生命周期与过程模型：瀑布、螺旋、RUP 到底差在哪

2.1 阶段划分与各阶段的核心产出

软件生命周期这道简答题几乎年年出现，但很多人背的时候只记阶段名，不记「每个阶段交什么」。判卷时真正给分的是产出物。按经典划分，阶段与产出对应关系如下：

这张表里最容易混的是总体设计与详细设计：总体设计的成果是「模块结构图」，详细设计的成果是「模块内部算法」。选择题里问「总体设计阶段的结果是什么」，答案就是模块结构图，而不是数据流图——数据流图是需求分析阶段的产物，这个顺序不能倒。

可行性研究从三个维度展开：技术可行性、经济可行性、操作可行性（也叫社会可行性）。填空题里挖空的就是第三个。需求分析要建立三类模型：数据模型、功能模型、行为模型（有的教材叫状态模型），三者分别对应 ER 图、数据流图、状态转换图。

2.2 过程模型的迭代性判断

选择题里「哪个模型没有采用迭代思想」是个经典陷阱。判断标准很简单：看它是否允许回到上一阶段。

• 瀑布模型：严格线性，阶段间有去无回，不迭代。
• 渐增模型：按增量分批交付，每批内部可迭代。
• 螺旋模型：以风险分析为核心的螺旋式迭代。
• RUP（统一过程）：以用例驱动、架构为中心、迭代增量，四大阶段内多轮迭代。

所以不迭代的只有瀑布。简答题要求比较 RUP 与敏捷过程，答题时抓三个对比维度就够：RUP 强调「架构先行、文档较全、适合中大型团队」，敏捷强调「个体交互优先、可工作软件优先、拥抱变化、适合需求不稳定的小团队」。两者都迭代，区别在重量级与轻量级。

提示：向已经延期的项目追加开发人员可能让它更晚完成，这条判断题答案是 T。背后的逻辑是 Brooks 定律——新人加入需要沟通成本和培训成本，短期反而拖慢进度。这类「反直觉但正确」的命题在判断题里出现频率很高。

3. 结构化分析与设计：耦合、内聚与模块独立性

3.1 耦合类型与独立性排序

模块独立性由耦合和内聚共同决定：耦合越低越好，内聚越高越好。耦合从弱到强大致是：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。这里有个极易翻车的点：判断题说「非直接耦合的模块独立性最弱」，答案是 F。非直接耦合指的是两个模块之间没有直接联系、只通过主模块控制调用，它恰恰是耦合最弱、独立性最强的一档。把「最弱」和「最强」看反，是这张卷子里最典型的血泪经验。

内聚从高到低则是：功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚。答题时记住一句话：一个模块只做一件事且各部分为同一功能服务，就是功能内聚，最高。

3.2 作用范围与控制范围

模块的作用范围指受该模块内一个判定影响的所有模块的集合，它包含模块本身及其所有从属模块。设计原则是：作用范围应该落在控制范围之内，否则判定结果需要绕经上层模块传递，增加耦合。这条原则在简答和设计题里都会用到，判断「某模块作用范围是否合理」时，先画出模块结构图，再标出判定影响到的模块，看是否被该模块的控制范围包住。

结构化设计还有一条总要求：高内聚、低耦合，模块间联系尽量少、模块内联系尽量紧。填空题问「从模块内外联系看结构化设计的要求」，答的就是这八个字。

3.3 数据流图到结构图的转换

应用题里给生产科、技术科的业务描述，要求画软件结构图，考的是事务型与变换型数据流的识别。判断方法：如果数据流存在明显「输入—处理—输出」三段，是变换型，结构图按「输入、变换、输出」三个分支展开；如果数据流根据输入类型在若干动作序列中选择一个执行，是事务型，结构图中心是一个事务调度模块，下挂各事务分支。题干里「根据输入数据的类型在若干动作序列中选择合适的操作执行，形成事务流」这句，就是事务型的定义原文。

画结构图时注意三点：顶层是主控模块，中间层按数据流分解，底层是具体功能模块；每个模块用矩形表示，调用关系用带箭头直线；模块命名用动宾短语，如「制定月生产计划」「分解周计划」。

4. 面向对象与 UML：包图、主题划分与五层抽象

4.1 主题划分对应哪种图

选择题问「表示主题划分的建模图形」，答案是包图（Package Diagram）。主题划分是在更高抽象层次上对模型分组，包图正是用来表达这种分组的。配置图描述物理部署，顺序图描述对象间按时间排列的消息交互，合作图（通信图）强调对象间的链接关系。四张图各管一摊，别混。

面向对象建模的五个抽象层次，填空题挖的是最顶层：主题层、类与对象层、结构层、属性层、服务层。记忆顺序从粗到细：先划主题，再找类和对象，再看结构与属性，最后定服务（方法）。

4.2 面向对象方法与结构化方法的比较

简答题要求从思维特点、方法特点、适用范围三个角度比较。可以整理成一张对照表：

面向对象软件工程通常采用迭代增量模型实现生命周期各阶段，这也是填空题的常见挖空点。UML 作为统一建模语言，名词解释答题时抓住「可视化、面向对象、用于建模、非编程语言」四个关键词即可。

5. 软件测试：覆盖准则与基本路径法

5.1 覆盖准则的包含关系

判断题「判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖」答案是 T。这是测试部分最烧脑的一组关系，梳理清楚只需记住两条链：

• 语句覆盖 ⊂ 判定覆盖 ⊂ 条件组合覆盖
• 判定覆盖与条件覆盖之间没有必然包含关系

原因在于：判定覆盖只要求每个判定的真假分支各走一次，条件覆盖只要求每个条件的真假各取一次，两者关注的对象不同，一个管整体判定结果，一个管单个条件取值，所以互不包含。而条件组合覆盖要求每个判定内所有条件取值的组合都出现，强度最高。

5.2 基本路径测试的完整流程

应用题第三题用 PDL 描述的求平均值算法考基本路径法，这是整张卷子分值最高的一题，流程固定为五步：

1. 画程序图（控制流图），每个节点对应一条语句或一个判定。
2. 计算 McCabe 环路复杂性：V(G) = E − N + 2，或等于判定节点数 + 1，或等于独立路径数。
3. 求一组独立路径，每条路径至少引入一条新边。
4. 为每条独立路径设计测试用例，给出输入值与预期输出。
5. 补充边界值用例。

以该算法为例，判定节点有四处：循环条件（value[i] ≠ -999 且 total.input < 100）、有效性判定（value[i] ≥ minimum 且 ≤ maximum）、以及循环后的 total.valid > 0。按「判定数 + 1」估算，环路复杂性为 4，对应 4 条独立路径。设计用例时，边界值分析法专门抓边界：输入范围 [-1.0, 1.0]，取 -1.001、-1.0、1.0、1.001 四个值，正好覆盖「刚好越界、刚好在界、刚好在界、刚好越界」四种情况，所以选择题答案是边界值分析法。

注意：单元测试能发现约 80% 的软件缺陷，这个数字判断题里常被改成「全部」来设陷阱。验收测试由最终用户参与实施，但通常由开发方组织、用户确认，说「完全由用户实施」也不严谨。

5.3 测试阶段的顺序与文档对应

单元测试对应详细设计说明书，集成测试对应概要设计，确认测试对应需求规格说明书，系统测试对应可行性研究。填空题问「单元测试与哪份文档相关」，答案是详细设计说明书。这个对应关系按「测试对象越细、参照文档越细」记，不容易乱。

6. 易错点清单：五个最容易翻车的判断题与概念

6.1 易错点一：非直接耦合的强弱

易漏点：把非直接耦合当成最弱耦合。为什么漏：字面上「非直接」听起来像「没关系」，直觉上觉得关系少就是弱，但题目问的是独立性，非直接耦合恰恰独立性最强。怎么补：记一句口诀「非直接、数据耦合最独立，内容、公共耦合最糟糕」，做题时先问自己问的是耦合强度还是独立性。

6.2 易错点二：单入口单出口不等于结构化

易漏点：认为「一个程序只有一个入口和一个出口就是结构化程序」。为什么漏：结构化程序的定义被简化成「单入口单出口」，但真正的判定标准是「仅由顺序、选择、重复三种基本控制结构组成」。怎么补：遇到这类题先看是否只用了三种基本结构，单入口单出口只是必要条件不是充分条件。

6.3 易错点三：需求分析阶段不考虑维护

易漏点：判断题「在进行需求分析时同时考虑维护问题」容易判 F。为什么漏：觉得维护是后期的事。怎么补：软件工程强调可维护性要在需求阶段就埋进去，需求规格说明的可追溯性直接影响后期维护成本，所以这条答案是 T。

6.4 易错点四：软件维护是费用大头

易漏点：选择题问生命周期中花费最多的阶段，容易选编码或测试。为什么漏：编码看得见、测试听得见，维护却是沉默成本。怎么补：记住维护通常占生命周期总费用的六成以上，这是软件工程的经典结论，也是「可维护性设计」存在的理由。

6.5 易错点五：软件重用不包括方法标准重用

易漏点：软件成分重用的范围记不全。为什么漏：把「方法标准」和「分析结果、设计结果、代码」混为一谈。怎么补：软件重用包括代码重用、设计结果重用、分析结果重用、测试信息重用等，方法标准重用不属于软件成分重用的范畴，选择题里它是干扰项。

7. 考前一周怎么用这份卷子查漏补缺

复习到最后一星期，最有效的动作不是再读一遍教材，而是拿这份卷子做「反向索引」：每做错一题，回到对应章节把那一小节的知识点重新画一遍结构。具体可以按三轮走。

第一轮限时模拟，按题型计时，判断题和选择题控制在 20 分钟内，填空和名词解释 20 分钟，简答和应用题留足 50 分钟。做完只标错题，不改答案。第二轮逐题溯源，把每道错题映射到知识模块，用下面这张表记录：

第三轮只攻错因类型为「概念反向」和「路径漏算」的题，因为这两类在考场上最容易重复犯错。基本路径法建议手算三遍：第一遍画控制流图，第二遍数边和节点算 V(G)，第三遍写独立路径并配用例。三遍下来，环路复杂性的三种算法（边减点加二、判定数加一、独立路径数）会自然对齐，考场上不管题目怎么问都能接住。

还有一个小技巧：把名词解释当简答的压缩版来背。软件工程、数据字典、需求分析、路径覆盖、UML 这五个词，每个准备三句话——一句定义、一句作用、一句在生命周期中的位置。比如路径覆盖：定义是「使程序中每条可能执行的路径至少执行一次」，作用是「发现路径组合相关的缺陷」，位置是「白盒测试中强度较高的一种覆盖准则」。三句话结构统一，考场上直接展开就是简答的骨架。

从那以后我每次复习这类概念密集的课，都强制自己先画一张「阶段—产出—易错点」三列对照表，再拿真题往里填，填不进去的地方就是没学透的地方。这份卷子的价值不在于题目本身，而在于它把整门课的骨架暴露得很清楚，照着骨架补，比盲目刷题省力得多。希望帮到你。

本文还有配套的精品资源，点击获取