敏捷测试面试题

本文档包含 80 道敏捷测试高频重点面试题，涵盖敏捷开发模式、敏捷测试方法、测试驱动开发（TDD）、行为驱动开发（BDD）、持续集成/持续部署（CI/CD）、测试左移和测试右移、敏捷测试实践等核心知识点。

一、敏捷开发模式（15 题）

Q1: 什么是敏捷开发？敏捷开发的核心价值观是什么？

答案： 敏捷开发是一种以人为核心、迭代推进、持续交付价值的开发方式，重点不是把计划一次写死，而是在短周期里不断拿到反馈并快速调整。

它的四条核心价值观是：个体和互动高于流程和工具，工作的软件高于详尽文档，客户合作高于合同谈判，响应变化高于遵循计划。

落到实践里，通常会体现为频繁交付可用软件、欢迎需求变化、业务与研发紧密协作、关注可持续节奏，并通过持续反思来改进团队工作方式。

Q2: Scrum 框架的核心概念是什么？

答案： Scrum 可以记成三部分：角色、事件、工件。

角色上，Product Owner 负责需求价值和优先级，Scrum Master 保障流程顺畅并协助团队移除障碍，开发团队负责在迭代内把需求做成可交付的软件增量。

事件上，一个 Sprint 通常是 1-4 周的固定周期，期间会有计划会、每日站会、评审会和回顾会，分别对应“定目标、同步进展、展示成果、持续改进”。

工件上，Product Backlog 是全量需求池，Sprint Backlog 是本迭代承诺完成的事项，Increment 是最终可工作的产出。

Q3: 敏捷开发中测试的角色是什么？

答案： 在敏捷团队里，测试不只是“验收者”，更是质量共建的一员。既要验证需求是否正确落地、及时发现缺陷，也要在需求讨论阶段就把风险提前暴露出来。

测试还承担质量倡导的角色：推动团队形成统一的质量标准，促进开发、产品、测试之间的协作，让“质量左移”真正落地，而不是只在提测后集中兜底。

另外，测试通常也是自动化和流程改进的推动者，通过维护自动化回归、复盘缺陷模式、优化测试策略，持续提升交付效率和稳定性。

Q4: 敏捷开发与传统瀑布模型的区别是什么？

答案： 两者最大的差别在节奏和反馈机制。敏捷是迭代增量开发，短周期持续交付；瀑布是按阶段顺序推进，通常在后期集中交付。

在需求处理上，敏捷默认需求会变化，强调快速响应；瀑布更强调前期需求冻结。测试时机也不同：敏捷强调持续测试和快速反馈，瀑布往往把测试放在开发后段。

协作方式上，敏捷强调跨职能团队并行协作，瀑布更偏阶段交接；文档上敏捷追求“够用且可维护”，瀑布通常更强调完整和详尽。

Q5: 敏捷开发中如何管理测试活动？

答案： 敏捷里的测试管理要轻计划、重执行、强反馈。测试计划通常按迭代滚动更新，以风险优先为原则，而不是一开始就做成长期静态文档。

执行上强调持续测试和自动化优先：开发过程就介入验证，关键回归尽量自动化，保证每次变更后都能快速给出质量反馈。

缺陷管理上要做到“快发现、快修复、快回归”，并通过可视化报告让团队实时看到质量状态。日常依托站会和跨角色沟通，把测试问题尽量在迭代内闭环处理。

二、敏捷测试方法（15 题）

Q6: 什么是敏捷测试？敏捷测试的特点是什么？

答案： 敏捷测试是在敏捷开发节奏下进行的质量保障活动，核心是持续测试、快速反馈和团队协作，而不是等到开发完成后再集中验收。

它的典型特点是：测试活动贯穿整个 Sprint，回归验证尽量自动化，测试人员深度参与需求和设计讨论，发现问题后能快速闭环。

因为敏捷需求会动态调整，所以敏捷测试也要求策略可迭代，测试范围和优先级能够随业务变化灵活更新。

