软件工程简答题

1. 软件生存周期和任务

6 个阶段：计算机系统工程、需求分析、设计、编码、测试、运行和维护。
计算机系统工程：确定待开发软件的总要求和范围，该软件与其他计算机系统元素之间的关系，进行成本估计，做出进度安排，并进行可行性分析，并在若干可行的解决方案中做出选择。
需求分析：解决待开发软件做什么的问题
设计：解决待开发软件怎么做的问题
编码：用某种语言将设计的结果转换为可执行的程序代码
测试：发现并纠正软件中的错误与缺陷
运维：发现软件中潜藏的错误或需要增加新的功能或使软件适应外界环境变化等情况出现时，对软件进行的修改。

2. 瀑布模型优缺点

优点：对确保软件开发的顺利进行、提高软件项目的质量和开发效率起到重要作用。
缺点：客户在测试完成后才看到真正可运行的软件，若不满足要求，修改软件代价巨大，实际软件开发很少能按其顺序没有回流地顺流而下。

3. 什么是黑盒测试法？常用的黑盒测试方法有哪些？

黑盒测试法把被测对象看成是一相黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。
采用黑盒技术设计测试用例的方法：等价类划分、错误推测、因果图、边界值分析。

4. 软件维护种类

纠错性维护；适应性维护；改善性维护；预防性维护。（jsgy）

5. 构件库管理系统的主要功能有哪些？简要说明

(1) 构件的分类存储：根据构建库的分类模型将入库的构件储存在构件库中，并保存构件描述信息(2) 构件检索：从构建库中检索出满足用户要求或接近用户要求的构件
(3) 构件浏览：浏览库中的全部或部分构件
(4) 删除构件：将不再使用的构件从构件库中删除
(5) 构件使用情况评价：根据用户使用和检索构件的反馈意见，对构件做出评价，为进一步的改进提供依据

6. 在模块化设计过程中，必须遵循的设计原则是什么？为了实现有效的模块化，采用的启发设计策略什么？

设计原则：抽象与逐步求精、信息隐藏、模块化、高内聚低耦合。
启发式设计策略（6 条）：
(1) 改造程序结构图，降低耦合度，提高内聚度
(2) 避免高扇出，并随着深度的增加，力求高扇入
(3) 模块的影响范围应限制在该模块的控制范围内
(4) 降低模块接口的复杂程度和冗余程度，提高一致性
(5) 模块的功能应是可预测的，避免对模块施加过多的限制
(6) 尽可能设计单入口和单出口的模块

7. 简述软件生存周期及其每一阶段的主要任务结果以及所采用的工具？

6 个阶段：计算机系统工程、需求分析、设计、编码、测试、运行和维护。

1. 可行性研究与计划阶段：系统流程图工具、项目管理工具（如 MS Project）
2. 需求分析阶段：数据流图工具、数据字典工具、UML 建模工具（如 Visio）
3. 软件设计阶段：概要设计：层次图 / 结构图工具、UML 类图工具。详细设计：N-S 图 / PAD 图工具、过程设计语言（PDL）编辑工具
4. 编码阶段：开发环境（如 Eclipse、Visual Studio）、版本控制工具（如 Git）
5. 软件测试阶段：自动化测试工具（如 JUnit、Selenium）、缺陷跟踪工具（如 Jira）
6. 运行与维护阶段：版本控制系统（如 Git）、持续集成工具（如 Jenkins）

8. CMM 的能力成熟度共分哪五级？简要说明？

(1) 初始级：软件过程的特点是无秩序的，甚至是混乱的
(2) 可重复级：建立了基本的项目管理过程来跟踪成本、进度和共扼性能
(3) 已定义级：已将管理和工程活动两方面的软件工程文档化，标准化
(4) 已管理级：对软件过程和产品都有定量的理解和控制
(5) 优化级：过程的量化反馈和新思想，新技术促使过程不断改进

9. 软件体系结构的风格

