2026年軟件研發(fā)項(xiàng)目經(jīng)理助理及技術(shù)管理專(zhuān)員考試題目參考一、單選題（共10題，每題2分，合計(jì)20分）1.在敏捷開(kāi)發(fā)中，Scrum框架中負(fù)責(zé)確保團(tuán)隊(duì)遵循敏捷實(shí)踐的角色是？A.ProductOwnerB.ScrumMasterC.DevelopmentTeamD.Stakeholder2.以下哪項(xiàng)不屬于軟件測(cè)試的“五大原則”？A.完整性原則B.隨機(jī)性原則C.可重復(fù)性原則D.優(yōu)先級(jí)原則3.在項(xiàng)目管理中，用于衡量項(xiàng)目進(jìn)度與計(jì)劃偏差的指標(biāo)是？A.CV（CostVariance）B.SPI（SchedulePerformanceIndex）C.ETC（EstimatetoComplete）D.BAC（BudgetatCompletion）4.以下哪種測(cè)試方法最適合驗(yàn)證代碼的覆蓋率和邏輯正確性？A.黑盒測(cè)試B.白盒測(cè)試C.灰盒測(cè)試D.動(dòng)態(tài)測(cè)試5.在技術(shù)管理中，用于評(píng)估技術(shù)方案可行性的工具是？A.SWOT分析B.PERT圖C.RACI矩陣D.FMEA分析6.ISO/IEC25000標(biāo)準(zhǔn)中，描述軟件質(zhì)量“功能性”的維度是？A.性能效率B.可靠性C.易用性D.安全性7.在需求管理中，用于跟蹤需求變更的文檔是？A.需求規(guī)格說(shuō)明書(shū)B(niǎo).需求變更日志C.用例圖D.狀態(tài)機(jī)圖8.以下哪項(xiàng)不是DevOps文化的核心原則？A.持續(xù)集成B.跨部門(mén)協(xié)作C.手動(dòng)測(cè)試D.自動(dòng)化部署9.在項(xiàng)目管理中，用于識(shí)別潛在風(fēng)險(xiǎn)并評(píng)估其影響的工具是？A.魚(yú)骨圖B.PERT圖C.敏感性分析D.決策樹(shù)分析10.在技術(shù)管理中，用于評(píng)估技術(shù)債務(wù)的指標(biāo)是？A.程序復(fù)雜度B.代碼行數(shù)C.缺陷密度D.技術(shù)成熟度二、多選題（共5題，每題3分，合計(jì)15分）1.以下哪些屬于敏捷開(kāi)發(fā)的核心價(jià)值觀(guān)？A.效率優(yōu)先B.客戶(hù)合作C.持續(xù)改進(jìn)D.按部就班E.自我組織2.軟件測(cè)試的常見(jiàn)類(lèi)型包括哪些？A.單元測(cè)試B.集成測(cè)試C.系統(tǒng)測(cè)試D.性能測(cè)試E.需求評(píng)審3.項(xiàng)目管理中的“三重約束”是指？A.成本B.時(shí)間C.范圍D.質(zhì)量E.風(fēng)險(xiǎn)4.技術(shù)管理中，團(tuán)隊(duì)知識(shí)管理的常見(jiàn)方法包括？A.文檔化B.代碼審查C.技術(shù)分享會(huì)D.自動(dòng)化測(cè)試E.外包開(kāi)發(fā)5.在軟件質(zhì)量保證中，以下哪些活動(dòng)屬于過(guò)程改進(jìn)？A.缺陷跟蹤B.審計(jì)C.流程優(yōu)化D.培訓(xùn)E.需求變更三、判斷題（共10題，每題1分，合計(jì)10分）1.Scrum框架中，Sprint計(jì)劃會(huì)議的參與者僅包括開(kāi)發(fā)團(tuán)隊(duì)。（×）2.黑盒測(cè)試不需要了解代碼內(nèi)部邏輯。（√）3.項(xiàng)目范圍蔓延會(huì)導(dǎo)致項(xiàng)目延期和成本超支。（√）4.技術(shù)債務(wù)是指代碼難以維護(hù)，需要重構(gòu)。（√）5.ISO9001是質(zhì)量管理體系的國(guó)際標(biāo)準(zhǔn)。（√）6.敏捷開(kāi)發(fā)強(qiáng)調(diào)一次性交付所有功能。（×）7.代碼審查可以提高代碼質(zhì)量，但效率較低。（×）8.軟件測(cè)試的目的是證明軟件沒(méi)有缺陷。（×）9.技術(shù)管理專(zhuān)員需要具備領(lǐng)導(dǎo)團(tuán)隊(duì)的能力。（√）10.自動(dòng)化測(cè)試可以提高測(cè)試覆蓋率，但不能完全替代手動(dòng)測(cè)試。（√）四、簡(jiǎn)答題（共5題，每題5分，合計(jì)25分）1.簡(jiǎn)述敏捷開(kāi)發(fā)與瀑布模型的主要區(qū)別。答：敏捷開(kāi)發(fā)強(qiáng)調(diào)迭代、快速反饋和靈活性，而瀑布模型是線(xiàn)性順序的，需求在早期固定。敏捷開(kāi)發(fā)適用于需求不確定的項(xiàng)目，瀑布模型適用于需求明確的項(xiàng)目。2.解釋什么是“測(cè)試用例”？并說(shuō)明其編寫(xiě)要點(diǎn)。答：測(cè)試用例是執(zhí)行測(cè)試的詳細(xì)步驟和預(yù)期結(jié)果，要點(diǎn)包括：可執(zhí)行性、可追溯性、獨(dú)立性、完整性。3.項(xiàng)目風(fēng)險(xiǎn)管理的主要流程有哪些？答：風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)分析（評(píng)估影響和概率）、風(fēng)險(xiǎn)應(yīng)對(duì)（規(guī)避、轉(zhuǎn)移、減輕、接受）、風(fēng)險(xiǎn)監(jiān)控。4.技術(shù)管理專(zhuān)員在團(tuán)隊(duì)協(xié)作中扮演的角色是什么？答：協(xié)調(diào)資源、解決技術(shù)難題、推動(dòng)技術(shù)標(biāo)準(zhǔn)化、培養(yǎng)團(tuán)隊(duì)成員能力、確保項(xiàng)目技術(shù)可行性。5.什么是“技術(shù)債務(wù)”？為什么需要管理？答：技術(shù)債務(wù)是指因快速開(kāi)發(fā)而未優(yōu)化的代碼，導(dǎo)致后期維護(hù)成本增加。管理技術(shù)債務(wù)可以避免長(zhǎng)期累積導(dǎo)致項(xiàng)目崩潰。五、案例分析題（共2題，每題10分，合計(jì)20分）1.某公司開(kāi)發(fā)一款電商平臺(tái)，項(xiàng)目初期需求不明確，客戶(hù)頻繁變更。項(xiàng)目經(jīng)理采用敏捷開(kāi)發(fā)，但團(tuán)隊(duì)成員對(duì)Sprint周期和任務(wù)拆分不熟悉，導(dǎo)致進(jìn)度滯后。問(wèn)題：-如何幫助團(tuán)隊(duì)適應(yīng)敏捷開(kāi)發(fā)？-如何管理客戶(hù)需求變更？答：-通過(guò)培訓(xùn)提升團(tuán)隊(duì)對(duì)敏捷的理解，定期進(jìn)行Sprint回顧和改進(jìn)；-需求變更需通過(guò)變更控制流程，評(píng)估影響后納入Sprint計(jì)劃。2.某軟件項(xiàng)目在測(cè)試階段發(fā)現(xiàn)大量缺陷，導(dǎo)致發(fā)布延期。技術(shù)管理專(zhuān)員發(fā)現(xiàn)代碼復(fù)雜度高，缺乏自動(dòng)化測(cè)試。問(wèn)題：-如何降低代碼復(fù)雜度？-如何改進(jìn)測(cè)試效率？答：-通過(guò)代碼重構(gòu)、模塊化設(shè)計(jì)降低復(fù)雜度；-引入自動(dòng)化測(cè)試框架，建立持續(xù)集成流程。答案與解析一、單選題1.B解析：ScrumMaster負(fù)責(zé)確保團(tuán)隊(duì)遵循敏捷實(shí)踐，如每日站會(huì)、Sprint評(píng)審等。2.B解析：軟件測(cè)試五大原則包括：完整性、一致性、可追溯性、優(yōu)先級(jí)、可重復(fù)性。3.B解析：SPI衡量進(jìn)度偏差，CV衡量成本偏差。4.B解析：白盒測(cè)試需要了解代碼邏輯，適合驗(yàn)證覆蓋率和正確性。5.D解析：FMEA分析用于評(píng)估技術(shù)方案的潛在風(fēng)險(xiǎn)。6.C解析：ISO/IEC25000中，“功能性”指軟件滿(mǎn)足用戶(hù)需求的程度。7.B解析：需求變更日志記錄所有變更歷史和影響。8.C解析：DevOps強(qiáng)調(diào)自動(dòng)化測(cè)試和部署，手動(dòng)測(cè)試不符合DevOps理念。9.A解析：魚(yú)骨圖用于分析問(wèn)題根本原因，識(shí)別潛在風(fēng)險(xiǎn)。10.A解析：程序復(fù)雜度是評(píng)估技術(shù)債務(wù)的常用指標(biāo)。二、多選題1.B,C,E解析：敏捷價(jià)值觀(guān)包括“個(gè)體和互動(dòng)高于流程和工具”“工作軟件高于詳盡文檔”“客戶(hù)合作高于合同談判”“響應(yīng)變化高于遵循計(jì)劃”。2.A,B,C,D解析：測(cè)試類(lèi)型包括單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、性能測(cè)試等。3.A,B,C解析：三重約束是成本、時(shí)間、范圍，質(zhì)量是隱含約束。4.A,B,C解析：知識(shí)管理通過(guò)文檔、代碼審查、技術(shù)分享實(shí)現(xiàn)。5.B,C,D解析：審計(jì)、流程優(yōu)化、培訓(xùn)屬于過(guò)程改進(jìn)，缺陷跟蹤是缺陷管理。三、判斷題1.×解析：Scrum計(jì)劃會(huì)議參與者包括ProductOwner、開(kāi)發(fā)團(tuán)隊(duì)、ScrumMaster。2.√解析：黑盒測(cè)試不關(guān)心內(nèi)部邏輯，只測(cè)試功能。3.√解析：范圍蔓延會(huì)導(dǎo)致資源分散，影響進(jìn)度。4.√解析：技術(shù)債務(wù)是因快速開(kāi)發(fā)導(dǎo)致后期維護(hù)成本增加。5.√解析：ISO9001是質(zhì)量管理體系標(biāo)準(zhǔn)。6.×解析：敏捷開(kāi)發(fā)通過(guò)短周期迭代交付，而非一次性交付。7.×解析：代碼審查效率高且能提升質(zhì)量。8.×解析：測(cè)試目的是發(fā)現(xiàn)缺陷，而非證明軟件完美。9.√解析：技術(shù)管理專(zhuān)員需協(xié)調(diào)團(tuán)隊(duì)，推動(dòng)技術(shù)落地。10.√解析：自動(dòng)化測(cè)試提高效率，但手動(dòng)測(cè)試仍不可少。四、簡(jiǎn)答題1.敏捷開(kāi)發(fā)與瀑布模型的主要區(qū)別答：敏捷開(kāi)發(fā)采用迭代和增量方式，需求可變，強(qiáng)調(diào)團(tuán)隊(duì)協(xié)作和快速反饋；瀑布模型是線(xiàn)性順序的，需求在早期固定，文檔驅(qū)動(dòng)。敏捷適用于需求不明確的項(xiàng)目，瀑布模型適用于需求穩(wěn)定的系統(tǒng)。2.測(cè)試用例的定義及編寫(xiě)要點(diǎn)答：測(cè)試用例是執(zhí)行測(cè)試的步驟和預(yù)期結(jié)果，要點(diǎn)包括：明確可執(zhí)行步驟、可追溯需求、保持獨(dú)立性、覆蓋所有場(chǎng)景。3.項(xiàng)目風(fēng)險(xiǎn)管理的主要流程答：風(fēng)險(xiǎn)識(shí)別（頭腦風(fēng)暴、歷史數(shù)據(jù)）、風(fēng)險(xiǎn)分析（評(píng)估影響和概率）、風(fēng)險(xiǎn)應(yīng)對(duì)（規(guī)避、轉(zhuǎn)移、減輕、接受）、風(fēng)險(xiǎn)監(jiān)控（定期跟蹤）。4.技術(shù)管理專(zhuān)員在團(tuán)隊(duì)協(xié)作中的角色答：協(xié)調(diào)資源分配、解決技術(shù)瓶頸、制定技術(shù)標(biāo)準(zhǔn)、組織技術(shù)培訓(xùn)、確保技術(shù)方案可行，促進(jìn)團(tuán)隊(duì)高效協(xié)作。5.技術(shù)債務(wù)的定義及管理原因答：技術(shù)債務(wù)是因快速開(kāi)發(fā)未優(yōu)化的代碼，導(dǎo)致后期維護(hù)成本增加。管理原因：避免長(zhǎng)期積累導(dǎo)致項(xiàng)目崩潰，提升代碼可維護(hù)性。五、案例分