Q7: 敏捷测试象限是什么？

答案： 敏捷测试象限用于区分“测试的目标”和“测试的导向”，帮助团队在一个迭代里合理分配测试活动：

Q1: 单元测试、组件测试（技术导向，支持团队）
     ↓
Q2: 功能测试、场景测试、用户体验测试（业务导向，支持团队）
     ↓
Q3: 探索性测试、可用性测试、用户验收测试（业务导向，评价产品）
     ↓
Q4: 性能测试、安全测试、可维护性测试（技术导向，评价产品）

其中 Q1、Q2 更偏“支持团队开发”，通常自动化占比更高；Q3、Q4 更偏“评价产品质量”，分别覆盖业务体验类和技术质量类风险。面试时可以补一句：象限不是替代关系，而是互补关系。

Q8: 敏捷测试中如何平衡自动化和手工测试？

答案： 平衡的关键不是“二选一”，而是按测试目标来分工：重复、稳定、回归频繁的场景优先自动化；探索性、可用性、新功能早期验证等场景更依赖手工测试。

实操里通常会先把核心业务链路和高频回归做成自动化，再保留一定比例的手工探索，持续补充自动化空白，避免脚本越写越多却覆盖不到真实风险。

从结构上看，测试金字塔依然适用：底层大量单元测试，中层适量集成测试，顶层少量 E2E。越靠上越昂贵，越要控制数量和稳定性。

Q9: 敏捷测试中如何应对需求变化？

答案： 应对需求变化最有效的方法是测试前移：在需求澄清阶段就参与讨论，把验收标准、边界条件和风险点提前对齐，避免后期被动返工。

当需求变更发生时，测试要能快速调整范围和优先级，及时更新用例与数据；自动化回归在这里很关键，它能帮助团队用较低成本验证“改动是否影响旧功能”。

同时要保持信息透明，变更内容、影响范围和测试结论尽快同步给开发与产品。每个迭代结束后再复盘变更带来的问题，逐步优化团队的应对机制。

Q10: 敏捷测试中如何保证测试质量？

答案： 保证测试质量要从策略、执行和反馈三方面同时发力。策略上以风险为导向，先覆盖核心流程和高影响场景，再逐步扩展覆盖面。

执行上保持持续测试和及时验证，尤其是关键改动后的快速回归；缺陷管理要形成闭环，从发现、定位、修复到回归验证都有明确时效。

另外要做评审和度量：定期评审用例有效性与结果质量，用覆盖率、缺陷趋势等指标观察质量变化，推动测试方法持续改进。

三、测试驱动开发（TDD）（15 题）

Q11: 什么是 TDD？TDD 的流程是什么？

答案： TDD（测试驱动开发）的核心是先写测试，再写实现，最后重构。它强制开发者先想清楚“期望行为是什么”，再动手编码。

流程通常是经典的“红-绿-重构”：先写一个会失败的测试（Red），再写最小实现让测试通过（Green），最后在测试保护下优化代码结构（Refactor）。

循环：

编写测试 → 运行失败 → 编写代码 → 运行通过 → 重构 → 运行通过 → 循环

Q12: TDD 的优势是什么？

答案： TDD 的直接收益是质量更稳定：代码通常更简洁、可维护性更好，回归时也更有保障。

它还能自然提升覆盖率，因为功能开发与测试编写是同步进行的；很多测试本身也能作为行为文档，帮助团队理解系统边界。

另外，TDD 会倒逼开发先思考接口和设计，减少“先堆功能再补救”的情况。配合快速反馈循环，能更早暴露问题、降低后期修复成本。

Q13: TDD 的挑战是什么？

答案： TDD 的挑战主要在于习惯切换。很多人一开始会觉得节奏变慢，因为要先写测试、再写实现，需要一段适应期。

另一个常见问题是测试维护成本：如果测试写得耦合过高或边界不清，后续重构时会出现“改实现先改一片测试”的负担。

