【試題】軟件工程試題及答案一、單項(xiàng)選擇題（每題2分，共20分）1.以下關(guān)于軟件生命周期模型的描述中，正確的是（）A.瀑布模型適用于需求頻繁變更的項(xiàng)目B.螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析，適合大型復(fù)雜系統(tǒng)C.敏捷開發(fā)（如Scrum）要求嚴(yán)格的文檔驅(qū)動開發(fā)D.原型模型僅適用于界面設(shè)計(jì)，無法驗(yàn)證核心業(yè)務(wù)邏輯2.需求規(guī)格說明書（SRS）的關(guān)鍵特性不包括（）A.完整性B.可驗(yàn)證性C.模糊性D.一致性3.以下UML圖中，用于描述系統(tǒng)動態(tài)行為的是（）A.類圖B.用例圖C.序列圖D.包圖4.軟件設(shè)計(jì)中，“高內(nèi)聚、低耦合”原則的主要目的是（）A.提高代碼執(zhí)行效率B.降低維護(hù)成本C.減少編譯時(shí)間D.簡化版本控制5.單元測試的主要對象是（）A.模塊接口B.系統(tǒng)整體功能C.用戶界面D.數(shù)據(jù)庫性能6.以下不屬于軟件危機(jī)表現(xiàn)的是（）A.軟件成本超出預(yù)算B.軟件交付時(shí)間延遲C.軟件功能符合需求D.軟件質(zhì)量低下7.敏捷開發(fā)中的“用戶故事”（UserStory）主要用于（）A.詳細(xì)描述技術(shù)實(shí)現(xiàn)細(xì)節(jié)B.記錄測試用例C.從用戶視角表達(dá)需求D.定義項(xiàng)目進(jìn)度計(jì)劃8.白盒測試的常用方法是（）A.等價(jià)類劃分B.邊界值分析C.路徑覆蓋D.錯(cuò)誤推測9.軟件配置管理（SCM）的核心活動不包括（）A.版本控制B.變更控制C.性能優(yōu)化D.配置審計(jì)10.以下關(guān)于軟件維護(hù)的描述，錯(cuò)誤的是（）A.完善性維護(hù)是為了增加新功能B.糾錯(cuò)性維護(hù)是修復(fù)運(yùn)行中發(fā)現(xiàn)的錯(cuò)誤C.適應(yīng)性維護(hù)是為了適應(yīng)環(huán)境變化D.預(yù)防性維護(hù)的成本通常低于其他維護(hù)類型二、填空題（每題2分，共20分）1.軟件生命周期的典型階段包括需求分析、______、編碼、測試、維護(hù)等。2.需求分析的主要任務(wù)是確定系統(tǒng)的______和______。3.UML中，用例圖的三個(gè)基本元素是______、______和______。4.軟件設(shè)計(jì)分為______設(shè)計(jì)（總體設(shè)計(jì)）和______設(shè)計(jì)（詳細(xì)設(shè)計(jì)）兩個(gè)階段。5.黑盒測試不考慮程序內(nèi)部結(jié)構(gòu)，僅根據(jù)______設(shè)計(jì)測試用例。6.敏捷開發(fā)的核心價(jià)值觀包括個(gè)體與交互重于流程與工具、可工作的軟件重于______、客戶合作重于合同談判、響應(yīng)變化重于遵循計(jì)劃。7.軟件質(zhì)量模型（如ISO/IEC25010）中，功能性、可靠性、易用性、效率、______和可維護(hù)性是六大特性。8.軟件項(xiàng)目管理的核心三要素是______、______和質(zhì)量。9.軟件缺陷的生命周期通常包括提交、______、修復(fù)、驗(yàn)證、關(guān)閉等階段。10.設(shè)計(jì)模式中，______模式用于解決接口不兼容問題（如適配器模式），______模式用于控制對象的創(chuàng)建過程（如工廠模式）。三、簡答題（每題8分，共40分）1.簡述瀑布模型與敏捷開發(fā)的主要區(qū)別，并說明各自的適用場景。2.需求分析階段需要完成哪些具體工作？請列舉至少5項(xiàng)關(guān)鍵活動。3.軟件設(shè)計(jì)中“模塊化”的優(yōu)勢有哪些？如何衡量模塊的獨(dú)立性？4.測試用例設(shè)計(jì)需要遵循哪些原則？請結(jié)合等價(jià)類劃分法和邊界值分析法舉例說明。5.軟件項(xiàng)目中，需求變更可能帶來哪些風(fēng)險(xiǎn)？如何通過需求管理流程降低這些風(fēng)險(xiǎn)？四、案例分析題（20分）某公司計(jì)劃開發(fā)一款在線教育平臺，主要功能包括用戶注冊/登錄、課程瀏覽與購買、直播教學(xué)、作業(yè)提交與批改、學(xué)習(xí)數(shù)據(jù)統(tǒng)計(jì)。假設(shè)你是該項(xiàng)目的軟件工程師，請結(jié)合軟件工程知識回答以下問題：（1）在需求分析階段，需要與哪些利益相關(guān)者溝通？應(yīng)收集哪些核心需求？（2）系統(tǒng)設(shè)計(jì)時(shí)，推薦采用哪種架構(gòu)模式（如分層架構(gòu)、MVC、微服務(wù)）？說明理由。（3）針對“直播教學(xué)”功能，應(yīng)設(shè)計(jì)哪些測試用例（至少5個(gè)）？需覆蓋哪些測試類型？（4）項(xiàng)目開發(fā)過程中，若用戶突然提出“增加課程回放功能”，應(yīng)如何處理這一變更？參考答案一、單項(xiàng)選擇題1.B（螺旋模型通過迭代和風(fēng)險(xiǎn)分析，適合高風(fēng)險(xiǎn)的大型系統(tǒng)；瀑布模型需求變更成本高，敏捷是以人為中心、輕文檔，原型模型可驗(yàn)證核心邏輯）2.C（需求規(guī)格說明書需清晰明確，模糊性是缺陷）3.C（序列圖描述對象間的消息傳遞，屬于動態(tài)圖；類圖、用例圖、包圖是靜態(tài)圖）4.B（高內(nèi)聚降低模塊內(nèi)部復(fù)雜度，低耦合減少模塊間依賴，便于維護(hù)）5.A（單元測試關(guān)注模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件等，系統(tǒng)功能是集成/系統(tǒng)測試的對象）6.C（軟件危機(jī)表現(xiàn)為成本超支、進(jìn)度延遲、質(zhì)量差、需求不滿足等，“符合需求”是成功表現(xiàn)）7.C（用戶故事以用戶視角描述需求，如“作為學(xué)生，我需要查看課程目錄，以便選擇課程”）8.C（白盒測試基于代碼結(jié)構(gòu)，路徑覆蓋是典型方法；其他選項(xiàng)是黑盒測試方法）9.C（配置管理包括版本控制、變更控制、配置審計(jì)，性能優(yōu)化屬于開發(fā)或維護(hù)階段）10.D（預(yù)防性維護(hù)是為未來修改做準(zhǔn)備，通常成本高于其他維護(hù)類型）二、填空題1.設(shè)計(jì)（或“軟件設(shè)計(jì)”）2.功能需求；非功能需求（或“性能需求”“約束條件”）3.參與者（Actor）；用例（UseCase）；關(guān)聯(lián)關(guān)系4.架構(gòu)（或“總體”）；詳細(xì)（或“模塊”）5.需求規(guī)格說明書（或“外部行為”）6.詳盡的文檔7.可移植性（或“維護(hù)性”需注意題干已提到“可維護(hù)性”，正確應(yīng)為“可移植性”）8.范圍（或“需求”）；時(shí)間（或“進(jìn)度”）；成本（注：三要素通常指范圍、時(shí)間、成本）9.確認(rèn)（或“分配”“評審”）10.適配器；工廠（或“創(chuàng)建型”）三、簡答題1.區(qū)別與場景：瀑布模型是線性順序模型，強(qiáng)調(diào)階段間嚴(yán)格的順序和文檔驅(qū)動，每個(gè)階段完成后才能進(jìn)入下一階段；敏捷開發(fā)是迭代增量模型，強(qiáng)調(diào)快速交付可用軟件、客戶參與和適應(yīng)變更。適用場景：瀑布模型適合需求明確、技術(shù)成熟、變更少的項(xiàng)目（如傳統(tǒng)嵌入式系統(tǒng)）；敏捷適合需求模糊、需要快速響應(yīng)市場的項(xiàng)目（如互聯(lián)網(wǎng)產(chǎn)品）。2.需求分析關(guān)鍵活動：①與用戶、客戶、開發(fā)團(tuán)隊(duì)等利益相關(guān)者訪談，收集原始需求；②繪制用例圖，明確系統(tǒng)邊界和功能；③編寫需求規(guī)格說明書（SRS），定義功能需求（如“用戶可購買課程”）和非功能需求（如“系統(tǒng)響應(yīng)時(shí)間≤2秒”）；④進(jìn)行需求驗(yàn)證（評審），確保需求完整、一致、可測試；⑤建立需求跟蹤矩陣，關(guān)聯(lián)需求與后續(xù)設(shè)計(jì)、測試環(huán)節(jié)。3.模塊化優(yōu)勢與獨(dú)立性衡量：優(yōu)勢：降低系統(tǒng)復(fù)雜度（分而治之）、提高可維護(hù)性（局部修改不影響其他模塊）、支持并行開發(fā)（模塊可分配給不同團(tuán)隊(duì)）。衡量模塊獨(dú)立性的指標(biāo)是耦合和內(nèi)聚：耦合是模塊間依賴程度（如數(shù)據(jù)耦合<控制耦合<公共耦合），內(nèi)聚是模塊內(nèi)部元素的關(guān)聯(lián)程度（如功能內(nèi)聚>順序內(nèi)聚>偶然內(nèi)聚）。理想情況是低耦合、高內(nèi)聚。4.測試用例設(shè)計(jì)原則與舉例：原則：覆蓋所有需求（功能/非功能）、包含輸入與預(yù)期輸出、具備可重復(fù)性、兼顧正常與異常場景。等價(jià)類劃分法：將輸入域劃分為有效等價(jià)類（如“年齡18-60歲”）和無效等價(jià)類（如“年齡<18”“年齡>60”），各選一個(gè)代表值設(shè)計(jì)用例（如輸入“25”應(yīng)成功，輸入“15”應(yīng)提示“年齡不符合”）。邊界值分析法：關(guān)注等價(jià)類的邊界（如“年齡=18”“年齡=60”），測試用例為“17”“18”“59”“60”“61”，驗(yàn)證邊界條件是否處理正確。5.需求變更的風(fēng)險(xiǎn)與應(yīng)對：風(fēng)險(xiǎn)：導(dǎo)致進(jìn)度延遲（需重新設(shè)計(jì)、測試）、成本增加（額外開發(fā)工作量）、質(zhì)量下降（變更可能引入新缺陷）、團(tuán)隊(duì)士氣受挫（頻繁變更影響信心）。應(yīng)對流程：①建立變更控制委員會（CCB），評估變更的必要性和影響（如工作量、成本、進(jìn)度）；②記錄變更請求（CR），明確變更內(nèi)容、提出方、優(yōu)先級；③若批準(zhǔn)變更，更新需求文檔、設(shè)計(jì)文檔和測試用例；④通知所有相關(guān)人員（開發(fā)、測試、產(chǎn)品經(jīng)理），確保同步；⑤跟蹤變更實(shí)施效果，驗(yàn)證是否滿足需求。四、案例分析題（1）利益相關(guān)者與核心需求：利益相關(guān)者：學(xué)生（最終用戶）、教師（課程提供者）、運(yùn)營人員（平臺管理者）、技術(shù)團(tuán)隊(duì)（開發(fā)/測試）、財(cái)務(wù)部門（支付接口對接）。核心需求：-功能需求：用戶認(rèn)證（注冊/登錄）、課程管理（瀏覽/購買）、實(shí)時(shí)互動（直播連麥）、作業(yè)管理（提交/批改）、數(shù)據(jù)統(tǒng)計(jì)（學(xué)習(xí)進(jìn)度、成績）。-非功能需求：高并發(fā)支持（直播時(shí)可能數(shù)千人同時(shí)在線）、低延遲（直播延遲≤1秒）、數(shù)據(jù)安全（用戶信息加密）、可擴(kuò)展性（未來支持新課程類型）。（2）推薦架構(gòu)模式：推薦分層架構(gòu)（如表現(xiàn)層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層）或微服務(wù)架構(gòu)。理由：在線教育平臺功能模塊相對獨(dú)立（用戶、課程、直播、作業(yè)），微服務(wù)可將各模塊拆分為獨(dú)立服務(wù)（如用戶服務(wù)、直播服務(wù)），支持獨(dú)立開發(fā)、部署和擴(kuò)展，適合高并發(fā)場景；若團(tuán)隊(duì)規(guī)模較小，分層架構(gòu)更易管理，通過層間解耦降低復(fù)雜度。（3）直播教學(xué)測試用例與類型：測試用例：①正常場景：學(xué)生在WiFi環(huán)境下進(jìn)入直播房間，畫面清晰、聲音同步（功能測試、性能測試）。②弱網(wǎng)場景：4G信號弱（延遲200ms）時(shí)，直播自動切換為標(biāo)清，無卡頓（容錯(cuò)測試、性能測試）。③多角色互動：教師發(fā)起連麥，學(xué)生A申請后成功接入，其他學(xué)生可看到連麥畫面（功能測試、兼容性測試）。④異常退出：學(xué)生直播中途退出，重新進(jìn)入后恢復(fù)至當(dāng)前進(jìn)度（可靠性測試）。⑤并發(fā)壓力：同時(shí)1000名學(xué)生進(jìn)入同一直播間，系統(tǒng)無崩潰、延遲≤2秒（壓力測試、負(fù)載測試）。（4）需求變更處理：①提交變更請求：用戶或產(chǎn)品經(jīng)理填寫CR，說明“增加課程回放功能”的背景（如學(xué)生需要復(fù)習(xí)）、具體要求（回放支持