2025年敏捷技术测试题及答案

2025年敏捷技术测试题及答案一、单项选择题（每题2分，共30分）1.以下哪项不属于Scrum框架中定义的事件？A.Sprint计划会B.每日站会C.需求评审会D.Sprint回顾会答案：C解析：Scrum核心事件包括Sprint计划会、每日站会、Sprint评审会、Sprint回顾会，需求评审会非Scrum标准事件。2.敏捷开发中，用户故事的“可测试性（Testable）”主要指？A.故事能被自动化测试覆盖B.测试人员能明确验证完成标准C.开发人员能编写单元测试D.产品负责人能理解测试用例答案：B解析：用户故事的可测试性要求验收标准清晰，测试团队能明确判断是否完成，而非仅指技术实现。3.某团队采用2周Sprint，当前Sprint剩余3天时，开发团队发现一个高风险缺陷需要4天修复。最合理的处理方式是？A.延长Sprint至缺陷修复完成B.标记该用户故事为未完成，纳入下个SprintC.要求测试团队降低缺陷优先级D.临时增加开发人员赶工答案：B解析：Sprint长度固定，未完成的用户故事应重新评估优先级，放入产品待办列表，下个Sprint再处理。4.看板方法中“在制品限制（WIPLimit）”的主要目的是？A.减少任务切换带来的效率损失B.确保每个任务按时完成C.限制团队同时处理的任务数量D.提高单个任务的处理质量答案：A解析：WIP限制通过减少并行任务，降低上下文切换成本，提升流程流畅性。5.XP（极限编程）的核心实践中，“持续集成”强调？A.每天至少集成一次代码并运行测试B.每个功能完成后立即集成C.Sprint结束前完成整体集成D.由专门集成团队负责集成答案：A解析：XP要求开发人员每天多次将代码集成到主干，并运行自动化测试，确保快速反馈。6.敏捷团队中，“测试左移（ShiftLeft）”的核心目标是？A.将测试工作提前到需求阶段B.让开发人员承担更多测试任务C.减少后期大规模测试的成本D.提高自动化测试的覆盖率答案：C解析：测试左移通过早期介入（如需求分析、设计阶段）发现缺陷，降低后期修复成本。7.产品待办列表（ProductBacklog）的维护责任人是？A.ScrumMasterB.开发团队C.产品负责人D.测试团队答案：C解析：产品负责人（PO）负责管理产品待办列表，确保其有序、清晰并反映业务价值。8.以下哪项不符合敏捷估算的“故事点（StoryPoint）”原则？A.基于相对复杂度而非绝对时间B.团队共同参与估算C.用斐波那契数列（如1,2,3,5,8）表示D.故事点需转换为具体工时答案：D解析：故事点是相对估算单位，不直接对应工时，用于衡量任务间的复杂度差异。9.Sprint评审会的主要参与者是？A.仅Scrum团队B.Scrum团队和关键利益相关者C.产品负责人和ScrumMasterD.开发团队和测试团队答案：B解析：评审会需邀请客户、用户等利益相关者，展示Sprint成果并获取反馈。10.敏捷团队遇到“需求频繁变更”问题时，最有效的应对措施是？A.拒绝变更，按原计划执行B.要求产品负责人冻结需求C.优化需求拆分粒度，提高响应能力D.增加缓冲时间应对变更答案：C解析：敏捷提倡通过小而可交付的用户故事，快速响应变更，而非被动抵抗。11.以下哪项是“自组织团队（Self-organizingTeam）”的典型特征？A.由项目经理分配具体任务B.团队自主决定如何完成目标C.严格按照流程文档执行D.依赖外部专家指导工作答案：B解析：自组织团队自主规划工作方式、分配任务，无需外部指令。12.自动化测试在敏捷中的核心价值是？A.减少测试人员数量B.快速验证变更影响C.替代手动测试D.提高测试用例覆盖率答案：B解析：敏捷需要快速反馈，自动化测试通过持续运行验证代码变更的正确性，支持快速迭代。13.某团队Sprint燃尽图（BurndownChart）在中期出现上升趋势，可能的原因是？A.剩余工作量估算更准确B.团队效率显著提升C.新增了额外任务D.测试发现大量缺陷答案：C解析：燃尽图上升通常因Sprint中新增任务或重新估算后剩余工作量增加。14.看板方法与Scrum的主要区别在于？A.看板没有固定迭代周期，Scrum有SprintB.看板强调角色分工，Scrum强调自组织C.看板关注流程可视化，Scrum关注交付增量D.看板使用故事点估算，Scrum使用工时估算答案：A解析：看板是持续流动的工作方式，无固定迭代；Scrum通过固定长度的Sprint交付增量。15.敏捷原则中“可用的软件是进度的主要度量标准”意味着？A.代码行数越多进度越快B.完成的测试用例越多进度越快C.可运行、满足用户需求的功能越多进度越快D.文档完成度越高进度越快答案：C解析：敏捷关注实际交付价值，可用软件（可运行、满足验收标准）是核心度量。二、判断题（每题1分，共10分。正确填“√”，错误填“×”）1.Scrum团队必须包含专门的测试人员。（）答案：×解析：Scrum团队是跨职能的，开发团队应具备完成工作所需的所有技能，不强制要求专门测试角色。2.用户故事的“独立（Independent）”是指故事之间没有依赖关系。（）答案：×解析：独立指故事应尽可能减少依赖，但完全无依赖难以实现，核心是避免强耦合。3.每日站会的时长应控制在15分钟内，无论团队规模大小。（）答案：√解析：Scrum规定每日站会时间盒为15分钟，确保高效沟通。4.看板的“流动效率（FlowEfficiency）”等于增值时间除以总周期时间。（）答案：√解析：流动效率衡量任务在流程中实际产生价值的时间占比，计算公式为增值时间/总周期时间。5.XP的“结对编程（PairProgramming）”要求两位程序员同时编写同一段代码，一人编码一人审查。（）答案：√解析：结对编程是两人协作开发，实时评审，提升代码质量和知识共享。6.Sprint回顾会的主要目的是总结经验，改进团队流程。（）答案：√解析：回顾会聚焦“如何做得更好”，提出具体改进措施。7.敏捷团队中，产品负责人可以在Sprint中途调整Sprint目标。（）答案：×解析：Sprint目标在Sprint计划会确定，中途一般不调整，若需调整需终止当前Sprint。8.测试驱动开发（TDD）的流程是“编写测试用例→编写代码使测试通过→重构代码”。（）答案：√解析：TDD遵循“红→绿→重构”循环，先写失败的测试，再实现功能，最后优化代码。9.故事点估算中，团队可以使用PlanningPoker（计划扑克）方法达成共识。（）答案：√解析：计划扑克是常用的集体估算方法，通过讨论减少个人偏差。10.敏捷中的“持续交付（ContinuousDelivery）”要求每次代码提交都能自动部署到生产环境。（）答案：×解析：持续交付确保代码可随时部署，但部署到生产需人工决策；持续部署才是自动部署。三、简答题（每题8分，共40分）1.请简述Scrum团队自组织（Self-organizing）的三个具体体现。答案：（1）任务分配自主：团队内部自行决定谁负责哪个用户故事，无需外部指令；（2）流程改进自主：通过Sprint回顾会识别问题，主动提出并实施流程优化措施；（3）技术方案决策自主：针对具体技术问题（如架构选择、工具使用），团队集体讨论并确定方案，而非依赖外部专家。2.用户故事的INVEST原则具体指什么？请分别解释。答案：（1）独立（Independent）：故事应尽可能减少与其他故事的依赖，便于灵活排序；（2）可协商（Negotiable）：故事是沟通的起点而非合同，细节可在开发中与PO协商；（3）有价值（Valuable）：对用户或业务有明确价值，符合产品目标；（4）可估算（Estimable）：团队能理解故事内容，进行合理估算；（5）小（Small）：规模适中，可在一个Sprint内完成；（6）可测试（Testable）：有明确的验收标准，能验证是否完成。3.看板方法中“可视化工作流程”的具体实践包括哪些？其核心目的是什么？答案：实践包括：（1）绘制价值流图，明确工作阶段（如需求→开发→测试→部署）；（2）使用物理或电子看板，将任务状态（待办→进行中→已完成）可视化；（3）标注每个任务的负责人、优先级、阻塞原因等信息；核心目的：通过透明化工作状态，暴露流程瓶颈（如测试阶段堆积），促进团队协作和问题快速解决。4.敏捷测试中“探索式测试（ExploratoryTesting）”与“脚本化测试（ScriptedTesting）”的主要区别是什么？各自适用场景？答案：区别：（1）探索式测试：无固定脚本，测试人员边设计边执行，依赖经验和直觉发现潜在缺陷；（2）脚本化测试：基于预先编写的测试用例执行，结果可重复验证；适用场景：探索式测试适用于需求不明确、新功能首次测试或需要挖掘深层逻辑问题的场景；脚本化测试适用于需求稳定、需频繁重复执行（如回归测试）的场景。5.请说明“敏捷三角（AgileTriangle）”与传统项目三角的区别，并解释其核心思想。答案：传统项目三角（范围、时间、成本）强调三者平衡，通常固定两个变量调整第三个；敏捷三角（价值、质量、约束）以价值为核心，约束（时间、资源）固定，通过调整范围（选择高价值需求）确保交付质量；核心思想：敏捷更关注为用户和业务创造价值，而非机械满足固定范围，通过持续交付增量价值应对变化。四、案例分析题（每题10分，共20分）案例1：某互联网团队采用2周Sprint，当前Sprint进行到第5天（总10天），产品负责人突然提出一个紧急需求：“用户反馈支付功能有时报错，需在下个版本修复”。开发团队评估该需求需3天开发+2天测试，当前Sprint剩余5天。问题：如果你是ScrumMaster，应如何处理？请列出具体步骤。答案：处理步骤：（1）立即组织临时会议，与产品负责人、开发团队确认需求优先级：明确支付功能报错是否影响用户交易（高影响），是否有临时解决方案（如回滚版本）；（2）评估当前Sprint剩余容量：当前Sprint已进行5天，剩余5天，开发团队剩余可用工时（假设团队每日可用80小时，已用4天×80=320小时，总Sprint工时10×80=800小时，剩余480小时）；（3）分析当前Sprint待完成的用户故事：若现有故事均为低优先级且未开始，可替换为支付修复需求；若现有故事已部分完成，需评估拆分可能性（如暂停非关键任务）；（4）与产品负责人协商：若必须在本次Sprint完成，需调整Sprint目标（如减少原计划的功能数量），并更新Sprint待办列表；（5）同步团队：在每日站会中说明变更原因，确保团队理解新目标，调整工作优先级；（6）跟踪进展：后续每日站会关注支付修复任务的阻塞点（如依赖接口、测试环境），及时移除障碍。案例2：某金融科技团队在Sprint评审会上，用户提出新功能“转账限额提醒”的展示位置不符合使用习惯，要求调整。开发团队表示该功能已完成，调整需2天开发+1天测试，当前Sprint已结束。问题：从敏捷原则出发，应如何处理该反馈？请说明理由。答案：处理方式：（1）首先感谢用户反馈，将其记录到产品待办列表，标记为高优先级（因涉及