软件工程的试题及答案

软件工程的试题及答案一、单项选择题（每题2分，共20分）1.以下哪项不属于软件危机的典型表现？A.软件交付时间远超预期B.软件维护成本占总成本比例低于10%C.软件功能与用户需求存在显著偏差D.软件可靠性不足，频繁出现运行错误2.瀑布模型的核心特征是？A.强调迭代与增量开发B.各阶段严格顺序执行，前一阶段完成后才能进入下一阶段C.允许在编码阶段直接修改需求D.以用户原型为核心驱动开发3.用例图（UseCaseDiagram）中，“扩展（Extend）”关系的作用是？A.表示一个用例需要另一个用例的支持才能完成B.表示在特定条件下，一个用例可以添加额外的行为到另一个用例中C.表示两个用例共享部分功能D.表示参与者与用例之间的交互路径4.以下哪种测试方法属于黑盒测试？A.语句覆盖测试B.等价类划分测试C.条件覆盖测试D.路径覆盖测试5.模块间通过参数表传递简单数据，这种耦合类型称为？A.内容耦合B.公共耦合C.控制耦合D.数据耦合6.敏捷开发（AgileDevelopment）的核心原则不包括？A.个体与交互胜过流程与工具B.可工作的软件胜过详尽的文档C.客户协作胜过合同谈判D.严格遵循计划胜过响应变化7.软件可靠性通常用“平均无故障时间（MTTF）”衡量，其计算公式为？A.总运行时间/故障次数B.故障次数/总运行时间C.修复时间总和/故障次数D.总运行时间/修复时间总和8.UML（统一建模语言）中，用于描述系统动态行为的视图是？A.用例视图（UseCaseView）B.逻辑视图（LogicalView）C.进程视图（ProcessView）D.状态机视图（StateMachineView）9.软件配置管理（SCM）的核心活动不包括？A.版本控制B.变更控制C.缺陷跟踪D.需求验证10.软件维护中，为适应新的硬件环境或操作系统升级而进行的修改属于？A.正确性维护B.适应性维护C.完善性维护D.预防性维护二、填空题（每题2分，共20分）1.软件工程的三要素是方法、工具和__________。2.需求规格说明书（SRS）的核心特性包括正确性、完整性、一致性、可验证性和__________。3.模块独立性的两个关键指标是__________（衡量模块功能单一程度）和耦合（衡量模块间依赖程度）。4.白盒测试的覆盖标准中，__________要求程序中每个判断的所有可能结果至少执行一次。5.设计模式（DesignPattern）根据用途可分为创建型、结构型和__________三类。6.软件项目估算中，__________方法通过将项目分解为若干子任务，分别估算后求和得到总工作量。7.ISO/IEC25010软件质量模型中，“性能效率”属于__________质量特性。8.敏捷开发中的“用户故事（UserStory）”通常以“作为<角色>，我希望<功能>，以便<价值>”的格式描述，其核心作用是__________。9.软件缺陷的生命周期通常包括：新建、确认、分配、修复、__________、关闭等阶段。10.软件体系结构设计中，__________风格通过定义组件间的消息传递规则实现系统解耦（如生产者-消费者模式）。三、简答题（每题8分，共40分）1.简述软件生命周期模型的选择依据。需结合项目需求明确性、团队经验、资源约束等因素说明。2.需求分析的主要任务是什么？常用的需求获取方法有哪些？请列举至少4种方法并简要说明。3.模块化设计中，为何强调“高内聚、低耦合”？请从可维护性、可测试性、可复用性三个角度解释。4.黑盒测试与白盒测试的核心区别是什么？分别适用于哪些测试阶段？5.敏捷开发与传统瀑布模型在需求管理上的差异主要体现在哪些方面？请从需求变更处理、文档要求、客户参与度三个维度对比。四、应用题（每题10分，共20分）1.某公司计划开发一款“智能校园卡管理系统”，用户需求如下：学生可通过手机APP查询余额、交易记录，挂失/解挂校园卡；食堂、图书馆等终端设备支持校园卡刷卡消费、身份验证；管理员可统计各部门消费数据，设置卡类型（如学生卡、教师卡）的权限；系统需支持与学校现有教务系统对接，同步学生基本信息。请根据上述需求，编写需求规格说明书（SRS）的主要章节框架（至少包含6个核心章节），并说明每个章节的核心内容。2.为某系统的“用户登录”功能设计测试用例。功能需求为：用户名需为6-12位字母或数字组合，不支持特殊符号；密码需为8-16位，包含至少1位大写字母、1位小写字母和1位数字；连续输错3次密码，账号锁定15分钟；登录成功后跳转至主页，失败提示“用户名或密码错误”。要求覆盖等价类划分、边界值分析、错误推测法，设计至少8个测试用例（需包含输入数据、预期结果）。五、综合分析题（20分）某软件开发团队承接了一个小型电商系统开发项目，采用瀑布模型。项目初期需求调研不充分，仅形成了初步的功能列表；开发过程中，客户频繁提出需求变更（如新增“直播带货”模块、修改购物车逻辑），导致开发进度严重滞后；编码完成后，测试发现大量界面兼容性问题（如不同浏览器显示异常）和逻辑错误（如促销活动叠加计算错误）；最终交付时，软件质量未达预期，客户满意度低。请结合软件工程知识，分析该项目失败的主要原因，并提出具体改进措施（需涵盖需求管理、过程模型选择、测试策略、团队协作等方面）。参考答案一、单项选择题1.B（软件维护成本通常占总成本的60%以上，低于10%不属于危机表现）2.B（瀑布模型强调阶段顺序性和依赖性）3.B（扩展关系用于条件性添加行为）4.B（等价类划分基于功能输入输出，属于黑盒测试）5.D（数据耦合通过参数传递简单数据）6.D（敏捷强调响应变化胜过遵循计划）7.A（MTTF=总运行时间/故障次数）8.D（状态机视图描述对象状态转换的动态行为）9.D（需求验证属于需求工程，非SCM核心）10.B（适应性维护针对环境变化）二、填空题1.过程2.可修改性（或可跟踪性）3.内聚4.判断覆盖（或分支覆盖）5.行为型6.分解估算（或自底向上估算）7.产品质量8.简化需求描述，促进客户与开发团队的沟通9.回归测试（或验证）10.事件驱动（或消息驱动）三、简答题1.选择依据包括：（1）需求明确性：需求清晰且稳定时选瀑布模型；需求模糊或易变时选敏捷或原型模型。（2）团队经验：新手团队适合结构清晰的瀑布模型；经验丰富的团队可采用敏捷。（3）资源约束：资源充足时可选迭代模型（如RUP）；资源紧张时选快速原型。（4）项目规模：大型项目需分阶段控制（瀑布），小型项目适合敏捷。（5）客户参与度：客户频繁参与选敏捷，否则选瀑布。2.需求分析的主要任务：明确系统“做什么”，包括获取用户需求、分析并建模（如用例图、数据流图）、编写需求规格说明书（SRS）、验证需求正确性。常用方法：（1）用户访谈：直接与用户沟通获取痛点；（2）问卷调查：收集大量用户的结构化反馈；（3）场景分析：通过模拟用户使用场景挖掘隐含需求；（4）原型法：通过快速原型让用户直观反馈；（5）头脑风暴：团队集体讨论激发需求。3.（1）可维护性：高内聚模块功能单一，修改时影响范围小；低耦合模块间依赖少，变更一个模块对其他模块影响小。（2）可测试性：高内聚模块功能独立，测试用例设计更简单；低耦合模块可单独测试，减少依赖干扰。（3）可复用性：高内聚模块功能明确，更易被其他系统复用；低耦合模块与外部接口简单，复用成本低。4.核心区别：黑盒测试基于功能规格，不关注内部代码结构；白盒测试基于代码逻辑，覆盖路径、分支等。适用阶段：黑盒测试多用于集成测试、系统测试、验收测试；白盒测试多用于单元测试、组件测试。5.（1）需求变更处理：瀑布模型要求需求冻结后尽量不变更，变更需走严格流程；敏捷接受需求变更，通过迭代快速响应。（2）文档要求：瀑布模型强调详细的需求文档（如SRS）；敏捷仅保留必要文档（如用户故事），更注重可运行软件。（3）客户参与度：瀑布模型客户主要参与需求阶段和验收阶段；敏捷要求客户全程参与（如每日站会、迭代评审）。四、应用题1.SRS主要章节框架及内容：（1）说明系统背景、目标、文档范围及参考资料。（2）总体描述：定义系统边界（如与教务系统对接）、用户角色（学生、管理员、终端设备）、运行环境（手机APP的iOS/Android，终端设备的Windows/Linux）。（3）功能需求：分用户模块（查询、挂失）、终端模块（刷卡消费）、管理模块（数据统计、权限设置）、接口需求（与教务系统的数据同步协议）。（4）性能需求：定义响应时间（如查询余额≤2秒）、并发量（如同时1000人登录）、终端设备处理速度（如刷卡验证≤500ms）。（5）质量属性：可靠性（MTTF≥500小时）、安全性（校园卡信息加密传输）、易用性（APP界面操作步骤≤3步）。（6）约束与限制：如必须使用学校指定的数据库（MySQL）、对接教务系统的API版本（V2.0）。2.测试用例设计（示例）：测试用例ID输入数据（用户名/密码）预期结果覆盖方法TC01user123（6位字母数字）/Pass123（8位，含大小写数字）登录成功，跳转主页有效等价类TC02user（5位）/Pass123提示“用户名格式错误”边界值（用户名长度下限-1）TC03user123456789（13位）/Pass123提示“用户名格式错误”边界值（用户名长度上限+1）TC04user@123（含特殊符号）/Pass123提示“用户名格式错误”无效等价类（特殊符号）TC05user123/pass123（无大写字母）提示“密码格式错误”无效等价类（缺少大写）TC06user123/PASS123（无小写字母）提示“密码格式错误”无效等价类（缺少小写）TC07user123/Pass（7位）提示“密码格式错误”边界值（密码长度下限-1）TC08正确用户名/错误密码（连续3次）第3次提示“账号锁定15分钟”错误推测法（锁定逻辑）五、综合分析题失败原因分析：（1）需求管理不足：初期需求调研不充分，仅形成功能列表，未明确细节（如“直播带货”的具体功能）；未建立需求变更控制流程，导致客户随意变更需求。（2）过程模型选择不当：瀑布模型对需求稳定性要求高，而项目需求易变，应选择敏捷或迭代模型。（3）测试策略缺失：未在编码阶段进行单元测试，导致后期集中测试时发现大量底层错误；界面兼容性测试未覆盖主流浏览器（如Chrome、Firefox）。（4）团队协作低效：客户参与度低，需求变更未及时同步开发团队；缺乏每日站会等沟通机制，进度信息不透明。改进措施：（1）需求管理：采用用户故事和用例图细化需求，建立需求跟踪矩阵（RTM）；设置变更控制委员会（CCB），评估变更影响（如时间、成本）后再实施。（2）过程模型调整：切换为Scrum（敏捷）模型，以2