最后，TDD 往往依赖团队共识。如果只有个别人坚持、流程和代码评审不配套，实践很容易退化成“临时补测试”。

Q14: TDD 中如何编写测试用例？

答案： TDD 写用例时，先保证命名清晰，让人一眼看出“在什么条件下，期望什么结果”：

// 好的命名
testCalculateTotalPrice_WithValidItems_ReturnsCorrectTotal()
testLogin_WithInvalidCredentials_ThrowsException()

// 命名格式：test方法名_条件_预期结果

结构上推荐 AAA（Arrange-Act-Assert）模式，把准备、执行、断言分开写，代码更易读、问题更容易定位：

@Test
public void testCalculateTotal() {
    // Arrange（准备）
    ShoppingCart cart = new ShoppingCart();
    cart.addItem(new Item("product1", 10.0));
    cart.addItem(new Item("product2", 20.0));

    // Act（执行）
    double total = cart.calculateTotal();

    // Assert（断言）
    assertEquals(30.0, total, 0.01);
}

实践里再把握几个原则：尽量单一关注点、测试之间互不依赖、执行速度要快、结果可重复，这样才能支撑高频回归。

Q15: TDD 中如何重构代码？

答案： TDD 重构的前提是测试已经通过。也就是说，先确认功能正确，再动结构，不要把“修功能”和“改结构”混在一次提交里。

重构时遵循小步快跑：每次只做一小处调整，持续跑测试，确保外部行为不变。常见动作包括提取方法、提取类、消除重复和简化复杂分支。

判断重构是否成功可以看三点：测试持续通过、对外功能不变、代码可读性和可维护性明显提升。

四、行为驱动开发（BDD）（15 题）

Q16: 什么是 BDD？BDD 的特点是什么？

答案： BDD（行为驱动开发）强调先用业务可理解的语言定义系统行为，再把这些行为落成可执行测试和实现代码。

它的价值在于“业务可读、技术可执行”：产品、测试、开发能围绕同一份行为描述协作，减少需求理解偏差。

从落地角度看，BDD 的规范本身就是测试资产，既能自动执行，也能持续验证系统是否仍符合业务预期。

Q17: BDD 的格式是什么？

答案： BDD 常用 Gherkin 语法描述行为，核心结构是 Feature -> Scenario -> Given/When/Then：

Feature: 用户登录
  作为用户
  我想要登录系统
  以便访问我的账户

  Scenario: 成功登录
    Given 用户访问登录页面
    When 用户输入正确的用户名和密码
    And 用户点击登录按钮
    Then 用户应该成功登录
    And 用户应该看到欢迎页面

  Scenario: 登录失败
    Given 用户访问登录页面
    When 用户输入错误的密码
    And 用户点击登录按钮
    Then 用户应该看到错误提示
    And 用户应该仍在登录页面

其中 Feature 描述业务能力，Scenario 描述具体场景，Given/When/Then 分别对应前置条件、用户动作和预期结果，And/But 用于补充上下文或结果。

Q18: BDD 工具有哪些？

答案： 常见 BDD 工具有 Cucumber、SpecFlow、Behave、JBehave、Gauge。

Cucumber 生态最成熟，支持多语言；SpecFlow 适合 .NET 团队并且和 Visual Studio 集成好；Behave、JBehave 分别更贴近 Python 和 Java 技术栈；Gauge 则以多语言支持和易用性见长。

选型时优先看三件事：团队主语言、现有 CI 集成能力、以及报告与维护成本。

Q19: 如何使用 Cucumber 进行 BDD 测试？

答案： Cucumber 的基本落地路径是三步：先写 Feature，再实现 Step Definition，最后接入执行与报告。

第一步，编写 Feature 文件，用 Gherkin 明确业务场景和预期行为：