(1) 一些实现系统所需的功能部件
(2) 定义部件之间怎样整合的系统约束
(3) 一组用来连接部件通信，协作和合作的连接件
(4) 使设计者能够理解整个系统属性并分析已知

10. 什么是系统测试？系统测试有哪些？

(1) 是对整个机遇计算机的系统进行的一系列测试
(2) 恢复测试、安全保密性测试、压力测试、性能测试

11. 请给出 5 种软件过程模型，并简单说明每种模型的特点

瀑布模型、V 模型、原型模型、螺旋式模型、增量式模型、螺旋式模型

软件过程模型	核心特点	适用场景	优点	缺点
瀑布模型	线性推进，阶段无迭代	需求明确、稳定的中小型项目（如标准化软件、工具类软件）	流程清晰，文档规范，易管理	灵活性差，后期修改成本高，需求变更难适配
V 模型	开发与测试阶段一一对应，测试提前介入	需求明确、对质量要求高的项目（如军工、医疗软件）	强调测试，减少后期缺陷，质量可控	仍为线性模型，不支持需求变化，迭代能力弱
原型模型	快速构建原型，基于用户反馈迭代优化	需求模糊、创新性强的项目（如新产品研发、UI/UX 设计相关软件）	快速验证需求，降低需求误解风险，用户参与度高	原型可能偏离最终目标，过度依赖用户反馈，易产生额外成本
螺旋模型	循环迭代 + 风险分析，每轮螺旋扩展功能	大型、复杂、高风险项目（如大型系统集成、航天软件）	全程管控风险，可逐步完善系统，适配需求变化	周期长、成本高，对团队风险分析能力要求高
增量模型	分模块增量开发与交付，分批实现功能	需求部分明确、需快速交付核心功能的项目（如电商平台、企业管理系统）	快速交付可用版本，用户提前受益，便于迭代优化	模块集成复杂度高，需做好整体架构规划，可能出现模块间冲突

13. 简述面向对象的设计过程

(1) 系统设计：将子系统分配到处理器、选择实现数据管理、界面支持和任务管理的设计策略、为系统设计合适的控制机制；
(2) 对象设计：在过程级别（procedural level）设计每个操作，即设计每个操作的实现细节、定义内部类、为类属性设计内部数据结构；
(3) 消息设计：使用对象间的协作和对象 — 关系模型，设计消息模型
(4) 复审：审视设计模型并在需要时迭代。

14. OOA 包括哪些活动？

1. 获取客户对系统的需求：包括标识场景（scenario）和用况（use case，也称用例），以及建造需求模型
2. 用基本的需求术语，来选择类和对象（包括属性和操作）。
3. 定义类的结构和层次。
4. 建造对象 — 关系模型。
5. 建造对象 — 行为模型。
6. 利用用况 / 场景来复审分析模型。

15. 说明软件测试和调试的目的有何区别？

软件测试是设计合适的测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误。
调试的目的是确定错误的原因和准确位置，并加以纠正。

16. 结构化程序设计方法的基本要点是什么？

结构化设计是将结构化分析得到的数据流图映射成软件体系结构的一种设计方法。强调模块化、自顶向下逐步求精、信息隐蔽、高内聚低耦合等设计准则；分为概要设计和详细设计两大步骤。

17. 简述单元测试的内容，什么是白盒测试法？常用的白盒测试方法有哪些？
 

单元测试内容：

1. 模块接口测试这是单元测试的基础，验证单元的输入 / 输出是否符合规格：

   • 输入参数的数量、类型、格式、取值范围是否匹配设计；
   • 输出结果的类型、格式、正确性是否符合预期；
   • 全局变量、外部资源（如数据库连接、文件）的调用是否合规；
   • 异常输入（如空值、非法参数）时的接口响应是否合理。

2. 局部数据结构测试检查单元内部数据结构（如变量、数组、对象属性）的有效性：

   • 数据类型、初始值、取值范围是否正确；
   • 数据结构的完整性（如数组越界、链表断裂）；
   • 全局数据对单元的影响（是否被错误修改）。

