2025年(軟件工程)軟件工程管理試題及答案一、單項選擇題（每題2分，共30分）1.在Scrum框架中，負責確保團隊理解并遵循Scrum流程的角色是A.產(chǎn)品負責人?B.ScrumMaster?C.開發(fā)團隊?D.項目經(jīng)理答案：B解析：ScrumMaster是流程的守護者，負責移除障礙、促進會議并確保Scrum價值觀被遵守。2.某項目采用COCOMOII模型估算，規(guī)模為80KLOC，選擇“半獨立”模式，比例因子SF=1.08，指數(shù)因子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.持續(xù)反饋?B.持續(xù)集成?C.持續(xù)交付?D.持續(xù)學習答案：A解析：三步工作法為：流動、反饋、持續(xù)學習與實驗，持續(xù)反饋屬于第三步。4.在ISO/IEC25010質(zhì)量模型中，子特性“容錯性”屬于A.功能性?B.可靠性?C.可維護性?D.兼容性答案：B解析：可靠性包含成熟性、容錯性、可恢復(fù)性。5.某微服務(wù)采用藍綠部署，切換流量時發(fā)現(xiàn)新版本CPU飆高，最安全的回滾策略是A.數(shù)據(jù)庫回滾?B.快速切換回綠環(huán)境?C.重新打包鏡像?D.降級功能開關(guān)答案：B解析：藍綠部署的核心優(yōu)勢在于秒級流量切換，回滾成本最低。6.敏捷項目中，用于衡量“交付速率”的常用指標是A.累積流圖?B.燃起圖?C.燃盡圖?D.控制圖答案：C解析：燃盡圖追蹤剩余工作量隨時間減少的趨勢，直接反映速率。7.在軟件配置管理中，基線一旦建立，若要修改必須A.項目經(jīng)理口頭同意?B.提交變更請求并走CCB流程?C.開發(fā)人員直接提交?D.測試經(jīng)理審批答案：B解析：基線變更需正式流程，確?？勺匪菖c風險評估。8.下列關(guān)于技術(shù)債務(wù)的描述，錯誤的是A.主動技術(shù)債務(wù)是團隊為快速交付故意引入?B.被動技術(shù)債務(wù)多因缺乏知識導(dǎo)致?C.技術(shù)債務(wù)只能降低無法清零?D.可使用SQALE方法量化答案：C解析：通過重構(gòu)、替換架構(gòu)等手段可完全清償部分債務(wù)。9.在大型敏捷項目中，采用“ScrumofScrums”時，每日例會最佳頻率是A.每天?B.每周?C.按需?D.每迭代一次答案：C解析：SoS會議關(guān)注跨團隊依賴，頻率依據(jù)集成點與阻塞情況靈活調(diào)整。10.某系統(tǒng)要求RTO≤15分鐘、RPO≤30秒，最合適的容災(zāi)方案是A.冷備?B.溫備?C.熱備雙活?D.磁帶備份答案：C解析：雙活架構(gòu)可實時同步，滿足秒級RPO與分鐘級RTO。11.在精益思想中，“Muda”是指A.不均衡?B.浪費?C.過載?D.缺陷答案：B解析：Muda即無附加值活動，是首要消除對象。12.使用功能點法度量規(guī)模時，內(nèi)部邏輯文件數(shù)量度量的是A.外部輸入?B.外部輸出?C.外部查詢?D.內(nèi)部存儲數(shù)據(jù)組答案：D解析：ILF指系統(tǒng)內(nèi)部維護的邏輯相關(guān)數(shù)據(jù)組。13.某團隊采用看板方法，在制品限額WIP=6，當前卡片數(shù)已達上限，下一步應(yīng)A.繼續(xù)拉入新需求?B.停止拉入并聚焦瓶頸?C.增加一名開發(fā)者?D.提高WIP答案：B解析：WIP超限說明流程擁堵，需先解決瓶頸而非擴大擁堵。14.在威脅建模STRIDE中，Repudiation是指A.否認?B.篡改?C.信息泄露?D.拒絕服務(wù)答案：A解析：Repudiation即某方否認其行為，需日志與不可抵賴機制緩解。15.某項目采用用戶故事地圖，橫向軸通常表示A.用戶類型?B.發(fā)布版本?C.用戶活動順序?D.優(yōu)先級答案：C解析：橫向按用戶旅程時間線展開，縱向按優(yōu)先級排列。二、多項選擇題（每題3分，共15分，多選少選均不得分）16.以下屬于持續(xù)部署流水線質(zhì)量門的有A.單元測試通過率≥90%?B.代碼覆蓋率≥80%?C.靜態(tài)掃描高危漏洞為0?D.性能基準下降不超過5%?E.產(chǎn)品負責人驗收通過答案：ABCD解析：驗收通過屬于發(fā)布門，非部署門。17.關(guān)于微服務(wù)拆分原則，正確的有A.按業(yè)務(wù)能力拆分?B.數(shù)據(jù)庫必須共享?C.接口優(yōu)先契約測試?D.服務(wù)可獨立部署?E.服務(wù)粒度越細越好答案：ACD解析：數(shù)據(jù)庫應(yīng)獨立，粒度需權(quán)衡通信成本。18.以下哪些活動屬于項目收尾階段A.歸檔配置項?B.系統(tǒng)上線?C.合同付款?D.經(jīng)驗教訓(xùn)總結(jié)?E.資源釋放答案：ACDE解析：系統(tǒng)上線屬于執(zhí)行階段。19.在敏捷估算中，寬帶Delphi技術(shù)的步驟包括A.專家匿名提交估算?B.項目經(jīng)理強制拍板?C.召開共識會議?D.使用故事點作為單位?E.多輪迭代直至收斂答案：ACE解析：Delphi強調(diào)匿名與多輪收斂，單位不限。20.以下屬于云原生架構(gòu)模式的有A.Sidecar?B.Bulkhead?C.EventSourcing?D.Saga?E.SharedDatabase答案：ABCD解析：共享數(shù)據(jù)庫反云原生。三、判斷改錯題（每題2分，共10分，先判對錯，再改正）21.在RUP中，每個迭代都必須交付可運行的軟件產(chǎn)品。答案：對。解析：RUP強調(diào)迭代增量交付，每次迭代結(jié)束產(chǎn)生可執(zhí)行制品。22.使用故事點估算時，1故事點代表1人天。答案：錯。改正：故事點是相對復(fù)雜度單位，與時間無固定換算。23.若項目關(guān)鍵路徑上的活動延遲，則項目工期一定延遲。答案：對。解析：關(guān)鍵路徑無浮動時間，任何延遲直接影響總工期。24.在GitFlow模型中，hotfix分支應(yīng)從develop分支拉出。答案：錯。改正：應(yīng)從master分支拉出，修復(fù)后合并回master與develop。25.技術(shù)債務(wù)利息表現(xiàn)為修改同一代碼所需時間隨項目推進而增加。答案：對。解析：債務(wù)累積導(dǎo)致理解、修改成本上升，即利息。四、簡答題（每題8分，共24分）26.闡述DevOps中“基礎(chǔ)設(shè)施即代碼”（IaC）的核心實踐與價值。答案：核心實踐包括：1.使用聲明式語言（Terraform、CloudFormation）描述環(huán)境；2.版本控制所有腳本，實現(xiàn)可審計；3.自動化流水線驅(qū)動創(chuàng)建、變更、銷毀；4.測試基礎(chǔ)設(shè)施（如Terratest）；5.不可變服務(wù)器模式，禁止人工SSH。價值：環(huán)境一致性，消除“在我機器能跑”；快速復(fù)制與回滾；降低配置漂移；提升合規(guī)與安全；支持彈性伸縮與成本優(yōu)化。27.說明如何在高并發(fā)系統(tǒng)中實施“限流”與“熔斷”策略，并給出開源實現(xiàn)。答案：限流針對入口流量，常用算法：令牌桶（平滑突發(fā)）、漏桶（平滑輸出）、滑動窗口計數(shù)。開源實現(xiàn)：Nginxlimit_req、Sentinel、Bucket4j。熔斷針對下游故障，快速失敗防止雪崩，狀態(tài)機：Closed→Open→Half-Open，依據(jù)失敗率或響應(yīng)時間。開源實現(xiàn)：Hystrix、Resilience4j、Sentinel。落地步驟：1.定義閾值（QPS、RT、異常比）；2.配置降級邏輯（返回緩存、默認值）；3.監(jiān)控告警；4.演練驗證。28.描述在敏捷項目中如何建立“定義完成”（DoD）并持續(xù)改進。答案：建立DoD需團隊共創(chuàng)新：1.梳理迭代各環(huán)節(jié)（編碼、單元測試、代碼審查、集成測試、文檔更新）；2.使用檢查單形式，如“所有代碼合并前通過PR審查”“自動化測試通過率100%”；3.在迭代回顧會評審DoD有效性，收集數(shù)據(jù)（缺陷逃逸率、返工時間）；4.使用PDCA循環(huán)，每迭代調(diào)整一條指標，如將“性能基準”納入；5.產(chǎn)品負責人與QA共同參與，確保DoD與業(yè)務(wù)目標對齊；6.將DoD內(nèi)置于CI門禁，無法繞過。五、計算與建模題（共21分）29.（10分）某項目歷史數(shù)據(jù)顯示：生產(chǎn)率=18LOC/人時，需求文檔共45頁，平均0.8KLOC/頁，團隊8人，每天有效工時6小時，每周5天。采用WBS拆分后，模塊A預(yù)估12KLOC，模塊B8KLOC，模塊C10KLOC，復(fù)用率30%，調(diào)整系數(shù)1.2（復(fù)雜度+新人）。計算：（1）總凈新增規(guī)模；（2）總工作量（人月）；（3）理想日歷月（無并行）；（4）若采用2個并行FeatureTeam，最短日歷月；（5）在（4）前提下，為壓縮20%工期，需提升生產(chǎn)率到多少？答案：（1）總毛規(guī)模=30KLOC，復(fù)用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人時，新生產(chǎn)率=21000/240=87.5LOC/人時，提升倍數(shù)=87.5/18≈4.86倍。30.（11分）某微服務(wù)系統(tǒng)由5個服務(wù)組成，調(diào)用鏈：API-Gateway→A→B→C→D。各服務(wù)99th延遲（ms）分別為：20、40、60、80、30。網(wǎng)絡(luò)往返延遲忽略。（1）計算端到端99th延遲；（2）若要求整體99th≤200ms，哪個服務(wù)需優(yōu)先優(yōu)化？（3）采用“并行調(diào)用B、C”重構(gòu)，求新99th；（4）在（3）基礎(chǔ)上，若A→B、A→C均失敗率1%，且失敗時重試一次，重試成功概率99%，求可用性下降到多少？（可用性=成功概率）答案：（1）P99鏈=20+40+60+80+30=230ms（2）C服務(wù)80ms貢獻最大，優(yōu)先優(yōu)化。（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分）背景：某互聯(lián)網(wǎng)教育公司計劃2025年Q2上線“AI作業(yè)批改”SaaS，采用微服務(wù)+Kubernetes，團隊60人，分布北京、成都兩地。產(chǎn)品負責人要求支持百萬級日活，99.9%可用性，平均響應(yīng)<500ms。當前痛點：需求變更頻繁、集成沖突多、測試環(huán)境不穩(wěn)定、線上故障頻發(fā)。公司決定引入DevOps與SRE實踐，任命你為變革負責人。31.（12分）請給出“一站式DevOps平臺”建設(shè)的頂層藍圖，包含：a.核心能力模塊與對應(yīng)開源/商業(yè)工具選型；b.多環(huán)境（dev/test/stage/prod）治理策略；c.兩地協(xié)同的代碼托管與CI/CD架構(gòu)；d.質(zhì)量門禁設(shè)計示例（含指標閾值）。答案：a.模塊與工具：1.代碼托管：GitLabEE（Geo多活）；2.CI：GitLabRunner+DockerinDocker；3.構(gòu)建：Kaniko安全構(gòu)建鏡像；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.協(xié)作：Jira+Confluence+飛書集成。b.環(huán)境治理：dev：命名空間隔離，自動睡眠節(jié)省成本；test：每日定時同步生產(chǎn)脫敏數(shù)據(jù)，使用K8sRBAC限制開發(fā)者直接操作；stage：全量壓測環(huán)境，與prod同規(guī)格，僅只讀；prod：雙集群雙AZ，ArgoCD禁止手動kubectl，所有變更通過PR。c.架構(gòu)：GitLabGeo主節(jié)點北京，成都為從節(jié)點，實時同步；Runner標簽按地域與資源池劃分，緩存使用分布式MinIO；Harbor啟用代理緩存，鏡像推送北京后自動復(fù)制成都；ArgoCDAppset統(tǒng)一管理雙集群，SealedSecret加密敏感信息。d.質(zhì)量門禁示例：1.單測覆蓋率≥80%，新代碼≥90%；2.Sonar高危漏洞=0；3.Trivy鏡像高危漏洞=0；4.接口自動化通過率100%；5.性能基準：P99≤400ms，錯誤率≤0.1%；6.安全基線：以CISKubernetesBenchmark得分≥90%。任一門禁失敗，流水線自動終止并通知。32.（12分）針對“線上故障頻發(fā)”，設(shè)計一套SRE可靠性治理方案，要求：a.錯誤預(yù)算（ErrorBudget）制定過程與公式；b.SLI/SLO選取與測量方法；c.故障應(yīng)急響應(yīng)與復(fù)盤機制；d.自動化修復(fù)（Auto-Healing）實現(xiàn)思路。答案：a.錯誤預(yù)算：可用性目標=99.9%，年允許停機=365×24×60×0.0001≈525分鐘；按月分配=525/12≈44分鐘，作為ErrorBudget；預(yù)算消耗>80%觸發(fā)凍結(jié)發(fā)布，>100%觸發(fā)降級維護窗口。b.SLI/SLO：1.請求成功率：SLI=有效請求/總請求，SLO=99.9%；2.延遲：SLI=成功請求中<500ms比例，SLO=99%；3.業(yè)務(wù)自定義：批改任務(wù)完成率，SLO=99.5%。測量：Prometheus記錄sidecarEnvoy指標，GrafanaSLI儀表板自動計算7天滑動窗口。c.應(yīng)急響應(yīng)：1.On-call輪值，5分鐘響應(yīng)；2.故障分級：P0（全站不可用）、P1（核心功能）