Feature: 计算器
  Scenario: 加法运算
    Given 我有一个计算器
    When 我输入 5 和 3
    And 我选择加法
    Then 结果应该是 8

第二步，编写 Step 定义，把自然语言步骤映射到可执行代码：

@Given("我有一个计算器")
public void iHaveACalculator() {
    calculator = new Calculator();
}

@When("我输入 {int} 和 {int}")
public void iEnterNumbers(int a, int b) {
    this.a = a;
    this.b = b;
}

@When("我选择加法")
public void iSelectAddition() {
    result = calculator.add(a, b);
}

@Then("结果应该是 {int}")
public void resultShouldBe(int expected) {
    assertEquals(expected, result);
}

第三步，把 Cucumber 测试接入本地或 CI 流程，持续运行并查看报告，确保行为规范与实现保持一致。

Q20: BDD 与 TDD 的区别是什么？

答案： 两者都强调“测试先行”，但关注重心不同：TDD 更偏技术实现与代码设计，BDD 更偏业务行为与团队共识。

表达方式上，TDD 主要通过测试代码表达需求；BDD 借助自然语言场景（如 Gherkin）让业务和技术都能参与讨论。

实践里它们并不冲突。很多团队会用 BDD 对齐业务行为，再用 TDD 驱动底层实现，形成“上层行为清晰、下层实现稳健”的组合。

五、持续集成/持续部署（CI/CD）（15 题）

Q21: 什么是 CI/CD？CI/CD 的作用是什么？

答案： CI/CD 可以拆开理解：CI（持续集成）强调频繁合并代码并自动验证，CD（持续交付/持续部署）强调把可发布产物自动推进到各环境。

它的核心价值是把“构建、测试、发布”流水线化，从而更快发现集成问题、更早暴露缺陷，并显著减少手工操作导致的发布风险。

对团队来说，CI/CD 不只是提速工具，更是稳定交付机制：发布频率提升的同时，质量可观测性也更强。

Q22: CI/CD 的流程是什么？

答案： 典型流程是：代码提交触发流水线，先自动构建（编译/打包），再执行自动化测试（单测、集成、回归）。

通过测试后进入质量检查，如静态扫描、覆盖率、安全扫描等；满足门禁后再按策略部署到测试、预发，最终到生产环境。

上线后还要配套监控与反馈，把构建、测试、发布和运行期状态统一回传给团队，形成完整闭环。

Q23: 如何在 CI/CD 中集成自动化测试？

答案： 核心思路是把自动化测试做成流水线的标准阶段，在每次提交或合并时自动触发，并把结果沉淀成可追踪报告。

比如在 Jenkins 中，可以把构建、测试、报告拆分成独立 stage：

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean compile'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
        stage('Report') {
            steps {
                junit 'target/surefire-reports/*.xml'
            }
        }
    }
}

在 GitLab CI 中，测试任务通常放在 test 阶段，并上传 JUnit 报告供平台展示：

test:
  stage: test
  script:
    - mvn test
  artifacts:
    reports:
      junit: target/surefire-reports/*.xml

在 GitHub Actions 中，也可以直接在工作流里执行多套测试命令：

- name: Run Tests
  run: |
    mvn test
    npm test

无论使用哪种平台，关键都一样：失败要阻断后续发布，结果要可视化，异常要能及时通知到责任人。

Q24: CI/CD 中如何设置测试门禁？

答案： 测试门禁本质是“上线前的自动判定规则”。通常会同时设置质量门禁（通过率、覆盖率、缺陷阈值）、性能门禁（响应时间、资源占用）和安全门禁（漏洞扫描、合规检查）。

只要任一门禁不达标，流水线就应停止并阻断发布，避免把高风险变更带到下一环境。一个典型实现方式如下：

stage('Quality Gate') {
    steps {
        script {
            def testResults = sh(
                script: 'mvn test',
                returnStatus: true
            )
            if (testResults != 0) {
                error('Tests failed, blocking deployment')
            }
        }
    }
}