2025年(软件工程)软件工程管理试题及答案

2025年(软件工程)软件工程管理试题及答案一、单项选择题（每题2分，共30分）1.在Scrum框架中，负责确保团队理解并遵循Scrum流程的角色是A.产品负责人 B.ScrumMaster C.开发团队 D.项目经理答案：B解析：ScrumMaster是流程的守护者，负责移除障碍、促进会议并确保Scrum价值观被遵守。2.某项目采用COCOMOII模型估算，规模为80KLOC，选择“半独立”模式，比例因子SF=1.08，指数因子EM=1.15，则工作量最接近A.480人月 B.620人月 C.740人月 D.890人月答案：C解析：PM=2.94×(80)^1.08×1.15≈738人月，四舍五入得740人月。3.下列哪项不是DevOps“三步工作法”中的第二步A.持续反馈 B.持续集成 C.持续交付 D.持续学习答案：A解析：三步工作法为：流动、反馈、持续学习与实验，持续反馈属于第三步。4.在ISO/IEC25010质量模型中，子特性“容错性”属于A.功能性 B.可靠性 C.可维护性 D.兼容性答案：B解析：可靠性包含成熟性、容错性、可恢复性。5.某微服务采用蓝绿部署，切换流量时发现新版本CPU飙高，最安全的回滚策略是A.数据库回滚 B.快速切换回绿环境 C.重新打包镜像 D.降级功能开关答案：B解析：蓝绿部署的核心优势在于秒级流量切换，回滚成本最低。6.敏捷项目中，用于衡量“交付速率”的常用指标是A.累积流图 B.燃起图 C.燃尽图 D.控制图答案：C解析：燃尽图追踪剩余工作量随时间减少的趋势，直接反映速率。7.在软件配置管理中，基线一旦建立，若要修改必须A.项目经理口头同意 B.提交变更请求并走CCB流程 C.开发人员直接提交 D.测试经理审批答案：B解析：基线变更需正式流程，确保可追溯与风险评估。8.下列关于技术债务的描述，错误的是A.主动技术债务是团队为快速交付故意引入 B.被动技术债务多因缺乏知识导致 C.技术债务只能降低无法清零 D.可使用SQALE方法量化答案：C解析：通过重构、替换架构等手段可完全清偿部分债务。9.在大型敏捷项目中，采用“ScrumofScrums”时，每日例会最佳频率是A.每天 B.每周 C.按需 D.每迭代一次答案：C解析：SoS会议关注跨团队依赖，频率依据集成点与阻塞情况灵活调整。10.某系统要求RTO≤15分钟、RPO≤30秒，最合适的容灾方案是A.冷备 B.温备 C.热备双活 D.磁带备份答案：C解析：双活架构可实时同步，满足秒级RPO与分钟级RTO。11.在精益思想中，“Muda”是指A.不均衡 B.浪费 C.过载 D.缺陷答案：B解析：Muda即无附加值活动，是首要消除对象。12.使用功能点法度量规模时，内部逻辑文件数量度量的是A.外部输入 B.外部输出 C.外部查询 D.内部存储数据组答案：D解析：ILF指系统内部维护的逻辑相关数据组。13.某团队采用看板方法，在制品限额WIP=6，当前卡片数已达上限，下一步应A.继续拉入新需求 B.停止拉入并聚焦瓶颈 C.增加一名开发者 D.提高WIP答案：B解析：WIP超限说明流程拥堵，需先解决瓶颈而非扩大拥堵。14.在威胁建模STRIDE中，Repudiation是指A.否认 B.篡改 C.信息泄露 D.拒绝服务答案：A解析：Repudiation即某方否认其行为，需日志与不可抵赖机制缓解。15.某项目采用用户故事地图，横向轴通常表示A.用户类型 B.发布版本 C.用户活动顺序 D.优先级答案：C解析：横向按用户旅程时间线展开，纵向按优先级排列。二、多项选择题（每题3分，共15分，多选少选均不得分）16.以下属于持续部署流水线质量门的有A.单元测试通过率≥90% B.代码覆盖率≥80% C.静态扫描高危漏洞为0 D.性能基准下降不超过5% E.产品负责人验收通过答案：ABCD解析：验收通过属于发布门，非部署门。17.关于微服务拆分原则，正确的有A.按业务能力拆分 B.数据库必须共享 C.接口优先契约测试 D.服务可独立部署 E.服务粒度越细越好答案：ACD解析：数据库应独立，粒度需权衡通信成本。18.以下哪些活动属于项目收尾阶段A.归档配置项 B.系统上线 C.合同付款 D.经验教训总结 E.资源释放答案：ACDE解析：系统上线属于执行阶段。19.在敏捷估算中，宽带Delphi技术的步骤包括A.专家匿名提交估算 B.项目经理强制拍板 C.召开共识会议 D.使用故事点作为单位 E.多轮迭代直至收敛答案：ACE解析：Delphi强调匿名与多轮收敛，单位不限。20.以下属于云原生架构模式的有A.Sidecar B.Bulkhead C.EventSourcing D.Saga E.SharedDatabase答案：ABCD解析：共享数据库反云原生。三、判断改错题（每题2分，共10分，先判对错，再改正）21.在RUP中，每个迭代都必须交付可运行的软件产品。答案：对。解析：RUP强调迭代增量交付，每次迭代结束产生可执行制品。22.使用故事点估算时，1故事点代表1人天。答案：错。改正：故事点是相对复杂度单位，与时间无固定换算。23.若项目关键路径上的活动延迟，则项目工期一定延迟。答案：对。解析：关键路径无浮动时间，任何延迟直接影响总工期。24.在GitFlow模型中，hotfix分支应从develop分支拉出。答案：错。改正：应从master分支拉出，修复后合并回master与develop。25.技术债务利息表现为修改同一代码所需时间随项目推进而增加。答案：对。解析：债务累积导致理解、修改成本上升，即利息。四、简答题（每题8分，共24分）26.阐述DevOps中“基础设施即代码”（IaC）的核心实践与价值。答案：核心实践包括：1.使用声明式语言（Terraform、CloudFormation）描述环境；2.版本控制所有脚本，实现可审计；3.自动化流水线驱动创建、变更、销毁；4.测试基础设施（如Terratest）；5.不可变服务器模式，禁止人工SSH。价值：环境一致性，消除“在我机器能跑”；快速复制与回滚；降低配置漂移；提升合规与安全；支持弹性伸缩与成本优化。27.说明如何在高并发系统中实施“限流”与“熔断”策略，并给出开源实现。答案：限流针对入口流量，常用算法：令牌桶（平滑突发）、漏桶（平滑输出）、滑动窗口计数。开源实现：Nginxlimit_req、Sentinel、Bucket4j。熔断针对下游故障，快速失败防止雪崩，状态机：Closed→Open→Half-Open，依据失败率或响应时间。开源实现：Hystrix、Resilience4j、Sentinel。落地步骤：1.定义阈值（QPS、RT、异常比）；2.配置降级逻辑（返回缓存、默认值）；3.监控告警；4.演练验证。28.描述在敏捷项目中如何建立“定义完成”（DoD）并持续改进。答案：建立DoD需团队共创新：1.梳理迭代各环节（编码、单元测试、代码审查、集成测试、文档更新）；2.使用检查单形式，如“所有代码合并前通过PR审查”“自动化测试通过率100%”；3.在迭代回顾会评审DoD有效性，收集数据（缺陷逃逸率、返工时间）；4.使用PDCA循环，每迭代调整一条指标，如将“性能基准”纳入；5.产品负责人与QA共同参与，确保DoD与业务目标对齐；6.将DoD内置于CI门禁，无法绕过。五、计算与建模题（共21分）29.（10分）某项目历史数据显示：生产率=18LOC/人时，需求文档共45页，平均0.8KLOC/页，团队8人，每天有效工时6小时，每周5天。采用WBS拆分后，模块A预估12KLOC，模块B8KLOC，模块C10KLOC，复用率30%，调整系数1.2（复杂度+新人）。计算：（1）总净新增规模；（2）总工作量（人月）；（3）理想日历月（无并行）；（4）若采用2个并行FeatureTeam，最短日历月；（5）在（4）前提下，为压缩20%工期，需提升生产率到多少？答案：（1）总毛规模=30KLOC，复用30%，净新增=30×(1-0.3)=21KLOC（2）工作量=21×1000/(18×6×5×4)×1.2≈21×1000/2160×1.2≈11.67人月（3）理想日历月=11.67/8≈1.46月（4）2团队并行，理论最短=1.46/2≈0.73月≈22天（5）压缩20%工期=0.73×0.8≈0.584月=17.5天，需完成21KLOC，总工时=8×2×6×17.5/7=240人时，新生产率=21000/240=87.5LOC/人时，提升倍数=87.5/18≈4.86倍。30.（11分）某微服务系统由5个服务组成，调用链：API-Gateway→A→B→C→D。各服务99th延迟（ms）分别为：20、40、60、80、30。网络往返延迟忽略。（1）计算端到端99th延迟；（2）若要求整体99th≤200ms，哪个服务需优先优化？（3）采用“并行调用B、C”重构，求新99th；（4）在（3）基础上，若A→B、A→C均失败率1%，且失败时重试一次，重试成功概率99%，求可用性下降到多少？（可用性=成功概率）答案：（1）P99链=20+40+60+80+30=230ms（2）C服务80ms贡献最大，优先优化。（3）B、C并行，新链=20+max(40,60)+80+30=20+60+80+30=190ms（4）原可用性=0.99^5≈0.95099，并行后B、C失败重试：单次失败1%，重试后失败0.01×0.01=0.0001，成功概率=1-0.0001=0.9999，整体可用性=0.99×0.9999×0.99×0.99≈0.9702，反而上升，因并行降低长尾。六、案例分析题（共24分）背景：某互联网教育公司计划2025年Q2上线“AI作业批改”SaaS，采用微服务+Kubernetes，团队60人，分布北京、成都两地。产品负责人要求支持百万级日活，99.9%可用性，平均响应<500ms。当前痛点：需求变更频繁、集成冲突多、测试环境不稳定、线上故障频发。公司决定引入DevOps与SRE实践，任命你为变革负责人。31.（12分）请给出“一站式DevOps平台”建设的顶层蓝图，包含：a.核心能力模块与对应开源/商业工具选型；b.多环境（dev/test/stage/prod）治理策略；c.两地协同的代码托管与CI/CD架构；d.质量门禁设计示例（含指标阈值）。答案：a.模块与工具：1.代码托管：GitLabEE（Geo多活）；2.CI：GitLabRunner+DockerinDocker；3.构建：Kaniko安全构建镜像；4.制品库：Harbor（两地同步）；5.安全扫描：Trivy+SonarQube+Dependency-Check；6.测试：JUnit+PyTest+Postman/Newman+SeleniumGrid；7.部署：ArgoCDGitOps，支持Canary、BlueGreen；8.观测：Prometheus+Grafana+Jaeger+ELK；9.混沌：ChaosMesh；10.协作：Jira+Confluence+飞书集成。b.环境治理：dev：命名空间隔离，自动睡眠节省成本；test：每日定时同步生产脱敏数据，使用K8sRBAC限制开发者直接操作；stage：全量压测环境，与prod同规格，仅只读；prod：双集群双AZ，ArgoCD禁止手动kubectl，所有变更通过PR。c.架构：GitLabGeo主节点北京，成都为从节点，实时同步；Runner标签按地域与资源池划分，缓存使用分布式MinIO；Harbor启用代理缓存，镜像推送北京后自动复制成都；ArgoCDAppset统一管理双集群，SealedSecret加密敏感信息。d.质量门禁示例：1.单测覆盖率≥80%，新代码≥90%；2.Sonar高危漏洞=0；3.Trivy镜像高危漏洞=0；4.接口自动化通过率100%；5.性能基准：P99≤400ms，错误率≤0.1%；6.安全基线：以CISKubernetesBenchmark得分≥90%。任一门禁失败，流水线自动终止并通知。32.（12分）针对“线上故障频发”，设计一套SRE可靠性治理方案，要求：a.错误预算（ErrorBudget）制定过程与公式；b.SLI/SLO选取与测量方法；c.故障应急响应与复盘机制；d.自动化修复（Auto-Healing）实现思路。答案：a.错误预算：可用性目标=99.9%，年允许停机=365×24×60×0.0001≈525分钟；按月分配=525/12≈44分钟，作为ErrorBudget；预算消耗>80%触发冻结发布，>100%触发降级维护窗口。b.SLI/SLO：1.请求成功率：SLI=有效请求/总请求，SLO=99.9%；2.延迟：SLI=成功请求中<500ms比例，SLO=99%；3.业务自定义：批改任务完成率，SLO=99.5%。测量：Prometheus记录sidecarEnvoy指标，GrafanaSLI仪表板自动计算7天滑动窗口。c.应急响应：1.On-call轮值，5分钟响应；2.故障分级：P0（全站不可用）、P1（核心功能）