2025年(軟件工程)敏捷軟件開發(fā)試題及答案一、單項選擇題（每題2分，共20分）1.在Scrum框架中，負責確保團隊理解并遵循Scrum指南的角色是A.產(chǎn)品負責人??B.ScrumMaster??C.開發(fā)團隊??D.項目經(jīng)理答案：B解析：ScrumMaster是流程的守護者，負責幫助團隊正確理解并實踐Scrum。2.以下哪項最能體現(xiàn)“個體與交互高于流程與工具”的敏捷價值觀？A.每日站會嚴格按15分鐘計時??B.使用Jira自動生成燃盡圖C.團隊成員面對面討論需求細節(jié)??D.通過郵件確認所有需求變更答案：C解析：面對面交流是敏捷強調的高效溝通方式，直接體現(xiàn)“個體與交互”。3.極限編程（XP）中，持續(xù)集成的首要目標是A.降低代碼行數(shù)??B.減少缺陷返工??C.提高部署頻率??D.增加單元測試覆蓋率答案：B解析：持續(xù)集成通過頻繁驗證，盡早暴露缺陷，從而減少返工成本。4.用戶故事“作為一名司機，我希望在支付停車費時可以使用手機，以避免找零麻煩”中，屬于“價值”部分的是A.司機??B.支付停車費??C.使用手機??D.避免找零麻煩答案：D解析：價值強調用戶獲得的利益，“避免找零麻煩”直接體現(xiàn)利益。5.在精益開發(fā)中，下列哪項屬于“浪費”？A.對需求進行細化??B.為可能變化的接口提前編寫完整文檔C.重構重復代碼??D.與真實用戶進行演示答案：B解析：提前編寫可能用不到的文檔屬于“額外功能”浪費。6.敏捷估算技術PlanningPoker主要解決A.需求優(yōu)先級沖突??B.專家權威壓制??C.代碼合并沖突??D.性能瓶頸答案：B解析：通過匿名出牌避免權威影響，促進團隊共識。7.在DevOps實踐中，CanaryRelease的核心優(yōu)勢是A.零配置部署??B.快速全量發(fā)布??C.小流量驗證降低風險??D.完全回滾到物理機答案：C解析：金絲雀發(fā)布用小比例真實流量驗證新版本，降低故障半徑。8.以下哪項不屬于敏捷合同特征？A.固定總價??B.早期終止條款??C.激勵共享??D.可變范圍答案：A解析：敏捷合同鼓勵范圍可變與風險共擔，固定總價與之沖突。9.在FeatureToggle技術中，ReleaseToggle的主要生命周期是A.長期存在??B.隨版本退役??C.僅用于A/B實驗??D.僅用于性能調優(yōu)答案：B解析：ReleaseToggle在新功能穩(wěn)定后應移除，避免技術債。10.根據(jù)2021年StateofAgile報告，導致敏捷轉型失敗的首要原因是A.工具太復雜??B.文化沖突??C.預算不足??D.代碼規(guī)范缺失答案：B解析：文化不匹配導致流程難以落地，是失敗主因。二、多項選擇題（每題3分，共15分）11.以下哪些實踐有助于實現(xiàn)“可持續(xù)開發(fā)”？A.每周固定加班8小時??B.限制在制品數(shù)量??C.回顧會議識別速率下降??D.自動化回歸測試答案：B、C、D解析：可持續(xù)強調節(jié)奏穩(wěn)定，限制在制品、識別速率下降、自動化測試均可減少透支。12.關于MoSCoW排序，下列說法正確的是A.M代表Musthave??B.S代表Shouldhave??C.W代表Willnothavethistime??D.C代表Couldhave答案：A、B、C、D解析：MoSCoW四項含義依次為Must、Should、Could、Willnothave。13.以下哪些指標屬于“流動效率”范疇？A.需求前置時間??B.流程效率=增值時間/前置時間??C.故事點完成速率??D.在制品數(shù)量答案：A、B、D解析：流動效率關注端到端流速與浪費，故事點速率是產(chǎn)能指標。14.在BehaviorDrivenDevelopment（BDD）場景中，有效的Given-When-Then語句應具備A.業(yè)務語言??B.可測試性??C.技術實現(xiàn)細節(jié)??D.獨立上下文答案：A、B、D解析：BDD強調業(yè)務可讀與可測試，避免暴露實現(xiàn)細節(jié)。15.以下哪些做法有助于構建“心理安全”的敏捷團隊？A.領導公開承認錯誤??B.回顧會只表揚不批評??C.使用匿名投票暴露風險??D.鼓勵提問“愚蠢問題”答案：A、C、D解析：心理安全需要真實反饋與容錯氛圍，只表揚不批評會掩蓋問題。三、判斷題（每題1分，共10分）16.敏捷團隊拒絕一切文檔。答案：錯解析：敏捷支持“剛好足夠”的文檔，而非拒絕。17.在Scrum中，Sprint評審會議只能演示已完成的故事。答案：錯解析：可展示未完成進展以獲取反饋，但“完成”故事需符合DoD。18.代碼集體所有權意味著任何人在任何時候可修改任意代碼。答案：對解析：XP鼓勵集體所有權，要求團隊具備同等能力并輔以測試保障。19.敏捷估算單位必須使用故事點，不能使用理想人天。答案：錯解析：故事點是推薦，但團隊可自選單位，只要保持一致。20.看板方法強制迭代時間盒。答案：錯解析：看板無固定迭代，以流動為核心，可選迭代節(jié)奏。21.持續(xù)交付等于持續(xù)部署。答案：錯解析：持續(xù)交付強調隨時可發(fā)布，但發(fā)布決策可人工；持續(xù)部署則自動到生產(chǎn)。22.敏捷教練與ScrumMaster職責完全相同。答案：錯解析：ScrumMaster是Scrum框架角色；敏捷教練更廣，可跨框架。23.在LeSS框架中，只有一個產(chǎn)品負責人和一個產(chǎn)品待辦列表。答案：對解析：LeSS強調單一產(chǎn)品視角，避免多列表碎片。24.重構可以在不添加測試的情況下進行。答案：錯解析：無測試重構風險極高，違背XP“測試驅動”精神。25.敏捷團隊速率越高越好，無需考慮缺陷率。答案：錯解析：高速伴隨高缺陷是虛假速率，需平衡質量。四、簡答題（每題8分，共24分）26.說明“定義完成（DoD）”與“驗收標準（AC）”的區(qū)別與聯(lián)系，并給出某移動支付應用“掃碼付款”用戶故事的示例。答案：定義完成是團隊對所有增量統(tǒng)一約定的通用質量門檻，如“單元測試通過、代碼評審合并、接口測試≥90%、無P1缺陷、性能基準≤200ms”。驗收標準則是針對單個用戶故事的業(yè)務驗證條件，由產(chǎn)品負責人與團隊共同擬定，用于確認故事是否滿足用戶價值。掃碼付款示例：DoD：1)代碼覆蓋≥85%；2)通過SonarQubeA級門禁；3)灰度流量測試24h無異常；4)安全團隊代碼掃描無高危漏洞；5)更新用戶文檔。AC：a.給定用戶打開付款碼，當商戶掃描時，系統(tǒng)應在2秒內(nèi)返回支付結果；b.若網(wǎng)絡超時，應提示“網(wǎng)絡異常，請重試”并允許再次支付；c.支付成功后，用戶余額即時扣減并推送通知；d.支持微信、支付寶兩種渠道；e.失敗交易不收取手續(xù)費。聯(lián)系：AC是DoD的子集驗證，DoD保證整體質量，AC保證具體價值。兩者共同確保增量可發(fā)布。27.描述“探索性測試”在敏捷迭代中的實施步驟，并說明如何與自動化測試互補。答案：步驟：1)章程制定：測試人員與產(chǎn)品負責人快速對齊風險區(qū)域，如“新聚合支付接口可能存在邊界溢出”。2)時間盒：設定90分鐘會話，避免發(fā)散。3)會話執(zhí)行：使用“測一測、記一記、說一說”模型，實時記錄屏幕、日志與筆記。4)缺陷評估：發(fā)現(xiàn)疑似缺陷立即與開發(fā)結對復現(xiàn)，判斷嚴重性。5)報告與分享：使用SBTM（Session-BasedTestManagement）生成輕量報告，包含覆蓋區(qū)域、問題清單、新測試想法。互補：自動化測試負責回歸與快速反饋，確保已有行為不被破壞；探索性測試聚焦新功能與邊緣缺陷，提供人工洞察。發(fā)現(xiàn)的高價值場景可轉化為自動化腳本，納入持續(xù)集成；自動化失敗結果可為探索性測試提供線索。兩者形成“自動化防護網(wǎng)+人工顯微鏡”的雙循環(huán)。28.某SaaS公司采用兩周Sprint，但每輪結束仍出現(xiàn)大量緊急缺陷，導致下一Sprint計劃不斷被壓縮。請從“質量內(nèi)建”角度提出三條具體改進措施，并說明如何度量成效。答案：措施：1)測試左移：需求澄清階段引入“實例化需求”工作坊，產(chǎn)品、開發(fā)、測試共同編寫B(tài)DD場景，并在Jira中關聯(lián)自動化腳本，確保需求無歧義。2)代碼評審+結對編程：關鍵支付模塊強制雙人實時提交，使用Gerrit強制評審，引入靜態(tài)分析工具CodeScene，復雜度>15的方法禁止合并。3)生產(chǎn)可觀測性前置：在功能開發(fā)階段注入結構化日志、分布式追蹤標識，并在預發(fā)布環(huán)境模擬真實流量，使用混沌工程工具Gremlin注入網(wǎng)絡延遲，提前暴露缺陷。度量：a.缺陷逃逸率=生產(chǎn)缺陷數(shù)/總缺陷數(shù)，目標<5%；b.Sprint計劃變動率=計劃故事點變動/初始故事點，目標<10%；c.平均修復時間MTTR從48h降至12h；d.單元測試覆蓋率由60%提升至85%，復雜度>15的方法數(shù)下降30%。連續(xù)三輪達成即視為改進有效。五、案例分析題（共31分）背景：2025年3月，某城商行啟動“數(shù)字人民幣商戶錢包”項目，采用SAFe6.0框架，共5個敏捷發(fā)布火車（ART），涉及移動、核心、風控、運營、數(shù)據(jù)五個領域。項目預算1.2億元，監(jiān)管要求9月前上線，逾期將暫停業(yè)務資質。4月底，管理層發(fā)現(xiàn)：1)集成測試環(huán)境部署頻率僅每周一次，缺陷平均修復周期3.8天；2)風控ART與核心ART接口協(xié)議每周變更，導致返工；3)移動端采用Flutter，但UI自動化用例不足，回歸需3人日；4)數(shù)據(jù)ART使用傳統(tǒng)Oracle，無法快速提供測試數(shù)據(jù)，每次需DBA手工導入；5)團隊士氣低落，Retro提出的阻塞問題連續(xù)三輪未下降。29.（10分）請使用“價值流圖”方法，繪制從“需求提出”到“生產(chǎn)發(fā)布”的主要步驟，標注平均處理時間與等待時間，并指出最大浪費節(jié)點。答案：步驟與耗時（小時）：需求提出(0)→需求評審(4)→等待ARTPI規(guī)劃(72)→開發(fā)(240)→等待集成環(huán)境(48)→集成測試(48)→等待缺陷修復(91.2)→回歸(24)→等待UAT環(huán)境(96)→UAT(48)→等待監(jiān)管驗收(168)→生產(chǎn)部署(8)。等待時間：72+48+91.2+96+168=475.2h；增值時間：4+240+48+24+48+8=372h；流程效率=372/(372+475.2)=43.9%。最大浪費節(jié)點：等待監(jiān)管驗收（168h），因無早期介入與自動化合規(guī)報告，導致一次性審查。30.（10分）針對“接口協(xié)議每周變更”問題，請設計一個基于“消費者驅動契約測試（CDC）”的方案，包含角色職責、契約文件格式、流水線階段與失敗處理策略。答案：角色：提供者（核心ART）負責生成契約并維護兼容性；消費者（風控ART）提出期望；測試教練負責工具選型。契約格式：使用PactJSON，示例{“consumer”:{“name”:“risk-art”},“provider”:{“name”:“core-art”},“interactions”:[{“description”:“querymerchantbalance”,“request”:{“method”:“GET”,“path”:“/merchant/{id}/balance”,“headers”:{“Accept”:“application/json”}},“response”:{“status”:200,“headers”:{“Content-Type”:“application/json”},“body”:{“balance”:100}}}]}流水線：1)消費者提交代碼時觸發(fā)Pact測試，生成契約；2)契約上傳至PactBroker；3)提供者側流水線拉取契約，運行ProviderTest驗證；4)若失敗，提供者立即收到Slack告警并禁止合并；5)每周自動生成兼容性報告供架構評審。失敗策略：若提供者破壞兼容，需在24小時內(nèi)回滾或發(fā)布修補版本；消費者若提出破壞性變更，需與提供者協(xié)商版本策略，采用語義化版本控制，重大變更走API版本號升級。31.（11分）請給出“數(shù)據(jù)ART快速提供測試數(shù)據(jù)”的完整技術方案，要求包含數(shù)據(jù)即服務（DaaS）架構、數(shù)據(jù)脫敏、同步策略與成本評估，并說明如何與DevOps流水線集成。答案：架構：1)源庫：Oracle19c；2)捕獲：使用OracleGoldenGate實時抓取RedoLog，寫入Kafka；3)脫敏：KafkaStreams調用FPE（格式保持加密）算法，對手機號、身份證號、卡號進行脫敏，保持長度與字符集；4)存儲：脫敏后數(shù)據(jù)寫入可插拔的PostgreSQL集群（Kubernetes部署），并按商戶號分片；5)服務：GraphQLAPI封裝，支持按需查詢、快照、回滾。同步策略：全量快照每日凌晨2點，增量流實時延遲<30秒；提供“時間機器”接口，允許測試腳本回滾到任意保存點。脫敏合規(guī)：采用國密SM4FPE，密鑰托管于HashiCorpVault，審計日志發(fā)送至SIEM。成本評估：GoldenGate許可證50萬/年；Kafka與PostgreSQL使用開源版本；硬件利用現(xiàn)有K8s集群，