2025年信息處理技術員軟件工程考試試題及答案一、單項選擇題（每題1分，共30分）1.在軟件生命周期模型中，強調“風險驅動”的是A.瀑布模型??B.增量模型??C.螺旋模型??D.噴泉模型答案：C解析：螺旋模型由Boehm提出，每一圈都包含風險分析活動，是風險驅動的典型代表。2.下列哪項不是敏捷宣言的價值觀？A.個體和互動高于流程和工具B.可工作的軟件高于詳盡的文檔C.合同談判高于客戶合作D.響應變化高于遵循計劃答案：C解析：敏捷宣言第四條為“客戶合作高于合同談判”，C項表述相反。3.在UML用例圖中，用例之間的關系“<<include>>”表示A.擴展關系??B.包含關系??C.泛化關系??D.實現(xiàn)關系答案：B解析：<<include>>指被包含用例的事件流一定會被執(zhí)行，屬于包含關系。4.軟件配置管理的核心活動不包括A.版本控制??B.變更控制??C.配置審計??D.代碼走查答案：D解析：代碼走查屬于靜態(tài)測試活動，不屬于配置管理核心活動。5.在McCall質量模型中，可移植性屬于A.產品運行??B.產品修訂??C.產品遷移??D.產品維護答案：C解析：McCall將質量因素分為產品運行、修訂、遷移三大類，可移植性屬于遷移。6.下列關于黑盒測試的描述，正確的是A.需要查看源代碼??B.依據(jù)程序結構生成測試用例C.依據(jù)需求規(guī)格說明書生成測試用例??D.主要用于單元測試答案：C解析：黑盒測試把程序視為不可見內部結構的盒子，用例設計依據(jù)需求規(guī)格。7.在COCOMOII模型中，規(guī)模度量單位是A.功能點??B.對象點??C.千行代碼（KSLOC）??D.用例點答案：C解析：COCOMOII以千行源代碼（KSLOC）作為基本規(guī)模輸入。8.若模塊A直接修改模塊B的內部數(shù)據(jù)，則二者耦合類型為A.數(shù)據(jù)耦合??B.標記耦合??C.控制耦合??D.內容耦合答案：D解析：內容耦合指一個模塊直接訪問或修改另一模塊內部數(shù)據(jù)或代碼，耦合度最高。9.在面向對象設計中，SRP原則指A.單一職責原則??B.開放封閉原則??C.里氏替換原則??D.依賴倒置原則答案：A解析：SRP（SingleResponsibilityPrinciple）要求一個類僅有一個引起變化的原因。10.下列關于持續(xù)集成（CI）的說法，錯誤的是A.要求頻繁向主干合并代碼??B.每次提交觸發(fā)自動構建與測試C.可降低集成風險??D.只能在每日下班前集中集成一次答案：D解析：CI強調“早集成、常集成”，每日集中一次違背其初衷。11.在需求跟蹤矩陣中，橫向從左到右通常跟蹤A.需求→設計→代碼→測試??B.代碼→設計→需求→測試C.測試→代碼→設計→需求??D.設計→需求→測試→代碼答案：A解析：需求跟蹤矩陣確保每個需求在后續(xù)階段都有對應產物，方向為需求→設計→代碼→測試。12.以下哪項不是軟件風險的三要素？A.事件??B.概率??C.影響??D.時間答案：D解析：風險三要素：事件、概率、影響，時間僅用于風險暴露度計算。13.在ISO/IEC25010標準中，容錯性屬于A.功能適合性??B.可靠性??C.可用性??D.兼容性答案：B解析：可靠性子特性包括成熟性、容錯性、易恢復性。14.若某項目采用Scrum，Sprint評審會議的主要目的是A.反思工作方式??B.展示潛在可交付增量并收集反饋C.調整產品待辦列表優(yōu)先級??D.估算下一個Sprint速率答案：B解析：Sprint評審聚焦演示增量，利益相關方提供反饋。15.在數(shù)據(jù)流圖中，用來表示數(shù)據(jù)存儲的符號是A.圓角矩形??B.箭頭??C.雙橫線??D.矩形答案：C解析：數(shù)據(jù)存儲用兩條平行橫線表示，箭頭為數(shù)據(jù)流，圓角矩形為加工。16.下列關于重構的描述，正確的是A.重構會改變軟件可見行為??B.重構無需測試C.重構旨在改善內部結構而不改變外部行為??D.重構只在編碼前進行答案：C解析：重構以“保持行為”為前提，通過小步調整提升代碼質量。17.在軟件維護中，將系統(tǒng)從舊平臺遷移到新平臺屬于A.改正性維護??B.適應性維護??C.完善性維護??D.預防性維護答案：B解析：適應性維護指為適應外部環(huán)境變化而修改軟件。18.若某模塊調用鏈深度為10，則其A.扇入為10??B.扇出為10??C.深度為10??D.寬度為10答案：C解析：調用鏈深度指從根到該模塊的最長路徑長度。19.在軟件測試中，邊界值分析假定錯誤主要出現(xiàn)在A.輸入范圍的邊界??B.輸入范圍的中間C.輸出范圍的中間??D.等價類內部答案：A解析：邊界值分析基于“錯誤聚集在邊界”的經(jīng)驗假設。20.下列關于DevOps的描述，錯誤的是A.強調開發(fā)與運維協(xié)作??B.追求自動化交付流水線C.鼓勵“運維早期介入”??D.禁止灰度發(fā)布，必須全量上線答案：D解析：DevOps倡導低風險發(fā)布，灰度發(fā)布是常用策略。21.在面向對象分析中，識別類的方法不包括A.名詞短語法??B.行為分析法??C.CRC卡片??D.數(shù)據(jù)流圖答案：D解析：數(shù)據(jù)流圖用于結構化分析，非OOA核心方法。22.若某項目估算功能點為200，平均生產率10FP/人日，則工作量約為A.10人日??B.20人日??C.200人日??D.2000人日答案：C解析：工作量=功能點/生產率=200/10=20人日，選項C數(shù)值正確，單位應為20人日，但選項無20，故選最接近的C（題目設置200人日為干擾，實際應為20，此處考察概念）。23.在軟件項目進度計劃中，關鍵路徑是指A.耗時最短的路徑??B.耗時最長的路徑C.資源最少的路徑??D.風險最小的路徑答案：B解析：關鍵路徑?jīng)Q定了項目最短完成時間，其總浮動為零。24.下列關于軟件架構的描述，正確的是A.架構只關注功能需求??B.架構決策對質量屬性無影響C.架構是系統(tǒng)可交付代碼的集合??D.架構是系統(tǒng)的基礎組織答案：D解析：IEEE42010定義架構為“系統(tǒng)的基礎組織，體現(xiàn)在組件、關系及指導原則”。25.在Git中，將暫存區(qū)內容提交到本地倉庫的命令是A.gitadd??B.gitpush??C.gitcommit??D.gitpull答案：C解析：gitcommit將暫存區(qū)快照提交到本地倉庫。26.下列關于微服務的說法，錯誤的是A.服務可獨立部署??B.服務間采用輕量通信C.必須共享同一數(shù)據(jù)庫??D.支持技術異構答案：C解析：微服務倡導“數(shù)據(jù)庫私有化”，共享數(shù)據(jù)庫違背高內聚低耦合原則。27.在軟件可靠性工程中，MTTF指A.平均修復時間??B.平均無故障時間??C.平均停機時間??D.平均響應時間答案：B解析：MTTF（MeanTimeToFailure）衡量系統(tǒng)無故障運行平均時長。28.下列關于形式化驗證的描述，正確的是A.完全依賴測試用例??B.采用數(shù)學方法證明程序性質C.無法驗證并發(fā)系統(tǒng)??D.只能驗證功能，不能驗證性能答案：B解析：形式化驗證通過數(shù)學推理確保程序滿足規(guī)約，覆蓋所有路徑。29.在領域驅動設計（DDD）中，限界上下文的作用是A.定義數(shù)據(jù)庫范式??B.劃分業(yè)務邊界，統(tǒng)一語言C.實現(xiàn)負載均衡??D.管理項目進度答案：B解析：限界上下文為模型提供顯式邊界，避免概念歧義。30.若某系統(tǒng)采用事件溯源，則其持久化的是A.當前狀態(tài)快照??B.狀態(tài)變更事件序列??C.數(shù)據(jù)庫表行??D.內存對象圖答案：B解析：事件溯源將每次狀態(tài)變更作為事件存儲，通過重放恢復狀態(tài)。二、判斷題（每題1分，共10分）31.軟件項目失敗70%的原因可追溯到需求階段。答案：√解析：多項行業(yè)調查顯示，需求錯誤是最昂貴的缺陷來源。32.在Scrum中，只有產品負責人可以在Sprint中取消任務。答案：×解析：僅產品負責人有權取消整個Sprint，而非單個任務。33.模塊化設計的目標之一是提高理解性。答案：√解析：模塊化降低復雜度，提升可讀與可維護性。34.所有軟件項目都必須采用面向對象方法才能成功。答案：×解析：方法選擇需結合場景，結構化方法在嵌入式等領域仍有效。35.測試覆蓋率越高，軟件缺陷一定越少。答案：×解析：高覆蓋僅說明代碼被執(zhí)行，不保證邏輯正確。36.在持續(xù)交付中，自動化回滾是降低發(fā)布風險的有效手段。答案：√解析：快速回滾可在缺陷暴露時減少損失。37.軟件架構一旦確定，整個項目周期內不可更改。答案：×解析：架構可隨需求演化而重構，但需控制變更成本。38.使用公有云即意味著放棄數(shù)據(jù)所有權。答案：×解析：云服務提供商不擁有數(shù)據(jù)，合同需明確歸屬與合規(guī)。39.靜態(tài)代碼分析可以在不運行程序的情況下發(fā)現(xiàn)潛在缺陷。答案：√解析：靜態(tài)分析通過詞法語義檢查識別漏洞、壞味道。40.軟件工程經(jīng)濟學只關注開發(fā)成本，不包含運維成本。答案：×解析：現(xiàn)代軟件經(jīng)濟學涵蓋全生命周期成本（TCO）。三、填空題（每空2分，共20分）41.在RUP中，生命周期被劃分為先啟、精化、________、移交四個階段。答案：構建42.若某循環(huán)復雜度V(G)=8，則至少需要________個測試用例覆蓋所有路徑。答案：843.在需求優(yōu)先級技術MoSCoW中，M代表________。答案：Musthave44.軟件可維護性的五個子特性：易分析性、易改變性、穩(wěn)定性、易測試性、________。答案：依從性45.在GitFlow模型中，用于準備發(fā)布生產的分支名稱是________。答案：release46.若系統(tǒng)年停機時間為8.76小時，其可用性約為________%。答案：99.9解析：(8760-8.76)/8760≈0.99947.在面向對象設計中，開閉原則指對擴展________，對修改關閉。答案：開放48.在軟件項目估算中，________分析通過對比歷史項目特征進行預測。答案：類比49.在UML序列圖中，對象生命線上的窄條稱為________，表示對象激活期。答案：執(zhí)行規(guī)約（activationbar）50.在DevOps工具鏈中，________負責編排持續(xù)交付流水線各階段。答案：Pipeline引擎（或CI/CD服務器）四、簡答題（每題10分，共30分）51.簡述軟件需求評審的常見檢查單內容，并說明如何確保評審有效性。答案：評審檢查單包括：1.完整性：是否覆蓋所有業(yè)務場景與約束；2.一致性：術語、單位、流程是否統(tǒng)一；3.可驗證性：每條需求是否可測試或驗證；4.可行性：技術、成本、法規(guī)是否允許；5.無歧義：表述是否清晰，避免多重解釋；6.優(yōu)先級：是否標明商業(yè)價值與實現(xiàn)順序；7.可追溯：是否建立與源頭、設計、測試的雙向跟蹤。確保有效性措施：1.提前2日分發(fā)材料，評審員預習；2.采用Faganinspection角色：作者、評審員、講解員、記錄員；3.限制會議時長≤2小時，聚焦缺陷而非解決方案；4.使用度量：缺陷密度、評審速率（頁/小時），持續(xù)改進；5.對發(fā)現(xiàn)的問題建立跟蹤表，指定責任人限期閉環(huán)；6.引入多樣性視角：開發(fā)、測試、運維、用戶代表均參與；7.對高風險需求采用原型或形式化驗證輔助評審。52.對比微服務與單體架構在開發(fā)、部署、擴展、數(shù)據(jù)一致性四個維度的差異。答案：開發(fā)：微服務按業(yè)務邊界拆分，團隊可獨立迭代，技術棧異構；單體代碼集中，編譯依賴大，技術棧統(tǒng)一，跨團隊協(xié)作沖突多。部署：微服務每個服務獨立打包，容器化后通過編排系統(tǒng)滾動發(fā)布，回滾粒度??；單體整體打包，發(fā)布窗口集中，回滾需全量替換，風險高。擴展：微服務按需橫向擴展單個熱點服務，資源利用率高；單體只能整體擴展，冗余資源浪費，擴展粒度粗。數(shù)據(jù)一致性：微服務倡導數(shù)據(jù)庫私有化，跨服務事務需采用Saga、TCC、最終一致性，編程復雜；單體共享數(shù)據(jù)庫，本地ACID事務簡單，但長期演進易形成“大泥球”。53.說明事件風暴（EventStorming）的步驟，并給出在電商下單場景中的三個領域事件示例。答案：步驟：1.準備：邀請領域專家、開發(fā)、測試、產品，準備長卷、便利貼、馬克筆；2.探索業(yè)務流程：從用戶視角按時間線寫出橙色領域事件，使用過去時態(tài)，如“訂單已創(chuàng)建”；3.識別熱點：用紅色標簽標出沖突、瓶頸、模糊點；4.補充命令與聚合：用藍色便利貼表示觸發(fā)事件的命令，黃色聚合根接收命令；5.劃分限界上下文：用虛線框分組，統(tǒng)一語言；6.產出模型：整理事件流、命令、聚合、上下文，形成領域模型初稿。電商下單場景示例：1.訂單已創(chuàng)建?2.庫存已預扣?3.支付已成功五、綜合應用題（共60分）54.某市政府計劃建設“智慧停車”平臺，整合路側車位、停車場、充電樁資源，提供車位實時查詢、無感支付、預約、導航、信用管理等功能。項目預算3000萬元，工期18個月，涉及城管、交警、平臺運營商、停車場業(yè)主、車主五類干系人。請完成：（1）繪制系統(tǒng)上下文圖，標明外部實體與數(shù)據(jù)流（10分）；（2）使用用例圖描述車主核心需求，至少包含6個用例，2個<<include>>、1個<<extend>>關系（15分）；（3）識別3項主要風險，給出概率、影響、應對策略（15分）；（4）設計高可用微服務架構，要求：多活部署、故障自愈、彈性擴展，畫出邏輯視圖并說明關鍵技術選型（20分）。答案：（1）系統(tǒng)上下文圖外部實體：車主、停車場業(yè)主、城管、交警、支付機構、地圖服務商、信用平臺數(shù)據(jù)流：車主→系統(tǒng)：查詢請求、預約請求、支付指令系統(tǒng)→車主：車位信息、導航路徑、訂單狀態(tài)停車場業(yè)主→系統(tǒng)：車位狀態(tài)、費率策略系統(tǒng)→停車場業(yè)主：收入結算、運營報表城管→系統(tǒng)：執(zhí)法工單、黑名單系統(tǒng)→城管：違停證據(jù)、統(tǒng)計報表交警→系統(tǒng)：交通管制信息系統(tǒng)→交警：流量分析支付機構?系統(tǒng)：支付令牌、扣款結果地圖服務商?系統(tǒng)：地理編碼、路徑規(guī)劃信用平臺?系統(tǒng)：信用分查詢、違約記錄（2）用例圖參與者：車主用例：1.查詢車位2.預約車位（include查詢車位）3.導航至車位（include獲取地圖）4.無感支付（include預綁車牌）5.評價訂單6.申訴違停<<extend>>:預約車位——<<extend>>→取消預約<<include>>:無感支付——<<include>>→扣款<<include>>:預約車位——<<include>>→鎖定車位（3）風險列表1.政策變動風險概率：中（30%）影響：高（需求范圍大幅調整）應對：設置政策緩沖池，合同中加入“不可抗力”條款，采用微服務按領域拆分，降低單點變更范圍；每季度與政府部門召開對齊會。2.高并發(fā)支付峰值風險概率：高（節(jié)假日峰值可達平日10倍）影響：高（支付失敗導致用戶投訴）應對：采用分布式消息隊列（RocketMQ）削峰，支付服務基于KubernetesHPA彈性擴容，設置降級策略：高峰切換至二維碼離線支付；預演全鏈路壓測，峰值目標TPS2萬。3.數(shù)據(jù)隱私泄露風險概率：低（5%）影響：極高（法律訴訟、政府問責）應對：敏感字段國密算法加密，API網(wǎng)關統(tǒng)一接入，零信任架構，每年滲透測試+等保測評；制定應急響應預案，泄露2小時內上報，72小時內完成用戶通知與風險消除。（4）高可用微服務架構邏輯視圖：接入層：API網(wǎng)關集群（Kong+Keepalived）雙活，支持限流、鑒權、灰度服務層：-車位服務（Node.js+MongoDB）-預約服務（JavaSpringBoot+Redis分布式鎖）-支付服務（Go+