3. 边界条件测试验证单元在边界值场景下的表现（最易出现错误的场景）：

   • 输入参数的最大值、最小值、临界值（如循环次数为 0/1 / 最大值）；
   • 数据结构的边界（如数组的第一个 / 最后一个元素）；
   • 异常边界（如空输入、超大输入、负数值）。

4. 独立路径测试覆盖单元内部所有可能的执行路径（白盒测试核心）：

   • 所有分支语句（if/else、switch）的分支覆盖；
   • 循环语句（for/while）的循环次数（0 次、1 次、多次）覆盖；
   • 异常处理路径（try/catch）的覆盖；
   • 确保没有冗余路径、死代码或逻辑错误。

5. 错误处理测试验证单元对异常情况的处理能力：

   • 错误捕获是否完整（如除零、空指针、IO 异常）；
   • 错误提示是否清晰、准确；
   • 错误处理逻辑是否不会导致单元崩溃或数据损坏；
   • 异常发生后是否能恢复到稳定状态。

6. 功能逻辑测试验证单元的核心功能是否符合设计需求：

   • 每个功能点的计算结果、业务逻辑是否正确；
   • 条件判断、逻辑运算（与 / 或 / 非）是否符合预期；
   • 单元的行为是否与需求规格说明书一致。

白盒测试：把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。
常用的白盒测试方法有：逻辑覆盖测试（语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、组合覆盖）、基本路径覆盖测试、数据流测试、循环测试。

18. 什么是类？什么是继承？什么是多态？简述类在建模中的作用

（1）类（Class）

类是面向对象编程（OOP）的核心概念，是对具有相同属性（数据）和行为（方法）的一组对象的抽象描述，相当于创建对象的 “模板” 或 “蓝图”。

（2）继承（Inheritance）

继承是类之间的一种关系，指子类（派生类）复用父类（基类）的属性和方法，并可扩展或重写父类内容，实现代码复用和层次化设计。

（3）多态（Polymorphism）

多态指同一操作作用于不同对象时，产生不同的执行结果，核心是 “接口统一，实现各异”，分为编译时多态（重载）和运行时多态（重写）。

（4）类在建模中的作用

• 抽象现实世界：将复杂的现实实体（如用户、订单）抽象为类，简化系统设计；
• 封装数据与行为：类通过访问控制（如私有属性、公共方法）隐藏内部细节，提高代码安全性和可维护性；
• 支撑模块化设计：类作为系统的基本模块，降低耦合度，便于分工开发和复用；
• 构建层次化结构：通过继承形成类的层次体系，清晰表达实体间的关系（如 “员工→教师→教授”）；
• 实现多态扩展：为系统提供灵活性，便于后续功能扩展（如新增子类无需修改父类代码）。

19. 什么是需求规约？简述需求规约的作用

（1）需求规约（Software Requirements Specification，SRS）

需求规约是对软件系统需求的正式、详细、一致的书面描述，是需求分析阶段的核心输出文档，明确规定了软件必须实现的功能、性能、接口、约束等全部需求，是用户与开发团队之间的 “契约”。

• 核心内容：功能需求（系统需完成的操作）、非功能需求（性能、安全性、兼容性等）、接口需求（与外部系统的交互）、数据需求（数据结构、存储）、约束条件（技术、资源限制）等。

（2）需求规约的作用

1. 沟通桥梁：统一用户、开发团队、测试团队、管理层对需求的理解，消除歧义，避免需求误解；
2. 开发依据：作为软件设计、编码、测试的核心依据，确保开发过程围绕需求展开，不偏离目标；
3. 验收标准：定义软件交付的验收依据，用户可根据需求规约验证软件是否满足预期；
4. 项目管理基准：为项目计划、成本估算、进度安排提供基础，便于管控项目范围；
5. 变更控制依据：当需求发生变更时，需求规约可作为对比基准，评估变更的影响范围和成本；
6. 法律与合同依据：在商业项目中，需求规约可作为合同附件，明确双方责任，减少纠纷。